Проектирование схем реляционной БД. Часть1

1.      Основные положения

2.       Избыточность данных и аномалии обновления

3.       Функциональная зависимость

1. Основные положения

Для  определения оптимальная структура кортежа, определения числа отношений и связей между отношениями. В реляционной  БД существуют отношения: 1:1 и 1:N.

Если возникает ситуация M:N, необходимо такие отношения разбивать на 2 отношения, путем введения нового отношения, который называется отношением связи. При проектировании схем реляционной БД можно использовать следующие подходы:

- проектирование сверху вниз;

- проектирование снизу вверх.

При первом подходе вначале определяется общее число отношений, затем атрибутный состав и устанавливаются связи между отношениями.

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

С целью упрощения проектирования реляционной БД в 1976г. Была разработана модель «сущность связь» (ER-модель).Основу этой модели составляют типы сущностей, типы связей, атрибуты.

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

Физ. существование	Концеп. существования
Работник	Осмотр объекта недвижимости
Отделение	Продажа объекта недвижимости

Каждый идентифицируется  объектом и списком свойств. Сущности подразделяются на слабые и сильные. Слабый тип – тип сущности, существование которого зависит от какого-то другого типа сущности. Сильный тип – существование независимо от других сущностей.

Пример: Аренда и продажа объектов недвижимости

 

Сильные сущности (родительские, доменные)	Слабые сущности (дочерние)
Работник	Объект недвижимости
Отделение	Осмотр объекта недвижимости
Владелец

 

 Модель «сущность связи» представляется в виде диаграммы. На этой модели каждая сильная сущность представлена в в идее прямоугольника с двойным контуром.

Свойства сущности (атрибуты):

- простые;

- составные;

- однозначные;

- многозначные.

Простой – состоящий из одного компонента с независимым существованием.

Составной – состоящий из нескольких компонентов, каждый из которых характеризуется независимостью существования.

  Пример:

Однозначный атрибут – атрибут, который содержит несколько значений для одной сущности.

Производный атрибут – атрибут, который представлен значением производным от связного с ним атрибута.  Пример:  Возраст сотрудника -> Дата рождения.

 

Атрибут может быть:

 - ключевым – обозначается подчеркнутой чертой;

 - не ключевым.

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

Пример:

Отделение(NОТД, УЛИЦА, ГОРОД, ИНДЕКС, ТЕЛЕФОН, ФАКС)

Первичный ключ – NОТД.

Альтернативный ключ – ФАКС.

Многопользовательский атрибут – ТЕЛЕФОН.

Составной атрибут –

 Владелец – объект недвижимости.

 

Связь -   Количество участников связи – степень этой связи.

 

Между ВЛАДЕЦ объектом недвижимости можно выделить связь ВЛАДЕЕТ.

Основные ограничения на типы связи:

- кардинальность – 1:1, 1:N, M:N;

- степень участия.- количество возможных связей для каждой из сущностей (2).

Существует два варианта участия сущности в связи

- полная;

- частичная.

Степень участия считается полной, если для ее необходимо существование некоторых других сущностей.

Участия сущности «Сотрудник» в этой связи является частичным, поскольку некоторый работник может не относиться к конкретному отделению.

Участники связи с полным участием  - двойная линия.

Участники связи с частичным  участием  - одинарная линия.

При разработке концептуальной модели БД могут возникать проблемы с неправильной интерпретацией некоторых связей. Эти проблемы – ловушки соединения.

ловушки разветвления возникают в тех случаях, когда из одной сущности вытекает несколько связей 1:N.

Ловушки разрыва возникает при наличии связи с частичным участием. Например: отдел имеет, много сотрудников, которые имеются со сдаваемым в аренду объектом, но не все сотрудники занимаются именно этой работой. Кроме того, не все отделы находятся в введении этого отделения. В данном случае возникает проблема определения, какие объекты приписаны к тому или иному отделу. В таких случаях необходимо ввести дополнительную связь.

 

2. Избыточность данных и аномалии обновления

Основная цель проектирования заключается в определении атрибутов в отношении, чтобы минимизировать избыточность данных и т.о. сократить объем памяти, которая необходима для физического хранения отношения.

Сотрудник (Nсотр, ФИО, Адрес, Должность, З/П, Nотд)

Отдел (Nотд,  Адрес, Nтел)

Сотрудники отдела (Nсотр, ФИО, Адрес, Должность, З/П, Nотд, Адрес_отд, Nтел_отд)

В отношении «Сотрудники отдела» есть избыточность данных.

Поскольку сведения об отделе будет повторяться для каждого сотрудника отдела. В связи с этим в «Сотрудники отдела» существует следующее отношения обновления.

- При добавлении нового сотрудника отдела, необходимо указывать все сведения об этом отделе.

- При добавлении сведений о новом отделе, который еще не имеет сотрудников, придется присвоить значение NULL ключевому полю, что нарушает целостность данных.

При возникновении подобных аномалий рекомендуется отношение разбивать на две части. Для отношений «Сотрудники» и «Отдел» подобных аномалий уже не будет.

 

3. Функциональная зависимость

Функциональная зависимость описывает связь между отношениями: R(A,B) A->B.

Атрибут B функциональная зависимость от атрибута A, что означает, что каждое значение атрибута A связано только с одним значением атрибута B. При наличии функциональной зависимости атрибут или группа атрибутов, которые расположены слева от стрелки называются детерминантом.

Сотрудники_отделения:

Nсотр -> ФИО, Адрес, Должность, З/П, Nотд, Адрес_отд, Nтел_отд.

Nотд -> Адрес_отд, Nтел_отд.

Адрес_отд -> Nотд, Nтел_отд.

Nтел_отд -> Nотд, Адрес_отд.

Первичный ключ  - Nотд, поскольку все остальные атрибуты функционально зависят от Nотд.