Моделювання і опис сутностей

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

Для формування елементів діаграми використовується палітра елементів ( "Palette", рис. 3.49), де розміщена область "Data" з об'єктами "Entity" (сутність) і зв'язку. Вибір елемента палітри "Entity" (сутність) надасть користувачеві можливість створити об'єкт "Сутність" на діаграмі, в результаті чого необхідно ввести назву сутності.

Створення сутностей може бути також реалізовано через контекстне меню папки "Package ..." (пакет ...), де пункт меню "Add Data Object / Entity" (Додати новий об'єкт / Сутність) створить сутність в дереві проекту і надасть розробнику можливість, як і на діаграмі, ввести назву сутності (рис. 3.50).

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

У закладці властивостей сутності "Volumetries" (Вимірники) розробник може вказати параметри зміни кількості примірників даної сутності (рис. 3.51), серед яких:

• • Initial number of rows (початкова кількість примірників) - вказує на ту кількість даних (примірників), яке повинно бути додано одразу після створення таблиці;
• • Row growth per month (додавання примірників на місяць) - вказує, яка кількість примірників має додаватися в місяць;
• • Maximum number of rows (максимальна кількість примірників) - вказує на максимальну кількість примірників, яке може зберігатися в таблиці, описуваної розглянутої сутністю.

Мал. '3.51. Встановлення параметрів зміни
кількісних показників суті

У розділі властивостей сутності серед параметрів закладки "General" (основне) розробнику пропонується встановити додатковий параметр "Persistent" (постійний), який визначає можливість трансформації сутності в таблицю при переході від логічної до фізичної моделі бази даних. Але вся інформація про структуру майбутньої бази даних закладена в зв'язках між сутностями і атрибутах, які характеризуються значно більшим кількість параметрів. Використовуючи закладку "Attributes" (атрибути), можна створити атрибути сутності та визначити їх основні параметри.

Також, аналогічно створенню суті, атрибути можуть бути створені різними способами (рис. 3.52):

• - За допомогою контекстного меню - використовується контекстне меню суті в дереві проектів, де надається можливість вибрати об'єкт для створення - атрибут, альтернативний ключ, обмеження і т.д .;
• - За допомогою властивостей сутності - використовується область властивостей в закладці "Attributes" (атрибути), де за допомогою наявного там інструментарію створюються і специфицируются атрибути;

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

Puc. 3.52. Приклад створення атрибута
через властивості сутності

При використанні властивостей сутності розробник в закладці "Attributes" (атрибути), використовуючи піктограму зі знаком "+", створює нові атрибути, після чого повинен визначити основні параметри створеного атрибута:

• • Name (найменування) - найменування атрибута, за яким визначається змістовний сенс описуваних даних;
• • Primary Key (первинний ключ) - ознака, що означає, що атрибут є елементом первинного ключа і для нього необхідно створити відповідні обмеження цілісності;
• • Surrogate Key (сурогатний ключ) - ознака, що означає, що атрибут не є елементом предметної області, але необхідний для ефективної роботи з базою даних і буде містити значення, автоматично генеруються відповідно до правил арифметичної прогресії;
• • Туре (тип) - тип даних, яким описуються значення, що подаються атрибутом;
• • Length / Precision (розмір / точіость) - числове значення, що позначає кількість символів (байт), необхідних для зберігання максимального значення за описуваного атрибуту;
• • Scale (масштаб) - числове значення, яке використовується для числових атрибутів, яке описує кількість знаків після десяткової точки при роботі з числами;
• • Required (обов'язковість) - ознака неможливості зберігання по атрибуту порожнього значення NULL;
• • Derived (обчислюється) - ознака необхідності обчислення значення за певним висловом, використовуючи математичні, лінгвістичні операції і різні функції мови СУБД;
• • Default Value (значення умовчання) - значення, яке має записуватися, якщо при додаванні або зміні даних для атрибута не було визначено;
• • Derivation Expression (обчислюється вираз) - формульне вираз, яке повинно обчислюватися при додаванні або зміні даних.

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

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

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

Крім встановлення характеристик для кожного атрибута, включаючи завдання значення за замовчуванням і формульного виразу для обчислення, будь-яка сутність може мати обмеження цілісності, що забезпечують коректне зберігання значення за відповідним атрибуту. Наприклад, для атрибута, що зберігає значення років, може бути необхідним обмежити мінімальне значення. Оскільки на рівні побудови логічної моделі розробник може не знати про те, яка СУБД буде застосовуватися для реалізації, то використання функцій будь-якою мовою програмування не буде коректним. Однак інструментальне засіб IBM InfoSphere Data Architect надає можливість розробнику вказати умову обмеження на декількох мовах (рис. 3.53):

• • OCL (Object Constraint Language) - мова обмежень для об'єктів, застосовуваний при об'єктно-орієнтованому поданні даних і програми додатки, досить рідко застосовуваний при реалізації реляційних баз даних, використовує стандартні логічні вирази і вказівки на атрибути сутностей (наприклад: Сутність. Рік> = 2000):
• • SQL (Structured Query Language) - мова структурованих запитів, застосовуваний при обробці реляційних баз даних, зазвичай орієнтований на конкретну СУБД і має безліч функцій, властивих тільки обраної СУБД, використовує логічні операції (AND (І), OR (АБО) і ін. ) і застосовує їх на рівні атрибута даної сутності (наприклад: Рік> = 2000 and Рік <2100);
• • English - природна мова, неперекладний в мову програмування, зазвичай застосовується для опису обмеження з наступним поданням в процесі програмування відповідним логічним виразом (наприклад: Рік представляється значенням в діапазоні [2000; 2100));
• • XML (Extended Mark Language) - мова розширеної розмітки, застосовуваний для опису ієрархічно структурованих даних, для обмежень використовується в рамках спеціалізованих мовних логічних виразів з обробки дій наддають XML-документа.

Створення нового обмеження цілісності виконується за допомогою контекстного меню суті в дереві проектів "Add New Object / Constraint" (Додати новий об'єкт / ограничсниях). В результаті розробнику в області властивостей об'єкта буде запропоновано ввести найменування обмеження, яке зазвичай представляється латинськими символами, що пояснюється необхідністю подальшого його трансформування в обмеження фізичної моделі і фізичної бази даних, які часто не можуть коректно обробляти об'єкти, названі з використанням національного алфавіту.

Крім найменування обмеження розробник визначає мову, на якому представлено логічне вираз для обмеження. Тут важливо розуміти, яким чином далі буде це обмеження оброблятися. Якщо передбачається, що обмеження має бути трансформовано в умови на мові програмування, то застосовується одна з мов (OCL, SQL, XML), з яких для реляційних баз даних використовується мова SQL. Якщо трансформація не передбачено, а програміст бази даних повинен буде самостійно, враховуючи опис обмеження, сформулювати логічний вираз, то воно може бути представлено на природній мові.

При використанні будь-якого з мов програмування розробник, використовуючи правила цієї мови, в поле "Expression" (вираз) вказує необхідне вираження, а також визначає одне з правил трансформації:

• - None (відсутній) - трансформація логічного виразу не передбачається і обмеження може бути виведено тільки у звіті за логічної моделі бази даних;
• - Check Constraint (перевірочне обмеження) - трансформація переведе вказане вираз в відповідне логічне вираз па зазначеному мовою програмування, враховуючи особливості обраної для фізичної моделі бази даних СУБД;

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

Як правило, оскільки обмеження рівня суті і атрибута видається простим логічним виразом, то найбільш частим варіантом трансформації обмеження є Check Constraint (перевірочне обмеження), що підкоряється правилам побудови логічних виразів і повертає в якості результату виконання логічне значення "True" (істина) або "False "(неправда).

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

Іноді розробники бази даних, розуміючи, що деякі атрибути не повинні використовуватися в якості первинних ключів, але при цьому мають обмеженнями, які накладаються на ключові атрибути, створюють альтернативні ключі (рис. 3.54). Як правило, така ситуація виникає, якщо в якості ключового атрибута повинні виступати атрибут

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

Для реалізації цього завдання (створення альтернативного ключа) розробник, використовуючи контекстне меню суті в дереві проектів "Add New Object / Alternate Key" (Додати новий об'єкт / Альтернативний ключ), створює необхідний об'єкт і в області властивостей об'єкта на закладці "General" (Основне ) вказує найменування ключа (як правило, використовуючи латинські символи) і тип трансформації ключа в фізичну модель бази даних:

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

У закладці "Key Attributes" (атрибути ключа) розробник вказує склад ключа з переліку атрибутів, сформованих для даної сутності. Саме зазначені для ключа атрибути будуть оброблятися при забезпеченні унікальності значень. Причому якщо вибрано кілька атрибутів (зчеплений ключ), то унікальність буде забезпечуватися на рівні сукупності значень по всіх атрибутів.