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

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

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

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

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

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

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

Відділ кількохСпівробітників

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

Співробітник різніЗвіти.

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

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

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

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

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

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

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

Унікальним чиномідентифікувати екземпляр сутності.
Не використовувати значення NULL.
Чи не змінюватися з часом. Екземпляр ідентифікується за допомогою ключа. При зміні ключа відповідно змінюється екземпляр.
Бути якомога коротшими для використання індексування та отримання даних. Якщо вам потрібно використовувати ключ, який є комбінацією ключів з інших сутностей, переконайтеся, що кожна частина ключа відповідає правилам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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