Рас, 7.5. Обозначение стороны связи нуль, один или многие

Рис. 7.6. Обозначение стороны связи один или многие

Рис. 7.7. Обозначение стороны связи нуль или один

Рис. 7.8. Обозначение стороны связи один

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

С другой стороны, на рис. 7.7 снова разрешено создание связи, минимальное значение кардинальности которой на этом конце равно нулю, но на этот раз максимальное значение кардинальности составляет единицу. Это - сторона связи нуль или один .

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

Безусловно, довольно трудно представить себе, как происходит создание связей, изучая лишь отдельно взятые признаки конца, поэтому рассмотрим в качестве примера диаграмму, на которой показано несколько таблиц и одна связь (рис. 7.9).

Orders

OrderHasDetails

OrderDate DATE CustomerNo INT

OrderDetails

Lineltem TEXT(50) OrderlD INT (FK)

PartNo TEXT(5) Qty INT

UnitPrice CURRENCY

Puc. 7.9. Пример диаграммы с таблицами и связью

Следует пояснить, что на рис. 7.9 показана ER-диаграмма, на которой приведены две таблицы, реализующие понятие всего лишь одной логической сущности- заказа. В таблице Orders отслеживается информация, общая по отношению ко всему заказу (в данном случае таковой является информация только о номере заказчика CustomerNo,

Orders

Products

OrderHasDetails

OrderDetallContalnsParts

OrderDetails

Linettem TEXT(50) OrderlD INT (FK)

Qty INT

UhitPrice CURRENCY RartNoie(T(5)(FK)(IE)

PiLC. 7.10. Пример диагрсщмы с тремя т/лблицами и двумя связями

От таблицы Products к таблице OrderDetails проходит новая связь, которая весьма напоминает связь, введенную ранее. Новая связь OrderDetailCon-tainsParts также представляет собой связь один (но на этот раз на данной стороне находится таблица Products) к нулю, одному или многим (на этой стороне снова находится таблица OrderDetails), но в отличие от связи OrderHasDetails является неидентифицирующей (на что указывает штриховая линия). На рис. 7.10 обозначение IE указывает, что для данной таблицы столбец PartNo представляет собой инверсную запись (Inversion Entry), или индекс, который не связан больше ни с чем, кроме внешнего ключа. В данном случае инверсная запись была добавлена потому, что обычно целесообразно иметь индекс на столбце, на котором задан внешний ключ (поскольку этот столбец часто становится адресатом поисковых операций).

Рассматривая все три таблицы вместе, можно прийти к выводу, что между таблицами Orders и Products установлена связь многие ко многим в силу того, что они связаны друг с другом через таблицу OrderDetails.

Выше уже было сказано, что данный пример может позволить получить лишь самое общее представление о том, какой объем самой разнообразной информации может быть передан с помощью ER-диаграмм. Тем не менее, как будет показано ниже, в разделе с описанием инструментальных средств формирования ER-диаграмм СУБД SQL Server, предусмотрены еще более удобные методологии, позволяющие представить в схематическом виде гораздо более подробную информацию по сравнению со встроенными инструментальными средствами. Наконец, преимуществом ER-диаграмм

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

На рис. 7.10 показано, что дополнительно к двум указанным таблицам введена таблица Products.

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

Сравнение логического и физического проектирования

При проектировании базы данных очень сложно обойтись без применения логических и физических моделей. В настоящем разделе приведено краткое описание этапов логического и физического проектирования и показаны различия мелсд) ними.

По-видимому, наиболее простой является концепция физической модели. По существу, до сих пор в этой книге мы в основном работали с физическими моделями, не упоминая этого явно. Вообще говоря, как относящиеся к физической модели могут рассматриваться любые объекты базы данных, создаваемые с помощью оператора CREATE. Однако любой объект СУБД SQL Server, применительно к котором) выполняются какие-либо операторы, не может не входить в состав физической модели.

С др)той стороны, логическая модель - это высокоуровневое представление данных в базе данньЕС, на основе которого, в частности, создается физичесхсая модель. Таким образом, работа над созданием и усовершенствованием логической модели становится предпосылкой успешного формирования операторов DDL (Data Definition Language - язык определения данных, в состав которого входят такие операторы, как CREATE, ALTER и DROP), необходимых для практической реализации физической модели.

Назначение логической модели

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

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

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

Создать представление данных в наиболее абстрактной форме (без учета тех дополнительных объектов управления данными, без которых невозможна нормальная эксплуатация базы данных).

Подготовить основную часть документации проекта, содержаш;)то описание требований к данным.

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