3.2. Проектування баз даних
Створення і впровадження в практику сучасних ІС АБД висуває нові завдання проектування, які неможливо вирішувати традиційними прийомами і методами. Велику увагу необхідно приділяти питанням проектування БД. Від того, наскільки успішно буде спроектована БД, залежить ефективність функціонування системи в цілому, її життєздатність і можливість розширення і подальшого розвитку. Тому питання проектування БД виділяють як окремий, самостійний напрям робіт при розробці ІС.
Проектування БД – це ітераційний, багатоетапний процес ухвалення обгрунтованих рішень в процесі аналізування інформаційної моделі ПрО, вимог до даних з боку прикладних програмістів і користувачів, синтезування логічних і фізичних структур даних, аналізування і обгрунтування вибору програмних і апаратних засобів. Етапи проектування БД пов'язані з багаторівневою організацією даних. Розглядаючи питання проектування баз даних, дотримуватимемося такого багаторівневого представлення даних: зовнішнього, інфологічного, логічного (даталогічного), внутрішнього.
Таке представлення рівнів даних не єдине. Існують й інші варіанти багаторівневого представлення даних. Так, відповідно до пропозицій дослідницької групи по системах управління даними Американського національного інституту стандартів ANSI/X3/SPARC, а також CODASYL (Conference on Data Systems Languages), як правило, виділяються три рівні представлення даних:
зовнішній (з погляду кінцевого користувача і прикладного програміста);
концептуальний (з погляду СУБД);
внутрішній (з погляду системного програміста).
Відповідно до цієї концепції зовнішній рівень – це частина (підмножинність) концептуальної моделі, необхідна для реалізації якого-небудь запиту або прикладної програми. Тобто, якщо концептуальна модель виступає як схема, підтримувана конкретною СУБД, то зовнішній рівень – це деяка сукупність підсхем, необхідних для реалізації конкретної прикладної програми або запиту користувача.
Існує також інша точка зору, відповідно до якої під зовнішнім рівнем розуміють більш загальні поняття, пов'язані з вивченням і аналізом інформаційних потоків ПрО та їхньою структуризацією. Деякі автори вводять допоміжний рівень, пойменованим “інфологічним”. Він може виступати як самостійний або бути складовою зовнішнього рівня. Така концепція доцільніша з погляду розуміння процесу проектування БД.
Тому розглядатимемо інфологічний рівень як самостійний рівень представлення даних. Зовнішній рівень в цьому разі виступає як окремий етап проектування, на якому вивчається все позамашинне інформаційне забезпечення, тобто форми документування і представлення даних, а також зовнішнє середовище, в якому функціонуватиме БнД з погляду методів фіксації, збирання і передачі інформації в БД.
При проектуванні БД на зовнішньому рівні необхідно вивчити функціонування об'єкта управління, для якого проектується БД; всю первинну і вихідну документацію з погляду визначення того, які саме дані необхідно зберігати в БД. Зовнішній рівень – це як правило, словесний опис вхідних і вихідних повідомлень, а також даних, які доцільно зберігати в БД. Опис зовнішнього рівня не виключає наявність елементів дублювання, надмірності й неузгодженості даних. Тому для усунення цих аномалій і суперечностей зовнішнього опису даних виконується інфологічне проектування. Інфологічна модель є засобом структуризації ПрО і розуміння концепції семантики даних. Інфологічну модель можна розглядати в основному як засіб документування і структуризації форми представлення інформаційних потреб, яка забезпечує несуперечливе спілкування користувачів і розробників системи.
Всі зовнішні уявлення інтегруються на інфологічному рівні, де формується інфологічна (канонічна) модель даних, яка не є простою сумою зовнішніх представлень даних.
Інфологічний рівень є інформаційно-логічною моделлю (ІЛМ) ПрО, з якої виключена надмірність даних та відображені інформаційні особливості об'єкта управління без урахування особливостей і специфіки конкретної СУБД. Тобто інфологічне представлення даних орієнтовано переважно на людину, яка проектує або використовує БД.
Логічний (концептуальний) рівень побудований з урахуванням специфіки і особливостей конкретної СУБД. Цей рівень представлення даних орієнтований більше на комп'ютерну обробку і на програмістів, які займаються її розробкою. На цьому рівні формується концептуальна модель даних, тобто спеціальним способом структурована модель ПрО, яка відповідає особливостям і обмеженням вибраної СУБД. Модель логічного рівня, підтримувану засобами конкретної СУБД, називають ще “даталогічною”.
Інфологічна і даталогічна моделі, які відображають модель однієї ПрО, залежні між собою. Інфологічна модель може легко трансформуватися в даталогічну модель.
Внутрішній рівень пов'язаний з фізичним розміщенням даних в пам'яті ЕОМ. На цьому рівні формується фізична модель БД, яка включає структури зберігання даних в пам'яті ЕОМ, в тому числі опис форматів записів, порядок їх логічного або фізичного приведення в порядок, розміщення за типами пристроїв, а також характеристики і шляху доступу до даних.
Від параметрів фізичної моделі залежать такі характеристики функціонування БД: обсяг пам'яті та час реакції системи. Фізичні параметри БД можна змінювати в процесі її експлуатації з метою підвищення ефективності функціонування системи. Зміна фізичних параметрів не зумовлює необхідності зміни інфологічної і даталогічної моделей.
Схеми взаємозв'язку рівнів представлення даних в БД, зображених на рис. 3.12. Проектування БД – це складний і трудомісткий процес, який вимагає залучення багатьох висококваліфікованих фахівців. Від того, наскільки кваліфіковано спроектована БД, залежать продуктивність ІС і повнота забезпечення функціональних потреб користувачів і прикладних програм. Невдало спроектована БД може ускладнити процес розробки прикладного ПЗ, зумовити необхідність використання складнішої логіки, яка, у свою чергу, збільшить час реакції системи, а надалі може привести до необхідності перепроектування логічної моделі БД. Реструктуризація, або внесення змін в логічну модель БД, це дуже небажаний процес, оскільки він є причиною необхідності модифікації або навіть перепрограмування окремих завдань.
Всі роботи, виконувані на кожному етапі проектування, повинні інтегруватися із словником даних. Кожен етап проектування розглядається як певна послідовність ітеративних процедур, в результаті яких формується певна модель БД.
Рис. 3.12. Схема взаємозв'язку рівнів представлення даних в БД
Зовнішній рівень – підготовчий етап інфологічного проектування. Метою проектування на зовнішньому рівні є розробка позамашинного інформаційного забезпечення, яке включає систему вхідної (первинної) документації, що характеризує певну ПрО, систему класифікації й кодування ТЕІ, а також перелік відповідних вихідних повідомлень, які потрібно формувати за допомогою БнД.
Існують два підходи до проектування БД на зовнішньому рівні: “від предметної області” і “від запиту”. Підхід “від предметної області” полягає в тому, що формується зовнішнє інформаційне забезпечення всієї ПрО без урахування потреб користувачів і прикладних програм. Іноді цей підхід називають “об'єктним” або “непроцесним”.
При підході “від запиту” основним джерелом інформації щодо ПрО є вивчення запитів користувачів і потреб прикладних програм. Цей підхід також має назву “процесний” або “функціональний”. При такому підході БД проектується для виконання поточних завдань управління без урахування можливості розширення системи і виникнення нових завдань управління.
Перевага підходу “від предметної області” – це його об'єктивність, системність при відображенні ПрО і стійкість інформаційної моделі, можливість реалізації великої кількості прикладних програм і запитів, зокрема незапланованих при створенні БД. Недоліком цього підходу є значний обсяг робіт, які необхідно виконати при визначенні інформації. що підлягає зберіганню в БД, що відповідно ускладнює і збільшує термін розробки проекту.
Функціональний підхід орієнтований на реалізацію поточних вимог користувачів і прикладних програм без урахування перспектив розвитку системи. При його використанні можуть виникнути складнощі в агрегації вимог різних користувачів і прикладних програм. Проте, при такому підході значно зменшується трудомісткість проектування, і тому можливо створити систему зіз високими експлуатаційними характеристиками.
Проте узятий окремо будь-який з цих методів не може дати досить інформації для проектування раціональної структури БД. Тому при проектуванні БД доцільно спільно використовувати ці два підходи. Якщо схемно представити процес проектування БД на зовнішньому рівні, то він складається з таких робіт.
1. Визначення функціональних завдань ПрО, які підлягають автоматизованому рішенню. Оскільки основною метою створення БД є забезпечення інформацією функцій обробки даних, то, перш за все, необхідно вивчити всі функції ПрО (об'єкта управління), для якої розробляється БД, і проаналізувати їх особливості. Функції й функціональні особливості об'єкта управління необхідно вивчати в нерозривному зв'язку з вивченням функціональних вимог до даних з боку майбутніх користувачів інформаційної системи. Вивчення і аналізування передбачають виявлення інформаційних потреб і визначення інформаційних потоків. Ці роботи можна виконувати обстеженням ПрО і анкетуванням її співробітників. Результатом такого вивчення може бути перелік функціональних завдань, які повинні вирішуватися автоматизованим способом з використанням БД.
2. Вивчення і аналізування оперативних первинних документів. Вивчивши функції і визначивши перелік функціональних завдань, які підлягають автоматизованому рішенню, переходять до вивчення оперативних документів, використовуваних на вході кожного завдання або їх комплексу. Вивчивши і проаналізувавши всі оперативні документи (як зовнішні, так і внутрішні), використовувані на вході кожного завдання, визначають, які реквізити цих документів потрібно зберігати в БД.
3. Вивчення нормативно-довідкових документів. На третьому кроці вивчають і аналізують всю нормативно-довідкову документацію. До такої документації належать різні класифікатори, кошториси, договори, нормативи, законодавчі акти по податковій політиці, планова документація і т.п. Розподіл і окремий аналіз оперативної і нормативно-довідкової інформації обумовлені технологічно. У БД розрізняються технології створення і ведення файлів умовно-постійної інформації, розміщеної в нормативно-довідковій документації, і файлів оперативної інформації.
4. Вивчення процесів перетворення вхідних повідомлень у вихідні. Перш за все, вивчаються всі вихідні повідомлення, які видаються на друк або на екран і зберігаються у вигляді вихідних масивів. Це необхідно для того, щоб визначити, які з атрибутів вхідних повідомлень потрібно зберігати в БД для отримання вихідних повідомлень. Крім того, на цьому етапі визначаються ті показники, які одержують під час рішення задачі в результаті виконання певних обчислень. По кожному розрахунковому показнику варто визначити алгоритм його формування і переконатися в тому, що цей показник можна одержати на основі атрибутів оперативної і нормативно-довідкової інформації, визначених на другому і третьому кроках. Якщо певних даних не вистачає для повного виконання розрахунків, необхідно повернутися назад, провести додаткове дослідження і визначити, де і яким способом можна одержати атрибути, яких не вистачає.
Крім того, потрібно визначитися, які з розрахункових показників доцільно зберігати в БД. Показники, одержані розрахунковим шляхом, як правило, в БД не зберігаються. Вийнятком є випадки, коли розрахунковий показник потрібно використовувати для вирішення інших завдань або для даного завдання, але в наступні календарні періоди.
При проведенні проектних робіт на зовнішньому рівні треба враховувати те, що для виконання певних функцій в БД необхідно зберігати додаткові дані, які не відображені в документах (дані календаря, статистичні дані й т.п.). Узагальнена схема процесу вивчення документів і даних при проектуванні на зовнішньому рівні зображена на рис. 3.13. Таке вивчення необхідно провести по кожному функціональному завданню або їх комплексу, які вирішуватимуться за допомогою БД.
Рис. 3.13. Узагальнена схема процесу проектування на зовнішньому рівні
Результатом проектування на зовнішньому рівні буде перелік атрибутів (реквізитів) оперативної і умовно-постійної інформації, які необхідно зберігати в БД, з вказівкою джерел їх отримання і форми уявлення. Проте цей перелік не виключає можливості існування в ньому надмірності, дублювання, неузгодженості та інших недоліків. Тому на цьому процес не закінчується, а здійснюється перехід до етапу інфологічного проектування.
Основними складовими елементами інфологічної моделі є суть (інформаційні об'єкти), зв'язки між ними та їх атрибути (властивості).
Суть – будь-який помітний об'єкт (об'єкт, який можна відрізнити від іншого), інформацію про який необхідно зберігати в БД. Суттю можуть бути люди, місця, літаки, рейси, смак, колір і т.д. Необхідно розрізняти такі поняття, як тип суті й екземпляр суті. Поняття “тип суті” відноситься до набору однорідних осіб, предметів, подій або ідей, виступаючих як ціле. “Екземпляр суті” відноситься до конкретного об’єкта в наборі. Наприклад, типом суті може бути МІСТО, а екземпляром – Москва, Київ і т.д.
Атрибут – пойменована характеристика суті. Його найменування повинне бути унікальним для конкретного типу суті, але може бути однаковим для різного типа суті (наприклад, КОЛІР може бути визначений для деякої суті: СОБАКА, АВТОМОБІЛЬ, ДІМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про суть. Прикладами атрибутів для суті АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР і т.п. Тут також існує відмінність між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів або значень: Червоний, Синій, Банановий, Біла ніч і т.д., проте кожному екземпляру суті привласнюється тільки одне значення атрибута.
Абсолютна відмінність між типами суті й атрибутами відсутня. Атрибут є таким тільки у контексті з типом суті. У іншому контексті атрибут може виступати як самостійна суть. Наприклад, для автомобільного заводу колір – це тільки атрибут продукту виробництва, а для лакофарбної фабрики колір – тип суті.
Ключ – мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр суті. Мінімальність означає, що виключення з набору будь-якого атрибуту не дозволяє ідентифікувати суть по тих, що залишилися. Для суті Розклад ключем є атрибута Номер_рейса або набір: Пункт_відправлення, Час_вильоту і Пункт_призначення (за умови, що з пункту до пункту вилітає в кожен момент часу один літак).
Зв'язок – асоціювання двох або більш сутностей. Якби призначенням БД було тільки зберігання окремих, не зв'язаних між собою даних, то її структура могла б бути дуже простою. Проте одною з основних вимог до організації БД є забезпечення можливості відшукання однієї суті за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А оскільки в реальних БД нерідко містяться сотні або навіть тисячі суті, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність інфологічних моделей.
Метою інфологічного проектування є створення структурованої інформаційної моделі ПЗ, для якої розроблятиметься БД. При проектуванні на інфологічному рівні створюється інформаційно-логічна модель (ІЛМ), яка повинна відповідати таким вимогам:
забезпечення найбільш природних для людини способів збору і представлення тієї інформації, яку передбачається зберігати в створюваній БД;
коректність схеми БД, тобто адекватне відображення модельованої ПрО;
простота і зручність використання на наступних етапах проектування, тобто може легко відображатися на моделі БД, підтримуваних відомими СУБД (мережеві, ієрархічні, реляційні й ін.).
Інформаційно-логічна модель повинна бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам.
Суть інфологічного моделювання полягає у виділенні суті (інформаційних об'єктів ПрО), яка підлягає зберіганню в БД, а також у визначенні характеристик (атрибутів) об'єктів і взаємозв'язків між ними.
Існує два підходи до інфологічного проектування: аналізування об'єктів і синтезування атрибутів. Підхід, базований на аналізуванні об'єктів, називається низхідним, а на синтезуванні атрибутів – висхідним.