2.2. Інші нотації, що застосовуються при проектуванні бд

Крім нотації Йордона - Де Марко для елементів DFD-діаграм можуть використовуватися й інші умовні позначки (OMT, SSADM, нотація Гейна - Сарсона і т.д.). Усі вони мають практично однакову функціональність і розрізняються лише в деталях. Наприклад, у нотації Гейна-Сарсона для позначення функцій використовуються прямокутники з закругленими кутами, а також не розглядаються керуючі потоки даних. В іншому ці системи позначень еквівалентні.

Інструментальні засоби проектування (CASE - системи), як правило, підтримують кілька нотацій представлення DFD-діаграм. Однієї з таких систем є Power Designer компанії Sybase, що включає наступні модулі:

• Process Analyst - побудова діаграм потоків даних з використанням кожної з вищезгаданих нотацій

• Data Analyst - побудова діаграм "сутність-зв'язок" і перетворення її в реляційну модель

• Application Modeller - засіб для генерації додатків

 

2.3. Методологія SADT (IDEFO)

Методологія SADT (Structured Analisys and Design Technique) розроблена Дугласом Т. Россом у 1969-73 роках. Вона споконвічно створювалася для проектування систем більш загального призначення в порівнянні з іншими структурними методами, що виросли з проектування програмного забезпечення. IDEF0 (підмножина SADT) використовується для моделювання бізнесів-процесів в організаційних системах і має розвинені процедури підтримки колективної роботи.

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

Правила інтерпретації моделі:

• Функціональний блок (функція) перетворить вхідні об'єкти у вихідні

• Управління визначає, коли і як це перетворення чи може повинне відбутися

• Виконавець здійснює це перетворення

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

Дуги можуть розгалужуватися і з'єднуватися. Розгалуження означає множинність (ідентичні копії одного об'єкта) чи розщеплення (різні частини одного об'єкта). З'єднання означає об'єднання чи злиття об'єктів.

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

2.4. Порівняльна характеристика методологій функціонального моделювання

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

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