Теория и практика построения баз данных (1088289), страница 50
Текст из файла (страница 50)
Итак, дерево, или иерархия — это совокупность записей, организованная таким образом, что все связи в ней имеют вид 1 1». Все записи имеют ровно одного родителя, кроме корня, который родителей пе имеет, Иерархия может быть представлена в ниде набора отношений с помощью описанных ранее методов.
Иерархии распространены в бизнесе, особенно в производственных приложениях. Рис. В.24. Представление дерева с помощью отношений: е — дерево сущностей; б — представление дерева сушиостей в виде отношений Деревья, сети и списки материалов 231 Простая сеть (ебп«р1е пег«уогк) также представляет собой структуру данных, имеющую связи «один ко многим». Однако в простой сети элементы могут иметь более одного родителя, если родители принадлежат к различным типам.
Например, в простой сети, представленной на рис. 6.25, каждая сущность СТУДЕНТ имеет два родителя: сущности РУКОВОДИТЕЛЬ и СПЕЦИАЛЬНОСТЬ. Структура данных, изображенная на рис. 6.25, не является деревом, поскольку сущности класса СТУДЕНТ имеют более одного родителя. На рис. 6.26, а показана общая структура этой простой сети. Обратите внимапп«, что все связи имеют вид «один ко многим», но сущность СТУДЕНТ имеет два родителя. На этом рисунке родительские записи помещены вверху, а дочерние ра«тюлагаются под ними. Такое расположение удобно, но не обязательно.
Вам могут нстретиться простые сети, где родители изображены рядом с потомками пли под ними. Распознать в этих структурах простые сети можно по тому при:пшку, что один тип записи фигурирует н качестве дочернего в двух (или более) связях «один ко многим». «1тобь«представить простую сеть сущностей с помощью реляционной модели, нужно следовать процедурам, описанным ранее. Сначала мы преобразуем каждую сущность в отношение и, при необходимости, нормализуем созданные отношения. Затем представляем каждую из связей 1:Х, помещая ключ родительского отношения в дочернее.
Результат этого процесса для сети, изображенной на рис. 6.26, а, показан на рис. 6.26, б. Сложная сеть (сошр1ех пет«уог)«) — это структура данных, среди связей которой имеется по меньшей мере одна связь «многие ко многим». Сложная сеть на рнс. 6.27, а иллюстрирует связи между счетами, строками заказа, товарами и поставщиками. Две из трех связей имеют вид 1:Ы, а третья — М )ч. Поскольку имеется как минимум одна связь «многие ко многим», эта структура называется сложной сетью.
Как отмечалось выше, связи М:Ы не имеют прямого прелставления в реляционной модели. Следовательно, прежде чем эту структуру можно будет представить в реляционной форме, л«ы должны ввести отношение пересечения, На рис. 6.27, б отношением пересечения является отношение ДЕТАЛЬ-ПОСТАВЩИК. Деревья, сети и списки материалов 233 может использоваться более чем в одном изделии, эта структура на самом деле представляет собой сеть. Например, деталь АВС100 имеет два предка: продукт А н продукт В. Рис. 6.28. Пример списка материалов Список материалов может быть представлен с помопгью отношений несколькими способами.
Наиболее распространенный из них — представление его в виде рекурсивной связи М:й!. Деталь (или изделие, или блок, или подблок и т. д.) содержит много элементов. В то же время, может быть много элементов, которые содержат данный элемент. На рис. 6.29, а показана общая структура рекурсивной связи М:!11, а на рис. 6.29, б изображен экземпляр отношения пересечения, созданного для представления данного списка материалов. ЭЛЕМЕНТ ВхсдитВСостав Содержит ПОСТАВЩИК СЧЕТ ДЕТАЛЬ Значение атрибута Содержит в отношении ЭЛЕМЕНТ-СВЯЗЬ догэкно существовать среди значений атрибута НомерЭлемента в отношении ЭЛЕМЕНТ Списки материалов а б Рис. 6.29.
Представление списка материалов с помощью отношений: а — отношения, представляющие список материалов; б — данные для отношения пересечения ЭЛЕМЕНТ-СВЯЗЬ 232 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» б Рис. 6.26. Представление простой сети с помощью отношений: а — простая сеть, сконструированная из сущностей; б — представление данной простой сети в виде отношений Рис. 6.27. Представление сложной сети с помощью отношений: з — сложная сеть, сконструированная из сущностей; б — представление этой сложной сети в виде отношений Список материалов (Ы!1 о! гпасег!а!з) — специальная структура данных, которая часто появляется в производственных приложсггиях.
Фактически, такие структуры дали главный импульс развитию технологии баз данных в начале 1960-х годов. На рнс. 6.28 представлен пример списка материалов, в котором показаны части, составляющие изделие. Если подходить с точки зрения конкретного продукта, эта структура данных является иерархией.
Но поскольку одна и та же деталь Ограничения ссылочной целостности: Значение атрибута ВходитВСостав в отношени и ЭЛЕМЕНТ-СВЯЗЬ должно существовать среди значений атрибута Номерэлемента в отношении ЭЛЕМЕНТ Обратите внимание, что элемент А содержит элемент АВС100, а элемент АВС100 входит в состав элемента А 234 Глава б. Проектирование баз данных в рамках модели «сущность — связь» Деревья, сети и списки материале,в 235 Прежде чем завершить эту главу, мы должны обсудить два важных вопроса: суррогатные ключи и пустые значения. Суррогатные ключи Суррогатный ключ (вштойасе )гсу) — это предоставляемый системой уникальный идентификатор, используемый в качестве перви шого ключа отношения. Значения суррогатного ключа не имеют смысла для пользователей, поэтому в формах и отчетах они обычно скрываются. СУБД не позволит изменить значение суррогатного ключа.
Есть две причины для использования суррогатных ключей: одна прагматическая, другая философская. Рассмотрим вначале прагматическую причину. Прагматическая причина Допустим, имеется связь М:Ы между следующими двумя таблицами: МОЛЛЮСК (НазваниеМоллюска, Размер, Цвет, Описание) ПЛЯЖ (НазваниеПляжа, Тип, НаправлениеВолны, СредняяТемператураВоды) Связь между этими таблицами имеет вид М:Ы, поскольку моллюсков можно найти на многих пляжах, н на одном и том же пляже можно найти много разных типов моллюсков.
Предположим, что названия моллюсков — это текстовые данные вроде Суггор/еига созгага, и моделируются онн физическим доменом ТЕХТ (50). Далее допустим, что названия пляжей также имеют текстовый формат, например Уидби-Айленд, Криссснт-Бич, Ист-Энд, и моделируются они физическим доменом ТЕХТ (75). Ясно, что индексы, которые необходимо будет создать из этих столбцов для обеспечения уникальности, будут довольно длинными. (Информацию о таком использовании индексов вы найдете в приложении А.) Более серьезная проблема, однако, касается таблицы пересечения, которая будет представлять связь М."э!.
В этой таблице будет два столбца (НазваниеМоллюска, НазваниеПляжа), домены которых определены как ТЕХТ (50) и ТЕХТ(75) соответственно. Данные и индексы этой таблицы пересечения будут непомерно объемными! Например, если база данных по моллюскам содержит 1000 видов, представителей которых можно найти в среднем на 100 пляжах, таблица пересечения будет содержать 100 000 строк, в каждой из которых будет по 125 символов.
Последней каплей будет то, что все эти данные дублирую~ НазваниеМоллюска в таблице МОЛЛЮСК и НазваниеПляжа в таблице ПЛЯЖ. Затраты на хранение и обработку зтпх индексов могут быть значительно снижены, если определить суррогатный ключ в таблицах МОЛЛЮСК и ПЛЯЖ. Для этого в таблицы МОЛЛЮСК и ПЛЯЖ нужно добавить новые столбцы: скажем, НомерМоллюска и НомерПляжа соответственно.
Эти столбцы СУБД определяет как тип Ац1оНцтЬег (или что-нибудь в этом роде, в зависимости от используемой СУБД). Когда столбец определяется таким образом, то всякий раз, когда СУБД создает новую строку, оца генерирует новое, уникальное значение для этого столбца новой строки. С использованием суррогатного ключа наши таблицы будут иметь следующий впд: МОЛЛЮСК (НомерМоллюска, НазваниеМоллюска, Размер, Цвет, Описание) ПЛЯЖ (НомерПляжа, НазваниеПляжа, Тип, НаправлениеВолны, СредняяТемператураВоды) МОЛЛЮСК-ПЛЯЖ (НомерМоллюска, НомерПляжа) Генерируемые значения суррогатных ключей представляют собой обычно 32-битные целые числа или ч го-нибудь подобное.
Такие значения компактны, их легко индексировать; введение суррогатных ключей приводит не только к значительному снижению занимаемого файлового пространства, но и к повышению быстродействия. Итак, по прагматическим причинам всегда, когда таблица имеет первичный ключ, являющийся длинным текстом, или композитный ключ, содержащий длинные текстовые элементы, стоит подумать об использовании суррогатных ключей. Философская причина Философская причина использования суррогатных ключей состоит в том, что опи служат для поддержания идентичности сущности. Когда пользователь записывает строку в таблицу, эта строка является представленпем чего-то. Это что-то должно существовать, пока пользователь не удалит его.