26. Локальні інфологічні моделі.

5.10. Локальні інфологічні моделі

Коли проектуємо локальні інфологічні моделі, то вони не повинні бути зв'язаними графами. Наприклад інфологічна модель для студента (рис. 5.18.) не пов'язана з інфологічною моделлю для бухгалтерії (рис. 5.19.).

Рис. 5.18. Інфологічна модель для студента

Рис. 5.19. Інфологічна модель для бухгалтерії

27. Побудова глобальної інфологічної моделі.

5.11. Побудова глобальної інфологічної моделі

Так як робота над проектом ІС ведеться по функціональним підсистемам і багатьма розробниками одночасно, то в результаті аналізу та проектування виходить множина локальних інфологічних моделей (ЛІМ), призначених для забезпечення вирішення завдань конкретного користувача. Кожна ЛІМ є проекцією загальної глобальної інфологічної моделі, яка доступна повністю тільки адміністратору бази даних. Тому потрібно узгодити ЛІМ і провести збірку глобальної моделі.

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

• оскільки локальні моделі розроблялися автономно, то після семантичного (смислового) аналізу необхідно усунути синоніми і омоніми шляхом перейменування атрибутів, зв'язків і сутностей;

• більш загальне уявлення поглинає менш загальне. Наприклад, в одній ЛІМ «начальник відділу» може існувати як атрибут сутності «відділ», а в іншій ЛІМ як екземпляр сутності «співробітник». В цьому випадку атрибут видаляється та встановлюється зв'язок «бути начальником» між сутностями «відділ» та «співробітник»;

• два локальних подання однієї і тієї ж сутності в глобальній моделі об'єднуються зі збереженням повної множини атрибутів. Так уявлення сутності «студент» для деканату та поліклініки відрізняються. У глобальній моделі, природно буде одна сутність «студент» з повним набором атрибутів;

• усуваються композиції зв'язків, які виникли в результаті об'єднання;

• узагальнюються обмеження цілісності та бізнес-правила;

• проводиться нормалізація глобальної моделі;

• коригуються локальні моделі відповідно до глобальної.

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

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

Отже, проектувальники баз даних повинні пам'ятати:

• ІС «живуть» довго і коштують дорого;

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

• як правило, база даних є інформаційною основою не одного, а декількох додатків, тому як користувач так і програміст бачить тільки проекцію БД (частина слона!). І не повинен виступати в ролі ескімоса, який складає інструкцію для жителів Африки;

• поганий проект бази даних не може бути виправлений за допомогою будь-яких (навіть самих витончених) додатків;

• чітко розмежовувати такі поняття як структурування даних, маніпулювання даними (введення, зміна та видалення) і адміністрування даних.