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

  
Структура 4. Детали и Проекты наравне, Связь назначения деталей проектам подчинена Деталям 

  
Структура 5. Детали, Проекты и Связь  назначения деталей проектам наравне

      Теперь  рассмотрим задачу выборки номера детали, названия детали и количества деталей  этого типа для каждой детали, используемой в проекте с названием "альфа". Следующие наблюдения могут быть сделаны независимо от того, какая конкретная информационная система с древовидной организацией информации выбирается для решения этой задачи. Если для этого разрабатывается программа P, ориентированная на использование одной из приведенных выше структур (т.е. P не определяет, какова реальная структура представления данных), то при любом выборе P не сможет работать, по меньшей мере, с тремя потенциально возможными структурами. Более точно, если P следует структуре 5, то ей не удастся работать со всеми другими структурами; если PP следует структуре 3 или 4, то ей, по меньшей мере, не удастся работать со структурами 1,2 и 5; если P следует структуре 1 или 2, ей, как минимум , не удастся работать со структурами 3, 4 и 5. В каждом случае причина проста. Если отсутствуют проверки для определения реально заданной структуры, то работа P заканчится неудачей по причине попытки перехода по ссылке к несуществующему файлу (в доступных сегодня системах это трактуется как ошибка) или из-за отсутствия перехода по ссылке к файлу, содержащему нужную информацию. Читателю, который в этом сомневается, рекомендуется написать пробные программы для решения этой простой задачи.

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

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

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

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

      Термин  отношение используется здесь в его общепринятом математическом смысле. Для заданных множеств S₁, S₂, ..., S_n (не обязательно различных) R является отношением на этих n множествах, если представляет собой множество кортежей степени n, у каждого из которых первый элемент взят из множества S₁, второй – из множества S₂ и т.д.¹⁾ Мы будем называть S_j j-тым доменом R. Говорят, что такое отношение R имеет степень n. Отношения степени 1 часто называют унарными, степени 2 – бинарными, степени 3 – тернарными и степени n – n-арными.

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

1. Каждая строка представляет кортеж степени n.
2. Порядок строк не является существенным.
3. Все строки различны.
4. Порядок столбцов является существенным – он соответствует порядку S₁, S₂,..., S_n доменов, на которых определяется R (однако обратите внимание на приводимые ниже замечания по поводу отношений с упорядоченными и неупорядоченными доменами).
5. Значимость каждого столбца частично выражается посредством его пометки именем соответствующего домена.

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

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

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

      Рисунок 2.Отношение с двумя одинаковыми доменами

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

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

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