Тема 2.2. Методика проектування реляційної бази даних на прикладі предметної області “Управління технічною службою“.

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

Методика використовує для опису даних предметної області інформаційні об'єкти й зв'язки між ними. Сукупність реквізитів стосовно інформаційного об'єкта повинна відповідати вимогам нормалізації: інформаційний об'єкт повинен включати унікальний ідентифікатор (ключ); ключ може бути простим, якщо він складається з одного ключового реквізиту, або складовим, якщо – із декількох; усі описові реквізити повинні бути взаємонезалежними; кожний описовий реквізит повинен функціонально залежати від ключа; кожний описовий реквізит не може залежати від ключа транзитивно, тобто через другий проміжний реквізит. Якщо існує транзитивна залежність між реквізитами, необхідно розділяти сукупність реквізитів з утворенням двох інформаційних об'єктів замість одного.

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

Правила виділення інформаційних об'єктів:

• на основі аналізу визначити документи предметної області, які слід зберігати у базі даних;

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

• вибрати всі залежні реквізити і вказати для кожного всі його ключові реквізити;

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

Сукупність виділених інформаційних об'єктів дозволяє отримати інформаційно-логічну модель реляційної бази даних ПО, яка відповідає вимогам нормалізації. Методика, що пропонується, являє собою послідовність робіт по створенню проекту реляційної бази даних ПО. Роботи поділяються на 3 етапи:

Етап 1. Виділення інформаційних об'єктів ПО.

1.1.Встановлення функціональної залежності реквізитів документів ПО.

1.2 Розподіл реквізитів документів на ключові і описові.

1.3 Визначення складу інформаційних об'єктів.

Етап 2. Побудова канонічної ІЛМ ПО.

2.1. Установлення структурних зв'язків між інформаційними об'єктами (ІО).

2.2. Побудова ІЛМ ПО в канонічній формі.

Етап 3. Створення проекту БД ПО МПТС.

3.1. Побудова логічної моделі реляційної БД ПО.

3.2. Створення макетів БД.

Метою етапу 1.1 є встановлення функціональної залежності реквізитів кожного документа. При цьому виділяються ключові реквізити, призначені для ідентифікації екземпляра документа. Усі інші реквізити будуть називатися описовими. Виконання етапу 1.1 відображується в таблиці 2.1

При створенні табл.2.1 у колонку 2 заносяться назви документів ПО. В колонці 3 послідовно наведені всі реквізити - ознаки кожного документа. В колонці 4 кожному реквізиту надається ідентифікатор. Він утворюється як сукупність символів, взятих із слів, що описують реквізит-ознаку. Перший символ слова пишеться з великої літери. В колонці 5 показана функціональна залежність реквізитів документа. Ключові реквізити, що ідентифікують або екземпляр документа або рядок таблиці, яку може містити документ, позначаються стрілками, що направлені праворуч. Описові реквізити позначаються стрілками, що направлені ліворуч. Зв'язок між реквізитами відображується у вигляді вертикальної лінії.

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

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

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

В колонку 1 табл.2.2 заноситься назва документа. В колонці 2 перелічуються всі ідентифікатори описових реквізитів документів, що підлягають включенню в табл. 2.2 із урахуванням вищезгаданих правил відбору описових реквізитів. В колонку 3 стосовно кожного описового реквізиту заносяться його ключові реквізити. Слід пам'ятати, що до ключових реквізитів табличної частини документа додаються ключові реквізити, що ідентифікують сам документ. В колонці 4 вказуються важливіші ознаки ключових реквізитів. При заповненні колонки необхідно враховувати такі властивості ключових реквізитів як унікальність (у). простота (п), складність (с) і вторинність (в). Унікальним є ключ, значення якого не повторюються серед екземплярів ІО. Простим є ключ, що утворюється одним реквізитом. Складним є ключ, що утворюється двома або більше реквізитами. Вторинність ключа – це властивість, яка вказує, що ключ є підлеглим до головного. В колонці 5 приводиться ідентифікатор ІО, який містить описовий реквізит.

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

Метою етапу 2.1 є формалізоване представлення предметної області у вигляді графічного зображення ІО і структурних зв'язків між ними (Рис.2.5), що зветься інформаційно-логічною моделлю предметної області (ІЛМ ПО).

Метою етапу 2.2 є побудова ІЛМ ПО у канонічній формі. Канонічна форма ІЛМ ПО застосовується для відображення ієрархічної підлеглості ІЛМ ПО. При цьому дозволяються зв'язки типів 1:1, 1:М. У кожній зв'язаній парі ІО головний ІО розміщується на більш високому рівні ніж підлеглий ІО. Для упорядкування розміщення ІО стосовно рівнів використовується їх розміщення з урахуванням індексів ІО. Індекс любого ІО можна визначити, якщо підрахувати кількість зв'язків, що мають місце у найбільшому по довжині шляху од верхнього рівня до даного ІО. На Рис.2.6 представлена ІЛМ ПО у канонічній формі.

Метою виконання етапу 3.1 є створення на основі ІЛМ ПО логічної моделі реляційної бази даних предметної області (Рис.2.7), яка відображує на папері схему зв'язків між ключовими реквізитами ІО і яка максимально наближена до діалогового вікна “Схема даних” СУБД Access. Слід відмітити, що взаємне розташування ІО на схемі повинно бути таким, щоб пересічення зв'язків було найменшим. Ключові реквізити на схемі відмічаються зірочками (*).

Метою етапу 3.2 є створення макетів об'єктів Access “Таблиця” для кожного з ІО, представлених у табл.2.3. Приклад створення макету стосовно ІО “КласМарка” приведено в табл.2.4. Для заповнення колонок 2, 3 таблиці використовуємо дані табл.1. В колонці 4 вказуємо тип даних реквізиту.

Можливі такі типи даних: символьний (текстовий), чисельний, дата, логічний, мемо, лічильник і OLE. Тип мемо застосовується для текстових даних невизначеної довжини. Тип OLE застосовується для даних графічного типу. Тип даних Лічильник застосовується для реквізитів, що відображують порядковий номер. В колонці 5 вказуємо максимальний розмір реквізиту у знаках (байтах). В колонці 6 для чисельних реквізитів указується кількість розрядів для десяткової частини. В колонці 7 вказуємо найменування реквізиту для відображення його у назві колонки таблиці, представленої у вигляді відеограми або табуляграми. Дані для колонок 8,9 вибираємо дані із таблиці 2. Якщо реквізит у таблиці 2 помічено як ключовий, то в колонку 8 заносимо так. Якщо в таблиці 2 реквізит помічено як простий ключовий, то в колонку 9 заносимо так. В усіх інших випадках у колонки 8,9 заносимо ні. В колонку 10 заносимо так, якщо реквізит обов'язково повинен мати значення. В колонку 11 заноситься маска вводу, яка застосовується при вводі реквізитів типу телефонний номер, номер паспорта та ін. В колонці 12 приводяться умови для перевірки правильності вводу реквізитів.

Реалізація методики буде провадитися на основі декількох документів ПО “Технічна служба АТП”, а саме: Класифікатор марок автомобілів, Класифікатор груп деталей автомобілів (Додаток 1, рис1.1, 1.14). Більш повний перелік документів ПО “Технічна служба АТП” представлений у Додатку 1, рис.1.1÷1.14.

Таблиця 2.1

Функціональна залежність реквізитів документів ПО.

№ пп	Назва документа	Найменування реквізита	Ідентифі- катор	Функціональ-на залежність реквізитів
1	2	3	4	5
1	Класифікатор марок автомоб	Код марки автомобіля Назва марки автомоб.	КМарка НМарка
2	Класифікатор груп деталей марок автомобілів	Код марки автомобіля Код групи деталей Назвагрупи деталей	КМарка КГруп НГруп

Таблиця 2.2.

Відповідність ключових і описових реквізитів документів.

Назва документа	Ідентифікатор описового реквізиту	Ідентифікатори ключових реквізитів	Вид ключа	Ідентифікатор інформацій-ного об'єкту
1	2	3	4	5
Класиф. марок авт	НМарка	КМарка	п,у	КласМарка
Класиф. груп авт.	НГруп	КМарка+КГруп	с,у,в	КласГруп

Таблиця 2.3.

Реквізитний склад ІО.

Ідентифікатор реквізиту	Ознаки ключа	Ідентифі- катор ІО	Назва ІО	Опис ІО
1	2	3	4	5
КМарка_____ НМарка	П,У	КласМарка	Класифіка-тор марок автомобілів	Містить дані про назви марок автомобілів та їх коди
КМарка КГруп______ НГруп	С,У,В	КласГруп	Класифіка-тор груп марок автомобілів	Містить дані про назви й коди груп (агрегатів і систем) та коди марок автомобілів

Таблиця 2.4

Макет інформаційного об'єкта “КласМарка” (Класифікатор марок).

№ пп	Найменування реквізиту	Ідентифікатор	Тип даних	Розмір	Кільк. дес.зн.
1	2	3	4	5	6
1	Код марка	КМарка	Текст	2
2	Назва марки	НМарка	Текст	20

продовження табл. 2.4.

Підпис	Зв'язок		Обов. поле	Маска вводу	Умова на значення
	Ключове поле	Унікальне поле
7	8	9	10	11	12
Код марки	да	да	да
Марка	ні	ні	да

Література : [1] с.448-457, 505-518, [2] с.35-49, [3], [6]

Розділ 3. Фізична модель предметної області і її використання у Access