Рисунок 1.10 - Візуалізація визначення доменів атрибутів на ER-діаграмі при створенні фізичної моделі реляційної БД

Відношення (зв'язок) сутностей на ER-діаграмі зображується лінією, що з'єднує ці сутності. Ступінь зв'язку зображується за допомогою символу "пташина лапка", що вказує на те, що у зв'язку бере участь багато (N) екземплярів сутності, і одинарною горизонтальною рисою, що вказує на те, що у зв'язку бере участь один екземпляр сутності.

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

2.3 Функціональна модель ПО БД

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

Рисунок 1.11 - Подання відношення між двома сутностями на ER-діаграмі

Функціональна модель призначена для опису процесів обробки даних у рамках виділеної ПО з різних точок зору.

Визначимо функціональну модель ПО БД як сукупність деяких моделей, призначених для опису процесів обробки інформації. Будемо називати ці моделі конструкціями функціональної моделі. Нижче наведений перелік основних конструкцій функціональної моделі, які необхідні для виконання проектування реляційних БД.

Моделі процесів:

· бізнес-модель процесів (ієрархія функцій системи);

· модель потоку даних.

Моделі станів:

· модель життєвого циклу сутності;

· набір специфікацій функцій системи (вимоги);

· опис функцій системи через сутності й атрибути;

· бізнес-правила, які реалізують функції.

Елементи інформаційної моделі ПО є вхідними даними для завдання створення

логічної моделі даних. Елементи функціональної моделі ПО є вхідними даними для завдання проектування додатків БД і частково для завдання створення фізичної моделі БД.

2.4 Процес проектування БД

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

В експлуатації БД повинна задовольняти набору вимог за рядом інтегрованих параметрів, таких як:

функціональність й адаптованість;

продуктивність обробки транзакцій;

пропускна здатність;

час реакції

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

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

Проектування БД - це пошук засобів задоволення функціональних вимог засобами наявної комп'ютерної технології з урахуванням заданих обмежень.

Як правило, ІТ-проекти зі створення БД містять у собі такі етапи:

1. Визначення стратегії побудови системи.

2. Аналіз вимог до БД.

3. Проектування БД.

4. Реалізація БД.

5. Тестування

6. Впровадження БД.

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

Процес проектування БД охоплює кілька основних сфер:

· проектування об'єктів БД (таблиці, подання, індекси, тригери, збережені процедури, функції, пакети) для подання даних ПО в БД;

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

· проектування БД під конкретне обчислювальне середовище або інформаційну технологію (архітектура "клієнт-сервер", паралельні архітектури, розподілене обчислювальне середовище);

· проектування БД під призначення системи (інтелектуальний аналіз даних, OLAP, OLTP і т.д.).

Типова бізнес-модель процесу проектування БД

Процес проектування БД може бути поданий у вигляді моделі бізнес-процесів. Бізнес-модель процесу проектування дозволяє:

· відобразити суб'єктивну думку розробника БД на процес проектування конкретної БД;

· врахувати особливості ІТ-проекту, у рамках якого проектується БД;

· досить швидко скласти план проектування конкретної БД;

· прорахувати тривалість проектних робіт (створити тимчасову модель проектування).

Розглянемо типову бізнес-модель процесу проектування БД.

На рис. 1.12 наведена контекстна діаграма процесу проектування БД.

Як бачимо з рисунка, на вхід процесу проектування БД подаються:

· інформаційна модель ПО БД: діаграми "сутність-зв'язок" (ER-діаграми);

· функціональна модель ПО БД: бізнес-модель процесів, діаграми потоку даних (DF- діаграми), діаграми станів, - діаграми життєвих циклів сутностей, специфікації на системи (вимоги), бізнес-правила;

· загальносистемні вимоги й обмеження;

· завдання зворотного впливу.

На виході процесу проектування БД формуються такі результати:

· фізична модель БД, що може бути перетворена у скрипт для створення БД;

· фізична БД;

· специфікація модулів додатків БД;

· план тестування БД.

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

Рисунок 1.12 - Контекстна діаграма процесу проектування БД

Такими завданнями (етапами) є:

· збір й аналіз вхідних даних - це початковий етап проектування, на якому здійснюється збір і контроль якості результатів аналізу ПО БД, готується план проектування БД;

· створення логічної моделі БД - це етап, на якому на підставі інформаційної моделі

ПО БД створюється логічна структура БД, незалежна від її реалізації;

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

Рисунок 1.13 - Діаграма декомпозиція процесу проектування БД: перший рівень

· створення фізичної моделі БД: облік впливу транзакцій - це етап, на якому аналізуються можливі транзакції системи, виконується при потребі денормалізація відношення для забезпечення більш високої продуктивності БД;

· створення серверного коду - це етап, на якому на підставі функціональної моделі ПО БД створюється серверний код БД у вигляді тригерів, збережених процедур і пакетів. Ці модулі створюються розробником БД і виконуються сервером;

· проектування модулів додатків БД - це етап, на якому створюються специфікації модулів додатків, розробляються стратегії тестування БД і додатків, створюється план тестування додатків БД і готуються тестові дані;

· контроль якості проектування БД полягає в перевірці якості результатів проектування на кожному його етапі;

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

Коротко розглянемо бізнес-моделі другого рівня.

Бізнес-модель процесу проектування БД: збір й аналіз вхідних даних

На рис. 1.14 наведена діаграма декомпозиції процесу проектування БД другого рівня, що відбиває основні завдання етапу збору й аналізу вхідних даних.

Такими завданнями є:

· збір документації з результатами аналізу ПО БД у вигляді діаграм, специфікацій і вимог;

· контроль якості результатів аналізу ПО БД;

· систематизація вимог і специфікацій замовника до БД;

· підготовка плану проектування БД.

Рисунок. 1.14 - Діаграма декомпозиції процесу проектування БД: збір й аналіз вхідних даних

У ході контролю якості основними моментами діяльності є контроль ER-діаграм і контроль діаграм функціональної моделі ПО. На підставі ER-діаграм створюється логічна модель реляційної БД; на підставі діаграм функціональної моделі розробляється серверний код і проектуються модулі додатків БД.

Систематизація вимог замовника до БД виконується з метою їх адекватного розподілу по етапах проектування БД. Важливим результатом систематизації є висновок про достатність вимог і можливість реалізації БД. Аналіз вимог на можливість реалізації БД у рамках конкретного ІТ-проекту є основою для ухвалення рішення менеджером проекту про можливості реалізації в цілому.

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

Бізнес-модель процесу проектування реляційної БД: створення логічної моделі БД (рис. 1.15). Основною метою етапу створення логічної моделі БД є перетворення інформаційної моделі ПО БД у логічну модель реляційної БД. Створення логічної моделі БД припускає рішення таких основних завдань і виконання операцій у рамках таких завдань:

· нормалізація сутностей ПО: одержати список атрибутів сутності; визначити функціональні залежності (ФЗ) у сутності; визначити детермінанти сутності; визначити можливі ключі відношення, зокрема, розглянувши унікальний ідентифікатор сутності; виконати нормалізацію сутності (перетворити сутність у відношення); для отриманого відношення призначити первинні ключі; сформувати список кандидатів на зовнішні ключі, якщо необхідно; сформувати бізнес-правила підтримки цілісності сутності, якщо необхідно;

· нормалізація відношення логічної моделі БД;

· визначити ступінь зв'язку сутностей;

· визначити клас приналежності сутності до зв'язку: нормалізувати відношення (дозволити зв'язку);

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

· перевірка правильності логічної моделі реляційної БД: перевірка відношень на відповідність нормальній формі Бойса-Кодда; перевірка відношень на властивості з'єднання без втрат і збереження функціональних залежностей; запобігання втрати даних;

· шляхом міграції первинних ключів відношення й призначення зовнішніх ключів; перевірка на відсутність незамкнутих зв'язків; перевірка на відсутність одиночних відношень;

· формулювання частини вихідних даних для вирішення завдання керування посилальною цілісністю;

· документування логічної моделі реляційної БД;

· ухвалення рішення про можливість реалізації побудованої логічної моделі реляційної БД;

· ухвалення рішення про розроблення фізичної моделі реляційної БД.

Результатом проектування логічної моделі БД є нормалізована схема відношень БД.

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

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

Страницы: 1, 2, 3, 4, 5, 6