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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ORM-діаграма, що представляє локальну концептуальну модель даних для програми «Автотранспортне підприємство», була показана в додатку 1. При виконанні етапу 2.1 ця модель не змінилася.

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

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` (

alter table `Transporting`

add constraint `Route_Transporting_FK1` foreign key (

`Route`)

references `Route` (

alter table `Transporting`

add constraint `Cargo_Transporting_FK1` foreign key (

`Cargo`)

references `Cargo` (

alter table `Transporting`

add constraint `Car_Transporting_FK1` foreign key (

`Driver work onemployee empNum`,

`Car`)

references `Car` (

`Driver`,

alter table `Repair`

add constraint `Car_Repair_FK1` foreign key (

`Mechanic`,

`Car`)

references `Car` (

`Driver`,

alter table `Repair`

add constraint `Mechanic_Repair_FK1` foreign key (

`Mechanic`)

references `Mechanic` (

alter table `Mechanic`

add constraint `Employee_Mechanic_FK1` foreign key (

`empNum`)

references `Employee` (

alter table `Foreman`

add constraint `Employee_Foreman_FK1` foreign key (

`empNum`)

references `Employee` (

alter table `Driver`

add constraint `Team_Driver_FK1` foreign key (

`empNum`,

`Team`)

references `Team` (

`Foreman`,

alter table `Driver`

add constraint `Employee_Driver_FK1` foreign key (

`empNum`)

references `Employee` (

alter table `Cargo`

add constraint `Measure_Cargo_FK1` foreign key (

`Measure`)

references `Measure` (

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;

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;

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 с.

Размещено на Allbest.ru