Основи методології IDEF1X

Зміст


Призначення IDEF1X


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


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


Концепція і семантика IDEF1X


Сутності в IDEF1X та їх атрибути.


Хоча термінологія IDEF1X практично збігається з термінологією IDEF1, існує ряд фундаментальних відмінностей у теоретичних концепціях цих методологій. Сутність в IDEF1X описує собою сукупність або набір примірників схожих за властивостями, але однозначно відрізняються друх від одного за одним або кількома ознаками. Кожен примірник є реалізацією сутності. Таким чином, сутність в IDEF1X описує конкретний набір примірників реального світу, на відміну від сутності в IDEF1, яка представляє собою абстрактний набір інформаційних відображень реального світу. Прикладом сутності IDEF1X може бути сутність "СПІВРОБІТНИК", яка представляє собою всіх співробітників підприємства, а один з них, скажімо, Іванов Петро Сергійович, є конкретною реалізацією цієї сутності. У прикладі, наведеному на рис. 1, кожен примірник сутності СПІВРОБІТНИК містить наступну інформацію: ID співробітника, ім'я співробітника, адресу співробітника і т.п. У IDEF1X моделі ці властивості називаються атрибутами сутності. Кожен атрибут містить тільки частину інформації про сутність.


Зв'язки між сутностями


Зв'язки в IDEF1X являють собою посилання, з'єднання та асоціацію між сутностями. Зв'язки це суть дієслова, які показують, як співвідносяться суті між собою. Нижче наведено ряд прикладів зв'язку між сутностями:


Відділ <Складається з> кількох Співробітників


Літак <Перевозить> кількох Пасажирів.


Співробітник <Пише> різні Звіти.


У всіх перерахованих прикладах взаємозв'язку між сутностями відповідають схемі один до багатьох. Це означає, що один примірник першої сутності пов'язаний з декількома екземплярами другий сутності. Причому перший сутність називається батьківського, А друга – дочірньої. У наведених прикладах дієслова укладені в кутові дужки. Зв'язки відображаються у вигляді лінії між двома сутностями з точкою на одному кінці і дієслівної фразою, яка відображається над лінією. На рис. 1 наводиться діаграма зв'язку між Співробітником і Відділом.


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


Ідентифікація сутностей. Подання про ключі.


Сутність описується в діаграмі IDEF1X графічним об'єктом у вигляді прямокутника. На рис.2 наведено приклад IDEF1X діаграми. Кожен прямокутник, що позначає собою сутність, поділяється горизонтальній лінією на частину, в якій розташовані ключові поля і частина, де розташовані неключові поля. Верхня частина називається ключовою областю, а нижня частина областю даних. Ключова область об'єкта СПІВРОБІТНИК містить поле "Унікальний ідентифікатор співробітника", в області даних знаходяться поля "Ім'я співробітника", "Адреса співробітника", "Телефон співробітника" і т.д.


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


При створенні сутності в IDEF1X моделі, одним з головних питань, на який потрібно відповісти, є: "Як можна ідентифікувати унікальну запис?". Для цього потрібно унікальна ідентифікація кожної записи по суті для того, щоб правильно створити логічну модель даних. Нагадаємо, що сутності в IDEF1X завжди мають ключову область і, тому в кожної суті повинні бути визначені ключові атрибути.


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


Наприклад, для того, щоб коректно використовувати сутність СПІВРОБІТНИК в IDEF1X моделі даних (а пізніше в базі даних), необхідно мати можливість унікально ідентифікувати запису. Правила, за якими ви вибираєте первинний ключ із списку передбачуваних ключів, дуже суворі, однак можуть бути застосовані до всіх типів баз даних та інформації. Правила встановлюють, що атрибути та групи атрибутів повинні:



Для наочного уявлення про те, як доцільно вибирати первинні ключі, наведемо наступний приклад – виберемо первинний ключ для знайомої нам сутності "СПІВРОБІТНИК":



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


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


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


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


Класифікація сутностей в IDEF1X. Залежні і незалежні сутності.


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


Дочірня сутність, унікальність якої залежить від атрибуту зовнішнього ключа, називається залежною сутністю. У прикладі на рис.1 сутність СПІВРОБІТНИК є залежною сутністю тому, що його ідентифікація залежить від сутності ВІДДІЛ. У позначеннях IDEF1X залежні сутності представлені у вигляді закруглених прямокутників.


Залежні сутності далі класифікуються на сутності, які не можуть існувати без батьківського сутності і сутності, які не можуть бути ідентифіковані без використання ключа батька (сутності, залежні від ідентифікації). Сутність СПІВРОБІТНИК належить до другого типу залежних сутностей, так як співробітники можуть існувати і без відділу.


Навпаки, існують ситуації в яких сутність залежить від існування іншої сутності. Розглянемо дві сутності: ЗАПИТ, використовуваний для відстеження запитів покупців, і ПОЗИЦІЯ ЗАПИТУ, який відстежує окремі елементи у запиті. Зв'язок між цими двома сутностями може бути виражена у вигляді ЗАПИТ <містить> один або кілька ПОЗИЦІЙ ЗАПИТУ. У цьому випадку, ПОЗИЦІЯ ЗАПИТУ залежить від існування ЗАМОВЛЕННЯ.


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


Типи зв'язків між сутностями. Ідентифікують і неидентифицирующей зв'язку.


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


Ідентифікують взаємозв'язку позначаються суцільною лінією між сутностями.


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


Неидентифицирующей зв'язку відображаються пунктирною лінією між об'єктами. Так як передані ключі в неидентифицирующей зв'язку не є складовою частиною первинного ключа дочірньої суті, то цей вид зв'язку не виявляється ні в одній ідентифікуючої залежності. У цьому випадку і ВІДДІЛ, і СПІВРОБІТНИК розглядаються як незалежні сутності.


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


Переваги IDEF1X


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


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*