Розробка моделей даних

В цьому розділі студент розробляє логічну та фізичну моделі предметної області.

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

Для прискорення процесу краще створити початковий набір таблиць по принципу “Один факт зберігається в одному місці”. Для цього треба виділити основні об’єкти предметної області та розмістити їх властивості як атрибути по різним таблицям. Можна кожному вхідному первинному обліковому документу поставити в відповідність одну таблицю. Але треба пам’ятати, що документ зі звичайним “паперовими” таблицями розбивається по принципу: документ – одна таблиця, одна “паперова” таблиця – одна сутність сутності. Наприклад, накладна на товар – це дві сутності (“Накладна” та “Матеріали за накладною”).

Кількість сутностей у моделі залежить від предметної області, але повинна бути не менше 10.

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

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

У підрозділі наводиться опис структури та довжини кодів. Рекомендується навести рисунки для пояснення структур або схем кодових позначень, а у додатку навести витяги з потрібних класифікаторів на 1 сторінку. Студент може виділити підрозділ “Опис систем класифікації та кодування”

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

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

Таблиця 3.1 Сутності моделі “_____________”

№	Сутність	Опис
1	Співробітники	Інформація про співробітників підприємства
2	…	……...

Сутності у табл. 3.1 можна поділити на оперативні та довідкові. Для кожної сутності треба описати її атрибути. Це можна зробити у вигляді таблиці виду табл. 3.2.

Таблиця 3.2 Атрибути сутностей моделі

№	Сутність	Атрибути
1	Співробітники	Ідентифікаційний номер, прізвище, ім’я, по-батькові,....
2	…	……...

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

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

Таблиці 3.1–3.2 можна замінити звичайним текстом, описуючи кожну сутність окремо, або використати мову інфологічного моделювання.

Логічна модель БД будується за допомогою того програмного CASE–пакету візуального моделювання, який погоджено з керівником проекту та консультантом. Дипломник повинен на 1-2 сторінках записки обґрунтувати вибір засобу розробки моделі даних з врахуванням СУБД.

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

• часткові залежності неключових полів від ключа;

• транзитивні залежності неключових полів від ключа;

• багатозначні залежності.

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

Треба пам’ятати, що ціль логічного моделювання – це таблиці у нормальних формах вищого порядку. Разом з тим, використання БКНФ може привести до значного збільшення кількості таблиць у моделі та появи додаткових зв’язків типу 1:1. Тому студент може обґрунтувати та провести незначну денормалізацію моделі.

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

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

Опис характеру в'язків у БД та умови цілісності даних можна навести у виді табл. 3.3.

Таблиця 3.3 Зв'язки між таблицями

Батьківська таблиця		Дочірня таблиця		Зв'язок
				Тип		Відновлення	Видалення
Назва	Індекс	Назва	Індекс

Логічна модель наводиться у вигляді рисунку.

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

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

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

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

Таблиця 3.4 Структура таблиці “Співробітники”

№	Ім'я поля	Тип	Розмір	Довжина, б
Всього

По тексту записки рекомендується навести описання двох–трьох основних зв’язаних таблиць, інші описання треба винести до додатку.

В записці наводиться рисунок фізичної моделі. Далі фізична модель використовується для генерації машинної БД у середовищі заданої СУБД. Фрагмент SQL–програми створення БД (2 сторінки) необхідно навести у додатку до записки.

Реалізація бази даних

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

Таблиця 3.5 Основні властивості полів таблиці “Співробітники”

Поле	Підпис	Маска вводу	………......	Індексоване поле
Код_робіт ника	Код робітника
........

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

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

Студент може змінювати вид опису результатів розробки БД. Таблиці 3.4–3.5 рекомендується об'єднати в одну для кожної інформаційної таблиці БД. При цьому окремо позначаються властивості, що визначені на стадії фізичної моделі, і властивості, що визначені на стадії реалізації БД. Для більшої наочності таблиці треба наводити у “альбомній” орієнтації.

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

Для наочності обов'язково наводиться екранна форма конструктору БД, яка реалізована в проекті. Тільки на цьому рисунку додатково вказуються типи та розміри полів.

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

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

Таблиця 3.6 Перелік об’єктів БД

№ пп	Ім'я об’єкту	Призначення об’єкту
Представлення
1	зСпівробітники	формування ПІБ співробітників
Вбудовані процедури
	ri_Insert1	підтримка цілісності даних при додаванні нового запису

Студент повинен у записці навести опис найбільш важливих об’єктів і навести SQL–команду або текст процедур, а також результати виконання.

Якщо для одержання якого-небудь запиту або представлення використовувалися інші об’єктів, то варто в додатку навести весь каскад SQL–інструкцій. Рекомендується зробити рисунок взаємодії об’єктів БД.

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

Організація збору та обробки інформації

В цьому підрозділі необхідно провести розрахунок об'єму необхідної дискової пам'яті. Цей розрахунок проводиться на термін використання БД (п’ять років). Розрахунок можна звести в таблицю виду табл. 3.7

Таблиця 3.7 Розрахунок об'єму БД

Назва таблиці	Об'єм заголовку	Об'єм 1-го запису	Кількість записів	Об'єм записів	Загальний об'єм
Усього

При розрахунках треба оцінити можливий обсяг всіх інших файлів БД (системних файлів, індексів та ін.).