Етапи проектування бази даних

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

Опис

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

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

Результати

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

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

• опис цілей і завдань автоматизації, витрат і можливого виграшу;

• узагальнена діаграма сутностей і зв'язків;

• узагальнена ієрархічна схема завдань (виробничих та управлінських);

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

• визначення меж і окреслення сфери застосування системи баз даних;

• можлива архітектура системи;

• поетапний план проектування бази даних.

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

• загальний напрям прикладної діяльності;

• прикладні завдання;

• інформаційні потреби.

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

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

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

На першому етапі слід виділити насамперед такі чинники успіху:

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

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

• проведення плідних нарад із ретельним розглядом усіх питань.

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

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

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

Опис

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

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

Підхід

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

• проведення бесід з користувачами;

• перегляд усіх документів та бланків, які обробляються і формуються органі­зацією;

• аналіз потоків документів;

• аналіз способів вирішення завдань організації;

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

Результати

До ключових результатів етапу аналізу належать:

• узгоджена діаграма сутностей і зв'язків;

• відомості про обсяги даних, частоту виконання завдань, очікуваний користу­вачем рівень продуктивності;

• деталізовані й узгоджені описи завдань;

• первинний варіант стратегії впровадження;

• опис заходів з ревізії і контролю даних, резервного копіювання й відновлення;

• загальний опис процедур, що не автоматизуються;

• критерії прийнятності, якості, гнучкості та продуктивності;

• попереднє оцінювання обсягів системи;

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

• уточнений план розроблення системи.

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

• активна участь користувачів;

• ретельна перевірка достовірності, повноти й несуперечності даних;

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

• встановлення точних характеристик ключових завдань і даних;

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

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

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

Опис

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

Результати

До ключових результатів етапу концептуального моделювання належать:

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

• докладний і строгий опис сховищ даних;

• детальний опис потоків даних;

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

• детальний опис чинних у предметній області правил і обмежень.

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

До ключових чинників успіху належать:

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

♦ знання методів проектування реляційної моделі та/або інших моделей даних.

Логічне й фізичне проектування

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

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

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

Опис

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

Підхід

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

Результати

До ключових результатів етапу проектування належать:

• архітектура системи;

• схеми системних модулів;

• логічна і фізична схеми;

• схема бази даних і файлів;

• детальні часові та ємнісні характеристики;

• програмні специфікації;

• специфікації неавтоматизованих процедур;

• чорновий варіант посібника для користувача;

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

• план випробувань системи;

• чорновий варіант експлуатаційної документації;

• уточнений план розроблення системи.

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

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

• знання можливостей апаратного й програмного забезпечення;

• розуміння прикладних потреб;

• ухвалення обґрунтованих компромісних рішень;

• виявлення і вирішення потенційних проблем.

4. ER-моделювання предметної області

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

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

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

Сутність

Сутність — це реальний або уявний об'єкт, інформація про який має бути зібра­на чи збережена. Графічно сутність зображується пойменованим прямокутником із заокругленими кутами. Ім'я сутності подається в однині й пишеться великими літерами (рис. 1, а).

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

Ім'я сутності має бути таким, щоб посилатися на тип або клас об'єктів, а не на окремий екземпляр. У нашому прикладі Хітроу або Орлі не можуть бути іменами сутностей, сутність — це АЕРОПОРТ, а згадані назви іменують екземпляри сутності (рис. 1, б).

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

Перелічимо найважливіші властивості сутностей.

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

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

Зв'язок

Прикладний зв'язок, або просто зв'язок — це пойменована асоціація двох або біль­шої кількості сутностей.

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

• ім'я;

• множинність, або потужність;

• обов'язковість — зв'язок може бути обов'язковим або факультативним.

Розрізняють дві множинності зв'язку — «один» і «багато». Якщо зв'язок між сутностями А і В з боку сутності А має множинність «один», то це означає, що кожний екземпляр В асоціюється даним зв'язком не більше ніж з одним екземп­ляром А. І навпаки, якщо екземпляр В може асоціюватися певним зв'язком із до­вільною кількістю екземплярів А, то зв'язок з боку сутності А має множинність «багато».

Зв'язок між сутностями А і В є обов'язковим з боку сутності А, якщо кожен її екземпляр повинен асоціюватися даним зв'язком з певним екземпляром (певни­ми екземплярами) сутності В. Якщо участь у зв'язку екземплярів А не є обов'яз­ковою, зв'язок з боку А називається факультативним.

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

Іменування й інтерпретація зв'язків

Біля кожного закінчення зв'язку маленькими літерами записується ім'я (рис. 3).

Бінарному зв'язку відповідають два предикати, або твердження, які цей зв'язок інтерпретують. Один з цих предикатів дає можливість «прочитати» зв'язок зліва направо, інший - справа наліво.

Діаграма, що наведена на рис. 3, зліва направо і справа наліво читається так:

Будь-який КВИТОК завжди виписується на одного й лише одного ПАСАЖИРА Будь-який ПАСАЖИР може мати на своє ім'я один або кілька КВИТКІВ

Слід зазначити, що обов'язкові зв'язки інтерпретуються за допомогою при­слівника «завжди», факультативні - за допомогою дієслова «може». Множин­ність «багато» означає «один або кілька», а множинність «один» — «один і лише один».

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

Рекурсивні зв'язки

Зв'язок сутності з самою собою називається рекурсивним. Таким зокрема є зв'я­зок типу «один-до-багатьох» для сутності ДЕТАЛЬ, якщо припускати, що деталі мо­жуть складатися з інших деталей (рис. 4).

Наведений на рисунку рекурсивний зв'язок утворює нескінченну ієрархію.

Атрибут

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

Зображення атрибутів

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

Атрибут має описувати сутність, якій він належить. Це може видаватися очевид­ним, проте з цим пов'язана найбільша кількість помилок під час визначення атри­бутів. Наприклад, атрибутом якої сутності є «номер місця»: квитка, посадкового талона, повітряного човна або місця в літаку? Очевидно, це атрибут сутності МІСЦЕ, але на практиці ми часто зустрічаємося з його багаторазовими повтореннями, на­приклад на посадковому талоні, що на рис. 6 зображений як самостійна сут­ність. Повторення пояснюються тим, що атрибут може використовуватися як зовнішній ключ для моделювання зв'язків.

Не слід використовувати імені сутності в найменуванні її атрибутів. Це зайве, оскільки атрибут описує тільки одну сутність. У наведеному прикладі існування дефініції «номер місця» вказує на наявність сутності МІСЦЕ, яку потім можна опи­сувати за допомогою атрибута номер та інших атрибутів (скажімо, атрибута тип).

Унікальний ідентифікатор

Кожна сутність має однозначно ідентифікуватися за допомогою комбінації атри­бутів та/або зв'язків. Тому серед можливих атрибутів та/або зв'язків сутності завжди мають бути такі, які дають змогу її ідентифікувати. Унікальний ідентифі­катор позначається на ЕИ-діаграмі символом «#» перед ім'ям кожного атрибута, що входить до його складу, і поперечними рисками на лініях відповідних зв'язків. Усі атрибути унікального ідентифікатора мають бути обов'язковими.

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

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

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

Згідно з рисунком для однозначної ідентифікації посадкового талона необхідні:

дата і час видачі;

• зв'язок з місцем, відтак і номер місця; зв'язок з повітряним човном;

• зв'язок з рейсовим польотом, відтак відповідні дата і час вильоту;

• номер рейсу, оскільки до складу унікального ідентифікатора рейсового польо­ту входить зв'язок з рейсом.

Типи та екземпляри

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

Складніші поняття ЕR-моделювання

У мові ЕR-моделювання використовуються й більш складні поняття. А саме, це поняття, пов'язані із:

• сутностями - підтипи, супертипи, базисні й перехідні сутності;

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

• унікальними ідентифікаторами — визначення за допомогою дуг, що виключа­ють одна одну;

• доменами — означення, характеристики і застосування;

• атрибутами — похідні атрибути.

Сутності Підтипи

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

Супертипи

Супертип — це сутність, що має підтипи. Одна й та сама сутність може бути су-пертипом однієї і підтипом іншої сутності. Підтипи сутності мають утворювати повну систему множин, тобто будь-який екземпляр супертипу має належати при­наймні одному з підтипів. У багатьох випадках це правило буде приводити до оз­начення додаткового підтипу з ім'ям на кшталт ІНША СУТНІСТЬ. Наприклад, в діа­грамі, зображеній на рис. 10, введено сутність ІНШИЙ ПОВІТРЯНИЙ ЧОВЕН.

Базисні сутності

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

Перехідні сутності

Перехідна сутність вводиться виключно для моделювання зв'язку типу «багато-до-багатьох» між двома іншими сутностями. Екземпляри перехідної сутності можуть існувати лише в контексті зв'язків з відповідними базисними сутностями.

Зв'язки

Моделювання зв'язків типу «багато-до-багатьох»

Зв'язки типу «багато-до-багатьох» часто створюються на етапах визначення стра­тегії та аналізу предметної області. Під час завершення етапу аналізу вони мають бути змодельовані за допомогою двох зв'язків типу «багато-до-одного» і нової пе­рехідної сутності, яка розділяє закінчення вихідного зв'язку (див. рис. 12).

Взаємовиключність

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

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

Взаємовиключні зв'язки мають такі властивості:

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

• закінчення зв'язку може перетинати лише одна поперечна дуга; майже завжди дуги перетинають закінчення «багато»;

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

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

Надлишкові зв'язки

Зв'язки, які можуть бути виведені з інших зв'язків, називаються надлишковими. ЕR-діаграма не повинна містити надлишкових зв'язків. Хоча у базах даних надлишковість є поширеним засобом досягнення необхідної швидкодії системи, по­дібні рішення мають ухвалюватися проектувальником і не повинні прийматися системним аналітиком.

Каскадне видалення

У реальному світі ми, коли втрачаємо про щось усі відомості, часто неявно втра­чаємо й відомості про якісь інші взаємопов'язані речі. Наприклад, якщо ми вида­лимо всі відомості про квиток, ми неявно видалимо і всі відомості про його посад­кові талони, оскільки вони, як «діти», існують виключно в контексті їхніх зв'язків з квитками («батьками»). Це явище відоме як каскадне видалення і має місце для деяких сутностей, розміщених у закінченнях «багато». У ситуаціях, коли каскад­не видалення неприпустиме, часто діє таке правило: забороняється видаляти не­залежні сутності («батьків»). Наприклад, не можна видалити екземпляр сутності ЕКІПАЖ доти, доки існують члени цього екіпажу.

Для відображення різних правил видалення сутності використовується по­кажчик каскадного видалення:

• X — видаляти всіх «дітей» під час видалення «батька»;

• С — заборонити видалення «батька», якщо існують «діти»;

• N — видалення «батьків» і «дітей» може здійснюватися незалежно. Правило заборони (С) зазвичай має місце в тих випадках, коли залежна сут­ність («дитина») обов'язково має бути пов'язана з «батьком», а незалежне вида­лення (К) — тоді, коли обидва закінчення зв'язку є факультативними.

Каскадне оновлення

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