Головна Інформатика
Бази даних: проектування
|
|
|||||||||||||
Моделювання і опис зв'язків між сутностямиІнструментальне засіб IBM InfoSphere Data Architect надає розширене кількість варіантів зв'язків між сутностями, по при цьому кількість типів зв'язків залишається відповідним правилам встановлення зв'язків між сутностями в теорії розробки бази даних. Аналогічно елементу "Сутність" всі варіанти зв'язків представляються в палітрі візуальних компонентів (рис. 3.55):
властивості можливості відсутності пов'язаного примірника в батьківської сутності і встановлення значення NULL для атрибута зовнішнього ключа;
Мал. '3.55. Палітра елементів логічної моделі бази даних Для встановлення зв'язків в інструментальному засобі є кілька варіантів, кожен з яких надає розробнику різні варіанти базового опису зв'язків, як правило, орієнтовані на визначення встановлюваного типу та подання зв'язку (рис. 3.56). Першим варіантом є використання візуальних інструментів у вигляді відображаються на кордонах суті різноспрямованих стрілок. Вибір і наведення обраної стрілки на зв'язувану сутність призводять до появи спеціалізованого меню, через яке вибирається потрібний варіант зв'язку. Пункти цього меню повністю ідентичні варіантів зв'язків в палітрі візуальних компонентів діаграми.
Другий варіант встановлення зв'язку використовує палітру візуальних компонентів, де можна вибрати потрібний варіант і створити зв'язок за допомогою руху "миші" з натиснутою лівою кнопкою від батьківської сутності до дочірньої. Якщо завершення (відпускання натиснутою лівої кнопки "миші") відбудеться незалежно наявних на діаграмі сутностей, то розробнику буде запропоновано створити нову сутність, пов'язану з вихідною (обраної першої) сутністю. Третій варіант створення зв'язку передбачає використання контекстного меню батьківської сутності "Add New Object / Relationship" (Додати новий об'єкт / зв'язок), що викличе відповідне діалогове вікно для визначення батьківської сутності. Вибравши потрібну сутність (рис. 3.57), розробник, якщо в обраній дочірньої суті вже існує атрибут з ім'ям, аналогічним імені первинного ключа батьківської сутності, повинен вказати правило перетворення створюваного атрибута.
Серед варіантів трансформації атрибута розробнику пропонується (рис. 3.58):
Create a new child attribute or column (створити новий дочірній атрибут або колонку) - формування зв'язку супроводжується створенням нового атрибута зовнішнього ключа в дочірній сутності з автоматично підставляє ім'ям, яке згодом можна змінити, і властивостями первинного ключа політельской суті.
Такі перетворення атрибутів відбуваються при будь-якому виявленні конфлікту в найменуваннях атрибутів. Використання механізму створення зв'язку між сутностями через контекстне меню не призводить до появи зв'язку на діаграмі. Щоб цей зв'язок відобразилася на діаграмі, необхідно її перенести з дерева проектів (розміщується вона серед елементів дочірньої сутності) на діаграму. В результаті на діаграмі, буде відображена необхідна зв'язок і атрибут зовнішнього ключа, оскільки розглядається зв'язок ідентифікує, буде розміщений в області первинних ключів (рис. 3.59). Якщо раніше вже був визначений первинний ключ в дочірньої суті, то зовнішній ключ буде додано, створюючи первинний зчеплений ключ, що вимагає подальшого розгляду цих ключів в частині нормалізації і забезпечення ефективної роботи бази даних.
Встановлення неидентифицирующей зв'язку (опціональною або обов'язкової, рис. 3.60) реалізується через відповідний вибір варіанту зв'язку, що на діаграмі буде відображено наявністю або відсутністю гуртка з боку батьківської сутності (сутність 1). Якщо обрана обов'язкова неідентіфіцірующей зв'язок, то для атрибута зовнішнього ключа дочірньої сутності у властивості "Required" (обов'язковий) буде встановлено прапорець, що позначає обов'язкове заповнення атрибуту значенням і неможливість внесення порожнього значення NULL. При формуванні зв'язку один - до - одному, представленої в неідентіфіцірующей варіанті (рис. 3.61), на моделі з боку дочірньої суті буде відображено не "лапка", а одинарна лінія, що показує, що один екземпляр батьківського суті може бути пов'язаний лише з одним екземпляром дочірньої сутності. Як і для зв'язку один - до - багатьох варіантів неідентфіцірующей зв'язку один - до - одному може бути кілька: опциональная і обов'язкова. Сенс цих варіантів повністю ідентичний змістом аналогічні варіантів зв'язку один - до - багатьох.
Зв'язок багато - до - багатьох, що не припускає безпосереднього зв'язування за атрибутами, на діаграмі відображається тільки лінією зв'язку, де на обох її сторонах відображена "лапка", що позначає можливість зв'язування одного примірника однієї з сутностей з безліччю екземплярів іншої сутності (рис. 3.62). Для зв'язку з цим суті не розділяються на батьківську і дочірню і зовнішні ключі не формуються. Також для цієї зв'язку, аналогічно зв'язку один - до - багатьох, може бути кілька варіантів по необхідності існування записів в одній з сутностей, що визначається властивостями опціонально або обов'язковості існування примірника відповідної сутності.
Встановивши зв'язок між сутностями, розробник специфицирует додаткові характеристики, які розміщуються в закладці властивостей "Details" (деталі). Ця закладка надає можливість вказати деякі параметри описового і атрибутивного характеру для батьківської та дочірньої сутностей (рис. 3.63):
Entity name (найменування сутності) - властивість є інформаційним і містить вказівку на сутність, яка розглядається для зв'язку в якості дочірньої, Inverse verb phrase (зворотна дієслівна фраза) - смислове відображення суті зв'язку в напрямку від дочірньої до батьківської сутності відповідно до її поданням до предметної області, Key attributes (ключові атрибути) - вказуються атрибути сутності, які повинні виступати в якості зовнішнього ключа, пов'язаного з первинним або альтернативним ключем батьківської сутності.
У закладці "Турі" (тип) властивостей зв'язку розробник може виконати дії але більш точного налаштування твань встановлюється зв'язку або повністю змінити тип зв'язку (рис. 3.64):
Puc. 3.64. Позначення типу та варіанту зв'язку Правильне визначення кардинальності (потужності) зв'язку дозволить створити працездатну і ефективну базу даних, забезпечуючи велику кількість правил посилальної цілісності та інформаційної взаємодії таблиць. Забезпечення цілісності бази даних реалізується на підставі вбудованих в СУБД механізмів контролю значень відповідно до встановлених описами зв'язків. Аналогічно іншим інструментальним засобам в IBM InfoSphere Data Architect розробник може вказати додаткові правила посилальної цілісності (рис. 3.65), визначаючи операції, що виконуються при настанні дії додавання, зміни або видалення даних у батьківській або дочірньої сутності. В інструментальному засобі надаються такі можливості операцій:
В рамках логічної моделі бази даних вказівку правил посилальної цілісності не є обов'язковим, оскільки зміст цієї дії орієнтований на програмну обробку даних при настанні дій додавання, зміни і видалення. Проте, вже на поточному етапі (логічне моделювання) можна, з огляду на особливості предметної області, визначитися з деякими правилами і уточняти їх. Зв'язок категоризації встановлюють між парами сутностей (рис. 3.66), позначаючи стрілкою в напрямку сутності-спільності і мигрирования її первинного ключа в якості зовнішнього первинного ключа сутності-категорії. Для створення зв'язку з цим необхідно вибрати в палітрі тип зв'язку "Generalization" (категоризації) і за допомогою "миші" з натиснутою лівою клавішею провести зв'язок від сутності-категорії до сутності-спільності. При цьому для кожної встановлюється зв'язку необхідно вказати ім'я категоризує властивості (ознаки), який за замовчуванням має назву "Generalization Set ..." Такий зв'язок розглядається у вигляді зв'язку один - до - одному і при трансформації в фізичну модель буде перетворена в неї з автоматичним встановленням відповідних правил.
|
<< | ЗМІСТ | >> |
---|