Логическое проектирование БД магазина «ТехноТорг»

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

• · отсутствие дублируемой информации;
• · поддержание целостности данных при вставке, удалении или изменении записей;
• · возможность организации всех видов связи между отношениями 1:1, 1: M и M: M.

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

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

Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными.

В конце этого этапа должно быть получено описание схемы БД в терминах выбранной СУБД. Целью даталогического проектирования является построение корректной схемы БД, ориентированную на реляционную модель. Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• · Декомпозиция (разбиение);
• · Синтез;

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

• 1. каждой сущности ставится в соответствие отношение;
• 2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;
• 3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);
• 4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);
• 5. по умолчанию, все атрибуты, не входящие в PK, необязательны;
• 6. для отражения категоризации сущностей возможны несколько вариантов;
• 7. все связи М: М должны быть раскрыты;

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

Категории.

• · Код категории — int NOT NULL PK
• · Название — varchar (40) NOT NULL

Товар

• · Код товара — int NOT NULL PK
• · Название — varchar (30) NOT NULL
• · Код категории — int NOT NULL FK
• · Код производителя — int NOT NULL FK
• · Срок гарантии — int NOT NULL
• · Цена товара — int NOT NULL

Продавец.

• · Код продавца — int NOT NULL PK
• · ФИО — varchar (40) NOT NULL
• · Дата рождения — date NOT NULL
• · Паспортные данные — varchar (20) NOT NULL
• · Адрес — varchar (100) NOT NULL
• · Телефон — int NOT NULL
• · Дата приема на работу — date NOT NULL

Клиент.

• · Код клиента — int NOT NULL PK
• · ФИО — varchar (40) NOT NULL
• · Дата рождения — date NOT NULL
• · Адрес — varchar (100) NOT NULL
• · Телефон — int NOT NULL
• · Почтовый индекс — int NOT NULL

Заказ.

• · Код заказа — int NOT NULL PK
• · Код доставки — int NOT NULL FK
• · Код клиента — int NOT NULL FK
• · Код товара — int NOT NULL
• · Количество товара — int NOT NULL
• · Дата заказа — date NOT NULL
• · Стоимость — int NOT NULL

Доставка товара.

• · Код доставки — int NOT NULL PK
• · Стоимость доставки — int NOT NULL
• · Адрес доставки — varchar (40) NOT NULL
• · Телефон — int NOT NULL
• · Дата доставки — int NOT NULL
• · Код менеджера — int NOT NULL FK

Менеджеры.

• · Код менеджера — int NOT NULL PK
• · ФИО — varchar (40) NOT NULL
• · Дата рождения — date NOT NULL
• · Паспортные данные — varchar (20) NOT NULL
• · Адрес — varchar (100) NOT NULL
• · Телефон — int NOT NULL
• · Дата приема на работу — date NOT NULL

Продажа товара.

• · Код чека — int NOT NULL PK
• · Код продавца — int NOT NULL FK
• · Количество товараint NOT NULL

Содержание чека.

• · Код чека — int NOT NULL FK
• · Код товара — int NOT NULL FK
• · Сумма — int NOT NULL

Производитель.

• · Код производителя — int NOT NULL PK
• · Название — varchar (25) NOT NULL
• · Страна — varchar (25) NOT NULL
• · Адрес сайта — varchar (30) NOT NULL
• · Телефон — int NOT NULL

При переходе от инфологической модели к реляционной модели была раскрыта связь М: М между отношениями «Продажа товара» и «Товар». Отношением-связкой стало отношение «Содержание чека». В нем в качестве FK были созданы атрибуты «Код товара» и «Код выбитого чека». Они вместе образуют уникальный идентифицирующий составной (композитный) PK.

Исходя из приведённых выше отношений, построим схему получившейся БД (Рисунок 8):

Рисунок 8. Схема реляционной модели БД «Магазин ТехноТорг».