Проектування РБД

УТ Зарплата працівників

Ід номер Прізвище Ім'я По батькові Стать

Дата народження Вік Адреса Фотографія

Характеристика Таб номер Дата прийому Дата звільнення Стаж роботи Підрозділ Посада Оклад

Дата призначення Ставка Рік Місяць

Нараховано за окладом % премії Премія

Нараховано (за місяць) Квартал Нараховано (за квартал) Півріччя

Нараховано (за півріччя) Нараховано (за рікл)

Рисунок 7.1 – Універсальна таблиця

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

Таким чином, до складового ключа УТ включені такі поля: Ід номер, Таб номер, Підрозділ, Посада, Оклад, Рік, Місяць

Після визначення ключа можна вважати, що УТ переведена до 1НФ. Для наочності рекомендується позначити ключові поля в УТ.

Далі визначимо ФЗ між полями в УТ.

Значення деяких полів можуть бути обчислені за формулами по значенням інших полів. Наведемо ці формули.

При цьому у правій частині формул назви полів візьмемо у квадратні дужки. Знак = (дорівнює) замінимо двокрапкою.

66

Нараховано: [Оклад]*[Ставка]*(100+[% премії])/100

Запишемо ці залежності як ФЗ: Дата народження → Вік

Дата прийому, Дата звільнення → Стаж Оклад,Ставка → Нараховано за окладом Нараховано за окладом,% премії → Премія

Нараховано за окладом, Премія → Нараховано (за місяць) Місяць → Квартал → Півріччя Нараховано (за місяць) → … → Нараховано (за рік)

Для наочності рекомендується показати всі ФЗ графічно.

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

В результаті отримаємо тЗарплата працівників (рис. 7.2) тЗарплата працівників

*Ід номер Прізвище Ім'я По батькові Стать

Дата народження Адреса Фотографія Характеристика *Таб номер Дата прийому Дата звільнення *Підрозділ *Посада *Оклад

Дата призначення Ставка *Рік *Місяць % премії

Рисунок 7.2 – УТ в 1НФ без ФЗ

67

Аналіз показує, що в цій таблиці за полем Ід номер, яке є частиною ключа, ми можемо точно вказати значення більшості інших полів, а саме:

*Ід номер → Прізвище *Ід номер → Ім'я

. . .

*Ід номер → Дата звільнення Крім того, існує ФЗ

*Ід номер, *Таб номер,*Підрозділ,*Посада,*Оклад,*Рік,*Місяць → % премії Виконаємо перший крок нормалізації. Розіб’ємо УТ на дві таблиці:

1)тПрацівники;

2)тЗарплата.

Процес проектування будемо ілюструвати за допомогою діаграм “Таблицізвязки”. Діаграма для двох таблиць показана на рис. 7.3.

Рисунок 7.3– ЛМД (дві таблиці)

Для підтримки цілісності даних за посиланнями визначимо зв’язок. Проаналізуємо цей варіант ЛМД. Таблиця тПрацівники знаходиться в

3НФ, бо вона має простий ключ.

В тЗарплата існує ФЗ від ключа *Ід номер, *Таб номер,*Підрозділ,*Посада,*Оклад,*Рік,*Місяць → % премії.

Але також існують ФЗ від частини ключа виду:

*Ід номер, *Таб номер, *Підрозділ, *Посада, *Оклад → Дата призначення; *Ід номер, *Таб номер, *Підрозділ, *Посада, *Оклад → Ставка.

Таким чином тЗарплата знаходиться в 1НФ. Необхідно виконати крок нормалізації та розбити тЗарплата на дві таблиці.

Додамо до МД тПризначення. Для переводу тЗарплата і тПризначення в 3НФ введемо штучний простий ключ. Існуючі ключі переведемо в звичайні унікальні ключі. Отримаємо МД БД з 3-х таблиць, які знаходяться в 3НФ. Діаграма показана на рис. 7.4.

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

68

Рисунок 7.4 – МД (три таблиці)

Додамо до діаграми МД тШтати. Отримаємо модель МД з 4-х таблиць, які знаходяться в 3НФ. Діаграма МД показана на рис. 7.5

Рисунок 7.5 – Діаграма МД (чотири таблиці)

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

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

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

69

Працівники отримують зарплату щомісячно (за роботу на робочих місцях).

На підприємстві створюються робочі місця.

На основі аналізу опису ПО області можна зразу визначити основні сутності МД:

1)Робочі місця (стрижень);

2)Працівники (стрижень);

3)Зарплата (характеристика).

Працівники працюють на робочих місцях.

Між працівниками і робочими місцями існує БЗ:

–один працівник може працювати на кількох робочих місцях (один термін – на одному місці, другий термін – на іншому, тощо);

–на одному робочому місці можуть працювати кілька працівників (спочатку один термін працює один працівник, потім інший працівник, а можуть і кілька працівників одночасно працювати на одному місці, наприклад, менеджерами).

Цю БЗ необхідно розв’язати через додаткову сутність-асоціацію Робота.

70

Далі кожній сутності ставимо у відповідність таблицю, розподіляємо атрибути сутностей як поля таблиць, вилучаємо ФЗ, вводимо прості ключі і отримуємо таку модель, яка показана на рис. 7.5.

Аналіз цієї МД показує, що тШтати має надмірність даних, яка може призвести до аномалій різних типів. Для розв’язання цієї проблеми введемо в

МД дві довідникові таблиці тПідрозділи та тПосади.

Отримаємо модель МД з 6 таблиць, які знаходяться в 3НФ. Діаграма МД показана на рис. 7.6

Рисунок 7.6 – Діаграма МД (шість таблиць)

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

В результаті отримаємо таку МД, діаграма якої показана на рис. 7.7. Значення, які можуть бути обчислені за формулами, мають бути

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

71

Розглянемо тПрацівники.

Значення полів Дата прийому та Дата звільнення можуть бути розраховані по записам тПризначення. Але ці поля не вилучаються з таблиці для оптимізації БД с метою прискорення обробки даних.

До тПрацівники можуть бути додані поля для зберігання необхідних додаткових анкетних даних, наприклад, адреси, домашнього, робочого та мобільного телефонів, E-mail.

Рисунок 7.7 – Діаграма МД “Зарплата” (сім таблиць)

Для прискорення обробки даних рекомендовано створити тТабНомери_працівників (*Таб номер, Ід номер, Дата прийому, Дата звільнення), яка буде проміжною між тПрацівники та тПризначення.

З метою оптимізації МД при зберіганні кількох характеристик та фотографій можна в МД ввести ще дві таблиці:

тПрацівникиФото (*Код фото, Код працівника, Дата фото, Фотографія); тПрацівникиХарактеристики (*Код характеристики, Код працівника,

Дата_характеристики, Характеристика).

Якщо ми хочемо мати адресу як сукупність кількох полів (поштовий індекс, населений пункт, вулиця, будинок, квартира), то це приведе до введення нових довідникових таблиць, наприклад, тНасПункти, тВулиці.

Таким чином, проводиться подальше розширення ЛМД.

72

8 АВТОМАТИЗАЦІЯ ПРОЦЕСУ ПРОЕКТУВАННЯ МОДЕЛЕЙ ДАНИХ

8.1 Інструментальні засоби розробки моделей даних

Для автоматизації проектування ІС широко застосовують комп’ютерні засоби розробки, які мають назву CASE-засобів (Computer-aided software engineering). Застосування цих візуальних інструментальних програмних пакетів істотно підвищує продуктивність розробників ІС. Більшість з них надають розробникам можливість розробки МД.

Автоматизація процесу проектування МД висуває додаткові вимоги до мови опису МД. Ця мова повинна:

–бути такою, що обчислюється, тобто сприйматися й оброблятися за допомогою засобів обчислювальної техніки;

–використовувати графічні інтерфейси, дружелюбні до користувача;

–бути незалежною від устаткування та інших ресурсів.

Візуальне подання МД, створених за допомогою CASE-засобів, може використовуватися для детального аналізу і уточнення задачі, а також для оформлення документації, необхідної в циклі розробки.

CASE-засоби дозволяють:

–проектувати схеми ЛМД;

–формувати ФМД;

–легко вносити зміни в МД їх розробці та корегуванні;

–автоматично генерувати опис БД на мові багатьох цільових СУБД;

–генерувати БД у середовищі СУБД;

–проводити зворотнє проектування МД по існуючим;

–сінхронізувати МД і БД.

Треба визнати, що концептуальне проектування прямо не реалізовано в жодному пакеті автоматизованого проектування ІС, а МД у виді ER-моделей типу “Таблиці – зв’язки” одержали широке використання.

CASE-засоби будуються на різних методологіях розробки МД, які визначають термінологію і знаки графічного зображення типових елементів на діаграмах.

Найбільш поширена методологія IDEF1X (ICAM Definition Method 1 Extended) дозволяє побудувати МД, близьку до оптимальної. Ця методологія, зокрема, поділяє сутності на дві категорії: незалежні та залежні.

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

ER-діаграми типу IDEF1X (або IDEF1X-діаграми) використовують кілька розповсюджених CASE-засобів, наприклад, пакети AllFusion Erwin Data Modeler (ERwin) фірми Computer Associates International Inc. і Microsoft Visio.

Розглянемо приклади розробки ER-діаграм за допомогою пакету ERwin.

73

8.2 Розробка баз даних за допомогою ERwin 8.2.1 Етапи розробки моделей

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

Діаграма ERwin будується із трьох основних блоків – сутностей, атрибутів і зв'язків. Пакет має багато варіантів відображення моделі залежно від обраного режиму подання діаграми. Режим може змінюватися через пункт основного меню Model або через контекстне меню, яке викликається правою кнопкою миші.

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

Процес створення МД за допомогою Erwin складається з наступних кроків:

1)створення планшету МД;

2)визначення сутностей;

3)визначення залежностей між сутностями;

4)завдання первинних й альтернативних ключів;

5)визначення атрибутів сутностей;

6)приведення моделі до необхідного рівня НФ;

7)перехід до ФМД;

8)генерація БД.

Останні два пункти відносяться до ФМД.

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

8.2.2 Створення планшету моделі

Розробка МД починається зі створення її планшету (бланку діаграми). Спочатку розглянемо процес створення ЛМД. Тому при створенні

планшету виберемо тип Logical (рис. 8.1).

Далі через меню Model→Model Properties уточнимо методологію (нотацію) МД (рис. 8.2).

Для того, щоб задавати імена атрибутів і сутностей російською або українською мовою, треба використовувати відповідні шрифти (Cyr – кирилиця). Вони встановлюються через меню Format → Default Fonts & Colors (рис. 8.3).

Моделі ERwin зберігаються на диску у вигляді файлу з розширенням

*.er1.

74