11.! Етапи проектування та побудови бд

Проектування баз даних відбувається в чотири етапи.

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

Етап концептуального проектування полягає в описі і синтезі інформаційних вимог користувачів у початковий проект БД. Вихідними даними можуть бути сукупність документів користувача при класичному підході або алгоритми додатків (алгоритми бізнесу) при сучасному підході. Результатом цього етапу є високорівневе подання (у вигляді системи таблиць БД) інформаційних вимог користувачів на основі різних підходів.

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

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

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

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

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

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

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

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

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

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

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

Основними причинами низької ефективності проектованих БД можуть бути:

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

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

У цих умовах важливого значення набувають питання автоматизації розробки.

12.! Схема даних реляційної БД – адекватне відображення інформаційно – логічної моделі. Посилальна цілісність.

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

• принцип “поділяй і пануй” – принцип розв’язання складних проблем шляхом їх розбиття на множину менших незалежних задач, легких для розуміння і розв’язання;

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

Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може призвести до непередбачуваних наслідків (у тому числі і до провалу проекту загалом). Основними з цих принципів є такі:

• принцип абстрагування – полягає у виділенні істотних аспектів системи і відволікання від несуттєвих;

• принцип формалізації – полягає в необхідності суворого методичного підходу до розв’язання проблеми;

• принцип несуперечливості – полягає в обґрунтованості й узгодженості елементів;

• принцип структурування даних – полягає в тому, що дані повинні бути структуровані й ієрархічно орґанізовані.

У структурному підході побудова схем баз даних здійснюється за допомогою ERD (Entity-Relationship Diagrams) – діаграм “сутність-взаємозв'язок”. Побудова ER¬-діаграм Ціль моделювання даних полягає в проектуванні концептуальної схеми бази даних у формі однієї або декількох локальних моделей, що відносно легко можуть бути відображені в будь-яку систему баз даних. Найбільше поширеним засобом моделювання даних є діаґрами “сутність-взаємозв'язок” (ERD). З їхньою допомогою визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відношення один з одним (зв'язки). ERD безпосередньо використовуються для проектування реляційних баз даних. Нотація ERD була уперше введена П. Ченом (Chen) і одержала подальший розвиток у роботах Баркера. Зараз існує декілька нотацій ERD, з яких “найзручнішими” можна вважати нотації Баркера чи Кровз-Фут (Crow’s Foot). Перший крок моделювання – отримання інформації про предметну область та виділення сутностей. Сутність (Entity) - реальний або уявлюваний об'єкт, що має істотне значення для аналізованої предметної області, інформація про який підлягає збереженню (рис. 1). Рис.1. Графічне зображення сутності. Кожна сутність повинна мати унікальний ідентифікатор. Кожний примірник сутності повинний однозначно ідентифікуватися і відрізнятися від всіх інших примірників даного типу сутності. Кожна сутність повинна мати наступні властивості:

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

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

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

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

Розглянемо приклад. Нехай необхідно створити базу даних для збереження інформації про розклад викладача та відпрацьованих ним занять. Аналізуючи цю ПО, виділимо 5 сутностей (рис. 2). Рис.2. Приклад сутностей. Наступним кроком моделювання є ідентифікація зв'язків. Зв'язок (Relationship) – це поіменована асоціація між двома сутностями, суттєва для предметної області, що аналізується. Зв'язок – це асоціація між сутностями, при якому, як правило, кожний примірник однієї сутності, що називається сутністю-предком, асоційований із довільною (у тому числі нульовою) кількістю примірників іншої сутності, що називається сутністю-нащадком, а кожний примірник сутності-нащадка асоційований точно з одим примірником сутності-предка. Таким чином, примірник сутності-нащадка може існувати тільки при існуванні сутності-предка. Зв'язок може мати ім'я, у вигляді граматичного звороту дієслова, яке розташовується біля лінії зв'язку. Ім'я кожного зв'язку між двома даними сутностями повинно бути унікальним, але імена зв'язків у моделі не зобов'язані бути унікальними. Ім'я зв'язку завжди формується з погляду предка, так що воно може бути утворене з'єднанням імені сутності-предка, імені зв'язку, виразу ступеня й імені сутності-нащадка. Наприклад, зв'язок предмету й теми може бути відображений наступним чином:

• предмет може включати 1 або більше тем;

• тема повинна належати до рівно одного предмету.

Ступінь зв'язку й обов'язковість графічно зображаються в такий спосіб (рис. 3). Рис.3. Графічне зображення зв’язків. Таким чином, два речення, що описують зв'язок предмету з темою, графічно будуть відображені в такий спосіб (рис. 4). Рис.4. Приклад зв’язків між сутностями. Після описання зв'язків між іншими сутностями одержимо наступну схему у нотації Crow’s Foot (рис. 5). Рис.5. Приклад схеми зв’язків між сутностями ПО. Останнім кроком моделювання є визначення атрибутів. Атрибут – будь-яка характеристика сутності, що є істотною для аналізованої ПО і призначена для кваліфікації, ідентифікації, класифікації, кількісної характеристики або відображення стану сутності. Атрибут подає тип характеристик або властивостей, асоційованих із множиною реальних або абстрактних об'єктів (людей, місць, подій, станів, ідей, пар предметів і т.д.). Примірник атрибута – це визначена характеристика окремого елемента множини. Примірник атрибута визначається типом характеристики і її значенням – значенням атрибута. У ER-моделі атрибути асоціюються з конкретними сутностями. Таким чином, примірник сутності повинний мати єдине визначене значення для асоційованого атрибута.

Інфологічна модель БД

Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об’єкту управління, без урахування особливостей і специфіки конкретної СУБД. Мета інфологічного проектування — створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється інформаційно-логічна модель, яка має відповідати таким вимогам:

• коректність схеми БД, тобто адекватне відображення модельованої ПО;

• простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СУБД (сіткові, ієрархічні, реляційні);

• ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.

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

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

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

Інформаційний об’єкт — деяка сутність ПО, яку необхідно відображувати в БД з точки зору прикладної програми чи користувача БД. Це може бути предмет, факт, дія, явище чи поняття. Кожен об’єкт описується його властивостями, тобто його атрибутами. Крім атрибутів та інформаційних об’єктів, складовими частинами інфологічної моделі є інформаційний запит, запитувальний зв’язок і структурний зв’язок.

Інформаційний запит — словесний опис інформаційної потреби користувача чи прикладної програми. 

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

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

 Екземпляр структурного зв’язку — це екземпляр об’єкта власника та певна су- купність зв’язаних з ним екземплярів підпорядкованого об’єкта.

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

Внутрішній рівень пов’язаний з фізичним розміщенням даних у пам’яті ЕОМ. На цьому рівні формується фізична модель БД, яка містить структури зберігання даних у пам’яті ЕОМ, включаючи опис форматів даних, порядок їх логічного чи фізичного упорядкування, розміщення за типами пристроїв, а також характеристики і шляхи доступу до даних. Від параметрів фізичної моделі залежать такі характеристики функціонування БД: обсяг пам’яті і час реакції системи. Фізичні параметри БД можна змінювати у процесі її експлуатації (не змінюючи при цьому опису інших рівнів) з метою підвищення ефективності функціонування системи. Структура таблиць-сутностей БД визначається на етапах інфологічного і логічного проектування, а формування структури — на етапі фізичного проектування БД. Структура  ж таблиці — це пойменована сукупність логічно взаємозв’язаних атрибутів