Построение концептуальной модели данных
На первом этапе проектирования разработчик базы данных внимательно изучает предметную область, для которой разрабатывается база данных. Предметной областью называется та часть реальной жизни, в которой имеются информационные процесс, требующие автоматизации. Предметной областью может быть работа магазина розничной торговли, деятельность лечебного учреждения, работа учебного заведения или предприятия и т.д. Изучая предметную область, разработчик должен четко определить ее границы, то есть уяснить для себя, что входит в задачи автоматизации, а что не входит. Например, если на предприятии стоит задача автоматизации отгрузки товара со склада покупателю, то проблемы получения товара на склад из выпускающих цехов в задачу не входят.
Для изучения предметной области разработчик использует следующие способы:
- Беседы с потенциальными пользователями базы данных.
- Изучение нормативных документов, на основании которых происходят бизнес-процессы. Это могут быть уставы, лицензии, нормативные акты.
- Изучение оперативных документов, которые отражают бизнес-процессы. Это могут быть различные накладные, квитанции, платежные поручения.
На втором этапе проектирования разработчик должен выделить сущности предметной области. Сущностью предметной области называется абстрактное представление группы объектов с одинаковыми свойствами. Например, молоко, сыр, сметана – это конкретные продукты, но все вместе они относятся к сущности «продукция молокозавода» или «товар». Сущности предметной области описываются атрибутами. Атрибуты сущности – это абстрактные характеристики сущности, конкретные значения которых определяют конкретный экземпляр сущности. Например, сущность «продукция молокозавода» может описываться следующими атрибутами: наименование продукции, тип упаковки, вес, жирность. Если задать этим атрибутам конкретные значения, то мы получим описание конкретного продукта, выпускаемого молокозаводом. Например, молоко в тетрапаке весом 0.5л. и жирностью 3.2%.
После того как выделены все основные сущности и выбраны их атрибуты наступает третий этап проектирования. Разработчик должен определить отношения между сущностями. Отношением между сущностями называется та взаимосвязь, в которой сущности находятся в реальном мире. Например, если есть две сущности «поставщики» и «товары», то очевидно они связаны отношением «поставка товаров поставщиками». Начинающим проектировщикам и разработчикам желательно описывать отношение двумя предложениями. Первое предложение должно описывать отношение с позиции одной сущности, второе – с позиции другой. Например, в случае с поставками товаров описание должно звучать так:
- Один поставщик может поставлять много товаров.
- Один товар может поставляться многими поставщиками.
Приведем еще один пример. Рассмотрим сущности «автомобили» и «владельцы автомобилей». Между ними имеется отношение «владения автомобилем». Его описание будет выглядеть так:
- Один владелец может владеть многими автомобилями.
- Один автомобиль может принадлежать только одному владельцу.
Подобные описания отношений между сущностями называются ограничениями предметной области.
Результатом первых трех этапов проектирования становится концептуальная модель базы данных. Обычно ее изображают в виде диаграммы.
Нормальные формы
Далее на основе концептуальной модели строится логическая модель данных. Для этого используются специальные правила теории баз данных, которые называются нормальными формами. Нормальные формы имеют строгую математическую формулировку, не всегда понятную людям, чья профессиональная деятельность далека от математики. Поэтому формулировки, которые далее будут использоваться, являются нестрогими и упрощенными.
Вначале введем некоторые термины. Основной структурой для хранения данных в базе данных является таблица. Имена столбцов таблицы называются полями таблицы. Строки таблицы называются записями таблицы. Содержимое ячейки таблицы на пересечении строки и столбца называется значением поля данной записи.
Считается, что таблица находится в 1-ой нормальной форме, если ни одно значение поля не содержит списков и перечислений.
На четвертом этапе проектирования разработчик должен для каждой сущности предметной области спроектировать таблицу, где полями таблицы станут атрибуты сущности. При этом должна выполняться 2-я нормальная форма.
Таблица находится во 2-ой нормальной форме, если она находится в 1-ой нормальной форме и в ней выбрано одно поле со следующими свойствами:
- Значение поля не пусто для любой записи.
- Значение поля уникально для любой записи так, что по этому значению можно однозначно определить запись.
Такое поле называется ключевым полем таблицы или первичным ключом таблицы.
Замечание. В некоторых случаях первичный ключ может быть составным, то есть состоять из нескольких полей, которые не уникальны в отдельности, но уникальны в комбинации. В этом случае нужна более строгая формулировка 2-ой нормальной формы. Но такие ситуации возникают нечасто.
Для рассматриваемого примера о товарах и поставщиках нужно спроектировать две таблицы:
Таблица «Товары»
Таблица «Поставщики»
Связи и виды связей
На пятом этапе проектирования необходимо спроектировать связи между таблицами. Связи моделируют отношение между сущностями предметной области.
Для того чтобы установить связь необходимо перенести ключевое поле из одной таблицы в другую, но в другой таблице оно станет уже не ключевым, а обычным полем. Такие перенесенные ключевые поля называются внешними ключами (foreign key).
Проблема лишь в том, что при наличии двух таблиц можно перенести ключевые поля как минимум двумя способами: из таблицы «Товар» в таблицу «Поставщики» или наоборот - из таблицы «Поставщики» в таблицу «Товар». Эти варианты неравноценны! Для выбора правильного варианта нужно воспользоваться ограничениями предметной области, описанными на третьем этапе проектирования.
Попробуем добавить поле «Код товара» в таблицу «Поставщики» и показать, что поставщик «Ашан» поставляет оба вида молока и сыр.
Совершенно очевидно, что это невозможно сделать, не нарушив 1 н.ф. – в поле «Код товара» появился список. Построенный вид связи называется «один-ко-многим». В нем один товар может быть связан со многими поставщиками, но один поставщик может поставлять только один товар. При таких условиях нарушения 1 н.ф. не произошло бы, но они не соответствуют поставленной задаче.
Второй способ тоже приведет к нарушению 1 н.ф.
Этот способ тоже называется «один-ко-многим», но он соответствует другой ситуации: один поставщик может поставлять много товаров, но один товар поставляется одним поставщиком. И этот вариант тоже не соответствует нашим ограничениям предметной области.
Остается еще один способ построения связи: вынести ключевые поля двух таблиц в третью таблицу. Такой вид связи называется «много-ко-многим». В результате появится вот такая таблица:
Здесь уже не нарушается 1 н.ф. и полностью выполняются ограничения предметной области. Если хорошо подумать, то становится видно, что полученная таблица соответствует сущности «документ о поставке». Результатом проектирования становится схема логической модели:
