Лекція 7.

5. Проектування бд

Этапы проектирования

Построение концептуальной модели предметной области

Логическое проектирование базы данных

Нормализация отношений

Автоматизированные технологии проектирования баз данных

Заключение

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

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

У процесі проектування баз даних часто виділяють три етапи.

Етап 1. Побудова концептуальної моделі предметної області.

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

Етап 2. Логічне проектування - перетворення створеної концептуальної моделі в концептуальну схему, реалізовану конкретною СУБД.

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

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

Етап 3. Фізичне проектування бази даних.

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

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

Розглянемо деякі засоби концептуального моделювання.

ER-модель

ER-модель (Entity-Relationship - сутність-зв'язок) була запропонована П. Ченом в 1976 р. [12]. Інформація про зміст предметної області в рамках моделі зображується в структурованому графічному вигляді (ER-діаграма).

Основними конструкціями моделі є сутності та зв'язки.

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

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

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

Сутності мають властивості, звані атрибутами. Атрибути повинні дозволяти розрізняти екземпляри сутності. Наприклад, для сутності Магазин атрибутами є його назва, адреса, спеціалізація, площа торгових залів і т. д. На ER-діаграмі атрибути зображаються овалами, в яких вказані їхні імена, з'єднаними з сутностями прямими лініями.

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

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

Зв'язки можуть мати різний характер:

• «один до одного» (1: 1) - один примірник сутності Директор пов'язаний з одним екземпляром сутності Магазин;

• «один до багатьох» (1: М) - один примірник сутності Директор пов'язаний з багатьма екземплярами сутності Продавець;

• «багато до багатьох» (М: М) - багато екземпляри сутності Продавець пов'язані з багатьма екземплярами сутності Товар.

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

Зв'язок будь-якого з перерахованих видів може мати обов'язковий і необов'язковий класи приналежності.

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

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

При побудові ER-діаграм можуть використовуватися генералізація, агрегація і угрупування сутностей [3, 12].

На рис. 15 представлений фрагмент ER-діаграми, що відображає роботу магазину.

Сутність Працівник має два підтипи - Директор і Продавець. Між сутностями Магазин й Працівник зв'язок має характер «один до багатьох» (один магазин обслуговується багатьма працівниками), між сутностями Директор і Продавець - «один до багатьох» (один директор керує багатьма продавцями), між сутностями Продавець і Товар - «багато до багатьох »(кілька продавців продає безліч різних товарів). Клас приналежності більшості зв'язків є обов'язковим. Він є необов'язковим для зв'язку фасує між сутностями Продавець і Товар з боку сутності Продавець (не кожен продавець фасує товари) (див. рис. 15).

Функціональна модель даних

Ця модель була запропонована Шіпменом в 1981 р. [12].

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

Рис. 15. Фрагмент ER-диаграммы, отображающей работу магазина

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

Діаграми функціональної моделі даних багато в чому аналогічні ER-діаграм, але зв'язки між ними представлені у вигляді функцій [12].

Модель семантичних об'єктів

Модель вперше запропонована Кренке в 1988 р. [12].

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

Розглянемо діаграми семантичних об'єктів Магазин, Продавець, Товар (рис. 16):

			Продавец ID  ИНН      1, 1 ФИО            1, 1 Должность   1, 1 Адрес           1, 1 Магазин       1, N
					Товар ID  Артикул     1, 1 Название           1, 1 Цена                   1, 1 Производитель 1, N Цвет                   1, N Магазин             1, N

 

Рис. 16.  Диаграммы семантических объектов

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

Для кожного атрибуту вказана його кардинальність (мінімальна і максимальна кількість входжень цього атрибуту в об'єкт). Наприклад, якщо для атрибута Ціна об'єкта Товар наводиться кардинальність 1, 1, це означає, що товар обов'язково повинен мати ціну, і тільки одну. Атрибут Виробник об'єкта Товар має кардинальність 1, N. Це вказує на те, що один і той же товар може виготовлятися одним або декількома виробниками (див. рис. 16).

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

В об'єкті Магазин має групування атрибут Адреса. Атрибути, що входять до його складу, об'єднані дужкою (див. рис. 16).

В об'єкті Магазин існує також атрибут об'єктного типу Продавець з кардинальністю 1, N (див. рис. 16). Це вказує на те, що даний об'єкт пов'язаний з одним або декількома об'єктами Продавець (в магазині можуть працювати один або кілька продавців). Для забезпечення зв'язку між розглянутими об'єктами в об'єкт Продавець обов'язково повинен входити атрибут Магазин, який характеризує цей об'єкт (див. рис. 16). Діаграми семантичних об'єктів допускають створення агрегованих об'єктів, підкласів об'єктів [12].

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

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

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

Найбільш часто для вирішення перерахованих завдань використовується перехід до логічної моделі бази даних від концептуальної моделі, представленої у вигляді ER-діаграми [3, 4].

Існують методи однозначного перетворення ER-моделі в логічну модель реляційної бази даних. Ці методи покладені в основу роботи багатьох CASE-систем - інструментальних засобів автоматизованого проектування баз даних (див. п. 7.5).

Розглянемо основні правила перетворення ER-моделі в логічну модель бази даних на прикладі діаграми, побудованої на рис. 15 (для ілюстрації деяких правил будуть залучатися додаткові сутності і зв'язки між ними). Для наочності отриманих результатів заповнимо таблиці даними.

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

Таблица 7.1 Магазины

Название	Адрес	Специализация
Светлый	Мира, 14	Хозяйственные товары
Восток	Запарина, 2	Продовольственные товары
Факел	Фрунзе, 13	Хозяйственные товары

Якщо між двома сутностями є зв'язок «один до одного», а клас приналежності зв'язку для обох сутностей є обов'язковим, обидві сутності можна об'єднати в одну таблицю.

Первинним ключем таблиці може бути первинний ключ будь-якої сутності. Наприклад, є пов'язані суті Директор і Магазин. В кожному магазині є директор, і кожен директор керує тільки одним магазином. Таблиця, що включає атрибути сутностей Директор і Магазин, може виглядати наступним чином (табл. 7.2):

Таблица 7.2 Магазины

Название	Адрес	Специализация	Директор	ИНН
Светлый	Мира, 14	Хозяйственные товары	Деев О.И.	27213456
Восток	Запарина, 2	Промышленные товары	Стогов П.И.	27243212
Факел	Фрунзе, 13	Хозяйственные товары	Репина О.Г.	27231217

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

Розглянемо зв'язок між сутностями Магазин й Автомобіль. Припустимо, лише деяким магазинам («Світлий», «Схід») належить автомобіль (тільки один). У інших магазинів («Факел») автомобіля немає (клас приналежності зв'язку для сутності Магазин є необов'язковим). Кожен автомобіль є власністю деякого магазину (клас приналежності зв'язку для сутності Автомобіль є обов'язковим). Таблиця з інформацією про магазини буде ідентична табл. 7.1, а таблиця з інформацією про автомобілі буде мати наступний вигляд (табл. 7.3):

Таблица 7.3 Автомобили

Номер	Марка	Водитель	Адрес магазина
Х 123 МН	ЗИЛ-130	Андреев Р.С.	Мира, 14
Х 234 РТ	ГАЗ-66	Реутов С.П.	Запарина, 2

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

У ситуації, коли клас приналежності сутності, яка знаходиться з боку «багато», обов'язковий, достатньо створити дві таблиці. Ключ таблиці, що знаходиться з боку «один», повинен бути доданий в таблицю, що знаходиться з боку «багато».

Розглянемо зв'язок «один до багатьох» між сутностями Магазин й Працівник (див. рис. 15). Клас приналежності зв'язку для сутності Працівник є обов'язковим. Таблиця з інформацією про магазинах буде мати вигляд, ідентичний табл. 7.1, таблиця з інформацією про працівників буде включати ключ таблиці Магазин (табл. 7.4):

Таблица 7.4 Работники

ИНН	ФИО	Должность	Адрес	Адрес магазина
27212367	Фомин Л.М.	продавец	Боровая, 16	Мира, 14
27233319	Цыпин Л.Е.	продавец	Мира, 33	Запарина, 2
27254322	Гейт Ф.П.	грузчик	Осиновая, 5	Фрунзе, 13
27265413	Ревва С.Р.	кассир	Мира, 67	Мира, 14

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

Розглянемо зв'язок «багато до багатьох» між сутностями Продавець і Товар. Таблиця Продавці може мати структуру, збігатися зі структурою таблиці Працівники (див. табл. 7.4), таблиця Товари буде мати вигляд (табл. 7.5):

Таблица 7.5 Товары

Артикул	Название	Цена, руб.
100	Туфли	5 000
200	Сапоги	7 000
300	Костюм	10 000
400	Костюм	8 000

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

Таблица 7.6 Продажи

ИНН	Артикул
27212367	100
27212367	300
27233319	100
27233319	400

Розглянуті правила перетворення ER-моделі в логічну модель бази даних досить прості, наочні і дозволяють отримати добрі результати.

Нормалізація відносин

Нормалізація відносин забезпечує ефективність структур даних в реляційній БД [12]. Цей процес зменшує надмірність даних (зберігання однакових даних в декількох місцях). В результаті раціональніше використовується зовнішня пам'ять, зменшується ймовірність порушення узгодженості даних.

Нормалізація являє собою дії по послідовному перетворенню початкової (ненормалізованої) таблиці в нормалізовані відносини в першій нормальній формі (1НФ), 2НФ, 3НФ, нормальній формі Бойса-Кодда (НФБК), 4НФ, 5НФ [2].

Основні властивості нормальних форм:

1. кожна наступна нормальна форма покращує властивості попередньої нормальної форми;

2. при переході до наступної нормальної форми властивості попередніх нормальних форм зберігаються.

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

Розглянемо таблицю, в якій міститься інформація про поставки товарів торговельному підприємству (табл. 7.7):

Таблица 7.7 Товары

Название товара	Артикул	Количество	Цена, руб.	Дата поставки	Поставщик	Способ доставки
Костюм	500	100	10 000	10.12.05	Янтарь	а/т
Сапоги	200	75	5 000		Факел	ж/д
Туфли	100	120	4 000	11.12.05	Янтарь	а/т
Костюм	500	100	10 000
	300	50	5 000	12.12.05
	400		4 000		Остон	ж/д
Туфли	100	100			Янтарь	а/т

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

Наведемо вихідну таблицю до виду (табл. 7.8):

Таблица 7.8 Товары

Название товара	Артикул	Количество	Цена, руб.	Дата поставки	Поставщик	Способ доставки
Костюм	500	100	10 000	10.12.05	Янтарь	а/т
Сапоги	200	75	5 000	10.12.05	Факел	ж/д
Туфли	100	120	4 000	11.12.05	Янтарь	а/т
Костюм	500	100	10 000	11.12.05	Янтарь	а/т
Костюм	300	50	5 000	12.12.05	Янтарь	а/т
Костюм	400	50	4 000	12.12.05	Остон	ж/д
Туфли	100	100	4 000	12.12.05	Янтарь	а/т

В результаті буде отримано відношення в першій нормальній формі.

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

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

Отримане відношення відповідає правилам реляційної теорії, але очевидно, що в ньому міститься багато надлишкової інформації (див. табл. 7.8).

Для цього відношення вельми трудомісткими є операції оновлення даних.

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

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

За визначенням атрибут Y відносини R функціонально залежить від атрибуту X відносини R, коли кожне значення X у відношенні R в кожен момент часу пов'язано тільки з одним значенням Y (атрибут X функціонально визначає атрибут Y) [2].

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

Таблица 7.9 Номенклатура товаров

Название товара	Артикул	Цена, руб.	Поставщик	Способ доставки
Костюм	500	10 000	Янтарь	а/т
Сапоги	200	5 000	Факел	ж/д
Туфли	100	4 000	Янтарь	а/т
Костюм	300	5 000	Янтарь	а/т
Костюм	400	4 000	Остон	ж/д

Таблица 7.10 Поставки

Артикул	Количество	Дата поставки
500	100	10.12.05
200	75	10.12.05
100	120	11.12.05
500	100	11.12.05
300	50	12.12.05
400	50	12.12.05
100	100	12.12.05

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

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

Поділ відносин Товари на відносини Номенклатура товарів і Поставки не призводить до втрати інформації. Всі необхідні відомості можуть бути отримані з цих стосунків після їх зв'язування по ключових полях.

В результаті виконаних дій буде отримано відношення в другій нормальній формі.

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

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

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

Це є наслідком того, що є функціональна залежність між неключовими атрибутами: атрибут Спосіб доставки функціонально залежить від атрибуту Постачальник (див. табл. 7.9). Такі залежності називаються транзитивними (перехідними).

Для усунення транзитивної залежності у відношенні Номенклатура товарів, дане відношення необхідно розділити на два відношення (табл. 7.11 і 7.12):

Таблица 7.11 Договоры

Название товара	Артикул	Цена, руб.	Поставщик
Костюм	500	10 000	Янтарь
Сапоги	200	5 000	Факел
Туфли	100	4 000	Янтарь
Костюм	300	5 000	Янтарь
Костюм	400	4 000	Остон

Таблица 7.12 Доставка

Поставщик	Способ доставки
Янтарь	а/т
Факел	ж/д
Остон	ж/д

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

Відносини Договори і Доставка знаходяться в третій нормальній формі.

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

У більшості випадків досягнення третьої нормальної форми вважається достатнім для реальних проектів баз даних [12], однак в теорії нормалізації існують нормальні форми вищих порядків (НФБК, 4НФ, 5НФ), деякі з яких пов'язані вже не з функціональними залежностями між атрибутами відносин, а відображають більш тонкі питання смислового змісту предметної області [4].

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

Автоматизовані технології проектування баз даних

Засоби автоматизації проектування і розробки інформаційних систем, у тому числі і банків даних, з'явилися відносно недавно (перша версія CASE-системи фірми Oracle була представлена ​​в 1989 р.) [3].

Термін «CASE» (Computer Aided Software Engineering) дослівно перекладається як розробка програмного забезпечення за допомогою комп'ютера. У CASE-системи входять програмні засоби, що дозволяють виконувати аналіз предметної області та побудова її моделі, проектування баз даних, розробку додатків, генерацію кодів, тестування і т.д.

CASE-системи, застосовувані для проектування баз даних, можуть не залежати від СУБД або вбудовуватися в них. Незалежні системи не входять до складу конкретної СУБД і зазвичай підтримують кілька форматів баз даних через інтерфейс ODBC. В якості прикладів таких систем можна привести S-Designor (PowerDesignor) (фірми SDP, Powersoft), Erwin (LogicWorks), Silverrun (Computer Systems Advisers Inc.) [15]. Вбудовані CASE-системи в основному підтримують формат баз даних СУБД, складовою частиною якої вони є. Приклад вбудованої системи - Designer/2000 (СУБД Oracle однойменної фірми) [15].

Розглянемо деякі CASE-системи.

S-Designor (PowerDesigner). Ця система дозволяє за допомогою графічних засобів в деякій мірі автоматизувати процес проектування реляційних баз даних. Система працює з СУБД Oracle, MS Access, Ingress, Informix, Sybase, MS SQL Server і т. д.

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

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

База даних за допомогою системи може бути створена двома способами. У рамках першого з них необхідно підключитися до працюючого сервера СУБД через інтерфейс ODBC. Інший спосіб - формування текстових файлів (пакетів) SQL-операторів по створенню структури БД. База даних створюється після обробки цих файлів СУБД [15].

У версії PowerDesigner 6.0 реалізовано проектування багатовимірних інформаційних моделей для сховищ даних (див. Висновок) [3].

Erwin. Дана система в цілому близька за функціональними можливостями системі S-Designor (PowerDesigner), але вона менш універсальна і підтримується меншим числом СУБД. У системі є обмеження на розміри моделі (не більше 500 сутностей і 1500 атрибутів) [3].

Silverrun. Система працює з СУБД Oracle, Informix, Ingress, MS SQL Server і т. д. За допомогою системи можна будувати два види моделей: функціональні (у вигляді діаграм потоків даних) і інформаційні (діаграми типу «сутність - зв'язок», вживані для створення схем баз даних).

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

Designer/2000. Ця система є вбудованою в СУБД Oracle.

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

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

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

Досвід застосування CASE-систем для проектування баз даних дозволяє зробити наступні висновки:

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

2. Найбільш корисними CASE-системи є на початкових стадіях проектування.

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

4. У деяких ситуаціях доцільно використовувати декілька CASE-систем спільно. Це дозволяє об'єднати переваги цих систем і скоротити терміни проектування.

В той же час не можна не погодитися з точкою зору на розглянуту проблему С. М. Діго: «... жодна система автоматизації проектування, наскільки б розвиненою вона не була, не може гарантувати відповідності побудованої концептуальної моделі реаліям предметної області. Це визначається тільки кваліфікацією розробників, їх розумінням предметної області і вмінням адекватно відобразити її в моделі »[3]. Висновок

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

1. Одним з таких напрямків є створення «Сховищ даних» (Data Warehouse), що здійснюють функції попередньої підготовки й зберігання даних для систем підтримки прийняття рішень (СППР).

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

Рішення приймаються за допомогою аналітичного аналізу (пошуку наявних закономірностей) агрегованих (узагальнених) даних.

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

Для пошуку і вибірки даних в процесі роботи системи використовується стратегія, звана «оперативної аналітичної обробкою» (On-line Analytical Processing, OLAP).

OLAP-системи будуються на основі двох базових принципів:

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

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

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

Подальше ускладнення моделі даних може виконуватися такими способами:

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

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

3. Вводиться ієрархія в межах одного виміру. Наприклад, рік складається з кварталів, квартал з місяців, місяць з тижнів, тиждень із днів.

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

При роботі з гіперкуба можуть використовуватися дві стратегії.

1. У системах MOLAP (Multidimensional OLAP) гіперкуб реалізується як окрема база даних спеціально не реляційної структури, що забезпечує максимально ефективний по швидкості доступ до даних, але вимагає додаткових ресурсів пам'яті. Тому дані зі сховища спочатку поміщаються в спеціальну багатовимірну базу, а потім обробляються OLAP-сервером. Прикладами таких систем є Essbase (компанія Arbor Software) і Oracle Express (Oracle).

Для систем ROLAP (Relational OLAP) гіперкуб - це лише користувальницький інтерфейс, який емулюється на звичайній реляційної СУБД. У цій структурі можна зберігати дуже великі об'єми даних, однак її недолік полягає в низькій і неоднакової ефективності OLAP-операцій. Приклади таких систем - MetaCube (фірма Informix) і Discoverer 3.0 (Oracle). Для підготовки рішення в рамках OLAP-технології користувач аналізує зріз даних по одному або декільком вимірам.

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

Під вітриною даних розуміється спеціалізоване сховище даних, яке обслуговує тільки один з напрямків діяльності підприємства, наприклад, облік товарів. Для розробки такого сховища потрібно, щоб відбуваються в цій сфері бізнес процеси були відносно прості і досить добре вивчені. Приклади вітрин даних: PowerMart Suite (фірма Informatica), Data Mart Solution (Sagent Technology), DataMart Suite (Oracle).

Сховища і вітрини даних можуть використовуватися при інтелектуальному аналізі даних (ІАД), направленому на вирішення завдань пошуку залежностей між даними, прогнозування змін даних, аналізу аномалій - виявлення даних, що не відповідають наявним закономірностям.

2. Для обліку зміни характеристик об'єктів баз даних у часі можуть використовуватися темпоральні бази даних [4]. У реляційної БД для оцінки стану об'єкта в різні моменти часу може бути створено безліч однакових за структурою таблиць. Темпоральні БД використовують спеціальні механізми зняття зрізів за часом для певних об'єктів бази даних. При цьому користувачеві доступні всі стани об'єкта в період часу його існування [4].

3. Іншим перспективним напрямком застосування і розвитку баз даних є організація доступу до їх змісту через Інтернет.

Достоїнствами цього підходу є [7]:

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

2. Можливість стандартизації користувальницького інтерфейсу при зверненні до даних (використовуються кошти уніфікованої програми-оглядача).

3. Застосування для обміну даними в мережі протоколів (наприклад, HTTP), не залежних від платформ, що використовуються користувачами.

При розміщенні бази даних на Web-сторінках можуть бути застосовані способи статичної та динамічної публікації.

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

Динамічна публікація застосовується при зверненні до часто змінюваною інформацією і використовується, наприклад, при організації роботи інтернет-магазинів, систем бронювання місць у готелях і т. д. Web-сторінки формуються тільки після надходження на сервер запиту користувача. Для цього застосовуються різні засоби і технології: ASP, PHP і IDC/HTX- сторінки, програми розширення сервера (Java-сервлети, CORBA-об'єкти, ISAPI-модулі і т. д.) [7].

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