Організація бази даних

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снували в 60-х рр.; були вiдсутнi пiдтримка логiчно зв’язаних файлiв, засоби вiдновлення даних у системi пiсля збоїв і параллельна робота декількох користувачів; не булла реалізована мова маніпулювання даними.

На початку 70-х рр. розроблений новий вид програмного забезпечення системи управлiння базами даних (Data Base Management - DBMS), яка дозволяла структурувати, систематизувати й орган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 ЕОМ (mainframe) мiстять величезнi масиви актуальної iнформацiї.

Розробка Е.Коддом реляцiйної теорiї пiдштовхнула до створення настпного класу СУБД. Особливостями другого покоління є застосування реляцiйної моделi даних i розвинена мова запитів SQL. Простота 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ня (4GL), технологiї тиражування даних та iнших досягнень у галузi обробки даних. Сьогоднi СУБД цього поколiння застосовуються в дiловiй сферi досить активно не тілъки як незакiнченi технiчнi рiшення, а iяк готовi продукти, що дають можливостi розробникам активно використовувати потужні засоби управлiння даними. 

2. Методи розв’язання задачi i засоби її вирiшення в СУБД

Основнi функції систем управління базами даних

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шеннями.

2.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лей СУБД, що має у своєму розпорядженн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ю.

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 активностi користувача стосовно БД. При вiдповiдному механiзмi управлiння транзакцiями користувач може вiдчути себе єдиним користувачем СУБД.

2.4. Протоколювання 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х випадках дотримуються “попереднъого” запису в журнал (так званий протокол Writer Ahead Log). Ця страгегiя полягає в тому, що запис про змiну будь-якого об’єкта БД повинен потрапити в зовнiшню пам’ягь журналу ранiше, нiж вона потрапить у зовнiшню пам’ять основної частини БД.Вiдомо, що коли в СУБД коректно дотримується протокол, то за допомогою журналу можна вирiшити всi проблеми вiдновлення БД пiсля будь-якого збою.

2.5. Пiдтримка мов БД

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

2.6. Арх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 описи даних.

 

3. Архітектура та структурний аналіз моделей бази даних автоматизованої інформаційної системи

3.1. Користувачі АІС та їх функції  в ІС

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

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

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

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

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

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

Кінцеві користувачі використовують ресурси АІС. Вони поділяються на непрямі і прямі.

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

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

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

3.2. Архітектура подання даних інформаційної системи

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

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

При розробці архітектури подання даних інформаційної системи керуються положеннями державного стандарту України ДСТУ 3329-96 щодо концепції для концептуальної схеми та інформаційної бази.

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

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

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

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

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

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

Кожен рівень подання даних АІС можна описати через структурні компоненти і таким чином здійснити декомпозицію кожного рівня подання даних від загального до найменшого складового елемента (див. табл. 3.1).

Таблиця.3.1

Архітектура подання даних в АІС

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

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

 

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

Природно, що проект бази даних треба починати з анал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йн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з двома зчепленими ключами. Схема буде мати такий вигляд:
Побудована схема задовольняє всi умови третьої нормальної форми.

5. Реалізація бази даних на внутрішньому рівні

 Лабораторна робота №1

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

Запуск програми Microsoft  Access:

ПУСК - Програми -  Microsoft  Access

У вікні Microsoft Access виберіть Нова база даних і клацніть на кнопці OK. У вікні Файл нової бази виберіть папку, у якій будете поміщати БД, а в нижній частині вікна дайте ім'я файлу Бібліотека.mdb (розширення mdb система додасть автоматично). Клацніть на кнопці Створити.

Відкривається вікно бази даних, де відображені всі компоненти БД.

Компоненти бази даних:

• таблиці – об'єкти, у яких зберігається інформація про якусь предметну область (наприклад, роботи бібліотеки, складального цеху заводу тощо).  У таблицях інформація представлена

- у стовпцях, які називаються доменами значень,

- у рядках, які називаються записами.

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

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

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

• звіти – інформація з таблиць, підготовлена для печатки;

• форми – зображення даних з таблиць на екрані у формі зручної для уведення, перегляду й коректування інформації; якщо з формою зв'язати програми мовою Visual Basic for Application (VBA), те форма стане засобом обробки даних;

• макросы й модулі – програми обробки даних, які зберігаються в БД мовою VBA.

4.1.Створення таблиць

Створимо три таблиці, які містять інформацію про роботу бібліотеки університету:

• Книги – містить інформацію про книги, які зберігаються в бібліотеці;

• ЧитКниги – містить інформацію про книги, які отримані читачами;

• Читачі – містить інформацію про читачів бібліотеки.

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

• Ім'я поля, може складатися з букв, цифр, може містити пробіли;

• Тип даного поля, вибирається зі списку, що розкривається;

• Размер поля, кількість символів для типу Текстовий, або один із числових типів для типу Числовий;

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

• Формат поля, можна вказувати формат для даних, які вводяться;

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

• Умова на значення записують логічні вираження для значень, які вводяться в поле (наприклад, для поля Вартість можна поставити <100,  якщо вартість книги не повинна перевищувати 100 гривень);

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

Одне з полів таблиці призначається ключовим. Значення в цьому полі однозначно визначає запис. Це поле повинне бути призначене Обов'язковим і необхідно вказати, що це поле є Індексованим (без повторений).  Таким полем у таблиці Книги є поле Инв№.  Щоб призначити це поле ключовим, відзначте поле й клацніть на інструменті Ключ (він виділений на малюнку 1). Закрийте вікно Конструктора таблиць для збереження структури таблиці й дайте їй ім'я у вікні запиту.

Тепер потрібно ввести дані в таблицю. Це можна зробити багатьма способами. Приведемо два найпростіших:

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

2). Використання автоформы: натисніть на кнопку Новий об'єкт на панелі інструментів і виберіть пункт Автоформа. Буде створена й відкрита форма для перегляду й редагування записів. Уведіть не менш 10 записів у таблицю Книги.

Створіть нову таблицю ЧитКниги з полями (Рис. 2):

- Инв№ - інвентарний номер книги, виданої читачеві;

- NB – номер читацького квитка читача;

- Дата видачі - дата видачі книги читачеві;

- Дата повернення – дата, коли читач належний повернути книгу в бібліотеку.

Виберіть відповідному змісту типи полів й їхні розміри. Поле Инв№ повинне бути типуТекстовий і мати розмір 6 (байтів) як й у таблиці Книги. Поле NB теж зробітьтекстовим. Поля Инв№ й NB повинні бути індексованими й обов'язковими. У цій таблиці можна не призначати ключового поля.

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

Таблиця 2

Список книг, які видані, до таблиці ЧитКниги

Инв№	NB	Дата видачі	Дата повернення	Прим
1	700	3.01.03	14.02.03
11	830	20.01.03	13.02.03
10	830	2.12.02	6.01.03
8	830	21.12.02	23.01.03
5	700	3.12.02	4.01.03
3	1220	10.12.02	11.01.03
4	830	2.12.02	3.01.03