Інформатика та ІКТ_pdf / tema2

Тема 2. Концепція проектування БД План

1.Основні поняття проектування БД.

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

3.Логічне проектування.

4.Користувачі та розробники БД.

1. ОСНОВНІ ПОНЯТТЯ ПРОЕКТУВАННЯ

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

(БД).

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

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

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

Етапи проектування:

Процес проектування БД складається з трьох етапів: концептуального,

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

Результат кожного етапу – відповідна модель предметної галузі (ПГ), що відображає трирівневу архітектуру (концептуальний, зовнішній, внутрішній рівні) будь-якої автоматизованої ІС.

Відповідно до цього розрізняють:

1)інфологічну модель (концептуальний етап)

2)даталогічну модель (логічний етап)

3) фізичну модель (фізичний етап)

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

Класифікація моделей даних

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

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

Крім того, сучасні СУБД широко використовують сторінкову організацію даних.

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

Фактографічні моделі даних відповідають уявленню інформації у вигляді певних структур даних (дерево, мережа, таблиця).

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

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

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

2. ПОБУДОВА КОНЦЕПТУАЛЬНОЇ МОДЕЛІ

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

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

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

екземплярами сутності.

Сутність та екземпляр сутності можуть бути визначені наступним чином:

Сутність: СТУДЕНТ (ПІБ, Група, Рік_народження)

Екземпляр сутності: (Петров П.І., 13, 1992)

Кожна сутність володіє набором атрибутів – властивостей. Значення атрибутів можуть часто змінюватися, у той час як сутність залишається тією ж самою. Так, у екземпляра сутності СТУДЕНТ може змінитися значення атрибута ПІБ, але сама сутність залишиться тією ж.

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

Наприклад, екземпляр сутності “Факультет” може однозначно ідентифікуватися будь-яким з перших двох зазначених атрибутів:

ФАКУЛЬТЕТ (Код_факультета, Назва_факультета, ПІБ_декана)

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

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

Ідентифікацію деяких сутностей іноді доводиться здійснювати за допомогою

складових ключів, які включають кілька атрибутів.

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

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

Розглянемо сутності ВИКЛАДАЧ і КУРС. Між цими сутностями можна визначити зв'язок ЧИТАЄ, зіставивши кожному викладачеві ту дисципліну, за якою він читає лекції, або, навпаки, кожній дисципліні - викладача. Зв'язок ЧИТАЄ складений з безлічі пар, у кожній з яких викладач - із сутності ВИКЛАДАЧ, а дисципліна – з сутності КУРС.

Зв'язок – взаємозв'язок (асоціація) між сутностями, який вказує яким чином сутності співвідносяться один до одного або взаємодіють між собою.

Для представлення концептуальної моделі використовують різні методи і моделі. Наприклад, модель "сутність" – “атрибут " - "зв'язок” (“entity”, “attribute”, “relationship” - EAR) описує предметну галузь на концептуальному рівні у вигляді

EAR-діаграм.

Дуже часто модель називають ER-модель, упускаючи атрибути об'єкта. Дану модель було запропоновано в 1976 р. американським вченим Пітером Ченом (Peter Pin-Shan Chen), яка стала стандартом при інфологічному моделюванні БД. Модель "сутність-атрибут-зв'язок" відноситься до семантичних моделей. Семантичне моделювання даних, пов'язане зі смисловим вмістом даних, незалежно від їх подання в ЕОМ.

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

Між сутностями можливі чотири типи зв'язків:

один - до одного (1↔1),

один - до багатьох (1↔∞),

багато - до одного (∞↔1),

багато - до багатьох (∞↔∞).

Характеристика типів зв'язків:

Зв'язок 1 ↔ 1: в будь-який момент часу один екземпляру першого

інформаційного об'єкту (ІО) відповідає один екземпляр іншого ІО. Зв'язок 1 ↔ ∞ : одному екземпляру першого ІО відповідає

0, 1, 2, ... екземплярів іншого і навпаки, кожному екземпляру другого ІО відповідає 0 або 1 екземпляр першого ІО.

Зв'язок ∞ ↔ 1: аналогічно як попередній (1 ↔ ∞).

Зв'язок ∞ ↔ ∞ : одному екземпляру першого ІО відповідає 0, 1, 2 , ... екземпляру іншого ІО і навпаки.

Приклади:

1. Студент 1 ↔ 1 Сесія: кожен студент має певний набір екзаменаційних

оцінок в сесію. Мається на увазі ІО Сесія як набір оцінок за поточний семестр.

2.Стипендія 1 ↔ ∞ Студент: вид (і сума) стипендії може багаторазово повторюватися для різних студентів за результатами сесії.

3.Студент ∞ ↔ ∞ Викладач: один студент навчається у багатьох викладачів і навпаки, один викладач навчає багатьох студентів.

Концептуальна модель застосовується для структурування предметної галузі

зурахуванням інформаційних інтересів користувачів ІС, вона не залежить ні від програмних, ні від технічних рішень.

Розглянемо приклад: проектування БД “Навчальний процес".

Фрагмент концептуальної моделі у вигляді EAR-діаграм «сутність» – «атрибут» - «зв'язок», представлений на рисунку.

У результаті аналізу предметної галузі виділено 4 інформаційних об'єкти (Студент, Група, Викладач, Кафедра), їх властивості та зв'язки.

3. ЕТАП ЛОГІЧНОГО ПРОЕКТУВАННЯ

Основним завданням логічного проектування є розробка логічної схеми (моделі), орієнтованої на обрану систему управління базами даних (СУБД).

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

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

Існуючі СУБД діляться за типами моделей даних на реляційні, ієрархічні і

мережні.

Процес логічного проектування складається з наступних дій:

1)вибір конкретної СУБД;

2)відображення концептуальної схеми у вигляді логічної схему, що відповідає зовнішньому рівню архітектури будь-якої автоматизованої ІС;

3)вибір ключів;

4)опис мови запитів.

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

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

Приклад відношення “План рахунків”

Домен визначається як допустима потенційна множина значень певного

типу.

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

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

Нормалізація БД

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

У процесі нормалізації забезпечується захист цілісності даних шляхом усунення їх дублювання. У результаті вихідна таблиця розбивається на дві або більше пов'язаних таблиць, які можуть бути "зібрані" разом за допомогою операції об'єднання. Остаточна мета нормалізації зводиться до отримання такого проекту БД, в якому «кожен факт з'являється лише в одному місці». Використання ненормалізованих таблиць може призвести до порушення цілісності даних (протиріччю інформації) в БД.

Інструкція щодо нормалізації - це набір стандартів (правил) проектування даних, що називаються нормальними формами (НФ).

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

Створення таблиць у відповідності з цими стандартами називається нормалізацією.

1 нормальна форма (НФ)

Реляційна таблиця (РТ) знаходиться в першій НФ, якщо атрибути однієї сутності (об'єкту) мають єдине значення. Якщо в будь-якому атрибуті є значення, які повторюються, таблиця не знаходиться в першій НФ.

Наприклад, задано наступне відношення:

ПРЕДМЕТ (Код предмета, Назва, Цикл, Об'єм годин, Викладачі).

Це відношення не знаходиться в 1НФ, оскільки атрибут Викладачі вказує на можливість наявності декількох прізвищ викладачів у записі, що відноситься до конкретного предмету. Тобто декілька викладачів можуть брати участь у веденні однієї дисципліни.

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

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

ПРЕДМЕТ (Код предмета, Назва, Цикл, Об'єм годин); ВИКЛАДАЧ (Код викладача, ПІБ, Посада, Оклад, Адреса, Код предмета).

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

А якщо врахувати, що насправді один лектор може читати більше однієї дисципліни, так само як одну і ту ж дисципліну можуть читати кілька лекторів, необхідно відмовитися від жорсткої прив'язки викладача до предмета в сутності ВИКЛАДАЧ, створивши додаткову сутність ВИВЧЕННЯ, яка буде показувати, як пов'язані між собою викладачі та предмети:

ПРЕДМЕТ (Код предмета, Назва, Цикл, Об'єм годин); ВИКЛАДАЧ (Код викладача, ПІБ, Посада, Оклад, Адреса); ВИВЧЕННЯ (Код предмета, Код викладача).

2 нормальна форма (НФ)

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

Повернувшись до останнього прикладу, зауважимо, що атрибут Цикл в сутності ПРЕДМЕТ, що характеризує належність предмета до циклу гуманітарних, природничо-наукових, загально або спеціальних дисциплін, не повністю залежить від унікального ідентифікатора Код предмета, оскільки різні предмети можуть мати одне і те ж значення атрибута Цикл. Перенесемо цей атрибут в нову сутність ЦИКЛ і отримаємо чотири взаємопов'язаних сутності:

ПРЕДМЕТ (Код предмета, Назва, Цикл, Об'єм годин); ПРЕДМЕТ (Код предмета, Назва, Об'єм годин, Код циклу); ЦИКЛ (Код циклу, Назва циклу); ВИКЛАДАЧ (Код викладача, ПІБ, Посада, Оклад, Адреса); ВИВЧЕННЯ (Код предмета, Код викладача).

3 нормальна форма (НФ)

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

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

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

При зміні посадового окладу в цьому випадку потрібно буде міняти дані в кожному записі, що містить цю посаду, отже, потрібно створити нову сутність ПОСАДУ з атрибутами Назва посади та Оклад і зробити посилання від сутності

ВИКЛАДАЧ на сутність ПОСАДУ:

ВИКЛАДАЧ (Код викладача, ПІБ, Посада, Оклад, Адреса); ПРЕДМЕТ (Код предмета, Назва, Об'єм годин, Код циклу); ЦИКЛ (Код циклу, Назва циклу); ВИКЛАДАЧ (Код викладача, ПІБ, Код посади, Адреса); ПОСАДУ (Код посади, Назва посади, Оклад); ВИВЧЕННЯ (Код предмета, Код викладача).

4 нормальна форма (НФ)

Четверта НФ забороняє незалежні відношення типу один – до багатьох між ключовими і неключовими атрибутами. Нормальні форми більш високих порядків розглядати не будемо, тому що вони є лише бажаними, але не обов'язковими. Більшість розробників баз даних визнають, що подання даних у третій та четвертій НФ повністю задовольняє всі їхні потреби

Концептуальна модель як логічна схема

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

Наступний етап - фізичне проектування: логічна модель даних відображається на фізичну схему, в результаті виходить фізична модель, що визначає розміщення даних, методи доступу і техніку індексування. Фізичний рівень проектування – власне дані, розташовані в файлах або в сторінкових структурах, розташованих на зовнішніх носіях інформації. Фізична модель відповідає внутрішньому рівню архітектури будь-якої АІС.

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

Порядок проектування БД

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

2)подання концептуальної моделі ПГ у вигляді EAR-діаграм;

3)вибір конкретної СУБД для реалізації БД, наприклад, MS Access;

4)логічне проектування (створення даталогічної моделі); визначення ключів кожної таблиці (первинних і зовнішніх), уточнення зв'язків між таблицями; створену “чорнову" структуру БД (сукупність взаємопов'язаних таблиць) слід проаналізувати на предмет відповідності правилам нормалізації, при необхідності внести зміни (в СУБД MS Access для цієї мети служить інструмент Аналізатор таблиць);

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

4. КОРИСТУВАЧІ ТА РОЗРОБНИКИ БАЗ ДАНИХ

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

1.Проектування

2.Реалізація

3.Експлуатація

4.Модернізація та розвиток

5.Зняття з експлуатації

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

адміністратори даних і баз даних

розробники баз даних

прикладні програмісти

кінцеві користувачі.

Адміністратор даних

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

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

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

Таким чином, адміністратор даних працює як менеджер, а не як фахівець з технічних питань.

Технічний спеціаліст, відповідальний за реалізацію рішень адміністратора даних - це Адміністратор БД.

Адміністратори БД

Адміністратор БД (системний адміністратор) - здійснює технічне обслуговування СУБД. Він створює і модифікує структуру БД, відповідає за швидкодію системи, за архівування даних, за відновлення системи після збою, за технічне управління правами доступу (привілеями).

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

У порівнянні з адміністратором даних, обов'язки адміністратора БД носять більш технічний характер, і для нього необхідне знання конкретної СУБД і системного оточення.

В одних організаціях між цими ролями не робиться відмінностей, а в інших