Клиенты

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

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

Две таблицы связаны отношением «один-ко-многим» (1:М), если каждой строке в первой таблице соответствует ни одной, одна или много строк во второй таблице, но каждой строке во второй таблице соответствует только одна строка в первой таблице. Как видно из таблицы 2.2, в каждом городе может быть несколько клиентов. Поэтому таблица Города связана с таблицей Клиенты отношением «один-ко-многим».

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

Две таблицы связаны отношением «многие-ко-многим» (М:М), если каждой строке в первой таблице соответствует много срок во второй таблице и каждой строке во второй таблице соответствует много строк в первой таблице. Отношения типа «многие-ко-многим» (М:М) не могут быть смоделированы в программах реляционных баз данных напрямую – они должны быть представлены множеством отношений типа «один-ко-многим» (1:М). Например, одна товарная номенклатура может быть поставлена множеством поставщиков, а один поставщик может поставлять множество товарных номенклатур. Поэтому таблица Номенклатура и Поставщики будет связана отношением «многие-ко-многим» (М:М). Чтобы смоделировать такие отношения между двумя указанными таблицами, необходимо ввести третью таблицу Поставки, которая будет таблицей связи. Таким образом, отношение «многие-ко-многим» (М:М) между таблицами Номенклатура и Поставщики может быть разбито на два отношения «один-ко-многим»: таблицы Номенклатура и Поставки, а также Поставщики и Поставки связаны между собой отношением «один-ко-многим». Действительно, одна единица номенклатуры может присутствовать во множестве поставок, а один поставщик может осуществлять поставки множество раз.

Реляционная модель задает общие и специфические правила целостности. Общие правила целостности относятся ко всем базам данных и определяют целостность объекта и целостность на уровне ссылок.

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

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

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

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

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

- дата приема заказа всегда должна быть больше или равна дате начала деятельности фирмы и меньше или равна текущей дате;

- время приема заказа должно указываться в пределах рабочего времени;

- дата и время выполнения заказа должны быть больше или равны дате и времени выполнения заказа;

- новые заказы не должны включать работы, которые фирмой уже не выполняются;

- возраст сотрудников должен быть старше 18 лет и т.д.

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

- между полями таблицы не должно быть нежелательных функциональных зависимостей;

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

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

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