21288

Методологія IDEF

Лекция

Информатика, кибернетика и программирование

Методологія IDEF Сімейство стандарту IDEF На даний момент до сімейства IDEF [ІДЕФ] можна віднести такі стандарти: IDEF0 методологія функціонального моделювання. За допомогою наочного графічного мови IDEF0 що розробляється система постає перед проектувальниками у вигляді набору взаємозалежних функцій функціональних блоків у термінах IDEF0. Як правило моделювання засобами IDEF0 є першим етапом вивчення будьякої системи; IDEF1 методологія моделювання інформаційних потоків усередині системи що дозволяє відображати і аналізувати їх...

Украинкский

2013-08-02

387 KB

22 чел.

Лекція 3. Методологія IDEF

Сімейство стандарту IDEF

  На даний момент до сімейства IDEF [ІДЕФ] можна віднести такі стандарти:

  •  IDEF0 - методологія функціонального моделювання. За допомогою наочного графічного мови IDEF0, що розробляється система постає перед проектувальниками у вигляді набору взаємозалежних функцій (функціональних блоків - у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи;
  •  IDEF1 - методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру та взаємозв'язку;
  •  IDEF1X тобто IDEF1 розширений - методологія побудови реляційних структур. IDEF1X відноситься до типу методологій "Сутність-взаємозв'язок» (ER - Entity-Relationship) та, як правило, використовується для моделювання реляційних баз даних, що мають відношення до даної системи; Використовується як одна з методологій в пакеті ER Win.
  •  IDEF2 - методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними труднощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. Проте в даний час присутні алгоритми та їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані на базі «розфарбованих мереж Петрі»;
  •  IDEF3 - методологія документування процесів, що відбуваються в системі, яка використовується, наприклад, при дослідженні технологічних процесів на підприємствах. За допомогою IDEF3 описуються сценарій та послідовність операцій для кожного технологічного процесу. IDEF3 має прямий взаємозв'язок з методологією IDEF0 - кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;
  •  IDEF4 - методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів і закладені принципи їх взаємодії, тим самим дозволяючи аналізувати й оптимізувати складні об'єктно-орієнтовані системи;
  •  IDEF5 - методологія онтологічного дослідження (Онтологія - спроба детальної формалізації деякої предметної області за допомогою концептуальної схеми. Звичайно така схема складається з структури даних, що містить всі класи об'єктів, їх зв'язку і правила, прийняті в даній області. Онтології використовуються в процесі програмування як форма представлення знань про реальний світ або його частини. Основні сфери застосування - моделювання бізнес-процесів та штучний інтелект) складних систем. За допомогою методології IDEF5 онтологія системи може бути описана за допомогою певного словника термінів і правил, на підставі яких можуть бути сформовані достовірні твердження про стан розглянутої системи в певний момент часу. На основі цих тверджень формуються висновки про подальший розвиток системи та проводиться її оптимізація.

Історія виникнення IDEF0

  Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої методології опису функціональних систем SADT. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках широкої програми автоматизації промислових підприємств і була запропонована департаментом військово-повітряних сил США. У процесі практичної реалізації, учасники даної програми зіштовхнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому крім покращеного набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках «аналітик-спеціаліст». Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.

  В результаті пошуку відповідних рішень народилась методологія функціонального моделювання IDEF0. C 1981 року в стандарт IDEF0 були кілька незначних зміни, в основному би характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом за Стандартами та Технологій США.

Основні елементи і поняття IDEF0

  Графічний мова IDEF0 досить простий і гармонійний. В основі методології лежать чотири основні поняття:

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

  Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:
Верхня сторона має значення «Управління»;
Ліва сторона має значення «Вхід»;
Права сторона має значення «Вихід»;
Нижня сторона має значення «Механізм».

  Кожен функціональний блок у рамках єдиної розглянутої системи повинен мати свій унікальний ідентифікаційний номер.

Рис. 1 Функціональний блок.

  Другим так би мовити «китом» методології IDEF0 є поняття інтерфейсної дуги. Також інтерфейсні дуги часто називають потоками або стрілками. Інтерфейсна дуга відображає елемент системи, який обробляється функціональним блоком або надає інший вплив на функцію, відображену даними функціональним блоком.

  Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування має бути обігом іменника.

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

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

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

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

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

Рис. 2.

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

Рис. 3.

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

  Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

  Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

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

  Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою, і позначається ідентифікатором "А-0".

  У пояснювальному тексті до контекстної діаграмі повинна бути зазначена мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).

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

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

  У процесі декомпозиції, функціональний блок, який в контекстній діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Отримана діаграма другого рівня містить функціональні блоки, що відображають головні підфункції функціонального блоку контекстної діаграми і називається дочірньої (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірньої діаграмі відповідно називається дочірнім блоком - Child Box). У свою чергу, функціональний блок - предок називається батьківським блоком по відношенню до дочірньої діаграмі (Parent Box), а діаграма, до якої він належить - батьківської діаграмою (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути далі деталізована шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному разі декомпозиції функціонального блоку все інтерфейсні дуги, що входять у цей блок, або виходять з нього фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF0 - моделі. Наочно принцип декомпозиції представлений на рисунку 4. Слід звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра у правому нижньому куті прямокутника), а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми. Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.

  Часто бувають випадки, коли окремі інтерфейсні дуги не має сенсу продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії, або навпаки - окремі дуги не мають практичного сенсу вище якогось рівня. Наприклад, інтерфейсну дугу, що зображає "деталь" на вході в функціональний блок "Опрацювати на токарному верстаті" не має сенсу відображати на діаграмах більш високих рівнів - це буде тільки перевантажувати діаграми і робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше деякого рівня. Для вирішення подібних завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунеля" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку - приймача означає той факт, що в дочірньою по відношенню до цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії - в такому випадку, вони спочатку "занурюються в тунель", а потім, при необхідності "повертаються з тунелю".

  Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даним елементом. Цей набір називається глосарієм і є описом суті даного елемента. Наприклад, для керуючої інтерфейсної дуги "розпорядження про оплату" глосарій може містити перелік полів відповідного дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочний графічний мову, забезпечуючи діаграми необхідної додаткової інформацією.

  Принципи обмеження складності IDEF0-діаграм

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

  Обмеження кількості функціональних блоків на діаграмі трьома-шістьма. Верхня межа (шість) змушує розробника використовувати ієрархії при описі складних предметів, а нижня межа (три) гарантує, що на відповідній діаграмі досить деталей, щоб виправдати її створення;

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

  Дисципліна групової роботи над розробкою IDEF0-моделі

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

  Створення моделі групою фахівців, що відносяться до різних сфер діяльності підприємства. Ця група в термінах IDEF0 називається авторами (Authors). Побудова початкової моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів і результатів опитувань створюється чернетка (Model Draft) моделі.

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

  Офіційне затвердження моделі. Затвердження узгодженої моделі відбувається керівником робочої групи в тому випадку, якщо у авторів моделі і читачів відсутні розбіжності з приводу її адекватності. Остаточна модель представляє собою узгоджене уявлення про підприємство (системі) з заданої точки зору і для заданої мети. Наочність графічного мови IDEF0 робить модель цілком читабельною і для осіб, які не брали участі в проекті її створення, а також ефективною для проведення показів і презентацій. Надалі, на базі побудованої моделі можуть бути організовані нові проекти, націлені на виробництво змін на підприємстві (в системі).

  Особливості національної практики застосування функціонального моделювання засобами IDEF0

  В останні роки інтерес в Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної web-сторінці (http://consulting.psi.ru), на якій коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5 я б назвав теоретичним, а до IDEF0 цілком практично обгрунтованим. Власне кажучи, перші Case-засоби, що дозволяють будувати DFD та IDEF0 діаграми з'явилися на російське ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.

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

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

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

  Що надходить до підрозділу "на вході"?

  Які функції, і в якій послідовності виконуються в рамках підрозділу?

  Хто є відповідальним за виконання кожної з функцій?

  Чим керується виконавець при виконанні кожної з функцій?

  Що є результатом роботи підрозділу (на виході)?

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

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

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

  Метод IDEF1, також заснований на підході П. Чена і дозволяє побудувати модель даних, еквівалентну реляційної моделі в третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X [ІДЕФ ОДИН ІКС]. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X - діаграми використовуються поруч поширених CASE-засобів (зокрема, ERwin).

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

Рис. 5. Сутності

  Кожній сутності присвоюється унікальне ім'я та номер, розділяються косою рисою «/» і поміщаються над блоком.

  Зв'язок може додатково визначатися за допомогою вказівки ступеня або потужності (кількості примірників сутності-нащадка, яке може існувати для кожного екземпляра сутності-предка). У IDEF1X можуть бути виражені такі потужності зв'язків:

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

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

  Зв'язок зображується лінією, проведеної між сутністю-батьком і сутністю-нащадком з точкою на кінці лінії у сутності-нащадка. Потужність зв'язку позначається як показано на рис. 6 (потужність за замовчуванням - N).

Рис. 6. Потужність зв'язку

  Идентифицирующая зв'язок між сутністю-батьком і сутністю-нащадком зображується суцільною лінією (рисунок 7). Сутність-нащадок в ідентифікує зв'язку є залежною від ідентифікатора сутністю. Сутність-батько в ідентифікує зв'язку може бути як незалежної, так і залежною від ідентифікатора сутністю (це визначається її зв'язками з іншими сутностями).

Рис. 7. Идентифицирующая зв'язок

  Пунктирна лінія зображує неидентифицирующей зв'язок (малюнок 8). Сутність-нащадок в неидентифицирующей зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком в якій-небудь ідентифікує зв'язку.

Рис. 8. Неидентифицирующей зв'язок

  Атрибути зображаються у вигляді списку імен усередині блоку сутності. Атрибути, що визначають первинний ключ, розміщуються вгорі списку і відділяються від інших атрибутів горизонтальній рисою (рисунок 2.34).

Рис. 9. Атрибути і первинні ключі

  Сутності можуть мати також зовнішні ключі (Foreign Key), які можуть використовуватися в якості частини або цілого первинного ключа або неключових атрибута. Зовнішній ключ зображується за допомогою приміщення всередину блоку сутності імен атрибутів, після яких слідують букви FK в дужках (рисунок 2.35).

Рис. 10. Приклади зовнішніх ключів


 

А также другие работы, которые могут Вас заинтересовать

68676. Анализ предметной области и разработка технического задания для разработки распределенной информационной системы «Магазин компьютерной техники» 452 KB
  Анализ предметной области это первый шаг этапа системного анализа с которого начинается разработка программной системы. Концептуальная модель применяется для структурирования предметной области с учетом информационных интересов пользователей системы.
68678. Система борьбы с организованной преступностью 364 KB
  Цель данного исследования – рассмотреть теоретические основы противодействия организованной преступности проблемы возникающие в борьбе с организованной преступностью. Объект исследования – Объектом исследования является организованная преступная деятельность, а также социально-правовые механизмы государственного реагирования на нее.
68679. Технология продукции общественного питания: Методические указания 46.47 KB
  Данные методические указания предназначены для организации учебно-исследовательских действий по выполнению выпускной квалификационной работы. В них отражены цель и задача выпускной квалификационной работы требования к её выполнению и оформлению структуре и содержанию состав и последовательность...
68680. Ұйым стратегиясының қалыптасуы және оны жүзеге асыру жолдары 56 KB
  Стратегиялық жоспарлау басқару шешімін қабылдауға қакерлер алдына бірлесіп жұмыс істесуі нәтижесінде жеткен жетістіктері үшін көтерме сыйлық берілітіндігі ескеріледі сондайақ олардың арасындағы кекілжіңге даудамайға дер кезінде тосқауыл қойылады.
68682. Обробка справ для наступного зберігання 65.61 KB
  Документи підприємств, що відклалися в діловодстві, надалі або залишаються на тривале зберігання, або зберігаються короткі терміни і потім виділяються до знищення. Для зберігання справ у великих установах, організаціях, на підприємствах існують відомчі архіви, «Основними правилами роботи відомчих архівів»...