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

Автор работы: Пользователь скрыл имя, 15 Февраля 2012 в 18:50, курсовая работа

Описание

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

Работа состоит из  1 файл

Kursova.docx

— 34.68 Кб (Скачать документ)
 
 
 
 
 
 
 

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

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

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

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

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

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

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

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

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

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

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

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

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

Firm

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
FirmID ціле число 10 Унікальний ID Первинний ключ
License ціле число 10 Номер Ліцензії Обов’язковий, унікальний
FirmName строка 20 Назва фірми Обов’язковий 
Address строка 50 Адреса фірми Обов’язковий
Telephone строка 11 Номер телефону Обов’язковий
Director строка 50 ПІБ директора Обов’язковий 
 

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

Managers

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
ManID ціле число 10 Унікальний ID Первинний ключ
ManName строка 50 Ім’я менеджера Обов’язковий
Address строка 50 Адреса менеджера Обов’язковий 
Date дата   Дата прийняття  на роботу Обов’язковий
NClients ціле число 5 Кількість клієнтів Обов’язковий
FirmID ціле число 10 ID Фірми, , зв'язок  з табл. Фірма Зовнішній ключ, що посилається на первинний ключ Firma(FirmID) відношення, обов’язковий
 
 

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

Client

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
ClName строка 50 Ім’я клієнта Обов’язковий
Address строка 50 Адреса клієнта Обов’язковий
ClientID ціле число 10 Код клієнта Первинний ключ
ManID ціле число 10 ID Менеджера  , зв'язок з табл. Менеджер Зовнішній ключ, що посилається на первинний ключ Managers(ManID) відношення, обов’язковий
 
 
 
 

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

Zakaz

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
ZakID ціле число 10 Унікальний ID Первинний ключ
Date дата   Дата замовлення Обов’язковий
Time ціле число 5 Час замовлення Обов’язковий, унікальний
ClientID ціле число 10 ID клієнта зв'язок  з табл. Клієнт Зовнішній ключ, що посилається на первинний ключ Clien(ClientID) відношення, обов’язковий
 

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

ZakTov

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
ZakID ціле число 10 ID  замовлення, звязок з табл. Замовлення Зовнішній ключ, що посилається на первинний ключ Zakaz(ZakID) відношення, обов’язковий
TovID строка 20 ID товару, звязок з табл. Товари Зовнішній ключ, що посилається на первинний ключ Tovar(TovID) відношення, обов’язковий
Сукупність  елементів ZakID,TovID є Первинним ключем
 

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

Tovar

Ім’я  стовпця Тип Довжина Призначення Обмеження цілісності стовпців
TovID ціле число 10 Унікальний ID Первинний ключ
Name строка 20 Назва товару Обов’язковий
TovModel строка 20 Модель товару Обов’язковий 
Kilk ціле число 5 Кількість на складі Обов’язковий, >=0
Cost ціле число 6 Ціна Обов’язковий, >=0

    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,

Информация о работе Проектирование базы данных