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

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

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

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

Існує кілька способів опису інфологичної моделі, проте на сьогодні одним з найбільш поширених підходів, що застосовуються в інфологічному моделюванні, є підхід, заснований на застосуванні діаграм "сутність – зв'язок" (ER – Entity Relationship).

41

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

Результатом створення даталогічної моделі є модель, створена з урахуванням обраної моделі даних, отримана шляхом перетворення інфологічної моделі з урахуванням певних правил.

Отже, даталогічна модель відображає структуру БД з урахуванням особливостей моделі даних [6].

Етап фізичного проектування БД в загальному випадку включає: вибір способу організації БД; розробку специфікації внутрішньої схеми;

опис відображення концептуальної схеми у внутрішню.

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

До питань організації даних належать:

вибір типу запису – одиниці обміну в операціях введення-виве- дення;

вибір способу розміщення записів у файлі і методу оптимізації розміщення;

вибір способу адресації та методу доступу до записів.

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

2.2. Логічне проектування баз даних. ER-діаграми

Головним завданням логічного проектування БД є подання визначених на попередньому етапі відомостей у вигляді даних у форматах, що

42

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

визначення в предметній області сутностей; введення множини атрибутів для кожної сутності та визначення

ключових серед них; виключення множини повторюваних атрибутів (за необхідності);

формування зв'язків між сутностями; виключення зв'язків типу М: 1 (за необхідності);

перетворення зв'язків в односпрямовані (у міру можливості). Інфологічна модель "сутність – зв'язок" (entity realationship model;

ER-model) П. Чена являє собою описову (неформальну) модель предметної області, що семантично визначає в ній сутності та зв'язки.

Відносна простота і наочність опису предметної області дозволяє використовувати її в процесі діалогу з потенційними користувачами із самого початку інфологічного проектування. Побудова інфологічної моделі П. Чена, як і будь-якої іншої моделі, є творчим процесом, тому єдиної методики її створення немає. Однак за будь-якого підходу до побудови моделі використовують три основних конструктивні елементи [6]:

сутність; атрибут; зв'язок.

Базовими елементами моделі "сутність – зв'язок" є сутності. Сутність (Entity) – множина екземплярів реальних або абстрактних

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

Сутність можна визначити як об'єкт, подію або концепцію, інформація про яких повинна зберігатися. Сутності повинні мати найменування з чітким смисловим значенням, іменуватися іменником в однині, не мати "технічних" найменувань. Іменування сутності в однині полегшує надалі читання моделі. Прикладом може бути сутність БАНК (але не БАНКИ) з

атрибутами номер банку, назва банку і адреса банку. Кожна сутність мо-

же мати будь-яку кількість зв'язків з іншими сутностями моделі.

Атрибут (Attribute) – будь-яка характеристика сутності, значуща для розглянутої предметної області і призначена для кваліфікації, іден-

43

тифікації, класифікації, кількісної характеристики або вираження стану сутності [27]. Атрибут є типом характеристик або властивостей, асоційованих із безліччю реальних або абстрактних об'єктів (людей, місць, подій, станів, ідей, предметів і т. д.) (рис. 2.1). Екземпляр атрибута – це певна характеристика окремого елемента множини. Екземпляр атрибута визначається типом характеристики і її значенням, так званим значенням атрибута. На діаграмі "сутність – зв'язок" атрибути асоціюються з конкретними сутностями. Таким чином, приклад сутності повинен мати єдине встановлене значення для асоційованого атрибута.

Прізвище	Ім’я	По батькові

Код клієнта

КЛІЄНТ

Стать

Дата народження

Рис. 2.1. Зображення атрибутів

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

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

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

44

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

Графічно зв'язок зображується лінією, що з'єднує дві сутності

(рис. 2.2):

ПРАЦІВНИК			ДИТИНА

ПРАЦІВНИК			ФІЛІЯ

Рис. 2.2. Зображення зв'язків між сутностями

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

Кожен зв'язок може мати один із наступних типів зв'язку (рис. 2.3): Зв'язок типу "один-до-одного" (рис. 2.4) означає, що один екземп-

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

Один-до-одного
					М
Один-до-багатьох
			М		N
Багато-до-багатьох
	а)			б)					в)

Рис. 2.3. Приклади позначення типів зв'язків

45

Зв'язок типу "один-до-багатьох" означає (рис. 2.5), що один екземпляр першої сутності (лівої) пов'язаний з декількома екземплярами другої сутності (правої). Це найбільш часто використовуваний тип зв'язку. Сутність з боку "один" називається батьківською, сутність з боку "багато" – дочірньою.

А В

С В

ПРАЦІВНИК				ФІЛІЯ

Рис. 2.4. Приклад відображення зв'язку "один-до-одного"

В

А С

D

Е

F

ПРАЦІВНИК				ДИТИНА

Рис. 2.5. Приклад відображення зв'язку "один-до-багатьох"

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

46

E

А

K

B

L

D

M

ПРАЦІВНИК ПРОФЕСІЯ

Рис. 2.6. Приклад відображення зв'язку

"багато-до-багатьох"

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

2.3. Види моделей даних

Одними з основоположних в концепції БД є узагальнені категорії "дані" і "модель даних".

Поняття "дані" в концепції БД – це набір конкретних значень, параметрів, що характеризують об'єкт, умову, ситуацію або будь-які інші фактори [6]. Дані не мають певної структури, вони стають інформацією тоді, коли користувач задає їм певну структуру, тобто усвідомлює їх смислове значення. Структура даних – це множина елементів даних і зв'язків між ними [27].

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

47

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

Модель даних – це сукупність взаємозалежних структур даних і операцій над цими структурами [23]. Таким чином, модель даних – це певна абстракція, яка після застосування до конкретних даних дозволяє користувачам і розробникам трактувати їх уже як інформацію, тобто відомості, що містять не тільки дані, але й взаємозв'язок між ними. На рис. 2.7 наведена класифікація моделей даних.

Моделі даних

	Інфологічні				Даталогічні			Фізичні

Діаграми

Модель

Документальні

Фактографічні

Засновані на

Засновані на

файлових

сторінко-

Бахмана

"сутність-зв'язок"

моделі

моделі

структурах

сегментній

організації

Орієнтовані на

Дескрипторні

Тезаурусні

Теоретико-

Теоретико-

Об’єктно-

формат

моделі

моделі

графові

множинні

орієнтовані

документа

Ієрархічні

Мережеві

Реляційні

Бінарних

асоціацій

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

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

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

48

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

Основна розбіжність у даних моделях полягає в поданні взаємозв'язків між об'єктами. Виділяють файлову, ієрархічну, мережеву та реляційну моделі даних [23; 27].

Файлова модель даних

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

Основні типи структур даних файлової моделі: поле, запис, файл. Запис є основною структурною одиницею обробки даних і одини-

цею обміну між оперативною і зовнішньою пам'яттю.

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

Первинний ключ (ПК) – це одне чи декілька полів, що однозначно ідентифікують запис. Якщо первинний ключ складається з одного поля, він називається простим, якщо з декількох полів – складним ключем.

Вторинний ключ (ВК) – це таке поле, значення якого може повторюватися в декількох записах файла, тобто він не є унікальним. Якщо за значенням первинного ключа може бути знайдений один єдиний екземпляр запису, то за вторинним – декілька [23; 60].

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

49

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

Опис організації даних файлової моделі здійснюється наступним чином:

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

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

		ІМ'Я ФАЙЛА			Ознака ключа
	ПОЛЕ			ФОРМА ПОЛЯ
Позначення		Найменування	Тип	Довжина		Точність

Рис. 2.8. Структура файла

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

Ієрархічна модель даних

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

Атрибут (елемент) даних – це мінімальна (неподільна) пойменована структурна одиниця даних (аналог поля у файлових моделях).

Агрегат даних – це пойменована підмножина атрибутів даних або інших агрегатів усередині запису.

Агрегат даних відповідає наступному рівню узагальнення в моделі. Агрегат даних має ім'я, і в системі допустиме звернення до агрегату на ім'я. У моделі виділяють агрегати двох типів: агрегат типу "вектор" і агрегат типу "повторювана група". Агрегат типу "вектор" відповідає лінійному набору елементів даних. Наприклад, агрегат "Адреса" може бути поданий таким чином (рис. 2.9):

50