12
Кроме того, в последние годы появились и стали активно внедряться на
практике следующие модели данных:
1) постреляционная модель (представляет собой расширенную
реляционную модель, снимающую ограничение неделимости данных,
хранящихся в записях таблиц; она допускает многозначные поля – поля,
значения которых состоят из подзначений, набор значений многозначных полей
считается самостоятельной таблицей, встроенной в основную таблицу);
2) объектноориентированная модель (база данных, в которой данные
моделируются в виде объектов, их атрибутов, методов и классов);
3) многомерная модель (позволяют оперативно обрабатывать информацию
для проведения анализа и принятия решения, т.е. означает многомерное
логическое представление структуры информации при описании и в операциях
манипулирования данными).
База данных предполагает наличие комплекса программных средств,
обслуживающих эту базу данных и позволяющих использовать содержащуюся в
ней информацию. Такие комплексы программ называются СУБД (системы
управления базой данных). Это комплекс программных средств,
предназначенных для создания структуры новой базы, наполнение ее
содержимым, редактирование содержимого и визуализации информации. Под
визуализацией информации базы понимается отбор отображаемых данных в
соответствии с заданным критерием, их упорядочение, оформление и
последующая выдача на устройства вывода или передачи по каналам связи.
Проще говоря, централизованное управление данными, хранимыми в базе,
доступ к ним, поддержка их в актуальном состоянии осуществляется с помощью
программы – СУБД.
Основными функциями СУБД являются:
1) управление данными во внешней памяти (на дисках);
2) управление данными в оперативной памяти с использованием дискового
кэша;
13
3) журнализация изменений, резервное копирование и восстановление
базы данных после сбоев;
4) поддержка языков БД (язык определения данных, язык
манипулирования данными).
СУБД также имеют ряд классификационных признаков.
По числу поддерживаемых уровней моделей данных СУБД
подразделяются на одноуровневые, двухуровневые и трехуровневые системы.
По языкам общения СУБД делятся на открытые, замкнутые и смешанные.
Открытые системы – это системы, в которых для обращения к базам данных
используются универсальные языки программирования. Замкнутые системы
имеют собственные языки общения с пользователями БД. Открытые системы в
настоящее время используются редко.
По выполняемым функциям СУБД делятся на информационные и
операционные. Информационные СУБД позволяют организовать хранение
информации и доступ к ней. Для выполнения более сложной обработки
необходимо писать специальные программы. Операционные СУБД выполняют
достаточно сложную обработку, например, автоматически позволяют получать
агрегированные показатели, не хранящиеся непосредственно в базе данных,
могут изменять алгоритмы обработки и т. д.
По сфере возможного применения различают универсальные и
специализированные (проблемноориентированные) СУБД.
Классификация по типу модели распространяется не только на базы
данных, но и на СУБД. То есть, они так же делятся на иерархичные, сетевые и
реляционные.
Подробнее следует рассмотреть классификацию СУБД по способу доступа
к базам данных. По данному признаку они подразделяются на:
1) файлсерверные (предполагают выделение одной из машин сети в
качестве центральной (главный сервер файлов), где хранится совместно
используемая централизованная база данных. Все другие машины исполняют
роль рабочих станций. Файлы базы данных в соответствии с пользовательскими
14
запросами передаются на рабочие станции, где в основном и производится их
обработка. При большой интенсивности доступа к одним и тем же данным
производительность информационной системы падает.);
2) клиентсерверные (располагается на сервере вместе с БД и осуществляет
доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы
на обработку данных обрабатываются клиентсерверной СУБД
централизованно. Недостаток клиентсерверных СУБД состоит в повышенных
требованиях к серверу. Достоинства: потенциально более низкая загрузка
локальной сети; удобство централизованного управления; удобство обеспечения
таких важных характеристик как высокая надёжность, высокая доступность и
высокая безопасность.)
3) встраиваемые (встраиваемая СУБД это библиотека, которая позволяет
унифицированным образом хранить большие объемы данных на локальных
машинах).
Многие специалисты указывают на распространённую ошибку,
состоящую в некорректном использовании термина «база данных» вместо
термина «система управления базами данных», и указывают на необходимость
различения этих понятий.
1.2. Проектирование баз данных
Одной из наиболее трудоемких и сложных задач при создании
информационных систем является проектирование базы данных, как основы
подсистемы представления и обработки данных. Проектирование БД является
очень важным этапом, от которого зависят последующие этапы разработки
СУБД. Время, затраченное разработчиком на проектирование БД, обычно
окупается высокой скоростью реализации проекта.
Организация данных требует предварительного моделирования
предметной области, т. е. построения инфологической модели данных, главным
назначением которой является систематизация разнообразной информации и
15
отражение ее свойств по содержанию, структуре, объему, связям, динамике с
учетом удовлетворения информационных потребностей всех категорий
пользователей. Информационнологическая (инфологическая) модель отражает
предметную область в виде совокупности информационных объектов и их
структурных связей. Основой для построения инфологической модели базы
данных является формализованное описание данных предметной области,
которые рассматриваются как совокупность информационных объектов,
содержащих наборы реквизитов и структурных связей этих объектов.
Предметная область включает объекты (клиенты, счета клиентов, документы,
операции и т. д.), их свойства и характеристики, взаимодействия и процессы над
ними.
Таким образом, перед созданием базы данных необходимо располагать
описанием выбранной предметной области, которое должно охватывать
реальные объекты и процессы, иметь всю необходимую информацию для
удовлетворения предполагаемых запросов пользователя и определить
потребности в обработке данных
2
.
Основные задачи проектирования баз данных:
1) обеспечение хранения в БД всей необходимой информации;
2) обеспечение возможности получения данных по всем необходимым
запросам;
3) сокращение избыточности и дублирования данных;
4) обеспечение целостности базы данных.
Процесс проектирования БД начинается с постановки задачи и выявления
объектов, процессов или сущностей предметной области. Например, объектами
могут быть предприятия, вкладчики, банки. Для каждого из объектов выбирается
набор характеризующих его свойств (полей, реквизитов). Для предприятия –
наименование, адрес, расчетный счет, название банка и пр., для вкладчика –
фамилия, имя, отчество, адрес, паспортные данные, место работы и пр. Затем в
2
Проектирование базы данных http://inf8.gym5cheb.ru/p28aa1.html
16
процессе анализа определяется информационная потребность каждой задачи,
которую составляют входные и результатные документы, и определяется
периодичность решения задач
3
.
Работа проектировщиков БД в значительной степени зависит от качества
инфологической модели. Инфологическая модель создается для того, чтобы на
ее основе можно было построить модель данных, т. е. она должна учитывать
особенности реализации выбранной СУБД. На основе инфологической модели
строятся концептуальная, логическая и физическая модели. Отсюда вытекают
основные этапы, на которые разбивается процесс проектирования базы данных
информационной системы:
1. Концептуальное (инфологическое) проектирование это процедура
конструирования информационной модели, не зависящей от какихлибо
физических условий реализации;
2. Логическое (даталогическое) проектирование это процесс
конструирования информационной модели на основе существующих моделей
данных, не зависимо от используемой СУБД и других условий физической
реализации;
3. Физическое проектирование это процедура создания описания
конкретной реализации БД с описанием структуры хранения данных, методов
доступа к данным.
Первый этап проектирования БД – концептуальное проектирование –
состоит в разработке концептуальных моделей данных для каждого из
существующих типов пользователей создаваемого приложения. Представления
пользователя включает в себя данные, необходимые конкретному пользователю
для принятия решения или выполнения некоторого задания. Обычно
представление пользователя отражает некоторую функциональную область в
общем поле деятельности предприятия. Например, производство, маркетинг,
сбыт, управление кадрами или складами, учет. Определить характеристики
3
Системы управления базами данных
http://edu.dvgups.ru/METDOC/ITS/STRPRO/INF_TEH_STR/METOD/SULDIN/frame/6.htm
17
представлений пользователей можно с помощью различных методов. Начинать
следует с изучения диаграмм потоков данных. Затем рекомендуется провести
опросы потенциальных пользователей, изучить условие процедуры,
существующие отчеты и формы и/или провести обследование работы
предприятия.
Исходя из представлений о предметной области, создание концептуальной
модели данных каждого из пользователей включает в себя следующие шаги:
1) определение типов сущности;
2) определение типов связей;
3) определение атрибутов и связывание их с типами сущностей и связей;
4) определение доменов атрибутов;
5) определение атрибутов, являющихся потенциальными и первичными
ключами;
6) создание диаграмм "сущность – связь” ( ERдиаграмма);
7) обсуждение локальной концептуальной модели с конечным
пользователем.
Первый этап построения локальной концептуальной модели состоит в
определении основных пунктов, которые могут интересовать пользователя. Эти
пункты являются типами сущностей, входящих в модель. Один из методов
идентификации сущностей состоит в изучении спецификаций по выполнению
конкретных функций пользователей на данном предприятии. Из этих
спецификаций следует извлечь все используемые в них существительные или
сочетания существительного и прилагательного. Например, «Личный номер»,
«Фамилия работника», «Номер объекта недвижимости». Затем среди них
выбираются самые крупные объекты или представляющие интерес концепции.
Например, свойства «Личный номер» и «Фамилия работника» объединяются
связью объекта «Работник Альтернативный способ идентификации сущностей
состоит в поиске объектом, которые существуют независимо друг от друга.
18
Например, объект «Работник» является сущностью, потому что работник
существует независимо от того, известен ли его адрес, телефон или нет
4
.
Выбранные имя и описание сущностей помещается в словарь данных. Если
сущность известна под разными именами, все дополнительные имена
рекомендуется заменить синонимами и также занести в словарь данных. После
выделения сущностей следующим этапом разработки будет установление всех
существующих между ними связей. При определении существующих связей
выбираются те выражения, в которых содержаться глаголы. Например, персонал
занимается объектами недвижимости, арендатор просматривает сведения от
объектах недвижимости, подразделение имеет персонал. В большинстве случает
связи являются парными, т.е. только между двумя сущностями.
После установления связей следует проанализировать степень участия
каждой из сущностей в конкретном типе связей. Степень участия может быть
полной либо частной. В словарь данных помещаем описание каждой связи. Для
представления сущностей и связей используется диаграмма «сущностьсвязь».
Далее необходимо выявить все данные, описывающие сущности и связи.
Выбираются все существительные, и из них определяются атрибуты в том
случае, если они отражают свойство, качество.
Что касается определения доменов для всех атрибутов, присутствующих в
модели, то они должны содержать следующие данные: набор допустимых
значений для атрибутов, с ведения о размере и формате каждого из полей
атрибута. После определения доменов атрибутов их имена и характеристики
помещаются в словарь данных.
На следующем этапе определяются все потенциальные ключи для каждого
пита сущностей, и если ключей окажется несколько, выбирается среди них
первичный ключ. При выборе первичного ключа среди потенциальных следует
руководствоваться следующими правилами:
1) выбирать потенциальный ключ с минимальным набором атрибутов;
4
http://database.ucoz.com/index/09
19
2) использовать тот потенциальный ключ, вероятность изменения
значения минимально;
3) выбирать тот потенциальный ключ, который имеет минимальную
вероятность потери уникальности в будущем;
4) использовать тот потенциальный ключ, значение которого имеет
минимальную длину (в случае текстовых атрибутов);
5) выбирать потенциальный ключ, с которым проще работать с точки
зрения пользователя.
Логическое проектирование подразделяется на следующие этапы:
Построение и проверка локальной логической модели для отдельных
представлений каждого из пользователей.
1. Локальная концептуальная модель преобразуется в локальную
логическую;
2. Исходя из структуры локальной логической модели определяются
наборы отношений;
3. Проверка модели с помощью правил нормализации;
4. Проверка модели в отношении транзакции пользователя;
5. Создание уточненной диаграммы “сущность – связь”;
6. Определение требований поддержки целостности данных;
7. Обсуждение разработанной локальной логической модели с конечным
пользователем.
Для того чтобы преобразовать концептуальную модель в логическую,
необходимо:
1) удалить сложные и рекурсивные связи;
Сложная связь – это связь, которая устанавливается между 3мя и более
сущностями. При преобразовании в логическую модель такая связь должна быть
разбита на нужное количество бинарных связей. При разбиении требуется
введение дополнительных сущностей.
Рекурсивные связи – это связи, в которых сущности взаимодействуют сами
с собой. Такие связи устраняются введением промежуточных сущностей.
20
2) удалить множественные атрибуты;
Множественными называются атрибуты, которые могут одновременно
иметь несколько значений для одного и того же экземпляра сущности.
Избавиться от множественных атрибутов можно путем объединения новых
сущностей. Пример – телефонная сеть.
3) перепроверить связи;
В процессе определения сущностей могут быть созданы две сущности,
которые представляют один и тот же объект. Если эти сущности имеют разные
первичные ключи, то первый указывается как первичный, а второй ключ – как
альтернативный, и эти сущности объединяются в одну сущность.
4) удалить избыточные связи.
Избыточная это связь, если одна и та же информация может быть получена
не только с помощью этой связи, но и с помощью другой связи.
После того, как получена структура локальной логической модели,
необходимо определить набор отношений. Для этого для каждой сильной
сущности создается отношение. Если имеются составные атрибуты, то в
отношении составляется только составляющие и их простые атрибуты. Для
каждой слабой сущности тоже создается отношение. Дополнительно в это
отношение добавляется атрибут внешнего ключа. Этот атрибут должен
соответствовать первичному ключу сущности владельца.
Проверка модели с помощью правил нормализации состоит из следующих
действий:
1) из отношений удаляются повторяющиеся группы атрибутов;
2) устраняется частичная зависимость атрибутов от первичных ключей;
3) устраняется транзитивная зависимость от первичных ключей.
Необходимо проверить модель в отношении транзакции пользователя.
Фактически на этом этапе необходимо выяснить, возможно ли выполнение всех
требуемых действий над данными. Проще всего это делать с помощью ER
диаграмм, на которой стрелками отмечаются пути и сущности, которые должны
быть задействованы для выполнения той или иной транзакции. Поэтому
21
рекомендуется этот этап совместить с этапом создания уточненной ERмодели,
в которой учитываются все изменения, проделанные в этих шагах.
Последний шаг логического проектирования БД является определение
требований поддержки целостности данных. Различают 5 типов целостности
данных:
1. Обязательные данные (необходимо отметить данные, которые являются
справочными и без наличия этих данных невозможна дальнейшая работа);
2. Ограничение для доменов атрибутов (указывается область определения
атрибутов, если такая необходима);
3. Целостность сущностей (значение первичного ключа не должно иметь
NULLзначения);
4. Ссылочная целостность (для каждого внешнего ключа должно быть
соответствующее значение первичного ключа);
5. Требования данного пользователя (могут включать конкретные
ограничения для значения атрибутов).
Создание и проверка глобальной логической модели данных.
1) слияние локальных и логических моделей в единую модель;
2) проверка глобальной логической модели;
3) проверка возможности расширения проблемы в будущем;
4) создание окончательного варианта диаграммы "сущность – связь”;
5) обсуждение глобальной логической модели с конечным пользователем.
Целью физического проектирования является создание описания СУБД—
ориентированной модели БД. На данном этапе решается вопрос, каким способом
реализовать физическую модель БД. Необходимо учитывать, в какой СУБД
будет реализован проект. Между физическим и логическим проектированием
существует обратная связь, так как иногда приходится с целью повышения
эффективности, менять структуру БД.
Фаза физического проектирования БД включает в себя следующие этапы: