Головна Інформатика
Бази даних: проектування
|
|
|||||||
Моделювання і опис сутностейОснову моделі бази даних в будь-який діаграмі становлять суті і зв'язку, які згодом трансформуються в таблиці і зв'язку бази даних. Створення сутностей виконується при формуванні діаграми моделі бази даних. Візуальне представлення моделі є невід'ємною частиною проектування бази даних, оскільки воно дозволяє розробнику легше аналізувати виникаючі некоректності в моделі і представити модель у вигляді, зручному для розгляду замовником і іншими розробниками. Для формування елементів діаграми використовується палітра елементів ( "Palette", рис. 3.49), де розміщена область "Data" з об'єктами "Entity" (сутність) і зв'язку. Вибір елемента палітри "Entity" (сутність) надасть користувачеві можливість створити об'єкт "Сутність" на діаграмі, в результаті чого необхідно ввести назву сутності.
Створення сутностей може бути також реалізовано через контекстне меню папки "Package ..." (пакет ...), де пункт меню "Add Data Object / Entity" (Додати новий об'єкт / Сутність) створить сутність в дереві проекту і надасть розробнику можливість, як і на діаграмі, ввести назву сутності (рис. 3.50).
Також можливе створення сутностей безпосередньо на діаграмі за допомогою контекстно-залежного графічного меню. Для цього необхідно навести курсор "миші" на порожній простір діаграми і не рухати її деякий час, що призведе до появи області з піктограмами, які позначають можливість створення допустимих елементів. Для логічної моделі бази даних буде виведена тільки одна піктограма, що позначає можливість створення сутності. Її вибір, як і в попередніх випадках, створить нову сутність з пропозицією ввести її назву. У закладці властивостей сутності "Volumetries" (Вимірники) розробник може вказати параметри зміни кількості примірників даної сутності (рис. 3.51), серед яких:
Мал. '3.51. Встановлення параметрів зміни
У розділі властивостей сутності серед параметрів закладки "General" (основне) розробнику пропонується встановити додатковий параметр "Persistent" (постійний), який визначає можливість трансформації сутності в таблицю при переході від логічної до фізичної моделі бази даних. Але вся інформація про структуру майбутньої бази даних закладена в зв'язках між сутностями і атрибутах, які характеризуються значно більшим кількість параметрів. Використовуючи закладку "Attributes" (атрибути), можна створити атрибути сутності та визначити їх основні параметри. Також, аналогічно створенню суті, атрибути можуть бути створені різними способами (рис. 3.52):
за допомогою графічного меню діафамми - використовується графічне меню з піктограмами при наведенні "миші" на сутність, за допомогою якого створюються первинний ключ і прості атрибути з наданням можливості вказати назву атрибута.
Puc. 3.52. Приклад створення атрибута
При використанні властивостей сутності розробник в закладці "Attributes" (атрибути), використовуючи піктограму зі знаком "+", створює нові атрибути, після чого повинен визначити основні параметри створеного атрибута:
Важливо відзначити, що інструментальне засіб надає можливості сортування атрибутів по суті в потрібному розробнику порядку. Здійснюється це за допомогою піктограм управління у вигляді різноспрямованих стрілок. Однак з урахуванням того, що правилами Кодда визначається незалежність від порядку розташування атрибутів, встановлення порядку не є необхідною складовою в моделі бази даних. Є дві причини, щоб вибудовувати необхідний порядок атрибутів: - Зручність роботи - при вибудовуванні порядку атрибутів за певними правилами (наприклад, першими повинні йти атрибути, що позначають первинний ключ, далі потрібно розмістити зовнішні ключі, потім альтернативний ключ і прості атрибути) легше читати діаграму моделі і ідентифікувати деякі проблемні ситуації, які можуть виникнути при практичній роботі з базою даних; використання особливих технологій обробки - при додаванні даних в мові SQL передбачається можливість не вказувати перелік нулів таблиці, в які будуть вноситися зазначені в команді дані, що вимагає від розробника програмного коду знання про точному порядку полів у таблиці, яке на рівні логічної моделі може бути визначено сортуванням атрибутів. Крім встановлення характеристик для кожного атрибута, включаючи завдання значення за замовчуванням і формульного виразу для обчислення, будь-яка сутність може мати обмеження цілісності, що забезпечують коректне зберігання значення за відповідним атрибуту. Наприклад, для атрибута, що зберігає значення років, може бути необхідним обмежити мінімальне значення. Оскільки на рівні побудови логічної моделі розробник може не знати про те, яка СУБД буде застосовуватися для реалізації, то використання функцій будь-якою мовою програмування не буде коректним. Однак інструментальне засіб IBM InfoSphere Data Architect надає можливість розробнику вказати умову обмеження на декількох мовах (рис. 3.53):
Створення нового обмеження цілісності виконується за допомогою контекстного меню суті в дереві проектів "Add New Object / Constraint" (Додати новий об'єкт / ограничсниях). В результаті розробнику в області властивостей об'єкта буде запропоновано ввести найменування обмеження, яке зазвичай представляється латинськими символами, що пояснюється необхідністю подальшого його трансформування в обмеження фізичної моделі і фізичної бази даних, які часто не можуть коректно обробляти об'єкти, названі з використанням національного алфавіту. Крім найменування обмеження розробник визначає мову, на якому представлено логічне вираз для обмеження. Тут важливо розуміти, яким чином далі буде це обмеження оброблятися. Якщо передбачається, що обмеження має бути трансформовано в умови на мові програмування, то застосовується одна з мов (OCL, SQL, XML), з яких для реляційних баз даних використовується мова SQL. Якщо трансформація не передбачено, а програміст бази даних повинен буде самостійно, враховуючи опис обмеження, сформулювати логічний вираз, то воно може бути представлено на природній мові. При використанні будь-якого з мов програмування розробник, використовуючи правила цієї мови, в поле "Expression" (вираз) вказує необхідне вираження, а також визначає одне з правил трансформації:
Trigger (тригер) трансформація призведе до створення програмного модуля автоматичної обробки (тригер), який буде виконуватися під час запуску операцій додавання, зміни або видалення даних. Як правило, оскільки обмеження рівня суті і атрибута видається простим логічним виразом, то найбільш частим варіантом трансформації обмеження є Check Constraint (перевірочне обмеження), що підкоряється правилам побудови логічних виразів і повертає в якості результату виконання логічне значення "True" (істина) або "False "(неправда). При використанні варіанту трансформації "Trigger" (тригер) розробником бази даних може бути, в рамках подальшого програмування, створений програмний код, що обробляє не тільки перевіряються екземпляр (запис), поле або таблицю, а й інші екземпляри (записи) і таблиці бази даних. Іноді розробники бази даних, розуміючи, що деякі атрибути не повинні використовуватися в якості первинних ключів, але при цьому мають обмеженнями, які накладаються на ключові атрибути, створюють альтернативні ключі (рис. 3.54). Як правило, така ситуація виникає, якщо в якості ключового атрибута повинні виступати атрибут символьного типу або група атрибутів, що формує зчеплений ключ в батьківської сутності. Ці варіанти вимагають створення сурогатних ключів, які подаються в якості первинного ключа, а також визначення альтернативного ключа з накладенням відповідних обмежень: унікальне значення в межах суті і неможливість зберігання порожнього значення NULL.
Для реалізації цього завдання (створення альтернативного ключа) розробник, використовуючи контекстне меню суті в дереві проектів "Add New Object / Alternate Key" (Додати новий об'єкт / Альтернативний ключ), створює необхідний об'єкт і в області властивостей об'єкта на закладці "General" (Основне ) вказує найменування ключа (як правило, використовуючи латинські символи) і тип трансформації ключа в фізичну модель бази даних:
У закладці "Key Attributes" (атрибути ключа) розробник вказує склад ключа з переліку атрибутів, сформованих для даної сутності. Саме зазначені для ключа атрибути будуть оброблятися при забезпеченні унікальності значень. Причому якщо вибрано кілька атрибутів (зчеплений ключ), то унікальність буде забезпечуватися на рівні сукупності значень по всіх атрибутів. |
<< | ЗМІСТ | >> |
---|