3. Проектування бази даних
3.1. Побудова er-діаграми
На підставі концептуальної моделі, виділяємо в системі наступні сутності:
масив груп відеодисків
масив відеодисків
масив груп абонентів
масив абонентів
масив видач
Побудуємо ER-діаграму, представивши її на трьох рівнях:
Рівень сутностей
Рівень ключових полів
Повна атрибутивна модель.
Ці рівні діаграми представлені на рисунках 3.1.1-3.1.3 відповідно
Рисунок 3.1.1. ER-діаграма на рівні сутностей
Рисунок 3.1.2. ER-діаграма на рівні первинних ключів та полів зв’язку (вторинних ключів).
Рисунок 3.1.3. Повна атрибутивна модель.
3.2. Побудова схеми реляційної бази даних у третій нормальній формі
Процес проектування БД з використанням методу нормальних форм є ітераційним (покроковим) і полягає у послідовному переведенні за певними правила відношень з першої нормальної форми у нормальні форми вищого порядку. Кожна наступна нормальна форма обмежує певний тип функціональних залежностей, усуває відповідні аномалії при виконанні операцій над відношеннями БД і зберігає властивості попередніх нормальних форм.
Виділяють таку послідовність нормальних форм:
перша нормальна форма
друга нормальна форма
третя нормальна форма
посилена третя нормальна форма або нормальна форма Бойса-Кодда
четверта нормальна форма
п’ята нормальна форма.
Для того, щоб БД належала до першої нормальної форми, її таблиці повинні відповідати таким вимогам:
поля містять неподільну інформацію;
в таблиці відсутні повторювані групи полів
До другої нормальної форми пред’являються такі вимоги:
таблиця повинна задовольняти вимогам першої нормальної форми
будь-яке неключове поле повинне однозначно ідентифікуватися ключовими полями
До третьої нормальної форми пред’являються такі вимоги:
таблиця повинна задовольняти вимогам другої нормальної форми
ні одне з неключових полів не повинно однозначно ідентифікуватися значенням іншого неключового поля (полів)
Опишемо функціональні залежності у побудованій в попередньому розділі БД:
- Таблиця «Масив груп відеодисків»
Т(код групи:назва групи)=1:1
Кожне неключове поле однозначно ідентифікується ключовим полем «код групи», жодне неключове поле не ідентифікується однозначно значеннями іншого неключового поля. Таблиця знаходиться у третій нормальній формі
- Таблиця «Масив відеодисків»
Т(інвентарний номер:код групи)=Б:1
Т(інвентарний номер:назва диску)=Б:1
Т(інвентарний номер:опис)=Б:1
Т(інвентарний номер:примітка)=Б:1
Т(інвентарний номер:дата надходження)=Б:1
Т(інвентарний номер:ознака видачі)=Б:1
Кожне неключове поле однозначно ідентифікується ключовим полем «інвентарний номер», жодне неключове поле не ідентифікується однозначно значеннями іншого неключового поля. Таблиця знаходиться у третій нормальній формі.
-Таблиця «Масив груп абонентів»
Т(код групи абонентів:назва групи абонентів)=1:1
Кожне неключове поле однозначно ідентифікується ключовим полем «код групи абонентів», жодне неключове поле не ідентифікується однозначно значеннями іншого неключового поля. Таблиця знаходиться у третій нормальній формі.
-Таблиця «Масив абонентів»
Т(код абонента:код групи абонента)=Б:1
Т(код абонента:ПІП абонента)=Б:1
Т(код абонента:адреса абонента)=Б:1
Кожне неключове поле однозначно ідентифікується ключовим полем «код групи абонентів», жодне неключове поле не ідентифікується однозначно значеннями іншого неключового поля. Таблиця знаходиться у третій нормальній формі.
-Таблиця «Масив видачі»
Щоб перевести талицю в другу нормальну форму, необхідно додати до неї поле, яке б відігравало роль ключа. Інколи таки поле називають псевдоключем. Назавемо його «унікальний код видачі». При його наявності функціональні залежності між полями виглядають так:
Т(унікальний код видачі:інвентарний номер книжки)=Б:1
Т(унікальний код видачі:код абонента)=Б:1
Т(унікальний код видачі:дата видачі)=Б:1
Т(унікальний код видачі:ознака повернення)=Б:1
Т(унікальний код видачі:дата повернення)=Б:1
Кожне неключове поле однозначно ідентифікується ключовим полем «унікальний код видачі», жодне неключове поле не ідентифікується однозначно значеннями іншого неключового поля. Таблиця знаходиться у третій нормальній формі.
Остаточно одержимо реляційну базу даних, структура якої приведена на рисунку 3.2.1.
Рисунок 3.2.1. Структура БД, зведеної до третьої нормальної форми