Проектування бази даних, Організація баз даних і знань, НУДПСУ

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

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

Така людино-орiєнтована модель цiлком незалежна вiд фiзичних параметрiв середовища збереження даних. Зрештою, цим середовищем може бути пам’ять людини, а не ЕОМ. Тому iнфологiчна модель не повинна змiнюватися доти, доки якiсъ змiни в реальному свiтi не потребуватимуть змiни в нiй певного визначення щоб ця модель продовжувала вiдбивати предметну галузь.

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

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

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

4.1. Особливостi СУБД АССESS

У свiтi iснує безлiч систем управлiння базами даних. Незважаючи на те, що вони можуть по-рiзному працювати з рiзними об’єктами i надають користувачу рiзнi функцiї і засоби, бiльшiсть СУБДспираються на єдиний усталений комплекс основних понять. Це дає нам можливiсть розглянути одну систему й узагальнити її поняття, прийоми і методи на весь клас СУБД. Таким навчальним об’єктом ми вибрали СУБДMicrosoftАссеss, що входить у пакет Microsoft Office.

Ассеss 1.0, випущений у 1992 р.,був одниміз найпоширеніших продуктiв, розроблених для персональних комп’ютерiв. Цей пакет установив новi стандарти для iнтерфейсу, полiпшивши систему звiтiв iзбiльшивши швидкiстъ управлiння даними. Завдяки цьому він став найпопулярнiшим пакетом СУБД для Windows ієдиним унiверсалъним програмним продуктом, що задовольняє усiх — і кінцевих користувачiв, i розробникiв повномасштабних додаткiв. Вданий час широко використовуються версії Ассеss 97 i Ассеss 2000.

При розробці баз даних одночасно доводиться працювати з декiлькома рiзними структурними об’єктами. У Ассеss реалiзований зовсім новий формат збереження даних. Єдина унiфiкована структура, яка називається контейнер, мiстить у собi всi структурнi елементи – таблицi, запити, програмнi модулi на Ассеss Ваsiс i т.д. Стандартне розширення цих файлiв .MDB (Microsoft Data Base). При вiдкриттi файла .МDВвсі об’єкти бази даних виводяться у виглядi списку у вiкнi бази даних. Для вибору одного з вказаних спискiв використовуються вкладки (корінці). 

4.2. Основнi об’єкти i процеси, що займають центральне мiсце в системi керування процесом проектування БД

4.2.1. Моделi організації даних

Набiр принципiв, якi визначають органiзацiю логiчної структури збереження даних у базi, одержав назву моделi даних. Моделi баз даних визначаються тръома компонентами:

• можливою органiзацiєю даних;

• обмеженнями цiлiсностi;

• множиною припустимих операцiй.

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

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

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

Концепцiя мережної моделі даних пов’язана з iм’я Ч. Бахмана. Мережний пiдхiд до органiзацій даних с розширенням iєрархiчного. Вiєрархiчних структурах запис-нащадок повинем мати одного предка; у мережнiй струкгурi даних нашадок може мати будь-яке число предкiв (рис. 1.3).

Мережна БД складається з набору записiв i набору зв’язкiв між цими записами, точнiше, з набору екземплярiв записiв заданих типiв (iз припустимого набору типiв) i набору екземплярiв iз заданого набору типiв зв’язку. 

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

Концепція реляційної моделі вперше були сформульованi в роботах американського вченого Е.Ф.Кодда. Звiдси походить її друга назва - модель Кодда.

Рис. 1.4. Схема реляцiйної моделi даних

У реляцiйнiй моделi об’єкти i взасмозв’язки мiж ними представляються за допомогою таблиць (рис. 1.4). Для її формального визначення використовується фундаментальне поняття вiдношення. Власне кажучи, термiн “реляцiйна” походить вiд англiйського relation - вiдношення.

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

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

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

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

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

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

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

4.2.2. Процес нормалізації

Нормалізація складається з трьох крокiв.

1. Перша нормальна форма (1НФ).

Повторення одних і тих самих полів небажане.Для того, щоб модель знаходилася в першiй нормальнiй формi, необхiдно:

• зробити всi поля атомарними;

• виключити повторюванi значення атрибутiв;

• виключити вiдносини «багато-до-багатьох». 

Приклад правильно органiзованої таблицi: значення полiв «Дата» i «Сума» слiд перенести в нову таблицю i зв’язати її з головною у вiдношеннi один-до-багатьох.

2. Друга нормальна форма (2НФ).

Кожнне поле повинне залежативід єдиного первинного ключа.

Для того щоб модель знаходилася в другiй нормальнiй формi,необхiдно:

• видiлити ключi та залежнi вiд них атрибути;

• видiлити зв’язки мiж ключами й iншими атрибутами;

• виписати в окрему таблицю складений ключ, частини ключiв i залежнi вiд них атрибути.

При використаннi допомiжних таблиць потрiбно простежити, щоб у них не було однакових полiв. У прикладi поле «Поштовий iндекс» повторюэться в декiлькох таблицях, але їх структуру треба переформувати так, гщб воно згадувалося лише в однiй.

3. Третя нормальна форма (ЗНФ).

Значення поля повинне зберiгатися незмінним, навiть якщо вміст інших полів змінився.

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

Наступний приклад iлюструє порушення третьої нормально форми. Якщо значення в полi «Код набору» таблицi «Телефонии» змiнилося, вмiс поля «Місто» також повинен змiнитися. У протилежному випадку iнформацiя в таблицi може виявитися неправильною. Залежнi одне вiд одного поля доцiльно винести в окрему таблицю.

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

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

З багатьох документiв розглянемо тi, котрi вiдносяться до вiдпускання готової продукцiї зi складу:

1) Замовлення.

2) Накладна.

3) Звiт по руху готової продукцiї на складi.

Проаналiзуємо спочатку структуру документiв. На рисунку видiленi групи полiв. В одному замовленнi може бути вказано кiлька найменувань продукцi, але тiльки один клiснт.

Видiлимо сутностi i зв’язки між ними позбувшись насамперед повторюваних груп. Для бiльшої наочностi наведене бiльш компактне графiчне представлення. Ключовi атрибути видiленi значком ’#’.

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

У схемi взасмозв’язкiв мiж сутностями для нашого об’єкта присутнє одне неспецифiчне вiдношення, яке необхiдно дозволити (в овалi поля, що залежать, як вiд замовлення, так i вiд виду продукцiї). Додамо сутнiсгь «Замовлено» iз двома зчепленими ключами. Схема буде мати такий вигляд:

Рис. 1.6. Дозвiл неспецифічних відносин

Побудована схема задовольняє всi умови третьої нормальної форми.

З повагою ІЦ "KURSOVIKS"!