Побудова інформаційної моделі

 

Огляд

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

¨    понизити надлишовість даних;

¨    підвищити їх надійність.

 

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

Життєвий цикл довільного програмного продукту, в тому числі і СУБД ,  складається в загальному із таких стадій:

¨    проектування;

¨    реалізація;

¨    експлуатація.

 

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

 

Означення інформаційної моделі

 

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

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

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

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

 

Типи представлень інформаційних моделей

 

Для опису інформаційної задачі використовуються три види представлення ІМ:

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

n     зовнішнє - відображає уявлення про задачу з точки зору конкретного споживача, тобто особи, яка розв”язує вузьку задачу роботи системи на конкретному робочому місці; значить, кожна інформаційна система буде мати кілька зовнішніх представлен  ІМ

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

 

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

 

Малюнок 1. Взаємозв”язок трьох видів представлення ІМ.

 

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

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

 

Структура інформаційної моделі

 

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

 

Приклади об”єктів , атрибутів  та їх значень

 

Об”єкт

Атрибут

Значення

Пацієнт

Прізвище

Іваненко

 

Ім”я

Тарас

 

Діагноз

виразка шлунку

Захворювання

Назва хвороби

ішемічна хвороба серця

 

категорія

серцево-судинні захворювання

 

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

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

            Взаємозв”язок між об”єктами виражає відображення або зв”язок між двома множинами даних. Розрізняють три типи взаємозв”язків:

 

Малюнок 2 . Зв”язок “один-до-одного”

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

Малюнок 3.

n     “один-до-багатьох”  допускає зв”язок з одним об”єктом кількох інших об”єктів, наприклад, масив лікарів і масив пацієнтів, коли до певного лікаря “прикріплені”  кілька пацієнтів. 

 

Малюнок 4. Зв”язок “багато-до-багатьох”

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

 

 

Малюнок 5 . Реалізація зв”язку “багато-до-багатьох”

            У Visual FoxPro, як і вбільшості інших СУБД  для персональних комп”ютерів останній тип зв”язку не підтримується безпосередньо. Для його організації комбінують два зв”язки “один-до-багатьох”  через проміжкову таблицю. У проміжковій таблиці  будуть зберігатися відомості про лікування конкретного пацієнта у конкретній клініці. 

 

 

Типи моделей даних

 

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

n     ієрархічна модель організовує дані у вигляді деревовидної структури і є реалізацією логічних зв”язків за типом “ціле-частина”. Прикладом ієрархічної моделі є довільна адміністративна структура

n     мережева модель дозволяє довільному об”єкту бути пов”язаним з довільним іншим об”єктом. Мережеві моделі утворюють складні структури, що створює певні труднощі при потребі модернізації або розвитку ІМ.

n     реляційна модель  представляє об”єкти і взаємозв”язки між ними у вигляді таблиць. Вперше вона була запропонована в 1970 році доктором Е.Ф.Коддом (E.F.Codd). На цій моделі даних будуються практично всі сучасні СУБД для комп”ютерів. В Visual FoxPro реляційна модель отримала подальший розвиток в плані наближення до класичних канонів побудови реляційної  моделі.

 

Вимоги до бази даних

 

Добре спроектована база даних

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

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

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

·      Задовільняє вимоги споживачів до продуктивності бази даних. При великих обсягах інформації питання збереження продуктивності починають відігравати головну роль; відразу “випливають” всі прорахунки етапу проектування.

 

Переваги технології побудови реляційної бази даних

 

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

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

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

n     чіткий взаємозв”язок атрибутів з різних відношень і файлів;

n     незалежність даних від прикладної програми;

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

 

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

 

 

Основні кроки проектування бази даних.

 

1.      Визначити інформаційні потреби бази даних

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

3.      Поставити у відповідність сутностям та характеристикам – таблиці і стовпчики (поля) в нотації вибраної вами СУБД  (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle і т.д.).

4.      Визначити атрибути, які унікальним чином ідентифікують кожен об”єкт.

5.      Виробити правила, які будуть встановлювати і підтримувати цілісність даних.

6.      Встановити зв”язки між об”єктами (таблицями і стовпчиками), провести нормалізацію таблиць

7.      Спланувати питання надійності даних і, при потребі, збереження секретності інформації. 

 

Математична модель реляційної бази даних

 

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

Нехай задано n множин D1,D2,...,Dn. Тоді R є відношенням над цими мноинами, якщо R є множиною впорядкованих наборів вигляду   <d1,d2,...,dn>, де d1 – елемент з D1, d2 – елемент з D2, ..., dn - елемент з Dn. При цьому набори вигляду <d1,d2,...,dn> називаються кортежами, а множини D1,D2,...,Dnдоменами.  Кожен кортеж складається з елементів, що вибираються із своїх доменів. Ці елементи називаються атрибутами, а їх значення – значеннями атрибутів. Малюнок представляє графічне зображення відношення з різних точок зору. 

 

 

 

Малюнок 6 . Терміни реляційної теорії і їх співвідношення з обробкою медичних даних

Легко помітити, що відношення є відзеркаленням деякої сутності реального світу (в даному випадку – сутності “пацієнт”) і з точки зору обробки даних є таблицею. Оскільки в локальних базах даних кожна таблиця розміщується в окремому файлі, то з точки зору розміщення даних для локальних баз даних відношення можна ототожнювати з файлом. Кортеж є рядком в таблиці, або що те ж саме, записом. Атрибут же є стовпчиком таблиці, або – полем в запису. Домен в свою чергу є деяким узагальненим типом, який може бути джерелом для типів полів у запису. Отже, наступні трійки термінів є еквівалентними:

·      відношення, таблиця, файл (для локальних баз даних)

·      кортеж, рядок, запис

·      атрибут, стовпчик, поле. 

 

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

 

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

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

Для підтримки посилальної цілісності даних в багатьох СУБД  є механізм так званих зовнішніх ключів. Суть цього механізму полягає в тому, що деякому атрибуту (або групі атрибутів) одного відношення призначається посилання на первинний ключ іншого відношення; тим самим закріпляються зв”язки підлеглості між цими відношеннями. При цьому відношення, на первинний ключ якого посилається зовнішній ключ іншого відношення, називається master-відношенням, або головним відношенням; а відношення, від якого виходить посилання, називається detail-відношенням. Після призначення такого посилання СУБД має змогу автоматично відслідковувати питання “непорушності” зв”язків між відношеннями, а саме:

·      якщо ви спробуєте вставити в підлеглу таблицю запис, для зовнішнього ключ а якої не  існує відповідності в головній таблиці  (наприклад, там немає ще запису з таким первинним ключом), СУБД  згенерує помилку;

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

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

 

Зауваження. Існує два підходи до знищення і зміни записів головної таблиці

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

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

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

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

 

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

 

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

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

·     які дані використовуються різними додатками; чи зможуть вашы додатки спыльно використовувати будь-якы з цих даних;

·     хто буде вводити дані в базу і в якій формі; як часто будуть змінюватися дані;

·     чи досить буде для вашої предметної області однієї бази даних, або ж вам буде потрібно кілька баз даних з різними структурами;

·     яка інформація є найчутливішою до швидкості її вилучення і зміни.

 

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

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

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

·     ідентифікацію об”єктів, які здійснюють цю функціональну діяльність, і формування  з їх операцій послідовності подій, які допоможуть вам ідентифікувати всі сутності і взаємозв”язки між ними. Наприклад, процес “ведення обліку пацієнтів” ідентифікує такі сутності як ПАЦІЄНТ, АНАЛІЗИ КРОВІ, ВІДДІЛЕННЯ і т.ін.

·     ідентифікацію характеристик цих сутностей. Наприклад, сутність ПАЦІЄНТ може включати такі характеристики як Ідентифікатор пацієнта, Прізвище, Ім”я, Адреса, Стать, Анамнез, Діагноз, Дата діагнозу і т.д.

·     ідентифікацію взаємозв”язків між сутностями. Наприклад, яким чином сутності ПАЦІЄНТ, АНАЛІЗИ КРОВІ, ВІДДІЛЕННЯ взаємодіють один з одним? Пацієнту відповідатимуть кілька аналізів крові (зроблених в різний час) і він значиться в одному відділенні; при цьому в одному відділенні може знаходитися багато пацієнтів.

 

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

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

 

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

 

5. П”ятий крок передбачає вироблення правил, які будуть встановлювати та підтримувати цілісність даних. Будучи означеними, такі правила в клієнт-серверних СУБД підтримуються автоматично - сервером баз даних; в локальних же СУБД їх підтримку доводиться покладати на додаток споживача.

Ці  правила включають:

n   означення типу даних

n   вибір набору символів, що відповідають даній країні

n   створення полів, що опираються на домени

n   встановлення значень за припущенням

n   означення обмежень цілісності

n   означення умов перевірки.

 

6. На шостому кроці встановлюются зв”язки між об”єктами (таблицями і стовпчиками) і проводиться дуже важлива операція для уникнення надлишковості даних - нормалізація таблиць.

Кожен з різних типів зв”язків повинен бути змодельований в базі даних. Існує кілька типів зв”язків:

n   зв”язок “один-до-одного”

n   зв”язок “один-до-багатьох”

n   зв”язок “багато-до-багатьох”

 

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

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

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

            Зв”язок “багато-до-багатьох” в явному вигляді в реляційних базах даних не підтримується. Однак, є ряд способів непрямої реалізації такого зв”язку, які успішно заміняють його відсутність. Один з найрозповсюдженіших способів полягає у введенні додаткової таблиці, рядки якої складаються із зовнішніх ключів, що посилаються на первинні ключі обох таблиць. Наприклад, є дві таблиці : ПАЦІЄНТИ та ХІМІОПРЕПАРАТИ. Один пацієнт може використовувати в ході лікування різні хімічні препарати, в той час як кожен хіміопрепарат може вживатися різними пацієнтами.  Для реалізації такого зв”язку “багато-до-багатьох”  вводиться додаткова таблиця, назвемо її ХІМІОПРЕПАРАТИ_ПАЦІЄНТА, рядок якої буде мати два зовнішніх ключі: один буде посилатися на первинний ключ в таблиці ПАЦІЄНТИ, а другий - на первинний ключ в таблиці ХІМІОПРЕПАРАТИ. Отже, в таблицю ХІМІОПРЕПАРАТИ_ПАЦІЄНТА можна записувати довільну кількість пацієнтів і довільну кількість хіміопрепаратів. 

                                                                                                                                                      

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

 

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

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

n   дані легко поновлювати або знищувати

n   виключається можливість неузгодження копій даних

n   зменшується можливість введення некоректних даних.

 

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

 

Процес нормалізації  полягає в зведенні таблиць до так званих нормальних форм. Існує кілька видів нормальних форм : перша нормальна форма (1НФ), друга нормальна форма (2НФ), третя нормальна форма (3НФ), нормальна форма Бойса-Кодда (НФБК), четверта нормальна форма (4НФ), п”ята нормальна форма (5НФ). З практичної точки зору досить трьох перших форм  - варто враховувати час, що затрачається системою для “з”єднання” таблиць при відображенні їх на екрані. Тому ми обмежимося вивченням процесу зведення відношень до перших трьох форм

Цей процес включає:

 

n   усунення груп, що повторюються (зведення до 1НФ)

n   знищення частково залежних атрбутів (зведення до 2НФ)

n   знищення транзитивно залежних атрибутів  (зведення до 3НФ).

 

            Розглянемо кожен з процесів детальніше.

 

Зведення до першої нормальної форми

 

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

n     аномалії включення, які викликані тим, що ключові елементи не можуть приймати нульових значень;

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

n     аномалії знищення. При знищенні запису із таблиці  втрачаються усі пов”язані із ним дані

 

Коли поле в даному записі містить більше як одне значення для кожного входження первинного ключа, такі групи даних називаються групами, що повторюються. 1НФ не припускає наявності таких багатозначних полів. Розглянемо приклад бази даних  лікувального закладу, що містить таблицю ПАЦІЄНТИ із такими значеннями (атрибут, виділений курсивом, є первинним ключом):

 

Таблиця А

Номер_пацієнта

Прізвище

Ім”я

Група_крові

Rh

Дата_аналізу_крові

К-сть_еритроцитів

1

Коваленко

Іван

1

+

12.04.99

норма

1

Коваленко

Іван

1

+

12.09.99

норма

2

Поліщук

Тарас

2

-

12.09.99

норма

5

Корнієнко

Олег

2

+

13.09.99

норма

 

 

Для зведення цієї таблиці  до 1НФ ми повинні усунути атрибут  (поле) Дата_аналізу_крові з таблиці ПАЦІЄНТИ і створити нову таблицю АНАЛІЗИ_КРОВІ, в якій означити первинний ключ, що є комбінацією номера пацієнта і датою його аналізу крові (Номер_пацієнта + Дата_аналізу_крові - див. Табл. Б). Тепер для кожного аналізу крові різні рядки; тим самим ми усунули групи, що повторюються. 

 

Таблиця Б. АНАЛІЗИ_КРОВІ

 

Номер_пацієнта

Дата_аналізу_крові

К-сть_еритроцитів

1

12.04.99

норма

1

12.09.99

норма

2

12.09.99

норма

5

13.09.99

норма

 

 

Зведення до другої нормальної форми

 

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

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

 Наприклад, припустимо, що ми хочемо розподілити пацієнтів за захворювання ми (поставленому діагнозу). Для цього створимо таблицю ЗАХВОРЮВАННЯ із складовим первинним ключом, що включає номер пацієнта та ідентифікатор захворювання (Номер_пацієнта + ІД_захворювання).

 

Таблиця В. ЗАХВОРЮВАННЯ

 

Номер_пацієнта

Ід_захворювання

Прізвище

Назва_захворювання

Опис_захворювання

1

ФРН

Коваленко

Фарингіт

<blob>

2

ТНЗ

Поліщук

Тонзиліт

<blob>

5

ЛРН

Корнієнко

Ларингіт

<blob>

 

У цій таблиці  виникає така проблема. Атрибути Назва_захворювання  та опис_захворювання відносяться до захворювання як до сутності, значить, залежать від атрибуту ІД_захворювання (що є частино. Первинного ключа), але не від атрибуту Номер_пацієнта. Отже, вони є частково залежними від складового первинного ключа. Те ж можна сказати і про атрибут Прізвище, який залежить від атрибуту Номер_пацієнта, але не залежить від атрибуту ІД_захворювання. Для нормалізації  цієї таблиці (зведення її до 2НФ) знищимо з неї атрибути Номер_пацієнта і Прізвище і створимо другу таблицю (назвемо її ПАЦІЄНТ), яка буде містити лише ці два атрибути, і вони ж будуть складати її первинний ключ. 

 

Зведення до третьої нормальної форми

 

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

Припустимо, наприклад, що ми добавили поля Номер_головного_симптому та Інші_захворювання_із_цим_симптомом в таблицю ЗАХВОРЮВАННЯ, що знаходиться в 2НФ (первинним ключом є поле ІД_захворювання). Атрибут Інші_захворювання_із_цим_симптомом логічно пов”язаний з атрибутом Номер_головного_симптому, неключовим атрибутом, але не з атрибутом ІД_захворювання, що є первинним ключом (табл. Г).

 

Таблиця Г. ЗАХВОРЮВАННЯ

 

Ід_захворювання

Назва_захворювання

Опис_захворювання

Номер_головного_симптому

Інші_захворювання_із_цим_симптомом

ФРН

Фарингіт

<blob>

3

Тонзиліт, грип, 

ТНЗ

Тонзиліт

<blob>

3

Фарингіт, грип

ЛРН

Ларингіт

<blob>

4

Пухлина гортані

 

Для нормалізації цієї таблиці (зведення її в 3НФ) знищимо атрибут Інші_захворювання_із_цим_симптомом, змінимо Номер_головного_симптому на Головний_симптом і зробимо атрибут Головний_симптом зовнішнім ключом, що посилається на атрибут Номер_симптому в таблиці СИМПТОМИ. Після цього таблиці  ЗАХВОРЮВАННЯ та СИМПТОМИ будуть виглядати таким чином:

 

Таблиця Д. ЗАХВОРЮВАННЯ

 

Ід_захворювання

Назва_захворювання

Опис_захворювання

Головний симптом симпт

ФРН

Фарингіт

<blob>

3

ТНЗ

Тонзиліт

<blob>

3

ЛРН

Ларингіт

<blob>

4

 

Таблиця Е. СИМПТОМИ

 

Номер_симптому

Назва_симптому

Захворювання _із_цим_симптомом

3

Біль горла

Тонзиліт, фарингіт, грип, 

4

Захрип голос

Ларингіт, пухлина гортані

 

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

 

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

n   хто буде мати права (і які) на використання бази даних

n   хто буде мати права на модифікацію, вставку і знищення даних

n   чи потрібно робити відмінність в правах доступу

n   яким чином забезпечити загальний режим захисту інформації і т.ін. 

 

Дані, які потрібно зберігати

 

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

n     частота використання даного показника;

n     складність підрахунку для отримання показника;

n     наскільки часто  величина розрахункового показника змінюється за тривалий проміжок часу.

 

Використання кодів замість природніх атрибутів

 

Складно формалізувати питання про потребу використання кодів замість природніх атрибутів . Коди доцільно вводити в таких випадках:

 

n     природній атрибут  повинен відігравати роль ключ ового, але не володіє властивістю унікальності;

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

n     природній атрибут може змінювати своє значення з часом.

 

Реалізація атрибутів  в СУБД

 

В СУБД  атрибути називаються полями БД. Їх тип і розмір визначаються, виходячи з фізичної природи даних.

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

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

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

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

            Альтернативним ключом  (Alternate Key) називається ключ, що відповідає тим же умовам, але не використовується в даний момент для пошуку.

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

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

 

Операції над таблицями

 

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

 

n     Вибірка - це генерація запиту за алгоритмом: “Вибрати з <ім”я таблиц > ті записи, які задовольняють умову <умова>, і відібрані записи помістити в <результат>. У Visual FoxPro найефективнішим механізмом реалізації вибірки є команда SELECT-SQL з поміщенням результату в курсор.

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

n     Проекція - це генерація запиту за алгоритмом: “Вибрати всі значення <ім”я поля> з <ім”я таблиці > і <помістити в результат>”.  Проекція  є свого роду “вертикальна” вибірка з таблиці.  У Visual FoxPro проекція реалізується як командою SELECT-SQL , так і установкою SET FIELDS  або ж опцією FIELDS

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

n     Переріз - за запитом створюється третя таблиця, що містить лише ті записи першої таблиці, що є у другій

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

 

            Останні три операції в Visual FoxPro реалізуються командою SELECT-SQL

 

Питання та вправи

 

1. Для чого призначена інформаційна модель ?

2. Який тип інформаційної моделі служить побудові реляційної бази даних?

3. Охарактеризуйте математичну модель реляційної  бази даних.

4. Який зв”язок між об”єктами носить назву “багато-до-багатьох”  і як його можна реалізувати в реляційній базі даних ?

5. Які основні кроки проектування бази даних?

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

 

№ п/п

Назва атрибуту

Опис атрибуту

1

SURNAME_NAME_WOMAN

Прізвище, ім”я, по-батькові вагітної

2

AGE

Вік вагітної

3

PROFESSION_WIFE

Професія вагітної

4

SURNAME_NAME_HUSBAND

Прізвище, ім”я, по-батькові чоловіка

5

PROFESSION_HUSBAND

Професія чоловіка

6

ADDRESS

Адреса

7

PREGNANT_TERM

Термін вагітності при відвідуванні

8

DISEASES

Перенесені захворювання

9

MEDICINAL_TOOLS

Чи використовувалися лікарські засоби (антибіотики, снодійні і т.д.)

10

BLOOD_TRANSFUSION

Чи використовувалося переливання крові

11

ENVIRONMENT_FACTORS 

Чи є шкідливі фактори зовнішнього середовища

12

FAM_CHRONIC_DISEASE

Хронічні захворювання в сім”ї

13

BAD_HABITS

Шкідливі звички

14

NUMBER_PREGN_DELIVERY

Кількість вагітностей і родів

15

NUM_HEALTHY_CHILD

Скільки здорових дітей

16

ABORTS

Кількість абортів, викидишів, їх причини

17

DISEASES_PREGN

Чим хворіла, в який термін вагітності

18

TREATEMENT

Чим лікувалася

19

HOW_FEEL

Скарги і самопочуття в теперішній час

20

GIGIENA_RULES

Чи дотримується правил гігієни

21

MEALS

Чи дотримується раціонального режиму харчування

22

RACHITIS

Чи проводилася антенатальна профілактика рахіту

23

ACCOMODATION

Житлово-побутові умови

24

GROUP_BLOOD

Група крові, резус-фактор

25

MILK

Чи проводить підготовку молочних залоз до кормління

26

DOCTOR_ADVICES

Чи виконує поради лікаря

27

LITERATURE

Чи має літуратуру з виховання здорової дитини