Концептуальне та логічне проектування навчальної бази даних «Автотранспортне підприємство»

Вступ

Історія досліджень систем баз даних — це за своєю суттю історія розвитку програмного забезпечення, яке на сьогоднішній день досягло виняткової потужності та продуктивності, що зробило великий вплив на економіку. Досягнення в дослідженнях баз даних стало основою фундаментальних розробок комунікаційних систем, транспорту та логістики, фінансового менеджменту, систем із базами знань, а також великої кількості програм у цивільних та військових установах. Вони також стали основою значного прогресу в провідних галузях науки — від інформатики до медицини.

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

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

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

Розділ 1. Специфікація вимог для кожного з двох користувачів

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

1.1 Вимоги до даних

Специфікація вимозі представлення користувача «Диспечер»

· в автотранспортному підприємстві працюють водії, механіки та бригадири

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

· всі водії розподілені по бригадам, яка має свою спеціалізацію і підпорядковуються бригадирам

· водій для здійснення перевезень використовує автомобіль, який має державний номер, модель, тип (напівпричіп, самоскид, цистерна, автовоз, бортовий автомобіль)

· Перевезення здійснюються по маршруту, який має номер, назву, довжину, тариф

· Підприємство займається перевезенням вантажів, які мають номер, назву, розмір, тип та одиницю виміру Специфікація вимозі представлення користувача «Головний інженер».

· Підприємство власними силами здійснює ремонт автомобілів. Облік ремонтів повинен містити його номер, дату, автомеханіка, який його здійснював, опис, номер автомобіля.

· Інформація про автомобілі складається з державного номеру, моделі, типу, дати виробництва, пройденого шляху, витрат пального на 100 км.

· Інформація про водія та механіка повинна містити номер, ім'я, прізвище, дату народження, дату працевлаштування, а для механіка, ще й № гаража в якому він проводить ремонт автомобілів.

1.2 Вимоги до транзакцій

Транзакція бази даних являє собою операцію, для виконання якої потрібно здійснити доступ до бази даних. Як правило, вона є відображенням деякої події, що відбувається в реальному світі. Ціль проектування транзакцій полягає у визначенні і документуванні високорівневих характеристик транзакцій, необхідних для створюваної системи з базою даних.

Відзначимо, що коли ми говоримо представлення користувача «Диспетчер», та «Головний інженер» ми маємо на увазі представлення про бізнес-процеси компанії, які у загальному випадку мають і реалізують усі працівники, котрі займають у цій компанії посади «Диспетчер» та «Головний інженер».

Специфікація вимозі представлення користувача «Диспетчер «

· Складання списку клієнтів;

· Складання списку водіїв;

· Створення звіту, що містить докладні зведення про укладені угоди.

Специфікація вимозі представлення користувача «Головний інженер».

· Складання списку працівників, що працюють у бригадах;

· Складання направлень для бригад на роботи;

· Складання звітів по виконаним завданням.

Розділ 2. Концептуальне проектування бази даних

Концептуальне проектування бази даних — процес створення моделі використовуваної на підприємстві інформації, що не залежить від будь-яких фізичних аспектів її представлення. Перша фаза процесу проектування бази даних називається концептуальним проектуванням бази даних. Вона полягає в створенні концептуальної моделі даних для аналізованої частини підприємства. Ця модель даних створюється на основі інформації, записаної в специфікаціях вимог користувачів. Концептуальне проектування бази даних абсолютно не залежить від таких подробиць її реалізації, як тип обраної цільовий СКБД, набір створюваних прикладних програм, використовувані мови програмування, тип обраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації. При розробці концептуальна модель даних постійно піддається тестуванню і перевірці на відповідність вимогам користувачів. Створена концептуальна модель дані підприємства є джерелом інформації для фази логічного проектування бази даних. Приступаючи до розроблення локальної концептуальної моделі даних для представлення користувача «Диспетчер» та «Головний інженер» у базі даних «Автотранспортне підприємство», насамперед, варто виявити різні компоненти цієї моделі, використовуючи наявні специфікації вимог користувача (далі - просто «специфікації»). У кожну створювану модель даних входять наступні компоненти:

· типи сутностей;

· типи зв’язків;

· атрибути;

· домени атрибутів;

· потенційні ключі;

· первинні ключі.

2.1 Визначення типів сутностей

Почнемо роботу з того, що визначимо основні типи сутностей, виходячи з наявних специфікацій. У специфікаціях сутності звичайно представлені як іменники або вирази, що містять іменники. Аналіз показує, що основними сутностями, що згадуються в специфікаціях, є наступні:

· працівник;

· водій;

· механік;

· бригадир

· автомобіль;

· ремонт;

· маршрут;

· бригада;

· вантаж;

· одиниці виміру вантажу;

· перевезення

Документування зведень про кожну з виділених сутностей полягає в підготовці докладного визначення кожної сутності, включаючи існуючі для неї псевдоніми й опис особливостей використання — наприклад, таких: «Кожен об'єкт має єдиного власника». Усі зведення, поміщені в документацію на цьому етапі, наведені в таблиці 2.1.

Таблиця 2.1 Відомості про типи сутностей, які поміщено в документацію бази даних «Автотранспортне підприємство»

2.2 Визначення типів зв’язків

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

Наступний крок — визначення кардинальності і рівня участі для кожного зв’язків.

Кардинальність будь-якого зв’язку може мати значення або «Один до одного» (1:1), або «один до багатьох» (1: Б), або «багато до багатьох» (Б:Б). Для кожного зв’язку потрібно вказати його кардинальність і, якщо це можливо, верхній або нижній ліміти груп. Участь кожного з членів зв’язку може бути визначена або як повна (тотальна, умовне позначення «П»), або як часткова («Ч»). Якщо зведень, що утримуються в специфікаціях, не досить для однозначного визначення властивостей деяких зв’язків, для прояснення ситуації варто звернутися до користувачів.

Результати аналізу представлені в табл. 2.2.

Таблиця 2.2. Зведення про типи зв’язків, поміщені в документацію

2.3 Визначення атрибутів і зв’язування їх з типами сутностей і зв’язків

Тепер нам необхідно виділити атрибути сутностей, що у специфікаціях також можуть бути представлені іменниками (або відповідними сполученнями). Атрибут описує деякий аспект визначеної сутності або зв’язку. У документацію необхідно помістити докладні зведення про атрибути. Для кожного атрибута варто вказати загальний опис, тип даних і довжину значення, наявні обмеження, значення за замовчуванням (якщо таке мається), псевдоніми (якщо такі існують), а також є атрибут складеним або похідним і чи припустиме для нього значення NULL. Зведення про виділені атрибути і їх приналежність відповідним сутностям і зв’язкам приведені в табл. 2.3.

Таблиця 2.3. Зведення про атрибути, поміщені в документацію

2.4 Визначення доменів атрибутів

Завдання цього етапу побудови локальної концептуальної моделі даних полягає у визначенні доменів атрибутів для всіх атрибутів, присутніх в моделі. Доменом називається деякий пул значень, елементи якого вибираються для присвоєння значень одному або більше атрибутів. Документування доменів атрибутів приведено в таблиці 1.4.

Таблиця 2.4 Зведення про домени атрибуті, поміщені в документацію

2.5 Визначення атрибутів, що є потенційними і первинними ключами

На цьому етапі для кожної сутності встановлюється потенційний ключ (або ключі), після чого здійснюється вибір первинного ключа. Потенційним ключем називається атрибут або мінімальний набір атрибутів заданої суті, дозволяє унікальним чином ідентифікувати кожен її примірник. Для деяких сутностей можлива наявність кількох потенційних ключів. У цьому випадку серед них потрібно вибрати один ключ, який буде називатися первинним ключем. Всі інші потенційні ключі будуть називатися альтернативними ключами.

Таблиця 2.5 Зведення про первинні та альтернативні ключі, поміщені в документацію

2.6 Спеціалізація/генералізація типів сутностей

Розглянемо взаємини між сутностями, що представляють працівників підприємства. У специфікаціях визначено чотири типи подібних сутностей: Робітник, Водій, Механік, Бригадир. Ці сутності мають багато однакових атрибутів тому виконаємо генералізацію сутностей.

2.7 Створення діаграми «сутність-зв'язок»

З метою одержання наочного представлення основних сутностей і зв’язків, визначених у специфікаціях, ми побудували вихідну ER-діаграму. Ця ER-діаграма і підготовлена на етапі 1 документація (у сукупності) являють собою локальну концептуальну модель даних бази даних «Автотранспортне підприємство».

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

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

Розділ 3. Логічне проектування учбової бази даних

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

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

В результаті виконання даного етапу будуть створені коректні, повні та точні моделі уявлень користувачів. Це дасть нам міцну основу, необхідну для виконання наступного етапу, що полягає в об'єднанні окремих локальних логічних моделей даних в єдину глобальну модель даних всього підприємства.

3.1 Перетворення концептуальної Моделі Даних у логічну модель

На цьому етапі ми займемося перетворенням концептуальної моделі даних з метою видалення з неї всіх структур, реалізація яких у СУБД реляційного типу скрутна. Бажаний результат може бути досягнуть за допомогою виконання таких дій, як:

1. Видалення зв’язків типу M: N.

2. Видалення складних зв’язків.

3. Видалення рекурсивних зв’язків.

4. Видалення зв’язків, що мають атрибути.

5. Видалення множинних атрибутів.

6. Повторний огляд зв’язків типу 1:1.

7. Видалення надлишкових зв’язків.

3.1.1 Видалення зв’язків типу багато до багатьох

У локальній концептуальній моделі даних зв’язки типу Б: Б відсутні, тому ми переходимо до наступного етапу.

3.1.2 Видалення складних зв’язків

На цьому етапі проводиться видалення будь-яких складених (не бінарних) зв’язків, що є присутніми у концептуальній моделі. У локальній концептуальній моделі даних для програми «Автотранспортне підприємство» складні зв’язки відсутні, тому ми переходимо до наступного етапу.

3.1.3 Видалення рекурсивних зв’язків

У локальній концептуальній моделі даних рекурсивні зв’язки відсутні, тому ми просто переходимо до наступного етапу.

3.1.4 Видалення зв’язків, що мають атрибути

Присутність зв’язків з атрибутами може вказувати на наявність у моделі ще не виділених сутностей. У нашому випадку таких атрибутів немає.

3.1.5 Видалення множинних атрибутів

У локальній концептуальній моделі даних множинні атрибути відсутні, тому ми переходимо до наступного етапу.

3.1.6 Повторний огляд зв’язків типу 1:1

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

3.1.7 Видалення надлишкових зв’язків

У локальній концептуальній моделі даних надлишкові зв’язки відсутні, тому ми переходимо до наступного етапу.

3.1.8 Створення діаграм «сутність-зв'язок»

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

3.2 Визначення набору відношень виходячи зі структури логічної моделі даних

На цьому етапі нашою задачею буде створення відношень, що представляють сутності і зв’язки, локальної логічної моделі даних програми «Автотранспортне підприємство».

Зв’язки між сутностями моделюються за допомогою механізму первинних і зовнішніх ключів. Для опису складу всіх створюваних відношень буде використовуватися мова DDL.

create table `Team` (

`TmName` CHAR (15),

`TmSpecialization` CHAR (15),

`Foreman` CHAR (10), constraint `Team_PK` primary key (`Foreman`, `TmName`));

create table `Transporting` (

`trNum` CHAR (10),

`TrDate` DATETIME,

`TrCustomer` CHAR (25),

`TrPaymentType` CHAR (13),

`Route` CHAR (25),

`Cargo` CHAR (10),

`Car` CHAR (8),

`Driver work onemployee empNum` CHAR (10), constraint `Transporting_PK` primary key (`trNum`));

create table `Route` (

`RtName` CHAR (25),

`RtNum` CHAR (10),

`RtLength` INTEGER,

`RtRate` INTEGER, constraint `Route_PK` primary key (`RtName`));

create table `Repair` (

`rpNum` CHAR (10),

`Mechanic` CHAR (10),

`Car` CHAR (8),

`RepDate` CHAR (10),

`RepDescription` CHAR (40), constraint `Repair_PK` primary key (`Mechanic`, `rpNum`));

create table `Employee` (

`empNum` CHAR (10),

`EmpFName` CHAR (15),

`EmpSName` CHAR (15),

`EmpMName` CHAR (15),

`EmpDoB` DATETIME,

`EmpDateOfEmployment` DATETIME,

`EmpTown` CHAR (15),

`EmpStreet` CHAR (15),

`EmpBuilding` CHAR (7),

`EmpRoom` CHAR (4), constraint `Employee_PK` primary key (`empNum`));

create table `Mechanic` (

`empNum` CHAR (10),

`MhGarageNum` CHAR (2), constraint `Mechanic_PK` primary key (`empNum`));

create table `Measure` (

`MsName` CHAR (3),

`MsTypeOfCargo` CHAR (10), constraint `Measure_PK` primary key (`MsName`));

create table `Foreman` (

`empNum` CHAR (10),

`FrDiplomNum` CHAR (8),

`FrDiplomSeries` CHAR (2), constraint `Foreman_PK` primary key (`empNum`));

create table `Driver` (

`empNum` CHAR (10),

`DrLicenseNum` CHAR (10),

`DrLicenseDate` DATETIME,

`Team` CHAR (15), constraint `Driver_PK` primary key (`empNum`));

create table `Cargo` (

`crgNum` CHAR (10),

`CrName` CHAR (10),

`CrSize` CHAR (10),

`CrTipe` CHAR (10),

`Measure` CHAR (3), constraint `Cargo_PK` primary key (`crgNum`));

create table `Car` (

`CarLicenseNum` CHAR (8),

`Driver` CHAR (10),

`CarModel` CHAR (15),

`CarTipe` CHAR (15),

`CarDoM` DATETIME,

`CarMileage` INTEGER,

`CarFuelPer100km` DOUBLE, constraint `Car_PK` primary key (`Driver`, `CarLicenseNum`));

alter table `Team`

add constraint `Foreman_Team_FK1` foreign key (

`Foreman`)

references `Foreman` (

`empNum`);

alter table `Transporting`

add constraint `Route_Transporting_FK1` foreign key (

`Route`)

references `Route` (

`RtName`);

alter table `Transporting`

add constraint `Cargo_Transporting_FK1` foreign key (

`Cargo`)

references `Cargo` (

`crgNum`);

alter table `Transporting`

add constraint `Car_Transporting_FK1` foreign key (

`Driver work onemployee empNum`,

`Car`)

references `Car` (

`Driver`,

`CarLicenseNum`);

alter table `Repair`

add constraint `Car_Repair_FK1` foreign key (

`Mechanic`,

`Car`)

references `Car` (

`Driver`,

`CarLicenseNum`);

alter table `Repair`

add constraint `Mechanic_Repair_FK1` foreign key (

`Mechanic`)

references `Mechanic` (

`empNum`);

alter table `Mechanic`

add constraint `Employee_Mechanic_FK1` foreign key (

`empNum`)

references `Employee` (

`empNum`);

alter table `Foreman`

add constraint `Employee_Foreman_FK1` foreign key (

`empNum`)

references `Employee` (

`empNum`);

alter table `Driver`

add constraint `Team_Driver_FK1` foreign key (

`empNum`,

`Team`)

references `Team` (

`Foreman`,

`TmName`);

alter table `Driver`

add constraint `Employee_Driver_FK1` foreign key (

`empNum`)

references `Employee` (

`empNum`);

alter table `Cargo`

add constraint `Measure_Cargo_FK1` foreign key (

`Measure`)

references `Measure` (

`MsName`);

alter table `Car`

add constraint `Driver_Car_FK1` foreign key (

`Driver`)

references `Driver` (

`empNum`);

3.3 Перевірка моделі за допомогою правил нормалізації

Нормалізація — метод створення набору відносин із заданими властивостями на основі вимог до даних, встановленим у деякій організації.

Перша нормальна форма (1НФ) — відношення, у якому на перетинанні кожного рядка і кожного стовпця міститься тільки одне значення.

Проаналізувавши програму «Автотранспортне підприємство» можна зробити висновок, що вона знаходиться в 1НФ.

Друга нормальна форма (2НФ) — відношення, що знаходиться в першій нормальній формі і кожен атрибут якого, що не входить до складу первинного ключа, характеризується повною функціональною залежністю від цього первинного ключа.

Повна функціональна залежність: У деякім відношенні атрибут Б називається цілком функціонально залежним від атрибута А, якщо атрибут Б функціонально залежить від повного значення атрибута, А и не залежить ні від якої підмножини повного значення атрибута А.

Оскільки логічна модель бази даних не має складених первинних ключів то вона знаходиться у 2НФ.

Третя нормальна форма (ЗНФ) — відношення, що знаходиться в другий нормальних формах і не має не вхідних у первинний ключ атрибутів, що знаходилися б у транзитивній функціональній залежності від цього первинного ключа. Транзитивна залежність: Якщо для атрибутів А, В и С деякого відношення існують залежності виду, А -> В и В -> С, те говорять, що атрибут С транзитивно залежить від атрибута, А через атрибут Б (за умови, що атрибут, А функціонально не залежить ні від атрибута В, ні від атрибута С). У логічній моделі бази даних курсового проекту відсутні не вхідні у первинний ключ атрибути, що знаходяться у транзитивній залежності ві цього ключа, отже, вона знаходиться у 3НФ.

Нормальна форма Бойса-Кодда (НФБК). Відношення знаходиться в НФБК тоді і тільки тоді, коли кожен його детермінант є потенційним ключем. Оскільки у логічній моделі БД відсутні детермінанти, які не є потенційними ключами можна вважати, що вона знаходиться в НФБК.

3.4 Перевірка моделі у відношенні транзакцій користувачів

Перевіряємо локальну логічну модель даних представлених у відношенні можливості виконання всіх транзакцій, передбачених специфікаціями, для цього використаємо ER-діаграму. Якщо, спроба виконати кожну з транзакцій вручну буде вдалою, то можна вважати, що дана логічна модель успішно перевірена. Якщо ж ні то у даній моделі присутня помилка, яку варто усунути.

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

Створення і коректування записів, що містять докладні зведення про роботу Автотранспортного підприємства, яке обслуговує клієнтів різного типу:

· Для коректування даних про вже існуючих працівників із уже призначеним унікальним номером, насамперед, необхідно виконати пошук цього номера серед значень відповідного атрибута. Якщо заданий користувачем номер знайдений не буде, фіксується помилка, оскільки виконати коректування виявляється неможливим. В іншому випадку необхідно переконатися, що кожний з елементів даних, значення яких необхідно відкоригувати, є присутнім у відношенні як атрибут.

· Для видалення відомостей про деяку бригаду, задану її особистим номером, варто виконати пошук необхідного номера бригади серед значень відповідного атрибута зовнішнього ключа.

3.5 Визначення вимог підтримки цілісності даних

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

· обов’язкові дані;

· обмеження для доменів атрибутів;

· цілісність сутностей;

· посилальна цілісність;

· вимоги підприємства.

Обов’язкові дані:

Необхідно установити, які з атрибутів завжди повинні містити одне з припустимих значень. Якщо говорити більш конкретніше то це атрибути, що завжди повинні мати значення, відмінні від NULL.

Наприклад, атрибути Номер працівника і ПІБ сутності Працівник завжди повинно містити значення, відмінні від порожнього. Але на атрибут Телефон цієї ж сутності дана вимога не поширюється, і ці атрибути цілком можуть мати значення NULL, що означає що в клієнта або немає телефону, або номер його невідомий, або зазначене значення виявилося некоректним.

Докладні зведення про атрибути, що входять у локальну модель даних були приведені у таблиці 1.3.

Обмеження для доменів атрибутів:

Домен атрибута встановлює набір припустимих значень, що можуть привласнюватися цьому атрибутові.

Наприклад, набір припустимих значень для атрибута Номер_працівника сутності Працівник являє собою всі можливі рядки довжиною від одного до п’яти символів.

Докладні зведення про домени атрибутів, що входять у локальну модель даних були приведені у таблиці 1.4.

Цілісність сутностей:

Атрибут первинного ключа сутності не може мати значення NULL.

Наприклад, кожен екземпляр сутності Відділення обов’язково повинний мати конкретне значення атрибута його первинного ключа Номер. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні етапів 2.5 і 3.2.

Посилальна цілісність:

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

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

Варто вказати умови для кожного зовнішнього ключа, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з запропонованих стратегій — NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK.

Вимоги даного підприємства

Ці вимоги, ще називають бізнес-правилами, які визначаються тими методами й обмеженнями, що прийняті на підприємстві.

Одним з них є те, що диспетчер не може редагувати дані про проведені ремонти, а головний інженер — про здійснені перевезення.

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

create view «Dispatcher» («Transporting number», «Date», «Customer», «Payment type», «Cargo», «Route», «car number», «Car model», «Driver number», «Driver Name», «Driver Second Name», «Car type», «Cargo name», «Cargo Size», «Cargo type», «measure», «Rout length», «Rate», «driver town», «driver street», «driver building», «driver room») as select c1." trNum", c1." TrDate", c1." TrCustomer", c1." TrPaymentType", c1." Cargo", c1." Route", c1." carLicenseNum", c2." CarModel", c1." Driver", c3." EmpFName", c3." EmpSName", c2." CarTipe", c4." CrName", c4." CrSize", c4." CrTipe", c4." Measure", c5." RtLength", c5." RtRate", c3." EmpTown", c3." EmpStreet", c3." EmpBuilding", c3." EmpRoom" from «Transporting» c1, «Car» c2, «Employee» c3, «Cargo» c4, «Route» c5 with check option;

go

create view «Chief engineer» («Repair number», «Repair date», «Repaire description», «Mechanic number», «Name», «Second name», «date of birs», «date of employment», «Garage», «car license number», «car model», «car type», «car date of manufactures», «car milage», «car fuel per 100 km», «driver») as

select c1." rpNum", c1." RepDate", c1." RepDescription", c1." Mechanic", c2." EmpFName", c2." EmpSName", c2." EmpDoB", c2." EmpDateOfEmployment", c3." MhGarageNum", c1." carLicenseNum", c4." CarModel", c4." CarTipe", c4." CarDoM", c4." CarMileage", c4." CarFuelPer100km", c4." Driver"

from «Repair» c1, «Employee» c2, «Mechanic» c3, «Car» c4 with check option ;

go

3.6 Обговорення розроблених логічних моделей даних з кінцевими користувачами

На цьому етапі виконується остаточна перевірка локальної логічної моделі даних, здійснювана за допомогою обговорення її з користувачами. Основним об'єктом обговорення для розроблювачів і користувачів є ER-діаграма. Однак не менш важливо, щоб користувачі уважно ознайомилися із супровідною документацією. Якщо в моделі або документації буде знайдена будь-яка невідповідність, усі необхідні етапи повинні бути пройдені ще раз.

Розділ 4. Створення і перевірка глобальної логічної моделі даних

На цьому етапі відбувається створення і перевірка глобальної логічної моделі даних. Глобальна модель створюється шляхом злиття локальних логічних моделей для представлення користувача Диспетчер та Головний інженер. Глобальна логічна модель даних повинна відбивати особливості представлень обох користувачів

Але оскільки ця модель ще на початковому етапі поєднувала представлення Диспетчер та Головний інженер, тому вона вже є глобальною.

4.1 Злиття локальних логічних моделей даних у єдину глобальну модель даних

Створюємо глобальне представлення для всієї моделі «Автотранспортне підприємство», тобто ми поєднаємо дві локальні логічні моделі даних з метою створення глобальної логічної моделі даних.

Злиття загальних сутностей з окремих локальних моделей Виконується перевірка імен і вмісту кожної сутності в обох представленнях. Зокрема, для ідентифікації еквівалентних сутностей з різними іменами варто проаналізувати їхні первинні ключі. Виконання даного етапу включає наступні дії:

· злиття сутностей з однаковими іменами й однаковими первинними ключами;

· злиття сутностей з однаковими іменами, що мають різні первинні ключі;

· злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.

· Злиття сутностей з однаковими іменами й однаковими первинними ключами.

Сутності, що мають в обох представленнях той самий первинний ключ, як правило, представляють ту саму концепцію реального світу. Ідентифікація й об'єднання подібних пар являє собою відносно нескладну задачу.

4.2 Перевірка глобальної логічної моделі даних

Хоча локальні логічні моделі даних представлень Диспетчер та Головний інженер були перевірені ще до виконання процедури їх злиття в глобальну логічну модель даних, існує імовірність того, що при виконанні цієї процедури в глобальну модель даних були внесені нові помилки. Треба перевірити створену глобальну логічну модель даних на відповідність вимогам нормалізації і проконтролювати можливість виконання всіх необхідних транзакцій.

4.3 Перевірка можливостей розширення моделі в майбутньому

Дуже важливо, щоб створена глобальна логічна модель даних допускала можливість її розширення в майбутньому при зміні вимог користувачів. Існуюче глобальне представлення повинне допускати внесення необхідних доповнень, що відбивають подібні зміни в діяльності фірми.

4.4 Створення остаточного варіанта діаграми «сутність — зв’язок»

У нашій базі даних не треба було вносити змін або доповнень у вихідний варіант ER-діаграми. Цей варіант діаграми є остаточною версією логічного глобального представлення предметної області «Автотранспортне підприємство».

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

Висновок

концептуальний база домен скрипт

Таким чином, під час виконання курсової роботи я закріпив свої теоретичні знання про проектування баз даних.

Я навчився:

· Проектувати концептуальні моделі бази даних, а саме: визначати сутності, зв’язки між ними, атрибути сутностей, їх домени.

· Проектувати логічні моделі бази даних, а саме: на основі концептуальної моделі створювати відношення, визначати потенційні (первинні та альтернативні) і зовнішні ключі.

· Створювати зовнішні представлення бази даних для різних користувачів.

У ході виконання курсової роботи я за допомогою програми Microsoft Visio, створив ORM source model та Database model diagram для бази даних «Автотранспортне підприємство», а також згенерував ddl-скрипт, за допомогою якого можна необхідну базу даних в СУБД SQL-Server.

Література

1. Visio-Based Database Modeling in Visual Studio .NET Enterprise Architect: Part 3 [an electronic resource] URL: http://msdn.microsoft.com/en-us/library/aa290382(v=VS.71).aspx (date of treatment: 11.25.2011)

2. Методичні вказівки до виконання курсової роботи з дисципліни «Проектування баз даних» «Концептуальне, логічне та фізичне проектування навчальної бази даних». Укладач: канд. техн. наук, доцент Крещенко Л. Ф. Полтава: ПолтНТУ, 2003 р. — 54с.

3. Борис Леонтьев. MS Office Visio 2003 не для дилетантов. Построение проектов, диаграмм и бизнес-схем в операционной системе MS Windows XP. М: Новый Издательский Дом, 2005 г. — 384с.

4. Якушев Д. М. IT-проектирование в программе Microsoft Visio 2002 Professional. М: Познавательная книга Прес, 2004 г. — 384с.