•  3.1 Життєвий цикл та методологія проектування
• 3.2 Етапи проектування БД
  • 3.2.1 Визначення стратегії
  • 3.2.2 Аналіз предметної області
  • 3.2.3 Концептуальне моделювання предметної області
  • 3.2.4 Логічне та фізичне моделювання даних
•  Бізнес-модель процессу проектування бази даних
  • 3.3.1. Типова бізнес-модель процесу проектування бази даних
  • 3.3.2. Діаграма декомпозиції першого рівня

 3.1 Життєвий цикл та методологія проектування

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

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

Фаза проектування поділяється на такі етапи:

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

Фаза реалізації складається з таких пунктів:

• власне програмна реалізація;
• документування;
• дослідне впровадження.

 

Рисунок 3.1 – Етапи життєвого циклу БД

Методологія проектування баз даних — це сукупність принципів, методів, інструментів і засобів, що застосовуються для послідовного розроблення структури бази даних. Оскільки система баз даних складається з програм і даних, методологія проектування баз даних розглядається як невід’ємна частина загальної методології проектування програмних систем.

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

Методологія проектування баз даних визначає:

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

Процес проектування.

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

З проектуванням тісно пов’язане експертне оцінювання проекту. Мета експертизи - знайти помилки й виправити їх на ранніх етапах проектування. Зазвичай експертиза виконується після завершення кожного з етапів.

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

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

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

Критерії оцінювання

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

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

Інформаційні вимоги

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

Засоби опису

Це мовні засоби, призначені для опису результатів виконання кожного етану проектування. А саме, йдеться про такі засоби.

• Природна мова, якою строго означуються всі необхідні для опису результатів проектування поняття. Використовується, як правило, на етапі визначення стратегії.
• Стандартні форми, анкети та бланки. Використовуються переважно на етапі аналізу.
• Спеціальні формалізовані мови концептуального моделювання (семантичні мережі, числення предикатів та ЕR-мови). Використовуються переважно на етапі концептуального моделювання.
• Формалізовані мова означення даних (МОД) і мова маніпулювання даними (ММД). Використовуються на етапі логічного проектування. Зазвичай з цією метою застосовують мову SQL.

3.2 Етапи проектування БД

3.2.1 Визначення стратегії

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

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

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

Результати. Основними результатами цього етапу мають бути

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

Такий підхід до моделювання предметної області передбачає її відображення з трьох різних точок зору:

• загальний напрям прикладної діяльності;
• прикладні завдання;
• інформаційні потреби.

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

Ключові чинники успіху:

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

3.2.2 Аналіз предметної області

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

Цей етап є найменше вивченим, найважчим і найтривалішим. Проте він найважливіший, оскільки саме на ньому формується більшість проектних рішень

Опис. Аналіз предметної області складається з аналізу даних та аналізу завдань. Аналіз даних передбачає документування всіх атрибутів. Аналіз завдань може потребувати застосування різноманітних методів побудови діаграм для дослідження зв'язків і способів використання даних, подій, станів даних, а також детального опису алгоритмів.

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

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

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

Результати:

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

Ключові чинники успіху:

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

3.2.3 Концептуальне моделювання предметної області

Етап концептуального моделювання полягає в побудові опису предметної області в термінах формальної мови, наприклад у термінах моделі сутностей і зв’язків. Ідеї побудови концептуальної моделі предметної області беруть свій початок із публікації робочої групи ANSI/SPARC, присвяченій архітектурі СКБД.

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

Результати:

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

Ключові чинники успіху :

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

3.2.4 Логічне та фізичне моделювання даних

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

Логічне проектування — це розроблення структур зберігання, методів доступу й логічної структури системи баз даних без прив’язки до конкретної СКБД.

Фізичне проектування — це проектування бази даних у конкретній СКБД.

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

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

Результати:

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

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

• знання можливостей апаратного й програмного забезпечення;
• розуміння прикладних потреб;
• ухвалення обґрунтованих компромісних рішень;
• виявлення і вирішення потенційних проблем.

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

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

• відобразити суб'єктивну думку розробника БД на процес проектування конкретної БД;
• врахувати особливості ІТ-проекту, у рамках якого проектується БД;
• досить швидко скласти план проектування конкретної БД;
• прорахувати тривалість проектних робіт (створити тимчасову модель проектування).

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

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

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

• функціональність й адаптованість;
• продуктивність обробки трансакцій;
• пропускна здатність;
• час реакції;
• безпека.

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

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

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

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

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

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

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

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

3.3.2. Діаграма декомпозиції першого рівня

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

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

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

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