Основи методології IDEF1X, CASE-засоби (моделювання), Програмування, статті

Зміст


Призначення 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>

*

*