Создание базы данных

 

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

 

1) Для каждого простого  объекта и его единичных свойств  строится отношение, атрибутами  которого являются идентификаторы объекта и реквизиты, соответствующие каждому из единичных свойств.

2) Если у объекта  имеются множественные свойства, то каждому из них ставится в соответствие отдельное отношение. Ключом этого отношения будет идентификатор соответствующего объекта, а неключевым атрибутом — реквизит, отражающий данное свойство.

3) Если между объектом  и его свойством имеется условная  связь, то при отображении в  реляционную модель возможны  следующие варианты:

-   если многие  из объектов обладают рассматриваемым свойством,         то его можно хранить в базе данных так же, как и обычное свойство;

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

4) Наличие между объектами  связи типа 1 : 1 является довольно  редкой ситуацией в реальной  жизни. Если связь между объектами  1 : 1 и класс принадлежности обоих сущностей являются обязательными, то для отображения обоих объектов и связи между ними можно использовать один файл. Такое решение потребует меньше всего памяти для своей реализации. Однако таким решением не следует злоупотреблять. Может случиться, что для каждого из этих объектов в дальнейшем потребуется отразить какие-то свои связи или в запросах часто требуется информация отдельно по каждому из объектов, то это может усложнить работу.

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

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

Если связь 1 : 1 реализована на одном и том же множестве объектов, то можно использовать одно отношение.

5) Если между объектами предметной  области имеется связь 1 : М  и класс     принадлежности n-связной сущности является обязательным, то можно   использовать два  отношения, по одному для каждой сущности. В отношение, соответствующее n-связной сущности, при этом надо дополнительно добавить идентификатор связанного с ней объекта.

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

   6) Если между объектами  предметной области имеется связь  М: N, то для хранения такой информации  потребуются три отношения: по  одному для каждой сущности и одно для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов .

    7) Каждому агрегированному  объекту, имеющему место в предметной области, в даталогической реляционной модели будет соответствовать отдельный файл базы данных   (отношение). Атрибутами этого отношения будут идентификаторы всех объектов, «задействованных» в данном агрегированном объекте, а также реквизиты, соответствующие свойствам этого агрегированного объекта.  Объединить информацию о нескольких агрегированных объектах в одно реляционное отношение можно только в том    случае, если те объекты, с которыми связан каждый из них, полностью совпадают.

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

Во втором случае каждое отношение  будет включать в себя идентификатор объекта, те свойства, которые присущи объектам данной категории, а также свойства, которыми обладают родовые объекты, стоящие выше его по иерархии. Другими словами, для «видовых» объектов наблюдается наследование свойств «родовых» объектов.

Кроме этих двух «крайних» решений, возможны и комбинированные варианты. Выбор конкретного решения будет  зависеть от многих факторов, в том числе насколько часто информация о разных категориях объектов обрабатывается совместно, как велико, различие в «видовых» свойствах и некоторых других факторах.

9) Наличие связи «целое-часть»  также может быть отображено  в даталогической модели по-разному. Само это отношение может качественно различаться для разных ситуаций.

Рассмотрев поставленную передо мной задачу создания базы данных для проектной организации ООО «Сиберия», мною было принято решение по созданию следующих сущностей:

1. «Клиенты». Описывается атрибутами: Код клиента(ключевой) – связывается с Кодом клиента в сущности Название компании, Имя контакта, Фамилия контакта, Адрес выставления счета, Город, Область Край Республика, Почтовый индекс, Страна/регион, Должность получения, Номер телефона, Факс.
2. «Заказы». Описывается атрибутами: Код заказа (ключевой), Код клиента (получается, что у каждый заказ соотнесен с одним клиентом, но один клиент может сделать несколько), Код сотрудника (совершающего договор с клиентом)(договор с клиентом заключает один сотрудник, но каждый сотрудник может совершать договор с несколькими клиентами)(связан с полем Код сотрудника сущности Сотрудники), Название получателя, Дата размещения (дата заключения договора), Адрес получателя, Город получателя, Регион получателя, Индекс получателя, Страна получателя, Телефон получателя, Дата исполнения (дата выполнения заказа), Код метода доставки(связан с полем Код метода доставки сущности Доставка), Стоимость доставки, Налоговая ставка организации.
3. «Оплата». Описывается атрибутами: Код оплаты (ключевой), Код заказа, Сумма оплаты, Дата оплаты, Номер карточки, Имя владельца карточки, Срок действия карточки, Код метода оплаты(связывается с полем Код метода оплаты сущности Методы оплаты).
4. «Сведения о заказе». Описывается атрибутами: Код заказанного(ключевой), Код заказа (связан с полем Код заказа сущности Заказы), Код товара(связан с полем Код товара сущности Товары), Количество (товаров в заказе), Цена (заказа), Скидка (предоставляется постоянным клиентам.
5. «Сотрудники». Описывается атрибутами: Код сотрудника(ключевой), Имя, Фамилия, Должность, Внутренний (номер внутреннего телефона), Рабочий телефон.
6. «Методы оплаты». Описывается атрибутами: Код метода оплаты (ключевой), Метод оплаты, Карточка (номер карточки).
7. «Товары». Описывается атрибутами: Код товара(ключевой), Марка (полное название товара), Цена (стоимость товара).
8. «Доставка». Описывается атрибутами: Код метода доставки (ключевой), Метод доставки.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.  Разработка модели «сущность-связь».

 

 

IDEF1X является методом  для разработки реляционных баз  данных и использует условный  синтаксис, специально разработанный  для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира

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

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

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

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

- Уникальным образом идентифицировать экземпляр сущности.

- Не использовать NULL значений.

- Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа,    соответственно меняется экземпляр.

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

Потенциальные ключи, которые  не выбраны первичными, могут быть использованы в качестве вторичных  или альтернативных ключей. С помощью  альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими. При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта. Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущность ОТДЕЛ можно считать независимой. В IDEF1X независимые сущности представлены в виде прямоугольников.