Ефективна реалізація проектування БД . CASE-системи

1. Інструментальні засоби побудови інформаційних систем

У багатьох випадках ефективну інформаційну систему не вдається побудувати вручну. Це пояснюється наступними причинами:

• не забезпечується досить глибокий аналіз вимог до даних

• велика тривалість процесу структурування

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

• обмеження термінів на розробку системи і т.д.

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

Така технологія одержала назву CASE (Computer Aided Software Engeneering - створення програмного забезпечення за допомогою комп'ютера). Основні риси CASE - технології:

• використання методології структурного проектування "униз"

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

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

• підтримка репозитарію, що зберігає специфікації проекту інформаційної системи на всіх етапах її розробки

• можливість одночасної роботи з репозитарієм багатьох розроблювачів

• автоматизація різних стандартних дій по проектуванню і реалізації додатка

Як правило, CASE-системи підтримують наступні етапи процесу розробки:

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

• Концептуальне моделювання - створення моделі "сутність-зв'язок" на основі переліку об'єктів, отриманого на попередньому етапі. Тут уточнюються характеристики кожного об'єкта (атрибути), установлюються зв'язки між об'єктами.

• Реляционное моделювання - перетворення моделі "сутність-зв'язок" відповідно до вимог реляційної моделі (реляційна модель допускає тільки бінарні зв'язки, не дозволяє існування атрибутів у зв'язків, не підтримує зв'язки типу n : m).

2. Методологія функціонального моделювання при проектуванні реляційних бд

2.1. Діаграми потоків даних. Нотація Йордона-Де Марко. Інші нотації, що застосовуються при проектуванні бд

Діаграми потоків даних (DFD - Data Flow Diagramm) будуються з наступних елементів:

Елемент	Опис	Позначення
Функція	Дія, виконувана модельованою системою
Потік даних	Об'єкт, над яким виконується дія. Може бути інформаційним (логічним) чи керуючим. (Керуючі потоки позначаються пунктирною лінією зі стрілкою).
Сховище даних	Структура для збереження інформаційних об'єктів
Ім'я зовнішнього об'єкту   Зовнішня сутність	Зовнішній стосовно системи об'єкт, що обмінюється з нею потоками даних

Такий тип позначень елементів DFD-діаграми одержав назву "нотація Йордона - Де Марко", по іменах його фахівців, що розробили.

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

• Функції перетворюють вхідні потоки даних у вихідні

• Сховища даних не змінюють потоки даних, а служать тільки для збереження об'єктів, що надходять

• Перетворення потоків даних у зовнішніх сутностях ігнорується

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