94. Проектирование структуры бд, нормализация отношений.

Классический подход к проектированию реляционных баз данных состоит из 3 этапов:

Инфологическое проектирование- построение информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД . Чаще всего концептуальная модель базы данных включает в себя:

- описание информационных объектов, или понятий предметной области и связей между ними ;

- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям м\у ними.

Логическое (даталогическое) проектирование- создание схемы базы данных на основе конкретной модели данных, например, реляционной. Для реляционной модели даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи. На этапе логического проектирования не учитываться специфика конкретной СУБД.

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных.

Наиболее распространенным средством моделирования данных является диаграмма “Сущность-связь”. С ее помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).

ER- диаграмма непосредственно используется для проектирования реляционной БД.

Основным понятием является сущность и связи, при этом под сущностью понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае каждый рассматриваемый объект является экземпляром сущности. Связь определяется как отношение между отдельными сущностями. Различают несколько типов связей:

1. Один ко многим – означает, что один экземпляр одной сущности взаимодействует с несколькими экземплярами другой сущности.

а) идентифицирующая связь «один ко многим» (независимая сущность с зависимой от нее). Обозначается сплошной линией с точкой на дочернем конце связи. При этом первичный ключ родительской записи входит составной частью в первичный ключ дочерней таблицы.

б) неидентифицирующая связь один ко многим (две взаимно независимые сущности, между экземплярами которых установлено соответствие). Обозначается пунктирной линией с точкой на дочернем конце связи и ромбом - на родительском. При этом первичный ключ родительской записи включается в качестве неключевых атрибутов дочерней.

2. Многие ко многим –экземпляры одной сущности взаимодействуют с экземплярами другой сущности.

Процесс построения логической модели:

1. Составить ER-диаграмму, определили сущности, атрибуты и проставили связи.

2. Определение ключевых атрибутов и типов атрибутов;

3. Нормализация БД. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении БД к ЗНФ.

Первая нормальная форма (1НФ): требует, чтобы каж­дое поле таблицы БД было неделимым и не содержало повто­ряющихся групп столбцов. Неделимость - значение поля не должно делиться на более мелкие значения. Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

Вторая нормальная форма (2НФ): требует, чтобы все поля (столбцы) таблицы зависели от первичного ключа, т.е. чтобы пер­вичный ключ однозначно определял запись и не был избыто­чен.

Третья нормальная форма (ЗНФ): требует, отсутствие транзитивных зависимостей между неключе­выми атрибутами, т.е. чтобы значения полей таблицы, не входя­щих в первичный ключ не зависели друг от друга.(Специальность, Специализация)

После построения логической модели можно подходить к построению физической.

Перед построением физической модели необходимо выбрать сервер, после чего можно автоматически получить физическую модель, корректируя типы и размеры полей. Кроме того на этапе создания физической модели вводятся правила , определяющие списки допустимых значений и значений по умолчанию.

Недостатком нормализованной БД является необхо­димость считывать из таблиц связанные данные при выполне­нии запросов к нескольким таблицам БД. На практике ненор­мализованные данные (хранящиеся в одной таблице), отыски­ваются быстрее по сравнению со случаем поиска данных в од­ной или более связанных таблицах. Подобное ускорение тем заметнее, чем большее число записей в связанных таблицах. Поэтому при работе с большими объемами данных при­ходится искать компромисс между требованиями нормализа­ции и необходимостью достигнуть максимального быстродей­ствия системы. Для окончательного выбора структуры БД, оптимально отвечающей потребностям конкретной ИС, необходимо по­строить критерий эффективности логической структуры и провести анализ предложенных вариантов в соответствии с этим критерием.