На підприємстві 5 страница

Аналіз предметної області доцільно розбити на три фази:

- аналіз концептуальних вимог та інформаційних потреб;

- виявлення інформаційних об'єктів і зв'язків між ними;

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

1 Аналіз концептуальних вимог та інформаційних потреб

На етапі аналізу концептуальних вимог та інформаційних потреб необхідно вирішити такі завдання:

- аналіз вимог користувачів до БД (концептуальних вимог);

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

- документування результатів аналізу.

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

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

2 Виявлення інформаційних об'єктів та зв'язків між ними

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

Під час вибору інформаційних об'єктів бажано відповісти на ряд запитань:

1. На які класи можна розподілити дані, що підлягають зберіганню в БД?

2. Яке ім'я можна надати кожному класу даних?

3. Які найбільш цікаві характеристики (з точки зору користувача) кожного класу даних можна виділити?

4. Які імена можна присвоїти вибраним наборам характеристик?

Виділення інформаційних об'єктів - процес інтерактивний. Він здійснюється на підставі аналізу інформаційних потоків та інтерв'ювання споживачів. Характеристики інформаційних об'єктів визначаються тими ж методами.

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

Які типи зв'язків між інформаційними об'єктами?

Яке ім'я можна присвоїти кожному типу зв'язків?

Які можливі типи зв'язків можна використовувати?

Чи мають сенс які-небудь комбінації типів зв'язків?

При необхідності потрібно завдати обмеження на об'єкти, їх характеристики та зв'язки, даючи відповіді на такі запитання:

Яка область значень для числових характеристик?

Які функціональні залежності між характеристиками одного інформаційного об'єкта?

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

Наприклад, твердження, що оклад професора ВНЗ більше, ніж оклад доцента, може розглядатися як обмеження цілісності лише в тому випадку, якщо воно слушне в будь-який момент і не залежить від процедури підвищення заробітної плати, або зміни, наприклад, тарифної сітки.

У загальному випадку розглядаються три види обмежень: внутрішні, явні та змішані. Внутрішні обмеження в основному пов'язані з моделлю даних, яка підтримується СКБД.

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

3 Побудова інформаційної структури

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

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

При концептуальному проектуванні як основна модель використовується модель типу “сутність - зв'язок” (ER-модель). На мові ER-моделі інформаційний об'єкт називають сутністю.

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

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

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

У цьому розділі на підставі аналізу предметної області системи необхідно навести:

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

- перелік зв'язків між сутностями з указівкою типу зв'язку;

- перелік можливих обмежень на значення окремих атрибутів;

- ERдіаграму концептуальної моделі предметної області.

8 Концептуальна модель

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

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

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

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

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

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

Правила побудови концептуальної моделі

1. Кожен атрибут повинен мати унікальне ім'я.

2. Сутність може мати будь-яку кількість атрибутів.

3. Для кожного екземпляра сутності повинне існувати значення кожного його атрибута (правило неперетворення в нуль - Not Null).

4. Жоден з екземплярів сутності не може володіти більше, ніж одним значенням, для її атрибута.

5. При побудові сутності схематично заключають у прямокутник, атрибути - в овал, відносини зв'язків - у ромб.

6. Ключовий атрибут повинен мати підкреслення.

7. Сутності повинні бути іменниками, відношення зв'язків - дієслова.

8. Зв'язок з боку «один» позначається одинарною стрілкою, з боку «багато» - подвійною.

9. Зовнішні ключі на концептуальній моделі не прописуються.

9 Фізична модель БД

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

Фізична модель БД по зовнішніх факторах, що впливають, представлена на рис. 2.2.2.

Рисунок 2.2.2 - Фізична модель БД по зовнішніх факторах, що впливають

10. Введення в реляційні БД

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

Реляційні системи далеко не відразу одержали широке поширення. У той час як основні теоретичні результати в цій області були отримані ще в 70-х роках і тоді ж з'явилися перші прототипи реляційних СКБД, довгий час вважалось неможливим домогтися ефективної реалізації таких систем. Однак поступове нагромадження методів й алгоритмів організації реляційних баз даних і керування ними привели до того, що вже в середині 80-х років реляційні системи практично витиснули зі світового ринку ранні СКБД.

Реляційна модель даних ґрунтується на математичних принципах, що випливають безпосередньо з теорії множин і логіки предикатів. Ці принципи вперше були застосовані в області моделювання даних наприкінці 1960-х рр. доктором Е. Ф. Коддом, у той час працював в IBM, а вперше опубліковані - в 1970р.

Технічна стаття "Реляційна модель даних для більших поділених банків даних" доктори Е. Ф. Кодда, опублікована в 1970 р., є родоначальницею сучасної теорії реляційних БД. Доктор Кодд визначив 13 правил реляційної моделі (які називають 12 правилами Кодда). Ця робота послужила стимулом для великої кількості статей і книг, у яких реляційна модель одержала подальший розвиток. Найпоширеніше трактування реляційної моделі даних належать К.Дейту.

Згідно Дейту, реляційна модель складається із трьох частин:

- структурної частини;

- цілісної частини;

- маніпуляційної частини.

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

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

Маніпуляційна частинаописує два еквівалентних способи маніпулювання реляційними даними - реляційну алгебруй реляційне числення.

12 правил Кодда:

1. Реляційна СКБД повинна бути здатна повністю управляти базою даних через її реляційні можливості.

2. Інформаційне правило - вся інформація в реляційній БД (включаючи імена таблиць і стовпців) повинна визначатися строго як значення в таблицях.

3. Гарантований доступ - будь-яке значення в реляційній БД повинне бути гарантированно доступно для використання через комбінацію імені таблиці, значення первинного ключа й імені стовпця

4. Підтримка порожніх значень (null value) - СКБД повинна вміти працювати з порожніми значеннями (невідомими або невикористаними значеннями), на відміну від значень за замовчуванням і незалежно для будь-яких доменів.

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

6. Вичерпна мова керування даними - принаймні, одна з підтримуваних мов повинна мати чіткий певний синтаксис і бути всеосяжною. Вона повинна підтримувати опис структури даних і маніпулювання ними, правила цілісності, авторизацію й транзакції.

7. Правило відновлення подань (views) - всі подання, теоретично обновлювані, можуть бути обновлені через систему.

8. Вставка, відновлення й видалення - СКБД підтримує не тільки запит на відбір даних, але й вставку, відновлення й видалення

9. Фізична незалежність даних - на програми-додатки й спеціальні програми логічно не впливають зміни фізичних методів доступу до даних і структур сховищ даних.

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

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

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

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

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

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

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

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

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

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

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

11. Компоненти РБД

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

Відносини зручно представляти у вигляді таблиць. На рис. 2.2.3 представлена таблиця (відношення ступеня 5), що містить деякі відомості про працівників гіпотетичного підприємства. Рядки таблиці відповідають кортежам. Кожен рядок фактично являє собою опис одного об'єкта реального світу (у цьому випадку працівника), характеристики якого знаходяться в стовпцях. Можна провести аналогію між елементами реляційної моделі даних й елементами моделі "сутність-зв'язок". Реляційні відносини відповідають наборам сутностей, а кортежі - сутностям. Тому, також як й у моделі "сутність-зв'язок" стовпці в таблиці, що представляють реляційне відношення, називають атрибутами.

Рисунок 2.2.3 - Основні компоненти реляційного відношення.

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

Кілька атрибутів одного відношення й навіть атрибути різних відносин можуть бути визначені на тому самому домені. У прикладі, показаному на рис.2.2.3 атрибути "Оклад" й "Премія" визначені на домені "Гроші". Тому, поняття домену має семантичне навантаження: дані можна вважати порівнянними тільки тоді, коли вони ставляться до одному домену. Таким чином, у розглянутому нами прикладі порівняння атрибутів "Табельний номер" й "Оклад" є семантично некоректним, хоча вони й містять дані одного типу.

Поіменована безліч пар "ім'я атрибута - ім'я домену" називається схемою відношення. Потужність цієї безлічі - називають ступенем або "арністю" відношення. Набір поіменованих схем відношень представляє схему бази даних.

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

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