МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Рекомендовано
Міністерством освіти і науки України
ББК 32.973.26-018.2
С 41

Рецензенти:
Ріппа С. П., д-р екон. наук, проф.
(Науково-дослідний центр з проблем оподаткування
Академії Державної податкової служби України)
Вовк В. М., д-р екон. наук, проф.
(Львівський національний університет ім. Івана Франка)

Рекомендовано Міністерством освіти і науки України

Лист № 14/18.2-162 від 27.01.03

Ситник Н. В.
С 41 Проектування баз і сховищ даних: Навч. посібник. — К.:
КНЕУ, 2004. — 348 с.
ISBN 966–574–625–1
У навчальному посібнику розкриті теорія проектування баз і сховищ да-
них та практика їх використання в сучасних інформаційних системах.
Тут подано основні теоретичні поняття та терміни, які розкривають сут-
ність бази даних і проблеми її проектування, а також детально висвітлено пи-
тання інфологічного і даталогічного проектування баз даних. Окремо викла-
дено реляційний підхід до проектування баз даних. Описано технологію
створення та ведення клієнтської бази даних засобами СКБД Microsoft Access,
розкриті особливості роботи з розподіленими базами даних.
Крім того, у посібнику розглянуто відмінності сховищ даних від баз да-
них, викладено характеристику побудови моделей сховищ даних та зроблено
акцент на питання проектування, зокрема викладена методика вимірного мо-
делювання сховищ даних. Розкриті питання застосування сховищ даних в
OLAP-системах та системах Data Mining. Викладено підходи до автоматизації
проектування баз і сховищ даних на основі використання CASE-технології.
Навчальний посібник підготовлено відповідно до курсу «Проектування
баз і сховищ даних», має на меті допомогти формуванню фундаментальних
теоретичних знань і практичних навичок з проектування баз і сховищ даних,
їх створення та ведення із застосуванням засобів сучасних СКБД.

ББК 32.973.26-018.2

Розповсюджувати та тиражувати
без офіційного дозволу КНЕУ забороняється

© Н. В. Ситник, 2004
ISBN 966-574-625-1 © КНЕУ, 2004
 Навчальне видання

СИТНИК Ніна Василіївна

ПРОЕКТУВАННЯ БАЗ
І СХОВИЩ ДАНИХ

Навчальний посібник

Редактор Т. Зарембо
Художник обкладинки Т. Зябліцева
Технічний редактор Т. Піхота
Коректор В. Білаш
Верстка І. Андрієнко

Підп. до друку 24.05.04. Формат 6084/16. Папір офсет. № 1.

Гарнітура Тип Таймс. Друк офсет. Ум. друк. арк. 20,22.
Обл.-вид. арк. 24,57. Наклад 1000 прим. Зам. № 01-2511.

Київський національний економічний університет

03680, м. Київ, просп. Перемоги, 54/1
Свідоцтво про внесення до Державного реєстру
суб’єктів видавничої справи (серія ДК, №235 від 07.11.2000)
Тел./факс (044) 458-00-66; (044) 456-64-58
E-mail: publish@kneu.kiev.ua
 ВСТУП

Питання проектування баз і сховищ даних є дуже важ-

ливими у вивченні інформаційних технологій, оскільки вони ле-
жать в основі створення інформаційної системи. Підґрунтям су-
часних інформаційних систем донедавна вважалися лише бази
даних. Стрімкий розвиток інформаційних технологій зумовив
необхідність створення такого їх різновиду, як сховища даних,
котрі є ядром будь-якої сучасної аналітичної інформаційної сис-
теми. На сьогодні при створенні інформаційних систем важливо
володіти не лише теорією проектування баз і сховищ даних, а й
інструментальними засобами, що автоматизують ці процеси. То-
му метою даного навчального посібника було викладення конце-
пцій побудови баз і сховищ даних, теорії їх проектування та ви-
користання CASE-засобів для автоматизації такого проектування
та ілюстрація цих процесів практичними матеріалами.
У першому розділі навчального посібника подано основні те-
оретичні поняття і терміни, які розкривають суть категорії «база
даних» та її місце в сучасних інформаційних технологіях, зміст
проблеми проектування баз даних та охарактеризовано його етапи.
Другий розділ присвячено інфологічному моделюванню пред-
метної області. У ньому детально розглянуто питання вивчення
предметної області, для якої розроблятиметься база даних, опи-
сано методику інфологічного проектування.
Третій розділ присвячено даталогічному проектуванню, тобто
розробці моделі бази даних у середовищі конкретної системи
управління базами даних (СКБД). Відображення інфологічної
моделі на даталогічну розглянуто для найпоширеніших типів мо-
делей баз даних — реляційної, ієрархічної та мережевої.
Проектуванню реляційних баз даних на основі нормалізації
реляційних відношень присвячено четвертий розділ. Виокрем-
лення цих питань пов’язано з тим, що реляційні моделі — це
найпопулярніший у практичній діяльності тип моделей, і біль-

3
шість сучасних СКБД, що представлені сьогодні на ринку про-
грамних засобів, підтримують саме реляційні моделі.
У п’ятому розділі розглянуто використання сучасних CASE-
технологій для автоматизації проектування баз даних. Тут по-
дано класифікацію CASE-засобів, основні методології інформа-
ційного моделювання і розглянуто автоматизацію проектування
баз даних у середовищі S-Designor та ERwin.
Шостий розділ висвітлює питання створення і ведення баз да-
них у середовищі реляційної СКБД Microsoft Access. Цей розділ
не може претендувати на повноту охоплення всіх питань,
пов’язаних з функціонуванням вказаної СКБД, і відповідно не
може замінити довідкову літературу, присвячену розгляду цієї
системи. В ньому розглянуто лише питання створення та ведення
баз даних, а також деякі особливості адміністрування роботи з
базами даних, які зумовлені специфікою та особливостями СКБД.
У сьомому розділі викладено характеристику мови SQL: наве-
дено загальну характеристику мови запитів реляційних СКБД, її
порівняльну характеристику з мовою Jet SQL та визначені основні
групи операторів. По кожній групі операторів мови Jet SQL наве-
дено синтаксиси операторів та описано їх практичне застосування.
Важливі питання створення розподілених баз даних розгляну-
то у восьмому розділі. Тут розкрито основні стратегії розподі-
лення даних та відмінності технології функціонування розподі-
лених систем. Викладено особливості процесу управління
одночасним доступом до даних у розподіленій базі даних і суть
механізму підтримки трансакцій розподілених СКБД.
Зміст дев’ятого розділу розкриває суть концепції сховищ да-
них і передумови їх створень, розглянуто основні характеристи-
ки сховищ даних, викладено характеристику основних компо-
нент і висвітлено види архітектур побудови сховища даних.
Десятий розділ присвячений моделям сховищ даних та особ-
ливостям їх проектування. Розглянуто основні моделі побудови
сховищ даних та методику вимірного їх моделювання.
В одинадцятому розділі проаналізовані питання практичного
застосування сховищ даних у сучасних інформаційних системах.
Зокрема, коротко викладено основи використання сховищ в
OLAP-системах і технологіях Data Mining.
Пропонований навчальний посібник є основним при вивченні
курсу «Проектування баз і сховищ даних», який має сформувати
у студентів фундаментальні теоретичні знання та практичні на-
вички з проектування баз даних, їх створення та ведення з вико-
ристанням засобів сучасних СКБД.

4
 1 Pоздiл
ВВЕДЕННЯ В ПОНЯТТЯ «БАНКИ ДАНИХ».
ОСНОВНI ПОНЯТТЯ

1.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в, головними з яких є:
1. Надлишковiсть даних. Файловi системи характеризуються
значною надлишковiстю, оскiльки нерiдко для розв’язування
рiзних задач управлiння залучаються однi й тi самі данi, розмі-
щені в рiзних файлах. Через дублювання даних у рiзних файлах
пам’ять на зовнішніх запам’ятовуючих пристроях використову-
ється неекономно, iнформацiя одного й того самого об’єкта
управлiння розподiляється мiж багатьма файлами. При цьому до-
сить важко уявити загальну iнформацiйну модель предметної об-
ластi (ПО).
2. Неузгодженість даних. Ураховуючи, що одна й та сама ін-
формац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к файлових систем призво-

5
дить до значного збiльшення вартостi супроводження програм-
них засобiв. Зазначимо, що інколи вартiсть супроводження про-
грамних засобiв може досягати близько 70 % вартостi їх розро-
бки.
Розвиток засобiв обчислювальної технiки, створення за-
пам’ятовуючих пристроїв прямого доступу забезпечили перед-
умови для розв’язання проблем незалежностi, неузгодженостi
й надлишковостi даних, а також сприяли виникненню нової
концепцiї органiзацiї iнформацiйного забезпечення — кон-
цепцiї iнтеграцiї даних, яка дістала назву «автоматизований
банк даних» (АБД). Головні переваги органiзацiї IЗ у виглядi
АБД такі:
1. Багаторазовiсть використання даних: однi й тi самі данi
можуть використовуватися для розв’язання рiзних задач.
2. Економiя витрат на створення i ведення: для органiзацiї IЗ
у виглядi АБД потрібні менші кошти, а внесення змін до бази да-
них (БД) супроводжується меншими витратами, оскільки змiни
на фiзичному рiвнi не завжди потребують внесення змiн у при-
кладнi програми.
3. Зменшення надлишковостi даних. Розв’язування нових за-
дач забезпечується здебільшого за рахунок iснуючих файлiв в
АБД, а не шляхом створення нових. Дублювання даних, яке спо-
стерігається в АБД, потрiбне лише для забезпечення оператив-
ностi пошуку даних й органiзацiї зв’язку мiж файлами БД. Таке
дублювання не є зайвим, а називається ненадлишковим дублю-
ванням.
4. Швидкiсть обробки непередбачених запитiв до системи.
Для обробки таких запитiв здебільшого не потрібно створюва-
ти нову програму мовами програмування, оскiльки цi процеду-
ри можна виконати за допомогою спецiальних мовних засобiв
(мови запитiв i мови генерацiї звiтiв), якi входять до складу
АБД.
5. Простота i зручнiсть внесення змiн до бази даних. Це дося-
гається за рахунок єдиної системи ведення БД, яка пiдтримується
засобами СКБД.
6. Логiчна i фiзична незалежності даних вiд прикладних про-
грам. Концепцiя автоматизованого банку даних побудована на
iнтеграцiї даних, які зберiгаютья окремо вiд прикладних про-
грам. Тому немає потреби повнiстю описувати логiчну та
фiзичну структури файлiв, якi оброблюються в прикладнiй
програмi.

6
 1.2. Поняття банку даних та його структура

Iснує дуже багато рiзних визначень автоматизованого

банку даних. Проте слід відзначити, що АБД не є загальновжива-
ним термiном; в англомовних виданнях часто зустрічається термiн
«система баз даних» (database system), який вміщує базу даних, си-
стему керування базою даних, вiдповiдне обладнання i персонал.
У деяких публiкацiях поняття «банк даних» i «база даних» не роз-
межовуються. Термiн «система баз даних» близький за семанти-
кою до терм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.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 з тех-
7
нологiчними цiлями, а саме із забезпеченням бiльш надiйного захи-
сту чи зменшенням тривалості реакцiї системи. Але в будь-якому
разі елементи дублювання повиннi бути вiдомi адмiнiстраторові ба-
зи даних, який повинен мати змогу управляти ними.
БД являє собою iнтегроване інформаційне середовище, яке ви-
користовується багатьма споживачами i забезпечує незалежність
даних вiд прикладних програм. Зв’язок кiнцевих користувачiв i
прикладних програм з БД відбувається через СКБД, яка виступає
iнтерфейсом мiж користувачем i базою даних (рис. 1.1). Користува-
чами БД можуть бути окремі фізичні особи чи прикладні програми.

Користувач,
прикладна СКБД База даних
програма

Рис. 1.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гався в прикладних програмах. Така програма мала вмiщувати
повний опис файлiв, якi вона оброблює, незалежно від кiлькості
полiв з того чи iншого файла, що оброблюються в програмi. Ви-
користання БД потребує опису в програмi лише тих полiв, якi во-
на оброблює; таким чином досягається незалежнiсть опису даних
8
вiд прикладних програм. Тому опис даних, навiть якщо вiн
зберiгається разом із даними, називають метаданими. Iнодi опис
даних у лiтературi називається схемою, а та частина баз даних,
що використовується якоюсь прикладною програмою, — пiдсхемою.
У деяких сучасних системах до метаданих належать не лише
описи самих даних, а й інформацiя про предметну область, корис-
тувачiв системи, статистику її роботи та iншi вiдомостi. Для
централiзованого зберігання всiєї метаiнформацiї використову-
ється словник даних (СД).
СД дуже важливий, особливо в умовах колективного викорис-
тання даних, оскільки він забезпечує розв’язання проблеми до-
стовiрностi, надлишковостi й контролю за рацiональним зберіган-
ням і використанням даних.
Словник даних повинен виконувати такi основнi функцiї:
 встановлення зв’язкiв мiж користувачами БД;
 виконання простого та ефективного управлiння елементами
даних при введеннi в систему як нових елементiв, так i при мо-
дифiкацiї опису iснуючих;
 зменшення надлишковості даних;
 запобiгання неузгодженостi даних;
 централiзоване управлiння даними з метою спрощення про-
цесу проектування БД та її розширення.
Словник даних використовується кiнцевими користувачами
під час роботи із системою, прикладними програмiстами — при
написаннi програм, системними програмiстами — в процесi екс-
плуатації системи та при її розширенні.
Словник даних може вмiщувати вiдомостi про джерело інфор-
мацiї, формати i взаємозв’язок мiж даними, вiдомостi про частоту
виникнення i характер використання даних, термiни коригування i
вiдповiдальних за це осiб i т.д. Отже, вiн являє собою базу даних
про данi як особливий вид ресурсу.
Одне з основних призначень СД є документування даних. На-
громадження iнформацiї про данi потрiбно починати вже на
раннiх стадiях проектування. Йому вiдводиться роль засобу
централiзованого ведення й управлiння даними на всiх етапах
проектування системи, а також забезпечення ефективної взає-
модiї мiж усіма користувачами при розподiленiй БД. До СД мож-
на занести iнформацiю про мiсце фiзичного зберiгання даних, а
також вiдомостi про обмеження секретного характеру, санкціо-
нованості доступу та інші питання, пов’язанi із захистом
iнформацiї.

9
 Робота з СД спрощує процес пiдготовки документацiї про-
грамiстами, забезпечує користувачiв iнформацiєю про наявнi в
системi данi, дозволяє контролювати вiдповiднiсть у назвах і фор-
матах даних та їх кодах.
Усi питання, пов’язанi з веденням СД, ми розглядатимемо в кон-
текстi СКБД i автоматизованої форми її ведення. Але, на жаль, не в
усiх СКБД є цей засiб. В такому разi потрiбно вести СД вручну чи за-
писувати вiдповiднi програми ведення такого словника. Пакет про-
грам ведення СД може iнтегруватися з СКБД чи бути незалежним.
Як приклад СКБД, що має в своєму арсеналi такий засiб, як
словник даних, є розподiлена СКБД Oracle. Словник Oracle — це
один з найважливіших компонентів, який вміщує: iмена користу-
вачiв; права та привiлеї, якi їм надаються; iмена об’єктiв БД (таб-
лиць та їх подання, iндексiв, синонiмiв тощо); перелiк обмежень
на таблицi; журнальну iнформацiю, наприклад вiдомостi про до-
ступ до таблиць і внесення в них змiн.
Iнформацiя словника Oracle розподілена за категорiями: для
кiнцевого користувача, проектувальника та адмiнiстратора. Слов-
ник вiдображає та зберiгає поточний стан бази даних; усi змiни в
структурах БД записуються в словник безпосередньо пiсля вико-
нання процедур щодо їх змiни. Словником даних користуються всi
користувачi в обсязi, який дозволяють їхні привiлеї.

1.2.2. Система керування базами даних

До складу АБД обов’язково входить такий компонент,

як СКБД, що є комплексом програмних i мовних засобiв загаль-
ного i спецiального призначення, необхiдних для створення БД,
пiдтримки її в актуальному станi, манiпулювання даними та ор-
ганiзацiї доступу до них рiзних користувачiв в умовах прийнятої
технологiї обробки даних.
СКБД вiдiграє центральну роль у функцiонуваннi АБД та ви-
конує такі функції:
 дозволяє визначати структуру бази даних, що виконується за
допомогою мови визначення даних (DDL — Data Definition
Language). Мова DDL надає користувачам засоби визначення ти-
пів даних та їх структури, а також засоби визначення обмежень
на дані, що зберігаються у БД;

10
  дає змогу виконувати операції вставки, вилучення та онов-
лення інформації з бази даних. Ці операції виконуються засобами
мови управління даними (DML — Data Manipulation Lanquaqe);
 дозволяє виконувати операції пошуку і вибірки даних з бази
даних та їх відображення в результатних наборах даних. Ці операції
виконуються засобами мови даних (Data Query Language — DQL);
 надає контрольований доступ до бази даних за допомогою:
— системи забезпечення безпеки та запобігання несанкціоно-
ваного доступу;
— системи підтримки цілісності та узгодженості даних;
— системи управління паралельною роботою додатків, яка
контролює процеси одночасного доступу до БД;
— системи відновлення, що дозволяє відновити БД при апарат-
них збоях чи помилках у програмному забезпеченні.
СКБД є основою програмних засобiв АБД. У нiй можна виок-
ремити ядро СКБД, яке забезпечує органiзацiю введення, оброб-
ки та зберігання даних, а також компоненти, що відповідають за
налагодження системи, засоби тестування, утилiти, якi забезпе-
чують виконання допомiжних функцiй (наприклад, ведення жур-
налу статистики роботи системи та iн.). Дуже важливою задачею
СКБД є забезпечення незалежностi даних. Практично одна й та
сама СКБД може бути застосована для ведення абсолютно рiзних
файлiв, якi використовуються для розв’язання рiзнопланових, не
пов’язаних мiж собою задач управлiння.

1.3. Характеристика багатокористувацьких СКБД

За технологічними особливостями використання СКБД

поділяються на персональні та багатокористувацькі.
Персональні СКБД — це системи, що забезпечують можли-
вість створення персональних БД та недороге прикладне програ-
мне забезпечення (ППЗ), яке працює з нею. Персональні СКБД
дуже часто можуть виступати як клієнтська частина багатокорис-
тувацької СКБД. До персональних СКБД належать Visual FoxPro,
Paradox, Clipper, dBase, Access та інші.
Багатокористувацькі СКБД включають сервер БД і клієнт-
ську частину та можуть працювати в неоднорідному обчислюва-
льному середовищі (з різними типами ЕОМ та операційними сис-
темами). До багатокористувацьких СКБД належать, наприклад,
такі системи: Oracle, Informix, Sybase.
11
 Існує декілька архітектурних рішень використання багатоко-
ристувацьких СКБД, які дістали назву «файл-сервер» та «клієнт-
сервер». Історично першими з’явились розподілені інформаційні
системи з використанням технології «файл-сервер» (рис. 1.2).
Файловий сервер містить файли, необхідні для роботи додатків і
СКБД. Користувацькі додатки і СКБД розміщені на окремих ро-
бочих станціях і звертаються за потрібними їм даними до серве-
ра. Тобто в таких системах за запитом користувача файли бази
даних передаються з сервера на робочі станції і там обробляють-
ся. Недоліком цієї архітектури є висока інтенсивність передачі
даних у мережі та значний її трафік. Оскільки сервер не розуміє
мови SQL, то файли передаються повністю, незалежно від того,
що робочій станції потрібна їх певна підмножина. Тобто переда-
ча надлишкових даних збільшує навантаження на мережу і в ці-
лому впливає на ефективність функціонування ІС.
Робоча станція
№2

Робоча станція Локальна Робоча станція

№1 мережа №3

Передача / повернення
файлів БД

База даних

Файл-сервер
Рис. 1.2. Архітектура технології «файл-сервер»
Таким чином, основними недоліками технології «файл-сервер»
є такі:
 при збільшенні кількості робочих станцій збільшується на-
вантаження на мережу, що призводить до зростання мережевого
трафіку;

12
  кожна робоча станція повинна зберігати повну версію
СКБД;
 адміністрування базою даних, тобто забезпечення цілісності,
відновлення даних, управління паралельністю доступу до одних і
тих самих файлів різних користувачів, значно ускладнюється при
збільшенні кількості робочих станцій.
Технологія «клієнт-сервер» з використанням сервера БД пока-
зана на рис. 1.3. При такій архітектурі на клієнтському робочому
місці користувачем чи додатками формуються мовою SQL чи
іншою мовою запити до сервера. Сервер обробляє запити, що на-
дійшли, тобто виконує пошук необхідних даних та передачу їх
клієнту. При виконанні запитів на сервері перевіряються повно-
важення клієнтів, забезпечується підтримка цілісності й узгодже-
ності даних, а також управління паралельністю доступу та відно-
вленням даних.
Клієнт 2

Клієнт 1 Клієнт 3
Локальна
мережа

Запити-вибірки Результати
(SQL-запити) вибірки з
файлів БД

База даних

Сервер
БД

Рис. 1.3. Архітектура технології «клієнт-сервер»

Основними перевагами архітектури «клієнт-сервер» є такі:

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

13
  підвищення рівня суперечності даних за рахунок того, що
підтримка цілісності виконується централізовано на сервері;
 зменшення комунікаційних витрат. На клієнтських робо-
чих місцях виконується переважна більшість операцій обробки
даних. Через мережу посилаються лише запити до бази даних,
що дозволяє значно знизити обсяги даних, що передаються по
мережі.
Наведена на рис. 1.3 архітектура є дворівневим «клієнт-
сервером». Ця архітектура при ускладненні прикладного програм-
ного забезпечення та збільшенні його обсягів призводить іноді до
виникнення проблеми «товстого» клієнта, яка полягає в тому, що
для ефективної роботи клієнта потрібні значні машинні ресурси,
великий дисковий простір, оперативна пам’ять та потужний про-
цесор.
Для вирішення проблеми «товстого» клієнта в 1995 р. була за-
пропонована трирівнева архітектура клієнт-сервера. За цієї архі-
тектури між сервером і клієнтом з’явився проміжний рівень, який
називається сервером прикладного програмного забезпечення, на
якому зосереджено прикладне програмне забезпечення. Архітек-
тура трирівневого клієнт-сервера показана на рис. 1.4.
Перший рівень Функції
Клієнт Інтерфейс користувача

Функціональні Результат виконання

запити функціонального
запиту
Другий рівень
Сервер прикладного
програмного забезпе-
чення (ППЗ)
Результати виконання
SQL-запити SQL-запити

Третій рівень Функції

Сервер бази даних Контроль цілостності даних
Доступ до бази даних

База даних

14
 Рис. 1.4. Архітектура трирівневого «клієнт-сервер»
Трирівнева архітектура клієнт-сервера має такі переваги:
 вирішена проблема «товстого» клієнта, тобто для обладнан-
ня клієнтського робочого місця не потрібні надто дорогі та потуж-
ні ПЕОМ;
 централізація зберігання прикладного програмного забезпе-
чення дозволяє виконувати його централізований супровід, що
спрощує проблему його модифікації;
 вирішена проблема функціонального взаємозв’язку між мо-
дулями прикладного програмного забезпечення.
Трирівнева архітектура «клієнт-сервера» може бути розщепле-
на до n-рівневої архітектури. Наприклад, проміжний рівень мож-
на представити двома рівнями, один з яких виконує роль WEB-
сервери, а другий — типові сервери ППЗ.

1.4. Покоління СКБД

На сьогодні відомо три покоління СКБД. Перше поко-

ління — це системи на основі інвертованих списків, єрархічних та
мережевих моделей даних. Ці СКБД використовувались на маши-
нах типу IBM 360. СКБД першого покоління не мали стандарту на
зовнішній інтерфейс, засобів автоматизації програмування, були до-
сить складними з погляду проектування і дуже дорогими. Але ці си-
стеми виявились найбільш довговічними, деякі й досі використову-
ються на Заході. Типовими представниками першого покоління
СКБД є: система Adabas (1969 р.) на основі інвертованих списків
фірми Software AG, єрархічна СКБД IMS (Information Management
System, 1968 р.) фірми IBM, мережева система IDMS (Integrated
Database Management System, 1971 р.) фірми Cullinet Software.
З появою персональних ЕОМ була розроблена теорія реляцій-
них баз даних, яка стала основою створення другого покоління
СКБД. Друге покоління — це персональні та багатокористува-
цькі реляційні СКБД. Персональні СКБД (або як ще їх називають
настільні системи) надають можливість розробки персональних
БД і недорогих додатків. Персональні СКБД можуть бути вико-
ристаними для розробки клієнтської частини у багатокористува-
цьких системах. Прикладом персональних СКБД є такі системи:
Clipper, dBase, Paradox, Access, Visual FoxPro та інші. Багатоко-
ристувацькі СКБД включають сервер БД і клієнтську частину; як

15
правило, можуть працювати в неоднорідному обчислювальному
середовищі (з різними типами ЕОМ та операційними системами).
Прикладом багатокористувацьких СКБД, які найпоширеніші на
вітчизняному ринку програмних засобів, є такі системи: Oracle,
Informix, Microsoft SQL Server, Sybase, DB2.
Реляційні СКБД найпопулярніші на сьогодні. Вони широко
представлені на ринку програмних засобів і найчастіше викорис-
товуються на практиці. Проте, незважаючи на привабливість і
широке застосування, реляційні СКБД мають ряд обмежень. Во-
ни ідеально підходять для вирішення економічних задач, що ма-
ють в основі дані, які можна без проблем представити у вигляді
нормалізованих таблиць. У принципі плоскі нормалізовані реля-
ційні відношення універсальні і теоретично підходять для пред-
ставлення даних будь-якої предметної області. Але для складних
предметних областей, дані яких необхідно представляти в сотнях,
а іноді й тисячах таблиць, виникає проблема їх об’єднання. Крім
того, суттєвим недоліком реляційних БД є атомарність атрибутів
таблиці, що не дає можливості представлення якихось агрегатів та
складових даних. Тому для усунення недоліків реляційних СКБД
запропонована ідея створення об’єктно орієнтованих систем.
Об’єктно орієнтовані бази даних (ООБД) — це системи тре-
тього покоління. Теорія об’єктно орієнтованих СКБД — віднос-
но нова теорія (перші публікації з’явились у середині 80-х років),
і поки що немає такої математичної основи, як реляційні чи ієрар-
хічні моделі. Інформаційні об’єкти, що зберігаються в ООБД, на-
лежать до певних класів, а зв’язки між класами встановлюються
за допомогою властивостей і методів класу. Основні властивості
об’єктно орієнтованих БД такі:
1. Абстракція. Кожен об’єкт, що зберігається в БД, є членом
якогось класу. Клас визначається як сукупність властивостей, мето-
дів, структур даних, а також програм, що застосовуються до
об’єктів (екземплярів) даного класу. Методи — це процедури, що
залучаються для виконання певних дій з об’єктом. Властивості —
це значення даних, пов’язаних з кожним об’єктом класу, які харак-
теризують його тим чи іншим чином (наприклад, розмір, собівар-
тість).
2. Інкапсуляція. Внутрішнє представлення даних та особли-
востей реалізації загальнодоступних і окремих методів (програм),
що є частиною певного класу і відомо лише всередині цього кла-
су. Доступ до об’єктів класу дозволяється лише через властивості
і методи цього класу або його батьків, а не шляхом використання
подробиць внутрішньої реалізації.

16
 3. Успадкування (одиночне чи множинне). Клас визнача-
ється як частина ієрархії класів. Кожен клас більш низького рівня
успадковує властивості та методи вищого за рівнем ієрархії класу
(батька), крім випадків, коли батьківські властивості оголошу-
ються неуспадковуючими чи змінені новим визначенням. Одино-
чне успадкування — це успадкування від одного батьківського
класу, тобто класова ієрархія має деревоподібну структуру. При
множинному успадкуванні клас може успадковувати властивості
та методи від багатьох батьківських класів, тобто ієрархія класів
має структуру нециклічного графа.
4. Поліморфізм. Декілька класів можуть мати імена методів і
властивостей, що збігаються, навіть якщо вони вважаються різ-
ними. Це дозволяє створювати методи доступу, які будуть прави-
льно працювати з об’єктами різних класів, якщо відповідні мето-
ди і властивості цих класів були визначеними.
5. Повідомлення. Взаємодія з об’єктами виконується шляхом
посилання повідомлень з можливістю отримання відповіді.
Модель ООБД перебуває на більш високому рівні абстракції,
ніж реляційні чи мережеві БД. Тому в центрі проектування зна-
ходяться не структури даних, а процедури (методи).
Зараз проводяться експериментальні і виробничі дослідження
в сфері розробки та впровадження об’єктно орієнтованих СКБД.
Переважаюча більшість робіт носить поки що дослідницький ха-
рактер. Проте уже існують комерційні версії об’єктно орієнтова-
них систем, прикладами яких можуть бути такі: О2 (французький
консорціум Aktair), ORION (американська компанія МСС), GemStone
(американська фірма Servio Logic), Iris (Hewlett-Packard).

1.5. Мовні засоби

Класифiкацiю мовних засобiв АБД, представлену на

рис. 1.5, розроблено американським комiтетом CODASYL з про-
ектування i створення БД.

17
 Мовні засоби АБД

Мова опису Мова спілкування Інші мовні

даних з БД засоби

Мова Мова Мова Мова

опису опису БД маніпулювання Мова запитів ведення
зовнішніх (DDL) даними (DML) (DQL) діалогу
даних

Мова Мова Мова опису

опису опису зберігання
схем підсхем даних

Рис. 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 засоби СКБД складаються з двох частин: мови опису
(визначення) даних (DDL) і мови маніпулювання даними
(DML) та мови запитів даних (DQL). Мова DDL використовуєть-
ся для визначення схеми бази даних, мова DML — для читання та
оновлення даних, що зберігаються в БД, а мова DQL — для фор-
мування запитів до бази даних з метою вибірки та пошуку необ-
хідних даних. Ці мови називаються іноді підмовами, оскільки во-
ни не містять всіх конструкцій для виконання всіх
обчислювальних операцій, які виконують мови програмування
високого рівня.

18
 Мова DDL — це мова описового характеру, яка дозволяє опи-
сати сутності, що зберігаються в БД, та зв’язки між ними. Ре-
зультатом компіляції DDL є набір таблиць, де зберігаються фай-
ли; він має назву системного каталогу. У ньому інтегровані
метадані, тобто дані, що описують об’єкти БД, а також спрощу-
ють спосіб доступу до них і управління ними.
Мова DDL призначена для опису даних на рiзних рiвнях абст-
ракцiї: зовнiшньому, логiчному i внутрiшньому. Виходячи з про-
позицiй CODASYL, мови опису даних на логiчному (концептуаль-
ному) i внутрiшньому рiвнях незалежнi й рiзнi. Однак бiльшість
промислових СКБД не поділяють мови на двi окремi — опису
логiчної та фiзичної органiзацiї даних, а iснує єдина мова, яка ще
називається мовою опису схем. Так, у більшості вiдомих i широ-
ко застосовуваних на практицi реляційних СКБД вживається
єдина мова опису даних для подання їх на логiчному й
фiзичному рiвнях. Ця мова має свiй синтаксис: наприклад, iм’я
файла не повинно перевищувати восьми символiв, а iм’я поля
— десяти; при цьому кожне iм’я має починатися з букви, поля
календарної дати позначаються символом D (DATA), символьнi
поля — С (CHARAСTER), числовi — N (NUMERIС), логiчнi — L
(LOGICAL), примiток — M (MEMO).
Опис усiх iмен, типiв i розмiрiв полiв зберiгається в пам’ятi
разом з даними; цi структури в разі потреби можна переглянути і
виправити.
Якщо логiчний i фiзичний рiвнi відокремленi, то до складу СКБД
має входити мова опису зберігання даних. У деяких СКБД, які
належали до першого покоління, використовується ще мова
опису пiдсхем (МОД — ПС), яка потрiбна для опису частини
БД, що вiдображає iнформацiйнi потреби окремого користува-
ча чи прикладної програми. Теоретично для кожного рівня
представлення даних можна було б виокремити кілька різних
підмножин мови DDL, а саме мову зовнішніх схем, мову концеп-
туальної схеми і мову внутрішньої схеми. Але на практиці існує
єдина мова DDL, яка дозволяє задавати специфікації як мінімум
зовнішньої і концептуальної схем.
Мова DML — це мова, оператори якої виконують основні
операції маніпулювання та управління даними БД. До цих опера-
цій належать такі: вставка в БД нових даних, модифікація да-
них БД, вилучення даних з БД.
Мова ведення діалогу — це мовні засоби, за допомогою
яких реалізовано інтерфейс системи з кінцевим користувачем.

19
Для переважної більшості сучасних СКБД — це підмножина
природної мови.
Мова DQL — це мова запитів до бази даних, яка дозволяє ви-
конувати вибірки необхідних даних.
Мови DML і DQL можуть бути процедурними і непроцедурними.
Процедурна мова дозволяє повідомити системі, які дані необ-
хідні, і точно вказати, як їх необхідно отримати. Для ієрархічних
і мережевих СКБД властивіша процедурна мова, для викорис-
тання якої користувачу потрібен посередник-програміст.
Непроцедурна мова дає змогу вказувати системі лише які дані
потрібні, незнаючи, як їх необхідно отримувати. Непроцедурна
мова називається ще декларативною мовою. Реляційні СКБД
містять непроцедурні мови. Найчастіше це мова структурова-
них запитів SQL або мова запитів за зразком QBE. Непроцеду-
рна мова менш складна з погляду її опанування, тому користу-
вач при відповідній підготовці може сам працювати з опера-
торами цієї мови без допомоги програміста.
Мова може бути базовою чи автономною. В деяких СКБД
передбачено можливість вмонтування операторів підмови в про-
грами, написані на таких мовах програмування високого рівня, як
COBОL, Fortran, Pascal, Ada, C. У такому разі мова високого рів-
ня називається базовою мовою (host language).
Системи, що вживають базову мову, називають вiдкритими.
Використання базових мов звужує коло осiб, котрі можуть без-
посередньо звертатися до БД, оскільки для цього потрiбно знати
мову програмування. У таких випадках для спрощення
спiлкування кiнцевих користувачiв з БД передбачається мова
ведення дiалогу, яка значно простіша для опанування, ніж мова
програмування.
Автономна — це власна мова СКБД, яка дає змогу викону-
вати рiзнi операцiї з даними. Системи з власною мовою нази-
вають закритими.
У сучасних СКБД для спрощення процедур пошуку даних у
БД передбачено мову запитiв. Найпоширенішими мовами запитiв
є SQL і QBE.
Мова запитiв SQL (Structured English Query Language —
структуpована англiйська мова запитiв) була створена фiрмою
IBM у рамках роботи над проектом побудови системи
управлiння реляцiйними базами даних на початку 70-х рокiв.
Американський нацiональний iнститут стандартiв (ANSI) по-
клав цю мову в основу стандарту мов реляцiйних баз даних,
прийнятого Мiжнародною органiзацiєю стандартiв (ISO). Яд-

20
ром iснуючого стандарту SQL-86, який часто називають SQL-2
чи SQL-92, є функцiї, реалiзованi практично в усiх вiдомих
комерцiйних реалiзацiях мови, а повний стандарт вміщує такi
вдосконалення, якi деякі розробники муситимуть ще ре-
алiзувати.
Крiм стандарту SQL-86, iснує комерцiйний стандарт мови
SQL, розроблений консорцiумом виробникiв баз даних SQL
Access Group. Ця група створила такий варiант мови, який вико-
ристовується бiльшiстю систем i дає змогу їм «розумiти» одна
одну. Було розроблено стандартний iнтерфейс мови CLI (Common
Language Interface) для всiх основних варiантiв мови SQL. Цей
інтерфейс, формалізований фiрмою Microsoft, дістав назву ODBC
(Open Database Connectiviti — вiдкритий доступ до даних).
ODBC — це iнтерфейс доступу до даних, якi зберiгаються, під
управлiнням рiзних СКБД. ODBC має цiлий набір драйверiв, за
допомогою яких одна СКБД може працювати з даними iнших си-
стем.
Мова запитiв QBE (Query By Example) — це графічна мова
реалiзацiї запитiв за зразком у виглядi таблиць. Для визначен-
ня запиту до БД користувач повинен заповнити надану систе-
мою таблицю QBE і визначити в нiй критерiї пошуку та вибору
даних.

1.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 не по-
требувати якоїсь складної спецiальної пiдготовки в галузі обчислю-
вальної технiки чи мовних засобiв СКБД. Iнодi в локальних АРМ на
кiнцевих користувачiв покладаються функцiї адмiнiстратора.

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

Основнi функцiї адмiнiстратора: спільна робота з проектуваль-

никами задач для визначення умов використання БД, розробка опи-
су БД i початкове її завантажування, пiдтримування цiлісностi БД,
органiзацiя захисту зберігання даних, вiдновлення БД у разі виник-
нення помилок програмного забезпечення чи збої пристроїв, якi
призводять до руйнування БД, нагромадження статистики по роботi
з БД, реорганiзацiя та реструктуризацiя БД відповідно до змiни по-
треб.
Рiзноманiтнi задачi, якi повинен розв’язувати адмiнiстратор,
можна подiлити вiдповiдно до етапів розробки АБД на чотири
групи: планування, проектування, експлуатацiя i використання
[49]. При плануваннi адмiнiстратор бере участь у виборi програ-
много забезпечення та обладнання. Вiн співпрацює з кiнцевими
користувачами, аби встановити реальнi потреби, мету та вимоги
прикладних програм до бази даних. Адмiнiстратор бере участь у
довгостроковому плануваннi, в якому визначаються перспективи
розвитку системи та розширення бази даних.
Під час проектування адмiнiстратор надає спецiалiстам нео-
бхiднi данi для розробки логiчної та фiзичної моделей даних.
Якщо виникають нові вимоги до даних, адмiнiстратор визначає,

22
як можна включити цi данi до баз даних i управляє процесом
внесення змiн.
На етапi експлуатацiї до обов’язків адмiнiстратора входять роз-
робка i контроль дiй, якi гарантують збереження цiлісностi бази
даних, включаючи процедури її копiювання та вiдтворення, а та-
кож визначення засобiв захисту iнформацiї за допомогою ме-
ханiзму управлiння доступом до ресурсiв БД.
Окрiм того, адмiнiстратор увесь час спiлкується з користувача-
ми бази даних, тому вiн визначає стандарти на змiст і використан-
ня даних, супроводжує спецiальне програмне забезпечення роботи
з базою даних (словники даних, статистику роботи з БД тощо),
проводить консультації та здійснює ведення БД.
Адмiнiстратор взаємодiє також із системними програмiстами,
вирiшуючи питання технологiї й доведення її до вiдповiдних екс-
плуатацiйних характеристик, спiлкується i спiвпрацює із систем-
ними програмiстами в разі змiни версiй системи чи операцiйного
середовища.
При супроводженні баз даних, особливо розподiлених,
адмiнiстраторові часто доводиться спiвпрацювати із
спiвробiтниками, котрі вiдповiдають за експлуатацiю технiчних за-
собiв АБД. Така спiвпраця пов’язана з необхiднiстю виявлення при-
чин збоїв обладнання, якi призводять до руйнування баз даних, і
розробки заходiв запобiгання цього в ході подальшої експлуатацiї
системи.
У звiтах ANSI/X3/SPARC видiляється також адмiнiстратор
предметної областi, який вiдповiдає за синтез опису предметної
областi, вiдображеної в базi даних.

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

Створення та впровадження в практику сучасних

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

23
 Проектування баз даних — це iтерацiйний, багатоетапний
процес прийняття аргументованих рiшень у процесi аналiзу
iнформацiйної моделi предметної областi, вимог до даних з
боку прикладних програмістів і користувачiв, синтезу
логiчних і фiзичних структур даних, аналiзу та обґрунтуван-
ня вибору програмних й апаратних засобiв.
Етапнiсть проектування даних пов’язана з багаторiвневою ор-
ганiзацiєю даних. Розглядаючи питання проектування баз даних,
ми дотримуватимося багаторiвневого подання даних:
зовнiшнього, iнфологiчного, логiчного (даталогiчного),
внутрiшнього.
Таке подання рiвнів даних не одне. Є iншi варiанти бага-
торiвневого подання даних. Так, згiдно з пропозицiями до-
слiдницької групи по системах управлiння даними Американсь-
кого нацiонального iнституту стандартiв ANSI/X3/SPARC, а
також CODASYL (Conference on Data Systems Languages), як пра-
вило, виокремлюються три рiвнi подання даних: зовнiшнiй (з по-
гляду кiнцевого користувача i прикладного програмiста), концеп-
туальний (з погляду СКБД), внутрiшнiй (з погляду системного
програмiста). Згiдно з цiєю концепцiєю зовнiшнiй рiвень є частина
(пiдмножина) концептуальної моделi, необхiдна для реалiзацiї яко-
гось запиту чи прикладної програми. Тобто, якщо концептуальна
модель виступає як схема, пiдтримувана конкретною СКБД, то
зовнiшнiй рiвень — це деяка сукупнiсть пiдсхем, необхiдних для
реалiзацiї конкретної прикладної програми чи запиту користувача.
Проте iснує також iнша точка зору, зг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, 16]. Вiн може виступати як самостiйний або
бути складовою зовнiшнього рiвня. Така концепцiя доцiльнiша з
погляду розумiння процесу проектування БД. Тому розглядати-
мемо iнфологiчний рiвень як самостiйний рiвень подання даних.
Зовнiшнiй рiвень у такому разі виступає як окремий етап проек-
тування, на якому вивчається все позамашинне iнформацiйне за-
безпечення, тобто форми документування та подання даних, а та-
кож зовнiшнє середовище, в якому функцiонуватиме банк даних
з погляду методiв фiксацiї, збирання та передачі iнформацiї в ба-
зу даних.
При проектуванні БД на зовнiшньому рiвнi необхiдно вивчити
функцiонування об’єкта управлiння, для якого проектується БД,
24
усю первинну та вихiдну документацiю з погляду визначення то-
го, якi саме данi необхiдно зберiгати в базi даних. Зовнiшнiй
рiвень є, як правило, словесним описом вхiдних і вихiдних
повiдомлень, а також даних, якi доцiльно зберiгати в БД. Опис
зовнiшнього рiвня не виключає наявностi елементiв дублювання,
надлишковостi та неузгодженостi даних. Тому для усунення цих
аномалiй і суперечностей зовнiшнього опису даних виконується
iнфологiчне проектування. Iнфологiчна модель є засобом струк-
туризацiї предметної областi і розумiння концепцiї семантики
даних. Цю модель можна розглядати в основному як засiб доку-
ментування та структурованої форми подання iнформацiйних по-
треб, що забезпечує несуперечливе спiлкування користувачiв і
розробникiв системи.
Усi зовнiшнi подання інтегруються на iнфологiчному рiвнi, де
формується iнфологiчна (канонiчна) модель даних, яка не є прос-
тою сумою зовнiшнiх подавань даних.
Iнфологiчний рiвень являє собою iнформацiйно-логiчну мо-
дель (IЛМ) предметної областi, в якiй виключено надлишковiсть
даних i вiдображено iнформацiйнi особливостi об’єкта
управлiння без урахування особливостей i специфiки конкретної
СКБД. Тобто інфологічне подання даних орiєнтоване переважно
на людину, яка проектує чи використовує базу даних.
Логiчний (концептуальний) рiвень побудований з урахуван-
ням специфiки та особливостей конкретної СКБД. Цей рiвень
подання даних орiєнтований бiльше на комп’ютерну обробку i
програмiстiв, якi займаються її розробкою. На цьому рiвнi фор-
мується концептуальна модель даних, тобто спецiальним спосо-
бом структурована модель ПЗ, яка вiдповiдає особливостям та
обмеженням вибраної СКБД. Модель логiчного рiвня,
пiдтримувану засобами конкретної СКБД, називають ще дата-
логiчною.
Iнфологiчна та даталогiчна моделi, якi вiдображають модель
однiєї предметної областi, залежнi мiж собою. Iнфологiчна мо-
дель має легко трансформуватися у даталогiчну модель.
Внутрiшнiй рiвень пов’язаний з фiзичним розмiщенням даних
у пам’ятi ЕОМ. На цьому рiвнi формується фiзична модель БД,
яка вмiщує структури зберiгання даних у пам’ятi ЕОМ, включа-
ючи опис форматiв записiв, порядок їх логiчного або фiзичного
впорядкування, розмiщення за типами пристроїв, а також харак-
теристики i шляхи доступу до даних.
Вiд параметрiв фiзичної моделi залежать такі характеристи-
ки функцiонування БД: обсяг пам’ятi та час реакцiї системи.

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

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

користувачів прикладних програм

Зовнішній рівень
даних

Інфологічний рівень
даних

Даталогічний
рівень даних
Вимоги та обмеження
вибраної СКБД
Внутрішній рівень
даних

Рис. 1.6. Схема взаємозв’язку рівнів подання даних у БД

Схему взаємозв’язку рiвнiв подання даних у БД зображено на

рис. 1.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чної моделi БД. Реструктуризацiя чи внесення
змiн до логiчної моделi БД є дуже небажаним процесом, оскільки
це спричинює необхiднiсть модифiкацiї чи навiть перепрограму-
вання окремих задач.
Усi роботи, якi виконуються на кожному етапi проектування,
повиннi iнтегруватись зі словником даних (схему взаємозв’язку
етапiв зображено на рис. 1.7). Кожний етап проектування розгля-
26
дається як певна послiдовнiсть iтеративних процедур, у резуль-
татi яких формується певна модель БД.

Зовнішнє Інфологічне Даталогічне Фізичне

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

Словник даних

Рис. 1.7. Схема взаємозв’язкiв етапiв проектування зі словником даних

Питання для самоперевiрки

1. Поняття автоматизованого банку даних та його переваги.

2. Структура АБД i характеристика основних його компо-
нентів.
3. СКБД та її функцiї.
4. Мовнi засоби АБД та їх призначення.
5. Які мови запитів поширені у сучасних СКБД?
6. Які функцiї виконує адмiнiстратор бази даних?
7. Які є технології використання багатокористувацьких СКДБ?
8. Охарактеризуйте технологію файл-сервер.
9. Охарактеризуйте технологію клієнт-сервер.
10. Перелічіть та охарактеризуйте етапи проектування бази
даних.
11. Які є підходи до виокремлення рiвнiв подання даних у
базi даних?
12. Що таке словник даних? Яка його роль у створеннi БД?

27
 2 Pозд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ї,
а також перелiк вiдповiдних вихiдних повiдомлень, якi потрiбно
формувати за допомогою АБД.
Iснує два пiдходи до проектування баз даних на зовнiшньому
рiвнi: «вiд предметної областi» та «вiд запиту».
Пiдхiд «вiд предметної областi» полягає в тому, що форму-
ється позамашинне iнформацiйне забезпечення всiєї предметної
областi без урахування поточних потреб користувачiв i приклад-
них програм. Вважається, що поточні потреби автоматично бу-
дуть враховані при такому підході. Iнодi цей пiдхiд називають ще
об’єктним, або непроцесним.
При пiдходi «вiд запиту» основним джерелом iнформацiї про
предметну область є вивчення запитiв користувачiв i потреб при-
кладних програм. Цей пiдхiд називається процесним, або
функцiональним. При такому пiдходi БД проектується для вико-
нання поточних задач управлiння без урахування можливостi
розширення системи i виникнення нових задач управлiння.

27
 Перевагами пiдходу «вiд предметної областi» є
об’єктивнiсть, системнiсть при вiдображеннi ПО i стiйкiсть
iнформацiйної моделi, можливiсть реалiзації великої кiлькості
прикладних програм i запитiв, у тому числi незапланованих при
створеннi БД. Недолiком цього пiдходу є значний обсяг робiт,
що його потрібно виконати при визначеннi iнформацiї, яка
пiдлягає фiксацiї в БД, що вiдповiдно ускладнює i збiльшує
термiн розробки проекту.
Функцiональний пiдхiд орiєнтований на реалiзацiю поточних
вимог користувачiв i прикладних програм без урахування перс-
пектив розвитку системи. При його використаннi можуть виник-
нути складнощi в агрегацiї вимог рiзних користувач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длягають ав-
томатизованому розв’язанню. Оскiльки основною метою ство-
рення БД є забезпечення iнформацiєю функцiй обробки даних, то
насамперед необхiдно вивчити всi функцiї предметної областi
(об’єкта управлiння), для якої розробляється база даних, і про-
аналiзувати їх особливост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. Вивчення та аналiз оперативних первинних документiв.
З’ясувавши функцiї та визначивши перелiк функцiональних за-
дач, що пiдлягають автоматизованому розв’язанню, переходять

28
до вивчення оперативних документ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ї.
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 були визначенi на другому та третьому
кроках. Якщо не вистачає для повного виконання розрахункiв пе-
вних даних, необхiдно повернутися назад, провести дообстежен-
ня i визначитися, де або в який спосіб можна отримати атрибути,
яких не вистачає.
Крiм того, потрібно визначитися, якi з розрахункових показ-
никiв доцiльно зберiгати в БД. Показники, отримані розрахунко-
вим шляхом, як правило, у БД не зберiгаються. Винятком є випад-
ки, коли розрахунковий показник потрiбно використовувати для
розв’язання інших задач чи даної задач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.1.

29
 Документи оператив- Документи оператив- Документи норма-
ної інформації ної інформації тивно-довідкової
(внутрішні) (зовнішні) інформації

Процедури перетворення
вхідних повідомлень
на вихідні

Вихідні Вихідні
машинограми інформаційні Відеограми
масиви

Рис. 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чного проектування.

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
пiдтримуються вiдомими СКБД (мережеві, iєрархiчнi, реляцiйнi);
 IЛМ повинна бути описана мовою, зрозумiлою проектувальни-
кам БД, програмiстам, адмiнiстратору i майбутнiм користувачам АБД.
30
 Основною складовою iнфологiчної моделi є атрибути, якi по-
трiбно проаналiзувати i певним чином згрупувати для подальшого
зберігання в БД.
Суть iнфологiчного моделювання полягає у видiленнi
iнформацiйних об’єктiв (сутностей) ПО, якi пiдлягають зберіганню в
БД, а також у визначеннi характеристик об’єктiв i взаємозв’язкiв мiж
ними.
Iснує два пiдходи до iнфологiчного проектування: аналiз
об’єктiв i синтез атрибутiв. Пiдхiд, що базується на аналiзi
об’єктiв, називається спадним, а на синтезi атрибутiв —
висхiдним. Перший рекомендується використовувати при проек-
туваннi документальних БД, а другий — при розробцi факто-
графiчних систем. У документальних системах об’єктом збері-
гання, пошуку та обробки є цiлий документ, у фактографiчних
системах — окремi данi, що характеризують певнi подiї, явища,
тобто вiдображають факти, якi спостерігаються в реальн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 характеристики об’єкта.
31
Наприклад, об’єкт студент (№ залiкової книжки, ПIБ, рiк наро-
дження, курс, група) є типом, а студент (009393, Костенко О.І.,
1986, 1-й курс, 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в спiввiдношень мiж
атрибутами, які можуть бути такими: 1 : 1, 1 : Б, Б : 1 i Б : Б.
Тип спiввiдношення «один до одного» Т (А1 : А2) = (1 : 1) іс-
нує тодi, коли одному i тому самому значенню атрибута А1
вiдповiдають не бiльше ніж одне значення атрибута А2. Напри-
клад, атрибути «табельний номер i прiзвище», «iм’я та по бать-
ковi» перебувають у спiввiдношеннi 1:1.
Тип спiввiдношення «один до багатьох» Т (А1 : А2) = (1 : Б)
iснує тодi, коли одному значенню атрибута А1 має вiдповiдати
багато значень атрибута А2. Водночас будь-якому екземпляру

32
атрибута А2 може вiдповiдати не бiльше ніж один екземпляр ат-
рибута А1. Наприклад, мiж атрибутами Т (цех : бригада) = 1 : Б.
Тип спiввiдношення «багато до одного» Т (А1 : А2) = (Б : 1)
iснує, коли одному значенню атрибута А1 вiдповiдає щонайбільше
одне значення атрибута А2, а будь-якому атрибуту А2 може від-
повідати багато значень атрибута А1. Якщо Т (А1 : А2) = Б:1,
тодi Т (А2 : А1) = 1 : Б.
Тип спiввiдношення «багато до багатьох» Т (А1 : А2) = Б : Б
означає, що будь-якому значенню А1 може вiдповiдати кiлька
значень А2 i водночас, навпаки, будь-якому значенню А2 може
вiдповiдати кiлька значень А1. Наприклад, Т (матерiал : постача-
льник) = Б : Б, тобто один i той самий матерiал може постачатися
рiзними постачальниками i, навпаки, один постачальник може
постачати рiзнi матерiали.

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

Iнфологiчнi моделі мають велике значення при

вiдображеннi семантики модельованої предметної областi. Iснує
кiлька методик iнфологiчного проектування. Найповніше методи-
ку з елементами формалiзацiї запропоновано в [4]. Її покладено в
основу викладення цього роздiлу. Схему взаємозв’язку робiт при
iнфологiчному проектуваннi показано на рис. 2.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 назви ви-
лучити зі списку. Наприклад, атрибути «верстат», «обладнання»,
«основний засiб», «пристрiй» є синонiмiчними, тому в перелiку

33
атрибутів замість групи потрібно залишати лише один атрибут
«обладнання».
Вилучення синонімії, омонімії та узагальнення атрибутів

Агрегація атрибутів і виокремлення інформаційних об’єктів

Перевірка об’єктів на відповідність умовам нормалізації

Зовнішнє кодування

Виявлення та опис інформаційних запитів до бази даних

Формалізований опис інформаційних запитів

у вигляді запиту вальних зв’язків

Аналіз і зведення запитувальних

зв’язків до канонічного вигляду

Побудова структурних зв’язків і графічне

зображення інфологічної моделі

Перевірка інфологічної моделі на коректність

Рис. 2.2. Схема взаємозв’язку робiт при iнфологiчному проектуваннi

бази даних
Складаючи список атрибутiв, можливо, необхiдно виконати
ще одну операцiю, яка називається узагальненням. При цьому де-
яку сукупнiсть атрибутiв замiнюють одним атрибутом, який уза-
гальнює сутнiсть представленої групи. Наприклад, у перелiку ат-
рибутiв є такi: токар, фрезерувальник, слюсар i т. д. Цю групу
можна замiнити одним атрибутом «спецiальність». Отже, уза-
гальненню пiдлягають атрибути, що мають однакові формат i се-
мантику.
2.Другий крок — агрегацiя атрибутiв i компонування їх в
iнформацiйнi об’єкти. Процес агрегацiї атрибутiв i визначення
об’єктiв є iтеративним, тобто послiдовним.
Для великих i складних систем з рiзними функцiями i великою
кiлькiстю документацiї перелiк атрибутiв аналiзують окремо по
34
кожнiй функцiональнiй задачi чи їх комплексу. В основi агрегацiї
лежить аналiз типiв спiввiдношень мiж атрибутами.
Порядок виконання процедури агрегації такий.
2.1. Спочатку серед атрибутiв виокремлюються тi, мiж якими
iснує однозначний зв’язок в обох напрямах (1 : 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 виконання 2.1
один i той самий атрибут може потрапити до кiлькох об’єктiв.
Наприклад, код робiтника може бути включений до об’єкта
«ПРАЦIВНИК», який уміщує всю довiдкову iнформацiю про
працюючих на пiдприємствi, а також до об’єкта «ВИРОБIТОК»,
що вмiщує данi про щоденний виробiток кожного робiтника.
2.2.Пiсля багаторазового виконання 2.1 перевiряють атрибути,
що залишились, на тип спiввiдношення з виокремленими
об’єктами; якщо серед них є такi, що перебувають у
спiввiдношеннi 1 : 1 з виокремленими об’єктами, то їх приєднують
до вiдповiдних об’єктiв.
2.3.Якщо серед решти атрибутiв немає таких, якi б перебу-
вали з виокремленими об’єктами у спiввiдношеннi 1 : 1, то
необхiдно виконати перевiрку на спiввiдношення 1 : Б мiж ре-
штою атрибутів і виокремленими об’єктами. При такому типi
спiввiдношення може існувати функцiональна залежність, але
слiд пам’ятати, що спiввiдношення 1 : Б у цьому разі означа-
тиме те, що в екземплярах об’єкта можуть дублюватись зна-
чення даного атрибута. Такi атрибути приєднуються до виок-
ремлених об’єктiв.
2.4.Якщо пiсля виконання описаного аналiзу ще залишаться
атрибути i серед них немає таких, якi б перебували з виокремле-
ними об’єктами у спiввiдношеннi 1 : 1 чи 1 : Б, то вирiшують пи-
тання про створення з решти атрибутiв окремих нових об’єктiв.
Не виключена можливiсть, що при цьому може з’явитися об’єкт,
який містить лише один атрибут. Це свiдчить про те, що існують
недолiки в проектуваннi на зовнiшньому рiвнi. Тому потрiбно
виконати дообстеження ПО з погляду поповнення таких об’єктів
атрибутами, яких бракує.

35
 Отриман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в виконано бездоганно, то
вони автоматично розміщуватимуться в 3НФ чи 4НФ. Але якщо
предметна область досить складна i велика, налiчує багато атри-
бутiв та iнформацiйних об’єктiв, то краще, аби переконатися, що
не припущено помилок на попередньому етапi, ще раз перевiрити
об’єкти на вiдповiднiсть умовам нормалiзацiї.
Теорiю нормалiзацiї викладено в розд. 4 пропонованого на-
вчального посібника.
4.Зовнiшнє кодування. На цьому етапі необхiдно вивчити ат-
рибути з неунiкальними значеннями. Якщо цi атрибути представ-
ленi досить довгими текстами, то необхiдно вирiшити питання
про доцільність замiни їх на короткi кодовi позначення. У цьому
разі в iнфологiчну модель вноситься новий iнформацiйний
об’єкт, який доречно назвати «ДОВIДНИК». Вiн буде складати-
меться з коду атрибута та його текстового значення. При цьому в
усiх ранiше виокремлених об’єктах текстовi значення
замiнюються на код.
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.

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

Oписуючи запит, також потрiбно враховувати режим його вико-

нання. Режими бувають одиночними i множинними. Одиночний
режим — це такий, коли запит виконується для одного екземпляра
початкового об’єкта, наприклад «Для заданого ПОСТАЧАЛЬНИКА
...». Множинний режим означає багаторазове виконання запиту для
всiх екземплярiв початкового об’єкта чи їх пiдмножини, наприклад
«Для всiх ПОСТАЧАЛЬНИКIВ ...». Отже, коли в запитi вказано
«для всiх» чи «для кожного», то передбачається виконання запиту
для багатьоx екземплярiв початкового об’єкта. Це свiдчить про те,
що при реалiзацiї алгоритму, екземпляри даного об’єкта вибирають
i обробляють послiдовно. Якщо в запитi вказано слова «для задано-
го», «для певного», це означає, що запит виконується для конкрет-
ного одного екземпляра початкового об’єкта, пошук якого при ре-
алiзацiї запиту можна виконувати за ключем.
6.Кожний запит необхiдно подати в структурованому виглядi
вiдповiдним запитувальним зв’язком. Узагальнена форма запиту-
вального зв’язку така:
X X 2 , ... , X n
Z У1 ,
де Х1, Х2, ..., Хn — початковi об’єкти, якi потрiбно розмістити в
порядку iнформацiйного пошуку чи в порядку зменшення групу-
вальної ознаки об’єктiв;
У — кiнцевий об’єкт, який уособлює мету реалiзацiї запиту
(вiн має бути завжди один).
Початкові й кiнцеві об’єкти виокремлюють на основi семан-
тичного аналiзу запиту. Якщо в результатi аналiзу виокремлено
кiлька кiнцевих об’єктiв, це означає, що один запит вмiщує
кiлька одновимiрних запитувальних зв’язкiв.

37
 Запити бувають одновимірні і багатовимірні. Запит, в якого на
вході є один початковий об’єкт, називається одновимірним, в яко-
го на вході кілька початкових об’єктів, — є багатовимірним. На-
приклад, запит «Видати список студентiв певної ГРУПИ заданого
ФАКУЛЬТЕТУ, вказаного КУРСУ» є багатовимiрним, оскільки
йому вiдповiдає такий запитувальний зв’язок:
ФАКУЛЬТЕТ, КУРС
Z ГРУПА

Запит «Видати список СПIВРОБIТНИКIВ зазначеного ВIДДIЛУ»

буде одновимiрним:
ВІДДІЛ
Z СПІВРОБІТНИК
Два запитувальних зв’язки тотожнi, якщо результати їх вико-
нання збігаються.
Усi одновимiрнi запитувальнi зв’язки не пiдлягають подаль-
шому аналiзу i перетворенням, їх можна одразу використовувати
для побудови структурних зв’язкiв. Багатовимiрнi зв’язки нео-
бхiдно додатково проаналiзувати i перевiрити їх на вiдповiднiсть
умовам канонiчностi.
7.На сьомому кроцi iнфологiчного проектування запитувальні
зв’язки перевіряють на вiдповiднiсть умовам канонiчностi.
Канонiчний запитувальний зв’язок — це такий багато-
вимiрний зв’язок, в якому:
 тип спiввiдношення мiж будь-якими двома початковими
об’єктами може бути лише Б:Б;
 тип спiввiдношення мiж будь-яким початковим i кiнцевим
об’єктaми не може бути Б:1.
Якщо багатовимiрний запитувальний зв’язок не є канонiчним,
то виконується ряд перетворень для зведення його до ка-
нонiчного вигляду.
Перетворення 1. Нехай у багатовимiрному запитувальному
зв’язку
Z У1
X , X 2 , ... , X n
.
Спiввiдношення мiж початковими об’єктами Т (Х1 : Х2) = 1 : Б,
тобто порушенo умову канонiчностi. Тодi запитувальний зв’язок
потрібно перетворити на тотожний ланцюжок запитувальних
зв’язкiв:
X 2 , X 3 ,..., X n
X , X 2 , ..., X n
Z У1 Z ХХ 12 Z У
.

38
 Наприклад:
«Видати список РОБIТНИКIВ, зазначивши їхні паспортнi данi,
заданих ЦЕХУ, ДІЛЬНИЦІ, БРИГАДИ».
ЦЕХ, ДІЛЬНИЦЯ, БРИГАДА
Z РОБІТНИК
У цьому запитi спiввiдношення Т (ЦЕХ : ДІЛЬНИЦЯ) = 1 : Б,
тобто необхiдно виконати перетворення 1.
Подамо запит у вигляді запитувального зв’язку і виконаємо
перетворення 1.
ЦЕХ, ДІЛЬНИЦЯ, БРИГАДА ЦЕХ ДІЛЬНИЦЯ, БРИГАДА
Z РОБІТНИК
Z ДІЛЬНИЦЯ Z РОБІТНИК

У результатi отримаємо ланцюжок тотожних запитувальних

зв’язкiв, який складається з одно- та багатовимiрного запитува-
льних зв’язків. Багатовимiрний запитувальний зв’язок знову по-
трiбно перевiрити на канонiчнiсть. Перевiрка показує, що
спiввiдношення мiж початковими об’єктами зв’язку Т (ДІЛЬНИ-
ЦЯ : БРИГАДА) = 1 : Б, тому отриманий на першому кроцi бага-
товимiрний запитувальний зв’язок необхiдно ще раз розкласти
згідно з перетворенням 1. У результатi виконання двох iтерацiй
початковий запитувальний зв’язок буде перетворено на такий то-
тожний ланцюжок запитувальних зв’язкiв:
ЦЕХ, ДІЛЬНИЦЯ, БРИГАДА ЦЕХ ДІЛЬНИЦЯ БРИГАДА
Z РОБІТНИК
Z ДІЛЬНИЦЯ Z БРИГАДА Z РОБІТНИК

Можливi багатовимiрнi запитувальнi зв’язки, для яких пере-

творення 1 виконується багаторазово, внаслідок чого початковий
запитувальний зв’язок зaмiнюється сукупнiстю, яка вміщує
кiлька одновимiрних i закiнчується багатовимiрним запитуваль-
ним зв’язком меншої розмiрностi, ніж початковий, який одразу
буде канонiчним, тобто не пiдлягатиме розкладанню на простiші
зв’язки.
Примітка 1. Пiсля виконання перетворення 1 отримуємо деяку по-
! слiдовнiсть запитувальних зв’язкiв, якi треба проаналiзувати на
доцiльнiсть їх урахування в iнфологiчнiй моделi. Аналiз виконують
на базi аналiзу семантики початкового запиту i форми видачi ре-
зультатiв користувачеві. Якщо в кiнцевому результаті користувача
цiкавить лише вибiрка екземплярiв об’єкта Хn i для нього можна за-
дати ключ пошуку, то вiдомостi про об’єкти Х1, Х2, ...., Хn–1 є надмір-
ними i їх можна не включати до опису iнформацiйного запиту.

39
 Якщо послiдовнiсть одновимiрних запитувальних зв’язкiв
використовується не лише для вибору екземплярiв об’єкта Хn, а
в алгоритмi вiдповiдного процесу потрiбнi екземпляри об’єктiв
Х1, Х2, ...., Хn–1, то всi запитувальнi зв’язки потрібно залишати i
описати.
Перетворення 2. Нехай iснує багатовимiрний запитувальний
зв’язок, спiввiдношення мiж початковим і кінцевим об’єктами
якого Т (Х1, У) = Б : 1. Тоді потрiбно виконати таке перетворення:
X , X 2 ,..., X n
Z У1  Z xy1 Z xX12,...хn

Наприклад, дано запит «По вказаному МАГАЗИНУ надати

інформацію про всі ТОВАРИ та ЗАМОВЛЕННЯ на них».
Цьому запиту відповідає такий запитувальний зв’язок:
ТОВАРИ, ЗАМОВЛЕННЯ
Z МАГАЗИН

Зазначений запитувальний зв’язок характеризується такими

співвідношеннями: Т (ТОВАРИ : ЗАМОВЛЕННЯ) = Б : Б;
Т (ТОВАРИ : МАГАЗИН) = Б : 1.
Тоді згідно з перетворенням 2 зв’язок можна перетворити так:
Z ЗАМОВЛЕННЯ , ТОВАР
МАГАЗИН Z МАГАЗИН
ЗАМОВЛЛЕННЯ Z ЗАМОВЛЕННЯ
ТОВАР

Примітка 2. Якщо перетворення 2 виконано над багатовимірним

! запитувальним зв’язком з двома вхідними об’єктами, то йому мо-
жуть бути поставлені у відповідність два тотожних запитувальних
зв’язки:
X ,Х2
Z У1  Z ху1 Z хX1 2  Z yx 2 Z xХ21
Справді,
Z ЗАМОВЛЕННЯ, ТОВАР
МАГАЗИН Z МАГАЗИН
ЗАМОВЛЕННЯ Z ЗАМОВЛЕННЯ
ТОВАР Z МАГАЗИН
ТОВАР Z ТОВАР
ЗАМОВЛЕННЯ

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

цюжку, який швидше можна виконати. У нашому випадку це —
перший ланцюжок. Визначитися щодо того, на виконання якого
ланцюжка буде витрачено менше часу, можна за допомогою ана-
лізу алгоритмів реалізації обох варіантів. Проаналізуємо праву й
ліву сторони наведених співвідношень. У першому випадку для
вказаного в інформаційному об’єкті «МАГАЗИН» магазину ви-
бирають всі замовлення, що знаходяться, і об’єкти із «ЗАМОВ-
ЛЕННЯ», а потім по коду товару, що вказаний у замовленні, ви-
значаються їх назви в об’єкті «ТОВАР».

40
 Також змоделюємо алгоритм i проаналiзуємо лiву частину
спiввiдношення. Спочатку для заданого магазину з об’єкті «МА-
ГАЗИН» вибирають всі товари з об’єкта «ТОВАР», що є у мага-
зині. Потім, переглядаючи кожен товар з об’єкта «ТОВАРИ», ви-
бирають ті, на які є замовлення в об’єкті «ЗАМОВЛЕННЯ».
Такий аналiз алгоритму в реалiзацiї обох ланцюжкiв показує,
що для реалiзацiї другого ланцюжка потрiбно виконувати бiльші
вибірки i переглядати бiльшу кiлькiсть записiв, а отже, на це по-
трiбно буде витратити бiльше машинного часу. Тому перевагу
віддають правому ланцюжку, який залишають для наступного
аналiзу, а лiвий вiдкидають.
Зауваження. Описуючи запити запитувальними зв’язками, необ-
! хідно керуватися такими правилами. Спочатку потрібно кла-
сифiкувати запитувальнi зв’язки на двi групи:
а) запитувальнi зв’язки iнформацiйно-пошукового характеру (по-
шук, упорядкування, логiчнi порiвняння, видача довiдок);
б) запитувальнi зв’язки, для реалiзацiї яких необхiдно виконувати
розрахунки, пов’язані з обробкою кiлькох iнформацiйних масивiв.
Якщо запит має лише iнформацiйно-пошуковий характер, то його
описують згiдно з наведеною методикою у виглядi багато-
вимiрного запитувального зв’язку, перевiряють на вiдповiднiсть
канонiчностi i виконують вiдповiднi перетворення.
Другий тип запитiв досить складно описувати за розглянутими
правилами. Тому для другого типу запитiв необхiдно виконати
аналiз i серед об’єктiв, задiяних у запитi, виокремити головнi (про-
відні) та довiдковi.
Головними, або провідними, будуть тi об’єкти, з перегляду яких
починається реалiзацiя запиту і дані яких використовуються в пев-
них розрахунках. Довiдковими є об’єкти, iнформацiя яких викори-
стовується для довiдкових цiлей, наприклад для розшифрування
табельного номера працiвника вiдповiдним прiзвищем, iм’ям і по
батьковi при видачi на друк чи на екран вiдповiдного вихiдного
повiдомлення.
Для запитів, пов’язаних з розрахунками, практично неможливо
подати запитувальні зв’язки згідно з описаною методикою. Тому
при їх формалізованому описі необхідно моделювати алгоритм і
подавати запитувальний зв’язок одразу у вигляді ланцюжка за-
питувальних зв’язків. Розглянемо приклад: «Провести аналіз
розрахунків за відвантажену готову продукцію і виявити борж-
ників серед її споживачів». Головними, або провідними, в реалі-
зації цього запиту будуть об’єкти «відвантаження» та «розрахун-
ки». Порівнюючи екземпляри цих об’єктів, можна визначити, по
яких операціях відвантаження не було виконано відповідних роз-
рахунків. Об’єкти «продукція» та «споживачі» є довідковими і
використовуватимуться лише для розшифрування відповідних
кодів продукції та споживача при друкуванні результату запиту.
Тому формалізовано запитувальний зв’язок можна записати у та-
кому вигляді:

41
 ВІДВАНТАЖЕННЯ ВІДВАНТАЖЕННЯ ВІДВАНТАЖЕННЯ
Z РОЗРАХУНКИ Z ПРОДУКТИ Z СПОЖИВАННЯ

7. Пiсля того як всi запитувальнi зв’язки зведенi до ка-

нонiчного виду, розпочинають побудову структурних зв’язкiв
мiж iнформацiйними об’єктами i графiчну побудову iнфологiчної
моделi. Перш нiж перейти до правил графiчної побудови IЛМ,
розглянемо iснуючi пiдходи до графiчного вiдображення
подiбних моделей.
Для графiчного вiдображення моделей даних часто викорис-
товують ER-моделi (entity relationship) або моделі Чена (за іменем
їх автора). ER-модель була запропонована як засiб графiчного зо-
браження схеми предметної областi, яка не залежить вiд особли-
востей середовища зберiгання, тобто вiд СУБД. Базовими елеме-
нтами ER-моделi є типи сутностей і типи зв’язкiв. Графiчно ER-
дiаграму для фрагмента такої предметної областi, як вищий на-
вчальний заклад, можна зобразити такою ERD (ER-дiаграмою),
на якiй сутностi мають вигляд прямокутникiв, а зв’язки — орієн-
тованих дуг (рис. 2.3). Дуга, що завершується двома стрілками,
вказує на зв’язок 1 : Б, а дуга, що завершується однією стрілкою,
— на зв’язок 1:1.

Університет

Складається

Факультети Студенти

Складають

Кафедри Вивчають

Працюють

Викладачі Дисципліни Програма

Викладають Має

Рис. 2.3. ER-дiаграма фрагмента предметної областi «вищий навчаль-

ний заклад»

Засоби графiчного вiдображення, за допомогою яких буду-

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

42
не змінюється. Тому не будемо зупинятись на детальному аналiзi
цих вiдмiнностей.
Розглянемо правила побудови структурних зв’язків.
Правило 1. Нехай в одновимірному запитувальному зв’язку
співвідношення Т (Х1, У) = 1 : Б, тодi початковий об’єкт Х1 ого-
лошується як власник структурного зв’язку, а кiнцевий У —
пiдпорядкованим об’єктом.
Ознака «Напрямок руху» набуває значення S1 = ВП (графiчно
це вiдображено на рис. 2.4). Подвоєна стрiлка вказує на те, що
екземплярiв пiдпорядкованого об’єкта може бути багато. За цим
самим правилом будують зв’язок при співвідношенні 1:1, проте в
цьому разі стрілка не подвоюється.
Х

S1

Рис. 2.4
Правило 2. Нехай в одновимiрному запитувальному зв’язку
спiввiдношення Т (Х1, У) = Б : 1, тодi кiнцевий об’єкт У оголошу-
ється власником структурного зв’язку, початковий Х1 — пiдпоряд-
кованим об’єктом, а ознака «Напрямок руху» набув значення S2
= ПВ (графiчно це показано на рис. 2.5).
Х

S2

Рис. 2.5
Правило 3. Нехай в одновимірному запитувальному зв’язку
співвідношення Т (Х1, У) = Б : Б, тодi Х1 i У оголошуються як
власники двох структурних зв’язків. Підпорядкованим об’єктом
оголошується новий об’єкт, який називається об’єктом-зв’язкою
(графічно це відображено на рис. 2.6).
У структурному зв’язку, де власником є об’єкт Х, напрямок
руху ВП, а в структурному зв’язку, де власником є кінцевий
об’єкт У, — напрямок руху ПВ. Для об’єкта-зв’язки клас членст-
ва в обох зв’язках обов’язковий.

43
 У Х
S2 S1
OS

Рис. 2.6

Об’єкти-зв’язки мають бути семантично визначенi, їм при-

своюється iм’я i задаються характеристики, тобто визначаються
атрибути, якi повиннi входити до їх складу.
Досить часто об’єктом-зв’язкою виступає той об’єкт, який не
визначили на бiльш раннiх стадiях проектування. До складу
об’єктa-зв’язки обов’язково повиннi входити первинні ключовi
атрибути тих об’єктiв, зв’язок мiж якими встановлюється. Крім
ключових атрибутів, до об’єкта-зв’язки можуть додатково входи-
ти атрибути, що уточнюють семантику зв’язку, що розглядається.
Наприклад, є два об’єкти, мiж якими існує тип спiввiдношення Б
: Б; Т (ДЕТАЛЬ : МАТЕРIАЛ) = Б : Б. Об’єктом-зв’язкою тут
може виступати такий об’єкт як «НОРМА», який вміщуватиме
первинні ключі «код деталi» і «код матерiалу» та неключовий ат-
рибут «норму витрат матерiалу на одну деталь».
Правило 4. Нехай маємо багатовимiрний запитувальний зв’язок
канонiчного вигляду:
ZУX1 , X 2 ,
тоді (рис. 2.7):
У Х2 Х1
S2
S3 S1
OS

Рис. 2.7
 усi початковi й кiнцевi об’єкти оголошуються власниками
кiлькох структурних зв’язкiв;
 підпорядкованим у всiх структурних зв’язках оголошується
новий об’єкт-зв’язка;
 об’єкт-зв’язка оголошується обов’язковим у всiх структур-
них зв’язках;
 для одного структурного зв’язку, де власник — початковий
об’єкт, напрямок руху позначається ВП, для всiх iнших — ПВ.

44
 2.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 допус-
кається вилучати структурні зв’язки, якщо решта зв’язків забез-
печують повне та коректне виконання всіх інформаційних запи-
тів. Виконуючи ці перетворення, можна навіть вилучати об’єкти-
зв’язки, а також узагальнювати деякі об’єкти.
Розглянемо два найтиповіших варіанти перетворення струк-
тури.
1. Нехай мiж трьома об’єктами А, В i С виявлено три структур-
них зв’язки S1, S2 i S3 (рис. 2.8). Для того щоб вирішити питання
про надлишковiсть зв’язку S3, необхiдно переконатися, що ре-
зультати проходження по зв’язку S3 i зв’язках S1, S2 для будь-
якoго екземплярa об’єкта А повнiстю збігаються. У противному
разі зв’язок S3 вилучати не можна.
Якщо зв’язок можна вилучити, то необхідно модифікувати ха-
рактеристики решти зв’язків, аби вони забезпечували реалізацію
функцій вилученого зв’язку (рис. 2.9).

А А

S1 S1
В S3 В

S2 S2
С С

Рис. 2.8 Рис. 2.9

45
 2. Нехай iнфологiчна модель складається з чотирьох об’єктів:
А, В, С і D, два з яких — С i D — є об’єктами-зв’язками (рис.
2.10). У такому разі між об’єктами А і В існує два маршрути і
порушується питання про надлишковість одного з них. Як і в
першому випадку, якщо хоча б один екземпляр об’єкта. А
зв’язаний з різними екземплярами об’єкта В за маршрутами S1,
S2 i S3, S4, то перетворення виконувати не можна.
A B
S1 S2
S3 C S4

Рис. 2.10

Якщо перетворення можливе, проектувальник повинен про-

аналізувати об’єкти-зв’язки на тип співвідношення між ними.
Якщо між ними існує співвідношення 1 : 1, їх можна об’єднати в
один об’єкт (рис. 2.11). Тоді надлишкові зв’язки вилучаються і
коригуються характеристики решти зв’язків.

A B

S1 S2
CD

Рис. 2.11

Якщо між об’єктами С i D тип співвідношення 1 : Б, то замість

вилучених структурних зв’язків S3 i S4 необхідно встановити
зв’язок L1 між об’єктами С i D (рис. 2.12).

46
 А В

S1 S2
C

L1

Рис. 2.12
Об’єкти інфологічної моделі можна узагальнювати, виходячи
зі спорідненості їх структур, семантики та ролi в процесах об-
робки. Наприклад, облiк руху матер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.6. Опис складових інфологічної моделі

Усі складові інфологічної моделі описуються у вигляді

таблиць, які використовуються при проектуванні БД на даталогіч-
ному і фізичному рівнях. Ці описи можна вважати складовою
словника-довідника БД, якщо він ведеться вручну. У табл. 2.1 на-
ведено форму опису атрибутів, який виконано по кожному інфо-
рмаційному об’єкту окремо.
Пояснимо. Формат визначає категорію і довжину значення ат-
рибута. Його пропонується задавати в символіці, що добре себе
зарекомендувала й прийнята в Коболі. При цьому можна обме-
житися такими символами:
9 — позначення десяткової цифри;
Х — позначення будь-якого символу, цифри, букви чи іншого
знака, який використовується в значенні атрибута;
А — позначення букви;

47
 . — позначення десяткової крапки в цифрових атрибутах, які
мають дробове значення;
S — позначення знаку «+» чи «—».
У форматі числа в дужках вказують на кількість повторів сим-
волу в форматі. Наприклад, для атрибута «рік народження» —
формат 9(4), а для атрибута «код виробу» — формат А(18), тобто
код виробу можна описати 18 довільними символами. Якщо ат-
рибут має змінну довжину, то описується максимально допусти-
ма довжина.
Ознака «Відсоток наявності», тобто відсоток наявності зна-
чень атрибута в екземплярах об’єкта дає змогу виявити атрибути,
які присутні не в усіх екземплярах об’єкта. Наприклад, такий ат-
рибут як «номер диплома», може бути присутнім не в усіх екземп-
лярах об’єкта «СПІВРОБІТНИК», він може, припустимо, дорів-
нювати 75 %. Це означатиме, що такий відсоток співробітників
мають диплом.

48
 ОПИС СКЛАДОВИХ ЕЛЕМЕНТІВ

Назва атрибута Формат Відсоток Обмеження на право зве-

наявності ртання

Код підприємства 9(8) 100 %

Дата подання заявки Х(8) 100 %
Мають право началь-
Сума необхідного кредиту 9(9)9(2) 100 % ник та інспектор кре-
дитного відділу
Термін кредиту 9(2) 100 %
Код виду забезпечення 9(1) 100 %

«Обмеження на право звертання» до значень атрибутів зада-

ють лише тоді, коли є певні обмеження, що відрізняються від
аналогічних обмежень, заданих для всього об’єкта. Наприклад,
в об’єкті «СПІВРОБІТНИК» є атрибут «сума вкладу на ощадк-
нижці». Ця інформація не може бути доступна всім користувачам
відповідного об’єкта. У цій графі табл. 2.1 можна проставляти
список імен груп користувачів, яким дозволено чи, навпаки, не
дозволено звертатися до цього атрибута.
Частота використання атрибута. Ця характеристика дає змогу
виявити атрибути об’єкта, які використовуються значно рідше
або частіше за інші атрибути. У цій графі проставляють число
звертань за певний період: дату, тиждень, квартал і т. п.
Область допустимих значень задають не обов’язково для
кожного атрибута. Областю може бути перелік можливих зна-
чень атрибута чи інтервали значень, а також алгоритм перевір-
ки коректності значень, наведений у додатку до інфологічної
моделі ПО.
Вивідність значень означає, що відповідний атрибут може бу-
ти отриманий алгоритмічно в результаті обчислень з використан-
ням інших атрибутів. У цьому разі у відповідній графі табл. 2.1
проставляють «Так», а сам алгоритм наводять у додатку до інфо-
логічної моделі.
У графі «Дублювання значень» проставляють «Так», якщо ат-
рибут може мати однакове значення в різних екземплярах
об’єкта, в противному разі проставляють «Ні». Наприклад, в
об’єкті «співробітник» атрибут «професія» може дублюватись,
оскільки різні співробітники можуть мати однакову професію.
Об’єкти інфологічної моделі описують за даними, наведеними
в табл. 2.2.

49
 Таблиця 2.1
ОБ’ЄКТА «ЗАЯВКА НА КРЕДИТ»

Частота вико- Вивідність Дублювання Допустимі Роль атрибута та інші

ристання значень значень, % значення характеристики

За потребою — Ні Первинний ключ

—“— — Так
—“— — Так
—“— — Так
—“— — Так

Також пояснимо цю таблицю. Графа «Спосіб звертання до ек-

земплярів об’єкта» означає, що для кожного об’єкта є можливість
звертатися до його екземплярів по структурних зв’язках, в яких
він бере участь. Ця ознака об’єкта передбачає можливість звер-
тань до екземплярів незалежно від структурних зв’язків. Якщо у
відповідній графі табл. 2.2 стоятиме літера К, то це означає мож-
ливість звертання до екземплярів об’єкта за ключем (у дужках
потрібно записувати імена атрибутів, які можуть виступати в ролі
ключових). Наприклад, «К = Код матеріалу» означає, що екземп-
ляр об’єкта «матеріал» буде вибраний за ключем «код матеріа-
лу». Якщо ж у графі 2 стоятиме літера М, то це означає, що пе-
редбачається можливість звертання до багатьох екземплярів.
Якщо потрібно вибрати не всі екземпляри об’єкта, а лише ті, що
відповідають певній умові, то після літери М у дужках наводять
імена пошукових атрибутів, які використовуються у вибірці. На-
приклад, М (постачальник, дата) для об’єкта «матеріал» означає,
що потрібна вибірка інформації про матеріали, які поставляються
певними постачальниками за вказаний період.
Структурна активність об’єкта. Ця ознака може мати значення
«Так» чи «Ні». Стверджувальну вiдповiдь проставляють у тому
разі, якщо об’єкт у майбутньому при розширеннi БД може стати
учасником нового структурного зв’язку. Це можливо тоді, коли
планується розширення ПО, для якої моделюється БД. Але не
завжди на етапi iнфологiчного проектування можна передбачити
розширення предметної областi, тому частiше ця ознака набуває
значення «Нi».
У графі «Обмеження на право звертання до екземплярів
об’єкта», як і в табл. 2.1, проставляють список користувачів, яким
дозволено (чи не дозволено) звертатися до екземплярів об’єкта.

50
 ОПИС ХАРАКТЕ

Найменування Спосіб звертання до екземп- Структурна Обмеження на пра-

лярів активність во звертання

Деталь К (код деталі) — —

Робітник М, К (табельний номер) — —

ОПИС СТРУК

Назва структурного Напрям руху Спосіб упорядкування Обмеження на

зв’язку по зв’язку екземплярів підпорядко- право руху
ваного об’єкта

Частота використання. Ознака для виокремлення об’єктів, які

використовуються набагато частіше або, навпаки, рідше за інші.
Значення ознаки дорівнює кількості звертань до екземплярів за
вибраний інтервал часу.
Значення ознаки «Кількість екземплярів об’єкта» визначає мак-
симально можливу кількість екземплярів об’єкта. Змінність скла-
ду екземплярів задає відсоток оновлення складу екземплярів
об’єкта за вибраний відрізок часу.
Структурні зв’язки описано в табл. 2.3.
Охарактеризуємо основні складові цієї таблиці. Напрям руху по
структурному зв’язку визначає можливу навігацію між об’єктами,
які беруть участь у структурному зв’язку. Він може набувати кіль-
кох значень. Значення ВП означає, що забезпечується перехід від
власника до підпорядкованого об’єкта, графічно це зображується
стрілкою, спрямованою вниз . Значення ПВ, навпаки, означає пе-
рехід від власника до підпорядкованого об’єкта. Цей зв’язок зобра-
жується . Третє можливе значення цієї ознаки ВПВ забезпечує
можливість переходу в обох напрямках: від власника до підпоряд-
кованого об’єкта, і навпаки. Цей зв’язок зображується . Одинар-
ною стрілкою позначають у тих випадках, коли співвідношення між
об’єктами становить 1 : 1; якщо ж співвідношення дорівнює 1 : Б, Б
: 1 чи Б : Б, то стрілка подвоюється. Наприклад, зв’язок об’єктів «де-
таль : верстат» = 1 : Б характеризується ВП, тоді стрілка в графі
зв’язку цих об’єктів подвоюється і зображується — .
51
 Таблиця 2.2
РИСТИК ОБ’ЄКТІВ

Частота використан- Кількість екземплярів Змінність скла- Примітка

ня ду, %

— 2000 —
— 1500 15

Таблиця 2.3
ТУРНИХ ЗВ’ЯЗКІВ

Частота вико- Кількість екземплярів Клас член- Переміщува- Обмеження

ристання підпорядкованого ства ність на час руху
об’єкта

Спосіб упорядкування екземплярів підпорядкованого об’єкта.

Цій ознаці присвоюють значення лише тоді, коли попередня
ознака визначена як ВП чи ВПВ. Ознака вказує на послідовність
упорядкування екземплярів підпорядкованого об’єкта в списку
екземплярів структурного зв’язку. Значення цієї характеристики
зображують похилою стрілкою, яка позначає відповідно впоряд-
кування за зростанням ( ) чи спаданням ключа ( ). Якщо
ключ не є унікальним, тобто можливе його дублювання, то поряд
з іменем ключа проставляють літеру Д. Наприклад, у значенні
ДАТА Д означає, що об’єкт підпорядкований за зростанням клю-
ча ДАТА, який не є унікальним. При довільному впорядкуванні
відповідну графу таблиці не заповнюють.
Ознака «Обмеження на право руху по структурному зв’язку»
вказує на наявність або відсутність обмежень з боку користувачів
на право користування зв’язком. Коли якісь обмеження існують,
то у відповідній графі табл. 2.3 проставляють перелік осіб, на які
ці обмеження поширюються, чи навпаки.
Частота використання означає кількість використань структур-
ного зв’язку за певний період. Але не завжди на етапі інфологіч-
ного проектування можна точно з’ясувати цю величину, тому у
відповідній графі табл. 2.3 проставляють орієнтовану цифру, яку
можна визначити точніше на наступних етапах проектування.
Значення ознаки «Кількість екземплярів підпорядкованого
об’єкта в структурному зв’язку» може бути сталим, тобто фіксо-
ваним у всіх екземплярах структурного зв’язку, або змінним (різ-
ним). Причому в останньому випадку обмежень на максимальну

52
кількість екземплярів може не існувати. Якщо кількість фіксова-
на, ознаку задають так: ФІКС (m), де m — кількість екземплярів
підпорядкованого об’єкта в кожному екземплярі структурного
зв’язку. При змінному значенні ця ознака така: ЗМІН (n1, n2), де
n1 — кількість екземплярів, яка найчастіше використовується в
зв’язках; n2 — максимально можлива кількість.
Клас членства підпорядкованого об’єкта. Ця ознака може мати
два значення — обов’язковий і необов’язковий. Це відповідно озна-
чає, що кожний екземпляр підпорядкованого об’єкта в кожний мо-
мент бере участь у деякому екземплярі структурного зв’язку і, на-
впаки, можуть існувати екземпляри підпорядкованого об’єкта, які
не беруть участі в даному структурному зв’язку.
Ознака «Переміщуваність екземплярів підпорядкованого
об’єкта в структурному зв’язку» може мати два значення —
«Так» чи «Ні», що означає відповідно можливість (заборону) пе-
реміщуватись екземплярам підпорядкованого об’єкта з одного
екземпляра структурного зв’язку в інший.
Якщо структурний зв’язок забезпечує рух в обох напрямках,
то ознака «Обмеження на час руху по структурному зв’язку» мо-
же набувати двох значень. Обмеження задають в одиницях, які
вибирає проектувальник системи (наприклад, у хвилинах).

Питання для самоперевірки

1. Зовнiшнiй рiвень — основа iнфологiчного проектування.

2. Вимоги до iнфологiчної моделi.
3. Основнi термiни i визначення iнфологiчного моделю-
вання: атрибут, об’єкт, запитувальний зв’язок, структурний
зв’язок.
4. За якими ознаками виокремлюється кінцевий об’єкт при
побудові запитувального зв’язку?
5. Побудова запитувальних зв’язкiв та умови їх ка-
нонiчностi.
6. Правила побудови структурних зв’язкiв.
7. Дайте пояснення об’єкта «зв’язки» та його призначення.
8. У чому полягає процедура перевірки інфологічної моделі
на повність, коректність та адекватність?
9. Опис складових iнфологiчного моделювання.

53
 3 Pоздiл
ДАТАЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗ ДАНИХ

3.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чне проек-
тування з боку СКБД, є:
1. Тип логiчної моделi, що його пiдтримує вибрана СКБД. За-
раз найпоширенішими на ринку програмних засобiв i в практицi
автоматизацiї економiчних розрахункiв є реляцiйнi СКБД. Крiм
реляцiйних моделей, існують єрархiчнi та мережеві моделi баз
даних.
2. Особливостi фiзичної органiзацiї даних у середовищi вибра-
ної СКБД. Наприклад, у СКБД Paradox чи dBASE-системах база
даних органiзована у виглядi набору взаємозв’язаних файлiв фо-
рматів DT і DBF. Усi iншi об’єкти, такi як форми та звiти, також
зберiгаються в окремих файлах. У середовищi СКБД Microsoft
Access ус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в тощо).

53
 Усе ще не знайдено формалiзованих методiв, якi б давали змо-
гу однозначно виконати даталогiчне проектування. Тому його ре-
зультат багато в чому залежить вiд умiння та рiвня квалiфiкацiї
спецiалiстiв, якi здійснюють проектнi розробки.
У результатi даталогiчного проектування можна отримати
кiлька варiантiв побудови логiчної моделi даних. Тому важливим
моментом є оцiнка отриманих моделей і вибiр найоптимальнішо-
го варiанта.
Отриманий результат передусім потрібно оц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.2. Відображення на реляційну модель

Основним структурним елементом реляційної БД є дво-

вимірні плоскі таблиці, які називаються реляцiйними
вiдношеннями. Тому при вiдображеннi iнфологiчної моделi на ре-
ляцiйну iнформацiйнi об’єкти потрібно трансформувати в ре-
ляцiйнi вiдношення, врахувавши такий момент. Якщо мiж
об’єктами існує зв’язок 1 : 1 i клас членства пiдпорядкованого
об’єкта обов’язковий, та об’єкти семантично спорiдненi, то теоре-
тично можливо об’єднати їх в одне реляцiйне вiдношення. Таке
об’єднання зменшує обсяг пам’ятi для зберiгання вiдношення за
рахунок усунення дублювання ключових атрибутiв, а також може
прискорити пошук при реалiзацiї запитiв. Але цим засобом не слiд
зловживати, оскільки проектувальник не може на 100 % бути впе-
вненим, що кожний з цих об’єктiв не знадобиться окремо для ре-
алiзацiї якихось запитiв, якi з’являться у системi пiзнiше, що може
ускладнити їх реалiзацiю.
Власне кажучи, при вiдображеннi на реляцiйну модель пере-
проектовувати iнформацiйнi об’єкти, якщо не було припущено
помилок на етапi iнфологiчного проектування, практично не по-
трiбно. Тобто iнформацiйнi об’єкти iнфологiчної моделi представ-
ляються в табличному вигляді і стають реляцiйними
вiдношеннями. Необхiдно лише перевiрити виконання таких
умов:
54
 1. Усi атрибути вiдношень мають бути атомарними, тобто не-
подiльними.
2. В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сть її вимогам 3НФ (4НФ).

3.3. Відображення на єрархічну модель

Iсторично єрархiчнi та мережеві СКБД виникли десь

приблизно рокiв на десять ранiше від реляцiйних моделей. Зараз
на практицi дуже поширенi ПЕОМ, на яких в основному викори-
55
стовуються реляцiйнi СКБД. Єрархiчнi та мережеві СКБД зали-
шилися на великих і мiнi-ЕОМ.
Вiдображення на єрархiчну модель виконується в два етапи.
1. Загальне вiдображення на єрархiчну модель без урахування
обмежень єрархiчної СКБД.
2. Модифiкацiя моделi з урахуванням обмежень, якi накладає
вибрана єрархiчна СКБД.
Роботи першого етапу виконують згiдно з основними прави-
лами побудови єрархiчних моделей. Розглянемо цi правила.
Єрархiчнi моделi, збудовані на основi принципу
пiдпорядкованостi мiж iнформацiйними об’єктами, являють со-
бою деревоподiбну структуру, яка складається з вузлiв (сег-
ментiв) i дуг (гiлок). Кожний вузол — це сукупнiсть логiчно вза-
ємозв’язаних атрибут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 iєрархiї знаходиться лише один
сегмент, який називається кореневим. Кожний екземпляр цього
сегмента починає один логiчний запис. Тому пошук в iєрархiчних
моделях виконують згори донизу, зворотного шляху пошуку в
цих моделях немає.
Першим кроком вiдображення iнфологiчної моделi на
єрархiчну буде вибiр з-поміж iнформацiйних об’єктiв інфологіч-
ної моделі того об’єкта, який мiг би бути кореневим сегментом.
Ним може бути об’єкт, який не має зв’язкiв на входi з 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. Зв’язки в єрархiчних моделях будують за принципом
«вихiдний – породжений». Так, сегмент другого рiвня iєрархiї за-

56
лежатиме вiд сегмента першого рiвня, тобто перший рiвень ви-
ступає як вихiдний, а другий –– як породжений; у свою чергу,
другий є вихiдним, а третiй –– породженим вiдносно другого
рiвня i т. д. Тому другим кроком вiдображення на єрарх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. В єрархiчнiй моделi пiдтримуються лише такі типи
спiввiдношень мiж даними: 1 : 1 і 1 : Б. Тому потрiбно перевiрити
типи спiввiдношень мiж даними i обмежитися лише згаданими.
Далі буде розглянуто, як в єрархiчних моделях можна ре-
алiзувати iншi типи спiввiдношень.
4. Кожний вихiдний сегмент може мати кiлька породжених,
але породжений сегмент може мати щонайбільше два вихiдних,
один з яких є фiзично, а інший логiчно вихiдним. Зв’язки в однiй
фiзичнiй базi даних (ФБД) називаються фiзичними, а зв’язки мiж
двома ФБД –– логiчними. На рис. 3.1 зображено двi фiзичнi бази
даних ФБД-1 і ФБД-2, в яких сегмент Х є фiзично вихiдним для
сегмента Z, а Y — логiчно вихiдним для цього самого сегмента; в
цьому разі Z виступає вiдносно Y як логiчно породжений сегмент,
відносно Х –– як фiзично породжений.
За описаним правилом побудови зв’язків необхідно перевіри-
ти всі породжені сегменти на виконання даного обмеження. Над-
лишкові зв’язки потрібно усунути об’єднанням кількох об’єктів в
один, якщо це можливо, або простим абстрагуванням від деяких
зв’язків.
Другий етап вiдображення полягає в модифiкацiї отриманої
моделi з урахуванням обмежень вибраної єрархiчної СКБД.

X Y

N R

57
 ФБД-1 ФБД-2
Рис. 3.1. Взаємозв’язки між двома фізичними базами даних

Розглянемо єрархiчну СКБД ОКА, що використовується на

машинах типу ЄС ЕОМ, яка є прототипом захiдної СКБД IMS
(система була створена в рамках виконання проекту «Аполлон»
— висадка на Мiсяць). ОКА найбiльшою мiрою вiдображає тео-
ретичнi канони побудови єрархiчних СКБД. Вона накладає такi
обмеження на логiчну модель БД:
1. СКБД пiдтримує лише спiввiдношення типу 1 : 1 і 1 : Б.
2. Кiлькiсть атрибутiв у сегментi не повинна перевищувати
254.
3. Кiлькiсть рiвнів iєрархiї –– не бiльше 15.
4. На логiчно породженi сегменти накладається ряд обмежень:
 кореневий сегмент не може бути логiчно породженим, але
може бути логiчно вихiдним;
 логiчно породжений сегмент може мати лише один логiчно
вихiдний сегмент. Так, на рис. 3.2 з наведених зв’язкiв А і В може
iснувати лише А. Зв’язок L, при якому кореневий сегмент Х стає
логiчно породженим, взагалi не допускається;

L Y
X
A

Z B
N R

ФБД-1 ФБД-2
Рис. 3.2. Організація логічних зв’язків між фізичними базами даних

 логiчно породжений сегмент не може бути нi логiчно, нi

фiзично вихiдним для логiчно породженого сегмента, тобто два
сегменти однiєї ФБД, розміщенi на iєрархiчному шляху безпосе-
редньо один за одним, не можуть бути одночасно оголошеними
як логiчно породженi;
 логiчно вихiдний сегмент може мати один чи кiлька логiчно
породжених в однiй чи кiлькох ФБД;

58
  зв’язки мiж логiчно вихiдними i логiчно породженими сег-
ментами можуть бути одно- чи двостороннiми.
Вiдповiдно до цих вимог i обмежень має бути модифiкована
ієрархiчна БД, яка працюватиме в середовищi СКБД ОКА.
Як зазначалося, в єрархiчних моделях не можна пiдтримувати
багатозначнi зв’язки в явному виглядi. Тому, якщо потрібно ре-
алiзувати спiввiдношення подібного типу, використовують такий
штучний засiб як адресне посилання. Для цього необхiдно, щоб
сегменти, мiж якими необхiдно встановити зв’язок Б : Б, були
розміщенi в рiзних ФБД.
Якщо потрібно, наприклад, реалiзувати зв’язок мiж сегмента-
ми СПIВРОБIТНИК : ПРОЕКТ = Б : Б, який свідчить про те, що
один спiвробiтник може брати участь у виконаннi кiлькох про-
ектiв, а, в свою чергу, у виконаннi одного проекту бере участь ба-
гато спiвробiтникiв, застосовують штучнi сегменти Y1 та Y2 (рис.
3.3), якi вмiщують вiдповiднi фiзичнi адреси спiвробiтникiв і
проектiв.

Відділ Програма

Співробітник Проект

Y1 Y2

Рис. 3.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 оброблятимуться на цих

59
верстатах, за наявностi спiввiдношення «вихiдний — породже-
ний» мiж сегментами ДЕТАЛЬ : ВЕРСТАТ. Єдиний вихiд –– вне-
сти iнформацiю про якiсь фiктивнi деталi, але про це має
пам’ятати адмiнiстратор БД, i фiктивна iнформацiя повинна з пев-
ним часом бути замiнена на реальну. Тому процедури вилучення
чи поповнення єрархiчної БД необхiдно завжди виконувати дуже
ретельно та уважно, щоб не знищити важливих даних чи, навпа-
ки, не використати штучнi данi.

3.4. Відображення на мережеву модель

Мережева модель БД –– це орiєнтований граф з

поiменованими дугами i вершинами. Вiдображення iнфологiчної
моделi на мережеву є складним процесом, який має ряд альтерна-
тивних рiшень. Розглядаючи перехiд вiд iнфологiчної моделi до
мережевої, ми орiєнтуватимемося на моделi робочої групи за ба-
зами даних (РГБД) Асоцiацiї з мов систем обробки даних ––
CODASYL (Conference On Date Systems Languages), якi дістали
практичного розвитку. Згiдно з пропозицiями CODASYL у мере-
жевих моделях файли є рiвноправними, тобто можуть виступати в
рiзних зв’язках: в одному випадку — як власники, в iншому ––
як пiдпорядкованi файли.
Перш нiж перейти до процесу вiдображення, визначимо основ-
ні термiни та поняття, якими оперують у ході розробки мереже-
вих моделей.
Основними структурними елементами моделей цього типу є
агрегат, запис і набiр даних.
При вiдображеннi iнфологiчної моделi на мережеву
iнформацiйним об’єктам ставлять у вiдповiднiсть записи. Кож-
ний запис вміщує певну множину атрибутiв. Розрiзняють такi
поняття, як тип запису i екземпляр запису. Тип запису –– це абст-
рактнi характеристики, а екземпляр запису — їх конкретнi зна-
чення. Наприклад, тип запису: ПОСТАЧАЛЬНИК (код постача-
льника, назва постачальника, адреса постачальника, телефон),
екземпляром цього типу запису буде: 105, Вега ЛТД, Київ-147,
вул. Бойченка, 75, 552-33-98. Отже, кожному типу запису в БД
може вiдповiдати деяка сукупнiсть екземплярiв.
Усерединi запису можуть виокремлюватись агрегати. Агрегат —
це поiменована сукупнiсть логiчно взаємозв’язаних атрибутiв

60
усерединi типу запису: ними можуть бути вектори, групи i по-
вторюючі групи.
На рис. 3.4 зображено внутрiшню структуру, що може підтри-
муватись у мережевих моделях і в якiй агрегат «iноземна мова»
представлений як вектор, а агрегат «адреса» –– як група.
ОСОБА

Адреса
Табельний № ПІБ Посада Іноземна
мова
Індекс Місто Вулиця Квартира

Рис. 3.4. Структура запису, який вмiщує агрегати

Звертаючись до даних, можна звертатись як до запису в

цiлому, так i до окремих агрегатiв, що входять до їх складу. От-
же, запис –– це агрегат, який не входить до складу iнших агре-
гатiв i є основною одиницею обробки БД (записи за-
пам’ятовуються, вилучаються, поповнюються). Поняття «запису»
в мережевих моделях традицiйне.
У реальних СКБД є певні обмеження на використання такої
конструкцiї, як агрегат. Так, деякi СКБД дозволяють використо-
вувати повторюючі групи лише на першому рiвнi iєрархiї. З рис.
3.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д

61
власника набору до його члена, являє собою логiчний взаємо-
зв’язок «один до багатьох» мiж власником і членом набору да-
них. Необхiдно розрiзняти такi поняття, як тип набору та екземп-
ляр набору. Наприклад:

ПОСТАЧАЛЬНИК ЗАМОВЛЕННЯ МАТЕРІАЛ

Тип набору ЗАМОВЛЕННЯ може характеризуватись екземп-

ляром типу запису-власника ПОСТАЧАЛЬНИК i деякою множи-
ною екземплярiв типу запису МАТЕРIАЛ. Отже, кожний екземп-
ляр набору складається з одного екземпляра типу запису-
власника i кiлькох екземплярiв типу записiв-членiв. Набiр вважа-
ється порожнім, якщо жоден екземпляр запису-члена не
зв’язаний з вiдповiдним екземпляром запису-власника. Таким
чином, набір може складатися лише iз запису-власника.
Певний екземпляр типу запису-члена в екземплярi даного типу
набору не може одночасно належати бiльше ніж одному екземпля-
ру типу запису-власника. Iнакше кажучи, власник типу набору має
бути обов’язково унiкальним.
В єрархiчнiй моделi для кожного породженого сегмента може
iснувати лише один фiзично вихiдний сегмент. У структурах
CODASYL в одному наборi тип запису може мати лише одного
власника, але враховуючи те, що тип запису може входити до різ-
них наборів, вiн може мати довiльне число власникiв. Записи-
власники можуть брати участь у кiлькох наборах, а записи-члени
можуть виступати як власники в iнших наборах. Кожний тип на-
бору iдентифiкується унiкальним iменем.
Існує кiлька типiв наборiв: набори першого та другого класу i
сингулярнi набори.
Набiр першого класу об’єднує два типи запису (рис. 3.5).

КЛІЄНТ Власник набору

КЛІЄНТСЬКИЙ РАХУНОК

РАХУНОК Член набору

Рис. 3.5. Набір першого класу

Набір другого класу –– це багаточленні чи групові набори, які
складаються з кількох типів записів (рис. 3.6).

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

СКБД

МАРШРУТ

ВЕРСТАТ

Рис. 3.6. Набір другого класу

ДЕТАЛЬ

ТЕХНОЛОГІЯ НОРМА

ОПЕРАЦІЯ МАТЕРІАЛ

Рис. 3.7. Сингулярний набір

Вiдображення iнфологiчної моделi на мережеву модель вико-

нують так само, як i вiдображення на єрархiчну, тобто в два ета-
пи: спочатку будують загальну мережеву модель, а потiм її мо-
дифiкують з урахуванням обмежень і особливостей конкретної
СКБД.
Вiдображення iнфологiчної моделi на мережеву починається з
аналiзу структурних зв’язкiв iнфологiчної моделi.
Перетворення 1. У мережевій моделі можна залишати лише
зв’язки типу ВП, а зв’язки ПВ і ВПВ повинні бути перетворені.
Це можливо об’єднанням об’єктів в один. При об’єднанні влас-
ника і підпорядкованого об’єкта створюється новий тип запису, в
якому підпорядкований об’єкт виступає як агрегат типу запису-
власника. Отже, зв’язок ПВ ліквідується, а зв’язок ВПВ перетво-
63
рюється на ВП. Це перетворення через злиття двох об’єктів в
один можливе тоді, коли підпорядкований об’єкт не бере участі в
інших наборах.
Перетворення 2. Згідно з правилами побудови мережевих мо-
делей кожний набір не може мати більше ніж одного власника в
одному й тому самому наборі. Тому наступним кроком відобра-
ження є усунення багатозначного володіння. Усі зв’язки типу
«багато до багатьох» (Б : Б) не можуть бути реалізовані в явному
вигляді. Їх моделюють так, як показано на рис. 3.8.

ДЕТАЛЬ

ОПЕРАЦІЯ МАРШРУТ

ВЕРСТАТ

Рис. 3.8. Реалізація зв’язку Б : Б двома зв’язками 1 : Б

На рис. 3.8 показано, як за допомогою двох зв’язкiв 1 : Б ре-

алiзовано взаємозв’язок Б : Б. Реалiзувати це однiєю дугою не-
можливо, оскільки одну й ту саму операцiю обробки можуть
проходити рiзнi деталi, а це призводить до порушення правила
унiкальностi володiння, бо одна й та сама деталь має стати чле-
ном одночасно двох чи бiльше екземплярiв одного набору. Тому
можна ввести два набори: МАРШРУТ вiдображатиме зв’язок
ДЕТАЛЬ — ВЕРСТАТ i вказуватиме, на яких верстатах пройшла
обробку та чи iнша деталь: ОПЕРАЦIЯ вказуватиме, якi деталi
проходять обробку на кожному верстаті.
У наборi даних ОПЕРАЦIЯ — тип запису ВЕРСТАТ — ви-
ступає власником, а ДЕТАЛЬ –– членом набору, а в наборi МАР-
ШРУТ, навпаки, ВЕРСТАТ — член, а ДЕТАЛЬ –– власник набору.
Перетворення 3. Більшість мережевих СКБД не підтримують
циклів. Тому необхідно проаналізувати інфологічну модель на
присутність у ній циклів та усунути їх, увівши адресні посилання
(вказівки).
Наприклад, зображений на рис. 3.9 фрагмент структури вмі-
щує цикл, який буде усунено введенням до типу запису С адрес-
ного посилання на тип запису А.

64
 А А

В В

С С
Посилання
на А

Рис. 3.9. Усунення циклу за допомогою адресних посилань

Зауваження. Якщо при даталогiчному проектуваннi спочатку

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

Раніше було розглянуто загальнi процедури в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.10).

А В А В С А В

С Вказівка D CD
на С

а) перший варіант б) другий варіант

перетворення перетворення

65
 Рис. 3.10. Зведення до дворівневих структур

Перший варiант перетворення полягає в перенесеннi всiх

промiжних рiвнів на перший рiвень iєрархiї (рис. 3.10 а).
Другий варiант перетворення полягає у використаннi кодова-
них записiв. На рис. 3.10 б екземпляр запису CD –– це запис типу
C чи запис типу D. Для того щоб вiдрiзнити запис типу C вiд за-
пису типу D, до складу таких записiв уводять додаткове поле, яке
є кодом, що вказує на тип запису. Тому цi записи називаються
кодованими. Вибираючи варiант перетворення, необхiдно врахо-
вувати характеристику, яка визначає ступiнь змiнностi об’єкта.
Якщо об’єкт характеризується високим ступенем змiнностi, то
його краще перетворювати на залежний запис.

3.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в. Вибираючи СКБД треба пе-
редусім орієнтуватись на серверні СКБД. Епоха настільних сис-
тем уже закінчилася і діючі інформаційні системи, які були оріє-
нтовані на технологію «файл-сервер» зараз в переважній біль-
шості установ та фірм модернізуються і переводяться на серверні
СКБД, що забезпечують технологію «клієнт-сервер».
Охарактеризуємо основні фактори, що впливають на вибір
СКБД.
Операційне середовище. Переважна більшість систем має кі-
лька версій, можуть працювати в різному операційному середо-
вищі (UNIX-Solaris, Windows NT Server, Windows 2000 чи Linux).
Винятком є лише Microsoft SQL Server, яка працює лише на од-
ній платформі Windows.

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

67
  наявність засобів автоматизованого відновлення й захисту
інформації (криптографування, шифрування даних тощо);
 резервне копіювання даних і журналів трансакцій;
 обслуговування реплікацій, тобто гарантоване копіювання
змін з одної БД в інші і синхронізація даних. Цей фактор важли-
вий для територіально розгалужених організацій, орієнтованих
на децентралізовану обробку даних з використанням декількох
серверів;
 забезпечення паралельної обробки даних. Сервери, які під-
тримують паралельну обробку даних, дозволяють кільком проце-
сорам звертатися до однієї БД, що забезпечує високу швидкість
обробки трансакцій.
3. Засоби підтримки прикладного програмного забезпечення.
До цих параметрiв належать:
 підтримка OLAP-технологій. Деякі фірми виробники серве-
рних СКБД пропонують окремі OLAP-сервери (ORACLE,
Informix) чи включають їх до складу реляційних баз даних
(Microsoft SQL Server 7.0), або ж надають можливість будувати
багатовимірні сховища на базі даних інших СКБД (Microsoft SQL
Server Extensional, Sybase Adaptive Server IQ). На цей фактор слід
звертати увагу в тому випадку, якщо в подальшому планується
створення сховища даних і систем підтримки прийняття рішень;
 підтримка розподілених запитів і трансакцій. Цей фактор
враховується в тому випадку, якщо планується наявність кількох
серверів БД;
 наявн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 засоби). Дiю цього ме-
ханiзму можна пояснити так. На початку виконання запиту роб-
лять копiї («фотографiї») всіх файлiв, якi беруть участь в його ре-
алiзацiї. Таким чином можна виконувати запити будь-якої
складностi, оскільки всi коректури, внесенi iншими користувачами

68
в файли БД протягом виконання запиту, не впливають на його ре-
зультат;
 наявнiсть механiзму встановлення замкiв чи виконання захоп-
лень при паралельному внесеннi змiн у файли БД. Замок чи захоп-
лення встановлюється на файл БД на перiод внесення змiн одним
користувачем. Замок захищає лише вiд паралельного внесення змiн;
файл доступний для проведення всіх iнших операцiй;
 механiзм стеження за часом виконання трансакцiй. Цей ме-
ханiзм необхiдний для попередження зависання системи при ко-
лективному використаннi даних. Якщо лiмiт допустимого часу
для виконання трансакцiї вичерпано, то її вiдмiнюють, i БД пове-
ртається в початковий стан;
 підтримка WEB-технологій.
Вартість системи. Вартість системи залежить від фірми ви-
робника і виду СКБД та кількості її інсталяцій. Вартість повно-
функціональної СКБД коливається у межах 500—1000 у.о., вар-
тість сервера — від кількох сот до п’ятисот тисяч у.о.

Питання для самоперевiрки

1. Цiлi та задачi даталогiчного проектування.

2. У чому полягають особливості даталогічного проекту-
вання?
3. Який аналіз виконується при пошуку в інфологічній мо-
делі об’єкта, який буде кореневим в ієрархічній моделі?
4. Етапи процесу відображення інфологічної моделі на єрар-
хічну.
5. Які особливості мережевої моделі слід ураховувати при
відображенні інфологічної моделі на мережеву?
8. Що представляє собою схема реляційної моделі даних?
9. Які процедури повинні виконуватися при відображенні
інфологічної моделі на реляційну?
10. Які фактори впливають на вибір СКБД?

69
 4 Pоздiл
ПРОЕКТУВАННЯ БАЗ ДАНИХ НА ОСНОВІ
НОРМАЛІЗАЦІЇ

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

нормалізації

Iнодi на практицi не виконується етап iнфологiчного

проектування. Це спостерігається в тих випадках, коли бажають
прискорити процес проектування i впровадження системи в екс-
плуатацiю або коли вже iснують локальнi файловi структури, якi
треба органiзувати у виглядi БД, що перебуватиме пiд
управлiнням СКБД. У такому разi доцільно використовувати
пiдхід до проектування БД, заснований на нормалізації незалеж-
но вiд того, яку СКБД буде вибрано — реляцiйного чи iншого
типу.
Скориставшись підходом, що ґрунтується на нормалізації,
або реляцiйному підході, можна спроектувати оптимальну логіч-
ну модель БД. Остання не має аномалій, пов’язаних з модифі-
кацією БД, тобто проблем, що можуть виникнути внаслідок за-
мін, вставок і вилучення даних з БД. Під аномаліями розуміють
відхилення від норм, які можуть призвести до порушення посил-
кової цілісності БД чи виникнення суперечності і неузгоджено-
сті даних.
Концепцію реляційної моделі запропонував американський
учений Е. Ф. Кодд у 1970 р. Виникнення її пов’язане з
розв’язанням проблеми забезпечення незалежності даних та їх
опису від прикладних програм. Створена Коддом теорія норма-
лізації вiдношень виявилася, по сутi, єдиною формалiзованою
теорiєю, за допомогою якої можна спроектувати оптимальну
логiчну модель даних. Цю теорiю можна використовувати не
лише при проектуваннi баз даних у середовищi реляцiйних
СКБД, а й для СКБД, якi пiдтримують iншi моделi даних. Отож,
будь-яку логiчну модель спочатку проектують як нормалiзовану
реляцiйну модель, а потiм вiдображають на ту модель, яку
пiдтримує вибрана СКБД.
В основу реляцiйних моделей покладено поняття
«вiдношення», яке є засобом структуризацiї даних. Вiдношення

70
має вигляд поiменованої двовимiрної плоскої таблицi. Рядки та-
кої таблицi називаються кортежами, а сукупнiсть атрибутiв пев-
ного стовпця — доменом. Схема вiдношення задається iм’ям
вiдношення та iменами вiдповiдних доменiв.
Реляцiйна БД — це набiр взаємозв’язаних вiдношень, які мо-
жна подiлити на два класи: об’єктнi і зв’язковi. Об’єктнi
вiдношення зберiгають данi про iнформацiйнi об’єкти предметної
областi. Наприклад: ДЕТАЛЬ (код деталi, назва деталi, маса де-
талi, собiвартiсть) –– об’єктне вiдношення.
В об’єктному вiдношеннi один з атрибутiв однозначно
iдентифiкує окрему сутнiсть предметної областi. Такий атри-
бут називається первинним ключем вiдношення. У наведеному
вiдношеннi роль ключевого атрибута відіграє атрибут «код де-
талi».
Ключ може вміщувати кiлька атрибутiв, тобто бути складо-
вим. В об’єктному вiдношеннi не повинно бути рядкiв з одна-
ковим первинним ключем, тобто не допускається дублювання
об’єктiв. Це основне обмеження реляцiйної моделi, яке нео-
бхiдно виконувати для забезпечення цiлісностi даних.
Зв’язкове вiдношення зберiгає первинні ключi двох або бiльше
об’єктних вiдношень, за якими встановлюються зв’язки мiж
ними.
Наприклад, розглянемо ще одне об’єктне вiдношення:
ВЕРСТАТ (код верстата, фiрма-виробник, дата введення в екс-
плуатацiю, балансова вартiсть). Тодi вiдношення ТЕХНОЛОГIЯ
(код деталi, код верстата) буде зв’язковим мiж двома об’єктними
вiдношеннями ДЕТАЛЬ i ВЕРСТАТ.
У зв’язковому вiдношеннi можуть дублюватися ключовi ат-
рибути. Крiм ключiв, за якими встановлюється зв’язок у
зв’язковому вiдношеннi, можуть бути ще й iншi атрибути, якi
функцiонально залежать вiд цього зв’язку та розширюють його
семантику. Наприклад, ТЕХНОЛОГIЯ (код верстата, код де-
талi, код технологiчної операцiї, норма часу обробки деталi на
верстаті). Ключi в зв’язкових вiдношеннях називаються
зовнiшнiми, або вторинними, оскільки вони пов’язанi з первин-
ними ключами iнших вiдношень. Реляцiйна модель накладає на
зовнiшнi ключi обмеження для забезпечення цiлісностi даних,
яке називається посилковою цiлiснiстю. Це означає, що кожному
зовнiшньому ключу має вiдповiдати рядок якогось об’єктного
вiдношення. Без такого обмеження може статися, що зовнiшнiй
ключ посилається на об’єкт, про який нiчого невiдомо.

71
 У реляцiйнiй БД накладається ще одне обмеження —
вiдношення мають бути нормалiзованi.

4.2. Аномалії ненормалізованого відношення

Структура реляцiйних вiдношень у нормалiзованiй базi

даних має бути оптимальною, тобто такою, яка є найбiльш
ст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на керiвника вiддiлу призведе
до необхiдності внесення змiн і модифiкацiй по кожному
працiвнику даного вiддiлу. Отже, для пiдтримки узгодженостi
даних необхiдно виконати змiну не лише в одному кортежі ба-
зи, а цілий ряд змiн, що може розглядатись як аномалiя, оскіль-
ки характер самої змiни повинен стосуватися лише одного пев-
ного запису БД.
2. Аномал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я.
4. Надлишковiсть. Вiдомостi про керiвника вiддiлу та тип
контракту повторюються в рядi кортежiв БД. Основнi проблеми
зi зберіганням надлишку iнформацiї пов’язанi не лише з неефек-
тивним використанням пам’ятi, а й із забезпеченням пiдтримки
узгодженостi цих даних.

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

4.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 форми (скорочена на-
зва — 1НФ, 2НФ i 3НФ). Найбільш досконала з них –– 3НФ. За-
раз вже вiдомi й визначенi 4НФ, 5НФ.
Нормалiзацію вiдношеннь виконують у кiлька крокiв.

4.3.1. Перша нормальна форма

Перша iтерацiя (перший крок) — зведення вiдношень

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

73
  усi атрибути вiдношення повинні бути унiкальними, тобто
не допускається їх дублювання, а також атомарними, тобто не-
подiльними;
 усi рядки таблицi повиннi мати однакову структуру, тобто
одну й ту саму кiлькiсть атрибутiв з iменами, що збігаються;
 iмена стовпцiв мають бути рiзними, а значення однорідними
(однакового формату);
 порядок рядкiв у таблицi не суттєвий.
Розглянемо приклад зведення вiдношення до 1НФ: МАТЕРIАЛ
(код матерiалу, назва матеріалу, одиниця вимiрювання, характе-
ристика: тип, сорт, розмiр). У цьому вiдношеннi атрибут «Харак-
теристика» є неатомарним, тому потрiбно позбутися складового
атрибута і перетворити його на три атомарних атрибути. В ре-
зультатi зведення до 1НФ вiдношення набере вигляду: МАТЕРІАЛ
(код матеріалу, назва матеріалу, одиниця вимірювання, тип, сорт,
розмір).
При приведенні до 1НФ необхідно визначити первинні ключі
відношення. Первинним ключем відношення МАТЕРІАЛ буде
атрибут «код матеріалу».

4.3.2. Друга нормальна форма

Кожне вiдношення БД ум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. Атрибут B залежить вiд А у вiдношеннi R тодi,
коли в кожний момент одному й тому самому значенню А
вiдповiдає не бiльше, ніж одне значення B.
Графiчно функцiональна залежнiсть вiдображається так: А
B. Цiй залежностi вiдповiдає спiввiдношення 1 : 1 мiж ат-
рибутами (наприклад, як мiж атрибутами код деталi назва
деталi, код верстата назва верстата).

74
 Детермінантом функцiональної залежності називають атри-
бут чи їх групу, які розташовані на діаграмі функціональної за-
лежності зліва від символа стрілки.
Коли вiдношення має складовi ключi, то залежнiсть неключо-
вих атрибутiв вiд такого ключа може бути повною або частко-
вою. Якщо маємо вiдношення R (A*, В*, C, D), ключ якого скла-
дається з двох атрибутiв A i B, тобто є складовим (знаком (*)
позначено ключовi атрибути), то функцiональнi залежностi в та-
кому вiдношеннi можуть мати такий вигляд:
R

A*

B*

Атрибут C перебуває в повнiй функцiональнiй залежностi,

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

Зауваження. Якщо відношення містить простий ключ, то відно-

! шення автоматично перебуває в 2НФ, тобто процедура приведення
до 2НФ виконується лише для відношень, що мають складові клю-
чі. Якщо вiдношення має неповнi функцiональні залежностi, то
виконують його декомпозицiю на два чи бiльше вiдношень, якi не
мають неповних функцiональних залежностей i з’єднання яких
дасть початкове вiдношення.

Виконавши декомпозицiю вiдношення R, отримаємо замiсть

одного два вiдношення, якi перебуватимуть в 2НФ:

75
 R1 R2
A* B*
B* D
C

Отже, в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
перебувають у 2НФ.
Переваги 2НФ: зручнiсть внесення змiн у БД. Трудомісткiсть
внесення змiн у БД, яка перебуває в 2НФ, значно менша, ніж у
ненормалiзовану БД. Так, при змiнi цiни якогось матерiалу нео-
бхiдно знайти лише вiдповiдний матерiал у вiдношеннi МА-
ТЕРIАЛ i замiнити лише один атрибут «цiна матерiалу». Якщо ж
БД ненормалiзована, потрiбно знайти всi деталi, на якi витрача-
ється даний матерiал, i виконати вiдповiднi в усiх знайдених за-

76
писах змiни. При цьому якщо буде пропущено хоча б одну де-
таль, то це призведе до суперечностей у даних.
2НФ повнiстю усуває можливiсть виникнення протирiччя да-
них, а також економить пам’ять при зберіганнi вiдношень у
пам’ятi ЕОМ. Наприклад, у разі зберігання в базi даних ненор-
малiзованого вiдношення НОРМА iнформацiя про один i той са-
мий матерiал буде дублюватись у БД стiльки разів, на скiльки
рiзних деталей вiн витрачається. Отже, буде значне надмірне ду-
блювання даних i великi перевитрати пам’ятi.

4.3.3. Третя нормальна форма

Відношенням у 2НФ меншою мірою, ніж відношенням

в 1НФ, властива надлишковість даних, проте деякі з них можуть
характеризуватися аномаліями оновлення. Аномалія оновлення
спричиняється наявністю залежностей між неключовими атрибу-
тами відношення.
Вiдношення в 2НФ потрібно аналiзувати на присутнiсть тран-
зитивних залежностей. Якщо таких немає, відношення у 2 НФ
автоматично є відношенням у 3НФ.
Третiй крок нормалiзацiї — вилучення транзитивних залежно-
стей. Тобто залежностей мiж неключовими атрибутами.
Означення 3. Атрибути називаються взаємно незалежними,
якщо жоден з них не є функціонально залежним від іншого.
Означення 4. Відношення R перебуває в третій нормальній
формі (3НФ) тоді і тільки тоді, коли відношення знаходить-
ся в 2НФ і всі неключові атрибути взаємно незалежні.

Нехай є вiдношення R(A*, C, D), в якому атрибут D безпосе-

редньо не залежить вiд ключового атрибута A, а залежить вiд не-
ключового атрибута C, який залежить вiд A. Тодi атрибут D тран-
зитивно залежить вiд A (транзитивна залежність на діаграмі
відображена пунктирною дугою).

R
A*
C
D

77
 Транзитивні залежності також вилучають за допомогою деком-
позицiї вiдношення на два чи бiльше iнших вiдношень, якi не мі-
стять транзитивних залежностей i з’єднання яких дасть початко-
ве вiдношення. В результаті декомпозиції відношення R
отримаємо два відношення R1 і R2.
R1
A*
C
R2
C*
D

Вiдношення перебуває в 3НФ, якщо воно перебуває в 2НФ i

кожний неключовий атрибут нетранзитивно залежить вiд пер-
винного ключа.
Наприклад, вiдношення ВИКЛАДАЧ (табельний №, прiзвище,
посада, оклад, кафедра, телефон) перебуває в 2НФ, але вмiщує
транзитивну залежнiсть:
Табельний №*
Прізвище
Посада
Кафедра
Телефон

У результатi зведення до 3НФ отримуємо два в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дношення перебуває в 3НФ, якщо змiна значення
будь-якого його атрибута (крiм тих, що входять до первинного
ключа) не призведе до необхiдностi змiни iнших атрибутів.

78
 4.4. Нормальні форми більш високих порядків

У попередньому параграфу були розглянуті нормальні

форми до третьої нормальної форми (3НФ). У більшості випадків
цього цілком досить, щоб розробляти повністю працездатні бази
даних. У даному параграфі розглядаються нормальні форми більш
високих порядків, а саме: нормальна форма Бойса—Кодда (НФБК),
четверта нормальна форма (4НФ) і п’ята нормальна форма (5НФ).

4.4.1. Нормальна форма Бойса—Кодда

Нормальна форма Бойса—Кодда, або ж підсилена 3НФ,

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

Інакше кажучи, всі стрілки на діаграмі функціональної залеж-

ності у відношенні, що знаходиться у НФБК, можуть починатись
лише з потенційних ключів і відповідно жодну з них не можна ви-
ключити за допомогою процедури декомпозиції. Розглянемо при-
клад відношення ЗВІТ_АУДИТ, в якому виокремимо всі можливі
функціональні залежності і відповідно з’ясуємо наявність усіх мо-
жливих детермінантів. Цей звіт формується на основі звіту адміні-
стратора фірми, який замовляв співробітникам автомобілі.
ЗВІТ__АУДИТУ

№ Дата Час Коментар Таб. ПІБ № автомо-

звіту № співробітника біля
ЗА4 18.03.02 10.00 У міністерство 37 Крамар І. А. КВ23-39
ЗА4 22.03.02 9.00 У банк 14 Друзь А. Р. КО53-39

79
 ЗА4 01.03.02 9.30 У банк 14 Друзь А. Р. ПО72-81
ЗА16 22.03.02 13.00 У податкову 14 Друзь А. Р. КО53-39
ЗА16 24.03.02 9.00 У міністерство 37 Крамар І. А. ПО72-81

Функціональні залежності відношення ЗВІТ_АУДИТУ показані

нижче:
№ звіту, Дата Час, Коментар, Таб. №, ПІБ, № автомобіля (1)
Таб. №, Дата № автомобіля (2)
№ автомобіля, Дата, Час № звіту, Коментар, Таб. № (3)
Таб. №, Дата, Час № звіту, Коментар (4)

З перелічених вище функціональних залежностей у залежності

(2) сукупність атрибутів (Таб. №, Дата) не є потенційними клю-
чами, внаслідок чого відношення ЗВІТ_АУДИТУ матиме аномалії
при виконанні операції оновлення. Наприклад, при заміні автомо-
біля, який замовлено для співробітника з табельним номером 14 на
22.03.02, потрібно буде внести зміни відразу в два рядки. Якщо ж
зміна буде виконана лише в одному рядку, це призведе до проти-
річчя даних.
Для приведення відношення ЗВІТ_АУДИТУ до НФБК необ-
хідно провести декомпозицію на два наступних відношення:
ЗАМОВЛЕНІ_АВТОМОБІЛІ

Таб. № Дата Номер автомобіля

14 22.03.02 КО53-39
14 31.03.02 ПО72-81
37 01.03.02 КВ23-39
37 11.03.02 ПО72-81

ЗВІТ

№ звіту Дата Час Коментар Таб. №

ЗА4 18.03.02 10.00 У міністерство 37

ЗА4 22.03.02 9.00 У банк 14
ЗА4 01.03.02 9.30 У банк 14

80
 ЗА16 22.03.02 13.00 У податкову 14
ЗА16 24.03.02 9.00 У міністерство 37

Відношення ЗАМОВЛЕНІ_АВТОМОБІЛІ і ЗВІТ знаходяться у

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

Місто*
Адреса
Індекс
Зведення вiдношення до 3НФ дасть два вiдношення: R1
(мiсто, адреса), R2 (адреса, iндекс). Вони перебувають у 3НФ,
але не є вiдношеннями в НФБК, оскільки у вiдношеннi R існує
залежнiсть iндекс мiсто, тобто вiдношення в 3НФ не завжди
є вiдношенням у НФБК. Якщо ми зведемо це вiдношення до
НФБК, то отримаємо вiдношення R1 (мiсто, адреса), R2 (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дношення в 3НФ є вiдношенням у НФБК.
Нормальна форма Бойса-Кодда має такi самі переваги, що й
3НФ, але її виконання потребує особливої уваги з погляду її зво-
ротності.

81
 4.4.2. Четверта нормальна форма

На четвертому кроцi нормалiзацiї проводиться аналiз

на присутнiсть у вiдношеннi багатозначних залежностей. На-
явність у відношенні таких залежностей може привести до
проблем надлишковості даних та аномалій при внесенні змін
до бази даних. Багатозначна залежнiсть є рiзновидом
функцiональної залежностi, їй вiдповiдає спiввiдношення 1 : Б
мiж атрибутами. Атрибут A багатозначно визначає атрибут B у
вiдношеннi R (A, B, C), якщо B залежить лише вiд A за будь-
яких його комбiнацiй з iншими атрибутами вiдношення R.
Графiчно це позначають так:
A B.
Для нормалізації відношення, що містить багатозначні залеж-
ності, необхідно розділити всі незалежні групи атрибутів, що по-
вторюються.
Якщо у вiдношеннi присутнi А B i A C, то
вiдношення потрібно розкласти на два iнших вiдношення: R1 (A,
B) i R2 (A, C).
Розглянемо приклад. Нехай задано вiдношення СПIВРОБIТ-
НИК (табельний номер, державна нагорода, прiзвище, iм’я та по
батьковi члена сiм’ї, код родинних вiдносин).
У цьому вiдношеннi виконуються багатозначнi залежностi:
табельний номер державна нагорода,
табельний номер прiзвище, iм’я та по батьковi члена
сiм’ї.
Для того щоб виключити надлишкове дублювання, початкове
вiдношення необхiдно розкласти на два вiдношення: ВИНАГО-
РОДИ (табельний номер, державна нагорода), СIМ’Я (табельний
номер, iм’я та по батьковi члена сiм’ї, код родинних вiдносин).
Поняття багатозначної залежностi складнiше, ніж поняття
функцiональної залежностi. Для виявлення багатозначної залеж-
ності потрiбен значно глибший семантичний аналiз атрибутiв.
Iснують поняття тривiальної i нетривiальної багатозначних зале-
жностей. Залежнiсть типів X YiY X є тривiальною,
а залежнiсть типів X YiY X нетривiальною. При-
сутнiсть нетривiальних багатозначних залежностей у схемi
вiдношення i незалежність їх лiвих частин призводять до
комбiнаторики правих частин вiдношення.
Означення. Вiдношення R перебуває в 4НФ, якщо в струк-
турi багатозначної залежностi, визначеної на множинi ат-

82
 рибутiв, є лише тривiальнi чи/або такi нетривiальнi багато-
значнi залежностi, що лiва частина будь-якої з них з клю-
чем.

Отже, зводячи до 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сть.
Вiдношення, яке вмiщує понад три багатозначні залежності,
потребує спецiальних прийомiв для забезпечення процесу зворо-
тностi декомпозицiї. Для цього iснує 5НФ.

4.4.3. П’ята нормальна форма

У відношенні, що має кілька багатозначних залежнос-

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

X Y Z

83
 1 1 2
1 2 1
2 1 1
1 1 1

Відношення R

Варіанти проекції відношення R мають вигляд:

X Y

1 1

1 2

2 1

Проекція R1 = R [X, Y]

X Z
1 2
1 1
2 1

Проекція R2 = R [X, Z]

Y Z
1 2
2 1
1 1

Проекція R3 = R [Y, Z]
Легко помітити, що відношення R не відновлюється по жод-
ному з попарних з’єднань відношень, отриманих у результаті
декомпозиції, тобто виконання операцій R1 JOIN R2, R1 JOIN R3
або R2 JOIN R3 не дає початкове відношення.
Дійсно, з’єднання R1 JOIN R2 має вигляд:

84
 X Y Z
1 1 2
1 1 1
1 2 2
1 2 1
2 1 1

Курсивом виділено зайвий кортеж, відсутній у відношенні R.

Аналогічно й інші попарні з’єднання не відновлюють відношен-
ня R.
Однак відношення R відновлюється операцією з’єднання всіх
трьох проекцій:
R1 JOIN R2 JOIN R3 = R.
Це говорить про те, що між атрибутами цього відношення та-
кож є певна залежність, але ця залежність не є ні функціональною,
ні багатозначною. Ця залежність має назву залежність з’єднання,
яка є узагальненням поняття багатозначної залежності. Таким чи-
ном, багатозначна залежність є окремим випадком залежності
з’єднання, тобто якщо у відношенні є багатозначна залежність, то
є і залежність з’єднання. Зворотнє, звичайно, невірно.
Означення. Залежність з’єднання називається нетривіальною
залежністю з’єднання, якщо для відношення R (A, B, Z) ви-
конується дві умови:
 одна з множин атрибутів A, B, …, Z не містить потенційного клю-
ча відношення R;
 жодна з множин атрибутів не збігається з усією безліччю атрибу-
тів відношення R.
Означення. Залежність з’єднання називається тривіальною
залежністю з’єднання, якщо для відношення R (A, B, Z) ви-
конується одна з умов:
 або всі множини атрибутів A, B, …, Z містять потенційний ключ
відношення R;
 або одна з множин атрибутів збігається з усією безліччю атрибу-
тів відношення R.
Означення. Відношення R перебуває в п’ятій нормальній
формі (5НФ) тоді і тільки тоді, коли будь-яка залежність
з’єднання є тривіальною.

85
 Визначення 5НФ може стати зрозумілішим, якщо сформулю-
вати його в негативній формі.
Означення. Відношення R не знаходиться в 5НФ, якщо у
відношенні знайдеться нетривіальна залежність з’єднання.
Тому п’ята нормальна форма (5НФ) ще називається проекцій-
но-з’єднувальною формою (ПЗНФ), або такою, що не має залеж-
ностей з’єднання.
Розглянемо конкретний приклад, проаналізувавши відношен-
ня УКОМПЛЕКТУВАННЯ МЕБЛЯМИ.
УКОМПЛЕКТУВАННЯ МЕБЛЯМИ

Код приміщення Назва меблів Код постачальника

R4 Ліжко P1
R4 Стілець P2
R16 Ліжко P2
R16 Стіл P1
R36 Стілець Р3

Це відношення містить залежність з’єднання, оскільки має не-

тривіальну залежність з’єднання, бо атрибут «назва меблів» не є
потенційним ключем відношення. Тобто декомпозиція цього
відношення лише на два відношення призведе до аномалії ви-
никнення фіктивних рядків при виконанні зворотної операції
з’єднання. Тобто відношення УКОМПЛЕКТУВАННЯ МЕБЛЯ-
МИ для вилучення нетривіальної залежності з’єднання необхідно
розкласти на три відношення: ПРИМІЩЕННЯ_МЕБЛІ, ПОСТА-
ЧАЛЬНИК_МЕБЛІ, ПРИМІЩЕННЯ_ПОСТАЧАЛЬНИК, які пе-
ребуватимуть у 5НФ.
ПРИМІЩЕННЯ_МЕБЛІ

Код приміщення Назва меблів

R4 Ліжко
R4 Стілець
R16 Ліжко
R16 Стіл

86
 R36 Стілець

ПОСТАЧАЛЬНИК_МЕБЛІВ

Код постачальника Назва меблів

P1 Ліжко
P2 Стілець
P2 Ліжко
P1 Стіл
P3 Стілець

ПРИМІЩЕННЯ_ПОСТАЧАЛЬНИК

Код приміщення Код постачальника

R4 P1
R4 P2
R16 P2
R16 P1
R36 P3

Таким чином, можна стверджувати, що відношення перебуває

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

Питання для самоперевірки

1. Дайте визначення реляційного відношення та охаракте-

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

87
5. Дайте визначення неповної функціональної залежності.
6. Що таке транзитивна залежність?
7. Дайте визначення багатозначної залежності.
8. У чому полягає суть зведення реляційного відношення до
1НФ?
9. У чому полягає суть зведення реляційного відношення до
2НФ?
10. У чому полягає суть зведення реляційного відношення
до 3НФ?
11. У чому полягає суть зведення реляційного відношення
до НФБК?
12. У чому полягає суть зведення реляційного відношення
до 4НФ?
13. У чому полягає суть зведення реляційного відношення
до 5НФ?
14. У чому полягає суть зведення реляційного відношення
до НФБК?
15. У чому полягає декомпозиції без втрат?
16. Переваги нормалізованої бази даних.

88
 5 Pоздiл
АВТОМАТИЗАЦІЯ ПРОЕКТУВАННЯ БАЗ ДА-
НИХ

5.1. Загальна характеристика CASE-засобів

На сучасному етапі при розробці інформаційних сис-

тем широко застосовуються CASE-системи. Вони використову-
ються не тільки як комплексні технологічні засоби для розробки
програмних продуктів, але й як ефективний інструмент вирішення
дослідницьких і проектних задач, пов’язаних з початковими ета-
пами розробки інформаційних систем, таких як аналіз предметної
області, розробка проектних специфікацій, випуск проектної до-
кументації, планування і контроль розробок, моделювання при-
кладного програмного забезпечення. Тому термін CASE (Computer
Aided Software Engineering), який дослівно перекладається як
розробка програмного забезпечення за допомогою комп’ютера,
на сьогодні дістав ширше трактування і означає автоматизацію
проектування інформаційних систем (ІС).
Як необхідний елемент системного і структурно-
функціонального аналізу CASE-засоби дозволяють моделювати
бізнес-процеси, діяльність і структуру організацій, проектувати
бази даних і створювати компоненти програмного забезпечення.
Результат застосування CASE-засобів — оптимізація інформацій-
них систем, зниження витрат, підвищення ефективності, змен-
шення ймовірності помилок.
Сучасні CASE-засоби охоплюють майже всю область під-
тримки технологій проектування інформаційних систем: від
простих засобів аналізу і документування до повномасштабних
засобів автоматизації, що «покривають» весь життєвий цикл
програмного забезпечення (ПЗ). Під життєвим циклом (ЖЦ)
програмного забезпечення розуміють безперервний процес від
моменту прийняття рішення про створення ПЗ до завершення
його експлуатації.
CASE-технологія являє собою методологію проектування ІС, а
також набір інструментальних засобів, що дозволяють у наочній
формі моделювати предметну область, аналізувати цю модель на
всіх етапах розробки і супроводу ІС і розробляти прикладне про-
88
грамне забезпечення відповідно до інформаційних потреб корис-
тувачів. Більшість сучасних CASE-засобів заснована на методоло-
гіях структурного (в основному) або об’єктно орієнтованого аналі-
зу і проектування, застосовуваних специфікації у вигляді діаграм
або текстів для опису зовнішніх вимог, зв’язків між моделями сис-
теми, динаміки поведінки системи та архітектури програмних за-
собів.
CASE-засоби представляють собою програмні засоби, що
підтримують процеси створення і/чи супроводу ІС, такі як: ана-
ліз і формулювання вимог, проектування баз даних і прикладно-
го програмного забезпечення, генерація кодів програм, тесту-
вання, управління конфігурацією проекта.
Основне завдання CASE-засобів — це звичайно автоматиза-
ція розробки систем шляхом прямого проектування, яке почи-
нається з аналізу ПО та її бізнес-процесів і завершується розро-
бкою бази даних та прикладного програмного забезпечення.
Пряме проектування систем дістало назву інжинірингу. Крім
інжинірингу, CASE-засоби використовуються і для зворотного,
або повторного, перепроектування, яке дістало назву реінжині-
рингу. Останній дзійснюється виконується з метою вдоскона-
лення існуючих інформаційних систем. При цьому може вико-
нуватись перепроектування не лише програмного забезпечення,
а й бізнес-процесів — BPR (business process reengineering). При
реінжинірингу за основу проектування береться існуюча інфор-
маційна система, що не задовольняє поточним вимогам і прово-
диться її аналіз. На основі аналізу програмних кодів будується
модель існуючого програмного продукту. Отримана модель вдо-
сконалюється і виконується повторна розробка.
На сьогодні ми дістали два головних напрями застосування
CASE-засобів:
 BPR — перепроектування бізнес-процесів, тобто реінжині-
ринг;
 системний аналіз і проектування, що включає функціональ-
не, інформаційне і процедурне моделювання як нових систем, що
створюються, так і вже існуючих.
Необхідно зазначити, що ці два напрями тісно пов’язані між
собою, оскільки при аналізі організації і розробці проекту її ав-
томатизації використовуються елементи BPR (більше того, тео-
ретично BPR повинне бути першим етапом розробки), в той же
час необхідним етапом перепроектування є принаймні створення
функціональної моделі бізнес-процесу.

89
 Сучасний ринок програмних засобів налічує понад 300 різних
CASE-засобів. До CASE-засобів належить будь-який програмний
засіб, що автоматизує ту або іншу сукупність процесів створення
ІС і має такі характерні особливості:
 графічні засоби для опису документування ІС, що забезпе-
чують зручний інтерфейс з розробником, розвиваючи його творчі
можливості;
 інтеграція окремих компонент CASE-засобів, яка забезпечу-
вала б керованість процесом розробки ІС;
 використання спеціальним образом організованого сховища
проектних метаданих (репозиторію).

5.2. Класифікація CASE-засобів

CASE-засоби можна класифікувати за такими ознаками:

 орієнтація на етапи життєвого циклу;
 функціональна повнота;
 тип моделей;
 ступінь незалежності від СКБД.
За орієнтацією на етапи життєвого циклу CASE-засоби по-
діляються на три основних категорії: верхнього рівня (upper),
нижнього (lower) та інтегровані.
До CASE-засобів верхнього рівня (upper-CASE) належать ін-
струментальні засоби, що автоматизують початкові стадії життє-
вого циклу розробки ПО: визначення вимог, аналіз, проектування.
До CASE-засобів нижнього рівня (lower-CASE) належать ін-
струментальні засоби, що автоматизують чи допомагають про-
грамісту на стадіях розробки і тестування програмного продукту.
Звичайно маються на увазі різні генератори коду, сюди ж можна
віднести й засоби автоматизації тестування.
Інтегровані CASE-засоби (i-CASE) включають CASE-засоби,
що виконують функції upper- і lower-CASE, компоненти яких ор-
ганізовані таким чином, що вихід одного компонента (результат
його роботи) може бути переданий далі на вхід іншого. Наприкінці
ланцюжка генерується програмний код, як правило, мовою типу
Коболу чи СI.
Інтегрований CASE-засіб (чи комплекс засобів), що підтримує
повний життєвий цикл ПЗ, і містить такі компоненти;
 репозитарій, що є основою CASE-засобу. Він повинен забез-
печувати збереження версій проекту та його окремих компонен-
тів, синхронізацію надходження інформації від різних розробни-
90
ків при груповій розробці, контроль метаданих на повноту і не-
суперечливість;
 графічні засоби аналізу і проектування, що забезпечують
створення і редагування ієрархічно зв’язаних діаграм (DFD, ERD
та ін.), які утворять моделі ІС;
 засоби розробки прикладного програмного забезпечення,
включаючи мови 4GL і генератори кодів;
 засоби конфігураційного управління;
 засоби документування;
 засоби тестування;
 засоби управління проектом;
 засоби реінжинірингу.
Класифікація за орієнтацією на етапи життєвого циклу в основ-
ному збігається з компонентним складом CASE-засобів і вклю-
чає такі основні типи:
 засоби аналізу (Upper CASE), призначені для побудови та
аналізу моделей предметної області (Design/IDEF (Meta Software),
BPwin (Logic Works);
 засоби аналізу і проектування (Middle CASE), що підтриму-
ють найпоширеніші методології проектування і використовують-
ся для створення проектних специфікацій (Vantage Team Builder
(Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV
(McDonnell Douglas), CASE. Аналітик (МакроПроджект)). Вихо-
дом таких засобів є специфікації компонентів та інтерфейсів сис-
теми, архітектури системи, алгоритмів і структур даних;
 засоби проектування баз даних, що забезпечують моделю-
вання даних і генерацію схем баз даних (як правило, на мові
SQL) для найпоширенішої СКБД. До них належать ERwin (Logic
Works), S-Designor (SDP, Powersoft) і DataBase Designer (ORACLE).
Засоби проектування баз даних є також у складі CASE-засобів
Vantage Team Builder, Designer/2000, Silverrun і PRO-IV;
 засоби розробки прикладних програм. До них належать засоби
4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase),
Developer/2000 (ORACLE), New Era (Informix), SQL Windows
(Centura), Delphi (Borland) та ін.) і генератори кодів, що входять
до складу Vantage Team Builder, PRO-IV і частково — до Silverrun;
 засоби реінжинірингу, що забезпечують аналіз програмних
кодів і схем баз даних і формування на їх основі різних моделей і
проектних специфікацій. Засоби аналізу схем БД і формування
ERD входять до складу Vantage Team Builder, PRO-IV, Silverrun,
Designer/2000, ERwin і S-Designor. В області аналізу програмних
кодів найбільше поширення дістали об’єктно орієнтовані CASE-
91
засоби, що забезпечують реінжиніринг програм на мові СІ++
(Rational Rose (Rational Software), Object Team (Cayenne)).
Допоміжні CASE-засоби включають:
 засоби планування та управління проектом (SE Companion,
Microsoft Project та ін.);
 засоби конфігураційного управління (PVCS (Intersolv));
 засоби тестування (Quality Works (Segue Software));
 засоби документування (SoDA (Rational Software)).
За функціональною повнотою CASE-системи можна поді-
лити на такі типи:
 системи, призначені для вирішення окремих задач на од-
ному чи кількох етапах життєвого циклу, наприклад ERwin
(Logic Works), S-Designor (SDP, Powersoft), CASE. Аналітик (Ма-
кроПроджект), Silverrun (CSA);
 інтегровані системи, що підтримують увесь життєвий цикл
ІС і пов’язані зі спільним репозитарієм, наприклад система
Vantage Team Builder (Cayenne), Designer/2000 з системою розроб-
ки додатків Developer/2000 (ORACLE).
За типом моделей CASE-системи можна поділити на такі три
основні різновиди: структурні, об’єктно орієнтовані і комбіновані.
Структурні CASE-системи основані на методах структурно-
го і модульного програмування, структурного аналізу систем,
наприклад, система Vantage Team Builder (Cayenne).
Об’єктно орієнтовані методи і відповідно CASE-системи
дістали свого розвитку на початку 90-х років. Прикладами
об’єктно орієнтованих систем є Relation Rose (Retional Software,
Object Team (Cayenne).
Комбіновані CASE-системи одночасно підтримують струк-
турні та об’єктно орієнтовані методи, наприклад Designer/2000
(ORACLE).
За ступенем незалежності від СКБД CASE-системи поділя-
ються на незалежні та вбудовані.
Незалежні CASE-системи — це автономні системи, що не
входять до складу конкретної СКБД. Як правило, вони підтри-
мують декілька баз даних через інтерфейс ODBC. До цих сис-
тем належать S-Designor (SDP, Powersoft), ERwin (Logic Works),
Silverrun (CSA).
Вбудовані CASE-системи — це системи, що підтримують фор-
мат баз даних тих СКБД, до складу яких вони входять. При
цьому можлива підтримка й інших форматів баз даних. Прикла-
дом такої системи є Designer/2000, який входить до складу СКБД
ORACLE.
92
 5.3. Характеристика методологій моделювання
даних

Найпоширенішими методологіями, що застосовуються

для моделювання даних, є такі:
 методологія ERD;
 методологія IDEF1.
Методологія ERD була вперше запропонована П. Ченом. По-
дальшого розвитку вона дістала у працях Баркера. Тому іноді мо-
делі даних на основі ER-діаграм називають не тільки моделлю Чена,
а й моделлю Баркера. В основу методології ERD покладено діагра-
му «сутність — зв’язок» (Entity-Relations Diagrams), за допомогою
якої визначаються об’єкти (сутності) предметної області, їх власти-
вості (атрибути) і відносини між об’єктами (зв’язки). Методологія
ERD використовується для проектування реляційних баз даних.
Методологія IDEF1, що теж ґрунтується на підходах П. Чена,
була розроблена Т. Ремей. Удосконалений варіант цієї методоло-
гії IDEF1X покладено в основу поширених CASE-засобів, які ви-
користовуються для автоматизації проектування реляційних БД
(зокрема, ERwin, Design/IDEF).

5.3.1. Характеристика методології ERD

Як уже зазначалось, основними складовими методоло-

гії ERD, є сутності, атрибути і зв’язки.
Сутність (Entity) — це реальний об’єкт ПО, який підлягає
зберіганню в БД.
Кожна сутність ідентифікується унікальним ім’ям, кожний ек-
земпляр сутності — однозначно ідентифікується і відрізняється
від усіх інших екземплярів даного типу. Сутність повинна харак-
теризуватись такими властивостями:
 мати унікальне ім’я, і до одного й того самого імені повинна
завжди застосовуватися одна й та ж інтерпретація. Остання не
може застосовуватися до різних імен, якщо тільки вони не є псе-
вдонімами;
 характеризуватися одним або кількома атрибутами, які або на-
лежать їй, або успадковуються через зв’язок з іншими сутностями;
 вміщувати один чи кілька атрибутів, які однозначно іденти-
фікують кожний екземпляр сутності;
 мати будь-яку кількість зв’язків з іншими сутностями моделі.
93
 Зв’язок (Relationship) — поімеінована асоціація між двома
сутностями, яка має місце в реальній предметній області.

Зв’язок — це асоціація між сутностями, за якої, зазвичай, кож-

ний екземпляр однієї сутності, що має назву батьківської, асоційо-
ваний з довільною (в тому числі нульовою) кількістю екземплярів
другої сутності, яка називається сутністю-нащадком, або дочірньою,
а кожний екземпляр сутності-нащадка асоційований з одним екзем-
пляром батьківської сутності. Таким чином, екземпляр сутності-
нащадка може існувати тільки у разі існування батьківської сутнос-
ті.
Зв’язки ідентифікуються іменами, котрі, як правило, є дієсло-
вами. Ім’я кожного зв’язку між двома сутностями повинно бути
унікальним, але імена зв’язків у моделі не обов’язково мають бу-
ти такими.
Вид зв’язку та його обов’язковість графічно зображаються та-
ким чином (рис. 5.1).
1:Б Необов’язковий
1:1 Обов’язковий

Рис. 5.1. Види зв’язків

Атрибут — будь-яка характеристика сутності, значуща для
предметної області і призначена для кваліфікації, ідентифі-
кації, класифікації, кількісної характеристики або виражен-
ня стану об’єктів предметної області.
Атрибут представляє тип характеристик або властивостей,
асоційованих з безліччю реальних або абстрактних об’єктів (лю-
дей, місць, подій, станів, ідей, пар предметів і т.д.). Екземпляр
атрибута — це певна характеристика окремого елемента множи-
ни. В ER-моделі атрибути асоціюються з конкретними сутностя-
ми. Атрибут може бути або обов’язковим, або необов’язковим.

<Ім’я сутності>
# <атрибут>
* <атрибут>
0 <атрибут>
Позначення:
# — первинний ключ;
* — обов’язковий атрибут;
0 — необов’язковий атрибут.

94
 Рис. 5.2. Позначення атрибутів

Обов’язковість означає, що атрибут не може набувати неви-

значених значень (null values). Атрибут може бути або описовим
(тобто звичайним дескриптором сутності), або входити до складу
унікального ідентифікатора (первинного ключа).
Унікальний ідентифікатор — це атрибут або сукупність атри-
бутів і/або зв’язків, призначена для унікальної ідентифікації кож-
ного екземпляра даного типу сутності. Остання може бути повніс-
тю ідентифікована своїми власними ключовими атрибутами або
в її ідентифікації беруть участь атрибути іншої батьківської сут-
ності. Позначення ER-діаграми, які використовуються в цих ви-
падках, наведені на рис. 5.3.
<Ім’я сутності> <Ім’я сутності>
# <атрибут> # <атрибут>
Ідентифікація з
Повна використанням
ідентифікація іншої сутності

Рис. 5.3. Види ідентифікації сутності

Кожний атрибут ідентифікується унікальним ім’ям, що вира-

жається, як правило, іменником, котрий описує семантику даного
атрибута. Атрибути зображаються у вигляді списку імен усере-
дині блоку сутності, причому кожний атрибут займає окремий
рядок. Атрибути, що визначають первинний ключ, розміщуються
вгорі списку і виділяються знаком «#».
Кожна сутність повинна володіти хоча би одним можливим
ключем. Можливий ключ сутності — це один або кілька атрибу-
тів, чиї значення безперечно визначають кожний екземпляр сут-
ності. У разі існування кількох можливих ключів один з них ви-
значається як первинний, а інші — як альтернативні.
Крім перелічених основних елементів, модель даних може міс-
тити ряд додаткових.
Підтипи і супертипи: одна сутність є узагальнюючим понят-
тям для групи подібних сутностей (рис. 5.4).

95
 Одяг Супертип
Зимовий Літній Демісезонний
Підтип
Чоловічий Жіночий Дитячий

Рис. 5.4. Підтипи і супертипи

Взаємно виключаючі зв’язки: кожний екземпляр сутності

бере участь тільки в одному зв’язку з групи взаємно виключаю-
чих зв’язків (рис. 5.5).
А 0 В

0
С

Рис. 5.5. Взаємно виключаючі зв’язки

Рекурсивний зв’язок: сутність може бути пов’язана сама з
собою (рис. 5.6).

Рис. 5.6. Рекурсивний зв’язок

Непереміщувані зв’язки (non-transferrable): екземпляр сут-
ності і не може бути перенесений з одного екземпляра зв’язку в
інший (рис. 5.7).

Рис. 5.7. Непереміщуваний зв’язок

5.3.2. Характеристика методології IDEF1X

Удосконалений варіант методології IDEF1X — розро-

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

96
ються незалежно від її зв’язків з іншими сутностями. Залежна
сутність — це сутність, однозначна ідентифікація екземплярів
якої залежить від її зв’язків з іншими сутностями. Кожній сутності
присвоюється унікальні ім’я і номер, що розміщуються над нею.
Атрибути зображаються у вигляді списку імен усередині бло-
ку сутності. Атрибути, що визначають первинний ключ, розмі-
щуються вгорі списку і відділяються від інших атрибутів горизо-
нтальною лінією (рис. 5.8); навпроти атрибутів, які є зовнішніми
ключами, стоїть позначка — (FK).
Сутніcть-A
<Атрибут первинного ключа >
<Ім’я атрибута_1>
<Ім’я атрибута_2> (FK)

Рис. 5.8. Приклад відображення сутності

Зв’язок між сутностями, крім імені, може додатково характери-
зуватись мірою або потужністю (кількість екземплярів сутності-
нащадка, яка може існувати для кожного екземпляра батьківської
сутності). У IDEF1X можуть бути вказані такі потужності зв’язків:
 кожний екземпляр батьківської сутності може мати нуль,
один або більше пов’язаних з ним екземплярів сутності-нащадка;
 кожний екземпляр батьківської сутності повинен мати не
менше одного пов’язаного з ним екземпляра сутності-нащадка;
 кожний екземпляр батьківської сутності повинен мати не бі-
льше одного, пов’язаного з ним екземпляра сутності-нащадка;
 кожний екземпляр батьківської сутності пов’язаний з деяким
фіксованим числом екземплярів сутності-нащадка.
Зв’язки можуть бути ідентифікуючими та неідентифікуючими.
Ідентифікуючий зв’язок — це зв’язок, за якого екземпляри
сутності-нащадка ідентифікуються зв’язком з батьківською сут-
ністю. Сутність-нащадок в ідентифікуючому зв’язку є залежною
від батьківської сутності. Батьківська сутність в ідентифікуючо-
му зв’язку може бути як незалежною, так і залежною, що визна-
чається її зв’язками з іншими сутностями.
Неідентифікуючий зв’язок — це зв’язок, за якого екземпляри
сутності-нащадка не ідентифікуються зв’язком з батьківською
сутністю. Сутність-нащадок в неідентифікуючому зв’язку буде не-
залежною від батьківської сутності, якщо вона не є також сутністю-
нащадком в якому-небудь іншому ідентифікуючому зв’язку.
Зв’язок зображується дугою, що виходить з батьківської сут-
ності до сутності-нащадка і завершується на кінці крапкою. Іден-

97
тифікуючий зв’язок відображається суцільною лінією (рис. 5.9), а
неідентифікуючий зв’язок — пунктирною (рис. 5.10). Залежна
сутність відображається прямокутником зі скругленими кутами.
Сутність-В
Сутність-А
Ключовий атрибут-В
Ключовий атрибут-А Ім’я зв’язку Ключовий атрибут-A (FK)

Рис. 5.9. Ідентифікуючий зв’язок

Цех Працівник
Код цеху Табельний номер
Назва цеху Працюють Код цеху (FK)
Телефон Прізвище
Ім’я
По батькові

Рис. 5.10. Неідентифікуючий зв’язок

Потужність зв’язку відображається літерами, які проставля-

ються над дугою (Z — ноль або один, P — один або більше по-
тужність, за замовчуванням потужність позначається літерою N
— ноль, один або більше).

5.4. Засоби інформаційного моделювання

Для цілей інформаційного моделювання на сьогодні не

існує альтернативи діаграмам «сутність-зв’язок» (ERD — entity-
relationship diagrams). Практично всі CASE-системи підтриму-
ють ту або іншу нотацію ERD. При цьому розробка інформацій-
ної моделі в середовищах, що розглядаються, включає не тільки
проектування логічної моделі, але й перетворення її у фізичну
модель з подальшою генерацією схеми БД з урахуванням специ-
фіки конкретної СКБД.
До незалежних CASE-засобів структурного типу, які викорис-
товуються для інформаційного моделювання, можна віднести
популярні продукти: S-Designor (фірми SDP, придбаний
Powersoft), ERwin (Logic Works) і Silverrun (CSA).

98
 5.4.1. S-Designor — засіб інформаційного моде-
лювання

5.4.1.1. Загальна характеристика S-Designor

S-Designor — це графічний інструмент для проекту-

вання структури реляційних баз даних. Як уже зазначалось, S-
Designor належить до незалежних CASE-засобів структурного
типу. Починаючи з версії S-Designor 6.0, випускається під назвою
PowerDesignor 6.0. S-Designor реалізує методологію інформацій-
ного моделювання, засновану на представленні інформаційних
об’єктів і взаємозв’язків між ними у вигляді ER-діаграми («сут-
ність-зв’язок»). У S-Designor використовується нотація — IE
(Information Engineering).
У S-Designоr ефективно реалізовано зв’язок з великою кількі-
стю сучасних СКБД і засобами розробки прикладних програм.
По завершенні розробки моделі даних S-Designor генерує пакети
SQL-пропозицій для широкого набору СКБД, включаючи Oracle
Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase,
Access і Paradox. Для підтримуваних СКБД автоматично генеру-
ються тригери, що забезпечують посилкову цілісність. Передба-
чено можливість редагувати збережені процедури безпосередньо
при підготовці фізичної моделі.
Для забезпечення супроводу існуючих систем S-Designor до-
зволяє проводити відновлення моделі за структурою бази даних.
Протягом усього циклу розробки моделі даних за допомогою S-
Designor можна отримати різноманітні звіти. На етапі проекту-
вання моделі даних S-Designor дає можливість визначити елеме-
нти користувацького інтерфейсу майбутніх програм, що працю-
ють із запроектованою базою даних. Це досягається
редагуванням репозитарія системи. Як засоби розробки підтри-
муються PowerBuilder, TeamWindows, Progress, Uniface та ін. S-
Designor працює в середовищі Microsoft Windows і Windows NT.
Для його використання досить комп’ютера з процесором 386SX
та обсягом пам’яті від 4 мегабайт.
У S-Designor присутні елементи, характерні для програм реда-
гування: лінійка інструментів, інтерфейс «drag-and-drop», ім-
порт/експорт графічних файлів, інструменти для створення стан-
дартних графічних елементів, керування кольором і шрифтовим
виділенням.

99
 При проектуванні в S-Designor використовується дворівневий
підхід: перший — концептуальна модель даних (ER-діаграма);
другий — фізична модель даних. При переході на другий рівень
S-Designor автоматично генерує відповідну фізичну модель да-
них для вибраної СКБД з урахуванням її специфіки.
Концепція S-Designor — реалізація класичної теорії інформа-
ційного моделювання, що включає чіткий поділ між концептуа-
льною моделлю даних (представлення об’єктів реального світу та
взаємозв’язку) і фізичної (відображення цих об’єктів у термінах,
близьких до фізичного представлення) (рис. 5.11). Наприклад,
зв’язки багато до багатьох. Відповідно до теорії інформаційного
моделювання і проектування баз даних такий зв’язок при реалі-
зації має бути деталізований додаванням третьої зв’язкової таб-
лиці. Представивши зв’язок Б : Б у S-Designor на концептуально-
му рівні при генерації фізичної моделі, S-Designor автоматично
додає зв’язкову таблицю, у такий спосіб деталізуючи цей зв’язок.
Особливість S-Designor полягає в тому, що він дозволяє вико-
нувати пряме та зворотне проектування. При прямому проекту-
ванні, розробивши концептуальну модель можна автоматично зге-
нерувати фізичну і після цього виконати генерацію структури БД.

100
 Предметна область

Побудова інформаційної
моделі предметної області
(концептуальна —
CDM-модель)

Вибір СКБД

Генерування Реінжиніринг
фізичної моделі моделі

Фізична модель (PDM)

Створення тригерів Реінжиніринг

і процедур, що моделі
зберігаються
Вибрана
СКБД

Рис. 5.11. Етапи розробки у S-Designor

При зворотному проектуванні послідовність дій прямо проти-

лежна. Можна одержати фізичну модель на основі структури БД і
після цього автоматично згенерувати концептуальну модель. На
кожному етапі можна вносити потрібні зміни в моделі концептуа-
льного і фізичного рівнів. S-Designor чітко відслідковує відповід-
ність між концептуальним і фізичним рівнем і «пам’ятає» не
тільки зміни в структурі об’єктів моделі (уточнення зв’язків, які
виконані при переході на фізичний рівень), але й їх розташування
на ER-діаграмі.
S-Designor складається з чотирьох взаємозв’язаних, але само-
стійних для окремого виконання модулів:
 DataArchitect — концептуальне і фізичне проектування БД;
 AppModeler — проектування програмного забезпечення для
обслуговування створеної БД;
 ProcessAnalyst — аналіз моделей, побудованих DataArchitect;
 MetaWorks — модуль, що керує роботою модулів
DataArchitect, AppModeler та ProcessAnalyst по дизайну даних.
101
 5.4.1.2. Опис зв’язків між об’єктами в S-Designor

У середовищі S-Designor використовуються спеціальні

графічні позначення для відображення можливих зв’язків між
сутностями (об’єктами) предметної області. Можливі види
зв’язків та їх графічне зображення мають такий вигляд:
1.Один до одного:
А B

1.1.Кожному запису об’єкта А може відповідати лише один

запис в об’єкті В, і навпаки, кожному запису об’єкта В може від-
повідати один запис із об’єкта А. При цьому необов’язково
(optional) кожному запису із об’єкта А відповідає пов’язаний з
ним запис в об’єкті В, і навпаки.
А B

1.2.Кожному запису об’єкта А може відповідати лише один

запис в об’єкті В, і навпаки, кожному запису із об’єкта В може
відповідати лише один запис із об’єкта А. При цьому обов’язково
(mandatory) для кожного запису із об’єкта А існує пов’язаний з
ним запис в об’єкті В, і навпаки.
А B

1.3. Кожному запису об’єкта А може відповідати лише один

запис в об’єкті В, і навпаки, кожному запису із об’єкта В може
відповідати лише один запис із об’єкта А. При цьому обов’язково
(mandatory) для кожного запису із об’єкта А існує пов’язаний з
ним запис в об’єкті В, а в об’єкті В можуть бути записи, яким не
відповідає жоден запис з об’єкта А.
2.Один до багатьох:
А B

102
 2.1.Кожному запису об’єкта А може відповідати один чи більше
записів з об’єкта В. При цьому необов’язково кожному запису із
об’єкта А відповідає пов’язаний з ним запис в об’єкті В, і навпаки.
А B

2.2.Кожному запису об’єкта А може відповідати один чи більше

записів з об’єкта В. При цьому обов’язково кожному запису об’єкта
А повинен відповідати пов’язаний запис в об’єкті В, а кожному за-
пису із об’єкта В може не відповідати певний запис в об’єкті А.
А B

2.3.Кожному запису об’єкта А може відповідати один чи більше

записів із об’єкта В. При цьому обов’язково кожному запису об’єкта
А відповідає пов’язаний хоча б один запис в об’єкті В, і навпаки.
3.Багато до багатьох:
А B

3.1.Кожному запису об’єкта А може відповідати багато записів

в об’єкті В, і навпаки, кожному запису об’єкта В може відповіда-
ти багато записів в об’єкті А. При цьому необов’язково для кож-
ного запису із об’єкта А повинен існувати пов’язаний запис в
об’єкті В, і навпаки.
А B

3.2.Кожному запису об’єкта А може відповідати багато записів

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

103
 3.3.Кожному запису об’єкта А може відповідати багато записів
в об’єкті В, і навпаки, кожному запису об’єкта В може відповіда-
ти багато записів в об’єкті А. При цьому кожному запису об’єкта
А обов’язково повинен відповідати хоча б один пов’язаний запис
в об’єкті В, і навпаки
4. Залежність коду об’єкта А від коду об’єкта В:
А B

Кожному запису об’єкта В може відповідати багато записів

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

5.4.1.3. Порядок інформаційного моделювання в S-

Designor

Процес побудови інформаційної моделі даних склада-

ється з таких станів:
 визначення сутностей;
 визначення атрибутів сутностей;
 завдання первинних і альтернативних ключів;
 приведення моделі до потрібного рівня нормалізації;
 визначення залежностей між сутностями;
 перехід до фізичного опису моделі;
 редагування імен таблиць та їх атрибутів на фізичному рівні
(якщо в моделі наявні, наприклад, зв’язки «багато до багатьох»
чи ієрархічні рекурсивні зв’язки і вони потребують уточнення);
 проектування тригерів, процедур і обмежень;
 генерація бази даних.
У даному навчальному посібнику детальніше буде розглянуто
модуль DataArchitect. Цей модуль надає такі можливості:
 побудова діаграми інформаційно зв’язаних сутностей, що
відображають концептуальну модель даних (у термінології паке-
та CDM-модель, Conceptual Data Model);
 генерація відповідної фізичної моделі з урахування специфі-
ки вибраної СКБД (у термінології пакета PDM-модель, Physical
Data Model);
104
  налагодження властивостей фізичного відображення даних
для повної відповідності вимогам користувача;
 генерація початкового тексту програм (script) створення БД
для вибраної СКБД;
 за наявності відповідних можливостей СКБД — генерація
тригерів;
 генерація, перегляд і друк звітів по моделі даних (model
reports);
 зворотний аналіз (reverse engineer) існуючої БД та програм-
ного забезпечення;
 визначення розширених атрибутів сутностей PDM-моделі.

5.4.1.4. Проектування сутностей та атрибутів

Завантаживши S-Designor з меню пуск, необхідно при-

ступити до створення сутностей (об’єктів), що характеризують
предметну область. Для цього у відкритому вікні в панелі ін-
струментів обираємо кнопку формування таблиць . Потім роз-
ставляємо об’єкти по робочому полю, натискуючи в потрібних
місцях ліву кнопку мишки. Розмістивши всі об’єкти на робочому
полі, натиснути кнопку . Курсор перетвориться на стрілку.
Вказуючи курсором на об’єкт, потрібно два рази натиснути ліву
кнопку мишки. Відкриється вікно ідентифікації сутності (об’єкта)
(рис. 5.12).
У цьому вікні потрібно ввести назву (Name) та ідентифікацій-
ний код (Code) об’єкта. Після створення та ідентифікації об’єктів
необхідно ввести їх характеристики, тобто атрибути. Це можна
зробити, натиснувши кнопку Attributes або перевівши курсор на
необхідний об’єкт і натиснувши двічі ліву кнопку мишки. На ек-
рані з’явиться вікно Entity Definition, в якому необхідно вибрати
опцію Attributes.

105
 Рис. 5.12. Вікно ідентифікації сутності

З’явиться вікно Attributes of the Entity для введення назв і

типів атрибутів (рис. 5.13). Для введення нового атрибуту необ-
хідно вибрати опцію New, помістити мишку на перше поле і на-
тиснути Ввод.

Рис. 5.13. Вікно для введення атрибутів

Опції цього вікна: New — ввести новий атрибут; Delete — ви-

лучити існуючий атрибут; Add — додати атрибут; Label — мітка
атрибута; Data Type — тип атрибута; Length — довжина атрибута;
Precision — кількість знаків після коми; Domain — визначити тип
даних як список; Identifier — атрибут є ключовим; Mandatory —
атрибут завжди повинен бути введеним; Display — атрибут по-
винен відображатись на екрані.
106
 У цьому вікні потрібно ввести назву атрибута (Name) та його
кодове позначення (Code).
Тип атрибута можна ввести з клавіатури (або вибрати зі списку,
що відкриється, якщо натиснути на кнопку )
та відмітити потрібні опції в лівій частині (D — виводити поле на
екран, M — неключове обов’язкове поле, І — ключове поле). Вік-
но типів даних, які можна визначати в S-Designor, наведене на
рис. 5.14.

Рис. 5.14. Вікно для визначення типу даних

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

Таким чином потрібно описати всі сутності, що були виокремле-
ні при інфологічному проектуванні. Причому потрібно мати на
увазі, що первинні ключі батьківської сутності автоматично міг-
рують у дочірню (підпорядковану) сутність.

5.4.1.5. Встановлення зв’язків

Після опису всіх сутностей (об’єктів) потрібно встано-

вити зв’язки між ними. Для цього на панелі інструментів потріб-
но натиснути на кнопку та встановити всі зв’язки між
об’єктами. Після встановлення всіх зв’язків потрібно натиснути
107
на кнопку із зображенням стрілки. Для визначення типу зв’язку
потрібно навести курсор на лінію зв’язку та два рази натиснути
ліву кнопку мишки. З’явиться вікно для визначення типу зв’язку
(рис. 5.15).
У вікні потрібно вказати, який тип відношення існує між
об’єктами (1 : 1, 1 : Б, Б : Б) та умову відповідності між екземпля-
рами сутностей (Optional — необов’язкова, Mandatory —
обов’язкова). Після визначення потрібно натиснути кнопку ОК.
Цю операцію потрібно повторити для всіх встановлених зв’язків.

Рис. 5.15. Вікно встановлення зв’язку

Після виконання перелічених етапів потрібно перевірити по-

будовану концептуальну модель на відсутність помилок. Для
цього в головному меню вибираємо пункт Dictionary, а з нього
підпункт Check Model або натискуємо клавішу F4. S-Designor
згенерує звіт, в якому будуть вказані помилки або зауваження до
побудованої моделі. Якщо модель не містить помилок, то на ек-
рані з’явиться таке повідомлення (рис. 5.16).
Якщо в цьому вікні буде повідомлено про знайдені помилки,
то переходити до наступного етапу моделювання не можна, бо
всі ці помилки будуть перенесені на фізичну модель, а потім і в
базу даних.
108
 Для виходу з перегляду вікна повідомлень необхідно натисну-
ти текстову кнопку «ОК».

Рис. 5.16. Діалогове вікно «Messages» діагностики помилок логічного

проектування
За відсутності помилок можна згенерувати фізичну (даталогі-
чну) модель бази даних. Для цього потрібно обрати пункт меню
Dictionary/Generate Phisical Model. Відкриється вікно, предста-
влене на рис. 5.17. В цьому вікні потрібно вибрати СКБД, для
якої буде згенеровано фізичну модель, та натиснути кнопку ОК.
У результаті згенерується фізична модель.

109
 Рис. 5.17. Вікно вибору СКБД

5.4.1.6. Створення тригерів і процедур, що зберіга-

ються

Для забезпечення цілісності бази даних у процесі до-

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

Процедури, що зберігаються, відрізняються від тригерів тим,

що виконуються не автоматично, а тільки за викликом.
Можна згенерувати всі стандартні тригери S-Designor на
додавання, вилучення та відновлення або відмінити будь-
який з них, або написати свій мовою SQL. Для генерації три-
герів необхідно викликати режим Database Generate
Triggers&Procedurs, змінити у разі необхідності параметри за
замовчуванням і натиснути текстову кнопку Generate skript для
генерація тексту програми створення тригерів. Текст програми
буде занесено у файл cretrg.sgl в директорії, що зазначена у полі
Directory. Якщо цей файл до запуску генерації тригерів відсутній
на диску, то S-Designor перепитає, чи можна створювати цей
файл (або переписувати, коли він уже існує).

5.4.2. ERwin — засіб інформаційного моделюван-

ня

5.4.2.1. Загальна характеристика ERwin

За допомогою CASE-засобу ERwin можна автоматизувати

проектування БД і генерацію її опису мовою вибраної СКБД
(Oracle, Sybase, MS SQL Server та ін.), а також виконати реінжи-
110
ніринг бази даних. За функціональними можливостями ERwin
близький до S-Designor. Відмінності полягають у тому, що ERwin
організує зв’язок із СКБД безпосередньо, а S-Designor виконує
його через ODBC-інтерфейс.

111
 Логічне моделювання в ERwin можна виконувати з викорис-
танням однієї з двох методологій — IDEF1X чи IE. Методологія
— IDEF1X була розроблена для ВВС США і тепер використову-
ється в урядових, аерокосмічних і фінансових установах, а також
багатьох приватних компаніях. Ця методологія визначає стандар-
ти і терміни, які використовуються при інформаційному моделю-
ванні і графічному зображенні типових елементів даних на діаг-
рамах. Діалогове вікно вибору методології проектування
наведено на рис. 5.18.

Рис. 5.18. Вікно вибору методології проектування

В ERwin існує два рівні представлення і моделювання БД: ло-

гічний і фізичний. На логічному рівні проектується інформаційна
модель предметної області, тобто концептуальна (інфологічна)
модель. На фізичному рівні проектується модель з урахуванням
специфіки та особливостей вибраної СКБД, тобто фізична (дата-
логічна) модель. Розділення процесу проектування на логічну та
фізичну моделі дозволяє вирішити проблему ідентифікації
об’єктів (сутностей). На логічному рівні об’єктам можна присвої-
ти імена, які зрозуміліші спеціалістам ПО, а на фізичному — по-
будувати імена за тими правилами, які вимагає вибрана СКБД.
Тобто у кожного імені може бути свій псевдонім. Враховуючи те,
1
що дуже часто використовуються нелокалізовані версії СКБД, то
це надає зручностей у документування моделі та її розумінні.
У середовищі ERwin можна виконувати пряме (Forward
Engineering) та зворотне (Reverse Engineering) проектування.
Пряме проектування полягає в тому, що на основі логічної моде-
лі, яка проектується в діалоговому режимі, ERwin автоматично
генерує фізичну модель для вибраної СКБД. При зворотному
проектуванні на основі фізичної моделі ERwin може згенерувати
системний каталог СКБД і відповідний SQL-скрипт. У той же час
згідно з системним каталогом і SQL-скриптом ERwin може від-
творити логічну модель БД і потім на її основі згенерувати фізи-
чну модель з використанням іншої СКБД. Таким чином, можна
вирішити проблему перенесення структури БД з одного сервера
на інший чи вирішити проблему переносу dbf-файлів у реляційну
СКБД, тобто перейти від файл-сервера до клієнт-сервера.
Діаграма ERwin складається з трьох основних блоків: сутнос-
тей (об’єктів), атрибутів і зв’язків. Якщо розглядати діаграму як
графічне представлення об’єктів предметної області і зв’язків
між ними, то об’єктами є іменники, а зв’язки — дієслова.
В меню ERwin існують такі режими відображення:
 режим «сутності» використовується для відображення сут-
ностей у вигляді прямокутників. Усередині прямокутника від-
творюється ім’я сутності (для логічної моделі) або ім’я таблиці
(для фізичної моделі);
 режим «визначення сутності» слугує для створення презен-
таційних діаграм;
 режим «атрибути» використовується для занесення характе-
ристик сутностей, якими є атрибути. В цьому режимі прямокут-
ник-сутність розділяється лінією на дві частини: у верхній відо-
бражаються атрибути первинного ключа, у нижній — неключові
атрибути;
 режим «первинні ключі» показує лише атрибути, що входять
до складу первинного ключа;
 режим «піктограми». Для презентаційних цілей кожній таб-
лиці може бути призначена відповідна піктограма (bitmap);
 режим «показ дієслівної фрази» відображає на дугах зв’язків
дієслова, які зв’язують сутності між собою (для логічного рівня)
чи імена зовнішніх ключів (для фізичного рівня).
Переключення на певний режим відображення виконується за
допомогою панелі інструментів чи за допомогою вікна (рис.
5.19), яке з’являється, якщо клацнути правою кнопкою мишки на
пустому місці діаграми.

2
 Рис. 5.19. Вікно переключення між режимами відображення

5.4.2.2. Характеристика інструментів ERwin

Інструментами ERwin є лінійка панелі інструментів та

додаткове меню ERwin Toolbox (елементи лінійки панелі ін-
струментів та їх призначення наведені в табл. 5.1).
Таблиця 5.1
ЛІНІЙКА ПАНЕЛІ ІНСТРУМЕНТІВ

Елемент Призначення елемента

Створення, відкриття, зберігання і друк моделі

Виклик діалогу Report Browser для генерації звітів

Вибір рівня відображення моделі: рівень сутностей,

рівень атрибутів і рівень опису

Зміна масштабу

Генерація схеми БД, синхронізація схеми БД з мо-

деллю і вибір сервера СКБД (доступні лише на фі-
зичному рівні)
Виклик додаткової панелі для роботи з репозитарієм
ModelMart

Перемикач між областями моделі

Перемикач між логічною та фізичною моделями

3
 Перехід з логічного рівня проектування на фізичний викону-
ється перемикачем панелі інструментів (палітра інструментів до-
даткового меню логічного рівня наведена на рис. 5.20).
Створення
Режим сутності
мишки

Текст

Категоріальний
зв’язок
Маніпулю- Ідентифі Зв’язок Неіденти-
вання куючий Б:Б фікуючий
атрибутами зв’язок зв’язок

Рис. 5.20. Додаткова панель інструментів логічного рівня

При переході на фізичний рівень моделі на екрані з’являється

додаткова панель інструментів фізичного рівня (рис. 5.21). Ця
панель має деякі відмінності від додаткової панелі інструментів
логічного рівня.

Рис. 5.21. Додаткова панель інструментів фізичного рівня

Замість кнопки створення категоріального зв’язку з’явилась

кнопка створення представлення (view) таблиці, а замість кнопки
«зв’язок Б:Б» — кнопка створення зв’язку між таблицею і пред-
ставленням. Кнопка створення сутності на фізичному рівні нази-
вається кнопкою створення незалежної таблиці.

5.4.2.3. Створення логічної моделі даних

Розрізняють три рівні моделі, які відрізняються за гли-

биною представлення інформації про дані:
 діаграма сутність-зв’язок (Entity Relationship Diagram, ERD);
 модель даних, основана на ключах (Key Based model, KB);
 повна атрибутивна модель (Fully Attributed model, FA).

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

Створення сутностей та визначення атрибутів

Сутності створюються на рівні логічного моделювання
у вікні меню Entity Editor. В цьому вікні визначається ім’я сут-
ності, робиться її опис та наводиться певний коментар. Для ство-
рення сутності необхідно на панелі інструментів ERwin Toolbox
(рис. 5.20) вибрати кнопку створення сутності. Клацнувши пра-
вою кнопкою мишки по сутності і в меню, що з’явиться, вибрати
діалог Entity Editor (рис. 5.22), в якому зазначаються ім’я, опис
та коментарі по створюваній сутності.
Закладинки Note, Note2, Note3 можна використовувати для
занотовування додаткових характеристик сутності: Note — для
зауважень чи бізнес-правил з організації діаграм; Note2 — для
документування запитів, які можуть бути поставленими до сут-
ності, Note3 — для прикладів даних сутності. За допомогою за-
кладинки Icon можна визначити піктограму для сутності. Закла-
динка UDP використовується для властивостей, що задаються
користувачем.
ERwin підтримує для UDP шість таких характеристик типів
даних:
 Date — тип «дата». Використовується формат MM/DD/YY;
 Int — ціле число;
 Real — дійсне число;
 Text — текст у форматі (ASCII);
 List — список. Задаючи список у діалозі UDP (User Defined
Property), значення необхідно розділяти комою, значення за за-
мовчуванням позначається «~»;
 Command — команда, що виконується.

5
 Рис. 5.22. Вікно для ідентифікації та опису сутності

Для визначення атрибутів, що входять до складу сутності, не-

обхідно клацнути правою кнопкою миші по сутності і з меню, що
з’явиться, вибрати Attribute Editor. З’явиться вікно (рис. 5.23), в
якому, якщо клацнути по кнопці New, з’явиться вікно New
Attribute (рис. 5.24), в якому можна вводити імена атрибутів та
їх характеристики.
У цьому вікні також можна задавати імена атрибутів, які ви-
користовуються на логічному рівні і відповідні їм імена фізично-
го рівня. Атрибути первинного ключа відмічаються в закладинці
General вікна Attribute Editor опції Primary Key.
Для більшої наочності кожному атрибуту присвоюється від-
повідна піктограма (іконка). Це можна зробити за допомогою ви-
бору опції Icon у закладинці General.
Слід пам’ятати, що імена атрибутів за ідеологією IDEF1X по-
винні бути унікальними не лише в рамках певної сутності, а й
моделі в цілому. На практиці таке обмеження не завжди зручне,
тому існує можливість відмінити це обмеження, встановивши
опцію Allow у меню Option/Unigue Name.

6
Рис. 5.23. Вікно для визначення атрибутів сутності

Рис. 5.24. Вікно для ідентифікації атрибута

7
 При встановленні зв’язку «атрибути первинного ключа» голо-
вної сутності вони автоматично переносяться як зовнішні ключі у
підпорядковану сутність. Тому при проектуванні підпорядкова-
ної сутності не слід в ній відображати вторинні ключі. Кнопка
Migrate діалога у Attribute Editor викликає діалогове вікно
Migrate Attribute Property, в якому можна задавати властивості,
що повинні зберегтися при міграції.
Закладинку Definition діалогу Attribute Editor використову-
ють для визначення атрибута та його додаткових характеристик,
таких як можливі значення, верхня-нижня межа та ін. Іноді атри-
бут обчислюється на основі інших атрибутів, тоді вказується по-
рядок такого обчислення.
Сутність відображається прямокутником, над яким вказується
її ім’я, а в середині прямокутника — атрибути, що входять до її
складу. Первинний ключ у прямокутнику, що відображає сут-
ність, відділяється від неключових атрибутів горизонтальною лі-
нією. Незалежна сутність відображається прямокутником з гост-
рими кутами, а залежна — прямокутником із закругленими
кутами.
Для атрибутів, крім основних, функціональних, імен, можна
задавати рольові імена. Рольові імена будуть синонімами атрибу-
та зовнішнього ключа, що вказують на ту роль, яку відіграє атри-
бут у дочірній сутності. Так, у сутності ВИКЛАДАЧ зовнішній
ключ КОД КАФЕДРИ має функціональне ім’я ДЕ ПРАЦЮЄ, яке
показує, яку роль відіграє цей атрибут у підпорядкованій (залеж-
ній) сутності (рис. 5.25).
Викладач Викладач
Код кафедри Де працює_Код кафедри (FK)
Табельний №
Назва кафедри
Телефон Зав_кафедрою_табельний № Керує /
підчиняється
Ім’я ролі
(функціональне) Ім’я ролі
(базове)
Рис. 5.25. Встановлення рольових імен для зовнішніх ключів
За замовчуванням у списку атрибутів вказується лише ім’я
ролі. Для відображення повного імені атрибута — як функціона-
льного, так і рольового — необхідно в контекстному меню клац-

8
нути лівою кнопкою мишки, вибрати опцію Rolename/Attribute
в меню Display Options/Entities.
Рольове ім’я необхідно обов’язково вказувати в тому разі, якщо
один і той самий атрибут, маючи однакову область значень, може
мати різну семантику. Наприклад, у структурі сутності ОБМІННІ
ОПЕРАЦІЇ, атрибут КОД ВАЛЮТИ присутній двічі. Він характе-
ризує код проданої валюти і код купленої валюти. Тобто сутність
ВАЛЮТА повинна бути зв’язана двічі із сутністю ОБМІННІ ОПЕ-
РАЦІЇ і первинний ключ КОД ВАЛЮТИ повинен два рази мігрува-
ти в підпорядковану сутність як зовнішній ключ (рис. 5.26).
Валюта Операції
Купівля
Код валюти Код валюти_Куплено (FK)
Код валюти_Продано (FK)
Назва валюти
Позначення валюти Продажа Дата операції
Сума

Рис. 5.26. Приклад обов’язковості визначення рольових імен

Другим випадком обов’язкового присвоєння рольового імені є

рекурсивний зв’язок, тобто такий зв’язок, коли одна і та ж сут-
ність виступає як батьківська і дочірня сутності одночасно. При
визначенні рекурсивного зв’язку атрибут первинного ключа по-
винен мігрувати до складу неключових атрибутів тієї самої сут-
ності. Оскільки ім’я атрибута не може дублюватись у рамках од-
нієї сутності, то йому необхідно присвоїти рольове ім’я. На рис.
5.25 сутність ВИКЛАДАЧ містить первинний ключ ТАБЕЛЬ-
НИЙ НОМЕР. Дані про завідуючого кафедрою розміщені в цій
же сутності. Щоб мати посилання на завідуючого кафедрою, не-
обхідно створити рекурсивний зв’язок і присвоїти рольове ім’я
ЗАВ. КАФЕДРОЮ. Слід відмітити, що рекурсивний зв’язок мо-
же бути лише неідентифікуючим. У противному разі зовнішній
ключ повинен війти до складу первинного ключа і отримати при
генерації ознаку NOT NULL.
Атрибути первинного ключа батьківської сутності за замовчу-
ванням мігрують зі своїми іменами в дочірню сутність. ERwin у
разі необхідності надає можливість перейменувати ці атрибути.
Така потреба може виникнути в результаті міграції первинного
ключа батьківської сутності у кілька різних за семантикою дочір-
ніх сутностей. Так, МФО банку може мігрувати з сутності, що
містить довідник банків, у різні дві дочірні сутності, в одній з
9
яких він виступатиме в ролі банка-платника, а в іншій — в ролі
банка-отримувача коштів.

Створення зв’язків між сутностями

Зв’язки між сутностями відображаються поіменовани-
ми дугами. Кожна дуга, яка ідентифікується дієсловом чи дієслі-
вною фразою (Relationship Verb Phrases), відображає логічні від-
ношення між сутностями, що мають місце в реальній предметній
області. Як окремий випадок можливий зв’язок сутності із самою
собою. Для відображення дуги імені необхідно в контекстному
меню, що з’являється, якщо клацнути мишкою по будь-якій ділян-
ці діаграми, не зайнятій об’єктами моделі, вибрати в пункті меню
Display Options/Relationship опцію Verb Phrase. За замовчуван-
ням імена зв’язків на діаграмі не вказуються.
Розрізняють залежні та незалежні сутності. Тип сутності ви-
значається її зв’язком з іншими сутностями.
В ERwin зв’язки можуть характеризуватися таким чином:
Ідентифікуючий зв’язок встановлюється між незалежною бать-
ківською сутністю та залежною дочірньою сутністю. Остання
при ідентифікуючому зв’язку є завжди залежною (рис. 5.27). При
встановленні ідентифікуючого зв’язку атрибути первинного
ключа батьківської сутності автоматично переносяться (мігру-
ють) до складу первинних атрибутів дочірньої сутності. В дочір-
ній сутності первинні ключі батьківської сутності позначаються
як вторинні літерами (FK). Екземпляри залежної сутності визна-
чаються лише через відповідні екземпляри батьківської сутності.
Тобто дані про деталь можуть бути занесеними до БД, коли у ба-
тьківській сутності буде занесена інформація про вироби, до
складу яких входить ця деталь. При генерації фізичної моделі ат-
рибути первинного ключа отримають ознаку NOT NULL.
Вибір Деталь
Код виробу Код деталі
Код виробу (FK)
Назва виробу
Модель вибору Складається Назва деталі
Собівартість деталі

Рис. 5.27. Ідентифікуючий зв’язок

При встановленні неідентифікуючого зв’язку дочірня сутність

залишається незалежною.

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

Рис. 5.28. Неідентифікуючий зв’язок

Екземпляр сутності ПРАЦІВНИК може існувати незалежно,

тобто не мати відповідного йому екземпляра у сутності ЦЕХ,
оскільки працівник може працювати на підприємстві і не бути
закріпленим за певним цехом.
Ідентифікуючий зв’язок відображається суцільною лінією, а
неідентифікуючий зв’язок — пунктирною. Лінія завершується
крапкою з боку дочірньої сутності.
Для неідентифікуючого зв’язку можна вказати характеристику
Nulls. У разі обов’язкового зв’язку (Not Null) при генерації БД ат-
рибут зовнішнього ключа отримає ознаку NOT NULL, незважаю-
чи на те, що зовнішній ключ не ввійде до первинного ключа до-
чірньої сутності. У разі необов’язкового зв’язку (Nulls Allowed)
зовнішній ключ може набувати значення Null. Необов’язковий
неідентифікуючий зв’язок позначається на діаграмі прозорим
ромбом з боку батьківської сутності.
Категоріальним зв’язком об’єднуються сутності, що нале-
жать до однієї категорії. Деякі сутності визначають цілу катего-
рію об’єктів одного типу. У такому разі створюється сутність для
визначення категорії і для кожного елемента категорії. Зв’язок,
що об’єднує такі сутності, називається категоріальним. Батьків-
ська сутність категорії називається супертипом, дочірня — під-
типом.
Наприклад, сутність ПРАЦІВНИК може вміщувати дані як про
штатних співробітників, так і співробітників, які працюють за сумі-
сництвом. Штатні співробітники і співробітники, які працюють за
сумісництвом, мають різні набори атрибутів, які часто перетина-
11
ються між собою. Спільна частина цих атрибутів, включаючи пер-
винний ключ, входить до складу сутності-супертипу ПРАЦІВНИК,
а відмінні між собою набори атрибутів (наприклад, дані про оплату
співробітників, що працюють за сумісництвом, дані про зарплату і
відпустку штатних працівників) розміщуються відповідно в сут-
ностях-підтипах: ПРАЦІВНИК.ШТАТ. Для розмежування співробі-
тників на штатних і сумісників до сутності-супертипу ПРАЦІВНИК
вводиться додатковий атрибут-дескриптор (наприклад, код ознаки
співробітника). Залежно від того, чи всі можливі сутності-підтипи
включені до моделі, категорія може бути повною чи неповною.
Повний категоріальний зв’язок (повна категорія) — це та-
кий зв’язок, коли кожному екземпляру сутності-супертипу
обов’язково відповідає певний екземпляр сутності-підтипу.
Неповний категоріальний зв’язок (неповна категорія) — це
такий зв’язок, коли певним екземплярам сутності-супертипу не-
має відповідних сутностей-підтипів наприклад, якщо сутність-
супертип ПРАЦІВНИК містить дані про звільнених співробітни-
ків та окрему ознаку, яка дозволить їх ідентифікувати, але для ці-
єї категорії співробітників не створено в моделі відповідна сут-
ність-підтип).
У ERwin повна категорія відображається колом з двома під-
креслюваннями, а неповна — колом з одним підкреслюванням.
Таким чином, зв’язок визначає сутність як залежну або неза-
лежну. Розрізняють кілька типів залежних сутностей.
 Характеристична — залежна дочірня сутність, яка зв’язана
лише з однією батьківською сутністю і за змістом зберігає інфор-
мацію про характеристики батьківської сутності.
 Асоціативна — залежна дочірня сутність, яка зв’язана з кі-
лькома батьківськими сутностями.
 Іменна — окремий випадок асоціативної сутності, яка не має
своїх власних атрибутів, а лише атрибути батьківських сутнос-
тей, що мігрували як зовнішні ключі.
Потужність зв’язку — це відношення кількості екземплярів
батьківської сутності до відповідної кількості екземплярів дочір-
ньої сутності. Для будь-якого зв’язку, окрім неспецифічного, цей
зв’язок відображається як 1 : n.
ERwin надає чотири варіанти для n, які відображаються дода-
тковим символом біля дочірньої сутності:
 нуль, один чи більше (за замовчуванням); не позначається
жодним символом;
 символом Р позначається зв’язок типу «один чи багато» (ви-
ключається нульове значення);

12
  символом Z позначається зв’язок типу «нуль чи один» (ви-
ключається багатозначність);
 цифрою позначається конкретне значення.
При моделюванні в ERwin зв’язки ідентифікують іменами.
Для зв’язку 1 : Б (ідентифікуючого чи неідентифікуючого) достат-
ньо вказати ім’я, яке характеризує відношення батьківської до
дочірньої сутності (Parent-to-Child). Для зв’язку Б:Б необхідно
вказати як ім’я Parent-to-Child, так і Child-to-Parent.
У палітрі інструментів для різного типу зв’язків використову-
ються такі кнопки:
— ідентифікуючий зв’язок;
— неідентифікуючий зв’язок;
— зв’язок «багато—до—багатьох».
Приклад відображення зв’язку «багато—до—багатьох» при
проектуванні на логічному рівні відображено на рис. 5.29.
Матеріал Виріб
Код матеріала Код виробу
Назва матеріала Назва виробу
Одиниця вимірювання Оптова ціна

Рис. 5.29. Зв’язок «багато—до—багатьох»

Приклад логічної моделі наведено на рис. 5.30.
Встановлення правил посилкової цілісності
При створенні зв’язків у закладинці Rolename/RI Actions
можна всановлювати бізнес-правила, що задають обмеження по-
силкової цілісності (referential integrity — RI) БД при виконанні
операцій вставки, заміни чи вилучення. Тобто посилкова цілісність
може контролюватись при виконанні всіх операцій, що змінюють
дані (insert, update, delete). На основі правил посилкової цілісності,
що прописуються кожному зв’язку, ERwin включає автоматичну
генерацію тригерів і механізмів декларативної посилкової цілісно-
сті (для тих СКБД, які підтримують ці механізми). Тобто при про-
ектуванні на логічному рівні можна встановити вимоги до вико-
нання операцій insert/update/ delete для батьківської та дочірньої
сутностей. ERwin надає такі варіанти обробки цих подій:
 відсутність перевірки;
 перевірка допустима;
 заборона операції;

13
  каскадне виконання операції (DELETE/UPDATE);
 установка пустого значення чи заданого значення за замов-
чуванням.
Замовник Замовлення Продукція Постачання
Код замовника Код замовлення Код продукції
Назва / ПІБ замовника Код замовлення (FK) Код продукції (FK)
Адреса замовника Код продукції (FK) Назва продукції Номер договору (FK)
Дата прийому Код виробника Код постачальника (FK)
Дата виконання Оптова ціна Дата
Кількість Min оптова партія Кількість
Ознака оплати Роздрібна ціна

Виконання Договір Виробник

Код замовлення (FK) Номер договору Код постачальника
Дата Код продукції (FK) Назва постачальника
Кількість Дата договору Адреса постачальника
Кількість МФО банка
Договірна ціна № рахунка
Телефон / Факс
Електронна адреса

Рис. 5.30. Приклад побудови логічної моделі

На рис. 5.31 показано ідентифікуючі зв’язки між сутностями

КАФЕДРА, ВИКЛАДАЧ і ПРЕДМЕТ.
Кафедра Викладач Предмет
Код кафедри Табельний номер Код предмета
Код кафедри (FK) Табельний номер (FK)
Назва кафедри Код кафедри (FK)
Телефон Прізвище
Ім’я Назва предмета
По батькові Кількість годин

Рис. 5.31. Ідентифікуючі зв’язки

Екземпляр сутності ВИКЛАДАЧ не може існувати без відпо-

відного екземпляра сутності КАФЕДРА. Отже, необхідно забо-
ронити вилучення інформації про кафедру, якщо в ній є дані хоча
б про одного викладача. Тобто інформацію про певну кафедру
можна вилучати лише після вилучення з БД інформації про всіх
викладачів, що працюють на кафедрі, чи відразу, вилучаючи ін-
формацію про кафедру, вилучити дані про всіх викладачів, що
працюють на ній. Такі правила вилучення називаються Parent
14
RESTRICT і Parent CASCADE. Слід відмітити, що сутності
ВИКЛАДАЧ і ПРЕДМЕТ, у свою чергу, зв’язані ідентифікуючим
зв’язком і якщо буде задано правило каскадного вилучення, то
при вилученні кафедри за каскадним ланцюжком буде вилучена
інформація не лише при викладачів, а й про предмети, які читає
кожен викладач. Тобто виконання команди на вилучення одного
рядка з батьківської таблиці може призвести до вилучення десят-
ків, а іноді сотень і тисяч записів з підпорядкованих таблиць. То-
му користуватись опцією Parent CASCADE слід дуже обережно,
краще використовувати опцію Parent RESTRICT. У разі вико-
ристання опції Parent RESTRICT при спробі вилучити інформа-
цію про певну кафедру, на якій є хоча б один викладач, СКБД
видасть діагностичне повідомлення про те, що вилучення даних
про кафедру неможливе з тієї причини, що цьому екземпляру за-
пису є підпорядковані екземпляри у таблиці ВИКЛАДАЧ.
На рис. 5.28 установлено необов’язковий неідентифікуючий
зв’язок між сутностями ЦЕХ і ПРАЦІВНИК. Екземпляр сутності
ПРАЦІВНИК може існувати без відповідного екземпляра сутнос-
ті ЦЕХ. У такому разі атрибут зовнішнього ключа ДЕ ПРАЦЮЄ.
КОД ЦЕХУ може набувати значення NULL. Тобто можна вико-
ристовувати правило установки в нуль — SET NULL. Тоді при
вилученні певного цеху атрибут зовнішнього ключа ДЕ ПРА-
ЦЮЄ. КОД ЦЕХУ НАБУДЕ значення нуль, тобто ПРАЦІВНИК
залишається в організації, навіть якщо не закріплений за певним
цехом.
Можливе встановлення ще двох правил вилучення за умови
підтримки їх СКБД:
 Set default — при вилученні атрибуту зовнішнього ключа
присвоюється значення за замовчуванням. Наприклад, при вилу-
ченні кафедри її викладачі будуть переведені на іншу кафедру;
 None — при вилученні значення атрибута зовнішнього
ключа не змінюється. Тобто дані про викладачів, умовно кажу-
чи, «підвисають у повітрі», оскільки посилаються на неіснуючу
вже кафедру. Така ситуація може бути характерною для файл-
серверних систем, що працюють з dbf-файлами, в яких правила
посилкової цілісності задаються у клієнтських прикладних про-
грамах.
Правила вилучення, які описані вище, управляють процеса-
ми, які відбуваються у БД при вилученні запису. Аналогічні
правила керують процесами змін чи поповнень. Наприклад, мо-
жна встановити правило, яке дозволить заносити дані про пред-

15
мети, якщо в БД записана інформація хоча б про одного викла-
дача кафедри.
ERwin автоматично присвоює кожному зв’язку значення по-
силкової цілісності за замовчуванням. Режими RI, які задаються
за замовчуванням, наведені в табл. 5.2. Ці режими у разі необхід-
ності можуть бути змінені в редакторі Referential Integrity
Defaulet, який можна викликати, клацнувши по кнопці RI
Defaults діалогу Target Server (меню Server/Target Server).
Таблиця 5.2
ЗНАЧЕННЯ RI, ЯКІ ПРИСВОЮЮТЬСЯ В ERwin ЗА ЗАМОВЧУВАННЯМ, а та-
кож можливі режими для кожного типу зв’язку

Ідентифіку- Неідентифікую- Неідентифіку- Категоріаль-

Режими чий зв’язок ючий зв’язок
ючий зв’язок (Nulls Allowed) (No Nulls) ний зв’язок

Child Delete Мож- RESTRICT, RESTRICT, RESTRICT, RESTRICT,

ливі режими CASCADE, CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL, SET DEFAULT
DEFAULT
Child Delete Ре- NONE NONE NONE NONE
жими за замовчу-
ванням
Закінчення табл. 5.2
Неідентифікую- Неідентифіку-
Режими Ідентифіку- чий зв’язок ючий зв’язок Категоріаль-
ючий зв’язок (Nulls Allowed) (No Nulls) ний зв’язок

Child Insert Мож- RESTRICT, RESTRICT, RESTRICT, RESTRICT,

ливі режими CASCADE, CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL, SET DEFAULT
DEFAULT
Child Insert Ре- RESTRICT SET NULL RESTRICT RESTRICT
жими за замовчу-
ванням
Child Update Мо- RESTRICT, RESTRICT, RESTRICT, RESTRICT,
жливі режими CASCADE, CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL, SET DEFAULT
DEFAULT
Child Update Ре- RESTRICT SET NULL RESTRICT RESTRICT
жими за замовчу-

16
ванням
Parent Delete RESTRICT, RESTRICT, RESTRICT, RESTRICT,
Можливі режими CASCADE, CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL, SET DEFAULT
DEFAULT
Parent Delete Ре- RESTRICT SET NULL RESTRICT CASCADE
жими за замовчу-
ванням
Parent Insert Мо- RESTRICT, RESTRICT, RESTRICT, RESTRICT, .
жливі режими CASCADE, CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL,SET DEFAULT
DEFAULT
Parent Insert Ре- NONE NONE NONE NONE
жими за замовчу-
ванням
Parent Update Мо- RESTRICT, RESTRICT, RESTRICT, RESTRICT,
жливі режими CASCADE; CASCADE, CASCADE, CASCADE,
NONE NONE, SET NONE, SET NONE
NULL, SET DEFAULT
DEFAULT
Parent Update Ре- RESTRICT SET NULL RESTRICT CASCADE
жими за замовчу-
ванням

17
 5.4.2.4. Фізичне проектування засобами ERwin

ERwin надає можливість вибору СКБД більше ніж з 20

реляційних і нереляційних БД. ERwin 3.5.2 дозволяє виконувати
фізичне проектування в середовищі таких найпоширеніших СКБД:
DB2/MVS 4, Informix 7.x, Ingres 1.х, ORACLE 8.х, Progress, AS/400
версії 4, InterBase, PROGRESS 8.x, SQLBase 6.x, SQL Server 7.x,
Sybase 11.x, Watcom SQL Anywhere 5, Teradata 2.x. та ін. Також
ERwin 3.5.2 надає можливість проектування у середовищі настіль-
них (desktop) СКБД: Microsoft Access, FoxPro, Clipper, dBASE III,
dBASE IV и Paradox. Крім останніх версій СКБД, ERwin 3.5.2 під-
тримує створення фізичної моделі в попередніх версіях СКБД.
Для створення фізичної структури БД може бути запрошена
генерація DDL-скрипта (data definition language). При цьому ви-
користовується діалект SQL для вибраного типу і версії сервера.
Хоча згенерований код не потребує модифікації, є можливість
його зберегти у файлі чи роздрукувати.
ERwin підтримує найпоширеніші засоби розробки 4GL, такі
як: PowerBuilder фірми Powersoft, SQL Windows фірми Gupta,
Visual Basic фірми Microsoft, Oracle*CASE фірми Oracle.
Фізичне проектування ЕRwin може бути представлено двома
рівнями:
 трансформаційна модель (Transformation Model);
 модель СКБД (DBMS Model).
Трансформаційна модель описує модель предметної області
чи її певну підмножину. ERwin підтримує ведення окремих проек-
тів, дозволяючи проектувальнику виокремити певні підмножини
моделі у вигляді предметних областей (Subjeсt Area).
Модель СКБД автоматично генерується з трансформаційної
моделі (діалогове вікно вибору СКБД наведено на рис. 5.32). Для
вибору СКБД використовується меню Server: викликається реда-
ктор Target Server та активізується кнопка навпроти обраної
СКБД.
У згенеровану БД можна вносити вручну ряд змін: у діалозі
Target Server задавати типи даних та опції NULL для нових ко-
лонок, а також правила посилкової цілісності, які визначаються
за замовчуванням. Тип даних можна вибрати зі списку Default
Datatype, який автоматично заповнюється типами даних, які під-
тримує вибрана СКБД. Посилкова цілісність визначається згідно
з правилами, наведеними в табл. 5.2. Задавати правила посилко-
вої цілісності можна у вікні (рис. 5.33) після натиснення кнопки
RI Defaults. Після вибору СКБД ERwin автоматично генерує

1
імена таблиць та індекси за шаблонами логічної моделі. Але та-
кож можна змінювати ці імена у разі потреби вручну. Вікна Table
Name Macro і Index Name Macro дозволяють внести ці зміни.

Рис. 5.32. Вікно для вибору СКБД

Рис. 5.33. Вікно визначення правил посилкової цілісності

2
 За допомогою кнопки Reset Names викликається вікно Globally
Rest DBMS Property (рис. 5.34), яке надає можливість поверну-
тись назад, тобто імена, які встановлювались вручну, будуть за-
мінені на імена за замовчуванням, що були визначені при проек-
туванні на логічному рівні. Якщо в імені сутності чи атрибуту
будуть пробіли, то вони автоматично замінюються на символ «_».

Рис. 5.34. Вікно для редагування таблиць

За допомогою кнопок Default Non-Key Null Option можна до-

зволяти чи забороняти значення Null для неключових стовпчиків.
У вікні можна встановити дозвіл чи заборону на використання
спеціальних символів і пробілів в іменах таблиць. Ця опція діє лише
на ті СКБД, які підтримують використання спеціальних символів.
Редагувати таблиці можна у редакторі таблиць та редакторі
стовпчиків. Ці редактори викликаються шляхом активізації від-
повідної опції у меню, яке з’являється, коли клацнути правою
кнопкою мишки по таблиці (вікно редактора таблиць Table
Editor наведено на рис. 5.35). У цьому вікні можна задавати вла-
стивості таблиці, які є відмінними від властивостей за замовчу-
ванням (синоніми, правила валідації, процедури і т. п.). Правила
валідації задають список допустимих значень для атрибутів і/чи
3
правила перевірки допустимих значень. Значення за замовчуван-
ням — це значення, яке буде автоматично вводитись у стовпчик,
якщо якесь інше значення не буде введене вручну. Редактор
Table Editor містить такі закладинки (рис. 5.36).

Рис. 5.35. Вікно редактора таблиць

Рис. 5.36. Закладинки редактора таблиць

Характеризуємо ці закладинки:
 Comment — коментарі до таблиці;
 Volumetrics — оцінка розміру БД;
 Physical Property — задання фізичних властивостей таблиці;
 Partitions — задання значення розділення. Доступна лише
для Oracle 8.x;

4
  UDP — задання властивостей, що визначаються користувачем;
 Validation — визначення правил валідації;
 Stored Procedure — зв’язування з таблицею процедур, що
зберігаються;
 Pre & Post Script — створення скриптів (наборів команд), які
будуть виконуватись до і після створення таблиць при генерації БД;
 Synonym — визначення синонімів таблиць, якщо вони під-
тримуються сервером;
 PowerBuilder — задання розширених атрибутів для генерації
клієнтського додатка на PowerBilder.
Для задання характеристик стовпчиків, відмінних від значень
за замовчуванням, використовується редактор стовпчиків Column
Editor (рис. 5.37), який подібний до редактора атрибутів моделі
логічного рівня. Вікно та режими редагування редактора таблиць
і стовпчиків залежить від вибраної СКБД.

Рис. 5.37. Вікно редактора стовпчиків

У редакторі стовпчиків при активізації закладинки, що відпо-

відає СКБД Access, можна задавати тип даних, керувати опцією
Null, задавати правила валідації і значення за замовчуванням.
Активізувавши закладинку Access, можна задавати формат та ма-
ску для відповідного стовпчика (приклад фізичної моделі бази
даних наведено на рис. 5.38).
5
 Замовлення
Код замовлення:Integer
Код продукції: Integer
Код замовника: Integer
Дата прийому: Date/Time
Дата виконання: Date/Time
Кількість: Integer
Ознака оплати: Yes/No
Продукція Постачання
Код продукції: Integer Код продукції: Integer
Код постачальника: Integer
Назва продукції: Text(18) Номер договору: Integer
Код виробника: Integer
Min оптова партія: Currency
Роздрібна ціна: Currency Дата: Date/Time
Кількість: Integer

Замовник
Договір
Код замовника: Integer
Номер договору: Integer
Назва/ПІБ замовника: Text(18) Код продукції: Integer Постачальник
Адреса замовника: Text(18) Код постачальника: Integer Код простачальника: Integer
Дата договору: Date/Time Назва постачальника: Text(18)
Кількість: Integer
Договірна ціна: Currency Адреса постачальника Text(18)
Виконання МФО банка: Integer
№ рахунка: Double
Код продукції: Integer Телефон/факс: Text(18)
Код замовника: Integer Електронна адреса: Text(18)
Код замовлення: Integer
Дата: Date/Time
Кількість: Integer

Рис. 5.38. Фізична модель бази даних

При зміні СКБД ERwin пропонує автоматично перетворити

типи даних атрибутів на доступні для вибраної СКБД. Для авто-
матичного перетворення досить надати стверджувальну відповідь
на відповідний запит.
ERwin має власну макромову для підготовки прототипів три-
герів і процедур. Схема використання прототипів полягає в під-
готовці шаблону для різних типів тригерів (наприклад, тригер,
який реалізує логіку каскадного вилучення, — ON DELETE
CASCADE). Базові шаблони вбудовані в ERwin, але користувач
може визначити власні шаблони і використати їх замість стан-
дартних. Макромова шаблонів реалізует велику кількість мак-
росимволів, що посилаються на різні об’єкти бази даних, на-
приклад:
%Action — розширяється в UPDATE/INSERT/DELETE;
%ForEachAtt(<таблиця>, <разділювач>) { <код макрокоман-
ди> } — циклічне виконання групи операторів над кожним атри-
бутом таблиці;
%ForEachEntity() { } — циклічне виконання функцій над усіма
таблицями;
%If, %else — оператори умовного управління. Наприклад,
шаблон тригера для реализації підтримки on delete cascade:
%Action /* ERwin Builtin %Datetime */

6
 /* %Parent %VerbPhrase %Child ON PARENT DELETE
CASCADE */
delete %Child
from %Child,deleted

where
/* %%JoinFKPK(%Child,deleted,« = »,« and») */
%JoinFKPK(%Child,deleted,« = »,« and»)

Усі макрофункції, які можуть використовуватись у тригерах,

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

Питання для самоперевірки

1. Дайте визначення CASE-технології та охарактеризуйте

області її застосування.
2. За якими ознаками можна класифікувати CASE-засоби?
3. Викладіть сутність методології даних ERD.
4. Викладіть сутність методології даних IDEF1.
5. Охарактеризуйте функціональні можливості CASE-
засобу S-Designor.
6. Які типи зв’язків між даними підтримує S-Designor?
7. Викладіть порядок інформаційного моделювання в S-
Designor.
8. Охарактеризуйте функціональні можливості CASE-
засобу ERwin.
9. Які типи зв’язків між даними підтримує ERwin?
10. Викладіть порядок інформаційного моделювання в ERwin.

7
 6 Pоздiл
CТВОРЕННЯ ТА РОБОТА З БАЗОЮ ДАНИХ У
СЕРЕДОВИЩІ СКБД MICROSOFT ACCESS

6.1. Характеристика СКБД Microsoft Access

СКБД Microsoft Access 97 підтримує 32-розрядну реля-

ційну модель БД. Вона призначена для створення як локальних
(настільних) БД, так і потужних мережевих додатків, що працю-
ють за технологією клієнт-сервер. Структура БД Access унікальна.
ВAccess усі відомості, що стосуються певної предметної області,
всі таблиці, форми, запити, звіти, макроси та модулі на фізично-
му рівні зберігаються в одному файлі з розширенням .MDB. Та-
ким чином, база даних у середовищі Access — це сукупність
пов’язаних між собою таблиць, які належать до однієї теми чи
предметної області та інструментальних засобів для роботи з ними.
В Access є таке поняття як об’єкт. У базі даних основними
об’єктами є таблиці, запити, форми, звіти, макроси та модулі.
Таблиця — це поіменоване реляційне відношення, яке зберігає
дані про якусь певну сутність предметної області.
Запит — це об’єкт, за допомогою якого можна отримати не-
обхідні дані з однієї чи кількох таблиць. За допомогою запитів
можна зробити вибірку, вилучення чи поповнення даних, а також
створити нові таблиці на базі вже існуючих.
Форма — це об’єкт, який використовується в основному для
завантаження даних, відображення їх на екрані та для управління
роботою додатків. Форми також можна використовувати для за-
пуску макросів чи процедур.
Звіт — це об’єкт, що вміщує результати обробки однієї, кіль-
кох таблиць чи запитів і може бути виданий на друк чи підклю-
чений до документів інших додатків.
Макрос — це об’єкт, що являє собою структурований опис у
вигляді макрокоманд однієї чи кількох дій, які необхідно автома-
тично виконати за певних умов. У вигляді макросів описуються
певні дії, які досить часто повторюються.
Модуль — це програми на Microsoft Access Basic, які можуть
бути прив’язані до окремих форм чи звітів і виконувати дії при

135
виникненні в них певних змін. В Access виокремлюється таке по-
няття, як подія, що визначає будь-яку зміну стану об’єктів.
СКБД Access працює з вікнами. Тут є довідкова система, за
допомогою якої можна отримати різну інформацію про поточну
робочу ситуацію, що висвічується у довідковому рядку. Однак,
якщо цієї інформації недостатньо, то, натиснувши клавішу F1, на
екрані автоматично відтвориться текст довідки, що відповідає
поточній робочій ситуації. Довідки, що видаються в Access, згру-
повані за темами і предметними рубриками. Це дозволяє знаходи-
ти ті теми і рубрики, які цікавлять користувача в даний момент.
Access є сучасним додатком Windows-95, тому вона дозволяє
використовувати всі можливості DDE-динамічного обміну дани-
ми (Dynamic Data Exchance), а також виконувати зв’язок та
включення OLE об’єктів (Object Linking and Embedding). DDE до-
зволяє виконувати обмін даними між Access та іншими засобами
Windows, які підтримують DDE. За допомогою OLE об’єктів мо-
жна виконувати зв’язок з іншими продуктами Windows, а також
включати в Access такі об’єкти, як картини, діаграми чи докуме-
нти з інших продуктів Windows, які підтримують OLE об’єкти.
В Access можливий імпорт/експорт даних з інших СКБД
(dBASEIII, dBASEIV, FoxPro, Paradox, BTrievе), програм елект-
ронних таблиць Exсel, Lotus, текстових файлів. Також інформа-
цію з бази даних у середовищі Access можна експортувати в ці ж
системи.
Access також може працювати з найпопулярнішими базами
даних, такими як Oracle, Microsoft SQL Server, DB-2 та іншими,
які підтримують стандарт ODBC (Open Database Connectivity —
відкритий доступ до даних).
Access має в своєму арсеналі деякі засоби захисту інформації.
В меню Access є спеціальні команда для відновлення БД. Якщо за
допомогою цієї команди не вдалося відновити втрачені дані, то
необхідно використовувати останню страхову (резервну) копію.
Відновити базу даних за допомогою спеціальної команди меню
Access вдається без резервної копії в тих випадках, якщо дані бу-
ли пошкоджені в результаті незапланованої зупинки Access (на-
приклад, через зависання системи).
В Access є можливість стискати дані для зменшення ємності
пам’яті та підвищення швидкості роботи системи. При вилученні
записів з таблиць вони фізично не знищуються, а лише відповідним
чином позначаються. Нові записи розташовуються в кінці таблиці.
В результаті такої організації через певний час у таблиці може деяка
частина записів мати відповідні позначення про їх вилучення. Ці за-

136
писи не братимуть участі в процесах обробки, а розмір таблиці буде
невиправдано великим. Тому з певною періодичністю адміністратор
повинен виконувати процедуру стискання, в результаті якої таблиця
реорганізується і з неї вилучаються всі позначені записи.
Access має засоби адміністрування бази даних і захисту її від
несанкціонованого доступу, зокрема такий інструмент, як шиф-
рування даних, котрий доцільно використовувати при транспор-
туванні бази даних по мережі. Шифрування даних захищає їх від
інших програм і дозволяє перегляд лише в середовищі Access.
Останній розпізнає зашифровані дані та автоматично виконує їх
дешифрування.
Access підтримує автоматизоване ведення словника даних,
який вміщує детальний опис усієї бази даних. Ця компонента
Access називається архіваріусом.
В арсеналі СКБД Access — мови запитів SQL та QBE. Версія
мови SQL тут носить назву Jet SQL. Мова запитів QBE (qubery-by-
example) — є графічною мовою реалізації запитів за зразком у
режимі конструктора. Access дозволяє конвертувати запити QBE
в SQL-запити. Крім того, Access підтримує мову Visual Basic for
Applications (VBA). VBA — це мова програмування, за допомо-
гою якої користувач має можливість створювати модулі, що роз-
ширяють стандартні можливості системи.
Додатки Access-97 можуть безпосередньо взаємодіяти з доку-
ментами, розташованими в World Wide Web.
Деякі обмеження Access-97:
 розмір бази даних (файла з розширенням .mdb) — 1 Гбайт.
Реально розмір обмежується обсягами пам’яті на диску, оскільки
до БД можна приєднувати таблиці;
 число об’єктів у БД — 32 768;
 кількість користувачів, що одночасно працюють із систе-
мою, — 255;
 максимальний розмір таблиці — 1 Гбайт;
 максимальна кількість полів у таблиці — 255;
 максимальна кількість індексів у таблиці — 32;
 максимальна кількість символів у записі (не враховуючи
Memo і OLE-об’єкти) — 2000;
 максимальна кількість символів в Memo-полі — 65 535;
 максимальний розмір OLE-об’єкта — 1 Гбайт;
 максимальна кількість таблиць у запиті — 32.
Таким чином, розглянута СКБД має розвинутий арсенал су-
часних технологічних засобів, які дозволяють виконувати проце-
дури проектування, створення і ведення баз даних.

137
 6.2. Типи даних в ACCESS

У Access можуть підтримуватися поля різних типів, які

наведені в табл. 6.1.
Кожне поле може мати певний розмір, що визначає його мак-
симальну довжину чи діапазон чисел.
Таблиця 6.1
ТИПИ ДАНИХ

Тип даних Розмір Зміст Обмеження

Лічильник 4 байти Число, яке автоматично Для кожної таблиці

збільшується на одини- може бути тільки
цю для кожного нового одне таке поле
запису
Грошовий 8 байт Число, яке відображає
суму грошей з двома
знаками після коми
Дата/час 8 байт Дати або час
Memo-поле До 64 000 байт Довгий текст Не може використо-
вуватись як індекс
таблиці
Числовий Від 1 до 8 байт Число
OLE-об’єкт До 1 ГБ Об’єкт OLE, включаю- Не може використо-
чи графіки, рисунки та вуватись як індекс
двійкові об’єкти таблиці
Логічний 1 байт Істина чи хибність (True Значення «так» чи
або False) «ні»
Текстовий До 255 байт Короткий текст

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

вибрати одне з п’яти наступних значень (табл. 6.2). Усі текстові
поля за замовчуванням установлюються такими, що дорівнюють
50 символам. Тому, якщо поле має більшу довжину, то необхідно
її задавати відповідним чином.
В Access є два поняття: формат і маска вводу даних. Формат
впливає на відображення даних після їх завантаження. Напри-
клад, якщо встановити формат поля, яке вміщує дату, таким, що
дорівнює «довгому формату дати», то 16.06.96 відобразиться як
«неділя, 16 червня 1996».
138
 Таблиця 6.2
РОЗМІРИ ПОЛІВ

Тип поля Діапазон поля Розмір поля

в байтах
Байт (Byte) від 0 до 255 1
З плаваючою крапкою Від — 3,402823E38 до — 1,401298Е-45 для
звичайної точності від’ємних значень 4
(Single) Від 1,401298 Е-45 до 3,402823 E38 для додатних
значень
З плаваючою крапкою Від — 1,79769313486232E308 до —
подвійної точності 4,94065645841247Е-324 для від’ємних значень 8
(Double) Від 4,94065645841247 Е-324 до
1,79769313486232E308 для додатних значень
Ціле (Integer) Від — 32768 до 32768 2
Грошовий (Currency) Від — 922337203685477,5808 до 8
922337203685477,5807
Довге ціле (Long) Від — 2147483648 до 2147483647 4

Маска вводу обмежує тип інформації, яку можна ввести в по-

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

6.3. Створення бази даних

Таблиця — це основа будь-якої бази даних. Access теж
зберігає дані у таблицях. Для створення бази даних необхідно за-
пустити Access.
Після запуску СКБД на екрані з’явиться командний рядок го-
ловного меню. Перш ніж виконати будь-які дії, необхідно ство-
рити нову чи відкрити існуючу базу даних.
Для створення бази даних необхідно:

139
 1. З меню вибрати команду Файл, вибрати опцію Cоздать ба-
зу данных чи натиснути кнопку із зображенням бланка на панелі
інструментів. Access відобразить вікно, наведене на рис. 6.1. Вік-
но має дві вкладинки Общие і База данных. Перша вкладинка
вміщує піктограму Новая база данных, друга — піктограми 22
стандартних шаблонів, одним з яких можна скористатися при
створенні бази даних.

Рис. 6.1. Діалогове вікно для створення бази даних

2. Якщо створюється унікальна база даних, то вибираємо пік-

тограму Новая база данных і тиснемо на кнопку OK. Після чого
відкриється діалогове вікно Файл новой базы данных (рис. 6.2), в
якому необхідно вказати ім’я файла нової бази даних та визначи-
ти шлях, на якому диску і в якій папці вона зберігатиметься. За
замовчуванням Access присвоює новій базі даних ім’я db1, якщо
таке ім’я уже існує, то db2 і т. п.
Ім’я нової бази даних може вміщувати не більше 255 симво-
лів і не повинно включати пробіли. Після введення ім’я тиснемо
кнопку OK, Access створює порожню базу даних, додавши авто-
матично до неї розширення .mdb.
У полі Тип файла можна задати тип файла, які відобража-
ються у списку вибраної папки. При виборі опції Все папки від-
творяться лише імена файлів, що мають розширення .mdb, тобто

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

Рис. 6.2. Діалогове вікно для створення файла бази даних

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

6.4. Таблиці в ACCESS

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

Отже, підкреслимо ще раз: таблиця — це основа бази

даних, де зберігаються дані про один інформаційний об’єкт
предметної області. База даних Access може вміщувати не більше
32768 таблиць, одночасно відкритими можуть бути 255 таблиць.
141
 Для створення таблиці в Access необхідно виконати такі дії:
У вікні відкритої бази даних вибрати вкладку Таблицы і на-
тиснути на кнопку Создать.
Вибрати у списку діалогового вікна Новая таблица (рис. 6.3)
режим (спосіб) створення таблиці. Access надає такі способи
створення таблиць:
Режим таблицы — створення таблиць у режимі таблиці надає
можливість на базі абстрактної таблиці створювати нову, напов-
нюючи її конкретним змістом;
Конструктор — створення таблиць за допомогою конструк-
тора таблиць;
Мастер таблиц — створення таблиць за допомогою майстра
таблиць. У цьому режимі надаються заготовки таблиць, з яких
користувач вибирає необхідну;
Импорт таблиц — створення таблиць шляхом імпорту із зов-
нішнього файла чи іншої бази даних.
Найзручнішим при створенні нових таблиць є спосіб, який на-
дає Конструктор. Вибираємо цей режим і тиснемо на кнопку
ОК, на екрані з’явиться вікно, в якому створюємо структуру но-
вої таблиці.

Рис. 6.3. Діалогове вікно режимів створення таблиць

При створенні структури таблиці виконуються такі кроки:

Визначення імені поля. В колонці Имя поля задається ім’я по-
ля, довжина якого не повинна перевищувати 64 символа і має
вміщувати будь-які спеціальні символи, крім крапок, окличних
знаків і вуглових дужок. Усередині таблиці можна призначати
лише унікальні ім’я. Після того, як ім’я поля введено, необхідно
натиснути клавішу Enter.
142
 Визначення типу даних. Після введення імені поля Access ак-
тивізує введення типу даних. У колонці Тип данных вибира-
ється Тип данных із списка, представленого на рис. 6.4. В цьо-
му списку є такий елемент, як Мастер подстановок, що
дозволяє представляти значення полів у вигляді простого чи
комбінованого списку. Додаткові властивості цього поля нада-
ються на вкладинці Подстановка конструктора таблиць. Виб-
равши тип даних, тиснемо на клавішу Enter і переходимо на
опис даних.
Опис даних. Заповнення колонки Описание необов’язкове. До
нього можна занести довільний коментар, який стосується ство-
реного поля. Типовим коментарем може бути опис призначення
поля.
Ця колонка може вміщувати коментарі, які детальніше харак-
теризують те чи інше поле.

Рис. 6.4. Список типів даних

Визначення параметрів поля. Крім імені, типу та опису поля

необхідно встановити характеристики поля. Характеристика
поля відображає його розмір, формат та деякі індивідуальні
властивості, які повинні враховуватись при занесенні даних у
таблиці та при їх модифікації. Властивості полів відображу-
ються у нижній частині діалогового вікна (їх опис представле-
ний в табл. 6.3).
143
 Таблиця 6.3
ОПИС ВЛАСТИВОСТЕЙ ПОЛІВ

Властивості Зміст
Визначає максимальну довжину текстового або числово-
Розмір поля
го поля
Визначає формат відображення даних у формі та запиті.
Формат поля Формат може бути: стандартний, числа, валютний, фіксо-
ваний з виділенням тисяч, процентний, експоненціальний
Число десятко- Визначає кількість розрядів в дробовій частині десятко-
вих знаків вого числа
Маска вводу Задає маску даних при введенні даних
Вміщує надпис, який виводиться поруч з полем у формі
Підпис чи звіті (цей підпис може не збігатися з іменем поля, як
правило, він пояснюючий до змісту поля)
Значення за за- Вміщує значення, яке встановлюється за замовчуванням
мовчуванням для відповідного поля таблиці
Умова на зна- Визначає множину значень, яких може набувати те чи
чення інше поле
Повідомлення Задає повідомлення, яке видається на екран при введенні
про помилку недопустимого значення
Обов’язкове Цей параметр вказує на те, що при заповненні таблиці це
поле поле повинно обов’язково бути заповненим
Параметр визначає, чи можливе введення пустих рядків у
Пусті рядки
дане поле
Визначає прості індекси для прискорення пошуку, вка-
завши наявність чи відсутність елементів дублювання.
Індексне поле
Поле первинного ключа визначається як індексне авто-
матично

Слід пам’ятати, що властивості полів описаними вище пара-

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

144
 Після того як робота завершена, необхідно вибрати в меню
Файл режим Сохранить, ввести ім’я таблиці і натиснути OK.
Якщо при створенні таблиці не було задано ключа, то при за-
критті таблиці Access запропонує зробити це. Коли буде вибрана
стверджувальна відповідь, то в таблицю автоматично додається
поле лічильника, якому буде присвоєна ознака ключового поля.
При від’ємній відповіді первинний ключ не створюється.
Таблицю можна в будь-який момент перейменувати. Для цьо-
го необхідно її маркірувати в списку об’єктів бази даних і викли-
кати команду Переименовать з меню Правка.
Таблиці, що створюються, повинні бути представленими у но-
рмалізованому вигляді. Якщо таблиці не нормалізовані, то приве-
сти їх у відповідність вимогам теорії нормалізації можна за до-
помогою опції Анализ меню Сервис.

6.4.2. Редагування структури таблиці

Редагування створеної таблиці виконується в режимі

конструктора. Це виконується таким чином:
1. Відкривається база даних, в якій знаходиться необхідна таб-
лиця, на її ім’я встановлюється курсор і вибирається опція Конс-
труктор.
2. У цьому режимі можна змінювати існуючі поля таблиці та
їх характеристики, додавати нові поля. Якщо таблиця вже вміщує
певні дані, то при зміні її структури вони губляться лише у ви-
ключних випадках, про що Access повідомляє відповідним чином.
Вставити нове поле можна, встановивши курсор у рядку, пе-
ред яким повинен бути введений новий рядок, і натиснути відпо-
відну кнопку на панелі інструментів або викликати команду
Строки чи Поле подстановок із меню Вставка. Якщо з таблиці
необхідно вилучити поле чи кілька полів, то відповідний рядок
чи рядки позначаються курсором і вибирається команда Удалить
строки з меню Правка.
Слід пам’ятати: якщо таблиця уже заповнена даними, то при
вилученні поля втрачаються відповідні дані.
Відмінити помилкове вилучення поля можна таким чином:
 натиснути кнопку Нет у вікні, що попереджає про вилучен-
ня даних;
 вибрати команду Отменить удаление з меню Правка. Це
можливе лише відразу після виконання операції вилучення;
145
  закрити вікно таблиці і натиснути кнопку Нет в діалоговому
вікні запиту про необхідність збереження змін. У такому разі всі
зміни, проведені після останньої процедури збереження, втратяться.
Вилучити всю таблицю з бази даних можна в режимі Правка
головного меню командою Удалить.

6.4.3. Введення, редагування та вилучення за-

писів із таблиці

Перш ніж ввести новий запис, провести певні зміни іс-

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

146
 6.4.4. Пошук даних

Для виконання пошуку в таблиці необхідно перейти в

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

Рис. 6.5. Вікно для задання зразка для пошуку

У полі Совпадение можна задати параметр Поле полностью.

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

6.4.5. Створення індексів

Для прискорення пошуку необхідних даних при роботі

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

147
внутрішню таблицю з двох стовпчиків, яка вміщує значення
ключів індексації та відповідну адресу кожного запису в таблиці,
для якої встановлюється індекс.
Створити індекс по одному полю досить просто. Для цього не-
обхідно відкрити таблицю в режимі конструктора і визначити по-
ле, яке буде ключем індексації, потім клацнути мишкою на харак-
теристиці поля Индексированное поле, яка розташована в нижній
частині вікна таблиці. Розглянемо створення індексу по одному
полю на прикладі таблиці договір на постачання матеріалів
(Docow). Первинним ключем, тобто унікальним полем, буде номер
договору на постачання, а індексним полем — код постачальника
(рис. 6.6). При цьому залежно від даних, які зберігаються в табли-
ці, можна вибрати одну з двох опцій: допускається збіг чи не до-
пускається збіг значення індексного поля. Для прикладу, що роз-
глядається, доцільно вибрати характеристику, яка допускає збіг
індексного поля, оскільки з одним і тим самим постачальником
може бути укладено кілька договорів на постачання матеріалів.

Рис. 6.6. Використання характеристики «Індексоване поле» для ство-

рення індекса по одному полю

Для створення індексу по кількох полях необхідно відкрити

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

148
дньому кроці (рис. 6.6). Для встановлення складового індексу не-
обхідно ввести ім’я наступних полів у пусті рядки.
Наприклад, для таблиці Docow створимо індекс, який склада-
тиметься із трьох полів — k_post, data і k_mat. Для цього необхід-
но, встановивши курсор на пустих рядках, занести туди ім’я полів
data і k_mat в стовпчики Индекс і Поле вікна Индексы, користу-
ючись списком полів, яке видасть у допоміжному вікні Access. Діа-
логове вікно Индексы після цього матиме такий вигляд (рис. 6.7).
Для вилучення певного індексного поля досить встановити
курсор в області маркірування поля та натиснути клавішу Del.
Access використовує складові індекси навіть у тих випадках,
коли пошук виконується лише по певних його полях. Таким чином
пошук можна виконувати по коду постачальника, коду постачаль-
ника і даті, а також коду постачальника, даті і коду матеріалу.

Рис. 6.7. Створення складового індексу

Також система може використовувати складовий індекс у тих

випадках, якщо пошук виконується послідовно по полях індексу,
починаючи з першого поля.
Існують певні обмеження на використання складових індексів
Access:
1. При визначенні умови пошуку не можна робити пропуски
полів у складовому індексі, тобто не можна виконувати пошук
лише по полях «код постачальника та код матеріалу», пропусти-
вши дату.
2. Якщо задана умова включає нерівність, то вона може вико-
ристовуватись лише для останнього ключа умови пошуку. Не до-
пускається, наприклад, така умова, як:
k_post=100 AND data>=31.12.96 AND k_mat=100256,
оскільки задана умова у вигляді нерівності для поля data, яке не є
останнім у даній умові. Для даного прикладу умова пошуку у ви-
гляді нерівності може бути задана для поля k_mat. Умова k_post
< 100 допускається.
При створенні індексів необхідно враховувати те, що таблиця
в Access не може мати понад 32 індексів.

149
 6.4.6. Встановлення зв’язку між таблицями

Після того як створені структури файлів, перш ніж за-

повнювати їх конкретними даними необхідно побудувати логічну
модель БД. Тобто необхідно встановити зв’язки між таблицями,
які потім при завантаженні виконуватимуть перевірку щодо уз-
годженості даних і збереження посилкової цілісності. Коли між
таблицями бази даних встановлені зв’язки, то Access автоматич-
но перевіряє та забезпечує цілісність бази даних.
Для створення зв’язку необхідно, щоб у головній таблиці
були визначені первинні ключі. Встановлення первинного клю-
ча для зв’язаної (підпорядкованої) таблиці не є обов’язковою
умовою. Для підпорядкованої таблиці необхідно визначити
поле вторинного ключа, тип даних і розмір якого повинні збі-
гатися з полем первинного ключа головної таблиці. Імена по-
лів первинного та вторинного ключів, між якими встановлю-
ється зв’язок, можуть не збігатися. Вторинні ключі
відрізняються від первинних тим, що для них допускається ду-
блювання значень.
Розглянемо встановлення зв’язку на прикладі двох таблиць.
Нехай головна таблиця Виріб вміщує інформацію про продукцію,
яка випускається на підприємстві, та її собівартість, а зв’язана з
нею підпорядкована таблиця Реалізація відображає дані про про-
даж цієї продукції різним споживачам протягом місяця. Поле Код
виробу в головній таблиці є первинним ключем, оскільки один і
той же виріб не може повторюватись у довіднику виробів, тобто
значення поля є унікальним (це саме поле у підпорядкованій таб-
лиці є вторинним ключем, тому що може дублюватись, а одна й
та ж продукція може бути реалізована в різні календарні періоди
та різним споживачам).
Після того, як визначені ключі, можна встановлювати зв’язок.
Для цього необхідно закрити вікна обох таблиць і з рядка меню
вибрати в меню Сервис команду Схема данных. На екрані
з’явиться вікно Добавление таблицы (рис. 6.8).
Позначте таблицю Виріб і натисніть кнопку Добавить. Таку
ж процедуру виконайте для таблиці Реалізація і клацніть миш-
кою по кнопці Закрыть. На екрані з’явиться вікно Схема дан-
ных, в якому будуть відображені таблиці, між якими встанов-
люється зв’язок. Якщо якоїсь таблиці не вистачає на полі вікна
Схема данных, то додавати її можна, клацнувши правою кноп-
кою миші.
150
 Рис. 6.8. Вікно для вибору таблиці
Для побудови зв’язку необхідно визначити головну (первин-
ну) та підпорядковану таблиці. Головною таблицею, з якої вихо-
дитиме дуга, буде таблиця, що містить первинний ключ, підпо-
рядкованою таблицею — таблиця зі вторинним ключем.
Унашому прикладі головною є таблиця Виріб, а підпорядкова-
ною— Реалізація. Для встановлення зв’язку між таблицями поле
Код виробу з таблиці Виріб мишкою перетягуємо в поле з таким
же ім’ям таблиці Реалізація. З’явиться вікно Связи для встанов-
лення параметрів зв’язку (рис. 6.9).

Рис. 6.9. Вікно для встановлення зв’язку

151
 У вікні Связи необхідно активізувати опцію Обеспечение це-
лостности данных і натиснути кнопку Создать. Опції Каскадное
обновление связанных полей, Каскадное удаление связанных
записей не є обов’язковими при побудові логічної моделі даних.
Встановлення опції Обеспечение целостности данных забезпе-
чує автоматичну перевірку посилкової цілісності між даними, тобто
відповідності значень між первинними і вторинними ключами.
Опція Каскадное обновление связанных полей забезпечує ці-
лісність даних при внесенні змін. Якщо вноситиметься нове зна-
чення вторинного ключа підпорядкованої таблиці і при цьому не
буде знайдено відповідне значення первинного ключа у зв’язаній
таблиці, така зміна не буде санкціонована, оскільки вона призведе
до порушення узгодженості між даними. Якщо ж буде виконана
заміна значення поля первинного ключа, то ці зміни будуть продуб-
льовані з полем вторинного ключа підпорядкованої таблиці.
Опція Каскадное удаление связанных записей дозволяє при
вилученні запису з головної таблиці автоматично виконувати кас-
кадне вилучення тих записів з підпорядкованих таблиць, значення
вторинного ключа яких збігається зі значенням первинного ключа.
Опції Каскадное обновление связанных полей, Каскадное
удаление связанных записей доцільно встановлювати лише пе-
ред внесенням змін до БД. Після виконання змін ці опції краще
знімати, щоб випадково не виконати вилучення чи поновлення
потрібних записів і полів.
Після визначення умов цілісності бази даних тиснемо на кно-
пку Объединение.
З’явиться вікно Параметры объединения, в якому можна ви-
брати один з трьох наступних (рис. 6.10):

Рис. 6.10. Вікно визначення параметрів об’єднання

152
 Перший параметр, що задається за замовчуванням, створює так
зване внутрішнє об’єднання на основі рівності первинного та вто-
ринного ключів таблиць, що зв’язуються. Вікно зі зв’язаними таб-
лицями за умови рівності первинного і вторинного ключів предста-
влено на рис. 6.11. СКБД автоматично визначає тип зв’язку, як 1:Б.

Рис. 6.11. Внутрішнє об’єднання таблиць

Якщо зв’язок виконується між полями, які є первинними клю-

чами, система встановлює зв’язок 1:1.
Слід пам’ятати про те, що якщо при створенні відношень між
таблицями використовується лічильник, то інше поле, яке з ним
зв’язується, повинно бути числовим з форматом довге ціле.
Редагувати отриманий зв’язок можна відмітивши його миш-
кою, а вилучити клавішею Del. У цьому ж режимі можна побуду-
вати новий зв’язок за допомогою мишки, як це робилося в попе-
редньому випадку.
Якщо схема побудована правильно, то роздрукувати її можна
за допомогою опції Печать описания з команди меню Файл. За-
вантаження таблиць конкретними даними слід виконувати лише
після створення схеми. Насамперед завантажуються таблиці-
довідники, що не мають вхідних дуг, потім ті таблиці, що мають
зв’язки з цими довідниками, і т. д.
Внутрішнє об’єднання — це найбільш поширений тип зв’язку
між таблицями БД. Крім нього, можна створювати ще три типи
об’єднань: зовнішнє об’єднання, самооб’єднання і тета-об’єднання.
Створення зовнішнього об’єднання. Зовнішнє об’єднання до-
зволяє відображати в запиті поля всі записи таблиць незалежно
від збігу значень ключових полів. Зовнішнє об’єднання буває лі-
вим та правим:
 Ліве зовнішнє об’єднання поєднує всі записи головної таб-
лиці з унікальним ключовим полем незалежно від того, чи є в
зв’язаних полях підпорядкованої таблиці співпадаючі значення.
153
При створенні лівого зовнішнього об’єднання користуються па-
раметром № 2 об’єднання таблиць (рис. 6.11).
Розглянемо приклад лівого зовнішнього об’єднання на прикладі
двох таблиць: Залишок (Код виробу, Код складу, Дата, Залишок),
Видатки (Код виробу, Код складу, Дата, Видано) (рис.6.12). Поле
Код виробу таблиці Залишок є первинним ключем, оскільки на
один і той самий виріб може бути представленим у залишках лише
один раз, тобто є унікальним. Поле Код виробу в таблиці Видатки є
полем вторинного ключа, тобто може дублюватись, бо один і той
же виріб може відпускатись зі складу кілька раз навіть протягом од-
нієї дати чи певного звітного періоду. Необхідність створення зов-
нішнього лівого об’єднання таблиць Залишок та Видатки поясню-
ється тим, що зі складу продовж певного звітного періоду,
наприклад місяця, можуть відпускатись не всі вироби, що були в за-
лишках. Відстежити вироби, по яких не було видатків протягом зві-
тного періоду, неможливо за допомогою внутрішнього об’єднання.

Рис. 6.12. Зовнішнє ліве об’єднання таблиць

Слід звернути увагу, що при створенні зовнішнього лівого
об’єднання система додасть стрілку над дугою, що об’єднує дві
таблиці, яка буде орієнтована зліва направо;
 Праве зовнішнє об’єднання поєднує всі записи підпорядко-
ваної таблиці незалежно від того, чи існують у зв’язаних з ними
полях головної таблиці співпадаючі значення. При створенні
правого зовнішнього об’єднання користуються параметром №3
об’єднання таблиць (див. рис. 6.11).
Розглянемо приклад правого зовнішнього об’єднання на прикладі
двох таблиць: Залишок (Код виробу, Код складу, Дата, Залишок),
Надходження (Код виробу, Код складу, Дата, Надійшло). Поле Код
виробу в таблиці Надходження є полем вторинного ключа, тобто
може дублюватись, бо один і той самий виріб може надходити на
склад кілька раз навіть протягом однієї дати чи певного звітного пе-
ріоду. На склад можуть надходити вироби, яких раніше не було в за-
154
лишках. Відстежити вироби, що вперше надійшли на склад, можна за
допомогою правого зовнішнього об’єднання. Схема правого зовніш-
нього об’єднання таблиць Залишок і Надходження наведена на рис.
6.13.

Рис. 6.13. Зовнішнє праве об’єднання таблиць

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

155
Рис. 6.14. Схема даних

156
 6.5. Запити в ACCESS

У таблицях Access не можна використовувати поля, які

отримуються розрахунковим шляхом. Крім того, в Access таблиці
автоматично упорядковуються за первинним ключем. Не існує мо-
жливості вибрати інший ключ сортування, наприклад вторинний.
Усі ці проблеми можна вирішити за допомогою запитів. Запити за-
безпечують швидкий та ефективний доступ до даних, які зберіга-
ються в таблицях. За допомогою запитів можна виконати необхідне
сортування, обчислити якийсь вираз або спільно обробити відразу
кілька зв’язаних таблиць. В одному запиті можна використовувати
до 32-х таблиць. У запитах Access зберігаються лише інструкції про
те, як повинні бути організовані дані в результаті виконання запиту.
При виконанні запиту підсумкові дані відображаються у ви-
гляді тимчасових таблиць, які не зберігаються і тому носять на-
зву динамічних наборів даних.
Динамічний набір даних — це тимчасова таблиця, яка
створюється запитом. В цій таблиці розміщуються записи,
які задовольняють вимогам певного запиту.
Запити можна використовувати приблизно так, як і таблиці:
можна відкрити і переглянути відповідний динамічний набір да-
них; на базі запиту можна створити форму чи звіт. Крім того, в
динамічні набори можна вносити зміни, які відобразяться в тих
таблицях, з яких були вибрані ті чи інші дані.

6.5.1. Типи запитів

Запити можна поділити на такі дві групи: запити-

вибірки і запити-дії.
Запити-вибірки — це найбільш поширений тип запитів. За
допомогою таких запитів не виконується жодних перетворень з
даними, а лише здійснюється пошук даних за певними умовами,
які відображають поточні інформаційні потреби користувача.
Наприклад, можна вибрати тих працівників, які мали лікарняний
лист у поточному місяці, чи вибрати ті поставки готової продук-
ції, за яку ще не отримані гроші від споживачів, тощо.
Запити-дії — це запити, за допомогою яких можна додавати,
змінювати чи вилучати дані. В Access існує чотири типи запитів-дії:
 запити-поповнення — дозволяють добавити вибрані дані в
існуючу таблицю;
156
  запити-вилучення — вилучають певні дані з однієї чи кількох
таблиць;
 запити-створення таблиць — створюють нові таблиці, запо-
внюючи їх даними з інших таблиць;
 запити-оновлення — змінюють дані, які зберігаються в запи-
сах існуючої таблиці.
Реалізацію запитів в Access можна виконувати за допомогою
запитів за зразком — QBE-запити та SQL-запитів.
SQL-запит — це запит мовою SQL, який формується у таких
випадках:
 запит-об’єднання — вибирає інформацію з кількох таблиць
в одну, відображаючи результат, який не може бути зміненим;
 запит до сервера — посилає на сервер інформацію, дає змо-
гу працювати з таблицями, які відсутні в базі даних користувача;
 запит-управління — може створювати чи вилучати таблицю,
додавати в таблицю нове поле, створювати чи вилучати індекс
таблиці.
Запити, які створюються в інтерактивному режимі, можуть
використовувати SQL-запити як підзапити, але вирази для ство-
рення цих підзапитів повинні вводитись у таблиці QBE.

6.5.2. Запити за зразком

Для полегшення створення запитів в Access викорис-

товуються таблиці QBE (Query By Example — запит за зразком).
Назва запиту відповідає способу створення запиту. При від-
критті нового запиту в режимі конструктора відкривається вік-
но, у верхній половині якого зазначається список полів таблиці,
які необхідно включити до запиту. Поля, які необхідно включи-
ти в запит, можна просто перетягнути мишкою з верхньої час-
тини вікна у нижню.
Нижня половина вікна є таблицею QBE, в якій задаються умо-
ви виконання запиту. В рядках умови можна задати значення по-
лів, які повинні бути вибрані в динамічний набір даних.
Розглянемо детальніше призначення кожного рядка таблиці QBE.
 Поле. В цьому рядку розташовуються імена полів. Якщо по-
ле є розрахунковим, то у відповідній йому клітинці стоїть вираз,
який використовується для обчислення значення цього поля.
 Сортування. Визначає спосіб упорядкування записів дина-
мічного набору даних за відповідним полем.
157
  Вивід на екран. Визначає, чи буде включено поле в динаміч-
ний набір даних.
 Умова вибору. Вміщує критерії, згідно з якими записи виби-
раються в динамічний набір даних.

6.5.3. Створення запиту-вибірки

Для того щоб відкрити вікно запиту, необхідно у вікні

бази даних натиснути мишкою на закладку Запрос і відкриється
вікно Новый запрос (рис. 6.15).

Рис. 6.15. Вікно для створення нового запиту

Вибираємо опцію Конструктор, відкриється вікно Запрос-
выборка і з’явиться діалог Добавление таблицы (рис.6.16). Миш-
кою виділяємо потрібні таблиці і натиснемо на кнопку Добавить.

Рис. 6.16. Вікно вибору таблиць

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

Рис. 6.17. Вікно запиту-вибірки

У рядок Поле таблиці QBE перетягуємо мишкою поля Код

споживача, Назва споживача, Код виробу, Назва виробу, Кіль-
кість, Ціна за одиницю, які необхідно отримати в результаті ви-
конання запиту. В рядку Условие отбора у стовпчику, який вмі-
щує назву споживача, задаємо умову вибірки «Гастроном
Геркулес». При закритті вікна Access запропонує вказати ім’я за-
питу, запропонувавши вибрати стандартне. Запит можна зберіга-
ти в поточній чи зовнішній базі даних (рис. 6.18).

Рис. 6.18. Вікно зі стандартним ім’ям запиту

159
 Зазначивши ім’я запиту і натиснувши кнопку ОК, ми збере-
жемо запит.
Переглянути результати виконання запиту можна в режимі
таблиці чи кнопкою Открыть у вікні бази даних.
Для встановлення умови вибірки можуть використовуватись
визначені вирази (наприклад, якщо потрібно вибрати числові ви-
рази певного поля, значення якого перевищує 3, то умова зада-
ється так: >3. Якщо цей вираз буде включено в поле номер теле-
фону, то будуть видані телефони, номер яких починається з
числа більшого за 3).
Крім оператора порівняння > (більше ніж), у запитах за зраз-
ком можуть використовуватись оператори < (менше ніж), >= (не
менше ніж), <= (не більше ніж). Якщо, наприклад, для текстового
поля буде задано критерій «В*», то в результатах виконання цьо-
го запиту виявляться тільки ті записи текстового поля, котрі по-
чинаються з букви «В» чи «в».

6.5.4. Запити з обчисленнями

У таблицях недоцільно зберігати дані, які можна отри-

мати розрахунковим шляхом. Access не дозволяє виконувати об-
числення над даними, що зберігаються в полях таблиць. Для цих
цілей використовуються запити з обчисленнями. Наприклад, у
запиті, що був сформований на попередньому кроці, можна об-
числити вартість реалізації по кожному виробу.
Для обчислення вартості реалізації по кожному виробу запит
відкривають у режимі Конструктора і додають до його полів нове
поле, яке буде розрахунковим. Це поле описують таким чином:
[Кількість] * [Ціна за одиницю].
Після того як розрахункове поле буде описане, воно набуде
такого вигляду:
Вираз 1:[Кількість] * [Ціна за одиницю].
У квадратні дужки заключаються лише імена полів. Access ав-
томатично використає «Вираз1» для позначення імені поля, яке
обчислюється. Це ім’я може бути замінене на Вар-
тість:[Кількість] * [Ціна за одиницю].
Вираз, що обчислюється, можна створювати вручну або з ви-
користанням Построителя выражений, викликати який можна,
клацнувши правою кнопкою мишки у відповідному стовпчику і
160
вибравши опцію Построить. Результат виконання запиту можна
відобразити в режимі таблиці, де буде отримана підсумкова таб-
лиця з новим полем Вартість, значення якого змінювати не можна.

Рис. 6.19. Приклад створення запиту з обчисленням

Якщо в обчисленнях з використанням арифметичних операто-

рів значення одного з полів буде пустим, то це може призвести до
помилки в обчисленнях. Для запобігання цьому пусте поле пере-
творюють на нульове за допомогою функції Nz. Наприклад,
Вартість : Nz ([Кількість]) * Nz ([Ціна за одиницю]).
Також перетворювати пусте поле на нульове можна, застосо-
вуючи функції IIf і IsNull. Наприклад, якщо поле Норма запасу
пусте, йому буде присвоєно значення нуль.
IIf (IsNull([Норма запасу]![Норма запасу]); 0; [Норма запасу] !
[Норма запасу])
Використовуючи ці ж функції, можна видати повідомлення,
що поля є пустими, наприклад:
IIf(IsNull([Кількість] * [Ціна]); «Перевірте відсутність значення»;
[Кількість] * [Ціна]).
У такому разі, якщо хоча б одне поле Кількість чи Ціна буде
пустим, у результатах виконання запиту буде видаватись по-
відомлення «Перевірте відсутність значення». У противному разі
виконуватиметься розрахунок.
161
 6.5.5. Групувальні запити

При створенні запиту можна вказати поля, які будуть

використовуватись для групування записів і виконання відповід-
них обчислень. Такі запити можна створювати як з використанням
даних однієї, так і зв’язаних між собою таблиць. Розглянемо при-
клад створення такого запиту до двох зв’язаних між собою таб-
лиць Реалізація і Виріб. Наприклад, необхідно визначитись із зага-
льною кількість реалізації по кожному виробу. Для цього, як у
попередньому випадку, вибирають таблиці і поля, які необхідно
включити до запиту. Коли поля вибрані, то на панелі інструментів
головного меню вибирається піктограма Групповая операция. Пі-
сля натиснення на неї в бланку QBE з’явиться рядок з назвою Гру-
пповая операция зі словом Группировка в кожному стовпчику.
Далі в стовпчику того поля, по якому виконуватиметься гру-
пування, необхідно клацнути мишкою в клітинці Групповая
операция. Access видасть список елементів і функцій, по яких
можна виконувати групувальні операції. З цього списку необхід-
но вибрати потрібний елемент чи функцію (рис. 6.20).

Рис. 6.20. Вікно формування групувального запиту

Можливі такі типи групувальних функцій:
Sum — обчислення суми значень поля;
Avg — обчислення середнього значення поля;
162
 Min — пошук мінімального значення поля;
Max — пошук максимального значення поля;
Count — підрахування кількості значень у полі;
StDev — обчислення середнього квадратичного відхилення для зна-
чень полів;
Var — обчислення дисперсії значень поля;
First — вибір значення з першого запису для встановлення поточно-
го порядку сортування;
Last — вибір значення з останнього запису для встановлення
поточного порядку сортування.
Крім функцій, цей список включає три таких елементи:
Группировка — визначає групи, для яких виконується обчи-
слення. Наприклад, щоб визначити сумарні обсяги реалізації ви-
робів елемент Группировка вибирається для полів Код виробу,
Назва виробу;
Выражение — створює поля, що обчислюються за допомо-
гою статистичної функції. Як правило, цей елемент використову-
ється, якщо потрібно включити у вираз кілька функцій;
Условие — визначає умову вибору для поля, яке не бере уча-
сті у групуванні. Якщо для поля вибирається цей параметр, то ав-
томатично знімається прапорець Вывод на экран і поле не виво-
диться на екран при виконанні запиту.
У розглянутому прикладі вибрана функція Sum. Результатом
виконання запиту буде таблиця з підсумками поля Кількість по
кожному виробу. Для зручності представлення результатів запиту
в рядку Сортировка проти поля Код виробу вибрана опція По во-
зростанию. Якщо ця опція була б задана проти поля Назва виробу,
то при видачі на екран назви були б впорядковані за алфавітом.

6.5.6.Запити вилучення
За допомогою запитів вилучення можна вилучати пев-
ні записи із таблиці. Це можна робити вручну за допомогою ко-
манд Правка / Удалить, але на це витрачається багато часу, крім
того, можна через необачність вилучити потрібні записи. Тому
краще створити запит, який проведе вилучення записів, що від-
повідають певній умові. Передусім необхідно визначитись, які
записи необхідно вилучати. Для надійності спочатку створюється
запит-вибірка, за допомогою якого можна переглянути ті записи,
котрі можуть бути вилучені. Якщо в результатах запиту-виборки
присутні лише ті записи, які підлягають вилученню, то такий за-
пит-вибірку можна перетворити на запит-вилучення.
163
 Розглянемо, яким чином перетворити запит-вибірку на запит-
вилучення.
Створимо на основі таблиці Довідник споживачів запит-
вибірку, задавши умову вибору тих споживачів, які знаходяться у
м.Кременчук. Переглянувши результати виконання цього запиту,
перетворимо його на запит вилучення. Перетворення виконуємо
за допомогою опції Удаление команди Запрос або вибравши оп-
цію Удаление піктограми Тип запроса (рис. 6.21).
Перед виконанням запиту-вилучення Access видає два діагно-
стичних повідомлення: перше — інформує користувача, що ви-
конання цього запиту приводить до змін у таблиці: друге — вка-
зує, скільки записів буде вилучено з таблиці, якщо користувач
підтвердить необхідність виконання запиту. Відмінити вилучен-
ня можна, натиснувши команду Отмена. Якщо вибрати ствер-
джувальну відповідь, то вказані записи будуть фізично знищені і
відновити їх можна буде лише за наявності страхової копії.

Рис. 6.21. Вікно перетворення запиту-виборки на запит-вилучення

6.5.7. Запити оновлення

Іноді в таблиці потрібно виконати кілька однакових

замін, виконання яких вручну займе багато часу. Для автомати-
зації такого виду робіт можна використати запити оновлення. Як
164
і в попередньому випадку, для надійності спочатку створюється
запит-вибірка, за допомогою якого можна переглянути ті записи,
в яких проводитимуться заміни. Якщо в результаті запиту-
вибірки присутні лише ті записи, які підлягають оновленню, то
такий запит-вибірку перетворюють на запит-оновлення.
Розглянемо приклад, як замінити у таблиці Матеріал поле, що
характеризує ціну. Нехай на 1,2 необхідно збільшити ціни на ма-
теріали, ціна яких була менша за 1 грн. Спочатку створюється за-
пит-вибірка, за допомогою якого вибираються ті товари, ціни на
які є меншими за 1 грн. Після його виконання і перегляду тих ма-
теріалів, на які будуть змінені ціни, запит-вибірка перетворюєть-
ся на запит-оновлення. Для цього вибирається піктограма Тип
запроса і з неї вибирається опція Обновление (рис. 6.22).
У бланку запитів QBE з’явиться рядок Обновление, в якому
навпроти поля Ціна необхідно ввести такий вираз : [ ціна ] * 1.2.

Рис. 6.22. Формування умов оновлення

Перед виконанням цього запиту буде видано діагностичне по-

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

Записи в таблиці завжди впорядковані за первинним

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

Рис. 6.23. Задання умови упорядкування записів таблиці за алфавітом

Виконання цього запиту дасть список співробітників, прізви-

ща яких упорядковані в алфавітному порядку.

6.5.9. Запити з параметрами

Для того, аби щоразу для кожного критерію вибірки не

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

166
таблиці. Наприклад, можна сформувати запит, який дозволить
переглядати дані про реалізацію за певний проміжок часу. Для
цього в діалогове вікно запитів додається таблиця, на основі якої
буде створюватись запит. Потім з неї вибираються і заносяться в
таблицю QBE необхідні поля. Як умова виконання запиту в рядку
Условие отбора задається вираз, наведений на рис. 6.24, який за-
дає діапазон вибірки, причому дати, які задають межі діапазону
необхідно задавати як параметри.

Рис. 6.24. Вікно створення запиту з параметрами

Після збереження цього типу запиту перед його виконанням

видаватиметься на екран повідомлення з проханням ввести ниж-
ню межу діапазону ввести дату з, після введення якої буде вида-
но ввести дату по, тобто верхню межу діапазону (рис. 6.25). За-
давши обидві дати, отримаємо дані про реалізацію товарів у
заданому інтервалі.

Рис. 6.25. Вікна для введення параметрів при реалізації запиту з пара-
метрами
167
 6.5.10. Перехресні запити
Для створення перехресного запиту, який відображатиме
підсумки реалізацій за кожен місяць, необхідно виконати такі дії:
1. Створити новий запит, включивши до нього таблиці Реалі-
зація і Виріб.
2. До бланка запитів переносяться поля: Назва виробу, Код
виробу, Кількість. Для поля Дата будується вираз з використан-
ням функції Month, яка відобразить номер місяця, коли було ви-
конано реалізацію Дата:Month ([Дата реалізації]).
3. З меню команди Запрос вибирається опція Перекрестный.
Після цього змінюється заголовок запиту — із запиту вибірки на
перехресний запит.
4. Після цього, розкривши список Перекрестная таблица,
необхідно визначитись з полями: які будуть заголовками рядків
стовпчиків, а які будуть значеннями. У нашому випадку поля На-
зва виробу і Код виробу вибрані заголовками рядків, поле Дата —
заголовком стовпчика, Кількість — значенням (рис. 6.27).
5. Розкривши список Групповая операция для поля Кіль-
кість, вибираємо функцію SUM.

Рис. 6.26. Вікно перехресного запиту

Рис. 6.27. Результат виконання перехресного запиту

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

Рис. 6.28. Вікно для вибору інтервала групування при створенні пере-
хресних запитів

6.5.11. Запити на створення нових таблиць

Якщо результати якогось запиту з обчисленнями необ-

хідно зберегти в таблиці, то в меню команди Запрос вибирається
опція Создание таблицы. Коли буде вибрана ця опція і задано
ім’я нової таблиці, то користувачу надається можливість запису
нової таблиці в поточну чи іншу БД (рис. 6.29).

Рис. 6.29. Вікно для визначення ім’я таблиці та БД для її запису

169
 При виконанні цього запиту система видає два діагностичних
повідомлення: перше вказує на те, що виконання запиту приведе
до створення таблиці, а друге — на те, що буде створена нова
таблиця з певною кількістю записів. Користувачеві надається
можливість підтвердити виконання запиту або ж відмовитись від
його виконання. Якщо користувач дає згоду, то в результаті ви-
конання запиту в переліку таблиць БД з’явиться нова таблиця.
Слід пам’ятати, що властивості полів і ключові поля початко-
вої таблиці не переходять на дані нової таблиці. Кожне нове чер-
гове виконання запиту по створенню нової таблиці приводить до
фізичного знищення старої таблиці і створення нової.
6.5.12. Оптимізація запитів
Оптимізація запитів — це ряд прийомів або процедур,
за допомогою яких здійснюється прискорення їх виконання:
1. Стиснення бази даних. Це підвищить швидкість виконання
запитів, оскільки при цьому здійснюється перетворення записів у
таблиці таким чином, що записи, упорядковані за ключем таблиці,
знаходяться на сусідніх сторінках. Це підвищує швидкість за раху-
нок зменшення кількості сторінок, які необхідно прочитати при ре-
алізації вибірок з бази даних. Після виконання стиснення бази даних
необхідно запустити кожен запит, щоб відкомпілювати його з но-
вими характеристиками таблиць.
2. Індексація всіх полів для визначення умов вибірки в запиті,
а також полів, по яких виконується зв’язок між двома таблицями,
особливо, якщо це поля з різних баз даних.
3. По можливості уникнення визначення в запитах умови ви-
бірки для розрахункових полів і непроіндексованих полів.
4. Індексація полів, що використовуються для упорядкування.
5. При створенні запитів уникнення їх складу зайвих полів. Не-
обхідно знімати прапорець виведення на екран для полів, які засто-
совуються в умовах вибору, але які не потрібно видавати на екран.
6. Використання операторів Between…And, In і = для проін-
дексованих полів.
7. Потрібно намагатися, щоб у підпорядкованих запитах не
використовувались поля, що обчислюються, оскільки це вповіль-
нює виконання запиту верхнього рівня. Якщо такі поля необхідні,
то краще їх обрахувати у формі.
8. При групуванні записів за значенням полів, що беруть участь
в об’єднанні, визначення умови групування в колонці Групповая
операция для поля в тій же таблиці, в якій знаходиться поле, для
якого обчислюється статистична функція.
170
 6.6. Форми в Access

Важливим моментом при завантажуванні даних у таб-

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

Коли джерелом даних для завантажування в базу даних є пер-

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

6.6.1. Створення форм на базі однієї таблиці

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

даних вибрати піктограму Форма, натиснути на кнопку Создать.
Після цього відкриється вікно (рис. 6.30), в полі якого необхідно
вибрати таблицю або запит, що будуть джерелом створення фор-
ми, і одну із опцій, які задають варіант створення форми.
Access надає такі можливості для створення форм:
 за допомогою Конструктора;
 за допомогою Майстра форм;
 використовуючи Автоформу.
Конструктор створює макет форми і надає користувачеві набір
інструментів для її побудови. Майстер за допомогою діалогу з
користувачем керує процесом проектування форми. Автоформа
автоматично створює на основі вибраної таблиці форму одного з
типів: у стовпчик, у вигляді таблиці, у вигляді стрічки.
Опція Сводная таблица дозволяє створити зведену таблицю
за типом того, як це робиться в Еxсel, тобто з підсумками за пев-
ними групувальними ознаками.
171
 Рис. 6.30. Діалогове вікно для створення форми

Розглянемо найпростіший спосіб створення форм за допомо-

гою автоформ. У вікні необхідно вибрати таблицю, яка буде дже-
релом для створення форми, та вибрати потрібну опцію. Вибере-
мо таблицю Виріб та опцію Автоформа: у стовпчик Access
автоматично створить форму такого вигляду (рис. 6.31).

Рис. 6.31. Вікно форми, представленої в стовпчик

Якщо таблиця Виріб порожня, то форма теж буде порожньою.

Якщо таблиця вміщує дані, то вони автоматично будуть перене-
сені у форму.
При закритті вікна створеної форми буде видане таке повід-
омлення: Сохранить изменение макета или структуры фор-
мы ‘Форма 1’. Якщо буде вибраний варіант Да, то тоді
з’явиться вікно Сохранение, (рис. 6.32), в якому необхідно вка-
зати ім’я, під яким зберігатиметься форма. Якщо користувач у
цьому вікні не вкаже ім’я форми, то Access сама визначить його
як Форма 1.
172
 Рис. 6.32. Вікно для визначення ім’я форми

Режимом автоформа доречно користуватися тоді, коли форма,

що проектується, формується на основі однієї таблиці з включен-
ням у неї всіх полів.
Якщо форма, що проектується, не повинна включати всі поля
таблиці чи повинна включати поля кількох таблиць, то тоді доре-
чно користуватись опцією Мастер форм.
Розглянемо створення форми за допомогою Мастер форм
на основі таблиці Реалізація. Перше вікно, що з’явиться
(рис.6.33), надає можливість вибору полів з таблиці Реалізація
для включення у форму. Вибір окремого поля виконується
кнопкою >, вибір всіх полів — кнопкою >>. Відмовитись від
вибраного окремого поля можна за допомогою кнопки <, мож-
ливість відмовитись від усіх полів, що були вибрані, можна
кнопкою <<.

Рис. 6.33. Вікно для вибору полів

173
 Вибираємо всі поля і натискаємо кнопку Далее. З’явиться вік-
но, в якому необхідно буде вибрати зовнішній вид форми із за-
пропонованих варіантів, які представлені на рис. 6.34.

Рис. 6.34. Вікно для вибору зовнішнього виду форми

Вибравши варіант представлення, тиснемо кнопку Далее.

З’явиться вікно вибору стилю (рис. 6.35), в якому вибираємо
стиль з назвою Обычный і тиснемо кнопку Далее.

Рис. 6.35. Вікно для вибору стилю

174
 В останньому вікні (рис. 6.36) Access запропонує вказати ім’я
форми, пропонуючи за замовчуванням залишити ім’я тієї таблиці
чи запиту, на базі якого створюється ця форма. Створеній формі
можна присвоїти унікальне ім’я.

Рис. 6.36. Створення складової форми

6.6.2. Створення підпорядкованих та зв’язаних

форм

В Access є можливість створити складову форму, дані

якої при її заповненні будуть заноситись до кількох таблиць. За
допомогою таких форм можна виконувати не лише одночасне за-
вантаження, а також одночасно переглядати і редагувати дані,
зв’язані між собою таблиці.
Створення підпорядкованих форм. Підпорядкована форма
формується на базі зв’язаних таблиць і складається з головної та
підпорядкованої форм, яка є, так би мовити, формою всередині
форми. Підпорядкована форма зручна для відображення на екра-
ні даних з таблиць чи запитів, які зв’язані відношенням 1:Б.
Створення форми, яка може працювати зі зв’язаними табли-
цями, розглянемо на прикладі таблиць Виріб і Реалізація, тип
відношення між якими 1:Б. За допомогою цих таблиць можна бу-
де переглядати дані про реалізацію конкретних виробів.
175
 Для створення форми необхідно активізувати команду Форма
у меню Вид чи відкрити закладку Формы у вікні відкритої бази
даних і клацнути мишкою по кнопці Создать. Відкриється вікно
Новая форма, в якому вибираємо спосіб створення Мастер
форм і тиснемо на кнопку ОК. Вибирати назву таблиці у цьому
вікні необов’язково.
З’явиться вікно Создание форм, в якому необхідно зазначити
імена таблиць для створення форми. Спочатку вказується ім’я
основної таблиці (у нашому прикладі це Виріб).
Кнопкою >> з вікна Доступные поля всі поля таблиці перено-
сяться у вікно Выбранные поля. Потім кнопкою > поле Код ви-
робу повертається назад. Далі у віконці Таблицы/запросы виби-
рається ім’я підпорядкованої таблиці Реалізація, з якої
відповідною кнопкою переносяться всі поля у вікно Выбранные
поля. Результат виконання всіх цих операцій представлений на
рис.6.36.

Рис. 6.37. Вікно для вибору типу підпорядкованості

Після натиснення кнопки Далее з’явиться вікно (рис. 6.37) з

установленою опцією Подчиненная форма, яка вказує на те, що
буде створена складова форма. В цьому вікні є ще опція Выбе-
рите тип представления данных, яка буде встановлена на оп-
цію по Виріб, тому, нічого не змінюючи в цьому вікні, тиснемо
176
кнопку Далее, хоча вже на цьому етапі можна клацнути по кноп-
ці Готово. У наступних вікнах необхідно лиш підтвердити всі
установки, які будуть видані за замовчуванням. Лише в остан-
ньому вікні можна задати імена основної та підпорядкованої
форм чи погодитись зі стандартними іменами, які надає Access, і
натиснути кнопку Готово.
Слід звернути увагу на те, що у вікні імен створених форм
з’явиться два імені форм: Виріб — основна форма, Реалізація —
підпорядкована таблиця (рис. 6.38).
Після вибору імені необхідно встановити одну з таких опцій:
 открытие формы для просмотра или ввода данных;
 изменение макета формы.
Якщо в подальшому не будуть вноситись зміни у макет фор-
ми, то вибирається перша опція, якщо ж зміст форми редагува-
тимуться, то необхідно вибрати другу опцію.

Рис. 6.38. Вікно для визначення імен форм

Результат створення складової форми представлено на рис.6.39.

Верхня частина форми утворена з полів таблиці Виріб, а ниж-
ня — з полів таблиці Реалізація. Особливістю складової форми є
те, що вона відображає лише ті значення таблиці Реалізація, які
зв’язані з поточним записом таблиці Виріб.
177
 Рис. 6.39. Результат створення складової форми

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

ся посилкова цілісність даних. Тому запис про якийсь виріб мож-
на буде вилучити лише після вилучення даних про їх реалізацію.
При завантаженні нових даних про реалізацію виробів Access
автоматично зв’язує записи з даними із таблиці Виріб, тому поле
Код виробу не потрібно буде ще раз заповнювати. Це поле взагалі
можна вилучити з підпорядкованої таблиці.
Створення зв’язаних форм. Зв’язана форма буде створена,
якщо у вікні створення форм (рис. 6.37) виберемо опцію Связан-
ная форма. При створенні зв’язаних форм в основній формі
створюється кнопка з назвою підпорядкованої форми (рис.6.40),
натиснувши на яку, можна переглянути дані про реалізацію від-
повідної продукції.

Рис. 6.40. Результат створення зв’язаних форм

Натиснувши кнопку Реалізація, отримаємо наступне вікно

(рис. 6.41).
178
 Рис. 6.41. Вікно спільного перегляду зв’язаних форм

6.6.3. Розробка зовнішнього вигляду форм

Розробка зовнішнього вигляду форм виконується в ре-

жимі Конструктора, за допомогою якого при роботі з формами
користувач може вносити певні зміни у зовнішній вигляд форми.
Це виконується у тому разі, якщо представлення форми з певних
причин не задовольняє користувача.
Якщо форма уже відкрита, то вибирається піктограма Конс-
труктор. Форму також можна відкрити в режимі Конструктора.
Для цього у вікні бази даних вибирається закладка Формы, миш-
кою вибирається ім’я форми і натискається кнопка Конструктор.
Кожна форма складається з таких областей: заголовок форми,
область даних і примітки форми. Форма може вміщувати такі
елементи: підписи, поля, поля зі списком, вимикачі, перемикачі,
прапорці та кнопки. Перш ніж змінити характеристики якогось
елемента форми, спочатку його необхідно вибрати і виділити.
Для цього вибраний елемент форми слід позначити мишку і
Access виділить елемент рамкою з маленькими квадратами, які
називаються маркерами виділення. Для вибраних елементів мож-
на змінити шрифт, розмір, колір та додати інші властивості. Для
кожної області можна встановити свій колір, для чого необхідно
вказати на відповідну область, а потім вибрати необхідний колір
із заданої палітри кольорів. Можна змінювати позиції розташуван-
ня елементів форми за допомогою буксування, тобто перетягуван-
ня мишкою позначеного елемента з однієї части форми до іншої.
179
 Якщо на виділений елемент натиснути правою кнопкою миш-
ки, то можна виконати певні операції з ним (рис. 6.42): вирізати,
копіювати, залишити, дублювати, вирівняти, змінити колір, пере-
глянути властивості і т.п.
Повний список усіх властивостей можна також отримати, від-
кривши вікно властивостей піктограмою Свойства. Access ви-
дасть вікно властивостей поля (рис. 6.43).
За допомогою списку властивостей Access можна задавати
властивості полів та змінювати їх. Наприклад, на виділене поле
можна задати значення за замовчуванням чи певну умову на його
значення. Також можна формувати діагностичні повідомлення на
екран, коли введене значення не відповідає заданій умові.

Рис. 6.42. Виділений елемент після натиснення правої кнопки мишки

Якщо виділити кілька полів, то можна одночасно змінювати їх
спільні властивості.

Рис. 6.43. Діалогове вікно зі списком властивостей

180
 6.6.4. Створення додаткових елементів форми

Створення додаткових елементів форми теж викону-

ється у режимі Конструктора. Наприклад, в існуючу форму Ма-
териал необхідно ввести додаткові поля Дата і Час, які повинні
відображати системну дату і час внесення змін до форми. Для
створення додаткових елементів необхідно викликати форму в
режимі Конструктора і натиснути на піктограму Панель элемен-
тов, після чого у діалоговому вікні зліва з’явиться ця панель, в
якій необхідно вибрати піктограму Поле і натиснути мишкою у
вільному місті верхнього колонтитула форми. Access створить
вільне поле, яке назвемо Дата. Для відображення в цьому полі
системної дати в значення поля необхідно ввести вираз: =Date().
Аналогічно створюється поле Час, в яке заноситься вираз:
=Time(). Відкрита форма в режимі конструктора з новими полями
представлена на рис. 6.44.
Переглянути результат створення нових полів можна в режимі
Форма.

Рис. 6.44. Вікно створення нових полів у формі

181
 6.6.5. Управління безпомилковим введенням
форм

Форми — це засіб контролю при завантаженні даних.

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

6.6.5.1. Створення прапорців

Дуже часто деякі поля вміщують логічні значення або

можуть набувати лише певних числових значень. Для полегшен-
ня введення таких даних можна використовувати прапорці і пере-
микачі.
Конструктор дозволяє для логічних полів створювати такий
елемент для управління вводом даних, як прапорець. Прапорець
відображається маленьким квадратом, який може бути поміченим
чи порожнім. Якщо прапорець помічений, то значення логічного
поля є істина, тобто воно може набувати значення Так чи 1.
Упротивному разі такому полю присвоюється значення хибність,
тобто Ні чи 0.
Розглянемо приклад створення прапорця для форми
Ф_Реалізація. Для цього відкриваємо форму в режимі Конструк-
тора і тиснемо на піктограму Панель элементов. У вікні відкри-
тої форми з’явиться віконце Панель элементов, в якому миш-
кою натиснемо на піктограму Флажок і відбуксуємо його у
вільне місце форми. Створене поле назвемо Ознака оплати, що
буде логічним (рис. 6.45).
Якщо числове поле може набувати тільки певних значень, то
для вибору значень можна використовувати групу перемикачів.
Розглянемо приклад створення групи перемикачів для форми Ви-
ріб, попередньо відредагувавши її структуру шляхом включення
нового поля з назвою Тип виконання.
182
 Рис. 6.45. Діалогове вікно для встановлення прапорця

6.6.5.2. Створення групи перемикачів

Для створення перемикачів необхідно в режимі Конс-

труктора відкрити відредаговану форму, вибрати піктограму
Группа переключателей на панелі елементів і у вільному місці
форми намалювати рамку. Відкриється вікно майстра Создание
группы переключателей, в якому вводяться імена перемикачів
(рис. 6.46). Тиснемо кнопку Далее.

Рис. 6.46. Вікно вибору імен перемикачів

183
 У наступному вікні буде запропоновано за замовчуванням задава-
ти значення параметра Звичайний. Знову тиснемо на кнопку Далее.

Рис. 6.47. Вікно вибору поля для перемикачів

З’явиться вікно, в якому майстер запропонує числа 1, 2, 3, 4 як
відповідні значення параметру. Погодившись, тиснемо кнопку
Далее. Далі майстер запропонує визначитись з полем, в якому
зберігатиметься значення параметру (рис. 6.47). Вибираємо поле
Тип виконання і тиснемо кнопку Далее. У наступному вікні по-
годжуємось з усіма установками за замовчуванням майстра і
тільки тиснемо кнопку Далее. В останньому вікні вказуємо назву
групи перемикачів, тиснемо на кнопку Готово і отримаємо ре-
зультат, представлений на рис. 6.48.

Рис. 6.48. Створена група перемикачів для поля Тип виконання

184
 6.6.5.3. Створення полів зі списком

При занесенні даних у форму користувачеві іноді не-

обхідно не вводити дані з клавіатури, а вибирати їх з якихось ін-
ших таблиць чи навіть запитів. Для реалізації такої можливості
зручно користуватися таким елементом управління, як вибір да-
них у полі зі списком чи у списку. Відмінність між списком і по-
лем зі списком полягає в тому, що із списку можна вибрати лише
значення, а в полі зі списком можна вибрати пункт списку чи
ввести значення з клавіатури. Цей механізм забезпечує швидкість
і точність при введенні даних.
Розглянемо створення полів зі списком. Так, при занесенні
поля Код виробу у форму Реалізація зручно було б переглядати і
вибирати той чи інший виріб із форми Виріб, що вміщує довідко-
ві дані про код виробу та його назву. Створення полів зі списком,
або комбінованих полів, виконується в такій послідовності.
Форма відкривається в режимі Конструктора. В цій формі ви-
лучається командою Del поле Код виробу. Далі відкривається вікно
списку полів цієї форми за допомогою піктограми меню Список
поле. Викликається Панель элементов, натискується кнопка Мас-
тера, а потім кнопка Список полей і лише після цього з отриманого
списку мишкою буксується поле Код виробу на вільне місце у формі.
Після цього на екрані з’явиться перше діалогове вікно процесу
створення полів зі списком, який складається з кількох кроків.
Після кожного з кроків до шостого включно необхідно натискати
на кнопку Далее.

Рис. 6.49. Вікно при створенні полів зі списком

185
 Крок 1. У першому діалоговому вікні впевніться у тому, що
виділена перша опція використовує для поля зі списком значення
із таблиці чи запиту (рис. 6.50).

Рис. 6.50. Перше діалогове вікно процесу створення полів зі списком

Крок 2. Виконується вибір таблиці. У такому разі вибирається

таблиця Виріб.

Рис. 6.51. Вікно вибору ширини стовпчиків

186
 Крок 3. Після вибору таблиці з’явиться наступне вікно, в якому
буде запропоновано вибрати необхідні поля із заданої таблиці. Ви-
бравши поля Код виробу, Назва виробу, тиснемо на кнопку Далее.
Крок 4. На четвертому кроці з’явиться вікно, в якому буде за-
пропоновано задати ширину стовпчиків та ознаку Скрыть клю-
чевой столбец, яка за замовчуванням відмічена прапорцем. У
нашому випадку ми відміняємо прапорець і тиснемо кнопку Да-
лее (рис. 6.51).
Крок 5. Необхідно виділити поле Код виробу, яке буде збері-
гатись.

Рис. 6.52. Вікно вибору поля зі списком

Крок 6. Система запропонує визначити ім’я створеному полю

зі списком. Натиснувши Готово, автоматично буде збережено
старе ім’я Код виробу.
Переглянути зміст створеного поля зі списком можна, натис-
нувши в головному меню опцію Режим форми.

6.6.6. Елементи управління, які обчислюються

Форма, на відміну від таблиць, може вміщувати вира-

зи, що обчислюються.
Елементи управління поділяються на зв’язані та незв’язані:
зв’язані — це такі елементи, які прив’язані до поля якоїсь таблиці
187
чи запиту; незв’язані елементи, як правило, відображають ре-
зультат якихось обчислень.
Розглянемо приклад використання елемента управління, що
обчислюється на прикладі зміни ціни матеріалу. Для цього форма
Материал відкривається у режимі Конструктора, викликаються
елементи управління і вибирається піктограма Поле. Потім миш-
кою в формі створюється нове поле і піктограмою Свойства від-
кривається вікно властивостей поля. В ньому в рядок Данные
вводиться вираз (рис. 6.53):
= [ціна] * 1,15.
Будь-яка формула є комбінацією операторів та імен полів.
Формула завжди повинна починатись зі знака дорівнює ( = ), іме-
на полів у таких виразах беруться в квадратні дужки. Щоб не
вводити самостійно імена полів з клавіатури, можна використати
Построитель выражений, клацнувши мишкою справа від рядка
Данные.

Рис. 6.53. Створення форми з елементами управління, що обчислюють-

ся

Оскільки Access не може самостійно визначити тип поля, що

обчислюється при створенні форми, необхідно змінити значення
властивості Формат поля відповідного елемента на Денежный
(рис.6.54). Крім того, необхідно змінити підпис поля на назву
«Нова ціна».
188
 Перевірити роботу створеного елемента управління можна,
викликавши команду Режим формы із меню Вид (рис. 6.55).

Рис. 6.54. Визначення типу даних поля, що обчислюється

Рис. 6.55. Результат обчислення поля з новою ціною

В існуючу форму Материал буде додано нове поле, що вмі-

щуватиме результат переоцінки.
Область приміток у формі — це область, яка може бути вико-
ристана для розрахунку та відображення підсумкових даних. На-
приклад, у цій області розмістимо нові поля: Вартість за ста-
189
рими цінами та Вартість по новій ціні, в даних яких вкажемо
відповідно по виразу:
=Sum([ціна]·[Залишок]), =Sum([ціна]·1,15·*·[Залишок])

Рис. 6.56. Вікно зі створеними полями, в яких обчислюється вартість

усіх матеріалів на складі

При переході в Режим формы буде відображена вартість усіх

матеріалів на складі з урахуванням нових цін (рис. 6.56).

6.6.7. Гіперпосилання у формах

Зв’язок між формою та іншими документами можна

створити не лише шляхом зв’язування таблиць і форм, а також з
використанням гіперпосилань, яке полягає у тому, щоб з вікна від-
критої форми звернутись за додатковою інформацією до іншого
документа (таблиць, звітів чи запитів) або файла (текстового, гра-
фічного, звукового, анімаційного чи виконавчого). За допомогою
гіперпосилань можна організовувати зв’язок з іншими файлами
Microsoft Office 97 з документами HTML, які знаходяться на жорст-
кому диску або в корпоративній мережі чи в мережі Internet. Для ор-
ганізації гіперзв’язку можна включати рисунок, підпис чи кнопку.
Розглянемо вставку у форму Реалізація кнопки гіперпосилан-
ня на форму Виріб. Для цього форму Реалізація відкриємо в ре-
жимі Конструктора, викличемо Панель элементов і перевіри-
мо, щоб кнопка Мастер не була активною. Активізуємо інструмент
Кнопка і помістимо його у вільне місце форми. Маркирувавши
190
цю кнопку, викликаємо піктограму Свойства панелі інструмен-
тів або оберемо команду Свойства у контекстному меню.
Відкриваємо закладку Все у вікні властивостей і переводимо
курсор у рядок Адрес гиперссылки. Клацаємо мишкою по кноп-
ці з трьома крапками, щоб відкрити вікно Добавить гиперссыл-
ку. У полі Связь с файлом/URL вказується шлях до файла на
жорсткому диску, URL чи UNC, однозначно визначивши місце
розташування файла, до якого необхідно перейти.
Якщо перехід виконується до об’єкта відкритої бази даних
Access, то необхідно вибрати цей об’єкт у вікні Выбор каталога,
яке відкривається кнопкою Обзор (рис. 6.57). При цьому поле
Связь с файлом/URL може залишатися порожнім.

Рис. 6.57. Вікно вибору імені об’єкта при створенні гіперпосилань

При переході до документа, який створено іншим продуктом

Microsoft Office 97, у полі Дополнительный адрес вікна Свойс-
тва вказується місце, в яке потрібно перейти, наприклад ім’я за-
кладки Word чи номер слайду PowerPoint. Якщо місце переходу
не потрібно зазначати, то поле Имя объекта в документе (вво-
дить необязательно) можна не заповнювати.
Після цього необхідно оформити кнопку гіперпосилання. Для
цього в рядок Подпись на закладці Все вікна властивостей вво-
диться назва самої кнопки, яка буде вставлена у форму. Потім, у
разі необхідності, можна змінити розмір і місце розташування
кнопки у формі, а також задати реакцію на подію, пов’язану з
191
кнопкою (вкладка События), вказавши текст, який буде
з’являтися при наведенні мишки на кнопку.
Закривши всі вікна, можна перевірити роботу кнопки, для чо-
го потрібно перейти в режим форми і клацнути мишкою по ство-
реній формі. Якщо все виконано правильно, то відкриється необ-
хідний документ.

6.6.8. Створення макроса у формі

При роботі з формами для забезпечення зручності ро-

боти та отримання додаткової інформації можна в полі форм
створювати макроси. Розглянемо приклад створення простого
макроса, який дозволить у вікні відритої форми Реалізація від-
крити і переглянути форму Довідник споживачів.
Для створення макроса закриваємо форму і у вікні бази даних
відкриваємо закладку Макросы і тиснемо кнопку Создать. У ві-
кні відкритого макроса відкриваємо мишкою список макроко-
манд, клацнувши мишкою в кінці першого рядка колонки Мак-
рокоманда. Вибираємо макрокоманду Открыть форму (рис.6.58).
Далі визначаємо аргументи макроса.
У рядку Имя формы вибираємо ім’я форми Довідник спо-
живачів, із списка Режим данных — Только чтение, в списку
Режим окна — Обычное. Зберігаємо макрос з ім’ям Перегляд
споживачів. На цьому процес створення макроса завершено.

Рис. 6.58. Вікно створення макроса

192
 Наступний крок — це створення кнопки у формі Реалізація
для виклику макроса. Форму відкриваємо в режимі Конструкто-
ра, у вільному місці на екрані за допомогою Панели элементов
створюємо кнопку. Потім, відмітивши кнопку маркером, тиснемо
праву кнопку мишки. З’явиться вікно Свойства, в якому задаємо
такі опції: Имя, Подпись, Нажатие кнопки. В опції Подпись
вказується ім’я кнопки, в опції Нажатие кнопки — ім’я створе-
ного макроса.
Результат можна переглянути, відкривши форму в режимі фор-
ми. Access відкриє форму Реалізація зі створеною кнопкою викли-
ку макроса, натиснення якої відкриє форму Довідник споживачів.

6.7. Звіти в Access

6.7.1. Порядок створення звітів

Звіти в Access дуже подібні до форм. Вони мають ті

самі області, що і форми: область заголовка і приміток, області
нижнього і верхнього колонтитулів. Джерелом для створення зві-
тів можуть бути дані таблиць, запитів, інструкцій SQL і форм.
Для створення звітів необхідно натиснути кнопку Создать на за-
кладці Отчеты у вікні відкритої бази даних. З’явиться вікно Но-
вый отчет (рис. 6.59), в якому буде запропоновано вибрати дже-
рело та спосіб створення звіту. Розглянемо створення звітів за
допомогою Мастера отчетов.

Рис. 6.59. Вікно для створення звітів

193
 Рис. 6.60 Вікно для вибору полів при формуванні звіту
Вибираємо запит Реалізація виробів та Мастер отчетов і тис-
немо кнопку ОК. На екрані з’явиться перше вікно майстра звітів,
в якому буде запропоновано вибрати поля для звіту. Зі списку
Доступные поля у список Выбранные поля поміщаємо кноп-
кою (>>) всі поля і тиснемо кнопку Далее (рис. 6.60). У наступ-
ному вікні (рис. 6.61) майстра кнопкою можна задати рівні
групування. Кількість рівнів групування для одного звіту не мо-
же бути більше чотирьох. Кнопками можна змінити поря-
док рівнів групування. Задавши рівні групування та їх порядок,
тиснемо кнопку Группировка.

Рис. 6.61. Вікно для визначення рівнів групування

194
 З’явиться вікно Интервалы группировки (рис. 6.62), в якому
за замовчуванням буде задано інтервал — Обычный.

Рис. 6.62. Вікно для вибору інтервалу групування

Звичайний режим групування в одну групу об’єднує записи з

однаковими значеннями в заданому полі, тому, не змінюючи
установку, тиснемо кнопку ОК. У наступному вікні майстер на-
дасть діалог для визначення способу сортування даних у звіті.
Access автоматично виконує сортування по тих полях, по яких
виконувалось групування. Якщо записи в звіті необхідно упоряд-
кувати ще по якихось полях, то їх задають у вікні для визначення
полів сортування (рис. 6.63). Порядок полів у вікні сортування
визначатиме їх порядок у звіті.
У нашому прикладі задаємо поле для сортування Дата реалі-
зації. Кнопкою, що стоїть справа від поля, визначається порядок
сортування. Далі тиснемо кнопку Итоги. У вікні Итоги (рис.6.64)
відмічаємо поля, по яких необхідно формувати підсумки у звіті,
спосіб їх відображення у звіті, вибравши варіант данные и итоги,
і тиснемо кнопку ОК.

Рис. 6.63. Вікно для визначення сортування полів звіту

195
 Рис. 6.64. Вікно для визначення підсумків у звіті

У наступному вікні вибираємо варіант відображення даних

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

6.7.2. Створення звітів на базі форми

В Access є можливість створити звіт на базі форми.

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

6.7.3. Створення складних звітів

Access надає можливість створення складних звітів, тоб-

то один звіт можна вмонтувати в інший. При цьому звіт, вставлений
в інший, називається підпорядкованим. Головний звіт може бути
приєднаним і вільним. Вільний — це звіт, який є контейнером для
кількох не пов’язаних між собою звітів, які потрібно об’єднати.
Головний звіт зв’язують з таблицею, запитом чи інструкцією
SQL тоді, коли в нього вставляються підпорядковані звіти, дані
яких пов’язані з даними головного. В головному звіті можуть зна-
ходитися спільні дані для двох чи кількох підпорядкованих звітів.
Допускається два рівні підпорядкування. Підпорядкованими мо-
жуть бути також форми, причому їх кількість не обмежується.
Можна створити підпорядкований звіт в існуючому звіті чи
додавати існуючий звіт в інший, уже створений звіт.
Порядок створення підпорядкованого та існуючого звітів на-
ступний. Перед створенням підпорядкованого звіту необхідно
перевірити наявність відповідних зв’язків між таблицями.
Головний звіт відкривається в режимі Конструктора. При на-
тиснутій кнопці майстра на панелі елементів управління ак-
тивізується кнопка Подчиненная форма/отчет і мишкою
позначається місце в головній формі, де буде розташовуватись
підпорядкований звіт. Далі, виконуючи інструкції, що видавати-
ме майстер створення підпорядкованих звітів, отримаємо звіт, що
складається з головного та підпорядкованого.
197
 6.8. Макроси в Access

Макроси створюються у вікні відкритої бази даних піс-

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

Рис. 6.66. Вікно створення макроса

Кожен макрос — це одна чи кілька макрокоманд, які викону-

ються при виконанні певних умов чи безумовно. При безумовно-
му виконанні макрокоманди виконуються в тій послідовності, в
якій вони записані на бланку макроса. Якщо макрос виконується
за певних умов, то в рядку Условие задається певна умова чи три
крапки «…». Якщо має місце задана умова, тобто вона є істин-
ною, то виконується дана макрокоманда і всі наступні, що мають
у рядку Условие три крапки «…». Якщо умова не виконується,
тобто результатом перевірки умови є хибність, то задана макро-
команда і всі наступні, що мають три крапки, пропускаються.
В наведеному прикладі умовою, яка перевіряється, є переви-
щення кількості матеріалу, який видається зі складу, над їх фак-
тичними залишками. Якщо буде спроба видати зі складу кіль-
кість матеріалу, яка перевищує їх фактичні залишки, то
макрокомандою Сообщение на екран буде видано повідомлення
198
«Видатки перевищують залишок» і наступна макрокоманда От-
менитьСобытие відмінить цю спробу.
Усю множину макрокоманд можна згрупувати таким чином:
 відкриття та закриття таблиць, форм і звітів;
 виведення даних;
 виконання запиту;
 перевірка істинності умов і управління виконанням макро-
команд;
 установка значень;
 пошук даних;
 побудова спеціального меню і виконання команд меню;
 управління виведенням на екран і фокусом;
 виведення повідомлення для користувача при виконанні дії;
 перейменування, копіювання, вилучення, імпорт та експорт
об’єктів.
Користувачу не обов’язково вводити макрокоманди. Їх можна
вибирати зі списку в стовпчику Макрокоманда. Вирази, які ви-
користовуються при створенні макросів, можна будувати за до-
помогою Построителя выражений.
Існує швидкий спосіб створення макроса, що виконує дії над
конкретним об’єктом бази даних. При цьому вибирається об’єкт
(таблиця, форма, макрос та ін.) у вікні бази даних і за допомо-
гою мишки перетягується у стовпчик макрокоманда вікна мак-
роса. Якщо у вікно макроса перетягується якийсь інший макрос,
то вводиться макрокоманда, що запускає цей макрос; якщо ж
перетягуються інші об’єкти, то вибирається макрокоманда від-
криття об’єкта. Завершенням створення макроса є задання його
імені. Макрос з іменем AutoExec запускається автоматично при
відкритті бази даних. Тимчасово відмінити автоматичний за-
пуск цього макроса можна за допомогою утримання клавіші
«Shift» у момент відкриття бази даних. Використовуючи мож-
ливості автоматичного запуску макроса, зручно виконати різні
підготовчі операції над БД після її відкриття. До таких операцій
належать виведення заставки і відкриття головної кнопочної
форми.
Створені макроси можуть запускатися користувачем, викли-
катися з інших макросів чи програм на Visual Basic, а також
з’являтись при виникненні певних подій. Події можуть виникати
в результаті дій користувача (натиснення кнопки мишки, від-
криття чи закриття форми, звіту, зміна даних) або генеруватись
системою чи виникати в результаті виконання програм на Visual
Basic.
199
 Автоматично викликатись макрос може при виникненні подій
у формах та звітах. Усі події за їх функціональними ознаками
можна згрупувати таким чином:
 події даних виникають при введенні, вилученні чи зміні да-
них у формі чи елементі управління, а також при переміщенні
фокуса з одного запису на інший;
 події клавіатури виникають при введенні з клавіатури, а та-
кож при передачі натиснень клавіш макрокомандам Команды-
Клавиатуры (SendKeys) чи інструкції SendKeys;
 події мишки виникають при діях з мишкою, наприклад при
натисненні кнопки мишки чи при утриманні кнопки в натисне-
ному положенні;
 події друку виникають при друкування звіту чи при його
форматуванні до друку;
 події фільтра виникають при створенні чи використанні фі-
льтра у формі;
 події вікна виникають при відкритті, зміні розмірів чи за-
критті форми або звіту;
 події помилки і таймера використовуються при обробці по-
милок і синхронізації даних у формах або звітах;
 події фокуса виникають, коли форма або елемент управління
втрачають чи отримують фокус, а також у момент, коли форма
або звіт становляться активними чи неактивними.
Для організації обробки події потрібно в рядку властивості ці-
єї події (форма, звіт чи елемент управління) ввести ім’я макроса
чи вибрати елемент [Процедура обработки события] і натисну-
ти кнопку Построителя. В останньому випадку можна напи-
сати необхідну програму на VBA.

Рис. 6.67. Створення процедури обробки події

200
 У нашому випадку (рис. 6.67) у вікні События поля Кіль-
кість у рядку До обновления вказано ім’я макроса Умова видачі,
який перевіряє умову, аби кількість, що відпускається, не пере-
вищувала наявні залишки.

6.9. Адміністрування та захист в Access

Access надає користувачеві цілий арсенал засобів ад-

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

6.9.1. Стиснення і відновлення файлів баз даних

Адміністратор періодично повинен стискати таблиці бази

даних, в які вносяться зміни шляхом вилучення даних. Особливість
Access полягає в тому, що після вилучення даних з бази залишають-
ся порожні місця на диску, що призводить до значної фрагментації
БД. Таким чином, після стиснення проводиться реорганізація і зві-
льняється дисковий простір, що вивільнився після вилучення даних.
Процедура стиснення бази даних виконується командою меню
Сервис/Служебные программы/Сжать базу данных.
Процедура стиснення БД подібна до процедури дефрагмента-
ції диску, що входить до складу Windows. У результаті стиснення
збільшується швидкість роботи Асcеss.
Якщо з’являється повідомлення про пошкодження бази даних,
то найвірогідніше причиною цих порушень є збій у роботі апара-
тних засобів. База даних може бути також пошкоджена в резуль-
таті виключення живлення в момент запису файла бази даних на
диск. Щоб спробувати відновити базу даних, виберіть команду
Сервис/Служебные программы/Восстановить базу данных.
Якщо таким чином БД не буде відновлена, то необхідно для від-
новлення використати останню резервну копію.
У деяких випадках необхідно також відновлювати файли mda
і mdw, що містять інформацію про облікові записи користувачів
бази даних.

201
 В деяких ситуаціях не вдається визначити, чи пошкоджена ба-
за даних. Якщо база даних веде себе непередбачено, виконайте
такі дії.
Відновлення відкритої бази даних.
Виберіть в меню Сервис команду Служебные программы і
підкоманду Восстановить базу данных.
Відновлення невідкритої бази даних.
1. Закрийте активну базу даних.
2. Виберіть в меню Сервис команду Служебные программы
і підкоманду Восстановить базу данных.
3. Зазначте ім’я і каталог бази даних, що відновлюється і на-
тисніть кнопку Восстановить.

6.9.2. Шифрування і дешифрування файлів баз

даних

Шифрування — це захист бази даних від несанкціоно-

ваного доступу. Інформація в зашифрованому вигляді не доступна
для читання. Шифрування бази даних деяким чином уповільнює
роботу Access, оскільки витрачається час на її дешифрування.

Рис. 6.68. Діалогове вікно для вибору бази даних для шифрування

Шифрування та дешифрування бази даних можуть виконувати

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

202
рення зашифрованої або дешифрованої копії бази даних. У про-
цесі цих двох операцій Асcess створює копію файла.
2. На всіх робочих станціях необхідно закрити базу даних, що
підлягає шифруванню.
3. Активізувати команду Сер-
вис/Защита/Шифрование/Дешифрование.
4. З’явиться вікно (рис. 6.68) вибору бази даних для шифру-
вання, в якому вибираємо базу даних і тиснемо ОК.
Якщо вибрана база даних не зашифрована, то відкриється вік-
но Шифрование базы даных под именем, в якому буде запро-
поновано нове ім’я для зашифрованої бази даних. Якщо ж вибра-
на база даних була зашифрована, то з’явиться вікно
Дешифрование базы даных под именем.
4. Вибирається ім’я файла для нової зашифрованої чи дешиф-
рованої бази даних. Натискаємо кнопку Сохранить.
У процесі шифрування або дешифрування Асcess стискає базу
даних.

6.9.3. Створення файлів MDE

Створення файлів MDE — це засіб захисту форм, звітів

і модулів. Якщо база даних вміщує програми Visual Basic, то її
зберігання як MDE-файла скомпілює всі модулі, вилучить всі по-
чаткові тексти програм і виконає стиснення БД. Програми Visual
Basic виконуватиметься, але їх не можна переглянути чи змінити,
завдяки чому зменшується розмір БД. Крім того, буде оптимізо-
вано використання пам’яті, що збільшить швидкість дії.
Зберігання БД як MDE-файла робить неможливим виконання
таких дій:
 перегляд, зміна чи створення форм, звітів або модулів у ре-
жимі Конструктора;
 зміна назв об’єктів БД;
 зміна модулів на Visual Basic;
 експортування лише таблиць, запитів і макросів.
Порядок створення MDE-файла.
1. Закрийте базу даних на всіх робочих станціях.
2. Виберіть в меню Сервис команду Служебные программы
і підкоманду Создать MDE-файл.
3. У діалоговому вікні База данных для зберігання як MDE
вкажіть базу даних, яку потрібно зберегти як MDE-файл, і натис-
ніть кнопку Создать MDE.
203
 4. У діалоговому вікні Сохранение файла MDE вкажіть ім’я,
диск і папку для бази даних.
Перед створенням файла MDE необхідно обов’язково зберег-
ти початкову копію бази даних. У базі даних, що зберігається як
MDE-файл, не можна змінювати структуру форм, звітів і моду-
лів. Це можна зробити в копії початкової бази даних, а потім зно-
ву перетворити її на MDE-файл.

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

допомогою аналізатора швидкості дії

Для проведення роботи щодо підвищення продукти-

вності бази даних за допомогою аналізатора необхідно відкри-
ти базу даних. У меню Сервис вибрати команду Анализ і під-
команду Быстродействие, потім — закладку Объект базы
данных, який необхідно оптимізувати. Виберіть закладку Все
для перегляду всіх об’єктів бази даних. Потім вибираються
імена тих об’єктів бази даних, які необхідно оптимізувати. Для
вибору всіх об’єктів натискається кнопка Выделить все і кно-
пка ОК.
Буде видано список пропозицій з оптимізації з відповідни-
ми назвами: Совет, Предложение і Мысль. Дії з оптимізації
пов’язані з певними компромісами, про які слід знати, перш
ніж приступити до цього процесу. Необхідно познайомитись зі
змістом пропозицій щодо оптимізації, які наводяться у полі
Примечание по кожній пропозиції окремо. Дії з оптимізації,
які вказуються під назвами Совет і Предложение, виконують-
ся Access автоматично при натисненні кнопки Оптимизация.
Після виконання оптимізації вибрана рекомендація буде відмі-
чена як виконана. Дії, що вказуються під назвою Мысль, не-
обхідно згідно з рекомендаціями в поле Примечание виконати
вручну.

6.9.5. Захист даних в Access

Access забезпечує два традиційних способи захисту ба-

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

Створення паролю бази даних

1. Обов’язково закрийте БД. Якщо вона використовується в

мережі, необхідно, щоб і всі інші користувачі її закрили.
2. Зробіть резервну копію БД.
3. Виберіть в меню Файл команду Открыть.
4. Встановіть прапорець Монопольный доступ і відкрийте БД.
5. У меню Сервис виберіть команду Защита і підкоманду
Задать пароль базы данных.
6. Введіть пароль у поле Пароль. Пароль вводиться з ураху-
ванням регістра.
7. Необхідне підтвердження паролю для чого він вводиться
повторно в поле Подтверждение, а потім натискаємо на кнопку
ОК. При наступному відкритті бази даних видаватиметься вікно з
проханням ввести пароль. Якщо ви його забули, то відновити йо-
го неможливо, тому паролі по кожній базі відповідно треба збері-
гати десь у надійному місці.
Не можна використовувати пароль, якщо база даних буде реп-
лікована. Репліковані бази даних не зможуть бути синхронізова-
ними, якщо на них визначений пароль.
Не можна встановлювати пароль на базу даних, якщо для неї
визначено захист на рівні користувача, і користувач не є адмініс-
тратором бази даних.

Зняття паролю бази даних

1. Виберіть в меню Файл команду Открыть.

2. Установіть прапорець Монопольный доступ і відкриту
базу даних.
205
 3. У діалоговому вікні Требуется пароль введіть пароль для
бази даних і натисніть кнопку OK. Пароль вводиться з урахуван-
ням регістра.
4. У меню Сервис виберіть команду Защита і виберіть опції
Удалить пароль базы данных. Ця опція доступна лише тоді,
коли пароль бази даних уже встановлено.
5. У полі Снять пароль базы данных введіть поточний паро-
ль і натисніть кнопку OK.

Захист на рівні користувача

При активізації захисту на рівні користувача адміністратор ба-
зи даних чи її власник надає певний дозвіл на доступ до об’єктів
бази даних (таблиці, запити, форми, звіти, макроси чи модулі)
окремим користувачам і групам користувачів.
Цей захист подібен до засобів захисту, що використовуються
у більшості мереж. Основними інструментами є робоча група,
файл робочої групи та реєстраційні (облікові) записи.
Робочою групою називається група користувачів, яка працює з
однією базою даних і має спільний файл робочої групи.
Файл робочої групи – це системний файл з інформацією про
групу користувачів, що працює в багатокористувацькому середо-
вищі з базою даних. У файлах робочих груп зберігаються облікові
записи про користувачів, а також дані про права доступу до
об’єктів бази даних. У середині файла робочої групи користувачі
ідентифікуються як члени.
При інсталяції Access за замовчуванням створюється стандар-
тний файл робочої групи SYSTEM.MDW, який зберігається в па-
пці Access. Він використовується програмою до створення ново-
го файла робочої групи. Зміна стандартного або створення
нового файла робочої групи виконується програмою Админист-
ратор рабочих групп (Wrkgadm), яка знаходиться у підпапці
System папки Windows.
Як правило, для архітектури клієнт-сервер необхідно створю-
вати три групи користувачів:
Адміністратори (група Admins), які мають право перегляду,
оновлення та вилучення таблиць, а також створення нових таб-
лиць і будь-яких інших об’єктів БД. Крім того, адміністратор має
право змінювати додатки до бази даних.
Постійні члени робочих груп (група Users-користувачі), які
мають право відкривати БД і відповідно до визначених повнова-
жень доступу до конкретних об’єктів переглядати і змінювати
206
інформацію. Як правило, члени цієї робочої групи не мають прав
змінювати додатки до бази даних. В Access всі члени групи адмі-
ністраторів є одночасно членами групи користувачів.
Тимчасові користувачі БД (Guestеs-гості), які мають дуже
обмежені права і не мають свого облікового запису. В Access-97
група Guestos не визначена.
Access за замовчуванням створює дві групи: адміністратори
(група Admins) і користувачі (група Users). У більшості випадків
цих двох груп досить. Необхідність створення нової групи вини-
кає тоді, коли з’явиться група користувачів, права яких відрізня-
ються від прав групи Users. Наприклад, можуть бути користува-
чі, яким дозволено лише введення даних.
Після установки Access користувач отримує права доступу
до всіх об’єктів бази даних і становиться членом групи Admins
з іменем Admin і автоматично отримує всі можливі права.
Оскільки за замовчуванням пароль у цьому обліковому записі
не створюється, то його не потрібно вводити при вході в сис-
тему.
Крім адміністратора, може бути зазначений власник бази да-
них. За замовчуванням користувач, який створив об’єкт, стає йо-
го власником і має права на роботу з ним.
Адміністратори і власники мають особливі права. Адміністра-
тор завжди може отримати права доступу до всіх об’єктів, ство-
рених членами його групи. Власник бази даних завжди може її
відкрити. Власник об’єкта має повні права доступу до цього
об’єкта.
Члени групи Admins мають право на модифікацію бази дан-
них. Для реєстрації входу в систему і захисту від вільного входу
в неї необхідно встановити пароль для адміністратора в реєстра-
ційному запису Admin.

Створення паролю облікового запиту

Для реєстрації входу в систему виконуються такі дії:

1. Запустіть Access, вказавши робочу групу, і відкрийте базу
даних.
У меню Сервис в опції Защита виберіть команду Пользова-
тели и группы.
2. У вікні, що відкриється, активізуйте закладку Изменение
пароля і введіть пароль у поле Новый пароль. Поле Текущий
повинно залишатись порожнім. Пароль може мати довжину від
207
1 до 14 знаків і включати будь-які символи, крім 0 кода ASCII.
При введенні пароля замість символів відображаються зірочки
(*). Необхідно пам’ятати, що при вводі пароля враховується
регістр.
Перевірте пароль шляхом повторного його введення у вікні
Подтверждение і клацніть по кнопці ОК.
3. При наступному запуску Access на екрані з’явиться діало-
гове вікно Вход для введення паролю. У полі Имя цього вікна
необхідно ввести ім’я користувача (в нашому випадку — Admin),
а в полі Пароль — пароль. Після натиснення на кнопку ОК
програма продовжить роботу, якщо пароль було введено пра-
вильно.
Пароль облікового запису вилучається таким чином:
1. Запустіть Access і в меню Сервис в підменю Защита акти-
візуйте команду Пользователи и группы.
2. У вікні, що відкриється, перейдіть на закладку Пользова-
тели і, впевнившись, що в полі Имя вказане правильне ім’я ко-
ристувача, натисніть на кнопку Снять пароль.

Зміна файла робочої групи

Поточна робоча група вказується у файлі робочої групи, ім’я

якого відображається у діалоговому вікні програми Админист-
ратора рабочих групп (рис. 6.69).

Рис. 6.69. Вікно адміністратора робочих груп

Для виклику цієї програми необхідно двічі клацнути мишкою

на програмі Wrkgadm у вікні Проводник.
Для внесення змін у файл робочих груп у вікні Администра-
тор рабочих групп необхідно натиснути на кнопку Связь, після
чого з’явиться вікно Файл рабочей группы (рис. 6.70).
208
 Рис. 6.70. Вікно для вибору файла робочої групи

У поле База данных введіть ім’я нового файла робочої групи.

Можна також відшукати та вибрати цей файл за допомогою кноп-
ки Обзор. Після натиснення на кнопку ОК буде видане повідом-
лення про встановлення зв’язку з новою робочою групою.
Щоб створити новий файл робочої групи, необхідно натиснути
кнопку Создать у вікні Администратор рабочих групп, після чо-
го відкриється вікно Сведения о владельце рабочей группы, ку-
ди слід внести відповідні дані. У поле Имя вводиться ім’я власника,
в поле Організація — назва організації, а в поле Код группы —
код робочої групи, який може бути будь-якою комбінацією з літер
та цифр, але не більше 20 символів. При введенні кода враховуєть-
ся регістр клавіатури. Після введення перелічених даних натисніть
ОК. Код робочої групи можна не вводити. На екрані з’явиться вік-
но Файл рабочей группы, поле База данных якого вміщує повне
ім’я існуючої робочої групи. У необхідності можна ввести нове
ім’я і натиснути ОК. Новий системний файл робочої групи буде
використаним лише після наступного запуску Access.
Файл робочої групи не обов’язково розміщувати в папку з
файлом бази даних. Відомості про файл і код робочої групи варто
записати і зберігати. Ці відомості можуть бути необхідними при
відновленні файла робочої групи. Якщо ж ці дані загубляться, то
відновити базу даних не буде можливості.

Облікові записи
Після створення робочої групи можна заносити облікові (ре-
єстраційні) записи. Оскільки реєстраційний запис Admin одина-
ковий для всіх копій Access, для захисту бази даних необхідно
включити нового користувача в групу Admins чи замінити адміні-
стратора Admin.
Для включення нового користувача в групу Admins необхідно:
1. Запустити Access, вибравши робочу групу, і відкрити базу
даних.
209
 2. У підменю Защита меню Сервис вибрати команду Поль-
зователи и группы.
3. У вікні, що відкриється (рис. 6.71), вибрати закладку Поль-
зователи і натиснути на кнопку Создать.

Рис. 6.71. Діалогове вікно для створення нового користувача

У наступному вікні (рис. 6.72) у полі Имя вводиться ім’я об-

лікового запису (користувача), а в полі Код — унікальний код
запису (будь-яка комбінація символів від 4 до 20 знаків). Натис-
каємо кнопку ОК.

Рис. 6.72. Вікно для введення імені та кода облікового запису користу-
вача

Ім’я користувача може мати довжину від 1 до 20 символів і

включати букви, цифри, пробіли та інші символи, за винятком
таких: " \ []: < > + = ; , * ? | і керуючих символів (з кодами ASCII

210
від 00 до 31). Крім того, ім’я користувача не може починатися з
пробілу.
Після повернення у вікно Пользователи и группы виберіть у
списку Имеющиеся группы групу Admins і натисніть кнопку
Добавить. Група Admins буде розміщена в списку Участие в
группе, що забезпечить введення облікового запису в цю групу.
В кінці натисніть кнопку ОК.
При створенні облікового запису власника виконується така
сама послідовність операцій. Обліковий запис власника може бу-
ти занесеним у групу Admins чи іншу групу.
Крім облікових записів адміністратора і власника, створюють-
ся записи для користувачів та груп користувачів, які можуть мати
однакові права.
Для створення нової групи користувачів і відповідного облі-
кового запису необхідно активізувати команду Пользователи и
группы в подменю Защита меню Сервис і натиснути кнопку
Создать на закладинці Группы. У вікні, що відкриється в полі
Имя, вводиться ім’я групи, а в полі Код — унікальний код (будь-
яка комбінація символів від 4 до 20 знаків). Натискаємо кнопку
ОК. На ім’я групи накладаються ті ж обмеження, що і на ім’я ко-
ристувача.
Вилучення облікового запису користувача чи групи з робочої
групи виконується таким чином:
1. Запустіть Access з вибраною робочою групою і відкрийте
базу даних.
2. У підменю Защита меню Сервис виберіть команду Поль-
зователи и группы. У вікні, що відкриється, виберіть закладку
Пользователи (при вилученні облікового запису користувача) чи
Группа (при вилученні облікового запису групи).
3. Виберіть ім’я користувача чи групи в списку Имя і натис-
ніть кнопку Удалить. Підтвердіть необхідність вилучення у на-
ступному вікні, натиснувши кнопку Да.
4. Закрийте вікно Пользователи и группы.
Після створення облікових записів для користувачів і груп
взаємозв’язок між ними можна побачити при натисненні на кно-
пку Отчет о защите.

Зміна прав власності

Після інсталяції Access користувач Admin є власником будь-
якої бази даних і всіх об’єктів. Тому для захисту бази даних не-
обхідно змінити права володіння базою і всіма її об’єктами.
211
 Існує кілька варіантів зміни власника об’єктів бази даних:
1) імпорт всіх об’єктів бази даних у новий файл;
2) використання закладки Смена владельца діалогового вікна
Разрешения.
Послідовність виконання дій при зміні власника бази даних
першим способом така:
1) Запустіть Access з вибраною робочою групою.
2) Ввійдіть у систему під іменем нового власника бази даних.
3) Створіть нову (порожню) базу даних.
4) У підменю Внешние данные в меню Файл активізуйте ко-
манду Импорт.
5) У вікні Импорт вкажіть базу даних, власника якої необхід-
но змінити, і скопіюйте всі її об’єкти в нову базу даних.
Більш простий спосіб зміни власника складається з таких кроків:
1. Відкрийте базу даних і виберіть в меню Сервис команду
Защита.
2. У підменю, що відкриється, активізуйте команду Разре-
шения.
3. У діалоговому вікні, що з’явиться, відкрийте закладку
Смена владельца.
4. Виберіть тип об’єкта в спеціальному списку. В області
Об’єкт буде відображено список всіх об’єктів заданого типу, а в
області Текущий владелец — список власників. Виділіть у спи-
сок ті об’єкти, власника яких потрібно змінити.
5. В полі Новый владелец вкажіть обліковий запис користува-
ча, якому надаються права власника об’єктів. Якщо власником буде
група, то попередньо необхідно активізувати перемикач Группы.
6. Натисніть кнопку Сменить владельца.

Призначення та вилучення прав доступу

Access надає можливості системним адміністраторам надавати
чи знімати дозвіл на використання тих чи інших об’єктів бази да-
них усім або окремим членам групи. Отримавши такий дозвіл,
користувачі можуть переглядати чи змінювати окремі об’єкти
БД. Якщо дозвіл встановлюється для групи, то він автоматично
поширюється на всіх користувачів. Адміністратор може надавати
додаткові права окремим членам групи, але не може позбавити
його прав, наданих усій групі. Визначити права доступу можна,
викликавши в меню Сервис опцію Защита, і вибрати в ній ко-
манду Разрешения. Перелік прав доступу, визначених в Access,
наведено в таблиці.
212
 Таблиця

Права Дії Об’єкти Наявний до-

звіл

Відкрити/Запуск Відкрити базу даних, форми, Форми, Читання

звіти чи запуск об’єкта звіти,
макроси
Читання макету Перегляд об’єктів у режимі Запуск лише
Усі
конструктора для макроса
Зміна макета Перегляд, зміни і вилучення Оновлення
об’єктів у режимі конструктора Усі даних і запуск
Адміністратора Повний доступ до об’єктів і Немає
даних з можливістю присво- Усі
єння прав доступу
Читання даних Перегляд даних Таблиці, Читання ма-
запити і кета
форми
Оновлення даних Перегляд і зміни даних без Таблиці, Читання ма-
вставок і вилучень запити і кета
форми
Вставка даних Перегляд і вставка даних без Таблиці, Читання ма-
змін і вилучень запити і кета
форми
Вилучення даних Перегляд і вилучення даних Таблиці, Читання ма-
запити і кета
форми
Монопольний Відкриття бази даних у моно- Права адмі-
доступ польному режимі Усі ністратора

Визначити права доступу до деяких об’єктів може власник

об’єкта, адміністратор у робочій групі Admins або користувач,
якому присвоєні права адміністратора цього об’єкта. Всі права
доступу до об’єкта зберігаються при його змінах тільки в тих ви-
падках, якщо не використовувався буфер обміну чи не виконува-
вся імпорт/експорт об’єкта. Крім того, всі права, пов’язані з
об’єктом, можуть бути втраченими, якщо виконуватиметься ко-
манда його збереження з новим ім’ям, з використанням команди
Сохранить как/экспорт.
Для надання прав доступу до об’єктів бази даних користувачу,
що має право доступа, необхідно виконати такі дії:
1. Відкрийте базу даних.
213
 2. У меню Сервис у команді Защита активізуйте команду
Разрешения. У вікні (рис. 6.73), що відкриється, перейдіть на за-
кладку Разрешения.
3. У полі Тип объєкта виберіть тип, на який поширюються
нові права.

Рис. 6.73. Вікно для надання прав доступу до об’єктів

4. У списку Имя объєкта позначте об’єкти, доступ до яких

буде дозволений користувачу або групі, зазначеним у списку
Пользователи и группы.
5. Виберіть право доступа до відмічених об’єктів і натисніть
кнопку ОК.

Питання для самоперевірки

1. Визначте та характеризуйте основні об’єкти Access.

2. Які типи даних підтримує СУБД Access.
3. Охарактеризуйте порядок створення та роботи з табли-
цями в Access.
4. Охарактеризуйте порядок побудови та призначення схе-
ми даних.
5. Охарактеризуйте ліве та праве зовнішнє об’єднання і
вкажіть, коли ним доцільно користуватись.
214
6. Що таке тета — та самооб’єднання таблиць?
7. Перелічіть і коротко охарактеризуйте основні типи запи-
тів в Access.
8. Визначте випадки, коли редагування бази даних доцільно
виконувати за допомогою запитів.
9. В яких випадках доцільно формувати запити з парамет-
рами?
10. Інструменти отимізації запитів в Access.
11. Охарактеризуйте призначення та використання форм.
12. Перелічіть основні елементи управління формою, що за-
побігають помилковому введенню даних.
13. Поясніть призначення та дайте характеристику
зв’язаних і підпорядкованих форм.
14. Гіперпосилання у формах та їх призначення.
15. Звіти: їх види і порядок створення.
16. Макроси: порядок їх створення та призначення.
17. Охарактеризуйте призначення операцій стиснення та
відновлення бази даних.
18. Перелічіть основні засоби захисту від несанкціоновано-
го доступу в Access.
19. Які обмеження прав доступу може призначити адмініст-
ратор бази даних в Access?

215
 7 Pоздiл
ХАРАКТЕРИСТИКА МОВИ SQL

7.1. Загальна характеристика мови SQL

Мова SQL — це найпоширеніша прикладна мова реля-

ційних СКБД. Мова SQL (Structured Query Language — структу-
рована англійська мова запитів) була розроблена на початку 70-х
років співробітниками фірми IBM у рамках роботи над проектом
реляційних СКБД. Однією з переваг цієї мови є те, що вона набу-
ла статусу стандарту мови реляційних СКБД. Перший американ-
ський стандарт SQL був опублікований в 1986 р. і називався
ANSI X3.115-1986. Перша версія стандарту SQL-86 була прийня-
та ANSI і міжнародною організацією зі стандартів ISO. Сучасна
версія ANSI X3.115-1992 отримала скорочену назву SQL-92.
SQL — це множинно орієнтована мова, тобто вона не має ні
засобів управління потоками (розгалуження та організації
циклів), ні засобів організації інтерфейсу.

Існуючий на сьогодні стандарт — це одночасно підмножина

основних реалізацій мови та узагальнення майже всіх відомих її
реалізацій. Тобто ядро стандарту реалізовано практично у всіх
відомих комерційних версіях реалізації мови, а повний стандарт
включає такі вдосконалення, здійснення яких ще попереду. Хоча
для мови SQL прийняті стандарти, але вони не є жорсткими і до-
зволяють у реальній дійсності фірмам-розробникам для підтрим-
ки спеціальних функцій своїх програмних продуктів використо-
вувати різні діалекти мови і навіть розширювати її. Таким чином,
можливі відмінності в синтаксисі мови SQL різних СКБД. Для
вирішення проблеми розуміння різних діалектів мови SQL понад
30 західних фірм провідних розробників програмного і апаратно-
го забезпечення створили спеціальну групу — SQL Access. Перед
цією групою було поставлено завдання розробити такий варіант
базової мови SQL, який би можна було використовувати таким
чином, щоб системи мали змогу її допомогою спілкуватись між
собою. В результаті було створено Стандартний інтерфейс мови
(Common Language Interface, CLI) для всіх основних варіантів
мови SQL. Ці фірми взяли на себе зобов’язання вмонтувати в свої

216
програмні продукти такі засоби, які б дозволили будь-якому до-
датку за допомогою CLI мати доступ до їх баз даних.
Корпорація Microsoft розробила формалізований інтерфейс
CLI для робочих станцій, який дістав назву драйвера ODBC.
Останній дає змогу різним розробникам спілкуватись між собою
за допомогою стандарту SQL Access Group. Microsoft Access мо-
же спілкуватись з іншими СКБД за допомогою ODBC, а також
розуміє основні діалекти стандарту SQL Access Group.
Отже, мова SQL може бути реалізована такими способами:
Прямий виклик. Набір операторів SQL передається безпосере-
дньо програмі управління базами даних. Ця програма відповідає
на запит, створюючи таблицю з результатами виконання запиту, і
відображає її на екран.
Модульна мова. Програмістом створюється файл, який скла-
дається з операторів SQL, після чого ці оператори можуть бути
виконані додатком.
Вмонтований SQL. Найпоширеніша реалізація мови. Операто-
ри SQL генеруються прикладною програмою чи вмонтовуються в
програмний код як рядки тексту програми. Саме такий варіант
використання SQL реалізовано в СКБД Access.

7.2. Порівняльна характеристика мови JET SQL з

ANSI SQL

Мова Access SQL носить назву Microsoft Jet Database

Engine SQL (скорочено Jet SQL). Ця мова сумісна зі стандартом
SQL-89 Levell 1 і включає не всі ключові слова стандарту мови.
Велика кількість відсутніх у Jet ключових слів ANSI SQL заміне-
на виразами, створеними за допомогою операторів чи вмонтова-
них або користувацьких функцій Access VBA. Багато ключових
слів ANSI SQL, що не підтримуються Jet, замінено стандартними
командами Access, доступними з вікна бази даних чи меню. І на-
впаки, SQL ядра Microsoft Jet використовує зарезервовані слова і
засоби, які не підтримуються ANSI SQL.
Основні відмінності:
1. Різні правила, застосовані в операторі Between...And, який
має такий синтаксис:
Вираз [NOT] Between значення_1 And значення_2
У мові SQL Microsoft Jet значення_1 може перевищувати зна-
чення_2; в ANSI SQL значення_1 повинно бути менше чи дорів-
нювати значенню_2.
2. Різні знаки підстановки використовуються в операторі Like.
217
 Відповідні символи Мова SQL Microsoft Jet ANSI SQL
—
Будь-який одиночний символ ?
(підкреслювання)
Будь-яке число символів * %

Мова SQL ядра Microsoft Jet надає користувачеві більше

свободи. Наприклад, дозволяється групування і сортування ви-
разів.
3. Мова SQL Microsoft Jet має особливі засоби:
 оператор TRANSFORM — створення перехресних запитів
 додаткові статистичні функції: StDev і VarP;
 параметр PARAMETERS, призначений для створення запи-
тів з параметрами.
 4.Засоби ANSI SQL, що не підтримуються в мові SQL
Microsoft Jet:
 оператори, що управляють захистом, такі як COMMIT,
GRANT і LOCK;
 зарезервоване слово DISTINCT як опис аргумента статисти-
чної функції. Наприклад, у мові SQL Microsoft Jet не можна вжи-
вати вираз SUM(DISTINCT ім’я Стовпчика);
 вираз LIMIT TO nn ROWS, що використовується для обме-
ження кількості рядків, котрі повертаються як результат вико-
нання запиту. Для обмеження кількості рядків можна застосову-
вати лише WHERE.
Усі команди мови SQL за функціями можна поділити на такі
групи:
Мова опису даних (Data Definition Language, DDL). Включає
оператори СREATE TABLE і СREATE VIEW, які описують
структуру таблиць і режими відображення даних. Команди DDL
також використовуються для зміни структури таблиць, створення
і вилучення індексів. Разом з операторами DDL вживаються
ключові слова, що забезпечують цілісність даних.
Мова запиту даних (Data Query Language, DQL). Ця мова ви-
користовується для пошуку і вибірки даних з бази даних та їх ві-
дображення в результатних наборах даних. Головною інструкці-
єю цієї мови є команда SELECT. Іноді оператора DQL відносять
до мови маніпулювання даними.
Мова маніпулювання даними (Data Manipulation Language,
DML). До неї належать команди INSERT і DELETE, які дозволя-
ють додавати і вилучати рядки з таблиць, а також команда
UPDATE, яка вносить зміни окремих значень полів.
218
 Мова обробки трансакцій (Transaction Processing Language, TPL).
Включає команди DEGIN TRANS[ACTION], COMMIT [WORK],
ROOLBACK [WORK], які об’єднують кілька команд DML. Якщо
при виконанні трансакції пройшов збій, то попередні операції
відміняються і виконується відкат трансакції. Jet SQL не підтри-
мує TPL, тому для обробки трансакцій необхідно використовува-
ти методи BeginTrans, CommitTrans і Roolback мови Access VBA.
Мова управління курсором (Cursor Control Language, CCL).
Команди цієї мови дозволяють виділити для обробки один рядок
результатного набору записів. Такі конструкції, як UPDATE
WHERE CURRENT, обробляються безпосередньо ядром бази да-
них Jet, тому в даному посібнику не будуть розглядатись.
Мова управління даними (Data Control Language, DCL). Забез-
печує виконання адміністративних функцій надання та відміни
прав доступу до всієї бази даних (команди GRANT REVOKE),
набору таблиць чи спеціальним командам SQL. До складу Jet
SQL команди цієї мови не входять, тому для забезпечення захис-
ту необхідно використовувати вбудовані засоби Access.
Усі ключові слова можна, в свою чергу, поділити на такі кате-
горії:
Команди. Це дієслова, які визначають дії, котрі необхідно ви-
конати, наприклад SELECT.
Умови. Обмежують діапазон значень елементів, що входять до
запиту, наприклад WHERE.
Модифікатори. Змінюють виконання команди, наприклад
ORDER BY.
Оператори. Порівнюють значення полів і застосовуються в
умовах відбору записів, а також для створення міжтабличних
зв’язків.
Статистичні (агрегатні) функції. Повертають одне результа-
тне значення, яке обчислюється для певного набору даних.
Інші ключові слова, що змінюють дії команд чи управляють
курсором (указником поточного запису), за допомогою якого ви-
бираються окремі рядки запиту.

7.3. Мова опису даних DDL

Мова DDL є підмножиною мови SQL, за допомогою

якої можна створювати та вилучати об’єкти бази даних. До основ-
них операторів цієї мови належать:
 CREATE TABLE — створює нову таблицю;

219
  CREATE INDEX — створює індекс для існуючої таблиці;
 ALTER TABLE — за допомогою цього оператора можна до-
давати нові поля в таблицю чи вилучати існуючі;
 DROP — вилучає існуючу таблицю з бази даних або вилу-
чає існуючий індекс з таблиці.

7.3.1. Оператор CREATE TABLE

Оператор CREATE TABLE створює нову таблицю. Він

має такий синтаксис:
CREATE TABLE таблиця (поле_1 тип (розмір))
[NOT NULL] [індекс_1] [, поле_2 тип (розмір)
[NOT NULL] [індекс_2] [,. ..]] [, CONSTRAINT складовий ін-
декс [,. ..]])
Охарактеризуємо складові оператора CREATE TABLE:
таблиця — ім’я таблиці, що створюється;
поле_1, поле_2 — імена полів нової таблиці;
тип — тип даних поля в новій таблиці;
розмір — розмір поля в символах (тільки для текстових і двій-
кових полів);
індекс_1, індекс_2 — oпція CONSTRAINT дозволяє створювати
прості чи складові індекси (детальніший опис цієї опції див. 7.3.2).
Оператор CREATE TABLE використовується для опису нової
таблиці, її полів і індексів. Якщо для поля встановлено обмежен-
ня NOT NULL, то при додавані нових записів це поле повинно
містити допустимі дані.
Опція CONSTRAINT встановлює різні обмеження на полі і
може бути використане для визначення ключа. Крім того, для
створення ключа або додаткового індексу для існуючої таблиці
можна використати оператор CREATE INDEX.
Допускається використання обмеження NOT NULL для оди-
ночного поля, а також усередині іменованої опції CONSTRAINT.
Обмеження NOT NULL можна накласти на поле тільки один раз.

7.3.2. Опція CONSTRAINT

Створення обмеження за допомогою опції CONSTRAINT

подібне до визначення індексу, хоча воно також застосовується
для встановлення відносин між таблицями. Ця опція використову-
ється в операторах ALTER TABLE і CREATE TABLE для створен-
220
ня чи вилучення індексів. Існують два типи опції CONSTRAINT:
одна для створення простого індексу (по одному полю); друга —
для створення складового індексу (по кількох полях).
Ця опція має такий синтаксис
Простий індекс:
CONSTRAINT ім’я {PRIMARY KEY ¦ UNIQUE ¦ NOT NULL ¦
REFERENCES зовнішня таблиця (зовнішнєПоле_1, зовнішнє-
Поле_2)}
Складовий індекс:
CONSTRAINT ім’я
{PRIMARY KEY (ключове_1[, ключове_2 [,. ..]]) ¦
UNIQUE (унікальне_1[, унікальне_2 [,. ..]]) ¦
NOT NULL (непорожнє_1[, непорожнє_2 [,. ..]]) ¦
FOREIGN KEY (посилання_1[, посилання_2 [,. ..]])
REFERENCES зовнішня таблиця (зовнішнєПоле_1, зовнішнє
Поле_2)}
Охарактеризуємо складові опції CONSTRAINT:
ім’я — ім’я індексу, який потрібно створити;
ключове_1, ключове_2 — імена одного або кількох полів, які
визначаються як ключові;
унікальне_1, унікальне_2 — імена одного або кількох полів,
які потрібно включити в унікальний індекс;
непусте_1, непусте_2 — імена одного або кількох полів, в
яких забороняються значення Null;
посилання_1, посилання_2 — імена одного або кількох полів,
включених у зовнішній ключ, які містять посилання на поля в
іншій таблиці;
ЗовнішняТаблиця — ім’я зовнішньої таблиці, яка містить поля,
вказані за допомогою аргументу зовнішнєПоле;
зовнішнєПоле_1, зовнішнєПоле_2 — імена одного або кількох
полів у ЗовнішнійТаблиці, на які посилаються поля, вказані за до-
помогою аргументу посилання_1, посилання _2. Цю опцію мож-
на пропустити, якщо дане поле є ключем Зовнішньої Таблиці.
Опція CONSTRAINT, призначена для створення простого ін-
дексу, розташовується відразу після опису типу поля в оператора
ALTER TABLE або CREATE TABLE.
Для формування унікального індексу використовується заре-
зервоване слово UNIQUE.
Для створення ключа таблиці, що складається з одного або кі-
лькох полів, необхідно використовувати зарезервовані слова
PRIMARY KEY, для зовнішнього ключа — зарезервовані слова
FOREIGN KEY. Якщо ключ зовнішньої таблиці складається з кі-

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

7.3.3. Оператор CREATE INDEX

За допомогою оператора CREATE INDEX створюється

новий індекс для існуючої таблиці.
Оператор має такий синтаксис:
CREATE [ UNIQUE ] INDEX індекс
ON таблиця (поле [ASC¦DESC][, поле [ASC¦DESC],. ..])
[WITH { PRIMARY ¦ DISALLOW NULL ¦ IGNORE NULL }]
Охарактеризуємо складові оператора CREATE INDEX:
індекс — ім’я індексу, що створюється;
таблиця — ім’я існуючої таблиці, для якої створюється ін-
декс;
поле — імена одного або кількох полів, що включаються в
індекс.
Для створення простого індексу (що складається з одного поля)
ім’я поля в круглих дужках вводиться відразу після імені таблиці.
Для створення складового індексу (що складається з кількох полів)
вказуються імена всіх полів. Для розташування елементів індексу
в спадаючому порядку застосовується зарезервоване слово DESC;
в іншому разі буде прийнято порядок за зростанням.
Для заборони збігу значень індексованих полів у різних запи-
сах використовується зарезервоване слово UNIQUE.
Необов’язкова опція WITH дозволяє задати умови на значення.
За допомогою параметра DISALLOW NULL забороняється
значення Null в індексованих полях нових записів.
За допомогою параметра IGNORE NULL забороняється вклю-
чення в індекс записів, що мають значення Null в індексованих
полях.
За допомогою зарезервованого слова PRIMARY індексовані
поля призначаються ключем. Такий індекс за замовчуванням є
унікальним, тому зарезервоване слово UNIQUE можна опустити.

222
 Оператор CREATE INDEX дозволяє створити тимчасовий ін-
декс для приєднаної таблиці, яка ще не має індексу, з такого дже-
рела даних ODBC, як SQL Server.

7.3.4. Оператор ALTER TABLE

Оператор ALTER TABLE використовується для вне-

сення змін до існуючої таблиці. За допомогою цього оператора
можна додавати нові поля у таблицю або вилучати існуючі.
Оператор має такий синтаксис:
ALTER TABLE таблиця {ADD {COLUMN поле тип(розмір)
[NOT NULL]
[CONSTRAINT індекс] ¦ CONSTRAINT складовийІндекс} ¦
DROP {COLUMN поле I CONSTRAINT ім’яІндекса} }
Охарактеризуємо складові оператора ALTER TABLE:
таблиця — ім’я змінної таблиці;
поле — ім’я поля, що додається в таблицю або вилучається з неї;
тип — тип даних поля;
розмір — розмір поля в символах (тільки для текстових і двій-
кових полів);
індекс — індекс для поля;
складовийІндекс — опис складового індексу, що додається до
таблиці;
ім’яІндекса — ім’я складового індексу, який потрібно вилучити.
За допомогою оператора ALTER TABLE існуючу таблицю
можна змінити кількома способами. Наприклад:
1. Додати нове поле в таблицю за допомогою опції ADD
COLUMN. Наприклад, наступний оператор додає в таблицю
«Деталь» текстове поле «Примітки» довжиною 25 символів:
ALTER TABLE Деталь ADD COLUMN Примітки TEXT(25)
2. Якщо для поля додане обмеження NOT NULL, то при дода-
ванні нових записів це поле повинно містити допустимі дані.
3. Можна додати складовий індекс за допомогою зарезервова-
них слів ADD CONSTRAINT.
4. Вилучити поле можна за допомогою зарезервованих слів
DROP COLUMN. У такому разі вказується лише ім’я поля, що
вилучається.
5. Вилучити складовий індекс можна за допомогою зарезерво-
ваних слів DROP CONSTRAINT. У даній ситуації зазначається
лише ім’я складового індексу.
Не можна додати або вилучати одночасно кілька полів або ін-
дексів.
223
 7.3.5. Оператор DROP

Оператор DROP вилучає існуючу таблицю з бази да-

них або вилучає існуючий індекс з таблиці.
Синтаксис цього оператора має такий вигляд:
DROP {TABLE таблиця ¦ INDEX індекс ON таблиця}
Характеристика складових оператора DROP:
таблиця — ім’я таблиці, яку потрібно вилучити або з якої по-
трібно вилучити індекс;
індекс — ім’я індексу, що вилучається з таблиці.
Перш ніж вилучити таблицю або вилучити з неї індекс, необ-
хідно її закрити.
Крім того, для вилучення індексу з таблиці можна використа-
ти інструкцію ALTER TABLE.

7.4. Мова запиту даних DQL

До мови запитів належать такі оператори:

SELECT — запит вибірки записів таблиці за певними умовами;
SELECT…. INTO — запит на створення нової таблиці.

7.4.1. Оператор SELECT

Оператор SELECT є ядром мови SQL Microsoft Jet. Він

використовується для вибірки чи перегляду рядків таблиць бази
даних, які необхідні користувачеві. Синтаксис оператора має та-
кий вигляд:
SELECT [предикат] { * ¦ таблиця.* ¦ [таблиця.]поле_1
[AS псевдонім_2] [, [таблиця.]поле_2 [AS псевдонім_2] [,. ..]]}
FROM вираз [,. ..] [IN зовнішняБазаДаних]
[WHERE... ]
[GROUP BY... ]
[HAVING... ]
[ORDER BY... ]
[WITH OWNERACCESS OPTION]
Характеристика складових оператора SELECT:
предикат — один з наступних предикатів відбору: ALL,
DISTINCT, DISTINCTROW або TOP. Предикати використову-
ються для обмеження числа записів, що повертаються. Якщо во-
ни відсутні, за замовчуванням застосовується предикат ALL.

224
 DISTINCT — виключає записи, які містять значення, що по-
вторюються у вибраних полях. Щоб запис був включений у ре-
зультаті виконання запиту, значення в кожному полі, включено-
му в інструкцію SELECT, повинні бути унікальними.
DISTINCTROW — пропускає дані, що ґрунтуються на запи-
сах, які цілком повторюються, а не окремих полів, що повторю-
ються. Предикат DISTINCTROW впливає на результат тільки в
тому разі, коли до запиту включені не всі поля з таблиць, що
аналізуються. Предикат DISTINCTROW ігнорується, якщо запит
містить тільки одну таблицю або всі поля всіх таблиць.
TOP n [PERCENT] — повертає певне число записів, що зна-
ходяться на початку або в кінці діапазону, описаного за допомо-
гою пропозиції ORDER BY;
* — вказує, що вибрані всі поля заданої таблиці або таблиць;
таблиця — ім’я таблиці, з якої повинні бути відібрані записи;
поле_1, поле_2 — імена полів, з яких вибираються дані. Якщо
задано кілька полів, вони вибираються у визначеному порядку;
псевдонім_2, псевдонім_2 — імена, які стануть заголовками
стовпчиків замість початкових назв стовпчиків у таблиці;
вираз — імена однієї або кількох таблиць, які містять дані, що
відбираються;
зовнішняБазаДаних — ім’я бази даних, яка містить таблиці,
вказані за допомогою опції вираз, якщо вони не знаходяться в
поточній базі даних.
Оператор SELECT не змінює дані в базі даних.
Звичайно слово SELECT є першим словом оператора SQL.
Нижче наведено мінімальний синтаксис оператора SELECT:
SELECT поля FROM таблиця.
Порядок таблиць у виразі не суттєвий. Для відбору всіх полів
таблиці можна використати символ зірочки (*). Наприклад, опе-
ратор відбирає всі поля з таблиці «Деталь»:
SELECT * FROM Деталь.
Якщо кілька таблиць, включених до опції FROM, містять од-
нойменні поля, перед ім’ям такого поля потрібно ввести ім’я таб-
лиці і оператор . (крапка).
Наприклад, якщо поле «Відділ» міститься в таблицях «Спів-
робітники» і «Керівники», то оператор SELECT відбере поле
«Відділ» з таблиці «Співробітники» і поле «Керівник» з таблиці
«Керівники»:
225
 SELECT Співробітники.Відділ,Керівники.Керівник
FROM Співробітники INNER JOIN Керівники
WHERE Співробітники.Відділ = Керівники.Відділ;
Якщо в результаті виконання потрібне інше ім’я поля, то ви-
користовується зарезервоване слово AS. У наступному прикладі
заголовок «Народження» стає ім’ям поля у результуючому наборі:
SELECT [Дата народження]
AS Народження FROM Співробітники;
При роботі зі статистичними функціями або запитами, які по-
вертають імена об’єкта, що повторюють поля, використовується
опція AS для іншого імені поля. В наступному прикладі заголо-
вок «Чисельність» задається для поля результуючого об’єкта.
SELECT COUNT(КодСпівробітника)
AS Чисельність FROM Співробітники;

7.4.1.1. Речення FROM

Речення FROM повинно бути в кожному операторі

SELECT. При цьому порядок таблиць у виразі не важливий.
Речення WHERE визначає умови вибірки, тобто які рядки з таб-
лиці в реченні FROM необхідно включати в результат виконання
запиту. Якщо не задавати WHERE, то результатом запиту будуть
усі рядки таблиці. Речення WHERE є необов’язковим. Якщо в запи-
ті беруть участь кілька таблиць і не задано речення WHERE, то ре-
зультатом його виконання буде скалярний добуток таблиць.
Розглянемо приклад вибірки з таблиці Матеріал — назви та
ціни матеріалів, ціна яких перевищує 1000 грн.
SELECT Назва _матеріала, Ціна
FROM Матеріал WHERE Ціна>1000;
Речення WHERE може вміщувати до 40 виразів, зв’язаних ло-
гічними операторами, такими як And і Or.
Імена полів, що мають пробіли чи розділові знаки, необхідно
заключати в квадратні дужки ([ ]).

7.4.1.2. Речення GROUP BY

Це речення є необов’язковим. Воно використовується при фор-

муванні підсумкових запитів. GROUP BY об’єднує записи з од-
наковими значеннями в указаному списку полів в один запис.

226
Якщо оператор SELECT вміщує статистичну функцію, наприклад
SUM, то для кожного запису буде розраховано підсумок.
Так, визначимо максимальну ціну матеріалу кожного типу.
SELECT КодТипу, Max (Ціна) AS МаксимальнаЦіна FROM
Матеріал GROUP BY КодТипу;

7.4.1.3. Речення HAVING

Це речення є необов’язковим. Після того як записи бу-

дуть згруповані за допомогою GROUP BY, речення HAVING
відбере ті з отриманих записів, які задовольнять умовам вибірки,
що вказані в реченні HAVING. Речення HAVING схоже на ре-
чення WHERE, котре визначає, які записи повинні бути відібра-
ними. Після того, як записи будуть згруповані за допомогою
GROUP BY, речення HAVING вказує, які з отриманих записів
повинні бути відібраними:
SELECT КодГрупи,
Sum(ВМагазині)
FROM Товари
GROUP BY КодГрупи
HAVING Sum(ВМагазині) > 100 And Like «МО*»;
Речення HAVING може вміщувати до 40 виразів, зв’язаних
логічними операторами, такими як And і Or.

7.4.1.4. Речення ORDER BY

Сортує записи, що отримані в результаті виконання за-

питу за зростанням чи спаданням значень указаних полів.
Це речення має такий синтаксис:
[ORDER BY поле_1 [ASC | DESC ][, поле_2 [ASC | DESC ]][, ...]]]
поле_1, поле_2 — імена полів, за якими сортуються записи.
Речення ORDER BY є необов’язковим. Але його необхідно
вказувати, якщо потрібно відсортувати результати запиту.
За замовчуванням задається порядок сортування за зростан-
ням (від «A» до «Я» і від 0 до 9). Обидва наведених нижче опера-
тори SQL однаково сортують записи за прізвищами співробітни-
ків Кафедри:
227
 SELECT Прізвище, Ім’я
FROM Кафедра
ORDER BY Прізвище;
SELECT Прізвище, Ім’я
FROM Кафедра
ORDER BY Прізвище ASC;
Для сортування за спаданням (від «Я» до «A» і від 9 до 0) не-
обхідно додати зарезервоване слово DESC після імені кожного
поля, яке потрібно відсортувати за спаданням. У наведеному ни-
жче операторі SELECT виконується вибірка окладів співробітни-
ків таблиці Кафедра, які сортуються за спаданням:
SELECT Прізвище, Оклад
FROM Кафедра
ORDER BY Оклад DESC, Прізвище;
Речення ORDER BY, як правило, є останнім елементом опера-
тора SQL.

7.4.1.5. Опція WITH OWNERACCESS OPTION

Опція WITH OWNERACCESS OPTION є необов’язковою. ЇЇ

наявність надає іншим користувачам мережі ті самі права, які є у
користувача, що виконує запит. Цю опцію зручно використову-
вати в захищених мережевих реалізаціях. Наступний приклад до-
зволяє користувачеві переглядати дані про зарплату (навіть, коли
в інших випадках користувач не має дозволу на перегляд інфор-
мації про зарплату). Передбачається, що у власника запиту цей
дозвіл є:
SELECT Прізвище, Ім’я, Оклад
FROM Співробітники
ORDER BY Прізвище
WITH OWNERACCESS OPTION;
Якщо зазвичай користувачеві заборонено створювати чи до-
повнювати таблиці, опція WITH OWNERACCESS OPTION до-
зволяє йому виконувати запит на створення таблиці чи запит на
додавання записів.
Якщо потрібно додержуватися правил захисту робочих груп і
надання дозволів користувачів, то недоцільно застосовувати оп-
цію WITH OWNERACCESS OPTION.

228
 7.4.2. Оператор SELECT...INTO

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

Синтаксис оператора має такий вигляд:
SELECT поле_1[, поле_2[,. ..]] INTO новаТаблиця [IN зовніш-
няБазаДаних]
FROM джерело;
Характеристика складових оператора SELECT...INTO:
поле_1, поле_2 — імена полів, які потрібно скопіювати в нову
таблицю;
новаТаблиця — ім’я таблиці, що створюється. Це ім’я пови-
нно задовольняти стандартним правилам іменування. Якщо но-
ваТаблиця збігається з ім’ям існуючої таблиці, виникає помилка,
яка діагностується;
зовнішняБазаДаних — шлях до зовнішнього джерела бази да-
них; ім’я існуючої таблиці, з якої відбираються записи. Це може
бути одна або кілька таблиць чи запитів.
Запит на створення таблиці можна використати для архіву-
вання записів, створення резервних списків таблиць, списків для
експорту в іншу базу даних, а також як основу звіту, що відобра-
жає дані за конкретний період.
У новій таблиці можна визначити ключ. При створенні табли-
ці поля в новій таблиці успадковують типи даних і розміри базо-
вих полів; жодні інші властивості таблиць і полів не передаються.

7.5. Мова маніпулювання даними DML

До мови маніпулювання даними належать оператори, які

дозволяють доповнювати таблицю новими записами чи, навпаки,
вилучати існуючі записи, а також оператори, що змінюють значення
окремих полів таблиці, та операції, за допомогою яких можна
зв’язувати таблиці. До мови маніпулювання даними належать:
оператор INSERT INTO — додає запис або записи в таблицю;
оператор UPDATE — змінює значення полів указаної таблиці
на основі заданої умови відбору;
оператор DELETE — вилучає записи з таблиці;
операція JOIN — об’єднує дані з кількох таблиць і видає їх у
результатному наборі даних; INNER JOIN — внутрішнє
об’єднання двох таблиць, LEFT JOIN — ліве зовнішнє
об’єднання, RIGHT JOIN — праве зовнішнє об’єднання;

229
 операція UNION — об’єднує результати кількох незалежних
запитів або таблиць.
До мови DML також можна віднести опис PARAMETERS,
який описує ім’я і тип даних кожного параметра в запиті з пара-
метрами.

7.5.1. Оператор INSERT INTO

Оператор INSERT INTO додає запис або записи в таб-

лицю. Він створює запит на дозапис записів у таблицю і має та-
кий синтаксис:
Запит на додавання кількох записів:
INSERT INTO призначення [IN зовнішняБазаДаних] [(поле_1[,
поле_2[,. ..]])]
SELECT [джерело.]поле_1[, поле_2[,. ..]
FROM вираз
Запит на додавання одного запису:
ІNSERT INTO призначення [(поле_1[, поле_2[,. ..]])]
VALUES (значення_1[, значення_2[,. ..])
Характеристика складових оператора INSERT INTO:
призначення — ім’я таблиці або запиту, в який додаються за-
писи;
зовнішняБазаДаних — шлях до зовнішньої бази даних;
джерело — ім’я таблиці або запиту, звідки копіюються записи;
поле_1, поле_2 — імена полів для дозапису даних, якщо вони
відповідають аргументу призначення; імена полів, з яких беруть-
ся дані, якщо вони відповідають аргументу джерело;
вираз — імена таблиці або таблиць, звідки вставляються дані.
Цей вираз може бути ім’ям окремої таблиці або результатом опе-
рації INNER JOIN, LEFT JOIN або RIGHT JOIN, а також збере-
женим запитом;
значення_1, значення_2 — значення, що дозаписуються у вка-
зані поля нового запису. Кожне значення буде вставлено у відпо-
відні поля: значення_1 вставляється в поле_1 в новому записі,
значення_2 в поле_2 і т. д. Кожне значення текстового поля по-
трібно брати в лапки (‘’); для розділення значень необхідно ви-
користовувати коми.
Оператор INSERT INTO можна використати для дозапису
одного запису в таблицю за допомогою запиту на дозапис одно-
го запису, описаного вище. У такому разі інструкція містить
ім’я і значення кожного поля запису. Треба визначити всі поля

230
запису, в які буде вміщено значення, і значення для цих полів.
Якщо поля не визначені, то в ці стовпчики буде вставлено зна-
чення за замовчуванням або значення Null. Записи додаються в
кінець таблиці.
Інструкцію INSERT INTO можна також використати для до-
запису набору записів з іншої таблиці або запиту за допомогою
SELECT. .. FROM, як показано вище в запиті на дозапис кількох
записів. У такій ситуацій SELECT визначає поля, що додаються у
вказану результатну таблицю.
Аргументи Джерело або Призначення визначають таблицю
або запит.
Інструкція INSERT INTO є необов’язковою, однак якщо вона
присутня, то повинна знаходитися перед інструкцією SELECT.
Якщо результуюча таблиця містить ключ, необхідно впевни-
тись, що в ключове поле (або поля) додаються унікальні непоро-
жні значення; у противному разі записи не будуть дозаписані.
Щоб дозаписати поля в таблицю з полем лічильника і наново
перенумерувати додані записи, не треба включати в запит поле
лічильника. Включати в запит поле лічильника необхідно, якщо
потрібно зберегти початкові значення поля.
При дозапису записів у таблицю в іншій базі даних потрібно
використовувати пропозицію IN.
Для створення нової таблиці краще використовувати оператор
SELECT... INTO замість запиту на створення таблиці.
Щоб заздалегідь дізнатися, які записи будуть додані, спочатку
виконайте і перегляньте результати запиту на вибірку, викорис-
товуючи ті самі умови відбору.
Запит на дозапис записів копіює записи з однієї або кількох
таблиць в іншу таблицю. Таблиці-джерела, з яких копіюються
записи, не змінюються.
Замість дозапису існуючих записів з іншої таблиці можна вка-
зати значення полів одного нового запису за допомогою пропо-
зиції VALUES. Якщо список полів пропущений, опція VALUES
повинна містити значення для кожного поля таблиці; інакше
оператор INSERT не буде виконано.

7.5.2. Оператор UPDATE

Оператор створює запит на оновлення, який змінює

значення полів вказаної таблиці на основі заданої умови відбору.
Синтаксис оператора має такий вигляд:

231
 UPDATE таблиця
SET новеЗначення
WHERE умоваВідбору;
Характеристика складових оператора UPDATE:
таблиця — ім’я таблиці, дані в якій потребують змін;
НовеЗначення — вираз, що визначає значення, яке повинно
бути вставлене в поле, що оновлюється;
умоваВідбору — вираз, що відбирає записи, які повинні бути
змінені. При виконанні цього оператора будуть змінені тільки за-
писи, що задовольняють указаній умові.
Оператор UPDATE особливо зручно використати для зміни
відразу багатьох записів або в тому випадку, якщо записи, що
підлягають зміні, знаходяться в різних таблицях.
Одночасно можна змінити значення кількох полів. Так, на-
ступна інструкція SQL збільшує вартість замовлення на 10 відсо-
тків, а вартість доставки — на 3 відсотки:
UPDATE Замовлення
SET СумаЗамовлення = СумаЗамовлення * 1.1,
ВартістьДоставки = ВартістьДоставки * 1.03
WHERE КлієнОтримувач = ‘АО_Вега’;
Інструкція UPDATE не приводить до створення результуючо-
го набору записів. Щоб дізнатися, які записи будуть змінені, спо-
чатку необхідно переглянути результати запиту на вибірку, ви-
користовуючи ті самі умови відбору, а потім виконувати запит на
оновлення записів.
При використанні цього оператора неохідно регулярне архіву-
вання даних. При ненавмисному оновленні записів вони можуть
бути відновлені по резервній копії.

7.5.3. Оператор DELETE

Оператор створює запит на вилучення записів. За його

допомогою можна вилучати записи з однієї або кількох таблиць,
перелічених у реченні FROM, які задовольняють речення WHERE.
Синтаксис цього оператора має такий вигляд:
DELETE [таблиця.*]
FROM таблиця
WHERE умоваВідбору
Характеристика складових оператора UPDATE:
таблиця — необов’язкове ім’я таблиці, з якої вилучаються за-
писи;
232
 таблиця — ім’я таблиці, з якої вилучаються записи;
умоваВідбору — вираз, що визначає записи, що вилучаються.
Оператор DELETE особливо зручний для вилучення великої
кількості записів. Щоб вилучити з бази даних цілу таблицю, мо-
жна використати метод Execute разом з інструкцією DROP. Од-
нак при такому вилученні таблиці втрачається її структура. Якщо
ж застосувати інструкцію DELETE, вилучаються тільки дані. При
цьому зберігаються структура таблиці і всі інші її властивості,
такі як атрибути полів та індекси.
Оператор DELETE можна використати для вилучення записів
з таблиць, пов’язаних відношенням «один—до—багатьох» з ін-
шими таблицями. Операції каскадного вилучення приводять до
вилучення записів з підпорядкованих таблиць.
Запит на вилучення вилучає записи повністю, а не тільки
вміст вказаних полів. Щоб вилучити дані в конкретному полі, по-
трібно створити запит на оновлення, який замінює існуюче зна-
чення на значення Null.
Не можна відновити записи, вилучені за допомогою запиту на
вилучення. Щоб впевнитись, які записи будуть вилученими, не-
обхідно спочатку переглянути результати запиту на вибірку, що
використовує ті самі умови відбору, а потім виконувати запит на
вилучення. Для того, щоб відновити ненавмисно вилучені запи-
си, необхідна резервна копія даних.

7.5.4. Операція JOIN

Широкі можливості SQL полягають у здатності

об’єднувати дані з кількох таблиць і видавати їх у результуючому
наборі даних. Для завдання типу об’єднання в реченні FROM вико-
нують операцію JOIN. Якщо в результати вибірки необхідно вклю-
чити всі рядки з обох таблиць, які задовольняють умові вибірки, ви-
користовують операцію INNER JOIN. Цю операцію ще називають
операцією внутрішнього об’єднання. Синтаксис цієї операції має та-
кий вигляд:
FROM таблиця_1 INNER JOIN таблиця_2
ON таблиця_1.поле_1 оператор таблиця_2.поле_2
Характеристика складових операції INNER JOIN:
таблиця_1, таблиця_2 — імена таблиць, записи яких підляга-
ють об’єднанню.

233
 поле_1, поле_2 — імена полів, що об’єднуються. Якщо ці поля
не є числовими, то повинні мати однаковий тип даних і вміщува-
ти дані одного виду, при цьому поля можуть мати різні імена;
оператор — будь-який оператор порівняння: «=,» «<,» «>,»
«<=,» «>=,» чи «<>».
Якщо за умови рівності виконується об’єднання таблиці самої
з собою, то результат об’єднання називається самооб’єднанням.
Операцію INNER JOIN можна використати з таблицями За-
лишок і Надходження для відбору надходжень товарів, по яких
були залишки на складі.
Операції JOIN можуть бути вкладеними. У такому разі вико-
ристайте наступний синтаксис:
SELECT поля
FROM таблиця_1 INNER JOIN
(таблиця_2 INNER JOIN [( ]таблиця_3
[INNER JOIN [( ]таблиця_X [INNER JOIN. ..)]
ON таблиця_3.поле_3 оператор таблиця_X.поле_X)]
ON таблиця_2.поле_2 оператор таблиця_3.поле_3)
ON таблиця_1.поле_1 оператор таблиця_2.поле_2;
Для створення зовнішніх об’єднань використовують операції
LEFT JOIN, RIGHT JOIN.
Синтаксис операції зовнішнього об’єднання має такий вигляд:
FROM таблиця_1 [ LEFT ¦ RIGHT ] JOIN таблиця_2
ON таблиця_1.поле_1 оператор таблиця_2.поле_2
Характеристика складових операцій LEFT JOIN і RIGHT
JOIN:
таблиця_1, таблиця_2 — імена таблиць, записи яких підля-
гають об’єднанню;
поле_1, поле_2 — імена полів, що об’єднуються. Поля повинні
мати однаковий тип даних і містити дані одного виду, однак син-
таксис імен може бути різним;
Оператор — будь-який оператор порівняння: «=,» «<,» «>,»
«<=,» «>=,» або «<>»;
Операція LEFT JOIN використовується для створення лівого
зовнішнього об’єднання, за якого всі записи з першої (лівої) таб-
лиці включаються в динамічний набір, навіть якщо у другій (пра-
вій) таблиці немає відповідних до них записів. Якщо у другій
таблиці, з якою виконується з’єднання, не має відповідних ряд-
ків, то замість значень її полів додається значення Null.
Операція RIGHT JOIN використовується для створення право-
го зовнішнього об’єднання, за якого всі записи з другої (правої)
таблиці включаються в динамічний набір, навіть якщо в першій

234
(лівій) таблиці немає відповідних до них записів. Якщо у першій
(лівій) таблиці, з якою виконується об’єднання, не має відповід-
них рядків, то замість значень її полів дається значення Null.
Наприклад, для відбору залишків товарів, по яких не було
надходжень, або надходжень товарів, по яких не було залишків,
потрібно використати операції LEFT JOIN і RIGHT JOIN, які
створюють відповідно ліве та праве зовнішнє об’єднання.
Операції LEFT JOIN або RIGHT JOIN можуть бути вкладені в
операцію INNER JOIN, але операція INNER JOIN не може бути
вкладена в операцію LEFT JOIN або RIGHT JOIN.

7.5.5. Операція UNION

Дана операція створює запит на об’єднання, що поєд-

нує результати кількох незалежних запитів або таблиць.
Синтаксис цієї операції має такий вигляд:
[TABLE] запит_1 UNION [ALL] [TABLE]
запит_2 [UNION [ALL] [TABLE] запит_n [. ][.. ]]
Характеристика складових операції UNION:
запит_1-n — інструкція SELECT, ім’я збереженого запиту або
ім’я збереженої таблиці, перед яким стоїть зарезервоване слово
TABLE.
В одній операції UNION можна об’єднати в будь-якому наборі
результати кількох запитів, таблиць і інструкцій SELECT. У на-
ступному прикладі об’єднується існуюча таблиця Нові клієнти
та інструкції SELECT:
TABLE [Великі кредити] UNION ALL
SELECT *
FROM Клієнти
WHERE СумаКредиту > 100 000;
За замовчуванням записи, що повторюються, не повертаються
при використанні операції UNION, однак у неї можна додати
предикат ALL, щоб гарантувати повернення всіх записів. Крім то-
го, такі запити виконуються швидше. Всі запити, включені в опе-
рацію UNION, повинні відбирати однакове число полів; при цьому
типи даних і розміри полів не обов’язково повинні збігатися.
Цей тип запиту комбінує поля (стовпчики) з однієї або кіль-
кох таблиць або запитів в одне поле в результатах запиту. На-
приклад, якщо шість постачальників щомісяця посилають нові
списки обладнання, то за допомогою запиту на об’єднання ці
235
списки можна об’єднати в один. А потім результати вмістити в
нову таблицю, створену за допомогою запиту на створення таб-
лиці, сформованої на запиті на об’єднання.
Запити на об’єднання дозволяють вводити в одне поле таблиці
дані з відповідних полів двох або кількох таблиць або запитів.
Нижче наведені приклади простого запиту на об’єднання, сорту-
вання в запиті на об’єднання, перейменування полів і повернення
записів, що повторюються.
Простий запит на об’єднання.
Наступний запит на об’єднання вибирає з таблиць Постача-
льники та Клієнти назви і міста постачальників, що знаходяться в
Україні.
SELECT[Назва], [Місто]
FROM [Постачальники]
WHERE КРАЇНА=«Україна»
UNION SELECT[Назва], [Місто]
FROM [Клієнти]
WHERE КРАЇНА=«Україна»
Сортування в запиті на об’єднання.
У наступному запиті на об’єднання відбираються всі назви
організацій і міст з таблиць Постачальники і Клієнти і викону-
ється сортування за назвою міст:
SELECT Назва, Місто
FROM Постачальники
UNION SELECT Назва, Місто
FROM Клієнти
ORDER BY Місто;
Перейменування полів у запиті на об’єднання.
У наступному запиті на об’єднання поле Назва отримує при
виведенні ім’я Постачальник/Клієнт:
SELECT Назва AS [Постачальник/Клієнт], Місто
FROM Постачальники
UNION SELECT Назва AS [Постачальник/Клієнт], Місто
FROM Клієнти;
Повернення записів, що повторюються в запиті на
об’єднання.
У наступному запиті на об’єднання інструкція UNION ALL
забезпечує повернення всіх записів, в тому числі тих, що повто-
рюються:
SELECT Назва, Місто
FROM Постачальники
UNION ALL SELECT Назва, Місто

236
 FROM Клієнти;
Використовувати псевдоніми можна тільки в першій пропози-
ції SELECT, оскільки в інших вони пропускаються. У пропозиції
ORDER BY необхідно посилатись на поля по їх назвах у першій
пропозиції SELECT.
У кожному аргументі запиту допускається використання оп-
цій GROUP BY або HAVING для групування даних, що поверта-
ються.
У кінець останнього аргументу запиту можна включити опцію
ORDER BY, щоб відсортувати повернені дані.

7.5.6. Опис PARAMETERS

Описує ім’я і тип даних кожного параметра в запиті з

параметрами.
Синтаксис цього опису має такий вигляд:
PARAMETERS ім’я типДаних [, ім’я типДаних [,. ..]]
Складові опису PARAMETERS:
ім’я — ім’я параметра. Задається у властивості Name об’єкта
Parameter і використовується для звернення до цього параметра в
сімействі Parameters. Значення аргументу Ім’я може бути рядком,
який відображається у вікні діалогу при виконанні запиту. Рядок,
що містить пропуски і розділові знаки, необхідно взяти в квадра-
тні дужки ([ ]). Наприклад, допустимими значеннями цього аргу-
менту є [Мінімальна відсоткова ставка] і [Зведення за який мі-
сяць Ви хочете отримати?];
типДаних — один з первинних типів даних SQL ядра Microsoft
Jet або їх синоніми.
Для запитів, що регулярно виконуються, можна використати
опис PARAMETERS, щоб створити запит з параметрами. Запит з
параметрами допомагає автоматизувати процес зміни умов від-
бору запиту. При наявності запиту з параметрами програма по-
винна вказувати параметри при кожному запуску запиту.
Опис PARAMETERS є необов’язковим, однак, якщо він при-
сутній, то повинен знаходитися перед всіма іншими інструкція-
ми, в тому числі перед інструкцією SELECT.
Для розділення параметрів в описі потрібно використати ко-
ми. У наступному прикладі описані два параметри:
PARAMETERS [Максимальна ціна] Currency, [Початкова да-
та] DateTime;

237
 В опції WHERE або HAVING можна використати аргумент
ім’я, але не типДаних. Наступна інструкція SQL запитує у корис-
тувача два параметри, а потім використовує їх при відборі запи-
сів з таблиці Кредити:
PARAMETERS [МінімальнийВідсоток] Currency,
[Початкова дата] DateTime;
SELECT НомерДоговору, СумаКредиту
FROM Кредити
WHERE Відсоток = [Мінімальний відсоток]
AND ДатаПідписання >= [Початкова дата];
Оператори SQL можна використовувати не лише для створен-
ня запитів, а у формах звітах і макросах.

Питання для самоперевірки

1. Призначення та загальна характеристика мови SQL.

2. В чому полягають основні відмінності мов Jet SQL з
ANSI SQL?
3. На які групи за функціями можна розділити всі команди
мови SQL?
4. Які оператори SQL входять до мови опису даних, DDL?
5. Які оператори SQL входять до мови запиту даних, DQL?
6. Які оператори SQL входять до мови маніпулювання да-
ними, DML?
7. Який оператор є ядром мови SQL Microsoft Jet?

238
 8 Pоздiл
РОЗПОДІЛЕНІ БАЗИ ДАНИХ

8.1. Поняття розподіленої бази даних

У розвитку сучасних інформаційних систем спостері-

гається тенденція переходу від локальних баз даних до розподі-
лених. Найповніше суть розподілених БД їх класифікація та особ-
ливості роботи з ними викладені в [25].
Розподілена база даних (Distributed Database DDB) –– це
сукупність взаємопов’язаних баз даних, розподілених у
комп’ютерній мережі.
Розподілена база даних є основою децентралізованої обробки,
тобто обробки даних безпосередньо на місцях їх вибору. Децент-
ралізована обробка логічно випливає з організаційної структури
організації, яка може складатися з цілого ряду підрозділів: відді-
лів, управлінь, філіалів і т. п., що фізично можуть бути розташо-
ваними в різних регіонах. Система управління розподіленою ба-
зою даних визначається як програмна система, котра керує базою
даних у такий спосіб, щоб її розподіленість була прозорою для
користувачів.
Прозорість — це досить поширене поняття незалежності да-
них у розподілених системах, яке передбачає, що користувач у
цій системі працює з розподіленою базою даних як з логічно ці-
лісною сукупністю, тобто на його роботу не повинно впливати
те, яким чином дані розподілені між вузлами мережі. Отже, в
розподіленій системі користувачеві надається логічно цілісне по-
дання фізично розподіленої бази даних. Прозорість — це основна
властивість розподілених СКБД, які повинні забезпечувати кори-
стувачеві враження, що вони працюють з централізованою БД.
Крім розподілених систем, існують системи віддаленого до-
ступу, які надають можливість користувачеві отримати доступ до
віддалених даних, що зберігаються на інших вузлах мережі. Такі
можливості надаються системами «клієнт-сервер», але при цьому
користувач, умовно кажучи, бачить з’єднання з іншими система-
ми і знає, що працює з віддаленими даними. У дійсно розподіле-
ній базі даних усі підключення до віддалених вузлів для користу-

239
вача повинні бути непомітними і складати в нього враження, що
він працює не з кількома, а з однією базою даних, яка вміщує всю
необхідну для його роботи інформацію.
На ринку програмних засобів з’явились розподілені СКБД
(РСКБД), які дають змогу підтримувати та обробляти розподіле-
ну базу даних у багатокориcтувацьких системах. Основним за-
вданням розподіленої СКБД є забезпечення управління доступом
до даних багатьох споживачів і цілісності й узгодженості даних в
умовах використання мережі ЕОМ. Тобто основна функція таких
СКБД — це координація спільної роботи багатьох користувачів з
розподіленою інформацією. Проте розв’язання проблеми авто-
номності роботи користувачів розподіленої системи створює ба-
гато специфічних проблем в організації баз даних, оскільки різні
користувачі можуть працювати паралельно з одними й тими са-
мими даними, виконуючи з ними різні перетворення.

8.2. Особливості та види розподілених систем

Слід розрізняти розподілену базу даних і розподілену

обробку даних. Відмінності тут полягають в тому, що при розпо-
діленій обробці дані не розподіляються, а зберігаються централі-
зовано. Тобто розподілена обробка даних — це обробка на різних
комп’ютерах даних, що зберігаються централізовано.
Крім того, є відмінності між паралельними та розподіленими
СКБД. Паралельні СКБД використовується для надвеликих баз
даних, розміри яких досягають кількох терабайтів, або у випад-
ках, коли для підвищення продуктивності потрібно об’єднати кі-
лька малопотужних машин для того, щоб отримати потужність,
рівну до надпотужної машини. Паралельні СКБД надають одно-
часний доступ до бази даних кількох процесорів. Слід відмітити,
що практично всі розробники сучасних СКБД поставляють на
ринок паралельні версії своїх систем.
Розподілені системи поділяються на гомогенні та гетерогенні.
Перші з них — це системи, орієнтовані на використання якоїсь
однієї СКБД. На відміну від гомогенних систем, у гетерогенних
системах у різних вузлах мережі можуть використовуватись різні
СКБД. Звичайно побудова та управління гетерогенними систе-
мами набагато складніші, ніж гомогенними, що вимагає вирі-
шення цілого спектра проблем, пов’язаних з побудовою глобаль-

240
ної цілісної моделі розподіленої БД, ускладнює розуміння систем
і мов запитів до них, потребує розробки якихось додаткових ін-
терфейсних та шлюзових програмних продуктів.
Існують ще так звані мультибазові системи, які характеризу-
ються абсолютно автономним управлінням кожного вузла мере-
жі. Мультибазові системи надають можливість користувачеві
самостійно управляти даними свого вузла без централізованого
контролю цих процесів. Дозвіл на доступ зовнішніх користувачів
до даних певного вузла визначається адміністратором БД вузла,
який надає права та визначає ту частину інформації, яка може
бути доступна зовнішнім користувачам. Мультибазова СКБД
об’єднує локальні схеми БД різних вузлів мережі і будує на їх
основі глобальну цілісну схему БД як єдиного цілого, на базі якої
користувачі можуть будувати запити.
Мультибазові системи поділяються на федеральні та нефеде-
ральні: нефедеральні — це ті, які не мають локальних користува-
чів; федеральні — це системи змішаного типу, які містять елемен-
ти розподілених і централізованих баз даних. Для локального
користувача федеральна система виглядає як централізована, а
для віддаленого — як розподілена.

8.3. Переваги і недоліки розподілених систем

Розподілені БД мають як переваги, так і недоліки.

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

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

8.4. Cтратегії розподілу даних

Розглянемо загальнi стратегiї розподiлу даних мiж ву-

злами мережі ЕОМ без урахування особливостей та обмежень
конкретної розподiленої СКБД. Охарактеризуємо альтернативні,
теоретично можливi стратегiї розподiлення даних у РБД [20]:
централiзована; розподiлена без дублювання; розподiлена з дуб-
люванням; змiшана, або комбiнована.
Централiзована cтратегiя характеризується тим, що всi данi
розміщуються в одному вузлi мережі, та існує система
управлiння доступу рiзних користувачiв з інших вузлiв до даних.
Ця стратегiя дуже зручна і має ряд переваг. Розглянемо основні з
них. Якщо данi зберiгаються в одному мiсцi, то значно простiше
реалiзувати проблему забезпечення цiлісностi та захисту
iнформацiї. При централiзованiй стратегiї спрощується техно-
логiя створення і ведення файлiв БД, оскільки можна скористати-
ся єдиними стандартними процедурами та методами ведення i
пiдтримки БД в актуальному станi. Проектування такої роз-
подiленої бази даних також досить просте порiвняно з iншими
стратегiями.
Нарівні з перевагами централiзована стратегiя має ряд не-
долiкiв: можуть виникати черги, що призводить до рiзкого
збiльшення часу реакцiї системи. Крiм того, витрачається певний

242
час i на процедури, пов’язанi з передачею iнформацiї. Обсяг бази
даних обмежений пам’яттю ЕОМ, що використовується для
зберiгання бази даних.
За розподiленої (децентралiзованої) стратегiї без дублювання
визначають данi, якi потрiбно зберiгати в кожному вузлi мережi.
При цьому розподiлену базу даних проектують як неперетинні
мiж собою пiдмножини даних, розподiленi по вузлах мережі.
Тобто при цій стратегії не допускаються копії окремих частин
БД. Проектування даних тут є складним завданням. Ключовим
фактором, який впливає на надійність і доступність бази даних,
виявляється так звана локалізація посилань. Якщо база даних
розподілена так, що дані, розміщені в цьому вузлі, викликаються
винятково його користувачем, то це свідчить про високий сту-
пінь локалізації посилань. Якщо подібне розчленування даних
здійснити неможливо і для виконання запитів користувача потрі-
бно звертатись за інформацією до інших вузлів, то це свідчить
про невисокий ступінь локалізації посилань.
Розглянута стратегiя пiдходить для тих предметних областей,
в яких практично немає дублювання даних у рiзних вузлах ме-
режi i потрiбна мiнiмальна кiлькiсть логiчних посилань для вико-
нання iнформацiйних взаємозв’язкiв вузлiв одного з одним. Тоб-
то користувач кожного вузла працює зi своїми файлами i досить
рiдко використовує данi iнших вузлiв мережi.
Економiчнi задачi за своїми iнформацiйними властивостями
xарактеризуються дуже тiсними iнформацiйними взаємо-
зв’язками, тому для даного класу задач реалiзацiя цiєї стратегiї
досить складна, неефективна i недоцiльна. Переваги цiєї стратегiї
полягають у тому, що зменшуються витрати на передачу
iнформацiї та вiрогiднiсть виникнення черг, коли кiлька користу-
вачiв одночасно звертаються до одного й того самого файла БД.
Разом з тим цю стратегiю важко контролювати з позицій дублю-
вання даних, чим ускладнюється реалiзацiя проблеми узгодже-
ностi та цілісності даних. Значно складнiшими є проблеми
адмiнiстрування та пiдтримки БД даних в актуальному станi.
Розподiлена (децентралiзована) стратегiя з дублюванням по-
лягає в тому, що база даних проектується як за централiзованого
пiдходу, але фiзично дублюється в кожному вузлi мережi. Тобто
кожний вузол має повну копiю всієї бази даних. Стратегiя роз-
подiлу з дублюванням найбiльш ефективно розв’язує проблеми
доступу та вибірки даних з мiнiмальними витратами часу. Сис-
тема досить проста при проектуваннi. Однак нарівні з перевагами
цей пiдхiд характеризується складнiстю адмiнiстрування та

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

8.5. Характеристика розподілених СКБД

Розподілена СКБД повинна забезпечувати функціона-

льні можливості як централізованої, так розподіленої систем.
Одним з варіантів побудови архітектури РСКБД є варіант, наве-
дений на рис.8.1 [25].
Розподілена БД потребує наявності локальної та розподіленої
СКБД. Локальна СКБД використовується для управління даними
окремого вузла і має свій власний системний каталог, що описує
дані конкретного вузла.
Розподілена СКБД керує даними всіх вузлів розподіленої ме-
режі і має глобальний системний каталог.
Глобальна концептуальна схема представляє собою загальний
опис усієї бази даних як єдиного цілого, оскільки вона уявляється

244
адміністратором БД. Глобальна зовнішня схема описує підмно-
жину глобальної концептуальної схеми розподіленої бази даних,
яка доступна конкретному вузлу.
Вузол 1 Вузол 2 Вузол n
Глобальна Глобальна Глобальна
зовнішня схема зовнішня схема … зовнішня схема

Глобальна
концептуальна
схема

Схема
фрагментації

Схема
розподілення

Вузол 1 Вузол 2 Вузол n

Локальна схема Локальна схема Локальна схема

відображення відображення … відображення

Локальна Локальна Локальна

концептуальна концептуальна концептуальна
схема схема схема

Локальна Локальна Локальна

внутрішня схема внутрішня схема внутрішня схема

БД БД БД

Рис. 8.1. Архітектура розподіленої СКБД

Схема фрагментації містить опис того, яким чином дані пови-

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

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

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

даних

Проектування розподілених БД потребує вирішення

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

246
ментів, чи навпаки, за рахунок горизонтальної фрагментації пев-
них вертикальних фрагментів.
Відновлення або ж реконструкція початкового відношення на
основі його фрагментів виконується за допомогою операції:
з’єднання — для вертикальних фрагментів та об’єднання — для
горизонтальних фрагментів.
Фрагментацію слід виконувати, додержуючись таких основ-
них правил:
 При фрагментації слід дотримуватись повноти. Згідно з цим
правилом, якщо якесь відношення розбивається на n-фрагментів,
то кожен атрибут відношення повинен бути присутнім хоча б в
одному зі створених фрагментів. Виконання правила повноти га-
рантує проектувальнику розподіленої БД, що жодні дані не бу-
дуть втрачені при фрагментації відношень.
 Фрагментація повинна забезпечувати зворотність, тобто га-
рантоване відновлення початкового відношення в результаті
об’єднання відношень, отриманих у результаті фрагментації. До-
тримування цього правила забезпечує зберігання всіх функціона-
льних залежностей початкового відношення.
 Отримані фрагменти не повинні перетинатись. Це правило
стосується насамперед результатів горизонтальної фрагментації,
тобто один і той же кортеж (запис) не може входити до складу
кількох фрагментів. Щодо вертикальної фрагментації, то це пра-
вило не поширюється на атрибути первинного ключа, які можуть
дублюватись у різних вертикальних фрагментах відношення.
Фрагментацію і розподіл даних необхідно виконувати поетапно,
при централізованому контролі за цією процедурою. Спочатку база
даних проектується за тими ж правилами, що і централізована. Зви-
чайно при цьому потрібно охопити користувачів кожного вузла та
досконало вивчити їх вимоги і запити до бази даних. Фрагментація
не є обов’язковою умовою побудови розподіленої бази даних. Во-
на застосовується лише за умови доцільності її використання; як-
що це не доцільно, то можлива відмова від фрагментації даних.

8.7. Вимоги до розподілених систем

Основні вимоги до розподілених систем, сформульо-

вані в [25], є пов’язаною між собою сукупністю правил і цілей,
яких потрібно при розробці розподіленої бази даних. Розглянемо
сутність цих вимог.

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

248
 Незалежність від реплікацій. Система повинна підтриму-
вати незалежність від реплікацій, якщо деякі відношення або їх
фрагменти можуть бути представленими різними копіями чи
репліками, що зберігаються на різних вузлах. Створення реплік
надає можливість вузлам працювати з локальними копіями, а не
витрачати час на обмін даними. Головний недолік реплік поля-
гає в тому, що при внесенні змін у реплікований об’єкт усі його
копії мають поновлюватися. В ідеалі система повинна підтри-
мувати незалежність від реплікацій, тобто у користувача з логі-
чної точки зору повинно складатися враження, що дані нереплі-
ковані.
Забезпечення виконання розподілених запитів. Система по-
винна забезпечувати виконання глобальних запитів, для реаліза-
ції яких потрібні дані кількох вузлів. При реалізації таких запитів
важлива увага надається їх оптимізації. Це пов’язано з тим, що,
якщо в запиті задіяна інформація кількох вузлів, то існує багато
способів її переміщення по мережі. Тобто для виконання розпо-
ділених запитів важливо найти найоптимальнішу стратегію взає-
модії з даними, що зберігаються на різних вузлах мережі.
Забезпечення управління розподіленими трансакціями. Си-
стема повинна забезпечувати механізм підтримки трансакцій як
одиниці відновлення бази даних. Механізм підтримки трансакцій
має працювати при виконанні як локальних, так і глобальних за-
питів. Тобто система повинна забезпечувати такі основні власти-
вості трансакцій, як атомарність, узгодженість, ізольованість і
довговічність.
Незалежність від апаратного забезпечення. Система управ-
ління розподіленою базою даних повинна забезпечувати функці-
онування на різноплатформенному обладнанні, забезпечуючи
при цьому єдність системи і рівноправність різних її вузлів.
Незалежність від операційної системи. Система управління
розподіленою базою даних повинна мати здатність функціонува-
ти не лише на різному апаратному забезпеченні, але й у різному
операційному середовищі.
Незалежність від архітектури мережі. Система управління
розподіленою базою даних повинна забезпечувати функціону-
вання в мережах різної архітектури.
Незалежність від типу СКБД. Виконання цієї вимоги в іде-
альній розподіленій системі передбачає, що розподілена СКБД
може співпрацювати з різними локальними СКБД, які підтриму-
ють бази даних локальних вузлів. Реалізація цієї вимоги, як пра-

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

8.8. Особливості технології роботи з розподіле-

ною базою даних

Робота в розподіленій системі має свою специфіку та

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

8.8.1. Управління одночасним доступом до бази

даних

Робота з базою даних у мережі створює проблему, пов’язану з

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

250
 Блокування виконуються за правилами сумісності блокувань,
що виключає виникнення конфліктів типу «читання — запис»,
«запис –– читання» чи «запис — запис». Існують три методи бло-
кування: централізоване блокування, блокування первинної копії
і розподілене блокування [16.].
При централізованому блокуванні для всієї розподіленої бази
даних підтримується єдина таблиця блокувань, яка розміщується
на одному з вузлів під управлінням єдиного менеджера блоку-
вань. Менеджер блокувань відповідає за встановлення та зняття
захватів від імені всіх трансакцій. Оскільки управління блоку-
ванням зосереджено на одному з вузлів, то воно аналогічне
централізованому управлінню одночасним доступом до даних.
Такий підхід має певні проблеми при його функціонуванні. По-
перше, недостатню надійність, яка при відмові чи недоступності
центрального вузла блокувань може призвести до виходу з ладу
всієї системи. По-друге, центральний вузол може стати вузьким
місцем у системі через великі обсяги обробки даних на ньому і
генерованість навколо нього інтенсивного трафіка мережі.
Блокування первинної копії — це управління одночасним до-
ступом, що використовується для баз даних з реплікаціями, в
яких копії одних і тих самих даних можуть зберігатися на бага-
тьох вузлах. Одна з таких копій виокремлюється як первинна,
тому для доступу до будь-якого елемента даних необхідно вста-
новити блокування на його первинну копію. Множина первин-
них копій відома всім вузлам розподіленої системи, і запити на
блокування надходять на ті вузли, де зберігаються ці копії. Якщо
в розподіленій базі даних не використовуються реплікації, то ме-
ханізм блокування первинної копії зводиться до розподіленого
блокування. Механізм блокування первинної копії запропонова-
ний у розподіленій версії СКБД Ingres.
Розподілене (деценралізоване) блокування пропонує розподі-
лити обов’язки з управління блокуванням між усіма вузлами сис-
теми. Під час блокування згідно з цим механізмом необхідна ко-
ординація взаємодій менеджерів блокувань кількох вузлів. Цей
підхід до блокування усуває недоліки централізованого блоку-
вання, пов’язані з перевантаженням централізованого вузла, про-
те він складніший і характеризується більш високими комуніка-
ційними витратами. Такий алгоритм використовується в
системах System R* і NonStop SQL.
Блокувати можна весь файл, окремий його запис чи групу за-
писів. При блокуванні система повинна інформувати інших ко-
ристувачів по мережі про те, що в даний момент виконано бло-

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

8.8.2. Трансакції та механізм їх підтримки

Для забезпечення логічної узгодженості даних у про-

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

Неможливою є проміжна ситуація, коли при виконанні транс-

акції частину змін заносили до бази даних, а частину –– відміняли.
Для кожної трансакції при її закритті всі зміни або заносять до ба-
зи даних, або відміняють їх і здійснюють так званий відкіт транс-
акції. Отже, повинна виконуватись вимога щодо атомарності
трансакцій –– виконання всіх дій або ж невиконання жодної з них.
Другою важливою ознакою трансакції є її довговічність, яка
полягає в тому, що коли трансакція зафіксована, то її результат
не повинен втратитися навіть у разі руйнування системи. Важли-
вою вимогою до трансакцій є так звана їх серіалізація, яка поля-
гає в тому, щоб різні трансакції не мали випадкового впливу одна
на одну. Трансакції також повинні мати властивості ізольованос-
ті, тобто результат трансакції не повинен залежати (бути ізольо-
ваним) від інших трансакцій, виконуваних паралельно.
Кожна трансакція має починатися при цілісному стані БД. Та-
кий самий стан повинен залишатися після її завершення. Неви-
конання цієї умови призводить до того, що замість фіксації ре-
зультатів трансакції в БД виконується «відкіт», тобто база даних
252
повертається в той початковий стан, при якому починалась вико-
нуватися трансакція.
Проілюструємо дію цього механізму на прикладі. Нехай необ-
хідно перевести деяку суму з одного розрахункового рахунку в
банку на інший. Ця операція складається з двох таких кроків:
1) зняти суму з одного розрахункового рахунку (модифікація
запису 1);
2) додати суму на другий рахунок (модифікація запису 2).
Зазначимо, що після виконання першого кроку файли бази да-
них перебуватимуть у неузгодженому стані (рахунки не будуть
балансуватись на величину суми, знятої з першого рахунку). При
паралельній роботі кількох користувачів такий стан файла буде
помилковим, оскільки інші користувачі бачать файли з неузго-
дженою інформацією. Крім того, другий крок операції може за-
вершитися тупиком (наприклад, другий запис буде заблокований
іншим користувачем) чи аварійним збоєм системи. Апаратний
збій між виконанням першого і другого кроків взагалі може при-
звести до втрати контролю над цілісністю та узгодженістю бази
даних. Спроба розв’язати задачу блокуванням файлів на період
виконання операції дуже уповільнить роботу інших користувачів
мережі і не зможе забезпечити відновлення файлів внаслідок
апаратних збоїв системи.
Для того щоб усунути подібні ускладнення, використовують
механізм обслуговування трансакції. Перед виконанням їй при-
своюють ідентифікатор початкової трансакції і виконують усі
необхідні дії (кроки 1 і 2). При цьому інші користувачі не обме-
жені у виконанні операцій пошуку у файлах, які використову-
ються в активній трансакції, і бачать її у початковому стані. Опе-
рації редагування цих файлів під час виконання трансакції
заборонені. Якщо трансакція закінчилась успішно, то після від-
повідного сигналу всі зміни, внесені у файли бази даних, стають
видимими для всіх користувачів, а файли –– доступними для вне-
сення змін. При виникненні ускладнень під час виконання наступ-
ного кроку (наприклад, ресурс недоступний для виконання)
трансакція завершується аварійно. При аварійному завершенні
трансакції система має виконати так званий відкот. При цьому
всі виконані з моменту початку трансакції перетворення повинні
бути знищені, а файли повернені в початковий стан. Аналогічний
«відкіт» повинен виконуватись і після збою системи.
У розподілених системах виокремлюють чотири типи збоїв:
збій трансакції, збій вузла, збій носія (диска), збій комунікаційної
лінії. Збій трансакції може бути спричинений помилками у вхід-

253
них даних і виявленням тупика. У всіх перелічених ситуаціях
збою трансакцію необхідно перервати і виконати «відкіт» бази
даних. Для попередження «зависання» системи потрібен конт-
роль за часом виконання трансакції. Якщо ліміт часу, відведений
для її виконання, перевищено, то її потрібно відмітити як таку,
що підлягає аварійному завершенню незалежно від результату
початкових кроків, а всі файли, задіяні при її виконанні, перевес-
ти в початковий стан.
Для підтримання цілісності бази даних при різного роду збоях
використовують протоколи журналізації, що вміщують інформа-
цію про всі зміни, які вносяться до бази даних під час виконання
трансакції.
В одну трансакцію доцільно об’єднувати операції, які вико-
нують логічно зв’язані між собою зміни файлів бази даних.
Наявність механізму підтримки трансакцій –– це показник рі-
вня розвинутості СКБД. Але, на жаль, не всі системи мають ме-
ханізм підтримки трансакцій, а лише ті системи, які проектува-
лись і розроблялись як розподілені СКБД для роботи в
багатокористувацькому середовищі. Підтримка трансакцій –– це
основа забезпечення цілісності БД.
З розподіленою трансакцією пов’язане таке поняття, як агент,
оскільки розподілена трансакція виконує операції з базою даних
на кількох вузлах. У такому разі говорять, що кожна трансакція
складається з кількох агентів, тобто процесів, які виконуються на
кожному вузлі за вказівкою даної трансакції. Тому система пови-
нна відстежувати агенти однієї трансакції, щоб не виникло тупи-
кових ситуацій.
У сучасних розподілених СКБД підтримку трансакцій можна
виконувати за допомогою двох методів — двофазної фіксації
трансакцій і дублювання даних. Ці два методи відрізняються тим,
що в першому випадку багато трансакцій працюють одночасно з
однією розподіленою базою даних. У другому випадку кожна
трансакція має змогу копіювати необхідні для її виконання дані з
розподіленої бази даних і працювати з нею як зі своєю особис-
тою базою даних, модифікувати ці дані, а потім після виконання
трансакції повертати у розподілену базу даних.
Розглянемо підтримку трансакцій за допомогою механізму
двофазної фіксації. При використанні цього методу трансакцію
виконують у два етапи, при цьому додержуються таких правил:
1. Якщо хоча б один вузол не може з будь-яких причин зафік-
сувати трансакцію, розподілена трансакція припиняється на всіх
інших вузлах, які беруть участь в її виконанні.

254
 2. Якщо всі вузли погоджуються з фіксацією трансакції, вона
фіксується на всіх вузлах, які беруть участь в її реалізації.
Перший етап, або перша фаза, полягає в тому, що на вузлі, де
виконуватимуть трансакцію, створюють процес-координатор, а
на всіх інших вузлах –– процеси-учасники. Спочатку процес-
координатор розсилає повідомлення учасникам про початок
трансакції, і кожний з них самостійно вирішує, чи може трансак-
ція бути завершеною на даному вузлі. Учасники, готові заверши-
ти трансакцію, надсилають повідомлення на вузол-координатор
про свою готовність до завершення трансакції. Учасники, які не
зможуть зафіксувати свою частину трансакції, надсилають по-
відомлення про те, що трансакцію буде перервано. Координа-
тор, зібравши повідомлення всіх учасників, вирішує долю транс-
акції згідно з правилами. Якщо всі учасники надіслали згоду,
координатор надсилає повідомлення про глобальну фіксацію
трансакції, відповідно до якого вносяться зміни на всіх серверах.
При відмові хоча б одного з учасників приймають рішення про
припинення виконання трансакції і надсилають повідомлення
про глобальне припинення тим учасникам, які надіслали згоду на
виконання трансакції. Тим учасникам, які надіслали відмову на
виконання трансакції, повідомлення можна не надсилати, оскіль-
ки вони самі в змозі прийняти рішення згідно з правилами дво-
фазної фіксації трансакцій. Ця ситуація називається односторон-
нім припиненням виконання трансакції. У результаті на всіх
серверах трансакція завершується однаково (фіксується або пе-
реривається). Якщо всі вузли мають змогу зафіксувати трансак-
цію, то всі перетворення виконують на всіх вузлах: якщо хоча б
один вузол не в змозі зафіксувати результати трансакції, то її
припиняють на всіх вузлах і виконують відкот.
Протоколом обслуговування трансакцій передбачається обмін
повідомленнями між координатором і учасниками двічі, тому
цей механізм отримав назву двофазної фіксації трансакцій. Проте
механізм двофазного виконання трансакцій має ряд недоліків:
одночасний захват усіх ресурсів може досить надовго заблокува-
ти доступ до даних; крім того, вихід з ладу під час виконання
трансакції того вузла мережі, який заблокував ресурси, призведе
до блокування деяких даних усієї мережі доти, поки не буде від-
новлено його роботу.
Основні проблеми, які можуть виникнути при двофазній фік-
сації трансакцій –– це забезпечення коректної поведінки системи
в разі виходу з ладу сервера чи пошкодження ліній зв’язку. Тому

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

256
оскільки йому не потрібно очікувати закінчення обміну даними
між серверами по внесенню змін. І ще одна важлива перевага
синхронного тиражування –– підтримка «дзеркальної» бази да-
них на резервному сервері, причому обидва сервери (основний і
резервний) у такому разі можуть працювати паралельно.
При асинхронному режимі зміни запам’ятовуються, а момент
їх передачі вибирають за якимось певним правилом. При такому
способі підтримки логічної цілісності розподіленої бази даних
спостерігається деяка розсинхронізація стану локальних баз да-
них, яка полягає в тому, що зміни, внесені до деяких локальних
баз, відстають за часом їх внесення одна від одної. Iнтервал часу,
через який поновлюються данi в iнших вузлах, має узгоджувати-
ся з iнтервалом розв’язання задачі в цих вузлах. Асинхронне ду-
блювання має недолiк, оскільки не забезпечує виконання проце-
дур поновлення даних у масштабi реального часу. Цей режим
можна використовувати в таких інформаційних системах, в яких
складно підтримувати постійний зв’язок між серверами, і термін
тимчасової неузгодженості стану бази даних не конфліктує з пе-
ріодичністю розв’язання задач у цій системі.
Стратегія дублювання для багатьох фiрм-виробникiв програм-
ного забезпечення стає домiнуючою в розподiлених СКБД, оскіль-
ки дозволяє виконати ту саму роботу, але з меншими затратами,
ніж при двофазній фіксації трансакцій. Можливості дублювання
мають такі системи, як Oracle 7, Informix-Online і Open-Ingres.
Порівняння двох методів підтримки трансакцій у розподіле-
них базах даних наведено в табл. 8.1.
Таблиця 8.1
ПОРІВНЯЛЬНА ТАБЛИЦЯ ДВОХ МЕТОДІВ ПІДТРИМКИ ТРАНСАКЦІЙ У
РОЗПОДІЛЕНІЙ БАЗІ ДАНИХ

Методи Двофазна фіксація трансакцій Дублювання

Характеристики Однорангові сервери. Сервери ведучий/підлеглий.

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

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

8.8.3. Управління відновленням розподілених баз

даних

Складність відновлення розподіленої бази даних пов’язана зі

складністю досягнення атомарності трансакції, якщо вона охоп-
лює операції з базами даних кількох вузлів. У такому разі слід
виконувати вимогу атомарності кожної локальної субтрансакції,
а також гарантувати атомарність усієї глобальної трансакції. Ко-
жна глобальна трансакція повинна відстежуватись та координу-
258
ватись. Координувати дії розподіленої трансакції повинен вузол,
на якому вона була ініційована. Виконання вимоги незалежності
від центрального вузла призводить до того, що кожен вузол може
для одних трансакцій бути координатором, а для інших — учас-
ником. Основними принципами, які можуть зумовити необхід-
ність відновлення розподіленої бази даних, є: втрата повідомлен-
ня; збій комунікаційної лінії; збій вузла.
Якщо розподілена СКБД зафіксує, який вузол мережі вийшов
з ладу, то будуть виконані такі дії:
 відмінені всі трансакції, в яких був задіяний вузол мережі,
що вийшов з ладу;
 помічено цей вузол як такий, що вийшов з ладу, щоб запобі-
гти спробам його використання іншими вузлами;
 після перезапуску вузла виконано процедуру відновлення
шляхом «відкату» всіх трансакцій, що були виконані лише част-
ково на момент аварійної зупинки вузла;
 після завершення процедури локального відновлення вузол
повинен поновити копію своєї бази даних, привівши її у відпові-
дність з іншими вузлами.

Питання для самоперевірки

1. Що таке розподілена база даних?

2. Охарактеризуйте сутність фрагментації бази даних та
основні її види.
3. Які є стратегії розподілу даних?
4. Які зі стратегій розподілу даних найбільш поширені
на практиці?
5. Особливості технології роботи з розподіленою ба-
зою даних.
6. Якими суттєвими відмінностями характеризуються
синхронний та асинхронний режими тиражування змін
у розподіленій базі даних?
7. Що таке трансакція? Які можуть виникнути усклад-
нення під час роботи з розподіленою базою даних за
відсутності механізму підтримки трансакцій?
8. Чому підтримку трансакцій можна назвати механіз-
мом підтримки цілісності розподіленої бази даних?
9. Поясніть суть двофазної фіксації трансакції.

259
 9 Pоздiл
КОНЦЕПЦІЯ ПОБУДОВИ СХОВИЩ ДАНИХ

9.1. Характеристика трансакційних та аналітич-

них систем

Інформаційні системи, орієнтовані на оперативну об-

робку даних, що зберігаються в базах даних, належать до класу
трансакційних систем. Задачі, які вирішуються в цих системах, є
задачами класу OLTP (On-line Transactional Procеssing).
Трансакційні системи, або системи операційної обробки
даних (СОД), орієнтовані на оперативну обробку даних, що
характеризують поточний стан об’єктів предметної області.

Саме до цього класу належать традиційні облікові та інші за-

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

260
 Зауважимо, що з позицій інформаційних процесів аналітична
система є вторинною щодо трансакційної системи, оскільки всі
дані, що використовуються для аналізу, необхідно спочатку на-
громадити і, за можливістю, частково обробити, чим і займають-
ся різні трансакційні системи, і лише потім їх проаналізувати.
Аналітичні задачі залежно від концепції аналізу можна поді-
лити на дві групи:
 задачі статичного аналізу;
 задачі оперативного аналізу.
Ці дві групи аналітичних задач суттєво відрізняються між со-
бою. До першої групи належать регламентні аналітичні задачі, які
вирішуються з певною, заздалегідь відомою періодичністю. Ця
група задач характеризується тим, що вони реалізуються на основі
традиційної технології їх автоматизації. При цій технології споча-
тку формулюється технічне завдання, яке передається програмісту
на програмування. Програміст виконує програмування і тестуван-
ня програми і лише після цього отримує результат у вигляді рег-
ламентованих, тобто чітко визначених форм звітів. За такого під-
ходу виникає велика затримка в часі між моментом виникнення
потреби в аналізі та одержанням його результатів. Дуже часто
отриманий результат аналізу, який був потрібний аналітику, запіз-
нюється і рішення приймається без його врахування. Тому для
прийняття оперативних рішень такий вид аналізу не придатний.
До другої групи належать нерегламентні аналітичні задачі, які
вирішуються при виникненні потреби в бізнес-аналізі особи, що
приймає рішення. Тобто періодичність і представлення результа-
тів вирішення цих задач на може бути регламентована. Ці задачі
вирішуються за запитами, структура та види яких можуть зміню-
ватись залежно від бізнес-потреб.
Потреба в оперативному багатоаспектному бізнес-аналізі при-
вела до виникнення нової технології вирішення аналітичних за-
дач, яка дістала назву OLAP (On-Line Analytical Processing). Ця
технологія призначена забезпечувати аналітиків динамічним ба-
гатовимірним аналізом консолідованих даних.
Вирішення аналітичних задач не може обмежуватись лише да-
ними трансакційних систем. Для порівняльного аналізу та вияв-
лення тенденцій потрібно залучати великі обсяги зовнішніх даних
з різних статистичних збірників електронних та інших джерел.
Самі аналітичні запити складніші, ніж запити, які формулюються в
трансакційних системах. Так, одним із запитів до OLTP-системи
буде отримання інформації про суму коштів на рахунка конкрет-
ного клієнта. В аналітичній системі запит може мати таке форму-

261
лювання: «Знайти середнє значення проміжку часу між виставлен-
ням рахунка та сплатою його клієнтом у поточному і попередньо-
му роках у розрізі різних груп клієнтів». Виконати такий запит у
термінах мови SQL на основі традиційних баз даних дуже складно.
Для того, щоб реалізовувати оперативним чином аналітичні
запити, дані повинні бути організовані відмінним від прийнятого
в OLTP-системах способом. Це пов’язано з такими факторами:
 по-перше, для реалізації аналітичних запитів потрібна оброб-
ка великих обсягів інформації. У БД дані зберігаються в нормалі-
зованому вигляді: чим більша ступінь нормалізації, тим більше в
реляційній базі даних таблиць, тим повільніше виконуватиметься
аналіз, бо потрібно здійснити багато операцій об’єднання таблиць;
 по-друге, виконання деяких аналітичних запитів, пов’язаних
з виявленням тенденцій і прогнозуванням, потребує впорядкова-
них даних. Реляційна модель не передбачає певного порядку в
записах таблиці.
Тому виконання аналітичних запитів на традиційній базі даних
нераціонально, а іноді неможливе. Зручним способом зберігання
даних для вирішення оперативних аналітичних задач є різновид
баз даних, який носить назву сховище даних (Data Warehouse).
Доцільно провести певні розмежування та з’ясувати взаємо-
зв’язки OLAP-технологій і сховищ даних. Це необхідно зробити
тому, що іноді ці поняття ототожнюються. Хоча ці дві концепції
дуже часто технологічно поєднуються, вони можуть бути жод-
ним чином не пов’язані між собою. Тобто сховища даних як дже-
рело даних можуть використовуватись не лише для оперативних,
а й для регламентних аналітичних звітів. У той же час OLAP мо-
же черпати дані для оперативного аналізу не тільки зі сховищ да-
них, а також з традиційних баз даних.

9.2. Поняття сховищ даних та передумови їх

створення

Концепція сховищ даних вперше було сформульована у

1992 р. Необхідність розробки нової концепції сховищ даних обу-
мовлена такими факторами:
 Системи підтримки прийняття рішень, що ґрунтуються на
формуванні аналітичних запитів, почали конфліктувати з транс-
акційними системами оперативної обробки даних (OLTP-
системами). Одночасне вирішення оперативних та аналітичних
запитів на одній базі даних часто призводить до нестачі ресурсів.

262
  Реалізація аналітичних звітів на основі традиційних баз да-
них, які містять оперативну інформацію, займає дуже багато ча-
су. Це пов’язано з тим, що для аналітичних звітів переважно по-
трібні не первинні оперативні дані, а певним чином узагальнені,
тобто агреговані дані. Причому витрати часу, необхідні на фор-
мування аналітичних звітів, невпинно зростають по мірі зростан-
ня обсягів оперативної інформації в базі даних. Це призводить до
затримок при реалізації аналітичних запитів.
 Дуже часто на підприємстві чи в організації функціонує кі-
лька OLTP-систем, кожна з яких має свою окрему базу даних.
Уних використовуються різні структури даних, способи кодуван-
ня, одиниці вимірювання. Побудова зведеного аналітичного за-
питу на основі кількох баз даних є дуже складною проблемою,
яка спочатку потребує вирішення проблеми узгодженості даних,
що зберігаються в різних базах даних.
 Для вирішення оперативних аналітичних задач недостатньо
інформації, що зберігається в базі даних. Необхідні архівні дані, що
містять результати роботи за попередні календарні періоди. Крім
того, дуже часто виникає потреба в зовнішніх джерелах (дані про
клієнтів, конкурентів, політичні, соціологічні, демографічні та ін.).
Основні відмінності трансакційних систем від аналітичних,
що створили передумови для розробки концепції сховищ даних,
згруповані в табл. 9.1.
Таблиця 9.1
ПОРІВНЯЛЬНІ ХАРАКТЕРИСТИКИ ТРАНСАКЦІЙНИХ ТА АНАЛІТИЧНИХ
СИСТЕМ

Ознаки Трансакційна система (ТС) Аналітична система (АС)

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

263
 Оперативні БД можуть містити
семантично еквівалентну інфо-
рмацію, представлену в різних
форматах, яка не завжди може
Вигляд даних бути узгодженою між собою
(через використання різних
технологій і різних СКДБ)
Ознаки Трансакційна система (ТС)
Дані є динамічними, тобто
Частота оновлен- безперервно оновлюються і
ня дуже часто змінюються
Перелік запитів до трансакцій-
них систем уже відомий при її
проектуванні. Переважають рег-
ламентні запити, які детерміно-
вані в часі, тобто вирішуються
з певною періодичністю і ма-
Характер запитів ють фіксований перелік вихід-
до системи них повідомлень. При вирі-
шенні цих задач переважають
дуже часті вибірки з БД даних
невеликими порціями. ТС в ос-
новному складаються із задач
прямого розрахунку
Складання певного фіксованого
набору звітних форм, заздале-
гідь відомої структури. Пере-
Представлення важна кількість цих звітів ви-
результатів робо- магають первинної
ти деталізованої інформації
Для оперативної БД, як прави-
Захист ло, досить захисту на рівні
таблиць
Мета даними в OLTP-системах
Наявність мета користуються переважно лише
даних адміністратори систем
264
Сховище даних повинно містити
узгоджену інформацію, що пред-
ставлена в однакових форматах і
максимально відповідає опера-
тивній БД. Тобто сховища даних
повинно включати компоненту
для приведення до єдиного ви-
гляду інформації з різних дже-
рел
Закінчення табл. 9.1
Аналітична система (АС)
Дані є статичними, тобто вони
практично не змінюються, а
лише поповнюються новими
записами
При вирішенні аналітичних
задач переважають нерегламе-
нтні запити, які потребують об-
робки великих обсягів інформа-
ції. Тобто запити потребують
агрегованих даних (сум, мініма-
льних, максимальних, середніх
та інших агрегатів даних). АС
повинна надавати аналітику
різноманітні інструменти для
обробки даних, з використан-
ням різних методик аналізу (на-
приклад, статистичні методи,
нейронні мережі, генетичні ал-
горитми, нечітка логіка і т. п.)
Отримання великого числа рі-
зноманітних звітів на основі
агрегованих даних. Надання
аналітику можливості самому
визначати характер даних, що
використовуються, і форму
звітів. Виведення аналізу в
зручному для розуміння ви-
гляді (графічному, табличному
і т.ін.)
Захист аналітичних даних по-
требує більшої грануляції (за-
хист на рівні окремих значень
аналітичних показників)
Репозитарій мета даних — це
необхідна компонента, яка є
довідником про дані сховища
для користувачів системи
 Перелічені вище фактори створили передумови для розробки
різновиду баз даних, що дістала назву сховища даних.
Сховище даних — це інтегрований накопичувач даних, які
збираються з різних систем та джерел і використовуються
для бізнес-аналізу та прийняття обґрунтованих стратегічних
рішень.

Взаємозв’язок баз даних зі сховищами даних наведено на рис. 9.1.

Первинні
документи

OLTP-звіти
Бази
даних OLTP-системи
Вихідні
файли
Сховище
Архіви даних

Зовнішні OLAP-системи Аналітичні

джерела звіти

Рис. 9.1. Взаємозв’язок баз даних і сховищ даних

Перш ніж завантажити дані в сховище, необхідно виконувати

функції попереднього їх відбору, конвертації та очистки.

9.3. Основні характеристики сховищ даних

Сховище даних (Data Warehouse) — це предметно орі-

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

265
 Предметна орієнтація. Дані в сховищі даних організовані від-
повідно до основних напрямів діяльності підприємства чи фірми
(замовники, продажі, склад і т. п.). Це — відмінність сховищ даних
від організації оперативної БД, в якій дані організуються відповід-
но до процесів (відвантаження товару, виписка рахунків і т. п.).
Предметна організація даних не лише спрощує проведення аналізу,
але й значно прискорює виконання аналітичних розрахунків. Тоб-
то сховища орієнтовані на бізнес-поняття, а не на бізнес-процеси.
Інтегрованість. Дані у сховище надходять з різних джерел, де
вони можуть мати різні імена, формати, одиниці вимірювання і
способи кодування. Перш ніж завантажити дані до сховища, вони
перевіряються, певним чином відбираються, приводяться до одно-
го єдиного способу кодування, виду та формату і в необхідній мірі
агрегуються (тобто обраховуються сумарні показники). Зцього
моменту вони представляються користувачеві у вигляді єдиного
інформаційного простору, які набагато простіше аналізувати.
Якщо, наприклад, у чотирьох різних базах даних код товару
кодувався чотирма різними способами, то в сховищі даних буде
використана єдина система кодування.
Підтримка хронології. Дані в сховищі даних зберігаються у
вигляді «історичних пластів», кожен з яких характеризує певний
календарний період. Це дозволяє проводити аналіз зміни показ-
ників у часі. В OLTP-системах істинність даних гарантована
тільки в момент читання, оскільки вже в наступну мить вони мо-
жуть змінитися внаслідок чергової трансакції. Важливою відмін-
ністю сховищ від OLTP-систем є те, що дані в них зберігають
свою істинність у будь-який момент процесу читання.
В OLTP-системах інформація часто модифікується як резуль-
тат виконання яких-небудь трансакцій. Часова інваріантність да-
них у сховищі даних досягається за рахунок введення полів, що
характеризують час (день, тиждень, місяць) у ключі таблиць.
УСД містяться начебто моментальні знімки даних. Кожний еле-
мент у своєму ключі явно або непрямо зберігає часовий пара-
метр, наприклад день, місяць або рік.
Незмінність. Дані сховища даних, що характеризують кожен
«історичний пласт», не можуть змінюватись. Це теж є суттєвою
відмінністю даних, що зберігаються у сховищі даних, від опера-
тивних даних. Останні дані в базі даних постійно змінюються.
Зданими сховища даних можливі лише операції їх первинного
завантаження, пошуку та читання.
Якщо при створенні OLTP-систем розробники повинні врахо-
вувати такі моменти, як відкоти трансакцій після збою сервера,

266
боротьба із взаємним блокуванням процесів (deadlocks), збере-
ження цілісності даних, то для сховища даних ці проблеми не так
актуальні. Перед розробниками стоять інші задачі, пов’язані, на-
приклад, із забезпеченням високої швидкості доступу до даних.
Мінімальна надлишковість. Незважаючи на те, що інформація
до сховищ даних завантажується з БД OLTP-систем, це не при-
зводить до надлишковості даних. Мінімум надлишковості даних
забезпечується тим, що перш ніж завантажувати дані до сховищ,
вони фільтруються і певним чином очищаються від тих даних,
які не потрібні і не можуть бути використаними в бізнес-аналізі.

9.4. Характеристика основних компонент схови-

ща даних

Враховуючи те, що сховища даних є новою технологію, яка

розвивається, існують різні підходи до викладення структури.
Згідно з [25] схема основних компонентів сховища даних вклю-
чає до свого складу такі компоненти (рис. 9.2).
Менеджер завантаження виконує функції диспетчеризації
щодо регулярності завантаження нових даних до сховища даних
згідно зі встановленим регламентом. Оскільки джерелом даних
можуть бути різні OLTP-системи, функції менеджера заванта-
ження також полягають в очищенні, конвертації та приведенні
даних до заданого виду їх представлення в СД.

267
 Джерела даних
Дані Зовнішні
OLTP-систем дані

Менеджер завантаження
Предметні Мета-
дані дані
Менеджер
сховища даних

Детальні Репози-
дані тарій

Агреговані
дані
СКБД
Менеджер запитів

Засоби Data Засоби доступу

OLАP-засоби Mining користувача

Рис. 9.2. Основні компоненти сховища даних

Менеджер сховища виконує операції аналізу та управління

даними. Це такі основні операції: аналіз узгодженості та несупе-
речності даних; перетворення та переміщення даних з тимчасово-
го сховища в основні таблиці СД; створення індексів; денормалі-
зація даних у разі її необхідності; агрегація (узагальнення) даних;
резервне копіювання та архівування даних.
Детальні (оперативні) дані — ця складова містить усі дета-
льні дані, які визначені схемою сховища даних. Це можуть бути
як первинні дані найнижчого рівня деталізації, так і узагальнені
до певного рівня деталізації.
Агреговані дані — ця компонента містить дані, які попере-
дньо оброблені менеджером сховища з метою їх часткового чи
глибокого узагальнення. У цій частині зберігаються певним чи-

268
ном відсортовані та згруповані дані, необхідні для виконання за-
питів.
Ця частина сховища є тимчасовою і змінною, оскільки вона
постійно модифікується у відповідь на зміни запитів. Необхід-
ність цієї компоненти пов’язана з підвищенням продуктивності
виконання запитів. Узагальнені дані поновлюються по мірі над-
ходження нових даних до системи. Частково узагальнені дані —
це результат певного узагальнення та агрегації детальних даних.
Глибоко узагальнені дані отримуються на основі узагальнення част-
ково узагальнених даних.
Репозитарій метаданих — це інформація про дані, що збері-
гаються в СД.
Структура метаданих може відрізнятися залежно від їх при-
значення. Метадані використовуються для таких основних цілей:
Вибірка і завантаження даних. Метадані містять інформацію
про джерела даних, способи та періодичність їх вибірки і заван-
таження в СД.
Обслуговування сховища. Метадані використовуються для ав-
томатизації процедур узагальнення даних.
Обслуговування запитів. Метадані використовуються для ви-
значення переліку таблиць для виконання запитів.
Менеджер запитів — це складова сховища, яка виконує опе-
рації, пов’язані з управлінням запитів користувачів. Ця компоне-
нта реалізується, як правило, на базі СКБД, що підтримує схови-
ще даних, а також сховища даних і програм власної розробки.
Користувачі спілкуються і працюють зі сховищем за допомо-
гою спеціальних засобів. До них можуть бути віднесені OLAP-
інструменти, засоби, що підтримують технологію Data Mining, та
різні засоби доступу кінцевого користувача: створення звітів і за-
питів; інструмент що належать до систем підтримки прийняття
рішень (Executive Information System, EIS).
При визначенні програмно-технологічної архітектури схови-
ща потрібно мати на увазі, що система прийняття рішень, на які б
візуальні засоби вона не спиралася, повинна надавати користува-
чеві можливість деталізації інформації. Керівник підприємства
або фірми, отримавши інтегроване представлення даних і висно-
вки, зроблені на їх основі, може зажадати детальніші дані, що
уточнюють джерело даних або причини висновків. З погляду
проектувальника сховищ даних це означає, що необхідно забез-
печити його взаємодію в деяких випадках з БД OLTP-систем.

269
 9.5. Архітектура сховищ даних

Розрізняють такі види сховищ даних: корпоративні і кіоски,

або вітрини, даних.
Корпоративні сховища даних (enterprise data warehouses)
вміщують інтегровану інформацію, зібрану з певної множини
оперативних БД, яка характеризує всю корпорацію і необхідна
для виконання консолідованого аналізу діяльності корпорації в
цілому. Такі сховища охоплюють усі багаточисленні напрями ді-
яльності корпорації і використовуються для прийняття як такти-
чних, так і стратегічних рішень. Розробка корпоративного схо-
вища даних — дуже трудомісткий процес, який може тривати від
одного до кількох років, а обсяги сховища можуть досягати від
50 Гбайт до кількох терабайт.
Кіоски, або вітрини, даних (data marts) — це певна підмножи-
на корпоративних даних, які характеризують конкретний аспект
діяльності корпорації, наприклад роботу конкретного підрозділу.
Кіоск може вміщувати як агреговані, так і первинні дані певної
предметної області. Кіоск може отримувати дані з корпоративно-
го сховища даних (залежний кіоск) чи бути незалежним і тоді
джерелом поповнення його даними будуть оперативні БД. Розро-
бка кіоску даних потребує значно менше часу і в середньому за-
ймає приблизно 3—4 місяці.
Корпоративні сховища даних і кіоски будуються за подібними
принципами і використовують практично одинакові технології.
Останнім часом з’явилось поняття глобального сховища даних,
в якому сховище даних розглядається як єдине джерело інтегро-
ваних даних для всіх вітрин даних.
Успіх розробки та впровадження сховища даних залежить від
обґрунтованості вибору його архітектури. Щодо концептуальної
архітектури сховищ даних, то згідно з [46] сховища даних залеж-
но від підходів до побудови їх архітектури поділяються на:
 віртуальне СД;
 СД на основі семантичної інтеграції предметних областей;
 СД із системою управління запитами до предметних областей;
 Монолітне сховище;
 СД на основі стандартного архіву даних.
Зупинимося детальніше на характеристиці кожної архітектури.
Віртуальне сховище даних. Основою віртуального сховища
даних є репозитарій метаданих, який описує місце розташування
даних в оперативних системах, структуру даних, методи агрегації

270
та завантаження даних, відомості про структуру бізнес-понять та
інші дані. Архітектурно-віртуальне сховище даних складається з
оперативних систем та системи управління запитами, що зберігає
свій репозиторій метаданих (рис. 9.3).

Успадкування Управління
Управління
Успадковані запитамиіі
запитами
системи-джерела
системи-джерела Користувач
даних репозитарій
репозитарій
даних метаданих
метаданих

Рис. 9.3. Архітектура віртуального сховища даних

Коли користувач запускає на виконання запит, то засоби

управління запитами, використовуючи метадані, виконують по-
шук та вибірку необхідних даних з оперативних систем. Потім ці
дані об’єднуються необхідним чином і видаються користувачеві.
Тобто при виконанні запитів щоразу дані об’єднуються з різних
оперативних систем, тому системи, побудовані за цими принци-
пами, характеризуються низькою продуктивність виконання за-
питів. Інший недолік такої архітектури — можливість отримання
різних результатів на одні й ті ж запити, виконані у різний час,
оскільки дані оперативних систем постійно змінюються і не збе-
рігають історичних даних. Ще одна суттєва перепона, яка стоїть
на шляху побудови такої архітектури, — це відсутність єдиної
структури полів, кодів і ключів. Тому для організацій з розгалу-
женою організаційною структурою та наявністю великої кількос-
ті інформаційних систем, кожна з яких працює зі своєю базою
даних, такий підхід до архітектури сховища даних не може бути
прийнятним, оскільки кожного разу для виконання запитів потріб-
но буде об’єднувати дані з різних систем замість того, щоб це
зробити один раз при створенні сховища даних.
Переваги цієї архітектури полягають у тому, що максимально
використовується існуюче апаратне забезпечення і основне нава-
нтаження по виконанню запитів беруть на себе системи-джерела,
а система управління запитами лише управляє результатом та на-
дає його користувачеві. Така архітектура побудови сховища да-
них може бути рекомендована для організацій, інформаційні сис-
теми-джерела якої побудовані з урахуванням системного
підходу. Тобто вхідні дані для виконання запитів характеризу-
ються високою якістю, наявністю спільних ключів і систем кла-
сифікації та кодування. Крім того, інформаційні системи-джерела
мають засоби обмежень ресурсів, які виділяються для виконання
271
запитів, що надходять з віртуального сховища, щоб уникнути
ефекту «затоплення» запитами сховища.
Архітектура сховища на основі семантичної інтеграції пред-
метних областей. Сховище, побудоване за цією архітектурою,
поділено на певні розділи, кожен з яких характеризує окрему
предметну область, але проектуються вони за єдиними правила-
ми, що гарантує легкість їх об’єднання. Тобто спочатку проекту-
ється єдина корпоративна модель сховища, яка забезпечує іден-
тичність структур полів, кодів і первинних ключів. Цю
архітектуру схематично можна відобразити таким чином
(рис.9.4):

Успадковані
системи-джерела
даних

Вибірка,
перетворення
та інтеграція

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Користувач

Рис. 9.4. Архітектура сховища на основі семантичної інтеграції предме-

тних областей

Переваги цієї архітектури полягають у фізичному розподілі

сховища даних за предметними областями та простоті проекту-
вання. Після визначення процедур вибірки даних і зв’язків між
окремими предметними областями можна приступати до розроб-
ки сховища для певної предметної області. Тобто сховище для
окремої предметної області можна розробляти незалежно від ін-
ших предметних областей.
Для запобігання того, щоб для кожної предметної області ро-
бити окремі вибірки даних, програмні засоби будуються таким
чином, щоб при вибірці даних виконувалася семантична інтегра-
ція, необхідна для побудови сховищ даних усіх предметних обла-
272
стей. Вибрані дані розміщуються в проміжній області даних, і
зберігаються рівно стільки часу, скільки необхідно для заповнен-
ня сховищ предметних областей. Потім вони архівуються і зни-
щуються.
Проблемним є питання виконання запитів, що стосуються кі-
лькох предметних областей. Тобто серйозним недоліком цих сис-
тем є відсутність системи управління запитами, внаслідок чого на
виконання запитів, що стосуються різних предметних областей,
витрачається значний час, оскільки необхідно, щоб СКБД
об’єднала дані з різних ПО в одну загальну таблицю для реаліза-
ції таких запитів. Ця архітектура придатна: для організацій, що
мають на меті послідовну розробку сховищ даних для кількох
предметних областей, або кількох вітрин даних; для корпоратив-
ного управління на основі його децентралізації при централізова-
ному підході до обробки даних таких організацій, які не мають
потреби в отриманні інтегрованих рішень на основі інформації
кількох предметних областей.
Архітектура із системою управління запитами до предметних
областей. Ця архітектура, на відміну від попередньої, доповнюється
блоком управління запитами (схематично відображена на рис. 9.5).
Наявність блоку управління запитами дозволяє користувачеві
глибоко не занурюватись у деталі побудови структур даних кож-
ної предметної області. За допомогою блоку «Управління запи-
тами» спрощується вирішення проблеми семантичної інтеграції
областей, але залишається недолік, що насамперед виявляється у
значного часі виконання запитів до різних предметних областей.
Тому для організацій, які характеризуються дуже великими обся-
гами інформації, така архітектура сховища даних є недоцільною,
оскільки час реалізації запитів при збільшенні обсягів сховища да-
них буде весь час зростати. Ця архітектура вписується в корпора-
тивний стиль управління організацій з централізованою обробкою
даних і децентралізованим управлінням, які потребують створення
кількох вітрин даних і мають потребу в отриманні інтегрованих
рішень на основі інформації кількох предметних областей.

273
 Успадкування
Успадковані
системи-джерела
системи-джерела
даних даних

Вибірка, пертворення
та інтеграція

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Управління запитами

Користувач

Рис. 9.5. Архітектура із системою управління запитами до предметних

областей
Монолітне сховище. Монолітне сховище містить не дані всіх
предметних областей, а метадані. Тобто це репозиторій усіх досту-
пних на даний момент оперативних даних, які представлені на най-
вищому рівні деталізації і нормалізації. Запити не виконуються над
монолітним сховищем. Дані із монолітного сховища надходять у
допоміжне сховище, яке є проміжним сховищем даних (intermediate
data store), а потім передаються у сховища даних предметної обла-
сті, яке називається робочим сховищем (business data warehouse).
Архітектура монолітного сховища наведена на рис. 9.6.
Перевагою такої архітектури сховища даних є його гнучкість
для використання спеціалістами, а недоліками — занадто велика
кількість рівнів і значна надлишковість, що ускладнює супрово-
дження. Ця архітектура придатна для організацій з централізованою
командно-адміністративною системою управління, які можуть ви-
ділити значні кошти та задіяти велику кількість персоналу для
розробки та впровадження технології на основі сховища даних.

274
 Успадковані систе-
ми-джерела даних

Вибірка і
перетворення

Монолітне
сховище

Проміжне Проміжне
сховище сховище

Предметна Предметна
область 1 Користувач область 2
(кіоск 1) (кіоск 2)

Рис. 9.6. Архітектура монолітного сховища даних

Стандартний архів даних. Сховище на основі стандартного

архіву відображено на рис. 9.7.

Успадковані
Успадкування
системи-джерела
системи-джерела
даних
даних

Вибірка,
пертворення
та інтеграція

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Користувач

Рис. 9.7. Архітектура сховища на основі стандартного архіву даних

275
 При використанні цієї архітектури процес семантичної інтег-
рації і проміжне сховище заміняються стандартним архівом. Стан-
дартний архів — це стаціонарне інтегроване сховище, що вміщує
інформацію для всіх СППР, і яке можна використовувати для за-
повнення сховищ окремих предметних областей і вітрин даних.
Недоліком цього типу архітектури є високі витрати на пам’ять та
підвищені вимоги до супроводження. Великі витрати пам’яті
пов’язані з тим, що дані у стандартному архіві повинні зберіга-
тись в такому вигляді, щоб легко забезпечувати обробку опера-
тивних деталізованих запитів до сховища даних.
Ще одним суттєвим недоліком архітектури цього типу є від-
сутність інтеграції окремих предметних областей. Тому вклю-
чення додаткового блоку управління запитами (рис. 9.8) підви-
щує зручність використання сховищ даних при виконанні
інтегрованих запитів, для реалізації яких потрібні дані з кількох
предметних областей.

Успадковані
Успадкування
системи-джерела
системи-джерела
даних
даних

Вибірка,
пертворення
та інтеграція

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Управління
запитами

Користувач

Рис. 9.8. Архітектура сховища на основі стандартного архіву даних з

блоком управління запитами

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

Питання для самоперевірки

1. Охарактеризуйте передумови створення концепції схо-

вищ даних.
2. Охарактеризуйте відмінності між аналітичними і транс-
акційними системами обробки даних.
3. Дайте визначення сховища даних і наведіть основні його
відмінності від бази даних.
4. Дайте визначення корпоративного сховища даних та віт-
рини (кіоску) даних.
5. Перелічіть види побудови архітектури сховищ даних.
6. Охарактеризуйте архітектуру сховища даних на основі
семантичної інтеграції предметних областей.
7. Охарактеризуйте архітектуру сховища даних з системою
управління запитами до предметних областей.
8. Охарактеризуйте архітектуру монолітного сховища даних.
9. Охарактеризуйте архітектуру сховища даних на основі
стандартного архіву даних.
10. Охарактеризуйте основні компоненти сховища даних.
11. Репозитарій метаданих його роль та призначення.

277
 10 Pоздiл
МОДЕЛІ СХОВИЩ ДАНИХ ТА ОСОБЛИВОСТІ
ЇХ ПРОЕКТУВАННЯ

10.1. Багатовимірна модель

Найбільш вдалою формою сховищ даних, що надає

можливість багатовимірної їх параметризації, є представлення
даних у вигляді не плоскої реляційної моделі, а багатовимірної
моделі даних. Системи на основі багатовимірних моделей дістали
назву MOLAP-систем (Multidimensional OLAP).
В основі багатовимірної моделі лежить поняття багатовимір-
ного куба даних, у комірках якого зберігаються показники (змін-
ні), що аналізуються, (наприклад обсяги продаж), а вимірювання
характеризують якісь ознаки цих показників (скажімо регіони, де
виконувались продажі; календарні періоди, за які ведеться облік
продаж). У найпростішому варіанті двовимірної моделі маємо
таблицю, що показує значення обсягів продажу по товарах і ка-
лендарних періодах. Додавши третій вимір — регіон, отримуємо
представлення моделі у вигляді куба (рис. 10.1).
Регіон

Період

Обсяги
продажів

Товар

Рис. 10.1. Багатовимірна модель даних

Подальше ускладнення моделі даних може виконуватись у кі-

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

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

Продукція А 18,1 179,2 181,0 153,4 10,2

Продукція Б 23,5 236,7 303,9 181,0 15,5

Продукція В 12,3 101,1 114,5 79,7 9,4

Продукція Г 6,8 54,2 62,1 35,7 3,3

Продукція Д 4,5 42,3 53,9 23,1 2,2 05.03

04.03
03.03
Продукція Е 28,0 190,6 302,7 195,8 22,3 02.03
01.03 Період
1 2 3 4 5
Регіон

Рис. 10.2. Приклад куба для аналізу прибутку від реалізації продук-
ції

Таким чином, основними поняттями багатовимірної моделі

є: вимір (Demensions), відношення вимірів та комірки (Cell), в
якій зберігаються певні дані, що аналізуються. Іноді замість
терміну «комірка» вживається термін «показник» чи «змінна»
(Measure).
Показник, або змінна, — це поле, значення якого однозна-
чно визначаються фіксованим набором вимірів, що характе-
ризують певний факт.

279
 Показники, або змінні, складають, як правило, основний вміст
сховища даних і можуть бути представленими:
 числовими характеристиками факту чи події, що відбували-
ся на об’єкті управління, для якого створюється сховище (напри-
клад, обсяги чи дохід від продажів);
 формулами, що, як правило, являють собою прості функції
агрегування показників (змінних) для отримання узагальнених
даних (наприклад, сума, яка консолідує значення змінної за кіль-
ка календарних періодів в одне підсумкове значення).
Вимір — це множина однотипних даних, що утворюють од-
ну з граней куба і характеризують якусь ознаку показників,
котрі знаходяться в комірці багатовимірного куба.

Наприклад, день, місяць, квартал, рік — це виміри часу; ра-

йон, область, країна — це географічні виміри. За виміром вико-
нується індексація даних у багатовимірній базі даних (ББД). Ви-
міри бувають колективними (shared dimensional) та приватні
(private dimensional).
Колективні виміри — це виміри, які можуть використовува-
тись одночасно в декількох кубах. Колективними вимірами мо-
жуть бути якісь ознаки, які використовуються при бізнес-аналізі
різних предметних областей. Приватні виміри — це виміри, які
належать конкретному кубу і створюються разом з ним. Інакше
кажучи, це специфічні ознаки, що характеризують лише певну
конкретну предметну область.
Сукупність вимірів визначають параметри простору, в якому
можна буде виконувати бізнес-аналіз.
Відношення — це зв’язки між різними вимірами моделі та
між окремими значеннями всередині певного виміру.

Між окремими значення всередині певного виміру повинна

бути певна ієрархія, котра, як правило, характеризує тип відно-
шення «один до багатьох», наприклад населений пункт, район,
область. Відношення можуть також визначати зв’язки між двома
різними вимірами. Наприклад, вимір ТОВАР може бути
зв’язаним з виміром КАТЕГОРІЯ, яка, може, в свою чергу, набу-
вати таких значень: «Побутові товари», «Спортивні товари»,
«Канцелярські товари» та ін. В переважній більшості випадків ці
зв’язки характеризують тип відношення «один до одного» Від-
ношення між вимірами визначають порядок агрегування показ-
ників (змінних) багатовимірної моделі.
280
 У багатовимірних СУДБ (БСКДБ) використовуються два ос-
новних варіанти організації даних: гіперкубічна модель, поліку-
бічна модель.
Гіперкубічна модель — це модель, показники якої визначають-
ся однаковими наборами вимірювань.
Полікубічна модель — це модель, що підтримує кілька гіпер-
кубів різної розмірності з різними вимірами їх граней.
При виконанні запитів у багатовимірній моделі можуть здійс-
нюватись такі операції:
Операція перетину (slice-and-dice) виконує вибірку, яка зме-
ншує розмірність куба. При виконанні операції перетину форму-
ється підмножина гіперкуба, в якому значення одного чи кількох
вимірів фіксовано. Наприклад, зафіксувавши вимір «Період» і
надавши йому якесь конкретне значення, отримуємо двовимірну
таблицю з даними про обсяги продажів за вказаний період. Фік-
сація значення виміру при виконанні операції перетину зменшує
розмірність куба.
Операції розгортання та згортання (drill-down і roll-up) —
взаємно протилежні операції, які використовують ієрархію вимі-
рів і змінних для деталізації чи агрегування показників. Для ви-
конання операцій згортання і деталізації повинна існувати ієрар-
хія значень вимірів, тобто підпорядкованість одних значень
іншим. Наприклад, у межах виміру «Період» може виводитись
певна ієрархія значень, наприклад, рік, квартал, місяць і т.д. При
виконанні операції згортання одне із значень виміру замінюється
іншим значенням більш високого рівня ієрархії. Виконання цієї
операції забезпечує перехід від деталізованих до узагальнених
даних. Операція деталізації — це операція, яка є зворотною щодо
операції згортання. Вона забезпечує перехід від узагальнених до
деталізованих даних.
Операція об’єднання (drill-across) комбінує куби, які мають
одне чи кілька спільних вимірювань. З позицій реляційної алгеб-
ри така операція виконує з’єднання кубів (join).
Операція обертання (rotating) куба надає користувачеві мож-
ливості побачити дані, сгруповані за іншими вимірами. Операції
обертання змінюють порядок представлення вимірів. Як правило,
вони використовуються для більш зручного погляду сприйняття
представлення двовимірних таблиць. Після виконання цієї опе-
рації міняються місцями рядки і стовпчики таблиці.
Показники, що перебувають у комірках багатовимірної моделі
можна відшукати за будь-яким вимірюванням чи їх комбінацією.
Тобто, при аналізі обсягів продажів можна підрахувати число ви-

281
робів, проданих протягом останнього року, підсумувавши дані
про обсяги продажів за кожен місяць. Якщо необхідно з’ясувати,
який з регіональних відділів продажів показав кращі результати,
можна виконати пошук по регіонах і знайти максимальну вели-
чину обсягу продажів у межах регіону.
MOLAP-системи досить чутливі до обсягів даних, що збері-
гаються.
Проте багатовимірна модель має серйозні недоліки, які галь-
мують її широке застосування. У багатовимірній моделі заздале-
гіть резервується місце для всіх значень, навіть якщо частина з
них відсутня. Тобто не всі комірки багатовимірного куба можуть
бути заповнені конкретними даними. Другий недолік полягає в
тому, що вибір високого рівня деталізації при реалізації гіперку-
ба може дуже збільшити розмір у багатовимірного сховища. Че-
рез це поширені на ринку багатовимірні СКБД не в змозі оперу-
вати даними великого обсягу. Вони, як правило, обмежуються
10—20 гігабайтами. Багатовимірну модель доцільно використо-
вувати тоді, коли обсяги інформації, яку потрібно зберігати, не-
великі, і гіперкуб має стабільний набір вимірів.

10.2. Реляційна модель

Залежно від відповіді на запитання, гіперкуб існує як

окрема фізична структура або лише як віртуальна модель даних,
розрізнюють системи MOLAP (Multidimensional OLAP), ROLAP
(Relational OLAP) і HOLAP (Hybrid OLAP).
Основою ROLAP-моделі є звичайні, традиційні, реляційні
моделі даних.
У ROLAP-системах гіперкуб — це лише користувацький ін-
терфейс, який емолюється СКДБ на логічному рівні. Дані в схо-
вищі представляються у вигляді моделі, що дістала назву зірка
(star schema). Ця модель складається з таблиць двох типів: однієї
таблиці досліджуваних даних, тобто фактів (fact table), це —
центр зірки; і кількох таблиць, які характеризують певні виміри
цих фактів (demension table).
Таблиця фактів містить складовий ключ, який об’єднує всі
ключі таблиць вимірів, а також значення показників, що аналізу-
ються. За допомогою цих ключів таблиця фактів зв’язується з
таблицями вимірів. На схемі зв’язків таблиця фактів розташову-
ється в центрі, а таблиці вимірів — на вихідних з центра проме-
282
нях, створючих малюнок зірки. Звідси — і назва моделі
(рис.10.3). Таблиці вимірів виступають як батьківські, а таблиця
фактів є підпорядкованою дочірньою таблицею. Орієнтація дуг
на моделях сховищ не вказується.

Таблиця
«КАЛЕНДАР»
Таблиця «ВИБІР» Дата
Код вибору Тиждень
Назва вибору Таблиця «ПРОДАЖІ» Місяць
Одиниця вимірювання Дата продажу Квартал
Код вибору Рік
Код споживача
Код регіону
Кількість
Таблиця «РЕГІОН» Ціна за одиницю
Код регіону Знижка Таблиця
Назва регіону Прибуток за одиницю «СПОЖИВАЧ»
Код району Код споживача
Назва району Назва
Код населеного пункту Адреса
Назва населеного Телефон
пункту E-mail

Рис. 10.3. Схема моделі типу «зірка»

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

них дуже ефективна і зручна для кінцевих користувачів.
Таблиця фактів вміщує числові показники (змінні) якогось
напряму діяльності компанії чи фірми, наприклад обсяги про-
дажів, прибуток та ін., а також ключі таблиць вимірів. Таблиці
вимірів містять додаткові характеристики ключових полів. Як
правило, це довідкові текстові дані, наприклад, дані про назву
товару, назву його виробника, тип товару тощо. Необхідно за-
уважити, що дані таблиць вимірів у моделі типу «зірка» можуть
бути денормалізовані. Нормалізація даних запобігає виникнен-
ню аномалій при внесенні змін до БД. Оскільки дані сховищ да-
них є незмінними, денормалізоване їх зберігання не зумовить
жодних аномалій.
Якщо ж таблиці вимірів нормалізовані, то така модель назива-
ється «сніжинкою» (snowflake schema). Тобто в моделі типу «сні-
жинка» може бути певна ієрархічна підпорядкованість між окре-
мими таблицями вимірів.
283
 Вибір
Вибір Календар
Календар
Продажіі
Продаж
Регіон
Регіон Споживач
Споживач

Район
Район

Населений
Населений
пункт
пункт

Рис. 10.4. Модель типу «сніжинка»

Таблиці, що приєднуються до таблиць вимірів, називаються

консольними (вони виступають як батьківські), а таблиці до яких
вони приєднуються, — таблицями-нащадками (потомками). При-
клад моделі типу «сніжинка» наведено на рис. 10.4.
Іноді може використовуватись гібридна модель, яка є комбі-
нацією денормалізованої моделі типу «зірка» та нормалізованої
моделі типу «сніжинка». При цьому деякі таблиці вимірів будуть
присутніми для задоволення різних запитів в обох моделях.
ROLAP-моделі дозволяють зберігати великі обсяги даних, але
вони не досить ефективні при виконанні аналітичних операцій.
Тому системи, побудовані на реляційних моделях, скоріше роз-
глядаються як інтелектуальні генератори звітів.
Поки що ці системи переважають, оскільки в реляційні моделі
вкладені великі інвестиції. До того ж вони більш зрозумілі і зви-
чні і застосовуються в таких сферах, як роздрібна торгівля, теле-
комунікації, фінанси, де кількість даних велика, а високої ефек-
тивності запитів не потрібно.
Для зменшення часу реакції при реалізації запитів у цих сис-
темах доцільно використовувати такий спеціальний засіб, як оп-
тимізатор запитів. Він аналізує запит і визначає кращу, з позиції
певного критерію, послідовність операцій звертання до сховища
даних для його реалізації. Оптимізатори запитів використовують
складні алгоритми статистичної обробки, які оперують числом
записів у таблиці, діапазонами ключів і т. д.
HOLAP-системи — це комбінований варіант зберігання да-
них, який використовують обидва типи СКБД. Агрегати даних
зберігаються у багатовимірній СКБД, детальні оперативні дані —
у реляційній СКБД.

283
 10.3. Відмінності проектування сховищ даних від
проектування баз даних

Проектування сховищ даних має свою особливість і

специфіку, що робить цей процес відмінним від проектування баз
даних трансакційних систем.
Сховища даних за своїм призначенням не схожі на бази даних
OLTP-систем, які обслуговують поточну оперативну діяльність
підприємств та організацій. Сховища даних використовуються
для підтримки прийняття стратегічних рішень, що дозволяє ана-
літикам виявляти тенденції, проводити порівняння і прогнозува-
ти майбутні результати.
Системи OLTP не можуть безпосередньо виконувати функції
OLAP. Зокрема, в системах OLTP зберігається тільки «момента-
льний знімок» найостаннішої оперативної інформації, а для ана-
лізу OLAP потрібне знання попередньої історії трансакцій за
тривалий період. Бази даних OLTP-систем безперервно понов-
люються, проте іноді містять пропуски і помилкові дані; для
OLAP потрібні статичні, вичерпні дані, з виправленими помил-
ками. І нарешті, системи OLTP обробляють тисячі (часом міль-
йони) трансакцій у день; системи OLAP виконують тільки одну
трансакцію за один цикл завантаження: коли дані в систему зава-
нтажуються в пакетному режимі, але можуть одночасно реалізо-
вувати та охоплювати тисячі запитів у день. (Під трансакцією тут
розуміємо операцію, внаслідок якої база даних переходить з од-
ного стану в інший.)
Ці відмінності у функціях бази даних і сховища даних відо-
бражено в структурних відмінностях. Основними з них при проек-
туванні сховищ даних порівняно з проектуванням баз даних є такі:
1. У базі даних OLTP-систем дані нормалізуються з метою за-
побігання виникненню аномалій надмірності та порушення ціліс-
ності й узгодженості бази даних при внесенні змін до бази даних.
Дані в сховищі даних є статичними, тобто в них практично не
вносять зміни, тому для сховищ не таке актуальне питання нор-
малізації.
2. При проектуванні баз даних не враховуються процедури їх
подальшої обробки. При проектуванні сховищ даних потрібно
знати і враховувати процедури агрегування даних, причому сту-
пінь узагальнення для різних даних може бути різним.
3. При проектуванні сховищ даних необхідно враховувати
«часовий» фактор, тобто ступінь деталізації фактів.
284
 10.4. Підходи до проектування сховищ даних

Існує два способи проектування сховищ даних: спад-

ний і висхідний.
Спадний спосіб — це такий спосіб, коли спочатку проектуєть-
ся корпоративне сховище, а потім воно стає джерелом інформації
для кіосків даних, тобто кіоски є залежними.
Висхідний спосіб полягає в тому, що на початку проектуються
кіоски даних, які охоплюють окремі напрями діяльності корпо-
рації чи певні його підрозділи.
За умови узгодженого форматування даних можна на основі
семантичного об’єднання кіосків створювати розподілені корпо-
ративні сховища даних. Такий поетапний підхід дає можливість у
дуже стислі терміни отримати відчутні вигоди, оскільки для фо-
рмування корпоративного сховища потрібно кілька років, а
окремі кіоски можна сформувати за кілька місяців.
Можна виокремити такі три підходи до проектування сховищ
даних [47]: метод реконструкції, проектування за шаблоном, про-
ектування під замовлення.
Метод реконструкцій — це проектування сховища на основі
використання існуючих моделей даних OLTP-систем. Тобто ос-
новним джерелом даних для сховища виступають дані, що збері-
гаються в базах даних трансакційних систем. Іноді цей підхід ще
називається «від джерела». Він полягає в трансформації існуючої
моделі бази даних у модель сховища даних. Проектування за до-
помогою реконструкції рекомендується у випадках:
 коли модель OLTP-системи відносно нова та охоплює всі
предметні області, для яких планується розробка сховища даних;
 коли багато таблиць фактів та вимірів присутні в моделі ба-
зи даних.
Проте цей підхід має теж ряд недоліків. Насамперед переважна
більшість сутностей бази даних орієнтована на бізнес-процеси, а
не на бізнес-поняття, що вимагає суттєвого перепроектування іс-
нуючої моделі до потреб сховища даних. Так, база даних може мі-
стити такі сутності, що характеризують бізнес-процеси, як ВІД-
ВАНТАЖЕННЯ та ВИПИСКА. Перша сутність характеризує
такий бізнес-процес, як відвантаження продукції споживачу, ад-
руга — містить дані банківської виписки про перерахування кош-
тів за відвантажену продукцію. Представлена в такому розрізі опе-
ративна інформація для сховища даних не є актуальною. Для
аналізу та прийняття рішень потрібні дані про реалізацію продук-

285
ції, тобто про ту частину продукції, яка була не лише відвантаже-
на, але й оплачена, тобто за яку надійшли виписки про перераху-
вання коштів на рахунок у банку. Таким чином, у сховищі даних
повинні зберігатись не первинні оперативні дані, арезультати їх
певної обробки, які виконуються при вирішенні задачі «Автомати-
зація обліку реалізації готової продукції». Тобто використання ме-
тоду реконструкції потребує глибоких знань предметної області та
специфіки і особливостей функціонуючих OLTP-систем.
Крім того, суттєвим недоліком зазначеного підходу до проек-
тування сховищ даних є те, що він орієнтується на існуючі дже-
рела OLTP-систем і не враховує зовнішніх даних, які можуть ви-
явитись досить суттєвими для бізнес-аналізу, який потрібно
виконувати в даній предметній області.
Проектування за шаблоном — це такий підхід до розробки
сховища даних, коли за основу для проектування береться існую-
ча, функціонуюча модель сховища даних у подібній предметній
області. В цю модель вносяться зміни, що відображають специ-
фіку конкретного об’єкта управління. Кращим варіантом цього
підходу є придбання стандартної галузевої моделі побудови схо-
вища даних, якщо така є на підприємствах галузі.
Проектування під замовлення — це проектування з «чисто-
го аркуша». Цей підхід ігнорує врахування існуючих галузевих
моделей сховищ даних і моделей OLTP-систем. При цьому варіан-
ті проектування розробники цілком зосереджують свою увагу на
потребах користувачів у результатах бізнес-аналізу та особливос-
тях предметної області, що досліджується. Тобто при цьому під-
ході акцент робиться на дослідженні бізнес-вимог до сховища з
боку користувачів. Тому цей підхід ще можна назвати «від запиту».
Проте цей підхід теж має недоліки, пов’язані з тим, що корис-
тувач, висуваючи вимоги, керується поточними потребами і не
враховує перспективи розвитку. Тобто важко визначитись з пов-
нотою та ефективним складом вимог до сховища з боку користу-
вачів. Крім того, користувач може поставити такі вимоги, які не
забезпечені потрібними даними.
Враховуючи недоліки кожного з підходів до проектування
сховищ даних, можна запропонувати комбінований підхід, який
включає елементи двох підходів до проектування сховищ да-
них— «від запиту» та «від джерела». Це дасть змогу врахувати ті
дані, які накопичені в трансакційних системах, шляхом їх певної
реконструкції та поповнити сховище даних недостатніми даними,
які потрібні з позицій користувача для проведення бізнес-аналізу.
Схема взаємодії цих двох підходів наведена на рис. 10.5.

286
 Вимоги користувачів

Аналіз та визначення даних,

потрібних для бізнес-аналізу

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

Аналіз трансакційних даних

та їх реконструкція
Дані OLTP-систем

Рис. 10.5. Взаємозв’язок підходів до проектування сховищ даних

10.5. Визначення основних елементів сховища

даних

Основними елементами даних, які зберігаються в схо-

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

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

10.5.1. Визначення та вимоги до змінних

Визначення змінних — дуже важливий момент при

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

288
 Змінні поділяються на три категорії: повністю адитивні, не-
адитивні та напівадитивні.
Адитивні змінні можуть підсумовуватися по всіх вимірах. На-
приклад, кількість проданих виробів є аддитивий факт, оскільки
шляхом сумування можна визначити, скільки виробів продано на
минулому тижні (за часом); скільки виробів продано по регіонах;
скільки продано кожному споживачу. В сховищах даних надаєть-
ся перевага адитивним змінним, оскільки, підсумовуючи їх, мож-
на отримати компактні набори результатів. Тобто бажаним для
змінної є її повна адитивність.
Деякі змінні є напівадитивними. Напівадитивна змінна — це
показник, який агрегується лише за певними вимірами. Тобто на-
півадитивну змінну можна коректно підсумовувати по одних ви-
мірах, але не можна — по інших. Наприклад, складські запаси
доцільно підсумовувати по продуктах або по регіонах, але не за
часом. Напівадитивні факти не можна підсумовувати по всіх ви-
мірах, але їх можна оцінювати іншим способом. Наприклад, ви-
значити середню величину складських запасів, зміни якої дореч-
но аналізувати в часі, або максимальний і мінімальний рівні
запасів і деякі інші статистичні показники.
І нарешті, неадитивні змінні. Це змінні, які неможливо підсу-
мовувати по жодному виміру. Приклад числової неадитивної
змінної — табельний номер співробітника. Неадитивні змінні не
можна підсумовувати, але їх можна полічити, тому вони вимірні.
Неадитивні змінні частіше групуються з вимірами.
Кожна змінна повинна мати свою семантичну інтерпретацію у
відповідних бізнес-термінах. По кожній змінній необхідно визна-
чити та ідентифікувати джерело даних, проте не по кожній змін-
ній можна однозначно вказати єдине джерело даних. Іноді змінні
отримуються розрахунковим шляхом на основі обчислень за
якимись формулами. У такому разі необхідно описати цю фор-
мулу та вказати, які дані і звідки потрібно взяти для проведення
необхідних обчислень.
По кожній змінній необхідно описати її використання в аналізі
даних. Змінні при аналізі можуть брати участь в обчисленнях, які
бувають простими або складними. Так, запит «Показати список
значень певної змінної для вибраних фактів», є простим, запит
«Визначити чистий прибуток від реалізації продукції» — склад-
ним. В останньому змінну чистий прибуток необхідно обчислю-
вати за певною формулою. По кожному обчисленні потрібно ма-
ти формулу та провести аналіз, який має визначити, чи включає
модель усі елементи даних, необхідних для обчислення.

289
 10.5.2. Визначення ступеня деталізації змінних

Визначення ступеня деталізації змінних є наступним

кроком проектування. Зерно (grain) — нижчий рівень деталізації
даних, що зберігаються в сховищі.
Змінні пов’язані з вимірами. Ступінь деталізації змінної ви-
значається комбінацією її вимірів та розглядається на рівні фак-
тів. Необхідно завжди перевірити відповідність змінної ключо-
вим вимірам фактів. У разі невідповідності змінних ключовим
вимірам фактів можна прийняти рішення про включення змінної
до іншого факту чи змінити ступінь її деталізації.
Змінні можуть підсумовуватися по різних рівнях відповідно до
ієрархії вимірів: щоденний продаж — по тижнях, місяцях або ро-
ках; продані товари — по кожному товару окремо, за категоріями
чи товарними групами. Іноді застосовують кілька ієрархічних сис-
тем. Магазини можна групувати по поштових регіонах з однако-
вими тарифами на пересилку або по територіях з аналогічною
структурою продажу для проведення маркетингових досліджень.
Користувачі можуть працювати з даними різного рівня деталі-
зації. Питання полягає в тому, яка ступінь деталізації потрібна
користувачеві? Завжди існує вірогідність того, що якийсь корис-
тувач у своєму пошуку побажає дійти до базової трансакції. На
основі цього можна дійти висновку, що при проектуванні необ-
хідно враховувати можливість забезпечити найнижчий рівень де-
талізування. Але звичайно при цьому необхідно враховувати те,
що сховище призначене для проведення бізнес-аналізу, який по-
винен аналізувати тенденції, а не вивчати конкретні детальні фа-
кти. Проте ступінь деталізації даних, що зберігаються в сховищі
даних, насамперед визначається метою його створення. Так, ке-
рівництву роздрібного магазина, яке бажає відстежити зміни
складських запасів, немає потреби зберігати в сховищі даних дані
про кожну торговельну операцію; обсяги продажів можна підсу-
мовувати на рівні товарів. Але якщо необхідно проаналізувати
поведінку споживачів, то буде потрібна інформація про окремі
торговельні операції для того, щоб їх проаналізувати і вивчити
уподобання споживачів та їх споживчий кошик.
Визначення ступеня деталізації та агрегації даних — це дуже
важливий момент проектування, оскільки він впливає на розмір
фізичної моделі. Ступінь деталізації змінної визначає глибину, з
якою в подальшому користувачі зможуть виконувати аналіз.
Ступінь деталізації змінних впливає не лише на глибину аналі-

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

10.5.3. Визначення та вимоги до вимірів

Змінні вимагають вимірів для їх семантичної інтерпре-

тації. Як вже зазначалось, виміри — це описові, якісні атрибути,
які є ознаками-характеристиками показників сховища і виступа-
ють умовами вибірки у запитах або є заголовками рядів в аналі-
тичних звітах. Так, змінна, що характеризує середні запаси, вима-
гає наявність таких вимірів, як ВИРІБ, ВИРОБНИК і ЧАС. Тобто,
аналізуючи величину середніх запасів, аналітик повинен знати,
про який виріб та якого виробника йдеться, а також з яким пері-
одом пов’язане це значення. Таким чином, виміри є своєрідними
координатами змінних.
До вимірів належать групувальні і текстові дані, відносно ста-
тичні і переважно неадитивні.
Не завжди можна легко відрізнити змінну від виміру. Іноді до
вимірів можуть належати числові, адитивні атрибути, наприклад,
час. А іноді статичний і неадитивний атрибут доцільно розмісти-
ти в таблиці фактів. Усе залежить від призначення конкретного
сховища даних. Наприклад, стать співробітника — це текстовий,
статичний і неадитивний елемент. Але якщо проектується схо-
вище, присвячене аналізу трудових ресурсів, та аналітики часто
задають запитання типу «Яке співвідношення між числом спів-
робітників чоловічої і жіночої статі, що займають керівні поса-
ди?». Тоді ознаку статі краще визначати не як вимір, а як змінну.
Виміри поділяються на стандартні і часові.
Стандартні виміри — це виміри, які не залежать від часу
(календарного періоду). Часові виміри — це виміри, які є
залежними від часу (календарного періоду).

291
 У межах одного виміру може бути певна ієрархія. Наприклад,
для виміру «Географія» типовою ієрархією буде: Континенти,
Країни, Регіони, Міста. Кожен рівень містить певну сукупність
складових елементів. Наприклад, «Країна»= {Україна, Росія,
США і т. д.}, «Місто» = {Київ, Одеса, Львів, Суми і т. д.}. Члени
певного виміру пов’язані між собою родо-видовими, стосунками
спадковості (батько-нащадок). Наприклад, міста Київ, Одеса,
Львів, Суми виступають нащадками стосовно України. Один і
той самий елемент виміру може в одному випадку виступати як
нащадок, а в іншому — як батько. По одному і тому ж виміру до-
пускається наявність кількох ієрархій. Наприклад, для виміру
«Час» такими ієрархіями можуть бути: рік, тиждень, день і рік,
квартал, місяць, день.
Відображення ієрархії вимірів уявляється деревоподібним
графом, який має певну кількість підпорядкованих вузлів вершин
і дуг. Вузли дерева — це виміри, а дуги — зв’язки між ними. Іє-
рархія вимірів може бути збалансованою та незбалансованою.
Збалансована (balanced) ієрархія вимірів має однакову висоту
по кожній гілці дерева, а кожний підпорядкований вузол має ли-
ше одного батька. Прикладом збалансованої ієрархії вимірів мо-
же бути відношення між календарними періодами. На рис. 10.6
наведено приклад виміру підрозділ корпорації, що має збалансо-
вану структуру.
Назвакорпорації
Назва корпорації

Обласне регіональне Обласне регіональне … Обласне регіональне

відділення № 1 відділення № 2 відділення № n

Районна філія № 1 Районна філія № 1 Районна філія № 1

Районна філія № 2 Районна філія № 2 Районна філія № 2

… … …
Районна філія № n Районна філія № n Районна філія № n

Рис. 10.6. Збалансована ієрархія

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

292
 Є ще також різновид ієрархії, проміжний між збалансованою
та збалансованою ієрархією, яку називають «нерівною» (ragged).
«Нерівна» ієрархія характерна тим, що не всі її нащадки мають
своїх батьків на рівні, який безпосередньо є вищим. Напри-
клад, адміністративно-територіальний поділ у різних країнах
здійснюється за різними правилами: в деяких країнах є поділ
на регіони, штати, округи, а в деяких досить вказати назву на-
селеного пункту, а відомості про штат чи регіон будуть відсутні
(рис. 10.7).
Адміністративно-територіальний
Адміністративно-територіаль поділ
ний поділ

Країна Країна Країна

Штат 1 … Штат n Область Місто 1

…
Місто 1 Місто 1 Район … Район Місто n
… …
Місто n Місто n Місто 1 Місто 1
… …
Місто n Місто n

Рис. 10.7. «Нерівна» ієрархія

При проектуванні сховищ даних слід враховувати, що не всі

інструментальні засоби підтримують незбалансовані і «нерівні»
ієрархії вимірів.
Ієрархія в межах одного виміру може бути постійною або
змінною. При проектуванні сховищ даних необхідно обов’язково
вказувати таку характеристику виміру, як можливість виникнення
змін. Зміни можуть бути двох видів: структурні чи зміни окремих
значень у межах існуючої ієрархії. Зміни структурного характеру —
це коли змінюється кількість рівнів ієрархії, тобто виникають нові
рівні чи вилучаються існуючі. Розглянемо приклад зміни значень у
межах існуючої ієрархії. Наприклад, у вимірі Регіон (область, ра-
йон, населений пункт) окремі населені пункти можуть змінити
свою ієрархічну підпорядкованість внаслідок внесення змін у сис-
тему адміністративного підпорядкування. Врахування та фіксація
змін в ієрархії вимірів із зазначенням їх хронології значно усклад-
293
нює процедуру проектування сховища та висуває певні вимоги до
характеристик інструментальних засобів аналізу.
Основними операціями по вимірах є операції занурення (drill-
down) — рух вниз і перехід в ієрархії до більш детальних рівнів і
згортання (rollup) — навпаки, рух нагору по рівнях ієрархії для
отримання узагальнених даних.

10.5.4. Визначення та вимоги до фактів

Змінні разом з усіма своїми вимірами створюють фак-

ти. Факт може складатися з однієї чи кількох змінних і кількох
вимірів. Семантична інтерпретація фактів нерозривно пов’язана з
бізнесом. Залежно від особливостей бізнес-події факти можуть
мати такі характеристики.
1. Факт може представляти сукупність даних, що характери-
зують бізнес-трансакцію або бізнес-подію. Наприклад, факт «Про-
даж» характеризує, що було продано, де, коли, кому, за якою ці-
ною і т. п.
2. Факт може характеризувати стан якогось об’єкта бізнесу.
Наприклад, факт «Залишки» може представляти дані про наявну
кількість певного товару станом на кінець дня чи місяця за пев-
ним складом.
3. Факт може представляти зміни у стані об’єкта бізнесу. На-
приклад, той же факт «Запаси» можна розглядати в іншому кон-
тексті, якщо представляти наявну кількість певного товару як ди-
намічну величину, що змінюється після виконання кожної бізнес-
трансакції, котра характеризує надходження та видатки товарів
по складу.
Тому при ідентифікації фактів необхідно виконувати такі ви-
моги:
 кожен факт повинен характеризувати якусь бізнес-подію,
тобто мати реальний еквівалент у предметній області;
 кожен факт повинен бути ідентифікованим його еквівален-
том, що існує в реальній дійсності;
 кожен факт повинен представляти інтерес для бізнес-
аналітика;
 ступінь деталізації основних вимірів кожного факту повинна
бути настільки детальною, наскільки це можливо і потрібно для
бізнес-аналізу.
Кожен факт ідентифікується системою ключів. Ключі можуть
бути згенеровані системою або складатися з ключів, що характе-

294
ризують його виміри. Ключі, що генеруються системою, іноді на-
зиваються сурогатними ключами. Існує кілька підходів до ство-
рення таких ключів.
 Новий ключ генерується системою і складається з ключа си-
стеми та ключа джерела. Цей підхід виключає можливість збігу
ключів різних джерел, а також дає можливість відстежити, з яких
джерел дані надійшли в сховище. Створення таким способом
ключів сховища не вирішує проблеми унікальності при повтор-
ному використанні ключів з оперативних систем.
 Новий ключ генерується системою і складається з ключа си-
стеми, ключа джерела та мітки календарного періоду заванта-
ження даних у сховище даних. Цей підхід дозволяє створити дій-
сно унікальний ключ за рахунок фіксації періоду завантаження
даних, але довжина ключа при цьому може бути досить значною,
що вплине на швидкість виконання запитів при об’єднанні різних
таблиць за ключовими полями.
 Новий ключ генерується системою за допомогою спеціаль-
ного алгоритму. Перевага такого підходу до створення ключів
полягає в тому, що ключ можна зробити мінімальним за довжи-
ною, що зекономить пам’ять. Але такі ключі потребують спеціа-
льної інтерпретації, тобто встановлення відповідності між клю-
чами систем-джерел та ключами сховища даних.
Слід зауважити, що ключі, які генеруються системою, можуть
створити додаткові труднощі при завантаженні даних до сховища
даних. Ключі у сховищі ніколи не повинні змінюватись. Вибір
конкретного способу створення ключа залежить від кількості си-
стем-джерел і від вимог щодо продуктивності сховища. Тобто
конкретний спосіб створення ключів визначається проектуваль-
никами сховища даних.
При проектуванні слід враховувати, що факти найчастіше бу-
вають такими.
1. Факти, основані на окремих подіях, що відображають ре-
зультати виконання певних трансакцій (Transaсtion facts). Напри-
клад, отримання грошей з рахунку банку за допомогою банкомата.
2. Факти, що відображають стан об’єкта на певний момент
часу, які є його «моментальним фото» (Snapshot facts). Типовим
прикладом такого факту можуть бути залишки на рахунках банку
станом на кінець дня чи місяця.
3. Сукупні «моментальні фото» (Cumulative snapshot) відо-
бражають інформацію про діяльність організації за певний про-
міжок часу. Наприклад, сукупний обсяг продажу на поточну да-
ту, включаючи попередні місяці.

295
 4. Факти, що відображають дані певного документа (Line-
item facts) — це факти, які ґрунтуються на даних певного доку-
мента. Наприклад, факти такого документа, як кредитний дого-
вір, містить детальну інформацію цього документа: номер дого-
вору, вид кредиту, код клієнта, валюту, дата початку дії
договору, дата закінчення дії договору, сума кредиту та ін.
5. Факти, що фіксують події чи стан об’єкта (Event or state
facts). Ці факти лише фіксують певну подію чи певний стан об’єктів
без жодних коментарів і подробиць. Наприклад, факт погашення
кредиту чи факт непогашення кредиту без жодних коментарів.
Відмінність факту, що представляє певну бізнес-подію, від
факту, що являє собою якийсь випадок або фіксує стан якогось
об’єкта, є дещо незрозумілою, тому дамо пояснення на конкрет-
ному прикладі. Факт ПРОДАЖ є результат певної бізнес-
трансакції і для її аналізу потрібні виміри, що її характеризують.
Аналіз змін показників факту ПРОДАЖ актуальний досить дов-
гий період, оскільки можна виконувати динамічний аналіз змін
обсягів продажів за останній рік або використовувати їх для про-
гнозування майбутніх продажів і т.д. Прикладом факту, що пред-
ставляє стан об’єкта, є ЗАЛИШОК. Показники, що характеризу-
ють залишки, є актуальними лише на поточний конкретний
момент часу. Наприклад, при аналізі забезпеченості виробництва
виробами менеджеру потрібні фактичні дані про стан залишків на
поточний момент. Його не будуть цікавити дані про стан залишків
за попередній місяць. Тому тривалість зберігання даних у сховищі
даних залежить від того, які факти вони характеризують. Якщо це
факти типу Event or state facts, то вони можуть зберігатись не дуже
довго і весь час повинні оновлюватися новими даними. Напри-
клад, інформація про стан залишків має поновлюватися щоденно.
Якщо це факти, що входять до 1—3 груп, то вони можуть зберіга-
тися досить довго у сховищі, утворюючи так звані історичні плас-
ти.

10.6. Вимірне моделювання сховищ даних

Методика вимірного моделювання більш докладно викладена

в роботі [60]. Для визначення даних, які необхідно зберігати в
сховищі даних, передусім необхідно провести збір вимог кінце-
вих користувачів. Вимоги до сховища даних кінцевих користува-

296
чів можна умовно розбити на дві групи: вимоги, орієнтовані на
процес, та інформаційно орієнтовані вимоги.
Вимоги, орієнтовані на процес, пов’язані з процесами обробки
даних при виконанні бізнес-аналізу. При вивченні цих вимог
з’ясовуються основні види перетворень, групувань та обчислень, які
необхідно виконувати з даними при обчисленні агрегованих даних.
Інформаційно орієнтовані вимоги дозволяють визначитись з
основними запити та основними бізнес-цілями побудови сховища
даних. Аналіз цієї групи вимог дає змогу встановити одну або кіль-
ка цілей створення сховища, а також ідентифікувати основні біз-
нес-події та показники, які будуть аналізуватися кінцевим корис-
тувачем. Наприклад, бізнес-цілі можуть визначатися таким чином:
«Метою створення сховища даних є аналіз витрат на ВИ-
ПУСК ПРОДУКЦІЇ та доходу від її ЗБУТУ СПОЖИВАЧАМ».
Отже, основними бізнес-подіями, що аналізуватимуться у
сховищі, виступають випуск продукції та її збут, які будуть пред-
ставлені в сховищі даних показниками виробничі витрати і дохід
від збуту з вимірами продукція і споживач.
Вивчивши вимоги до сховища даних кінцевих користувачів,
необхідно сформулювати основні бізнес-запити до сховища, що
проектується. Бізнес-запити являють собою інформаційні потре-
би кінцевих користувачів в аналітичній інформації. При опиту-
ванні користувачів необхідно визначити основні типи запитів.
Найпоширенішими є такі:
 запити перевірки, результат виконання яких підтверджує
якусь бізнес-подію. Наприклад, з’ясування факту надходження
коштів від певного споживача за певний товар;
 запити порівняльного аналізу, результат виконання яких по-
рівнює дані про якісь факти. Наприклад, порівняння даних про
збут певного виду продукції за останній місяць з даними попере-
днього місяця;
 запити тенденції, результати виконання яких аналізують та
виявляють тенденції у зміні певних фактів у часі. Наприклад, як
змінювався дохід від реалізації певного виду продукції за останні
12 місяців;
 запити для аналізу відношень, ранжування та кластериза-
ції, результати виконання яких дозволяє певним чином класифі-
кувати та ранжувати дані про певні бізнес-події. Наприклад, ран-
жування кращих споживачів продукції за обсягами продажів
протягом останнього року;
 запити статистичного аналізу дозволяють провести стати-
стичний аналіз фактів, що характеризують певні бізнес-події. На-

297
приклад, обчислення середнього (мінімального, максимального)
доходу від реалізації продукції по певному регіону.
При формулюванні запиту необхідно описувати його так, щоб
можна було визначити основні змінні, які підлягають аналізу та
виміри, за якими будуть формуватися аналітичні звіти.
З’ясувавши всі запити користувачів до сховища даних, необхідно
побудувати таблицю взаємозв’язків вимірів та змінних із запита-
ми.
Розглянемо це на конкретному прикладі. Нехай дослідження
предметної області та опитування користувачів дозволило вияви-
ти такі запити до сховища даних:
1. Проаналізувати середні залишки кожної моделі Виробу в
розрізі Виробників за даний місяць.
2. Проаналізувати підсумкові витрати та дохід на поточну
дату від реалізації кожної моделі Виробу в розрізі Магазинів.
3. Надати підсумкові дані на поточну дату про витрати та
дохід, отриманий від реалізації кожної моделі Виробу в розрізі
Регіонів і Виробників.
4. Проаналізувати за останній тиждень (місяць) у розрізі Ма-
газинів відсотки товарів, на які можна встановити знижку та тих
по яких фактично було проведено уцінку.
5. Проаналізувати відсотки продажів за минулий місяць по
кожній моделі Виробу через оптову, роздрібну торгівлю та через
столи замовлень.
6. Які Моделі та Вироби не були продані минулого тижня (мі-
сяця)?
7. Проранжувати моделі Виробів, які були продані минулого
місяці за обсягами продажів, витратами та отриманим доходом.
8. Які Магазини не мали жодних продажів певної моделі Ви-
робу за минулий місяць?
9. По кожній з моделей Виробів виявити ті Магазини, в яких
не було продажів за минулий місяць.
Первинний аналіз запитів дозволив виокремити певну сукуп-
ність вимірів та змінних і згрупувати їх в табл. 10.1.
Таблиця 10.1
ТАБЛИЦЯ СПІВВІДНОШЕНЬ ВИМІРІВ І ПОКАЗНИКІВ

Номер запиту
Виміри та змінні
1 2 3 4 5 6 7 8 9
Виміри

298
 Магазини + + + +
Виробники + +
Вироби + + + + + + + +
Закінчення табл. 10.1
Номер запиту
Виміри та змінні
1 2 3 4 5 6 7 8 9
Змінні
Середні залишки +
Витрати + + +
Дохід + + +
Кількість продано +
Відсоток товарів, що мають +
право на знижки
Відсоток товарів, по яких бу- +
ло проведено знижки
Відсоток роздрібних продажів +
Відсоток продажів через стіл +
замовлень
Відсоток оптових продажів +

Більш детальний аналіз семантики запитів вказує на необхід-

ність введення ще такого виміру, як Час. При введенні в модель
сховища виміру часу необхідно визначитись зі ступенем його де-
талізації. З аналізу запитів можна визначити одиниці часу, які не-
обхідні для аналізу, та ієрархію між ними. В даному конкретному
випадку це такі одиниці як день, тиждень, місяць.
Вивчення та аналіз таблиці дозволяє виокремити початковий
набір фактів, які необхідно відображати в сховищі даних. Почат-
ковий набір фактів визначається, а за таким правилом: Змінні, що
описуються однаковими наборами вимірів, можна об’єднати в
один факт. Тобто виокремлення фактів здійснюється шляхом
перегляду таблиці і виявлення однакових вимірів. Виявивши од-
накові набори виміри до них приєднуються відповідні їм змінні.
Результат виокремлення фактів на основі такого аналізу даних
таблиці наведено на рис. 10.8.
Необхідно звернути увагу, що деякі запити (запит 6, 8, 9) не
мають жодної змінної, які були з ними пов’язані. Якби ці запити
не були включені з іншими запитами, що мають змінні до відпо-

299
відних фактів, то вони б створили факти, що не мають змінних.
Факти, що не мають змінних, називаються недостатніми, або
неповними. Вони фіксують лише факт певної події, не описуючи
її конкретними даними.
Після виокремлення фактів необхідно провести уточнення
структури початкових фактів шляхом оцінки адитивності змін-
них та визначення ступеня деталізації вимірів. Аналізуючи
факт1, можна виявити таку проблему деталізації. Середні залиш-
ки є величиною, яка визначається щомісячно (див. запит 1), дохід
та витрати (див. запит 3) — щоденними характеристиками. Тобто
зберігати в такому вигляді факт неможливо. У такому разі є дві
альтернативи: розбити факт 1 на два факти чи деталізувати вимір
часу до найнижчого його рівня, яким буде календарна дата, тобто
день. Оскільки середня кількість за місяць є величиною неадити-
вною, то краще зберігати в факті 1 адитивну змінну, що характе-
ризує фактичну величину наявності виробів за кожен день. При
реалізації запиту 1 середні залишки за місяць будуть розрахову-
ватись на основі фактичних даних про наявність виробів на кож-
ну дату.
Факт 1 Факт 2

Код виробника Кодмагазину

Код магазину
Код виробу Кодвиробу
Код вибору
Код часу Кодчасу
Код часу
Середні залишки Витрати
Витрати
Витрати Дохід
Дохід
Дохід

Факт 3 Факт 4
код виробу
Код вибору
Кодчасу
Код часу
Витрати
Витрати Кодма
Код магазину
газина
Дохід
Дохід Кодча
Код часу
су
Кількістьпродано
Кількість продано Відсоток
Відсот окмоделей,
моделей,що
щомають
мають
Відсотокроздрібних
Відсоток роздрібних правона
право назнижки
знижки
продажів
продажів Відсоток
Відсот окмоделей,
моделей,що
щобули
були
Відсотокпродажів
Відсоток продажівчерез
через продані
продан і зізізнижкою
знижкою
стілзамовлень
стіл замовлень
Відсотокоптових
Відсоток оптовихпродажів
продажів

Рис. 10.8. Набір початкових фактів

Факт 2 теж має проблеми з виміром часу. Запит 2 стосується

аналізу за конкретну дату, тобто день, а запити 8 і 9 потребують
даних за місяць. Тобто факт 2 об’єднує дані, не сумісні за вимі-
300
ром часу. Проте змінні, що входять до цього факту, є повністю
адитивні, тому коригування факту 2 полягатиме лише в тому,
що найменшою одиницею часу для нього буде конкретна дата,
тобто день.
У фактах 3 і 4 теж об’єднані запити з різними вимірами часу—
тиждень і місяць. Крім того, факти 3 і 4 мають змінні відсотків,
які є неадитивними, тобто неможливо змінити ступінь деталізації
часу, оскільки відсотки не підсумовуються. Таким чином, пер-
шим рішенням, що лежить на поверхні, є представлення замість
одного факту кількох, кожен з яких окремо характеризує дані за
тиждень і за місяць. Але це призведе не лише до збільшення кі-
лькості фактів, а й до ускладнення моделі, що зробить її заплута-
нішою для аналітиків. Тому краще визначити за найнижчий сту-
пінь деталізації часу день, а дані відсотків замінити фактичними
даними. Таким чином, у факті 3 змінні «Відсоток роздрібних
продажів», «Відсоток продажів через стіл замовлень» і «Відсоток
оптових продажів» будуть замінені на «Кількість моделей, про-
даних у роздріб», «Кількість моделей, проданих через стіл замов-
лень»; «Кількість моделей, проданих оптом». Враховуючи, що в
цьому факті є змінна, яка характеризує загальні обсяги продажів
по кожній моделі виробу, то змінні, котрі замінять відсотки, до-
зволять при потребі її розрахувати.
Аналогічно у факті 4 відсотки замінимо відповідно на «Кіль-
кість моделей, що мають право на знижку» та «Кількість моде-
лей, що були продані зі знижкою».
Набір фактів після визначення ступеня деталізації вимірів та
перевірки на адитивність змінних представлено на рис. 10.9.

301
 Факт 1 Факт 2
Кодвиробника
Код виробника Код магазину
Кодвиробу
Код вибору Код магазину
Кодчасу
часу(день) Код
Код вибору
виробу
Код Код
Код часу
часу (день)
Середні залишки
Залишки за день Витрати
Витрати
Витрати Витрати
Дохід Дохід
Дохід
Дохід
Факт 3 Факт 4
Код
код виробу
вибору
Код
Кодчасу
часу(день)
Витрати
Витрати Кодма
Код магазину
газина
Дохід
Дохід Кодча
Код часу
су(день)
Кількість
Кількістьпродано
продано Відсотсть
Кількі ок моделей,
моделей, що
що мають
мають
Кількість
Відсоток роздрібних
роздрібних правона
право назнижки
знижки
продажів Відсотсть
Кількі ок моделей,
моделей, що
що були
були
продажів продані
Кількість
Відсоток продажів
продажів через
через продан і зізізнижкою
знижкою
стіл
стілзамовлень
замовлень
Кількість
Відсоток оптових
оптових продажів
продажів

Рис. 10.9. Уточнений набір фактів після вирішення проблем деталізації

та адитивності

Вирішення проблеми зі ступенем деталізації вимірів та адити-

вністю змінних дає змогу розглянути питання можливості
об’єднання фактів, що розширює діапазон досліджень, оскільки,
як правило, призводить до збільшення кількості вимірів.
Об’єднання фактів надає такі переваги: за рахунок зменшення
кількості фактів спрощується модель; розширюються можливості
аналізу за рахунок зв’язування більшої кількості змінних і вимірів
на вищому рівні деталізації; спрощується адміністрування схови-
ща та робота з ним користувачів-аналітиків, оскільки для адмініс-
трування та реалізації запитів потрібно переглядати менше фактів.
Першим кроком оцінки перспектив об’єднання фактів є ви-
значення по кожній змінній можливостей підключення нових ви-
мірів для підвищення її інформативності та ступеня деталізації.
Об’єднувати можна факти, що містять спільні виміри. Виміри
факту 2 (код магазину та код виробу) представлені у фактах 1, 3 і
4. Об’єднати факт 1 і 2 неможливо і недоцільно, оскільки факт 1
містить дані про залишки виробів у розрізі кожного виробника, а
факт 2 — дані про продаж виробів у розрізі Магазину, а Вироб-
ник: Магазин = Б : Б.
Дослідимо можливість об’єднання фактів 2 і 3, оскільки вони
містять семантично споріднену інформацію, що характеризують
витрати і дохід та обсяги продажів по виробах. Об’єднання цих
фактів можливе шляхом включення виміру, що характеризує ма-
302
газин до факту 3. Таким чином, у результаті об’єднання отрима-
ємо факт, представлений на рис. 10.10. Цьому факту присвоюємо
номер 2 і проаналізуємо його на можливість об’єднання з фактом
4. Змінні «Кількість моделей, що мають право на знижки» та «Кі-
лькість моделей, що були продані зі знижкою» доречніше вказу-
вати в розрізі кожного виробу. Причому досить залишити лише
першу змінну, підключивши її у факт, що утворився внаслідок
об’єднання фактів 2 і 3.
Факт 2
Код магазину
Код виробу
Код часу (день)
Витрати
Дохід
Кількість продано
Кількість роздрібних продажів
Кількість продажів через стіл замовлень
Кількість оптових продажів
Кількість моделей, що мають право на знижку

Рис. 10.10. Результат об’єднання фактів 2 і 3

Змінну «Кількість моделей, що були продані зі знижкою» мож-

на не враховувати, оскільки є змінні, які характеризують обсяги
продажів, котрі у разі необхідності дозволять розрахувати кіль-
кість моделей, проданих зі знижками. Результат об’єднання фак-
тів 2, 3, і 4 наведено на рис.10.11.
Факт 2

Код магазину
Код виробу
Код часу (день)
Витрати
Дохід
Кількість продано
Кількість роздрібних продажів
Кількість продажів через стіл
замовлень

Рис. 10.11. Результат об’єднання фактів 2, 3 і 4

Таким чином після виконання процедури об’єднання фактів

на завершальному етапі маємо два факти: факт 1 та факт, який ді-
303
стали в результаті об’єднання фактів 2, 3 і 4. Назвемо відповідно
ці факти «Виробництво» і «Продажі» (структури цих фактів на-
ведені на рис. 10.12).
Виробництво Продажі

Код магазину
Код виробу
Код виробника Код часу (день)
Код виробу Витрати
Код часу (день) Дохід
Залишки за день Кількість продано
Витрати Кількість роздрібних продажів
Дохід Кількість продажів через стіл
замовлень
Кількість оптових продажів

Рис. 10.12. Кінцевий набір фактів

Спроектувавши та підключивши до цих фактів таблиці вимі-

рів, отримаємо такі дві моделі (рис. 10.13 і 10.14).
Виробник

Код виробника
Назва регіону
Виробництво Назва виробника
Календар Адреса

Код виробника
Код часу (день) Код виробу
Тиждень Код часу (день) Вибір
Місяць Залишки за день
Витрати
Дохід
Код виробу
Модель
Собівартість
Оптова ціна

Рис. 10.13. Модель «Виробництво»

304
 Продавець
Виробник

Продажі Код магазину

Код виробника Торгівельна площа
Торговельна площа
Назва регіону Назва регіону
Назва виробника Код магазину Тип виду збуту
Адре с а Код виробу Назва виду збуту
Код виробника
Код часу (день)
Витрати
Дохід
Кількість продано
Кількість роздрібних Вибір
Календар продажів
Кількість продажів через
Код часу (день) стіл замовлень Код виробу
Тиждень Модель
Місяць Собівартість
Оптова ціна

Рис. 10.14. Модель «Продажі»

Узагальнюючи описану вище методику вимірного моделю-

вання сховищ даних можна подати у вигляді наступної послідов-
ності робіт (рис. 10.15).

305
 Визначення цілей побудови сховища даних

Визначення вимог користувачів та

формулювання бізнес-запитів

Побудова таблиці взаємозв’язку змінних та вимірів

Виявлення запитів, що описуються однаковими вимірами,

і формування початкового набору фактів

Аналіз змінних Аналіз ступеня Аналіз сумісності фактів

на адитивність деталізації фактів за часовими вимірами

Уточнення структур початкового набору фактів

Дослідження фактів на можливість їх об’єднання

Формування кінцевого набору фактів

Проектування таблиць вимірювань

Об’єднання фактів і таблиць вимірювань

у вимірну модель сховища даних

Рис. 10.15. Схема послідовності робіт при вимірному моделюванні схо-

вищ даних

10.7. Визначення метаданих при проектуванні

сховищ даних

Метадані (metadata) є обов’язковою і дуже важливою

компонентою сховищ даних. Вони містять інформацію про дані,
що зберігаються у сховищі, а самі зберігаються в репозитарії. Це
своєрідний словник даних, який включає задокументовану повну
довідкову інформацію про дані і дозволяє користувачам глибше
зрозуміти основні бізнес-поняття та їх джерела. У трансакційних
306
базах даних метаданими переважно користуються лише адмініс-
тратори баз даних. Метадані сховища даних потрібні не лише
адміністратору та персоналу, що його обслуговує. Насамперед з
метаданими працюють користувачі, тобто бізнес-аналітики. Пра-
цюючи зі сховищем, бізнес-аналітики за рахунок метаданих ви-
значають спосіб обчислення тих чи інших показників, джерела їх
надходження, частоту поновлення і т. п. Інформація про всі дані,
що потрапляють чи вилучаються зі сховища, в першу чергу фік-
сується в репозитарії метаданих.
Метадані повинні дати відповідь користувачам на наcтупні
шість запитань: навіщо?, як?, де?, хто?, коли?, що? Виходячи з
цього, вони повинні мати шість таких характеристик [46]:
 мотивації (мета) створення та розвитку сховища даних (на-
віщо?);
 дії, які виконуються з даними при їх завантаженні (як?);
 місце розташування даних (де?);
 користувачі, які використовують сховище даних (хто?);
 моменти завантаження та обчислення підсумкових даних
(коли?);
 сутності або наповнення сховища даних (що?).
Мотивації (мета) створення та розвитку сховища даних. На-
самперед по кожній моделі необхідно визначитись з метою її ство-
рення та ім’ям. Мета — це лаконічний опис мотивації, тобто цілі
створення сховища даних. При формулюванні мети треба визначи-
ти, яку предметну область (чи її підмножину) характеризує модель,
та ціль бізнес-аналізу, який буде виконуватись з її допомогою. Опи-
суючи на цьому етапі метадані, що вміщують загальну характерис-
тику моделі, необхідно вказати відповідальних осіб, які у разі по-
треби можуть надати ґрунтовнішу інформацію про модель сховища.
Дії, які виконуються з даними при їх завантаженні. У метада-
них описують перетворення, які необхідно виконати над даними,
перш ніж завантажити їх у сховище даних. Дані, що необхідні
для сховища, можуть зберігатись у різних інформаційних систе-
мах-джерелах, внаслідок чого вони можуть бути по-різному за-
кодованими та ідентифікованими. При приведенні до єдиної схе-
ми ідентифікації та кодування виконуються певні перетворення,
які необхідно описати в репозитарії метаданих.
Місце розташування даних. Метадані зберігають інформацію
про розміщення систем-джерел, які є ресурсами сховища даних,
тобто відомості про розташування серверів і робочих станцій.
Користувачі, які використовують сховище даних. На різних
етапах життєвого циклу зі сховищем даних працюють дуже багато

307
різних спеціалістів, які виконують різні ролі. До основних фахівців,
що задіяні на етапі створення та експлуатації сховищ, належать такі
категорії: архітектори (проектувальники) сховища даних, менедже-
ри проектів, адміністратори баз даних, програмісти, бізнес-
аналітики та інші фахівці. Усі категорії персоналу, що задіяні та
працюють зі сховищем, повинні бути описані у метаданих, а ролі,
які вони виконують, задокументовані. Крім того, у метаданих пови-
нні бути відображені групи та права доступу користувачів до даних,
а також інші додаткові характеристики, що забезпечують безпеку
функціонування сховища даних. Усі користувачі, що працюють зі
сховищем, повинні бути розбиті адміністратором на групи з певни-
ми правами доступу. Користувач, що входить до певної групи, має
всі права доступу цієї групи. Це дозволяє спрощувати процедуру
адміністрування, змінюючи права доступу до даних групи користу-
вачів. Адміністратор має змогу відразу змінити їх у всіх членів цієї
групи.
Моменти завантаження та обчислення підсумкових даних.
Сховище даних відображає хронологічну послідовність бізнес-
подій, які представляють інтерес для бізнес-аналізу. Для того,
щоб дані сховища були завжди актуальними, необхідно чітко ви-
значитись з періодами поповнення сховища новими даними. Тоб-
то необхідно чітко визначити та задокументувати в метаданих
календарні і часові періоди завантаження нових даних до схови-
ща. Адміністратор сховища повинен відстежувати та своєчасно
завантажувати дані до сховища. Цього регламенту слід ретельно
дотримуватись, оскільки гіршим за відсутність даних у сховищі є
застарілі дані. Якщо дані своєчасно не актуалізовані, то слід за-
боронити доступ до них користувачів.
Завантаження даних дуже часто супроводжується їх оброб-
кою, яка полягає в узагальненні даних, тобто обчисленні певних
підсумкових даних. Тому обов’язково в метаданих повинні найти
відображення процедури агрегування даних.
Сутності або наповнення сховища даних. Ця складова репози-
тарію метаданих є найбільш важливою. Вона містить опис сутно-
стей предметної області, що знайшли відображення в сховищі.
Метадані групуються по кожній моделі предметної області та
описують всі її складові, тобто виміри, атрибути вимірів, факти і
змінні. Здійснюючи такий опис, насамперед усім переліченим
компонентам слід присвоїти імена і псевдоніми.
Псевдонім необхідний через те, що іноді важко дійти згоди
щодо визначення імені, оскільки різні користувачі по-різному на-
зивають одні і ті самі об’єкти предметної області, тобто один

308
об’єкт може мати кілька синонімічних імен. При описі моделі та
її вимірів і фактів необхідно вказати відповідальну особу для ко-
нтактів. Це потрібно для того, щоб користувач зміг у разі потреби
отримати додаткову, більш повну інформацію про модель схо-
вища даних та його складові. На рис. 10.16 наведено узагальнену
схему метаданих, що описує сутності сховища даних.
Назва
Модель Визначення
Мета
Виміри 1
Факти 2
1 Змінні 3
Особа для контактів
Вимір Назва
Визначення
Псевдонім
Ієрархія
Правила змін
Частота завантаження
Атрибути
Факти 2
Змінні 3
2 Особа для контактів

Факт Назва
Визначення
Псевдонім
Частота завантаження
Календарний період
Змінні 3
Виміри 1
2 Особа для контактів

Змінна Назва
Визначення
Псевдонім
Календарний період
Тип даних
Правила перетворення
Факт 2
Вимір 1

Джерело Назва
Визначення
Псевдонім
Календарний період
Тип даних
Правила змін
Предметна область
Правила перетворень

309
 Рис. 10.16. Узагальнена схема метаданих

Коротко охарактеризуємо метадані моделі та її складові, наве-

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

310
схему перетворення, за якою початкове значення в системі-джерелі
приводиться до нового значення у сховищі даних. Так, якщо у сис-
темі-джерелі для позначення статі використовувались літери: Ч —
чоловіча стать, Ж — жіноча стать, а у сховищі ці позначення відпо-
відно замінені на цифрові позначення: 1 — чоловіча стать, 2 — жі-
ноча стать, то інформація про це повинна відображатися у метада-
них. У деяких окремих випадках вибір даних для сховища може
виконуватись з різних джерел за деякими умовами. Тоді необхідно в
метадані про джерела включати алгоритм (логіку) їх вибору.
Логіка переходу від систем-джерел до сховища не завжди мо-
же виконуватись за один крок. Іноді такий перехід може вимага-
ти кілька кроків. Це може трапитися в таких випадках:
 системи-джерела, які необхідно об’єднувати, знаходяться у
різних місцях;
 не всі дані можна об’єднувати відразу, оскільки таблиці ви-
магають зовнішніх об’єднань;
 системи-джерела розміщені на різних платформах, які є тех-
нологічно несумісними між собою;
 необхідна наявність комплексу агрегування (узагальнення)
даних.
Важливим питанням інтеграції є синхронізація даних різних
типів, що використовуються в межах усього сховища даних.
Оскільки різні інструменти сховища даних створюють і викорис-
товують свої власні метадані, то для досягнення повної інтеграції
потрібно зробити так, щоб ці інструменти могли спільно викори-
стовуватись метаданими. Задача в такому разі полягає в синхро-
нізації метаданих між різними програмними продуктами різних
фірм виробників, які використовують різні сховища метаданих.
Наприклад, необхідно ідентифікувати потрібний елемент метада-
них на відповідному рівні деталізації одного програмного проду-
кту, а потім встановити його відповідність другому елементу ме-
таданих на відповідному рівні деталізації другого програмного
продукту, а також врегулювати будь-які відмінності в способі
кодування. Цю операцію необхідно виконати стосовно спільних
метаданих по всіх програмних продуктах. Більше того, будь-які
зміни метаданих одного програмного продукту необхідно пере-
давати в метадані іншого програмного продукту. Завдання син-
хронізації внесення змін метаданих по кількох програмних про-
дуктах складна і потребує надто великих витрат ресурсів. Вирішити
цю проблему можна двома способами:

311
  за допомогою механізму автоматичної передачі метаданих
між сховищами, що підтримуються різними інструментальними
засобами;
 шляхом створення репозитарію метаданих.
У 1995 році був створений комітет Metadata Coalition
Committee, який розробив специфікацію Metadata Interchange
Format (MIF), призначену для стандартизації процесу передачі
метаданих. Цей стандарт використовується фірмами-
розробниками для створення інструментів обміну метаданими.
Незважаючи на корисність цих продуктів, все ж краще користу-
ватись репозитарієм метаданих.
Репозитарій метаданих об’єднує різні типи метаданих в інтег-
рованому сховищі і може синхронізувати та реплікувати метада-
ні, розподілені по всьому сховищу даних. Репозитарій можна
розглядати як специфічне сховище для зберігання метаданих.
Прикладами репозитарія можуть бути такі продукти: PLATINUM
Repository фірми Platinum Technologies, ROCHADE Repository
фірми R & O, Directory Manager фірми Prisms Solution і Universal
Directory фірми Logic Works.

10.8. Автоматизація проектування сховищ даних

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

мо в середовищі CASE-засобу Erwin, який було детальніше роз-
глянуто в 5-му розділі.
ERwin підтримує методику вимірного (Deminsional) проекту-
вання сховищ даних. Базовою моделлю, яка є результатом вимір-
ного проектування сховища даних, є модель типу «зірка» та її рі-
зновид — «сніжинка». Вимірне проектування подібне до
проектування реляційних баз даних, але відрізняється акцентами
і цілями, які ставляться перед проектувальником. Якщо основ-
ною задачею проектування реляційних баз даних є забезпечення ці-
лісності і узгодженості даних при їх завантаженні, то основною
метою при проектуванні сховищ є мінімізація часу на виконання
складних аналітичних запитів.
Стандартом вимірного проектування сховищ даних є модель
типу «зірка», яка складається з центральної таблиці фактів та ра-
діально зв’язаних з нею таблиць вимірювань. Панель інструмен-
тів для моделювання сховищ наведена на рис. 10.17.

312
 Рис. 10.17. Панель інструментів для проектування сховищ даних

Таблиці фактів і вимірювань зв’язані ідентифікуючими

зв’язками, при цьому первинні ключі таблиць вимірювань мігру-
ють у таблицю фактів як зовнішні ключі. Тобто первинний ключ
таблиці фактів складається з первинних ключів усіх таблиць ви-
мірювань. У вимірній моделі напрямок зв’язку явно не зазначаєть-
ся, він визначається; типом таблиці.
Крім таблиць фактів та вимірювань, схема «зірка» може мати
також консольні таблиці (outrigger table), які приєднуються до
таблиці вимірювань. Консольні таблиці є батьківськими, а табли-
ці вимірювань — дочірніми. Консольна таблиця не може бути
зв’язана з таблицею фактів. Консольні таблиці використовуються
для нормалізації даних у таблицях вимірювань. Модель сховища,
в якій за рахунок введення консольних таблиць нормалізовані всі
таблиці вимірювань, називається «сніжинкою».
Якщо денормалізована таблиця вимірювань є надто великою і
при цьому до деяких її стовпчиків запити робляться частіше, ніж
до інших, то доцільно для підвищення ефективності виконання
запитів розбити цю таблицю на дві окремі таблиці вимірювань.
Дві нові таблиці, які будуть отримані внаслідок цієї операції,
зв’язуються неідентифікуючим зв’язком. Виконання такої опера-
ції зменшить час виконання запитів.
При проектуванні сховищ даних у середовищі ERwin викори-
стовуються такі позначення:
таблиця фактів (fact table);
таблиця вимірювань (dimensional table);
консольна таблиця (outrigger table).
Для переходу до вимірного моделювання сховища даних в
ERwin необхідно при створенні нової моделі (меню File/New) в
діалозі Teamplate Selection (рис. 10.18) зі списку шаблонів вибра-
ти шаблон DIMENSION.

313
 Рис. 10.18. Вибір методології моделювання сховища даних

Вибір цієї методології можна виконати через меню Option

Preferences (рис. 10.19), вибравши опцію DM (Dimensional
Modeing).

Рис. 10.19. Вікно вибору методології DM через меню Option Preferences

Ця опція надає всі необхідні можливості для підтримки вимі-

рного моделювання, хоча звичайну діаграму ERwin можна вруч-
ну перетворити на вимірну модель сховища даних.

314
 Для занесення нової таблиці в модель можна використати
кнопку в меню інструментів. Для визначення імені таблиці
необхідно клацнути правою кнопкою мишки по створеній поро-
жній таблиці і в меню, що з’явиться, вибрати опцію TABLE
EDITOR. Ця опція відкриває діалогове вікно (рис. 10.20), в яко-
му ідентифікується таблиця та визначаються її властивості.
Специфічні властивості таблиць вимірної моделі задаються
шляхом активізації закладинки Dimensional. Для кожної таб-
лиці можна задати шість правил маніпулювання даними: онов-
лення (Refresh), поповнення (Append), резервне копіювання
(Backup), відновлення (Recovery), архівування (Archiving) та
очистка (Purge).

Рис. 10.20. Вікно для ідентифікації таблиці

Для кожного з правил можна задати ім’я, тип, визначення. Так,
визначення для операції резервного копіювання може включати ча-
стоту в час його виконання. Зв’язок правила з певною таблицею
можна виконати за допомогою діалогу Table Editor чи безпосеред-
ньо з Data Warehouse Rule Editor (закладинка Attachment). Вікно
для визначення правил по веденню таблиці наведено на рис. 10.21.

315
 Рис. 10.21. Вікно для визначення правил ведення таблиці

Атрибути таблиці вводяться в редакторі Column Editor

(рис.10.22), який викликається при натисненні правої кнопки
мишки на діаграмі майбутньої таблиці.

Рис. 10.22. Вікно для визначення стовпчиків та їх характеристик

На основі створених зв’язків ERwin автоматично, за замовчу-

ванням, визначає роль таблиці у сховищі даних (таблиця фактів,

316
вимірювань чи консольна). Для визначення ролі таблиці вручну
необхідно активізувати опцію Calculate Automatically.

Календар Продаж
Продукція
Код_періоду: DATE Код_продукції: NUMBER (FK)
Код_магазину: NUMBER (FK) Код_продукції: NUMBER
Число: DATE Код_періоду: DATE (FK)
Місяць: DATE Назва_прод.: СHAR (18)
Рік: СHAR (18) Дата: DATE Код_типу: NUMBER
Кількість: DECIMAL (.) Назва_типу.: СHAR (18)
Ціна: NUMBER

Магазин
Код_магазину: NUMBER
Назва_магазину.: СHAR (18)
Код_регіону: NUMBER
Телефон_факс.: СHAR (18)

Рис. 10.23. Модель типу «зірка»

На рис. 10.23 відображено модель сховища даних типу «зірка».

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

317
  перезаписування старих даних новими, при якому старі дані
знищуються;
 створення нового запису в таблиці вимірювань з новими да-
ними і тимчасовими вимірами. У такому разі старі дані зберіга-
ються і можливе відстеження історії внесення змін до даних, але
при цьому необхідно генерувати ключі для посилань на старі дані;
 запис нових даних у додатковому полі того самого запису.
Утакому разі зберігається початкове й останнє значення. Усі
проміжні значення втрачаються, тобто не видно історії внесення
змін до таблиць вимірювань протягом усього терміну експлуата-
ції сховища даних.
Таблиці вимірювань сховища даних можна нормалізувати. Так,
у розглянутому прикладі (рис. 10.23) таблиці вимірювань Магазин
і Продукція є ненормалізованими. Нормалізація вказаних таблиць
призведе до створення нових таблиць — довідника регіонів (Регі-
он) та довідника типів продукції (Тип_продукції). Таблиці, які
утворилися внаслідок нормалізації таблиць вимірювань, будуть
консольними таблицями, які перетворять модель сховища даних
типу «зірка» на модель типу «сніжинка» (рис.10.24).
Продаж
Продукція
Код_продукції: NUMBER (FK)
Код_типу: NUMBER (FK)
Код_магазину: NUMBER (FK) Код_продукції: NUMBER
Код_регіону: NUMBER (FK) Код_типу: NUMBER (FK)

Дата: DATE Назва_прод: СHAR (18)

Кількість: DECIMAL (,)
Ціна: NUMBER
Тип_продукції
Код_типу: NUMBER
Назва_типу: СHAR (18)
Магазин
Регіон
Код_магазину: NUMBER Код_регіону: NUMBER
Код_регіону: NUMBER (FK)
Назва_магазину.: СHAR (18) Назва_регіону: CHARACTER ()
Телефон_факс.: СHAR (18)

Рис. 10.24. Модель типу «сніжинка»

Консольну таблицю можна зв’язувати з відповідною табли-

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

318
газин не можуть існувати без зв’язку з певним екземпляром таб-
лиці Регіон, оскільки магазини розташовуються в певних регіо-
нах, а кожна продукція з таблиці Продукція обов’язково нале-
жить до певного типу. Тому консольні таблиці на моделі
«сніжинка» зв’язані ідентифікуючими зв’язками.
При проектуванні сховищ даних в ERwin можна також визна-
чити метадані. Зокрема, для кожного стовпчика можна вказати
джерело даних; метод, за допомогою якого дані вибираються, фі-
льтруються, очищаються та перетворюються, перш ніж потрап-
лять до сховища даних. Для документування інформації про дже-
рела даних використовується редактор Data Warehouse Sourse
Editor.
ERwin автоматично перевіряє коректність вимірної моделі і
видає на екран діагностичні повідомлення у таких випадках по-
рушення синтаксису:
 таблиця факту не є у зв’язку дочірньою;
 консольна таблиця не є у зв’язку батьківською;
 установлено ідентифікуючий зв’язок між консольною таб-
лицею і таблицею фактів.
Для фізичного проектування використовується методологія
Dimensional Modeling (DM). Ця методологія вибирається в заклади-
нці Methodology діалогу Preferences (меню Option/Preferences).
Вибрана опція відображає зв’язки діагональними лініями
(Orthogonal), які встановлюються в групі Relationship lines заклади-
нки General діалогу Stored Diplay Editor меню Edit/Stored Display.

Питання для самоперевiрки

1. Охарактеризуйте принципи побудови багатовимірної мо-

делі сховища даних.
2. Визначте основні компоненти багатовимірної моделі схо-
вища даних.
3. Охарактеризуйте основні операції, які можуть виконува-
тись у багатовимірній моделі сховища даних.
4. Охарактеризуйте принципи побудови реляційної моделі
сховища даних.
5. Охарактеризуйте реляційну модель сховища даних типу
«зірка».
6. Охарактеризуйте реляційну модель сховища даних типу
«сніжинка».
7. Вкажіть основні відмінності проектування сховищ даних
від баз даних.

319
8. Охарактеризуйте способи та підходи до проектування
сховищ даних.
9. Визначте вимоги, які висуваються при проектуванні схо-
вищ даних до змінних.
10. Визначте вимоги, які висуваються при проектуванні
сховищ даних до вимірів.
11. Визначте вимоги, які висуваються при проектуванні
сховищ даних до фактів.
12. Розкрийте сутність вимірного моделювання сховищ даних.
13. В якій послідовності виконуються роботи по вимірному
моделюванню сховищ даних?
14. Які характеристики повинні мати метадані?
15. Яку інформацію повинні містити метадані про факти,
виміри і змінні?
16. Яку інформацію повинні містити метадані про модель та
її джерела?
17. Суть та особливості методології вимірного моделювання
в середовищі Erwin.
18. Поясніть процедуру міграції ключів при автоматизації
проектувань сховищ даних засобами ERwin.
19. Що являє собою консольна таблиця в ERwin?

320
 11 Pоздiл
ОСНОВИ ПОБУДОВИ ІНФОРМАЦІЙНИХ СИС-
ТЕМ НА БАЗІ СХОВИЩ ДАНИХ

11.1. Аналітичні системи на базі сховищ даних

OLAP-технологія покликана підвищувати ефективність

інформаційно-аналітичної та управлінської діяльності керівного
складу персоналу. Ознаки OLAP були сформульовані Е. Ф. Код-
дом. Основними ознаками OLAP, які були визначеними Коддом, є:
Багатовимірне концептуальне представлення даних. Ця вимо-
га по-різному підтримується фірмами розробниками OLAP-
інструментів. Деякі надають засоби OLAP-аналізу без організації
багатовимірного сховища даних.
Прозорість. OLAP-технологія, її архітектура, сховище даних,
а також (можливо) неоднорідні джерела даних повинні бути про-
зорими для користувача.
Доступність. OLAP-інструменти повинні дозволяти доступ
до потрібних для аналізу даних, які зберігаються в різних неод-
норідних корпоративних джерелах, включаючи реляційні, нере-
ляційні та інші успадковані системи.
Стабільна продуктивність створення звітів. Користувачі не
повинні відчувати зниження продуктивності при збільшенні кі-
лькості вимірів, рівнів узагальнення даних і розмірів сховища да-
них. При цьому не повинні змінюватися способи обчислення
найважливіших значень. Моделі, що використовуються, повинні
бути стійкими до можливих змін корпоративної моделі.
Архітектура «клієнт/сервер». OLAP-система повинна ефек-
тивно функціонувати в середовищі «клієнт/сервер». Використан-
ня цієї архітектури має забезпечувати оптимальну продуктив-
ність, гнучкість, адаптивність, масштабованість і можливість до
взаємодії.
Універсальність вимірів. Усі виміри даних повинні бути екві-
валентними за структурою та функціональними можливостями.
Інакше кажучи, основна структура, формули і засоби створення
звітів не повинні бути прив’язаними до конкретного виміру.
Динамічне управління розрідженістю матриць. OLAP-система
повинна вміти адаптувати свою фізичну схему до конкретної

319
аналітичної моделі. Мається на увазі динамічна оптимізація роз-
рідженістю матриць, що виконується для підтримки потрібного
рівня продуктивності системи. У багатовимірних моделях прису-
тні мільйони комірок, багато з яких не вміщують конкретних да-
них на поточний момент. Відсутність значень (NULL) не повинна
негативно впливати на точність і швидкість доступу до даних.
Багатокористувацька підтримка. OLAP-система повинна за-
безпечувати паралельну роботу групи користувачів з однією чи
кількома моделями корпоративних даних.
Необмежені перехресні операції між розмірностями. OLAP-
система повинна вміти розпізнавати ієрархію розмірностей та ав-
томатично виконувати перехресні узагальнюючі обчислення все-
редині розмірності та серед розмірностей.
Підтримка інтуїтивного зрозумілого маніпулювання даними.
Розбивка, поворот (створення зведених таблиць), спадний аналіз,
консолідація (сумування), а також інші будь-які маніпулювання з
даними повинні виконуватись за допомогою найпростіших дій
щодо комірок куба типу «вибери і клацни» чи «перетягни та опусти».
Гнучкість засобів формування звітів. Необхідно також мати
інструменти упорядкування рядків, стовпчиків і комірок, які до-
зволять спростити аналіз даних за рахунок зрозумілого візуаль-
ного представлення аналітичних звітів. Користувачі повинні мати
можливість організовувати будь-яке бажане представлення по-
трібних їм даних.
Необмежене число вимірів і рівнів узагальнення. Залежно від
конкретних бізнес-вимог аналітична модель може мати різну кі-
лькість вимірів, при цьому кожен з вимірів може мати власну іє-
рархічну структуру. OLAP-система не повинна накладати жод-
них обмежень на кількість вимірів або рівнів узагальнення даних.
Через певний час вимоги та ознаки OLAP-систем, визначені
Коддом, були перевизначені та розширені. Зокрема, в деяких пуб-
лікаціях з’явились вимоги стосовно комерційних OLAP-
інструментів: вони повинні забезпечувати виконання спадного
аналізу— до рівня детальніших даних (до записів у джерелах да-
них) виконувати оновлення бази даних, а також мати SQL-
інтерфейс.
Основними ознаками OLAP-систем є:
 розподіл даних на показники (змінні) і виміри, що відповід-
но визначають стан бізнесу в різних розрізах;
 необмежене число рівнів ієрархічних зв’язків між значення-
ми вимірів.
OLAP-система повинна надавати такі можливості:

320
  обчислення і багатовимірне ієрархічне моделювання аналі-
тичних показників;
 аналіз трендів за послідовні періоди;
 квантування підмножин (створення зрізів) для візуалізації на
екрані;
 підвищення рівня деталізації до найглибших рівнів консолі-
дації (об’єднання);
 прямий доступ до основних деталізованих даних;
 ротація (поворот) до нових вимірювальних порівнянь.
Основи багатовимірного аналізу, які були започатковані
Е.Ф.Коддом, покладені в основу теста FASMI (Fast Analysis
Shared Multidimensional Information), який на сьогодні є критері-
єм оцінки функціонування OLAP-систем.
Тлумачення цього тесту таке:
Fast (швидкий) — аналіз повинен виконуватись однаково
швидко по всіх вимірах інформації. Допустимий час реакції по-
винен знаходитись у межах 5 сек.;
Analysis (аналіз) — повинна надаватись можливість виконува-
ти основні типи числового і статистичного аналізу, заданого роз-
робниками продуктів, або визначатись довільно користувачем;
Shared (розподілений) — користувачі повинні мати доступ до
даних, при цьому виконується контроль доступу до конфіденцій-
ної інформації;
Multidimensional (багатовимірний) — це основна, найсуттєві-
ша характеристика OLAP;
Information (інформація) — додатки повинні мати можливість
звернень до будь-якої потрібної інформації, незалежно від її об-
сягу та місця зберігання.
Багатовимірність в OLAP-системах може бути поділена на
три рівні:
Багатовимірне представлення даних — це засіб кінцевого ко-
ристувача, який забезпечує візуалізацію та маніпулювання дани-
ми; багатовимірне представлення абстраговано від фізичної
структури даних і сприймає дані як багатовимірні.
Багатовимірна обробка — засіб (мова) формулювання бага-
товимірних запитів (традиційна реляційна мова SQL у даному ра-
зі не придатна) і процесор, який вміє обробляти і виконувати такі
запити.
Багатовимірне зберігання — засоби фізичної організації да-
них, що забезпечують ефективне виконання багатовимірних за-
питів.

321
 Перші два рівні повинні обов’язково бути в усіх OLAP-
засобах. Третій рівень необов’язковий, оскільки дані для багато-
вимірного представлення можуть добуватись з реляційних струк-
тур. Процессор багатовимірних запитів у такому разі транслює
багатовимірні запити в SQL-запити, які виконуються реляційною
СКБД.

11.2. Cховища даних і технологія DATA MINING

Із зростанням обсягів інформації у сховищі даних біз-

нес-аналітикам стає важко засобами запитів і звітів виявляти тен-
денції та зв’язки між даними. Створення великих за обсягами
сховищ даних порушило проблему відбору корисної інформації з
нагромадженої маси даних і виявлення нових знань (knowledge
discovery in databases, KDD). Для пошуку в сховищі даних такої
інформації, яку не зможуть виявити ні за допомогою запитів, ні
шляхом створення звітів, виникла нова технологія обробки да-
них, яка дістала назву Data Mining.
Слід зауважити, що технологія Data Mining відрізняється від
статистичних досліджень даних. Коли статистик аналізує дані, то
він спочатку робить гіпотезу про можливий зв’язок між даними,
потім виконує запит і використовує статистичні методи, щоб до-
вести або спростувати висунуту гіпотезу. Це підхід називається
режимом верифікації (verification mode). На противагу йому
технологія Data Mining працює в режимі відкриття (discovery
mode), тобто виявляє приховані, часто невідомі для користувачів
взірці (patterns — шаблони) зв’язків між даними, а не аналізує
наперед створену гіпотезу відносно даних.
Англомовний термін Data Mining часто перекладається україн-
ською мовою як розробка, добування даних; добування знань;
добування інформації; аналіз, інтерпретація і представлення ін-
формації з сховища даних; вибирання інформації з масиву даних.
У даному посібнику будемо користуватись терміном «добування
даних», під яким розумітимемо процес находження в сховищах
даних попередньо невідомої, комплексної і значимої інформації
для прийняття відповідальних бізнес-рішень.
Добування даних пов’язане з аналізом даних і використанням
інструментальних засобів пошуку прихованих і неочікуваних за-
кономірностей, взаємозв’язків у сховищах даних. Результати та-
кого пошуку можна характеризувати як знання, на основі яких
322
можливо будувати моделі, формулювати певні правила. За допо-
могою цих правил можна прогнозувати розвиток подій і процесів
у майбутньому чи запобігати виникненню певних аномалій їх
розвитку.
Процес інтелектуального аналізу даних включає три можли-
вості:
 виявлення закономірностей (Discovery — відкриття);
 використання виявлених закономірностей для передбачення
(Predictive Modeling — прогнозне моделювання);
 аналіз винятків для з’ясування і тлумачення аномалій у
знайдених закономірностях (Forensic Analisys — аналіз винятків).
Методи розробки даних на сьогодні переважно використову-
ються на комерційних підприємствах, що створили або розгор-
тають проекти по створенню інформаційних сховищ даних (Data
Warehousing), хоча наявність сховища даних не є обов’язковою
умовою використання технології Data Mining.
Основною метою технології Data Mining є виявлення невідо-
мих раніше відношень між даними. Основними методами, які
дозволяють це зробити, є такі: класифікація, регресія, прогнозу-
вання часових послідовностей (рядів), кластерізація, аналіз
зв’язків та відхилення. Перші три методи застосовуються голо-
вним чином для прогнозу, а останні зручні для опису неявних
закономірностей в даних. Коротко розглянемо характеристики
цих методів.
Класифікація. За допомогою цього методу нові вхідні дані
класифікуються в існуючі, уже визначені класи. Для кожного
класу класифікованих об’єктів визначаються певні ознаки (пра-
вила). Застосування класифікації допомагає вирішити низку про-
блем, наприклад за певними ознаками виявити так званих нестій-
ких клієнтів банку, які можуть перейти в інший банк, тобто
передбачити поведінку клієнтів у майбутньому. Виявлення таких
клієнтів допоможе менеджменту банку розробити стратегію ро-
боти з такими клієнтами шляхом ряду нових пропозицій: підви-
щення відсотків на залишки коштів на поточних рахунках, на-
дання кредитів на пільгових умовах та ін.
Регресійний аналіз використовується в тому випадку, якщо
відношення між змінними можуть бути виражені кількісно у ви-
гляді певної комбінації цих змінних. Отримана комбінація далі
використовується для прогнозу значення, який може набувати
цільова (залежна) змінна, що обчислюється на заданому наборі
значень вхідних (незалежних) змінних. У найпростішому випад-
ку для цього використовуються стандартні статистичні методи,

323
такі як лінійна регресія. На жаль, більшість реальних моделей не
вкладаються в рамки лінійної регресії. Наприклад, розміри про-
дажу або котирування цінних паперів є дуже складними для про-
гнозу, оскільки можуть залежати від дуже великої кількості
пов’язаних між собою факторів (змінних).
Кластерний аналіз — це групування даних по сегментах чи
кластерах. Кластеризація подібна до класифікації, але відрізня-
ється тим, що кількість сегментів або кластерів, на які розбива-
ються дані, наперед невідома. В один сегмент чи кластер
об’єднуються дані, які характеризуються певними спільними
властивостями, що дозволяє вважати їх однорідними. Таким чи-
ном, основна мета кластерного аналізу є виокремлення з почат-
кових даних тих однорідних підмножин, коли об’єкти всередині
груп схожі за ознаками один на одного, а об’єкти з різних груп —
несхожі.
Метод аналізу зв’язків використовується для встановлення
зв’язків (асоціацій) між окремими записами даних чи їх набора-
ми. Цей метод доцільно використовувати тоді, коли події, що
відбуваються в предметній області, пов’язані між собою. Метод
аналізу зв’язків поділяється на: пошук асоціації, пошук послідо-
вних закономірностей і пошук аналогічних часових закономір-
ностей.
Пошук асоціації — це пошук деяких об’єктів, які передбача-
ють наявність інших об’єктів в тій же події. Подібність між
об’єктами задається за допомогою певних асоціативних правил.
Типовим прикладом може бути аналіз структури купівель това-
рів у супермаркетах. Наприклад, «Якщо клієнт купує пиво, то у
60% він купує і чіпси». Маючи такий асоціативний зв’язок, мо-
жна дійово регулювати знижки на ці товари, що призведе до
збільшення обсягів їх продажів.
Пошук послідовних закономірностей полягає у виявленні пев-
них закономірностей між окремими подіями. Тобто виявлення
такої закономірності, яка б визначала, що поява одного набору
даних буде супроводжуватись появою іншого набору через пев-
ний проміжок часу. Цей підхід, наприклад, використовується для
довгострокового прогнозування поведінки клієнта при виконанні
покупок.
Пошук аналогічних часових закономірностей використовуєть-
ся для знаходження зв’язків між двома наборами даних, які зале-
жать від часу. Цей метод можна застосовувати теж для аналізу
продажів, але при цьому різні операції з купівлі одним і тим са-
мим клієнтом об’єднуються в одну часову серію. Варіант такого

324
аналізу можливий, коли існує додаткова інформація (номер кре-
дитної картки клієнта або номер його банківського рахунка) для
зв’язку різних купівельних трансакцій в єдину часову серію. У
такій ситуації важливе не тільки співвідношення даних усередині
однієї трансакції, але й порядок, в якому ці дані з’являються в різ-
них трансакціях і час між цими трансакціями. Правила, які вста-
новлюють ці зв’язки, можуть бути використані для визначення
типового набору попереднього продажу, який може повести за
собою подальший продаж певного товару. Тобто, якщо існує ла-
нцюжок пов’язаних у часі подій, то йдеться про послідовність.
Наприклад, після купівлі житла у 45% випадків протягом місяця
купується нова кухонна плита, а в межах двох тижнів 60% ново-
селів купують холодильник.
Виявлення відхилень — це метод, який дозволяє визначити
ступінь відхилення від деяких наперед відомих значень матема-
тичного сподівання і стандартного середнього. Цей метод вико-
ристовується, наприклад, для виявлення спроб шахрайства з кре-
дитними картками і страховими полісами, а також при контролі
якості і пошуку дефектів.
Подібні основні типи моделей використовуються для знахо-
дження нового знання в сховищі даних. Звернемося тепер до
методів, які використовуються для проведення інтелектуально-
го аналізу даних. У такому разі застосовуються такі основні
методи:
 нейронні мережі;
 дерева рішень;
 індукцію правил.
Крім цих методів, існують ще додаткові:
 системи міркування на основі аналогічних випадків;
 нечітка логіка;
 генетичні алгоритми;
 алгоритми визначення асоціацій і послідовностей;
 аналіз з виборчою дією;
 логічна регресія;
 еволюційне програмування;
 візуалізация даних.
Іноді застосовується комбінація перелічених методів.
Нейронні мережі — це спрощені моделі, що умовно імітують
роботу нейронів людської нервової системи, яка має здатність до
навчання, узагальнення й абстракції. Математична модель ней-
рона являє собою деякий універсальний нелінійний елемент з
можливістю широкої зміни і налагодження його характеристик.

325
Нейромережі знайшли широке застосування в системах підтрим-
ки прийняття рішень, зокрема як засіб добування знань (інфор-
мації) в базах і сховищах даних.
В одній з найбільш поширених нейромережевих архітектур —
багатошаровому персептроні — із зворотним поширенням по-
милки емулюється робота нейронів у складі ієрархічної мережі,
де кожний нейрон більш високого рівня сполучений своїми вхо-
дами з виходами підпорядкованих нейронів. На нейрони найниж-
чого рівня подаються значення вхідних параметрів, на основі
яких виконуються обчислення, необхідні для прийняття рішень,
прогнозування розвитку ситуації і т. д. Ці значення розглядають-
ся як сигнали, що передаються у вищі рівні, послаблюючись або
посилюючись залежно від числових значень (ваги), що характе-
ризують міжнейронні зв’язки. Внаслідок цього на виході нейрона
найвищого рівня генерується деяке значення, яке розглядається
як відповідь, реакція всієї мережі на введені значення вхідних
параметрів. Для того щоб мережу можну було використати, її на-
самперед потрібно «навчити» на отриманих раніше наборах да-
них (прикладах), для яких відомі і значення вхідних параметрів, і
правильні відповіді на них. Процес «навчання» складається в
підборі ваг міжнейронних зв’язків і модифікації внутрішніх па-
раметрів функції активізації нейронів. Для кожного поєднання
«тренувальних» даних на вході вихідні значення порівнюються з
наперед відомим результатом. Якщо вони відрізняються, то ви-
значається коригуючий вплив, що враховується при обробці у ву-
злах мережі. Вказані кроки повторюються, поки не виконається
умова щодо необхідної корекції, яка не перевищуватиме заданої
величини.
Нейронні мережі, по суті, являють собою сукупність
пов’язаних один з одним вузлів, одержуючих вхідні дані, що
здійснюють їх обробку і генерують на виході певний результат.
Між вузлами видимих вхідного і вихідного рівнів може перебу-
вати якесь число прихованих рівнів обробки. Нейронні мережі
реалізовують непрозорий процес. Це означає, що побудована мо-
дель, як правило, не має чіткої інтерпретації. Деякі алгоритми
можуть транслювати модель нейронної мережі у набір правил, що
допомагають усвідомити, що саме вона робить. Таку можливість
пропонують деякі оригінальні продукти, що використовують тех-
нологію нейронної мережі. Багато пакетів, які реалізують принци-
пи нейронних мереж, застосовуються не тільки в сфері обробки
комерційної інформації, а й при вирішенні задач розпізнавання об-

326
разів, зокрема розпізнавання рукописних текстів, типів клітин кро-
ві та ін.
Дерево рішень використовується для генерації класифікацій-
ного дерева рішень безпосередньо з даних. Дерево рішень скла-
дається з вузлів і відрізків ліній, що з’єднують ці вузли. Існує два
типи вузлів: вузли рішень і кінцеві вузли. Вузли рішень відпові-
дають ситуації, коли під час класифікації потрібно дати відповідь
на запитання про дані. Якщо вузол не містить запитань, то це кі-
нцевий вузол.
Цей метод придатний не тільки для вирішення задач класифі-
кації, а й для обчислень і тому досить широко застосовується в
сфері фінансів і бізнесу, де часто зустрічаються задачі чисельно-
го прогнозу. Використання цього методу дозволяє створити ієрар-
хічну структуру класифікуючих правил типу «ЯКЩО... ТОДІ...»,
що має вигляд класифікаційного дерева. Для того щоб вирішити,
до якого класу віднести деякий об’єкт або ситуацію, відповімо на
запитання, що стоять у вузлах цього дерева, починаючи з його
кореня. Запитання можуть мати вигляд «значення параметра А
більше X?» для випадку змінних, що вимірюються, або «значення
змінної В належить підмножині ознак З». Якщо відповідь пози-
тивна, то переходимо до правого вузла наступного рівня, якщо
негативна — до лівого вузла. Потім знову відповідаємо на запи-
тання, пов’язане з відповідним вузлом. Таким чином зрештою
доходимо до одного з кінцевих вузлів, де стоїть вказівка, до яко-
го класу треба віднести об’єкт, що розглядається. Цей метод
приваблює тим, що таке представлення правил наочне і його лег-
ко зрозуміти та інтерпретувати.
Класифікаційне дерево спочатку створюється для навчальної
вибірки даних, яка дає бажаний результат. Користувач може
управляти процесом генерації класифікатора, специфікуючи па-
раметри дерева (максимальне число рівнів, критерії розщеплення
вузлів та ін.) та оцінюючи інформацію про виведення: кількість
записів, використаних для навчання генератора висновку; кіль-
кість записів, використаних для оцінки точності результуючого
класифікатора, і т. д. Створений класифікатор може бути засто-
сований для класифікації нових даних. Класифікатори дерев ду-
же часто використовуються для вирішення такої задачі, як визна-
чення кредитоспроможності клієнтів (фізичних осіб) банку та
класифікації їх за рівнями ризику кредитування.
Дерева рішень, незважаючи на їх простоту і прозорість для
певних типів даних, можуть виявитися неприйнятними. Зокрема,
методи дерева рішень не дуже ефективні, якщо між цільовою

327
змінною та вхідними даними є лінійна залежність, оскільки в та-
кому разі дерево повинно мати велике число вузлів. Іноді вини-
кають проблеми при обробці безперервних величин, скажімо да-
них про вік або обсяг продажів. У даному разі їх необхідно
групувати і ранжувати. Однак вибраний для ранжування метод
може випадково приховати ту закономірність, яку хочемо вияви-
ти. Наприклад, якщо група об’єднує людей у віці від 25 до 34 ро-
ків, то той факт, що на рубежі 30 років деякий параметр має істо-
тну відмінність, може виявитися прихованим. Цього недоліку не
містить продукт SAS Enterprise Miner внаслідок того, що реалізо-
вані в ньому методи побудови дерева рішень можуть автоматич-
но виявляти межу (числовий критерій) розділення даних на од-
норідніші підгрупи.
Для дерев рішень дуже гостро стоїть проблема значущості.
Якщо побудоване дерево досить розгалужене і складається з не-
виправдано великого числа дрібних дуг, воно не даватиме стати-
стично обґрунтованих відповідей. Як свідчить практика, в біль-
шості систем, що використовують дерева рішень, ця проблема не
знаходить задовільного вирішення. Винятком з цього ряду є зга-
даний вище SAS Enterprise Miner, що включає широкий спектр
діагностичних інструментів, за допомогою яких аналітик може
вибрати статистично найобґрунтованішу модель з безлічі дерев
рішень і, більш того, порівняти отриману модель дерева з прин-
ципово іншими типами моделей (регресивною і нейромереже-
вою). У даному продукті цільовою змінною може бути як вели-
чина, що вимірюються, так і дискретна (змінна, що не вимірюється,
або ознаки), котра істотно розширює область застосування роз-
глянутого вище методу.
Індукція правил. Цей інструмент безпосередньо з даних ви-
водить класифікатор правил, що ранжує дані, визначаючи імо-
вірності, за яких може трапитися деякий, заздалегідь очікуваний
результат при заданих значеннях ознаки. Наприклад, можна ви-
значити, що клієнт банку, який володіє автомобілем вартістю
від 15 до 25 тис. дол., з імовірністю 70% поверне кредит. При
цьому класифікатор призначає умовні імовірності унікальним
величинам ознаки або діапазону величин для нього. Також на
основі розподілу записів з навчальних даних (використаних
для побудови класифікатора) обчислюється апріорна імовір-
ність.
Система міркування на основі аналогічних випадків ро-
бить прогноз на майбутнє або вибирає правильні рішення на ос-
нові минулому. В минулому знаходяться і близькі аналоги пото-

328
чної ситуації, які дають змогу вибрати ту відповідь, яка була пра-
вильною в минулому. Тому цей метод ще називають методом
найближчого сусіда (nearest neighbour). Системи міркування на
основі аналогічних випадків демонструють дуже хороші резуль-
тати у найрізноманітніших задачах. Головний їх недолік полягає
в тому, що вони взагалі не створюють яких-небудь моделей або
правил, котрі узагальнюють попередній досвід. При виборі рі-
шення вони засновуються на всьому масиві доступних історич-
них даних, тому неможливо сказати, на основі яких конкретних
чинників ці системи будують свої відповіді.
Нечітка логіка застосовується для таких наборів даних, де
зарахування елементів даних до якої-небудь групи визначається
мірою належності, що знаходиться на інтервалі від 0 до 1, але не
приймає крайніх значень. Чітка логіка маніпулює результатами,
які можуть бути або істиною, або хибністю. Нечітка логіка засто-
совується в тих випадках, коли необхідно маніпулювати мірою
«може бути» на доповнення до «так» і «ні».
Генетичні алгоритми застосовуються не лише для інтелек-
туального аналізу даних. Їх можна також використовувати як
засіб вирішення різноманітних комбінаторних і оптимізаційних
задач. Проте генетичні алгоритми увійшли в стандартний ін-
струментарій методів Data Mining. Генетичні алгоритми іміту-
ють процеси біологічної еволюції. Основна ідея їх полягає в то-
му, що внаслідок еволюції відбувається відбір найкращих
(найбільш пристосованих) екземплярів. Застосування генетич-
них алгоритмів при аналізі даних дає найкращу «популяцію»,
тобто рішення.
Нехай нам потрібно знайти розв’язання, найоптимальніше з
погляду деякого критерію. При цьому кожне рішення повністю
описується деяким набором чисел або величин нечислової при-
роди. Наприклад, якщо необхідно вибрати сукупність фіксовано-
го числа параметрів ринку, котре найбільш виражено впливає на
динаміку цього ринку, це буде набір імен цих параметрів. Про
цей набір можна говорити як про сукупність хромосом, що ви-
значають якості індивіда — рішення поставленої задачі. Значен-
ня параметрів, що визначають рішення, будуть тоді називатися
генами. Пошук оптимального рішення при цьому схожий на ево-
люцію популяції індивідів, представлених наборами їх хромо-
сом. У цій еволюції діють три механізми: по-перше, відбір най-
сильніших наборів хромосом, яким відповідають найкращі
рішення; по-друге, схрещування, тобто продукування нових ін-
дивідів за допомогою змішування хромосомних наборів відібра-

329
них індивідів; і, по-третє, мутації — випадкові зміни генів у де-
яких індивідів популяції. Внаслідок зміни поколінь виробляється
таке рішення поставленої задачі, яке вже не може бути в подаль-
шому суттєво поліпшене.
Генетичні алгоритми мають два недоліки. По-перше, сама по-
становка задачі в її термінах не дає можливості проаналізувати
статистичну значущість рішення, що отримується за їх допомо-
гою і, по-друге, ефективно сформулювати задачу, визначити кри-
терій відбору хромосом під силу тільки фахівцеві високої квалі-
фікації. Внаслідок таких обставин сьогодні генетичні алгоритми
треба розглядати швидше як інструмент наукового дослідження,
ніж як засіб аналізу даних для практичного застосування в бізне-
сі та фінансах.
Алгоритми виявлення асоціацій знаходять правила про
окремі об’єкти, які з’являються разом в одній економічній опе-
рації, наприклад в одній трансакції купівлі. Послідовність — це
також асоціація, але вона залежить від часу. Асоціація завжди
досліджується між парами подій (об’єктів), наприклад, між А і Б,
де А називається лівою частиною, або передумовою, Б — правою
частиною, або наслідком.
Сила асоціації задається кількісно такими характеристиками:
1.Поширеність. Частота появи кожного окремого об’єкта або
їх групи показує, як часто А і В зустрічаються разом у файлі. Об-
числюється як співвідношення кількості записів, де А і В присут-
ні разом до загальної кількості записів. Ця величина вимірюється
у відсотках і носить назву поширеність. Низький рівень пошире-
ності (менш однієї тисячної відсотка) говорить про те, що така
асоціація не істотна.
2.Довірчість — характеризує взаємозв’язок між А і Б. Вона
демонструє, як часто при появі А з’являється Б, і розраховується
як відношення частоти появи (поширеність) А і Б разом до по-
ширеності А. Тобто якщо довірчість А до Б дорівнює 20%, то це
означає, що при купівлі товару А в кожному п’ятому випадку бу-
де придбано і товар Б. Необходімо помітити, що якщо пошире-
ність А не дорівнює поширеності Б, то і довірчість А до Б не дорі-
внює довірчості Б до А. Дійсно, купівля комп’ютера частіше веде
до купівлі дискет, ніж купівля дискети до купівлі комп’ютера.
3.Потужність характеризує вплив появи А на появу Б. Чим
більша потужність, тим сильніше вплив появи А на появу Б. По-
тужність розраховується за формулою: (довірчість А до Б) / (по-
ширеність Б).

330
 Деякі алгоритми пошуку асоціацій спочатку сортують дані і
тільки після цього визначають взаємозв’язок і поширеність. Єди-
ною відмінністю таких алгоритмів є швидкість або ефективність
знаходження асоціацій. Це особливо важливо через величезну кі-
лькість комбінацій, які необхідно перебрати для знаходження
найбільш значущих правил. Алгоритми пошуку асоціацій можуть
створювати свої бази даних поширеності, довірчості і потужнос-
тей, до яких можна звертатися за запитом. Наприклад: «Знайти
всі асоціації, в яких для товару Х довірчість перевищує 50% і по-
ширеність не менша за 2,5%».
При знаходженні послідовностей додається змінна часу, яка
дозволяє працювати з серією подій для знаходження послідовних
асоціацій протягом певного періоду.
Аналіз з виборчою дією — одна з давно відомих математи-
чних технологій класифікації. Вона знаходить площини (або
лінії для двовимірного простору), які розділяють групи. Отри-
мані моделі дуже прості для пояснення, оскільки все, що кори-
стувач повинен зробити з отриманою моделлю, — це визначи-
ти, по яку сторону площини або лінії потрапляє крапка. Така
технологія часто застосовується в медицині, соціальних науках
і біології.
Однак потрібно визнати, що аналіз з виборчою дією не дуже
часто застосовується при аналізі даних за допомогою технології
Data Mining з таких причин. По-перше, передбачається, що змін-
ні, які необхідно спрогнозувати, нормально розподілені. По-друге,
неможливо передбачити категоріальні змінні, які не можна упо-
рядкувати (наприклад, червоний-жовтий-зелений). По-третє, ме-
жі, які розділяють класи, — це лінії або площини (в їх класично-
му Евклідовому розумінні), але дані переважно не можуть бути
розділені таким способом. Нові методи аналізу з виборчою дією
вирішують деякі з цих проблем, дозволяючи межам бути не лі-
нійними, а квадратичними. Також можливо замінити припущен-
ня нормальності оцінкою реального розподілу, тобто теоретичну
дзвоноподібну криву параметрами реального розподілу змінної,
що передбачається.
Логічна (логістична) регресія має багато загального із зви-
чайною лінійною регресією, але використовується для прогнозу
імовірності появи того або іншого значення дискретною цільо-
вою змінною, таких як (0 або 1), («так» або «ні»), («відмінно»,
«добре», «погано»). Оскільки ця змінна дискретна, вона не може
бути змодельована методами звичайної багатофакторної лінійної
регресії. Проте результат (імовірність) може бути виражена у ви-

331
гляді лінійної комбінації вхідних змінних, що дозволяє дістати
кількісні оцінки впливу цих параметрів на залежну змінну.
Отримані імовірності можуть використовуватися і для оцінки
шансів. Шанс — це відношення імовірності появи події до імові-
рності того, що подія не станеться. Це відношення означає те са-
ме, що і шанс у грі або спортивних змаганнях. Коли ми говоримо
про те, що шанси команди виграти футбольний матч 3 : 1, це
означає, що імовірність перемоги в три рази більша за імовірність
поразки. Тобто, ми маємо 75% імовірність перемоги і 25% імові-
рність поразки. Аналогічна термінологія вживається і до шансів
певного типу клієнта (тобто клієнта заданої статі, з певним при-
бутком, сімейним станом тощо) відповісти на цільову рекламу.
Логічна регресія — це, з одного боку, класифікаційний ін-
струмент, який використовується для прогнозу значень категорі-
альних змінних (чи зробить певний клієнт купівлю, чи ні). З ін-
шого боку, — це регресійний інструмент, який використовується
для оцінки міри впливу вхідних чинників (у даному разі індиві-
дуальних характеристик клієнтів).
Еволюційне програмування — це найперспективніший на-
прям Data Mining. Суть методу полягає в тому, що гіпотези про
вигляд залежності цільової змінної від інших змінних формулю-
ються системою у вигляді програм на деякій внутрішній мові
програмування. Якщо це універсальна мова, то теоретично на
ньому можна виразити залежність будь-якого вигляду. Процес
побудови цих програм формується як еволюція в світі програм
(цим метод трохи схожий на генетичні алгоритми). Коли система
знаходить програму, яка досить точно виражає залежність, що
відшукується, вона починає вносити в неї невеликі модифікації і
відбирає серед побудованих таким способом дочірніх програм ті,
які підвищують точність. Таким чином, система створює («виро-
щує») кілька генетичних ліній програм, які конкурують між со-
бою в точності виразу шуканої залежності. Спеціальний транс-
люючий модуль перекладає знайдену залежність з внутрішньої
мови системи на зрозумілу користувачеві мову (математичні фор-
мули, таблиці та ін.), роблячи їх прозорими для користувача. Для
того щоб зробити отримані результати ще зрозумілішими для ко-
ристувача-нематематика, існує багатий арсенал різноманітних за-
собів візуалізації виявлених залежностей.
Пошук залежності цільових змінних від інших ведеться у фо-
рмі функцій якогось певного вигляду. Цей метод не має суттєвих
переваг порівняно з нейронними мережами з їх готовим набо-
ром стандартних нелінійних функцій, незважаючи на те, що

332
отримана формула залежності в принципі піддається аналізу та
інтерпретації (хоча на практиці все таки буває досить складно у
такій ситуації).
Комбіновані методи. Часто виробники поєднують вказані
підходи. Об’єднання засобів нейронних мереж і технології дерев
рішень повинно сприяти побудові більш точної моделі і підви-
щенню її швидкодії. Програми візуалізації даних у прямому ро-
зумінні не є засобом аналізу інформації, оскільки вони лише ві-
дображають результати аналізу користувачеві. Проте візуальне
відображення, наприклад, відразу чотирьох змінних досить вираз-
но узагальнює дуже великі обсяги даних. Деякі виробники розу-
міють, що для розв’язання кожної проблеми потрібно застосовува-
ти свій оптимальний метод. Наприклад, продукт SAS Enterprise
Miner 3.0 включає модуль автоматичної побудови результуючої
гібридної моделі, визначеної на безлічі моделей, створених зазда-
легідь принципово різними методами: методами дерева рішень,
нейронних мереж, узагальненої багатофакторної регресії.

11.3. Основи побудови інформаційних систем на

базі сховищ даних

Системи, що використовують сховище даних, буду-

ються на основі архітектури «клієнт-сервер». Сховище даних
розміщується на спеціальному сервері сховища даних. Для його
реалізації застосовуються потужні багатопроцесорні обчислюва-
льні системи таких виробників, як IBM, Hewllett-Packard, DEC,
NCR, Microsoft, SAS та ін. Як СКДБ може використовуватись
одна з таких систем, які підтримують паралельну обробку запи-
тів: Teradata (фірми NCR), DB/2 (фірми IBM), Oracle, SQL Server
(фірми Microsoft), Informix тощо.
Сучасні системи ґрунтуються на базі сховищ даних і можуть
зберігати великі обсяги інформації. Залежно від обсягів інформа-
ції сховища даних класифікуються таким чином (табл.11.1) [46].
Таблиця 11.1
КЛАСИФІКАЦІЯ СХОВИЩ ДАНИХ ЗА ОБСЯГАМИ ДАНИХ

Тип сховища Обсяги інформації Кількість записів у таблиці фа-

ктів
Мале До 3 Гбайт Декілька мільйонів

333
 Середнє До 25 Гбайт До ста мільйонів
Велике До 200 Гбайт Декілька сотень мільйонів
Гіпервелике Понад 200 Гбайт Мільярд і більше

Системи, побудовані на основі сховищ, повинні мати інстру-

менти для виконання операцій адміністрування. Інструменти
управління і адміністрування дозволяють виконувати такі операції:
 моніторинг завантаження даних з кількох джерел;
 перевірка якості і цілісності даних;
 управління і поновлення метаданих;
 моніторинг поточної ефективності сховища даних з метою
забезпечення більш швидкого виконання запитів та ефективного
використання ресурсів;
 аудит процесів використання сховища даних по кожному
користувачеві та визначення вартості виконаних робіт;
 реплікація, розбивка та розподіл даних;
 очистка даних;
 архівування і резервне копіювання даних;
 відновлення після збоїв;
 управління засобами захисту.
Основними виробниками програмних продуктів для підтрим-
ки сховищ даних є компанії: Arbor, Business Objests, Carleton,
Cognos, Hewlett-Packard, IBM, Information Builders, Informix,
Intellidex, Microsoft, MSP, NCR, Oracle, Platinum Technology,
Praxis, Prism, Pyramid, Red Brick, SAS Institute, Sequent, Software
AG, Sybase, Tandem. Усе ці фірми мають сторінки в Internet, де
наводиться детальна інформація про їх продукти та послуги. Роз-
глянемо коротку характеристику програмних продуктів основних
компаній — виробників сховищ даних.
Компанія IBM. Рішення компанії IBM називається А Data
Warehouse Plus. Мета компанії — забезпечення інтегрованого
набору програмних продуктів і сервісів, заснованих на єдиній ар-
хітектурі. Основою сховищ даних є сімейство СКБД DB2. Пере-
вага IBM полягає в тому, що дані, які треба витягнути з оператив-
ної бази даних і вмістити в сховищі даних, знаходяться в
системах IBM. Тому природна тісна інтеграція програмних про-
дуктів.
Пропонуються три рішення для сховищ даних:
Ізольована вітрина даних. Призначено для розв’язання окре-
мих задач поза зв’язком із загальним сховищем корпорації.

334
 Залежна вітрина даних. Аналогічно ізольованій вітрині да-
них, але джерела даних перебувають під централізованим конт-
ролем і управлінням.
Глобальне сховище даних. Корпоративне сховище даних, яке
повністю централізовано контролюється. Глобальне сховище да-
них може зберігатися централізовано або складатися з кількох
розподілених у мережі сховищ даних.
Oracle. Сімейство програмних продуктів Oracle Express при-
значено для розробки систем багатовимірного аналізу даних і за-
безпечує багатофункціональний інструментарій як для створення
і підтримки багатовимірних баз даних, так і для одержання при-
кладних програм, що реалізують функції аналізу даних і корис-
тувацького інтерфейсу. Oracle Express побудований за архітекту-
рою «клієнт/сервер» і включає серверні і клієнтські-програми.
Серверне програмне забезпечення Oracle Express Server може
працювати під управлінням операційних систем UNIX, Windows
NT, Sun Solaris та ін. Express Server являє собою систему управ-
ління багатовимірною базою даних і забезпечує широкі можли-
вості моделювання взаємозв’язків між даними, маніпулювання
даними, прогнозування, аналізу типу «що, якщо …?», формуван-
ня звітів і графіків. До складу Oracle Express Server входить мова
програмування високого рівня Express, яка дає змогу створювати
багатофункціональні збережувані процедури для реалізації сер-
верних функцій.
Express Server підтримує обмін даними з іншими СКБД завдя-
ки технології ODBC, має вбудовану мову структурованих запитів
SQL, що забезпечує взаємодію з реляційними БД, надає можли-
вості обміну запитами із SQL-серверами. Серверні функції на пер-
сональних комп’ютерах реалізує Personal Express, який забезпе-
чує гнучку взаємодію з Express Server і є його функціональним
аналогом.
Клієнтське програмне забезпечення Oracle Express працює
на персональних комп’ютерах і реалізує функції інтерфейсу
користувача, надаючи доступ до виконання на сервері програм
і функцій. До складу клієнтських програм Oracle Express вхо-
дять: Express Administrator, Express Analyzer, Express Objects,
Financial Analyzer, Sales Analyzer, Express Web Agent, Express
Web Publisher.
Hewlett Packard. Роботи, пов’язані зі сховищами даних, ви-
конуються в рамках програми OpenWarehouse. Виконання цієї
програми повинно забезпечити можливість побудови сховищ да-
них на основі могутніх комп’ютерів HP, апаратури інших вироб-

335
ників і програмних компонентів. Основою підходу HP є Unix-
платформи і програмний продукт Intelligent Warehouse, який при-
значений для управління сховищами даних. Основа побудови
сховищ даних (HP), що пропонується, залишає свободу вибору
реляційної СКБД, засобів реінжинірингу і т. д.
NCR. Рішення компанії спрямоване на розв’язання проблем
корпорацій, в яких однаково сильні потреби і в системах підтрим-
ки прийняття рішень, і в системах оперативної аналітичної обро-
бки даних. Архітектура, що називається Enterprise Information
Factory, засновується на досвіді використання системи управлін-
ня базами даних Teradata і пов’язаних з нею методах паралельної
обробки.
Informix Software. Стратегія компанії стосовно сховищ даних
спрямована на розширення ринку для власного продукту On-Line
Dinamic Parallel Server. Архітектура сховища даних, що пропо-
нується, базується на чотирьох технологіях: реляційні бази да-
них, програмне забезпечення для управління сховищем даних,
засоби доступу до даних і платформи відкритих систем. Три
останні компоненти розробляються партнерами компанії. Після
виходу універсального сервера, заснованого на об’єктно-
реляційному підході, можна чекати, що і він буде використову-
ватися для побудови сховищ даних.
SAS Institute. Компанія вважає себе постачальником повного
рішення для організації сховища даних. Підхід заснований на та-
кому:
 забезпечення доступу до даних з можливістю їх витягнен-
ня з найрізноманітніших сховищ даних (і реляційних, і нереля-
ційних);
 перетворення даних і маніпулювання ними з використанням
4GL;
 наявність сервера багатомірних баз даних;
 великий набір методів і засобів для аналітичної обробки і
статистичного аналізу.
Sybase. Стратегія компанії у галузі сховищ даних ґрунтується
на розробленій нею архітектурі Warehouse WORKS. В основі під-
ходу — реляційна СКБД Sybase System 11, засіб для підключення
і доступу до баз даних OmniCONNECT і засіб розробки приклад-
них застосувань PowerBuilder. Компанія продовжує вдосконалю-
вати свою СКБД для кращого задоволення потреб сховищ даних
(наприклад, введена побітова індексація).
Software AG. Діяльність компанії в сфері сховищ даних від-
бувається в рамках програми Open Data Warehouse Initiative.

336
Програма базується на основних продуктах компанії ADABAS і
Natural 4GL, власних і придбаних засобах витягнення й аналізу
даних, засобах управління сховищем даних SourcePoint. Останній
дозволяє автоматизувати процес витягнення і пересилки даних, а
також їх завантаження у сховище даних.
Узагальнюючи все описане вище, можна навести таку струк-
туру інформаційної системи на основі сховищ даних (рис. 11.1).

OLTP Блок
регламентних
аналітичних Інформаційна
задач система
БД

Блок очищення
Зовнішні та узгодження
дані даних Data Mining

Сховище Блок
даних інтелектуального
аналізу даних

OLАP

Блок оперативних
аналітичних задач

Рис. 11.1. Структура інформаційної системи на основі сховищ даних

Нагромадження значних обсягів інформації у сховищі даних

створить у подальшому передумови для інтелектуального аналізу
даних. Інтелектуальний аналіз даних — це новий напрям у розви-
тку інформаційних систем, який нерозривно пов’язаний зі схо-
вищами даних та OLAP-системами. Оперативний багатовимірний
та інтелектуальний аналіз даних — це дві нерозривні складові
процесу прийняття рішень. Тому зараз відбувається інтеграція
цих двох напрямів розвитку інформаційних технологій за такими
варіантами:
 Cubing the mining — інтелектуальний аналіз повинен вико-
нуватись над будь-яким результатом запиту, тобто над будь-якою
проекцією гіперкуба;

337
  Mining the cubing — добуті зі сховища результати інтелекту-
ального аналізу повинні представлятись у гіперкубічній формі
для подальшого багатовимірного аналізу;
 Cubing while mining — гнучкий спосіб інтеграції, який до-
зволить автоматично активізувати однотипні механізми інтелек-
туального аналізу над результатами кожного кроку багатовимір-
ного аналізу.

Питання для самоперевірки

1. Перелічіть та коротко охарактеризуйте основні ознак

OLAP-технології.
2. Дайте визначення терміну «добування даних» (Data Mining).
3. Наведіть приклади застосування технології Data Mining.
4. Як сховище даних пов’язане з технологією Data Mining?
5. Перелічіть основні методи інтелектуального аналізу та
добування даних.
6. Охарактеризуйте сутність інтелектуального аналізу даних
на основі нейромереж.
7. Охарактеризуйте сутність інтелектуального аналізу даних
на основі генетичного алгоритму.
8. Охарактеризуйте сутність інтелектуального аналізу даних
на основі дерева рішень.
9. Охарактеризуйте сутність алгоритму виявлення асоціацій.
10. Який існує зв’язок між сховищами даних і технологією
Data Mining?
11. Охарактеризуйте основні блоки інформаційної системи,
побудованої на основі сховищ даних.

338
 СПИСОК ЛІТЕРАТУРИ

1. Аналитические технологии для прогнозирования и анализа данных:

Wysiwyg://content.11/http://www.neuroproject.ru/database/genealg.html.
2. Архипенков С. Аналитические системы на базе Oracle Express
OLAP: Проектирование, создание, сопровождение. — М.: Диалог-
МИФИ, 2000. — 320 с.
3. Атре Ш. Структурный подход к организации баз данных: Пер. с
англ. А. А. Александрова и В. И. Будзко; Под ред. В.И. Будзко. –– М.:
Финансы и статистика, 1983. — 317 с.
4. Бойко В. В., Савинков В. М. Проектирование баз данных инфор-
мационных систем. — М.: Финансы и статистика, 1999. — 371 с.
5. Буров К. Обнаружение знаний в хранилищах данных // Открытые
системы. — 1999. — №5—6.
6. Ванг Ю., Джонсон Е., Уай П. Средства автоматизации проекти-
рования баз данных: моделирование для будущего // Компьютеры +
программы. Банковские технологии. — 1997. — № 1. — С. 79—77.
7. Вейскас Д. Эффективная работа с Microsoft Access 97: Пер. с
англ.— СПб.: Питер Ком, 1999. — 974 с.
8. Вендров А.М. СASE-технологии: Современные методы и средства
проектирования информационных систем.
9. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с
СУБД.— СПб.: Питер, 1997. — 704 с.
10. Горин С. В., Тандоев А. Ю. СASE-средство S-Designor 4.2 для
разработки структуры баз данных // СУБД. — 1996. — №1. —
С.79—86.
11. Горин С. В., Тандоев А. Ю. Применение CASE-средств ERwin
2.0 для информационного моделирования в системах обработки дан-
ных. — М.: Диалог-МИФИ, 1999. — 256 с.
12. Гусева Т. А., Башин Ю. Б. Проектирование баз данных в приме-
рах и задачах. –– М.: Радио и связь, 1992. — 160 с.
13. Дейт К. Дж. Введение в системы баз данных: Пер. с англ. — 6-е
изд. — К.: Диалектика, 1998. — 784 с.
14. Державний стандарт України. Системи оброблення інформації.
Бази даних. Терміни і визначення. ДСТУ 2874-94. — К.: Держстандарт
України, 1994. — 31 с.
15. Дженигс Р. Использование Microsoft Access 97: Пер. с англ. —
2-е изд. — К.; М.; СПб.: Изд. дом «Вильямс», 1998. — 944 с.

339
 16. Диго С. М. Проектирование и использование баз данных: Учеб-
ник. –– М.: Финансы и статистика, 1995. — 208 с.
17. Дюк В. А. Data Mining — интеллектуальный анализ данных.
Wysiwyg://18/http://www.olap.ru/basic/dm2.asp
18. Дюк В. А. Data Mining — состояние проблемы, новые решения:
Wysiwyg://38/http://www.inftech.webservis.ru/database/datamining/ar1.html
19. Єрьоміна Н. В. Концепція побудови аналітичної інформаційної си-
стеми банку // Наук. вісник Державної податкової служби України.— № 3.
20. Єрьоміна Н. В. Проектування баз даних: Навч. посібник.— К.:
КНЕУ, 1998. — 208 с.
21. Заратуйченко О. Современные подходы и методы построения
аналитических информационных систем // Тезисы выступления на се-
минаре НТЦ АРБ «Практические вопросы информационно-
аналитической работы в коммерческом банке». — 1998. — март.
22. Змитрович А. М. Базы данных: Учебн. пособие. –– Минск:
Університетське, 1991. — 271 с.
23. Кембелл М. Access. Ответы: Пер. с англ. — М.: Восточная Книж-
ная Компания, 1997. — 336 с.
24. Киселев М., Соломатин Е. Средства добычи знаний в бизнесе и
финансах: Открытые системы. — 1997. — №4. — С. 41—44.
25. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование,
реализация и сопровождение: Теория и практика // Пер. с англ.: Учебн.
пособие. — 2-е изд. — М.: Изд. дом «Вильямс», 2000. — 1120 с.
26. Корнеев В. В., Гареев А. Ф., Васютин С. В., Райх В. В. Базы дан-
ных: Интеллектуальная обработка информации. — М.: Нолидж, 2000.—
372 с.
27. Кузнецов С. Д. Ведення в СУБД // СУБД. — 1997. — №1—3.
28. Кузнецов С., Артемьев В. Обзор возможностей применения ве-
дущих СУБД для построения харнилищ данных (DataWarehouse) //
http:/www.citforum.ru/database/kbd98/glava15.shtml.
29. Куправа Т. А. Создание и программирование БД средствами
СУБД. — М.: Мир, 1991. — 177 с.
30. Ленг-Хонг Б., Плагман Б. Система словарей-справочников дан-
ных: Пер. с англ. — М.: Финансы и статистика, 1997. — 311 с.
31. Львов В. Создание систем поддержки решений на основе храни-
лищ данных // СУБД. — 1997. — № 3. — С. 30—40.
32. Маклаков С. В. BPwin и ERwin CASE-средства разработки ин-
формационных систем. — М.: Диалог-МИФИ, 2000. — 250 с.
33. Мартин Дж. Организация баз данных в вычислительных систе-
мах: Пер. с англ. — М.: Мир, 1980.
34. Microsoft Access 2000: Справо. пособие. — 2-е изд. — СПб.: Пи-
тер, 2000. — 416 с.
35. Основы современных компьютерных технологий: Учебн. посо-
бие / Под ред. проф. А. Д. Хомоненко. — СПб.: КОРОНА-принт, 1998.
36. Перспективы развития вычислительной техники: В 11 кн.:
Справ. пособие / Под ред. Ю. М. Смирнова; Кн. 2. Интеллектуализация

340
ЭВМ / Е. С. Кузин, А. И. Ройтман, И. Б. Фоминых, Г. К. Хахалин. —
М.: Высш. шк., 1989. — 159 с.
37. Полищук Ю. М., Хон В. Б. Теория автоматизированных банков
информации: Учебн. пособие. — М.: Высш. шк., 1999. — 194 с.
38. Поспелов Г. С. Искусственный интеллект — основа новой ин-
формационной технологии. — М.: Наука, 1988. — 280 с.
39. Поспелов Д. А. Данные и знания: Искуственный интеллект:
Кн.1.— М.: Радио и связь, 1990.
40. Проектирование интегрированных баз данных / А. А. Стогний,
В.Э. Вольфенгаген, В. А. Кушниров и др. — К.: Техника, 1987. — 143с.
41. Сахаров А. А. Принципы проектирования и использования мно-
гомерных баз данных (на примере Oracle Express Server) // СУБД. —
1996. — № 3.
42. Сиколенко В. В. Поддержка распределенных систем в СУБД
ORACLE // СУБД. — 1997. — № 4. — С. 27—74.
43. Cистемы баз данных третьего поколения: Манифест. Комитет по
развитию функциональных возможностей СУБД // СУБД. — 1995. —
№2. — С.143—159.
44. Системы управления базами данных и знаний: Справ. изд. / Под.
ред. А. Н. Наумова. — М.: Финансы и статистика, 1991. — 372 с.
45. Ситник В. Ф. та ін. Основи інформаційних систем: Навч. по-
сібн.— 2-ге вид., перероб. і доп. — К.: КНЕУ, 2001. — 420 с.
46. Спирли Э. Корпоративные хранилища данных: Планирование,
разработка, реализация: Том 1.: Пер. с англ. — М.: Изд. дом «Вильямс»,
2001. — 400 с.
47. Тамер Оззу М., Патрик Валдуриз. Распределенные и параллель-
ные системы баз данных // СУБД. — 1997. — № 4. — С. 4—27.
48. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х
кн.: Пер. с англ. — М.: Мир, 1997. — 311 с.
49. Торбен Бэч Педерсен, Кристиан Йенсен. Технология многомер-
ных баз данных // Открытые системы. — 2002. — № 1.
50. Ульман Дж. Основы систем баз данных. — М.: Финансы и ста-
тистика, 1983.
51. Федоров Ф., Елманова Н. Введение в OLAP: Ч. 1: Основы OLAP
// КомпьютерПресс. — 2001. — №4.
52. Федоров Ф., Елманова Н. Введение в OLAP: Ч. 2: Хранилища
данных // КомпьютерПресс. — 2001. — №5.
53. Федоров Ф., Елманова Н. Введение в OLAP: Ч. 5. Создание мно-
гомерных баз данных // КомпьютерПресс. — 2001. — № 8.
54. Хансен Г., Хансен Д. Базы данных: разработка и управление: Пер.
с англ. — М.: БИНОМ, 1999. — 704 с.
55. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных:
Учебник для высш. учеб. заведений / Под ред. проф. А. Д. Хомонен-
ко.— СПб.: КОРОНА-принт, 2000. — 416 с.
56. Цаленко М. Ш. Семантические и математические модели баз
данных. — М.: ВИНИТИ, 1985. — 205 с.

341
 57. Цикритзис Д., Лоховски Ф. Модели данных: Пер. с англ. — М.:
Финансы и статистика, 1997. — 344 с.
58. Pendse N. The OLAP Report Whot is OLAP? — Busines Intelligence
Ltd. 1999. — 8 p.
59. Codd E. F., Codd S. B., Salley C. T. Providing OLAP (On-Line
Analytical Processing) to User-Analysts: An IT Mandate: www.hyperion.com/
solutions/whitepapers.cfm
60. Ballard Chuck, Herreman Dirk, Schau Don, Bell Rhonda, Kim
Eunsaeng, Valencie Ann. Data modeling Technigues for Data
Warehousing.— International Technical Support Orcanization, 1998.

342
 ЗМІСТ

ВСТУП. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Розділ 1. Введення в поняття «банки даних». Основні поняття. . . . 5

1.1. Передумови створення та основні переваги банків даних . 5
1.2. Поняття банку даних та його структура . . . . . . . . . . . . . . . 7
1.2.1. База даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. Система керування базами даних . . . . . . . . . . . . . . 10
1.3. Характеристика багатокористувацьких СКБД . . . . . . . . . 11
1.4. Покоління СКБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5. Мовні засоби . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6. Адміністрування бази даних . . . . . . . . . . . . . . . . . . . . . . . 21
1.7. Етапи проектування баз даних . . . . . . . . . . . . . . . . . . . . . 23

Розділ 2. Інфологічне проектування баз даних . . . . . . . . . . . . . . . . 27

2.1. Зовнішній рівень — підготовчий етап інфологічного проек-
тування . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2. Вимоги і підходи до інфологічного проектування . . . . . . 30
2.3. Складові інфологічної моделі . . . . . . . . . . . . . . . . . . . . . . 31
2.4. Методика інфологічного проектування . . . . . . . . . . . . . . 33
2.5. Перевірка повноти і коректності інфологічної моделі . . . 44
2.6. Опис складових інфологічної моделі . . . . . . . . . . . . . . . . 47

Розділ 3. Даталогічне проектування баз даних . . . . . . . . . . . . . . . . 53

3.1. Поняття даталогічного проектування . . . . . . . . . . . . . . . . 53
3.2. Відображення на реляційну модель . . . . . . . . . . . . . . . . . 54
3.3. Відображення на єрархічну модель . . . . . . . . . . . . . . . . . 55
3.4. Відображення на мережеву модель. . . . . . . . . . . . . . . . . . 60
3.5. Вибір СКБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

343
Розділ 4. Проектування баз даних на основі нормалізації . . . . . . . 70
4.1. Сутність проектування баз даних на основі нормалізації . 70
4.2. Аномалії ненормалізованого відношення . . . . . . . . . . . . . 72
4.3. Теорія нормалізації відношень . . . . . . . . . . . . . . . . . . . . . 73
4.3.1. Перша нормальна форма . . . . . . . . . . . . . . . . . . . . . 73
4.3.2. Друга нормальна форма. . . . . . . . . . . . . . . . . . . . . . 74
4.3.3. Третя нормальна форма . . . . . . . . . . . . . . . . . . . . . . 76
4.4. Нормальні форми більш високих порядків . . . . . . . . . . . . 78
4.4.1. Нормальна форма Бойса—Кодда. . . . . . . . . . . . . . . 78
4.4.2. Четверта нормальна форма . . . . . . . . . . . . . . . . . . . 81
4.4.3. П’ята нормальна форма . . . . . . . . . . . . . . . . . . . . . . 83

Розділ 5. Автоматизація проектування баз даних . . . . . . . . . . . . . . 88

5.1. Загальна характеристика CASE-засобів . . . . . . . . . . . . . . 88
5.2. Класифікація CASE-засобів . . . . . . . . . . . . . . . . . . . . . . . 90
5.3. Характеристика методологій моделювання даних . . . . . . 93
5.3.1. Характеристика методології ERD . . . . . . . . . . . . . . 93
5.3.2. Характеристика методології IDEF1X . . . . . . . . . . . 96
5.4. Засоби інформаційного моделювання. . . . . . . . . . . . . . . . 98
5.4.1. S-Designor — засіб інформаційного моделювання . 98
5.4.1.1. Загальна характеристика S-Designor . . . . . . 98
5.4.1.2. Опис зв’язків між об’єктами в S-Designor . 101
5.4.1.3. Порядок інформаційного моделювання в S-
Designor . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.1.4. Проектування сутностей та атрибутів . . . . 104
5.4.1.5. Встановлення зв’язків . . . . . . . . . . . . . . . . 106
5.4.1.6. Створення тригерів і процедур, що зберіга-
ються . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.4.2. ERwin — засіб інформаційного моделювання . . . 109
5.4.2.1. Загальна характеристика ERwin . . . . . . . . 109
5.4.2.2. Характеристика інструментів ERwin. . . . . 112
5.4.2.3. Створення логічної моделі даних . . . . . . . 113
5.4.2.4. Фізичне проектування засобами ERwin . . . . 127
Розділ 6. Створення та робота з базою даних у середовищі СКБД
Microsoft Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.1. Характеристика СКБД Microsoft Access . . . . . . . . . . . . . 135
6.2. Типи даних в ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3. Створення бази даних . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.4. Таблиці в ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4.1. Створення таблиць . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4.2. Редагування структури таблиці . . . . . . . . . . . . . . . 145
6.4.3. Введення, редагування та вилучення записів із табли-
ці . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

344
 6.4.4. Пошук даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.4.5. Створення індексів . . . . . . . . . . . . . . . . . . . . . . . . 147
6.4.6. Встановлення зв’язку між таблицями . . . . . . . . . . 150
6.5. Запити в Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.5.1. Типи запитів . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.5.2. Запити за зразком . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.5.3. Створення запиту-вибірки . . . . . . . . . . . . . . . . . . 160
6.5.4. Запити з обчисленнями . . . . . . . . . . . . . . . . . . . . . 160
6.5.5. Групувальні запити . . . . . . . . . . . . . . . . . . . . . . . . 162
6.5.6. Запити вилучення . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.5.7. Запити оновлення . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.5.8. Запити для впорядкування записів таблиць . . . . . 166
6.5.9. Запити з параметрами . . . . . . . . . . . . . . . . . . . . . . 166
6.5.10. Перехресні запити . . . . . . . . . . . . . . . . . . . . . . . . 168
6.5.11. Запити на створення нових таблиць . . . . . . . . . . 169
6.5.12. Оптимізація запитів. . . . . . . . . . . . . . . . . . . . . . . 170
6.6. Форми в Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.6.1. Створення форм на базі однієї таблиці . . . . . . . . . 171
6.6.2. Створення підпорядкованих та зв’язаних форм . . 175
6.6.3. Розробка зовнішнього вигляду форм . . . . . . . . . . 179
6.6.4. Створення додаткових елементів форми. . . . . . . . 181
6.6.5. Управління безпомилковим введенням форм . . . . 182
6.6.5.1. Створення прапорців . . . . . . . . . . . . . . . . 182
6.6.5.2. Створення групи перемикачів . . . . . . . . . 183
6.6.5.3. Створення полів зі списком . . . . . . . . . . . 185
6.6.6. Елементи управління, які обчислюються . . . . . . . 187
6.6.7. Гіперпосилання у формах . . . . . . . . . . . . . . . . . . . 190
6.6.8. Створення макроса у формі. . . . . . . . . . . . . . . . . . 192
6.7. Звіти в Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.7.1. Порядок створення звітів . . . . . . . . . . . . . . . . . . . 193
6.7.2. Створення звітів на базі форми . . . . . . . . . . . . . . . 196
6.7.3. Створення складних звітів . . . . . . . . . . . . . . . . . . 197
6.8. Макроси в Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6.9. Адміністрування та захист в Access . . . . . . . . . . . . . . . . 201
6.9.1. Стиснення і відновлення файлів баз даних . . . . . . 201
6.9.2. Шифрування і дешифрування файлів баз даних. . . . 202
6.9.3. Створення файлів MDE . . . . . . . . . . . . . . . . . . . . . 203
6.9.4. Підвищення продуктивності бази даних за допомогою
аналізатора швидкості дії . . . . . . . . . . . . . . . . . . . 204
6.9.5. Захист даних в Access . . . . . . . . . . . . . . . . . . . . . . 204

Розділ 7. Характеристика мови SQL. . . . . . . . . . . . . . . . . . . . . . . . 216

7.1. Загальна характеристика мови SQL . . . . . . . . . . . . . . . . 216
7.2. Порівняльна характеристика мови Jet SQL з ANSI SQL. . . 217

345
 7.3. Мова опису даних DDL. . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.3.1. Оператор CREATE TABLE . . . . . . . . . . . . . . . . . . 220
7.3.2. Опція CONSTRAINT . . . . . . . . . . . . . . . . . . . . . . . 220
7.3.3. Оператор CREATE INDEX . . . . . . . . . . . . . . . . . . 222
7.3.4. Оператор ALTER TABLE . . . . . . . . . . . . . . . . . . . 223
7.3.5. Оператор DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.4. Мова запиту даних DQL . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.4.1. Оператор SELECT . . . . . . . . . . . . . . . . . . . . . . . . 224
7.4.1.1. Речення FROM. . . . . . . . . . . . . . . . . . . . . 226
7.4.1.2. Речення GROUP BY. . . . . . . . . . . . . . . . . 226
7.4.1.3. Речення HAVING. . . . . . . . . . . . . . . . . . . 227
7.4.1.4. Речення ORDER BY. . . . . . . . . . . . . . . . . 227
7.4.1.5. Опція WITH OWNERACCESS OPTION. . . 228
7.4.2. Оператор SELECT...INTO . . . . . . . . . . . . . . . . . . . 229
7.5. Мова маніпулювання даними DML . . . . . . . . . . . . . . . . 229
7.5.1. Оператор INSERT INTO . . . . . . . . . . . . . . . . . . . . 230
7.5.2. Оператор UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 231
7.5.3. Оператор DELETE. . . . . . . . . . . . . . . . . . . . . . . . . 232
7.5.4. Операція JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
7.5.5. Операція UNION . . . . . . . . . . . . . . . . . . . . . . . . . . 235
7.5.6. Опис PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . 237
Розділ 8. Розподілені бази даних . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.1. Поняття розподіленої бази даних . . . . . . . . . . . . . . . . . . 239
8.2. Особливості та види розподілених систем . . . . . . . . . . . 240
8.3. Переваги і недоліки розподілених систем . . . . . . . . . . . 241
8.4. Стратегії розподілу даних. . . . . . . . . . . . . . . . . . . . . . . . 242
8.5. Характеристика розподілених СКБД . . . . . . . . . . . . . . . 244
8.6. Особливості проектування розподілених баз даних . . . . 246
8.7. Вимоги до розподілених систем . . . . . . . . . . . . . . . . . . . 247
8.8. Особливості технології роботи з розподіленою базою даних250
8.8.1. Управління одночасним доступом до бази даних . . . 250
8.8.2. Трансакції та механізм їх підтримки . . . . . . . . . . . 252
8.8.3. Управління відновленням розподілених баз даних 258
Розділ 9. Концепція побудови сховищ даних . . . . . . . . . . . . . . . . . 260
9.1. Характеристика трансакційних та аналітичних систем . . . 260
9.2. Поняття сховищ даних та передумови їх створення . . . . 262
9.3. Основні характеристики сховищ даних . . . . . . . . . . . . . 265
9.4. Характеристика основних компонент сховища даних . . . . 267
9.5. Архітектура сховищ даних . . . . . . . . . . . . . . . . . . . . . . . 269

Розділ 10. Моделі сховищ даних та особливості їх проектування 277

10.1. Багатовимірна модель. . . . . . . . . . . . . . . . . . . . . . . . . 277
10.2. Реляційна модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

346
 10.3. Відмінності проектування сховищ даних від проектуван-
ня баз даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
10.4. Підходи до проектування сховищ даних . . . . . . . . . . 285
10.5. Визначення основних елементів сховища даних . . . . 287
10.5.1. Визначення та вимоги до змінних. . . . . . . . . . 288
10.5.2. Визначення ступеня деталізації змінних. . . . . 290
10.5.3. Визначення та вимоги до вимірів . . . . . . . . . . 291
10.5.4. Визначення та вимоги до фактів . . . . . . . . . . . 294
10.6. Вимірне моделювання сховищ даних . . . . . . . . . . . . . 296
10.7. Визначення метаданих при проектуванні сховищ даних305
10.8. Автоматизація проектування сховищ даних. . . . . . . . 311
Розділ 11. Основи побудови інформаційних систем на базі сховищ
даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
11.1. Аналітичні системи на базі сховищ даних . . . . . . . . . 319
11.2. Cховища даних і технологія DATA MINING . . . . . . . 322
11.3. Основи побудови інформаційних систем на базі сховищ
даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Список літератури . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

347