Рівні представлення моделей даних

Концепція багаторівневого подання бази даних є основою сучасної технології баз даних. Ці ідеї вперше були сформульовані в звіті робочої групи по базах даних Комітету з планування стандартів Американського національного інституту стандартів (АИЗГ / ХЗ / ЗРАЯС), опублікованому в 1975 р У даному звіті була запропонована узагальнена трирівнева модель архітектури бази даних, що включає концептуальний, зовнішній і внутрішній рівні (рис. 1.36).

Концептуальний рівень архітектури АК51 / 5РАЯС служить для підтримки єдиного погляду на структуру бази даних, загальної для всіх додатків, що використовують її, і незалежно від них. Концептуальний рівень являє собою формалізовану інформаційно-логічну модель бази даних.

Внутрішній рівень архітектури АИ81 / 8РАКС визначає підтримку уявлення бази даних в середовищі зберігання. На цьому рівні вона представляється в повністю "матеріалізованих" вигляді.

Зовнішній рівень архітектури АШ1 / 5РА11С призначений для відображення підтримки бази даних на рівні окремих груп користувачів. Описи таких уявлень бази даних називаються зовнішніми схемами. При цьому в системах управління базами даних підтримується декілька зовнішніх схем бази даних для різних груп користувачів або завдань.

Таке уявлення характеризує загальні підходи до реалізації баз даних в процесі їх розробки та реалізації, але розвиток технологій привело до необхідності виділення додаткових архітектурних рівнів подання даних, визначаючи, тим самим, основні правила та концепти проектування і реалізації баз даних (рис. 1.37).

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

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

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

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

З огляду на ці особливості розробки баз даних, аналітичний рівень представлення моделі даних містить три основні моделі, де дані є ключовим елементом: модель потоків даних на основі реалізованих бізнес-процесів, схема документообігу, модель взаємозв'язків об'єктів предметної області. Основну складність при побудові моделей даних на аналітичному рівні викликає необхідність побудови всіх трьох моделей одночасно, розуміючи, що відомості, що відображаються в одній з моделей, враховуються і (або) відображаються в іншої моделі, відповідно до певних правил подання (нотація ^[1] ) .

Розглядаючи подання відомостей про дані на аналітичному рівні, необхідно відштовхуватися від термінології, прийнятої при описі предметної області в бізнес-процесах і документах, а саме: об'єкт, атрибут, функція / процес / завдання, зв'язок, екземпляр об'єкта, класифікатор і т.д. Використовувана термінологія дозволяє, не переходячи на рівень комп'ютерних систем, подати відомості про структури даних і їх характеристиках мовою, зрозумілою функціональним фахівцям ^[2] і фахівцям в області інформаційних технологій.

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

Концептуальний рівень представлення моделі бази даних відображає абстрактне уявлення даних предметної області в структурах, що відображають атрибутивний складу кожного елемента (об'єкта) моделі і особливості зв'язків між ними.

Одним з основних варіантів концептуального представлення моделі бази даних є модель в нотації Пітера Чена, запропонована в 1976 р На той момент це подання давало можливість розробнику вказати всі необхідні компоненти майбутньої бази даних і розглядалося на об'єднаному концептуально-логічному рівні уявлення бази даних.

Для сучасних баз даних, які включають значно більшу кількість елементів структури, ніж це було представлено в 1976 р, модель Пітера Чена може бути віднесена тільки до концептуального рівня, відображаючи основні елементи предметної області з використанням наступної термінології: сутність (об'єкт), зв'язок, атрибут, тип зв'язку, потужність (кардинальність) зв'язку, відносини.

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

Таким чином, термін "Відношення" для моделі Пітера Чена (рис. 1.38) визначає саме особливості зв'язку між сутностями, висловлюючи її дієслівної формою, відповідної діяльності в предметній області. Наприклад, при зв'язуванні сутностей "Учень" і "Дисципліна" встановлюють відношення "Вивчає", ілюструючи предметну сутність взаємодії між учнями і дисциплінами, які вони вивчають.

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

Подання моделі в нотації Пітера Чена є досить громіздким, що не дуже зручно для подальшого аналізу і розгляду моделі бази даних. Тому для логічного і наступних рівнів застосовуються більш прості, з точки зору візуалізації, нотації, як, наприклад, нотація Crow's Foot ^[3] , що застосовується в більшості інструментальних засобів ^[4] моделювання бази даних

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

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

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

Переходячи з логічного на даталогіческого рівень, розробник бази даних змінює використовувану термінологію, а саме: від терміна "Сутність" виконується перехід до терміну "Таблиця", від терміна "Атрибут" - до терміну "Поле" ( "Колонка") і т.д . Цей перехід зумовлений необхідністю розглядати модель в термінах СУБД, яка працює на фізичному рівні.

При переході до даталогіческого рівню розробнику бази даних необхідно прийняти базові правила визначення простору імен, які будуть застосовуватися в базі даних. Це простір імен відображає основні вимоги до того, як будуть іменуватися окремі об'єкти бази даних (табл. 1.10).

Такий опис простору імен дозволить стандартизувати найменування об'єктів бази даних і однозначно інтерпретувати використовувані імена при написанні програмних кодів обробки і вибірки даних.

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

• • таблиці і поля, що позначають поділ даних на атомарні відомості і групуються в нерозривні за функціональною ознакою сукупності полів;
• • типи даних, які визначають основні правила подання та обробки збережених в полях даних, враховуючи особливості роботи СУБД;
• • обмеження на значення полів, що подаються у вигляді логічних виразів і використовуються в СУБД при визначенні можливості збереження відповідного значення в потрібному полі таблиці;
• • умовчання, які задаються, якщо командою доданий або змінений надано значення для збереження в поле таблиці;
• • поле первинного ключа, відповідне атрибутам первинних ключів логічної моделі бази даних, але накладає правила обмежень на фізичному рівні по можливості внесення відповідних значень в цьому полі;
• • поле зовнішнього ключа, відповідне атрибутам зовнішніх ключів логічної моделі бази даних, але також, як для нуля первинного ключа, що накладають особливі обмеження на зберігання в ньому відповідних значень;
• • формули обчислення значення, що використовуються для обчислюваних полів, де для математичного або лінгвістичного обчислення застосовуються значення полів тієї ж таблиці і записи, в яких використовується дане поле;
• • правила посилальної цілісності ^[5] , що визначають можливі дії (Restrict, Cascade, Set NULL, Set default, No action і ін.) При виконанні операцій модифікації даних (додавання, зміна, видалення).

Оскільки сучасні засоби моделювання бази даних мають досить хорошими можливостями переходу від одного рівня до іншого і до фізичної базі даних, то коректність і точність складання

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

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

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

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

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

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

• - Створення коду визначення уявлення і подальше його використання в запитах користувача;
• - Виконання запиту, використовуючи мову з поверненням результату відповідно до призначених для користувача типами даних, відповідним набору і властивостями полів, значення за якими повинні бути повернуті в результат вибірки.

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

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

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

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

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

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

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

• [1] Терміни "Нотація" і "Методологія" розглядаються в рамках теорії проектування інформаційних систем (див. Відповідну літературу).
• [2] Функціональним фахівцем є власник процесів в предметної області, що виконує відповідну діяльність в організації.
• [3] Окремі нотації будуть розглянуті в гл. 2.
• [4] Під інструментальним засобом розуміється програмний додаток, що реалізує певну решаемую завдання. Для моделювання бази даних інструментальне засіб створює можливості графічного представлення схеми бази даних і реалізацію додаткових завдань, пов'язаних із забезпеченням коректності подання моді
• [5] Особливості обмежень посилальної цілісності будуть розглядатися в гл. 5.