Теория и практика построения баз данных (1088289), страница 45
Текст из файла (страница 45)
Отвечая на эти вопросы, исходите из следуюших предположений: + Тип и версия горелки определяют емкость бака. + Горелка может ремонтироваться много раз, но не более одного раза в день. + На каждый произведенный ремонт выписывается отдельньш счет. + Горелка может быть зарегистрирована на различных пользователей, но не одновременно. + Горелка состоит из многих деталей, и каждая деталь может использоваться во многих горелках. Таким образом, фирма Р(гесП)р ведет записи о различных типах деталей (например. ютаиип форсунки), но не об отдельных деталях (клапан форсунки номер 41734, изготовленный 12 декабря 2001 г.). Ниже следует список отношений. ПРОДУКТ1 (Серийный Номер, Тип, Номе рВерсии, ЕикостьБака, Дата Изготовления, И нициалыИнспектора) ПРОДУКТ2 (СерийныйНомер, Тип, ЕмкостьБака, ДатаРемонта, НомерСчетаЗаРемонт, СтоимостьРемонта) РЕМОНТ1 (НомерСчетаЗаРемонт, ДатаРемонта, Стоимостьремонта, ИмяВыполнявшегоРемонт, ТелефонВыполнявшегоРемонт) РЕМОНТ2 (НомерСчетаЗаремонт, ДатаРемонта, СтоимостьРемонта, ИмяВыполнявшегоРемонт, ТелефонВыполнявшегоРемонт, СерийныйНомер, Тип, ЕмкостьБака) РЕМОНТЗ (Датаремонта, СтоимостьРемонта, СерийныйНомер, ДатаИзготовления) ГОРЕЛКА1 (СерийныйНомер, НомерСчетаЗаремонт, НомерДетали) ГОРЕЛКА2 (СерийныйНомер, НомерСчетаЗаРемонт, РегистрационныйНомерВладельца) Предположим, что нужно записывать владельца горелки, даже если она никогда не ремонтировалась.
Исходя из сделанных предположений, приведенных выше отношений и содержащихся в них атрибутов, а также из ваших знаний о малом бизнесе, постройте для фирмы Р(геб()р набор отношений в доменно-ключевой нормальной форме, Укажите первичные ключи и внешние ключи, а также сформулируйте ограничения целостности по внешнему ключу. Глава 6 Проектирование баз данных в рамках модели а сущность — связь| В главе 3 мы обсуждали модель «сущносгь — связь», а в главе 5 — реляционную модель и нормализацию. В настоящей главе мы свяжем этн два предмета и покажем, как требования пользователей, выраженные в терминах модели «сущность — связь», преобразуются в реляционные конструкции. Эти конструкции не зависят от конкретной СУБД.
Глава 6 состоит из трех разделов. В первом разделе мы изложим методики преобразования моделей «сущность — связь» в реляционные конструкции, Как вы увидите, важнуто роль в этом процессе играет нормализация. Второй раздел посвящен применению этих методик для преобразования четырех структур, часто возникающих в приложениях баз данных.
В заключительном разделе главы обсуждаются суррогатные ключи и пустые значения. Преобразование моделей «сущность — связь» в реляционные конструкции Согласно модели «сущность-связь», вещи, учет которых хотят вести пользовате- ли, представляются сущностями, а взаимоотношения между этими сущностями представляготся явно определенными связл.ии. В данном разделе описывается, как эти сущности и связи преобразуются в элементы реляционной модели.
Представление сущностей с помощью реляционной модели Представление сущностей средствами реляционной модели имеет прямолинейный характер. Начнем с того, что введем для каждой сущности свое отношение. Именем отношения будет имя сущности, а атрибутами отношения — атрибуты Преобразование моделей «сущность — связь» 207 сущности, Далее рассмотрим каждое из отношений в свете критериев нормализа- ции, описанных в главе 5.
При этом может (но не обязана) возникнуть необходи- мость в модификации первоначальной структуры. клиент(номвркпиввгд, имяклиентв, Адрес, ГоРод, штат, Индекс, ИмяДоверенногопицв, НомерТелефонв) б Рис. в.т. Представление сущности с помощью отношения: а — сущность КЛИЕНТ; б — отношение, представляющее сущность КЛИЕНТ На рис. 6.1, а изображена сущность КЛИЕНТ, взятая из рис. 3.1.
Она имеет следующие атрибуты: НомерКлиента, ИмяКлиента, Адрес, Город, Штат, Индекс и Телефон. Определим для этой сущности отношение, а атрибуты сущности сделаем его столбцами. Если из модели данных нам известно, какой атрибут идентифицирует сущность, то данный атрибут станет ключом отношения. В противном случае, чтобы определить, какой атрибут или набор атрибутов может идентифицировать сушностк мы должны спросить пользователей или как-то иначе проанализировать требования. Здесь мы предполагаем, что ключом является НомерКлиента. На этом рисунке, как н на следующих за ним, ключи отношения подчеркнуты. Роль нормализации На этапе формулировки требований единственное условие состояло в том, чтобы сущность была важна для пользователя, Не предпринималось никаких попыток определить, удовлетворяет ли сущность критериям нормализации, описанным в главе 5.
Теперь отношение, введенное для сущности, следует проанализировать в свете критериев нормализации. Рассмотрим, например, отношение КЛИЕНТ на рис. 6,1, б. Находится ли оно и доменно-ключевой нормальной форме (ДКНФ)? Чтобы это выяснить, нам необходимо знать, какие ограничения существуют относительно него. Без исчерпывающего описания требований мы не будем знать все ограничения (например, все ограничения доменов). Но некоторые требования мы можем определить, исходя только из имен атрибутов и наших знаний о природе бизнеса. Во-первых, НомерКлиента определяет все остальные атрибуты, поскольку уникальные значенгтя атрибутов ИмлКлиента, Адрес, Город, Штат, Индекс, ИмяДоверенногоЛица и Телефон могут быть определены по заданному значению атрибута 208 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» НомерКлиента.
Есть, однако, и другие ограничения, проистекающие из других функциональных зависимостей. Индекс определяет Город и Штат, а ИмяДоверенногоЛица определяет НомерТелефона. Чтобы создать набор отношений в ДКНФ, мы должны представить эти дополнительные функциональные зависимости как логические следствия доменов и ключей, и это мы можем сделать, введя три отношения, показанные на рис. 6.2. Заметьте, что клю юм отношения КЛИЕНТ является НомерКлиента, ключом отношения ТАБЛИЦА ИНДЕКСОВ является Индекс, а ключом отношения КОНТАКТ является ИмяДоверенногоЛица. Также обратите внимание на ограничения ссылочной целостности.
Отношения, изображенные на рис. 6.2, находятся в ДКНФ и будут лишены аномалий модификации. То есть, чтобы добавить новые индексы и новых доверенных лпц, нам гге придется добавлять нового клиента. Кроме того, при удалении последнего клиента с данным индексом мы не потеряем информацию о том, какие город и штат соответствуют этому значению индекса. Однако, как мы указали в конце главы 5, большинство профессионалов сочли бы этот дизайн выхолощенным: вынесение атрибутов Индекс, Город и Штат в отдельную таблицу затрудняет работу с конструкцией в целом.
Следовательно, более удачным решением было бы оставить атрибуты Индекс, Город и Штат в отношении КЛИЕНТ. КЛИЕНТ (НрмерКривнтд, Адрес, Индекс, ИмяДоверенногопицв) ТАБЛИЦА ИНДЕКСОВ (Индекс, Город, Штат) КОНТАКТ (ИмяДрвереннргрЛица, НоыерТелефона) Ограничения ссылачной целостности: Значение атрибута Индекс в отношении КЛИЕНТ должно существовать среди значений атрибута Индекс в отношении ТАБЛИЦА ИНДЕКСОВ Значение атрибута ИмяДоверенногопица в отношении КЛИЕНТ должно существовать среди значений атрибута ИыяДоверенногаЛицв в отношении КОНТАКТ Рис.
6.2. Представление сущности КЛИЕНТ с помощью отношений в домениа-ключевой нормальной форме Что можно сказать по поводу отношения КОНТАКТ? Если связь между донеренным лицом и компанией имеет вид 1;1, то вынесение контактной информации в отдельную таблицу мало что дает. В этом случае отношение па рис. 6.1, б приемлемо. Если же указанная связь не однозначна, то отношение КОНТАКТ следует представить как отдельнукг сущность, надлежащим образом связанную с сущностью КЛИЕНТ (эта связь может иметь вид Х:1 илп 1:)ч)), и соответственно модифицировать ЕВ-моделг» В других примерах ДКНФ является наиболее предпочтительной формой. Рассмотрим сущность КОМИССИОННЫЕ ПРОДАВЦА на рис.
6.3, а. Если мы попытаемся представить эту сущность в виде одного отношения, как показано на рпс. 6.3, б, результатом явится беспорядочное нагромождение атрибутов с многочисленными потенциальными аномалиями модификации. Данное отношение явно содержит более одной темы, а именно оно содержит тему служащих, тему продаж за определенный период и тему комиссионных, вы- Преобразование моделей «сущность — связь» 209 плачиваемых служащим.
Отношения в ДКНФ, представляющие эту сущность, изображены на рис. 6.3, е. Интуитивно ясно, что это решение является более удачным, чем то, которое показано на рис. 6.3, б; оно более прямолинейно и луч- ше подходит в данной ситуации. КОМИССИОННЫЕ (НомерПродавца. ИмяПродввца, Теле4юн, НрыерЧека, ДатаВыпискиЧекв, Период, СуммвПродаж, СуымвКамиссионных, БюджетнвяКатегария) Функциональные зависимости: Атрибут НоыерЧекв является ключом Атрибут НоыерПродавца определяет атрибуты ИмяПродввца, Телефон и БюджетнвяКвтегория Комбинация (НомерПродавца, Период) определяет атрибуты СуыывПродвж, СумывКомиссионных б ПРОЛАВЕц (НрмерПррдааца, ИмяПрадавцв, Телефон, БюджетнвяКатегория) ПРОДАЖИ (Нрмерпрррдвцр, Оярврд, СуммаПродвж, СуммаКоыиссионных) КОМИССИОННЫЙ ЧЕК (НрыерЧека, ДвтвВыпискиЧека, НомерПродавца, Период) Ограничения ссылочной целостности: Значение атрибута Номерпрадавца в отношении ПРОДАЖИ должно существовать среди значений атрибута НомерПродавца в отношении ПРОДАВЕЦ Сочетание (НомерПродавца, Период) в отношении КОМИССИОННЫЙ ЧЕК должно существовать среди значений сочетания (Номерпрадввца, Период) в отношении ПРОДАЖИ в Рис.
6.3. Нормализованная сущность: в — сущность КОМИССИОННЫЕ ПРОДАВЦА; б — представление сущности КОМИССИОННЫЕ ПРОДАВЦА в виде одного отношения; в — представление сущности КОМИССИОНЙЫЕ ПРОДАВЦА в виде отношений в доменно-ключевой нормальной форме Подводя итог нашего изложения на данный момент, можно сказать следующее: чтобы преобразовать сущность в реляционнуго конструкцию, сначала следует построить отношение, в качестве столбцов которого выступают атрибуты сущности. Затем это отношение нужно проанализировать в свете критериев нормализации. Во многих случаях реляционную структуру можно улучшить, разработав набор отношений, находягцпхся в ДКНФ.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
