Разработка концептуальной модели базы данных
Концептуальное (инфологическое) проектирование – построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции.
Целью концептуального проектирования является обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком.
Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами [8].
Проведённый анализ предметной области позволяет построить её концептуальную модель, которая строится либо в виде диаграммы «Сущность-Связь» (Entity-Relationship-диаграммы, ER-диаграммы), либо записывается на языке концептуального(инфологического) моделирования (ЯКМ, ЯИМ).
Сущность Клиенты имеет следующие основные атрибуты:
- Код клиента
- Наименование компании
- ФИО клиента
- ИНН
- Адрес
- Индекс
- Город
- Телефон
Сущность Заказы имеет следующие основные атрибуты:
- Номер заказа
- Код клиента
- Код услуги
- Номер договора
- Наименование заказа
- Дата заказа
- Срок выполнения
- Код сотрудника
Сущность Услуги имеет следующие основные атрибуты:
- Код услуги
- Наименование услуги
- Цена услуги
Сущность Сотрудники имеет следующие основные атрибуты:
- Код сотрудника
- ФИО сотрудника
- ИНН
- Адрес
- Телефон
Сущность Заказ/Договор имеет следующие атрибуты (свойства):
- Номер договора
- Дата договора
- Сумма по договору
Изобразим это в виде диаграммы «Сущность-Связь» (ER-диаграммы), представленной на рисунке 1.
Рисунок 1 – ER-диаграмма базы данных
Все связи у сущностей «один ко многим».
Логическое проектирование базы данных
Логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования.
Логическая структура реляционной базы данных является адекватным отображением полученной информационно-логической модели, не требующим дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей.
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Первая нормальная форма (1НФ) не допускает наличия повторяющихся групп, то есть полей, содержащих более одного значения для каждого вхождения первичного ключа.
Вторая нормальная форма (2НФ) состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми.
Третья нормальная форма (ЗНФ) состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом.
Учитывая все требования, база данных рекламного агенства будет представлять собой шесть связанных таблиц: Клиенты, Заказы, Заказ/Договор, Заказ/Услуги, Сотрудники, Услуги. Таблица 1 содержит информацию о таблицах, находящихся в составе БД «Рекламное агентство».
Таблица 1 - Атрибуты и отношения в составе таблиц БД «Рекламное агентство»
Таблица |
Имя столбца |
Тип данных |
Ключ таблицы по полю |
Ограничения |
||
Первичный ключ |
Внешний ключ |
|||||
1 |
2 |
3 |
4 |
5 |
6 |
|
zakazi |
KOD_ZAK |
int |
+ |
- |
IDENTITY |
|
|
KOD_KL |
int |
- |
+ |
UNIQUE |
|
|
KOD_USLUG |
int |
- |
+ |
- |
|
|
NAIMEN_ZAK |
varchar(50) |
- |
- |
- |
|
|
DATA |
date |
- |
- |
- |
|
|
KOD_ISP |
int |
- |
+ |
- |
|
klienti |
KOD_KL |
int |
+ |
- |
IDENTITY |
|
|
NAZV_KOMP |
varchar(50) |
- |
- |
- |
|
|
FIO_KL |
varchar(40) |
- |
- |
- |
|
|
INN |
int |
- |
- |
- |
|
|
ADDRESS_KL |
varchar(40) |
- |
- |
- |
|
|
INDEX_KL |
int |
- |
- |
- |
|
|
CITY |
varchar(30) |
- |
- |
- |
|
|
TEL |
bigint |
- |
- |
- |
|
uslugi |
KOD_USLUG |
int |
+ |
- |
IDENTITY |
|
|
NAME_USLUG |
varchar(30) |
- |
- |
- |
|
|
CENA_USLUG |
bigint |
- |
- |
- |
|
sotrudniki |
KOD_SOTRUD |
int |
+ |
- |
identity |
|
|
FIO_SOTRUD |
varchar(40) |
- |
- |
- |
|
|
INN |
int |
- |
- |
- |
|
|
ADDRESS_SOTRUD |
varchar(40) |
- |
- |
- |
|
|
TEL |
bigint |
- |
- |
- |
|
zakaz_dogovor |
NOM_DOG |
int |
+ |
- |
identity |
|
|
DATE_ZD |
date |
- |
- |
- |
|
|
SUMMA_ZD |
bigint |
- |
- |
- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Продолжение таблицы 1
Датологическая модель базы данных разработана в соответствии с принципами нормализации, следующий этап разработки – создание физической модели данных.