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

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

Связи

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

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

Связи, поддерживаемые между объектами в базе данных (в основном строками), подра.зделяются на три основных типа.

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

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

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

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

Каждый из этих типов связей имеет определенные разновидности, определяемые тем, может ли одна из сторон связи быть п}стой или нет. Например, иногда возникает необходимость ввести в действие вместо связи один к одному связь нуль или один к одному .

Схематическое изображение

Разработка качественного проекта базы данньгх без использования такого важного средства, как диаграммы сущность-связь (Entity Relationship Diagrams- ERD, или ER-диаграммы), почти не осуществима. Безусловно, небольшие базы данных обычно удается легко создать с помощью нескольких сценариев и непосредственно их реализовать, вообще не применяя какР1х-либо схем. Но чем больше становится база данньгх, тем сложнее удерживать все, что к ней относится, в своей памяти. ER-диаграммы позволяют устранять многочисленные проблемы, поскольку с их помопщю можно быстро представить визуально и уточнить все нюансы, касающиеся применяемых сущностей и их связей.

При подготовке настоящей книги автор решил принять на вооружение подход, противоположный тому, который использовался им в предыдущих книгах. Дело в том, что в прежних изданиях рассматривалось очень простое инструментальное средство построения диаграмм, входящее в комплект программных средств SQL Server, которое может служить в качестве отправной точки при формировании простейших ЕК-дилграмм. Но, к сожааению, в этой программе используется собственная методология формирования ER-диаграмм компании Microsoft, которая не соответствует ни одному известному автору стандарту разработки ER-диаграмм. Кроме того, эта программа не позволяет использовать логическое моделирование, которое, по мнению автора, представляет собой довольно важный подход. Поэтому в настоящей главе в первую очередь рассматриваются стандартные методологии формирования ER-диаграмм и только после этого затрагивается тема, касающаяся встроенных инструментальных средств SQL Server и их использования.

Практика показывает, что основная часть инструментальных средств создания ER-диаграмм поддерживает две наиболее распространенные методологии - IE и IDEF1X. Обе эти методологии широко используются, но в настоящей главе будет достаточно подробно описана лишь методология IE (Information Engineering - информационная инженерия). Следует отметить, что IDEF1X- чрезвычайно удобный подход к созданию ER-диаграмм, который впервые нашел свое применение в ВВС США. Но сам автор использует методологию IE (следует еще раз подчеркнуть, что эта аббревиатура в данном контексте обозначает информационную инженерию, а не Internet Explorer) лишь по одной причине - ER-диаграммы, составленные с ее помощью, являются гораздо более удобными для чтения теми лицами, которые не имеют большого опыта в проектировании. Кроме того, по мнению автора, методология IE - намного более обобщенная из двух )тсазанных.

Но полноценные инструментальные средства создания ER-диаграмм нельзя назвать дешевыми, поскольку их стоимость находится в пределах от 1 до 3,5 тыс. долл. (в расчете на одно рабочее место!). Кроме того, каждое из этих инструментальных средств поддерживает собственный язык разработки ER-диаграмм. Причем любое, даже самое совершенное инструментальное средство подготовки ER-диаграмм не способно справиться со своим заданием без помощи разработчика, поэтому необходимо заранее определить, какой цели вы хотите достичь с его помощью, и предпринять для этого требуемые шаги.

К тому же, каким бы дорогостоящим не было используемое инструментальное средство, прежде чем приступать к работе с ним, необходимо создать логическую модель. Одним из широко используемьгх инструментальных средств является программа Visio (которая к тому же относится к категории недорогих программных продуктов). Безусловно, эта программа не позволяет беспрепятственно решать абсолютно все задачи проектирования баз данных, но вполне способна помочь при выполнении основных работ логического моделирования. Несмотря на сказанное, если проект, для которого должна быть создана база данных, является достаточно серьезным и предназначен для использования в качестве основы важной разработки, то настоятельно рекомендуется обеспечить возможность приобретения действительно полноценного инструментального средства создания ER-диаграмм.

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

Создание логических моделей, а также прямой и обратный переход от логической модели к физической.

Работа над ER-диаграммой в автономном режиме с последующим единоразо-вым распространением всех внесенных изменений на физическую базу данных (которое происходит по завершении всех необходимых действий в составе плановых операций, связанных с сопровождением базы данных).

Раскрытие структуры базы данных, связанное с переходом от одной из ведущих реляционных СУБД (или даже от баз данных ISAM некоторых типов) к другой СУБД, с последующим созданием определений для СУБД совершенно иного типа.

Создание физической модели, основанной на использовании многочисленных и разнообразных систем.

На этом возможности указанных инструментальных средств далеко не исчерпываются.