ЧАСТЬ 1 Теории нных баз данных

Но подобная связь межд стямп Office (Кабинет) и Employee (Сотрудник) будет правильной лишь до определенного момента времени. Очевидно, что рано или поздно в одном кабинете соберется несколько сотрудников. (Расположение кабинетов в здании также может измениться, но мы сейчас не берем это во внимание). Используя связь один к одному , как показано на рис. 3-6, вы получите простую модель служебных помещений, имеющихся в. здании, однако проследить истории щен.ия сотрудников из одного кабинета в другой в рамках этой модели не сможете. Возможно, подобная проблема вас просто не волнует. Например, если вы разрабатываете систему для рассылки все. что необходимо знать -куда направлять корреспонденцию, адресованную Джей (Jane Doe), а информация о том, куда направлялась эта корреспонденция три месяца тому назад, для вас совершенно бесполезна. Но если вы проектируете систему для агентства, работающего с недвижимостью, информация о том, кто и когда занимал данное помещение, окажется очень нужной для составления различных отчетов - надо же знать, насколько часто сменяются арендаторы помещения.

Хот мэи один к одному в реальном мире встречаются довольно редко, ров;1нии баз данных они широко используются, например, чтобы уменьшить число атрибутов в отношении, а также при моделировании подклассов сущностей. Существует ограничение числа полей в таблице: для механизма СУБД Microsoft Jet оно не должно превышать 255, а для SQL Server - 250. Обычно модели данных не выходят за рамки этих ограничений, поскольку таблицы с таким огромным числом полей встречаются крайне редко. Однако мне приходилось сталкиваться с системами (они были предназначены для медицинских и научных учреждений), где у одной имелось

более 255 уникальных гпибугсч. И у разработчиков не было иного выбора, как создать новое отношение с некоторым произвольным подмножеством оу i )rj и определить связи один к одному между этим и исходным отношением.

Другая область, где модель данных часто содержит сущность с чересчур большим числом атрибутов - это составление моделей iccroB и опросных листов. Например, если нужно разработать тест с произвольным числом вопросов, велико искушение смоделировать ответы каждого тестируемого (рис. 3-7).

Такую структуру проще всег изовать; однако она далека от идеала. Атрибуты сущности Answer (Ответ) представляют собой повторяющуюся группу, и поэтому нельзя считать, что отношение находится в первой нормальной форме. Модель на рис. 3-8 намного удачней.

Test

Student Name DateTaken Answer 1 Answet2 AnswerN

Puc. 3- 7 pa, используемая для создания моделей тестов и опросных листов, далеко не идеальна

Categories

CategorylD CategoryName Description. Picture

Products

PfoduclID PtodiictName SupplieilD CategorylD Quantity Peru nit

Гис. 3-8. Эта структура, хот жней с точки зрения реализации, лучш одит для моделирования тестов и опросных листов

Реализация сущностей как классов-наследни ков

Более интересный случай применения отношений один к одному - классы-наследники дл гостей. Эта концепция заимствована из объектно-ориентированного программирования. Чтобы наглядней представить себе преимущества классов-наследников, сначала рассмотрим наиболее простой BecrubFii пример их применения. В базе данных wind, которая входит в комплект поставки Microsoft Access, каждый продукт связан с категорией продукта (рис. 3-9).

Categories

CatogorylD CategoryName Description Picture

Products.

Prod net ID

ProductNaine

SiippHerlD

CategorylD

QiiantltyPerUnit

Рис. 3-9. В базе данных Northwind каждый продукт связан с категорией продукта

Наличие связи с отношением Categories позволяет сгруппировать продукты, например, для получения отчетов. Однако при реализации системы, представленной на рис. 3-9, вы можете иметь дело только с

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

Возможно, у вас появится искушение смоделировать список продуктов из базы данных wind, как показано на рис. 3-10. Такая модель позволяет хранить всю информацию ичную для отдельных видов продуктов, при этом каждый тип продукта представляет собой отдельное отношение. Но при этом затруднительно работать с продуктом как таковым, поскольку приходится иметь дело со множеством различные вдов продуктов.

Prix) nets

Beverages

Condiments

Dairy Products

Meat/Poultry

Confections

Seafood

Grains/ Cereas

Produce

Рис. 3-Ю. Данная модель позволяем зить все атрибуты, свойственные етной категории

Представьте себе, например, процесс проверки, правильно ли пользователь ввел код продукта. В данной модели он выражается следующим образом: если данный код присутствует в отношении или в отношении уш...>. Это ничуть не лучше, чем запрос к повторяющимся группам ных, о которых шла речь в главе 2. Кроме того, в процессе реализации могут возникнуть нарушения целостности данных, когда некоторые атрибуты применимы только к одной категории продуктов. Например г/вс/са,(;е(число бутылок или другой тары е упаковке) - атрибут, применимый к категории продуктов