Проектирование баз данных.
Итак, поискав на хабре информацию по проектированию БД, и не найдя ничего более или менее вразумительного, я решил написать об этом небольшую статью.
Проектирование базы данных сводится к трем последовательным этапам:
- Концептуальное проектирование
- Логическое проектирование
- Физическое проектирование
Ниже я предлагаю ознакомиться с ними более детально.
Концептуальное проектирование
На этапе концептуально проектирования мы создаем концептуальную модель данных, для исходных требований, которая не зависит от типа СУБД, прикладных программ, языка программирования и др. Также концептуальная модель данных должна быть понятна не только разработчику, но и простому человеку.
Наиболее широко используемым методом создания концептуальной модели является модель «сущность — связь» (Entity – Relationship model, ER – модель).
Суть этой модели состоит в том, что рассматриваемая область представляется в виде сущностей, и связей между ними.
Сущность это некий объект реального мира, информацию о котором нужно сохранить в базе данных. Например сотрудники, компьютеры, велосипеды, договоры и т.д.
Сущности, в свою очередь делятся на сущности слабого и сильного типов, сущности сильного типа, это те, которые могут существовать независимо от других, например сущность студенты — сильная, а родственники студентов — слабая, т.к. она не может существовать отдельно от студентов.
Например, пусть мы имеем следующий исходный набор данных при разработке базы данных «Склад товаров сети магазинов»:
Информация о товарах:
- Название товара
- Описание товара
- Цена товара
- Остаток
Информация о поставщиках:
- Код поставщика
- Товар поставки
Выдача товаров магазинам:
- Номер филиала
- Выданный товар
- Дата выдачи
Из этих данных можно выделить три сущности:
- Товары
- Поставщики
- Магазины
Построим т.н. ER диаграмму:
Примечание: Существует множество схем представления ER-диаграмм, я выбрал схему предложенную П.Ченом, сущности на диаграммах обозначаются прямоугольниками, связываются с их атрибутами линиями, а связи между сущностями обозначаются ромбами.Ключевые атрибуты подчеркнуты.Указывается тип связи 1:1, или 1:N (один ко многим), N:N (многие ко многим)
Логическое проектирование
На этапе логического проектирования мы переходим от полученной концептуальной модели, ко конкретным отношениям (таблицам) базы данных. В частности, на данном этапе проводится нормализация отношений.
Продолжим на том же примере. В полученной ER — модели у нас получилась связь многие ко многим между товарами и поставщиками (т.к. один товар может поставляться несколькими поставщиками, и один поставщик может поставлять несколько товаров), это приводит к увеличению объема обеих таблиц и повторению данных. Разобьем две сущности на три таблицы:
- Товары (Название товара, описание, цена, остаток)
- Поставщики ( Код поставщика, название поставщика)
- Поставка товаров ( Код поставщика, название товара )
в результате получим три отношения со связями один ко многим между товарами и поставками товаров и поставщиками и поставками товаром.Так же эти три отношения находятся в НФБК.
Сущность филиалы, в том виде, в котором она есть уже уже удовлетворяет НБФК:
Филиалы ( Номер филиала, название товара, дата заказа, количество)
Таким образом, мы получили четыре отношения, из трех сущностей, при задаче нормализации полученных отношений до НФБК. Количество получившихся отношений, зависит целиком от условий поставленной задачи.
Физическое проектирование
На этом этапе выбирается СУБД, в которой реализовываются полученные в предыдущем пункте отношения, разрабатывается пользовательский интерфейс.
Подводя итоги, замечу, что подобный, последовательный подход сокращает время при проектировании достаточно больших баз данных, в которых легко запутаться проектируя «наскоком» или «интуитивно», конечно для каждого понятие большие очень субъективно, но используя подобный подход при проектировании любых баз данных, ее качество получится точно не хуже чем при проектировании «интуитивно».
Спасибо за внимание.
Автор: GlebkaF
