Классика баз данных - статьи

       

Реляционное представление данных


Термин отношение используется здесь в его общепринятом математическом смысле. Для заданных множеств S1, S2, ..., Sn (не обязательно различных) R является отношением на этих n множествах, если представляет собой множество кортежей степени n, у каждого из которых первый элемент взят из множества S1, второй – из множества S2 и т.д.

Мы будем называть Sj j-тым доменом R. Говорят, что такое отношение R имеет степень n. Отношения степени 1 часто называют унарными, степени 2 – бинарными, степени 3 – тернарными и степени n – n-арными.

Для наглядности мы будем часто использовать представление отношений в виде массивов, но нужно помнить, что это конкретное представление не является существенной частью излагаемого реляционного представления. Массив, представляющий n-арное отношение R, обладает следующими свойствами:

  1. Каждая строка представляет кортеж степени n.

  2. Порядок строк не является существенным.

  3. Все строки различны.

  4. Порядок столбцов является существенным – он соответствует порядку S1, S2,..., Sn

    доменов, на которых определяется R (однако обратите внимание на приводимые ниже замечания по поводу отношений с упорядоченными и неупорядоченными доменами).

  5. Значимость каждого столбца частично выражается посредством его пометки именем соответствующего домена.

В примере на рис.1 показано отношение степени 4 поставка. В этом отношении отражаются выполняемые поставки деталей от указанных поставщиков для указанных проектов в указанных количествах.



поставка (поставщик деталь проект количество)
1 2 5 17
1 3 5 23
2 3 7 9
2 7 5 4
4 1 1 12

Рисунок 1. Отношение степени 4

Можно спросить: если столбцы помечены именами соответствующих доменов, зачем нужна упорядоченность столбцов? Как показывает рис.2, для двух столбцов могут иметься одинаковые заголовки (означающие одинаковые домены), но смысл этих столбцов может быть различным. Показанное отношение называется компонент.
В этом тернарном отношении два первых домена называются деталь, а третий – количество. Смысл отношения компонент (x, y, z) состоит в том, что деталь x является непосредственным компонентом (или составной частью) детали y, и для сборки одного экземпляра детали y требуется z экземпляров детали x. Это отношение играет критическую роль в проблеме разборки деталей.

компонент (деталь деталь количество)
1 5 9
2 5 7
3 5 2
2 6 12
3 6 3
4 7 1
6 7 1
Рисунок 2.Отношение с двумя одинаковыми доменами

Примечательным фактом является то, что некоторые современные системы (главным образом, те, которые основываются на файлах с древовидной структурой) не в состоянии обеспечить представление данных для отношений, которые имеют два или более одинаковых домена. Примером такой системы является текущая версия IMS/360 [5].

Ко всем данным, находящимся в банке данных, можно относиться как к коллекции изменяющихся во времени отношений. Эти отношения обладают разными степенями. Во время существования каждого n-арного отношения в него могут вставляться дополнительные кортежи степени n, удаляться существующие кортежи и изменяться компоненты существующих в нем кортежей.

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

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

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



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

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

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

Рассмотрим пример банка данных, включающего отношения, которые содержат информацию о деталях, проектах и поставщиках. Одно отношение, называемое деталь, определено на следующих (и, возможно, на некоторых других) доменах:
  1. номер детали;

  2. наименование детали;

  3. цвет детали;

  4. вес детали;

  5. количество имеющихся деталей;

  6. количество заказанных деталей.


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


Мы будем называть множество хранимых в некоторый момент времени значений активным доменом в этот момент времени.

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

Общее требование для элементов отношения – обеспечение взаимосвязи с другими элементами данного отношения или с элементами другого отношения. Ключи обеспечивают средства пользовательского уровня (но не только эти средства), для выражения таких взаимосвязей. Мы будем называть домен (или комбинацию доменов) отношения R внешним ключом, если он не является Первичным Ключом R, но его элементы – это значения Первичного Ключа некоторого отношения S (возможность идентичности R и S не исключается). В отношении поставка, приведенном на рис.1, комбинация поставщик, деталь, проект

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

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


В пользовательской реляционной модели отсутствуют преимущества от проведения такого разделения (тем не менее, такие преимущества могут существовать при применении реляционных концепций к машинному представлению пользовательского набора связей).

Таким образом, мы обсудили примеры отношений, определенных над простыми доменами – доменами, элементы которых являются атомарными (не поддающимися декомпозиции) значениями. В рамках реляционного подхода могут обсуждаться и неатомарные значения. Мы имеем в виду то, что некоторые домены могут в качестве элементов содержать отношения. Эти отношения могут, в свою очередь, быть определены на непростых доменах и т.д. Например, одним из доменов, на которых определено отношение служащий, мог бы быть домен история зарплаты. Элемент домена история зарплаты – бинарное отношение, определенное на домене дата и домене зарплата. Домен история зарплаты

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

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


Содержание раздела