Составление схемы базы данных 89

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

Диаграммы отношений объектов соответствуют одному из трех уровней абстракции: физическому, программному или концептуальному. Диаграмма физического уровня описывает аппаратные компоненты. Это взгляд на систему как на совокупность физических устройств. На программном уровне система анализируется с точки зрения одного или нескольких программных компонентов. Концептуальный уровень представляет собой взгляд на систему со стороны пользователя.

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

Продавец

Продать товар Рис. 7.1. Концептуальная диаграмма

Добавить заказчика

Каждый программный компонент имеет собственное представление о системе. СУБД MySQL рассматривает данные как информационные блоки файлов на диске. Приложения работают с данными как с записями, которые возвращаются в результате SQL-запросов.

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

Рис. 7.2. Диаграмма таблиц

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

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

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

Языки моделирования

Существует несколько стандартов моделирования информационных структур вообще и баз данных в частности. Среди них диаграммы Бейчмана, модель отношений объектов, стандарты IDEF1X и UML (Uniform Modeling Language - единый язык моделирования). Диаграммы Бейчмана были разработаны Чарльзом Бейчманом для описания сетевых баз данных, но некоторые их идеи применимы и для реляционных баз данных. Модель отношений объектов впервые б1ла описана Питером Ченом (Peter Chen) в 1976 г. под влияниемстатьи доктора Кодда, посвященной реляционной алгебре. Стандарт IDEF1X б1л принят правительством США в 1993 г. UML- это популярный язык моделирования, созданный Гради Бучем (Grady Booch), Айваром Якобсоном (Ivar Jacobson) и Джимом Рамбо (Jim Rumbaugh) из компании Rational Software Corporation.

Люди часто говорят база данных , имея в виду система управления реляционными базами данных . Это объясняется двумя причинами: удобством и тем, что реляционная модель намного превосходит по популярности все остальные модели. Точно так же диаграммами отношений объектов стали называть любые диаграммы, в которых информационные сущности изображаются в виде замкнутых фигур, а отношения между ними обозначаются линиями. Строгое определение таких диаграмм было дано в исходной работе Чена под названием Модель отношений объектов: попытка унифицированного представления данных ( The Entity-Relationship Model: Toward a Unified View of Data ).

Дополнительную информацию о стандарте IDEF1X можно получить на Web-узле www.idef.com. Там выложен 145-страничный документ, содержащий описание методик составления диаграмм.

Компания Rational Software ведет Web-узел, посвященный языку UML (www.rational. com/umt). Стандарт UML основан на методологии объектно-ориентированного проектирования, позволяющей создавать многократно используемые программные компоненты. Концепции многих моделей хорошо выражаются диаграммами UML. Правда, считается, что традиционные диаграммы лучше подходят для описания информационных систем, в частности баз данных.

Составление схемы базы данных 91

Диаграммы отношений объектов

Диаграммы отношений объектов отображают три основных типа информации: объекте! (сущности), отношения и характер этих отношений. Объекты представляются прямоугольниками. Внутри прямоугольника находится имя объекта. Объект - это общее понятие, но при моделировании реляционных баз данных оно означает таблицу. На рис. 7.3 представлено типичное изображение объекта.

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

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

Клиент

Рис. 7.3. Объект

Рис. 7.4. Отношение один к одному

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

Рис. 7.5. Отношение один ко многим

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

Рис. 7.6. Необязательное отношение один к одному