Реляционная модель данных для больших совместно используемых банков данных

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

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

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

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

1. номер детали;
2. наименование детали;
3. цвет детали;
4. вес детали;
5. количество имеющихся деталей;
6. количество заказанных деталей.

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

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

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

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

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

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

      1.4. Нормальная форма 

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

      Рассмотрим, например, набор отношений, приведенный на рис.3(а). История работы и дети – непростые домены отношения служащий. История зарплаты – непростой домен отношения история работы. На дереве на рис.3(а) показаны именно эти взаимосвязи указанных непростых доменов.

      служащий (номер_служащего, имя, дата_рождения, история_работы, дети)  
история_работы (дата_приема_на_работу, название, история_зарплаты)  
история_зарплаты (дата_назначения_зарплаты,зарплата)  
дети (имя_ребенка, год_рождения)

      Рисунок 3(a). Ненормализованное множество 

      служащий' (номер_служащего, имя, дата_рождения)  
история_работы' (номер_служащего, дата_приема_на_работу, название)  
история_зарплаты' (номер_служащего, дата_приема_на_работу, дата_назначения_зарплаты, зарплата)  
дети' (номер_служащего, имя_ребенка, год_рождения)

      Рисунок 3(б). Нормализованное множество 

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

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

      Чтобы можно было применить описанную нормализации, ненормализованный набор отношений должен удовлетворять следующим условиям:

1. Граф взаимосвязей непростых доменов должен являться набором деревьев.
2. Ни один первичный ключ не должен включает в себя непростые домены.

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

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

1. Передаваемая форма не содержала бы указатели (со значениями – адресами или смещениями).
2. В ней отсутствовали бы все зависимости от схемы хэш-адресации.
3. Она не содержала бы какие-либо индексы или упорядоченные списки.

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

      R(g).r.d

      где R – имя отношения, g – необязательное имя поколения, r – необязательное имя роли, d – имя домена. Поскольку g необходимо только в случае существования или ожидаемого появления нескольких поколений данного отношения, а r необходимо только, если отношение R имеет два или более доменов с именем d, простая форма R.d часто будет достаточной.

      1.5. Некоторые лингвистические  аспекты 

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

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

      Универсальность подъязыка данных основана на его  декларативности (а не на возможностях вычислений). В больших банках данных каждое подмножество данных имеет очень большое количество возможных (и осмысленных) описаний, даже если мы предполагаем (как мы это и делаем), что существует только конечное множество функций, к которым система получает доступ для ограничения выбираемых данных. Следовательно, класс выражений ограничения, которые могут быть использованы для спецификации множества, должен иметь выразительную мощность класса правильно построенных формул прикладного исчисления предикатов. Хорошо известно, что для сохранения этой выразительной мощности не является обязательной возможность выражения (в соответствующем синтаксисе) каждой формулы выбранного исчисления предикатов. Например, достаточно ограничиться формулами, находящимися в предваренной нормальной форме [9].

      В выражениях ограничения или других частях оператора выборки могут потребоваться арифметические функции. Они могут быть определены в H и использованы в R.

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

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