Проектирование базы данных

 
 
 
 
 
 
 

КУРСОВА РОБОТА

з дисципліни «Організація баз даних та знань» 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

1.Логічне проектування

Логічне проектування — це розробка логічної структури системи баз даних

без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д. 

     У якості логічній моделі бази даних  була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.

    Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.

• Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
• Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
• Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

 
 

Рис. Концептуальна ER-модель

Сутність  може унікально ідентифікуватися комбінацією  атрибутів і/або  зв'язків. При  використанні в ідентифікаторі сутності зв'язку до складу первинного ключа  включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.

• Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори  кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
• Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях. 
 
 

Таблиця 1. Відношення сутності Фірма

Firm

 

Таблиця 2. Відношення сутності Менеджер

Managers

 
 

Таблиця 3. Відношення сутності Клієнт

Client

 
 
 
 

Таблиця 4. Відношення сутності Замовлення

Zakaz

 

Таблиця 5. Відношення сутності Замовл-Товари

ZakTov

 

Таблиця 6. Відношення сутності Товари

Tovar

    2.Фізичне проектування

    Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.  

База  даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об’єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних.  Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.

Логічна модель бази даних легко відображається в реляційну фізичну модель, оскільки логічна модель була побудована з  використанням реляційної структури  даних. Крім того, логічна модель була приведена у третю нормальну  форму, тому усі відношення представляються  у фізичній моделі окремими таблицями. Ніякі злиття відношень в одну таблицю для підвищення ефективності виконання окремих класів запитів  не виконуються у зв’язку  з  тим, що такі класи запитів не були знайдені. У результаті отримано сімнадцять таблиць реляційної бази даних, де кожне відношення прямо відповідає окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а первинні ключі відношень стають первинними ключами таблиць. 

Скрипти створення бази даних:

Наведемо  скрипт мови SQL Oracle, який створює таблиці БД. 

create table Firm(

      FirmID integer(10) CONSTRAINT PRIMARY KEY,

      License integer(10) CONSTRAINT NOT NULL UNIQUE,

      FirmName char(20) CONSTRAINT NOT NULL,

      Address char(50) CONSTRAINT NOT NULL,

      Telephone char(11) CONSTRAINT NOT NULL,

      Director char(50) CONSTRAINT NOT NULL 

);

create table Managers(

      ManID integer(10) CONSTRAINT PRIMARY KEY,

      ManName char(50) CONSTRAINT NOT NULL,