Інформаційні системи та субд

ІНФОРМАЦІЙНІ СИСТЕМИ ТА СУБД

Історія розвитку

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

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

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

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

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

 

Моделі даних

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

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

Рис. 1 – Ієрархічна модель даних

ANSI (American National Standards Institute) пропонує виділяти три рівні архітектури СУБД: зовнішня модель - концептуальна модель - БД (фізична модель)

Рис. 2

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

На рис.1 приведена загальна ієрархія моделей даних (див. [1]). Рисунок 2 відображає тимчасові рамки розвитку СУБД.

РЕЛЯЦІЙНА МОДЕЛЬ ДАНИХ

Тип даних

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

Домен

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

 

Рис. 5

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

Слід зазначити також семантичне навантаження поняття домену: дані вважаються порівнянними (тета-порівнюваними) лише у тому випадку, коли вони відносяться до одного домену, а не до одного базового типа.

Відношення

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

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

Схема бази даних - це набір іменованих схем відношень.

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

Відношення - це множина кортежів, відповідних одній схемі відношення.

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

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

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

Реляційна база даних - це набір відношень, імена яких збігаються з іменами схем стосунків в схемі БД.

 

Властивості відношень

Тепер дамо теоретико-множинний опис поняття відношення.

DEF. N-арним відношенням R називають підмножину декартової похідної D_1 X D_2 X … X D_N множин D_1, D_2, …, D_N (N>=1), необов’язково різних.Вихідні множини D_1, D_2, …, D_N називаються доменами.

Коротко обговоримо витікаючі з цього визначення фундаментальні властивості відношень.

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

 

Рис. 6

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

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

ü Відсутність впорядкованості кортежів також є наслідком визначення відношення-екземпляра як множина кортежів. Відсутність вимоги до підтримки порядку на множині кортежів відношення дає додаткову гнучкість СУБД при зберіганні баз даних в зовнішній пам'яті і при виконанні запитів до бази даних.

ü Відсутність впорядкованості атрибутів. Для посилання на значення атрибуту в кортежі відношення завжди використовується ім'я атрибуту.

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

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

Відношення, що знаходиться в 1НФ, також називають універсальним або нормалізованим відношенням. Приклад ненормалізованного відношення наведено в табл. 1.

Таблиця 1

Кафедра	Тел.	Особистий номер	Прізвище	Посада	Оклад	Назва предмета	К-сть годин
МО ЕОМ	4-89		Фролов	доцент	380 руб.	СПО БКС	36 72
	Костін	доцент	380 руб.	Алгебра
ПМ	4-88		Бойко	професор	520 руб.	Алгебра
Фізики	4-12		Глазов	асистент	270 руб.	Фізика Оптика	52 30

 

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

 

Нормальна форма Бойса-Кодда

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

DEF. Відношення знаходиться в НФБК тоді і лише тоді, коли воно знаходиться в 3НФ, і кожен його детермінант є так само і можливим первинним ключем.

Відношення ВИКЛАДАЧ_ПРЕДМЕТ не знаходиться в НФБК. Для доказу порівняємо можливі ключі і детермінанти (таблиця. 3).

Проте РБД ВИКЛАДАЧ_ПРЕДМЕТ, що складається з шести відношень, знаходиться в НФБК, оскільки кожне її відношення знаходиться в НФБК (див. таблиці. 4).

Таблиця 3

Можливі ключі	Детермінанти
<Назва предмету, Особистий номер>	<Назва предмету>
	<Посада>
	<Кафедра>
	<Особистий номер>
	<Телефон>

 

Таблиця 4

Відношення	Можливі ключі	Детермінанти
ПРЕДМЕТ	<Назва предмету>	<Назва предмету>
ТАРИФНА_СІТКА	<Посада>	<Посада>
ТЕЛ_ДОВ1	<Кафедра>	<Кафедра>
ВИКЛАДАЧ	<Особистий номер>	<Особистий номер>
ТЕЛ_ДОВ2	<Телефон>	<Телефон>
НАВАНТАЖЕННЯ	<Назва предмету, Особистий номер>	<Назва предмету, Особистий номер>

 

Може здатися, що будь-яке відношення, що знаходиться в 3НФ знаходиться і в НФБК. Проте це не так. Приклади слід шукати у відношеннях з декількома можливими первинними ключами.

Розглянемо процес здачі студентом сесії. Структура відношення, що відображує це явище, може мати вигляд:

УСПІШНІСТЬ = <№Зал.Кн., ID_студента, Дисципліна, Дата, Оцінка>

Під ID_студента розуміється деякий номер, який привласнений студентові під час вступу, наприклад, в деканаті (залікова книжка може бути загублена, видана нова з іншим номером, а ID не міняється протягом всього періоду навчання).

Структура ФЗ в цьому випадку зображена на рис. 8.

Множина ВПК: {<№Зал.Кн.>, < ID_студента >}

У відношенні успішність немає ні функціонально неповних, ні транзитивних залежностей. Дійсно, взаємно-однозначна ФЗ №Зал.Кн. ID _Студента не може бути ідентифікована як неповна, оскільки не є залежністю між неключовими атрибутами.

Рис. 8

Таким чином, відношення УСПІШНІСТЬ знаходиться в 3НФ. В той же час воно не знаходиться в НФБК, оскільки безліч ВПК і Детермінантів не збігається (таблиця. 5).

Таблиця 5

Можливі ключі	Детермінанти
<№Зал.Кн., Дисципліна, Дата>	<№Зал.Кн., Дисципліна, Дата>
<ID_студента, Дисципліна, Дата>	<ID_студента, Дисципліна, Дата>
	<ID_студента>
	<№Зал.Кн.>

 

Щоб привести відношення УСПІШНІСТЬ до НФБК слід розділити його два одним з наступних способів:

СТУДЕНТ1 = < №Зал.Кн., ID_студента >

УСПІШНІСТЬ = < №Зал.Кн., Дисципліна, Дата, Оцінка>

або

СТУДЕНТ2 = < ID_студента, №Зал.Кн.>

УСПІШНІСТЬ = < ID_студента, Дисципліна, Дата, Оцінка>

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

Відзначимо, що у будь-якому випадку ми відмовилися від одного з напрямів взаємно-однозначної відповідності, інакше нам було б потрібно обидва відношення СТУДЕНТ1 і СТУДЕНТ2.

 

Правила виводу

Визначення транзитивності і концепція додавання торкаються три правил виводу з шести. Ці правила використовуються для спрощення вихідного набору ФЗ. Розглянемо ще три правила:

1. Об’єднання ФЗ: Якщо А→В і А→С, то А→В,С.

2. Декомпозиція ФЗ: Якщо А→В,С, то А→В і А→С.

3. Псевдотранзитивність: Якщо А→В і В,С→Z, то А,С→ Z.

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

А) Вихідний набір ФЗ.

Б) B, C → D видалена (додавання B → C)

В) А → B, C заміщена А → B & А → C (декомпозиція)

Г) А → C і А → D заміняються на А → К & К → C і А → B & В → D (транзитивність).

Мінімальне покриття

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

 

Рис. 12

 

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

 

Алгоритм проектування

1. Побудувати універсальне відношення для БД.

2. Визначити всі ФЗ, існуючі між атрибутами універсального відношення.

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

4. Використовувати ФЗ з мінімального покриття для декомпозиції універсального відношення в набір НФБК-відношень. При цьому застосовується загальний алгоритм декомпозиції.

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

6. Після завершення процесу проектування, отриманий набір необхідно проконтролювати на предмет наявності не виявлених проблем:

- одна і та ж ФЗ не повинна з'явитися більш ніж в одному відношенні;

- набір ФЗ в отриманих стосунках повинен в точності збігатися з мінімальним покриттям;

- не повинно бути надлишкових відношень.

Відношення надлишкове якщо:

- всі атрибути його можуть бути знайдені в одному іншому відношенні;

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

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

 

Перетворення сутностей

1. Кожній сутності ставиться у відповідність відношення.

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

3. Первинний ключ сутності стає ПК відношення (PRIMARY KEY). Атрибути, що входять в ПК, набувають властивості обов’язковості (NOT NULL) і унікальності (UNIQUE).

Перетворення зв’язків

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

КОНЦЕПТУАЛЬНОЇ МОДЕЛІ

Вище ми отримували РБД ВИКЛАДАЧ_ПРЕДМЕТ на основі концепції функціональної залежності. Інший підхід до проектування розглянемо на цій же моделі.

В наочній області можна виділити наступну суть і відповідні ним атрибути (ключі суті підкреслені).

При цьому спостерігаються наступні зв'язки між суттю.

1. ВИКЛАДАЧ - ПРЕДМЕТ: тип зв'язку *:*, клас приналежності обох суті - обов'язковий. Кожен Викладач повинен вести хоч би один Предмет. Кожен Предмет повинен вестися хоч би одним Викладачем. Крім того, даний зв'язок має атрибут зв'язку, що характеризує кількість годинника, яка веде викладач по предмету. Цей атрибут відмінний від загальної кількості годинника, що відводиться на вивчення конкретного предмету.

2. ВИКЛАДАЧ - КАФЕДРА: тип зв'язку 1:* (уважно розглянете діаграму!), клас приналежності обох суті - обов'язковий. На кожній Кафедрі повинен працювати хоч би один Викладач. Кожен Викладач повинен працювати лише на одній Кафедрі.

3. ВИКЛАДАЧ – ТАРИФНА_СІТКА: тип зв'язку 1:*, клас приналежності суті ВИКЛАДАЧ - обов'язковий, суть ТАРИФНА_СІТКА - необов'язковий. Кожен Викладач повинен мати лише одну Посаду. На кожному Посаді можуть працювати декілька ВИКЛАДАЧІВ.

Відповідна концептуальна модель даних змальована на малюнку 13.

Перетворимо отриману модель в РБД. Згідно з правилом перетворення суті, кожній суті заведемо по відношенню. Ключі суті стануть первинними ключами своїх стосунків. Маємо:

ВИКЛАДАЧ = < Особистий №, Прізвище>;

КАФЕДРА = < Назва, Телефон>;

ПРЕДМЕТ = < Назва, К-сть годин>;

ТАРИФНА_СІТКА = < Посада, Оклад>.

 

Рис. 13

Ці таблиці прийнято називати довідниками. Відмітимо, що оскільки ми не вводили суть ТЕЛЕФОН, то проблеми з взаємно-однозначною залежністю не існує. Телефон є атрибутом суті КАФЕДРА. Таке трактування наочної області допускає наявність паралельних підключень телефонів.

Згідно з правилом перетворення зв'язків один-до-одного з обов'язковим класом приналежності з боку багатозв'язкової суті, ключі суті КАФЕДРА і ТАРІФНАЯ_СЕТКА мають бути додані у відношення ВИКЛАДАЧ як зовнішні ключі:

ВИКЛАДАЧ = < Особистий №, Прізвище, Назва_кафедри (FK)>.

Згідно з правилом перетворення зв'язків многие-ко-багатьом в реляційну модель слід додати відношення зв'язки, що складаються з ключів суті ВИКЛАДАЧ і ПРЕДМЕТ, а так само атрибуту зв'язку К-сть_годин:

НАВАНТАЖЕННЯ = < Особистий №, Назва (FK), Навантаження (FK)>.

Повна схема РБД наведена на рисунку 14.

Звернете увагу на спосіб розкриття не бажаного в реляційній моделі зв'язку типа «багато до багатьох» шляхом створення додаткової таблиці зв'язку. Це є завуальованим методом переходу від зв'язків типа «багато до багатьох» до зв'язків «один до багатьох».

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

Рис. 14

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

 

 

ЛАБОРАТОРНИЙ ПРАКТИКУМ

ПО ПРОЕКТУВАННЮ РБД

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

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

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

Варіант 1

Розробити концептуальну модель БД роботи цеху. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

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

 

Варіант 2

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

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Видати короткий опис стилю, в якому працює виконавець А? Скільки у фонотеці сольних СП, а скільки збірок? Які композиції колекції записані різними виконавцями? Що нового в колекції?

 

Варіант 3

Розробити концептуальну модель БД каталогу комп’ютерних компакт-дисків. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

Диски діляться на 2 типи - ігрові і прикладні. Ігри характеризуються назвою стилю ("квест", "аркада", "стратегія" і ін.), прикладні програми діляться на транслятори, редактори, ел. таблиці, СУБД і.т.д.). Ігри характеризуються назвою, роком випуску, країною-виробником. Необхідно знати системні вимоги, що пред'являються як іграми, так і ППО.

БД повинна уміти відповідати на питання, подібні наступним.

Видати короткий опис стилю гри А? Скільки в колекції ігор, а скільки найменувань ПО? Які версії транслятора С++ є в колекції? Які вимоги до найостаннішої? Найранішою? Що нового в колекції ігор?

Варіант 4

Розробити концептуальну модель БД обліку садових посадок. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки сортів персиків в саду А? Скільки дерев в середньому гине в рік в саду В? Який середній вік яблунь? На скількох сливах щеплено по декілька сортів?

 

Варіант 5

Розробити концептуальну модель БД малого банка. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки поточних рахунків в банку? Скільки ощадних рахунків? Скільки клієнтів? У скількох клієнтів декілька поточних рахунків? Який відсоток ощадних рахунків, з балансом вище $1000?

 

Варіант 6

Розробити концептуальну модель даних роботи фірми-виробника. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки видів продукції А випускає фірма? Конкретний завод? Скільки видів продукції розроблено в КБ 2 за останній рік? Скільки розробок не закінчено? Скільки закінчилося невдачею? На яку суму завод У випустив продукції В за звітний період? Отримати список ФІО і робочих телефонів керівників всіх підрозділів фірми?

 

Варіант 7

Розробити концептуальну модель даних обліку книг в бібліотеці. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки читачів користуються бібліотекою? Скільки книг знаходиться на руках? Скільки книг знаходиться на руках у конкретного читача? Які це книги? Які книги даного автора є в бібліотеці? Скільки з них в со-авторстві? Скільки творів даного автора увійшло до збірок? Скільки книг даної тематики є в бібліотеці?

 

Варіант 8

Розробити концептуальну модель деканату. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

На факультеті читається деяка кількість курсів. Курс передбачає наявність лекцій, лабораторних і практичних робіт. Один курс може читатися лише одним викладачем, але практичні і лабораторні роботи можуть вести декілька викладачів. Кожен викладач може читати декілька курсів, вести лише практики або лабораторні. Студенти діляться на групи. Кожна група слухає одні і ті ж курси, і кожен курс може слухати декілька груп.

БД повинна уміти відповідати на питання, подібні наступним.

Скільки студентів вчиться на факультеті? Скільки курсів читає викладач А? Скільки він веде практичних занять? Скільки лабораторних? Які це курси? Які курси вивчає студент В? Група С? Скільки годин відводиться на викладання дисципліни Д?

 

Варіант 9

Розробити концептуальну модель будівельної компанії. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Хто з робітників в яку бригаду, на якій будівлі призначений? Який у нього оклад? Який графік робіт на будівлі А (хто і коли і який період часу там повинен працювати)? Які матеріали потрібні при зведенні будівлі В?

 

Варіант 10

Розробити концептуальну модель кулінарної книги + меню ресторана. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки інгредієнтів необхідно для приготування блюда А? Яких? Як блюдо готується? Хто поставляє продукт Би за найбільш вигідною ціною? Яка калорійність замовленої вечері? А яка його ціна? Що можна приготувати з буряка? А з моркви і свинини разом?

Варіант 11

Розробити концептуальну модель обліку результатів олімпіади по програмуванню. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.

Скільки учасників в особистому заліку? Скільки команд? Хто в якій команді? У якому місті знаходиться ВУЗ переможця? Скільки балів набрав переможець? А чи перемогла його команда? Команда якого Вузу перемогла в першому турі? У скількох турах перемогла яка-небудь команда з м. Києва?

 

Варіант 12

Розробити концептуальну модель рекламного агенства. По отриманій моделі побудувати БД. Показати, що отримана БД знаходиться у формі Бойса-Кодда. Якщо це не так, виконати нормалізацію.

Опис наочної області:

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

БД повинна уміти відповідати на питання, подібні наступним.