Реляционная модель
4.1.1 Реляционное представление данных и неоднозначность семантики.
В реляционной модели отношение (relation) R – это математическое отношение, определенное на множествах X1, X2, ..., Xn:
R = {(x1,x2,...xn) | x1 ∈ X1, x2 ∈ X2, ..., xn ∈ Xn}
Множества X1, X2, ... , Xn называются доменами (domain), а (x1, x2, ..., xn) называется кортежем (tuple). На рис. 12 показано отношение EMPLOYEE. Доменами отношения являются EMPLOYEE-NO, FIRST-NAME, LAST-NAME, FIRST-NAME, LAST-NAME, NO-OF-YEAR. Порядок строк и столбцов в отношении не является существенным. Чтобы избежать неоднозначности столбцов отношения с одним и тем же доменом, имена доменов уточняются ролями (role) (для выделения роли домена в отношении). Например, в отношении EMPLOYEE, домены FIRST-NAME и LAST-NAME можно уточнить ролями LEGAL или ALTERNATIVE. Имя атрибута (attribute name) в реляционной модели – это имя домена и присоединенное к нему имя роли [10]. Сравнивая рис. 12 и 7, мы можем заметить, что домены почти эквивалентны множествам значений. Хотя может показаться, что роль и атрибут в реляционной модели служат той же цели, что и атрибут в модели сущность-связь, семантика этих терминов различается. Роль и атрибут в реляционной модели используются, главным образом, для того, чтобы различать домены с одним и тем же именем в одном и том же отношении, в то время как атрибут в модели сущность-связь – это функция, задающая отображение из множества сущностей (или связей) в множество(а) значений.
Рис. 12. Отношение EMPLOYEE
Рис. 13. Отношение EMPLOYEE-PROJECT
Использование реляционных операций в реляционной модели может вызывать семантические неоднозначности. Например, в результате соединения отношения EMPLOYEE с отношением EMPLOYEE-PROJECT (рис. 13) по домену EMPLOYEE-NO получается отношение EMPLOYEE-PROJECT' (рис. 14). Но какой смысл имеет соединение отношения EMPLOYEE с отношением SHIP по домену NO-OF-YEARS (рис. 15)? Проблема состоит в том, что одно и то же имя домена может иметь в разных отношениях разную семантику (заметим, что роль предназначена для различения доменов в данном отношении, а не во всех отношениях).
Если не допускается, чтобы значения домена NO-OF-YEAR отношения EMPLOYEE были сравнимыми со значениями домена NO-OF-YEAR отношения SHIP, должны объявляться разные имена доменов. Но если такие сравнения допустимы, сможет ли система баз данных предупредить пользователя?
Рис. 14. Отношение EMPLOYEE-PROJECT' как "соединение" отношений EMPLOYEE и EMPLOYEE-PROJECT
Рис. 15. Отношение SHIP
В модели сущность-связь семантика данных гораздо более очевидна. Например, один столбец в рассмотренном выше примере содержит значения AGE сущности EMPLOYEE, а другой столбец содержит AGE сущности SHIP. Если эта семантическая информация предоставлена пользователю, он может действовать более предусмотрительно (сошлемся на образцы запросов выборки информации из подраздела 3.4). Поскольку система баз данных содержит семантическую информацию, ей следует обладать возможностью предупреждать пользователя о потенциальных проблемах предложенной выше операции "типа соединения".
4.1.2 Семантика функциональных зависимостей между данными. В реляционной модели "атрибут" B отношения функционально зависит (functionally dependent) от "атрибута" A того же отношения, если каждому значению A соответствует не более, чем одно значение B. Семантика функциональных зависимостей между данными становится очевидной в модели сущность-связь. По существу, имеется два основных типа функциональных зависимостей:
- Функциональные зависимости, относящиеся к описанию сущностей или связей. Поскольку атрибут определяется как функция, он отображает сущность из множества сущностей в одно значение из множества значений (см. рис. 2). На уровне 2 для представления сущностей используются значения первичного ключа. Следовательно, неключевые множества значений (домены) функционально зависят от множества значений первичных ключей (например, на рис. 6 и 7 NO-OF-YEARS функционально зависит от EMPLOYEE-NO). Поскольку отношение может иметь несколько ключей, неключевые множества значений будут функционально зависить от любого ключевого множества значений.
Ключевые множества значений будут взаимно функционально зависеть друг от друга. Аналогично, в отношении связей неключевые множества значений будут функционально зависеть от множеств значений первичных ключей (например, на рис. 8 PERCENTAGE функционально зависит от EMPLOYEE-NO и PROJECT-NO). - Функциональные зависимости, относящиеся к сущностям в связи. Заметим, что на рис. 11 мы указываем для множеств связей типы отображений (1:n, m:n и т.д.). Например, PROJECT-MANAGER является отображением 1:n. Допустим, что PROJECT-NO – это первичный ключ в отношении сущностей PROJECT. В отношении связей PROJECT-MANAGER множество значений EMPLOYEE-NO будет функционально зависеть от множества значений PROJECT-NO (т.е. для каждого проекта имеется только один менеджер).
Проведение различия между уровнем 1 (рис. 2) и уровнем 2 (рис. 6 и 7) и разделение отношения сущностей (рис. 7) и отношения связей (рис. 8) вносит ясность в семантику функциональных зависимостей между данными.
4.1.3 3NF-отношения в сравнении с отношениями сущностей-связей.
Из определения отношения следует, что любое группирование доменов можно рассматривать как отношение. Чтобы избежать нежелательных свойств в поддерживаемых отношениях, предлагается процесс нормализации, в ходе которого произвольные отношения преобразуются в первую нормальную форму, затем во вторую нормальную форму и, наконец, в третью нормальную форму (3NF) [9,11]. Мы покажем, что отношения сущностей и связей в модели сущность-связь
похожи на 3NF-отношения, но обладают более ясной семантикой и не требуют выполнения операций преобразования.
Будем использовать упрощенную версию примера нормализации, описанного в [9]. Следующие три отношения находятся в первой нормальной форме (т.е. в них не используется домен, элементы которого сами являлись бы отношениями):
EMPLOYEE (EMPLOYEE-NO) PART (PART-NO, PART-DESCRIPTION, QUANTITY-ON-HAND) PART-PROJECT (PART-NO, PROJECT-NO, PROJECT-DESCRIPTION, PROJECT-MANAGER-NO, QUANTITY-COMMITED)
Заметим, что домен PROJECT-MANAGER-NO (НОМЕРА МЕНЕДЖЕРОВ ПРОЕКТОВ) содержит EMPLOYEE-NO (номер служащего) менеджера проекта.
В показанных выше отношениях первичные ключи подчеркнуты.
В соответствии с определенными правилами эти отношения преобразуются в третью нормальную форму:
EMPLOYEE' (EMPLOYEE-NO) PART' (PART-NO, PART-DESCRIPTION, QUANTITY-ON-HAND) PROJECT' (PROJECT-NO, PROJECT-DESCRIPTION, PROJECT-MANAGER-NO) PART-PROJECT' (PART-NO, PROJECT-NO, QUANTITY-COMMITED)
Используя диаграмму "сущность-связь" с рис. 11, можно легко вывести следующие отношения сущностей и связей:
сущность PART'' (PART-NO, PART-DESCRIPTION, QUANTITY-ONHAND) отношения PROJECT'' (PROJECT-NO, PROJECT-DESCRIPTION) EMPLOYEE''(EMPLOYEE-NO) связь PART-PROJECT''(PART/PART-NO, PROJECT/PROJECT-NO, QUANTITY-COMMITED) отношения PROJECT-MANAGER''(PROJECT/PROJECT-NO, MANAGER/EMPLOYEE-NO)
Указаны имена ролей сущностй в связях (такие как MANAGER). Имена отношений сущностей, ассоциированных с первичными ключами сущностей в связях, и имена множеств значений опущены.
Заметим, что в приведенном выше примере отношения сущностей-связей похожи на 3NF-отношения. При использовании подхода 3NF PROJECT-MANAGER-NO включается в отношение PROJECT', поскольку предполагается, что PROJECT-MANAGER-NO функционально зависет от PROJECT-NO. В модели сущность-связь
PROJECT-MANAGER-NO (т.е. EMPLOYEE-NO менеджера проекта) включается в отношение связи PROJECT-MANAGER, так как в этом случае EMPLOYEE-NO рассматривается как первичный ключ сущности.
Заметим также, что при использовании подхода 3NF изменения функциональных зависимостей данных могут приводить к тому, что некоторые отношения перестают находиться в 3NF. Например, если мы делаем новое предположение, что для одного проекта могут быть несколько менеджеров, отношение PROJECT' больше не будет 3NF-отношением, и его нужно будет разбить на два отношения – PROJECT'' и PROJECT-MANAGER''. При использовании модели сущность-связь
такие изменения не являются необходимыми. Следовательно, мы можем сказать, что используя модель сущность-связь мы можем привести данные к форме, аналогичной 3NF-отношениям, но с отчетливым семантическим смыслом.
Интересно отметить, что описанный выше подход декомпозиции (или преобразования) для нормализации отношений можно рассматривать как подход "снизу-вверх" в области проектировании баз данных. При использовании этого подхода все начинается с произвольных отношений (уровень 3 на рис. 1), а затем используется некоторая семантическая информация (функциональные зависимости данных) для преобразования этих отношений в 3NF-отношения (уровень 2 на рис. 1). В модели сущность-связь принят подход "сверху-вниз", в котором используется семантическая информацию для организации данных в отношения сущностей/связей.
