Проектування РБД

1)зарахувати студента Петрова в групу Група3, тобто зарахувати нового студента в нову групу;

2)зарахувати студента Петрова в групу Група2, тобто зарахувати нового студента в існуючу групу.

Якщо працювати з таблицею Студенти2, то істотної різниці у виконанні цих задач немає. Для рішення кожної з задач необхідно виконати одну операцію: вставити запис у таблицю Студенти2. Отже, обидві задачі будуть виконуватися однаково.

Якщо ж працювати з таблицею Студенти1, то перша задача вимагає такої

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

Очевидно, що перетворення таблиці Студенти1 в таблицю Студенти2 спростило роботу з додаванням інформації. Але ж для роботи, крім додавання інформації, ще потрібно обновляти інформацію і вилучати її. Перетворення таблиці Студенти1 в таблицю Студенти2 спростило роботу і при таких операціях.

Повторимо операцію перетворення для всієї таблиці “Успішність”. Позбудемося підграф, кожному полю дамо власне ім'я. Залишимо назви полів Рік, Семестр, Спеціальність, Група. Продублюємо їх значення по записах.

Полям з анкетними даними привласнимо імена Прізвище, Ім'я, По батькові. Поля оцінок для стислості назвемо за загальною схемою "Дисципліна + Вид контролю", при цьому екзамен позначимо символом Е, а залік – З. Наприклад, для поля оцінок на заліку з дисципліни Д1 позначимо як Д1З. Аналогічним образом назвемо інші поля: Д3Е,Д12З,..., Д30Е. Фактично ми замінили назви дисциплін разом з видами контролю шифром.

Для спрощення подання матеріалу покажемо тільки 30 оцінок. У результаті перетворень ми отримаємо табл. 5.7.

Таблиця 5.7 – Перетворення таблиці “Успішність”

35

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

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

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

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

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

Ключ також називають унікальним ідентифікатором або просто ідентифікатором.

Нехай Т – таблиця з полями Р1, Р2, ..., Рn. Говорять, що множина полів K=(Рi, Рj, ..., Рk), що належать до структури таблиці Т, є ключем цієї таблиці тоді і тільки тоді, коли задовольняються дві незалежні від часу умови:

–унікальність, тобто у довільний заданий момент часу два різних записи таблиці Т не мають однакового значення для полів Рi, Рj, ..., Рk, що входять до ключа;

–мінімальність, тобто жодне з полів Рi, Рj, ..., Рk , що входять до ключа, не може бути виключене з нього без порушення унікальності.

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

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

Рядки в новій таблиці “Успішність” подають інформацію про успішність конкретного студента і повинні відрізнятися один від одного. А як відрізнити успішність двох студентів, у яких збігаються не тільки прізвище, але й ім'я, по батькові, і навчаються вони в одній групі? Видно, що у нашому прикладі два студенти з ПІБ Андрєєв А.А. навчаються в групі1. І навіть оцінки у них однакові!

Треба домогтись виконання властивості унікальності записів. Визначимо кожному студенту код і додамо в таблицю “Успішність” поле Код_студента, який повинен стати первинним ключем. По ньому з таблиці можна витягати необхідну інформацію за вказаним по коду студентом. Значення цього поля не можуть дублюватися: у таблиці не повинно бути записів с однаковим

36

значенням коду. В якості значень коду може бути використаний ідентифікаційний номер студента. Як відомо, застосування ідентифікаційних кодів спростило обробку фінансової інформації по всій Україні. Але простіше як ключ ввести номер залікової книжки. Залікова книжка – це ж головний документ для студента, як і паспорт для громадянина. Такий же номер можуть мати студентський та читацький квитки. Код може включати дві останні цифри від року вступу та порядковий номер (номер справи абітурієнта, чи номер студента в наказі на зарахування, чи порядковий номер справи по відділу кадрів), наприклад 03/2000 або просто 032000.

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

Таблиця 5.8 – Вид реляційної таблиці “Успішність”

Структуру таблиці можна подавати у вигляді: Ім’я таблиці (Поле1, Поле2,…, ПолеN) Ключ: Поле1, Поле2.

Для нашого випадку маємо:

Успішність (Код_студента, Прізвище, Ім’я, …, Адреса, Ін_ст,…, Спеціальність, Група, Рік, Семестр, Д1З,…, Д30Е, Стипендія) Ключ: Код_студента

Стало видне семантичне навантаження поняття домену: дані вважаються порівняльними тільки в тому випадку, коли вони відносяться до одного домену. У нашому прикладі значення доменів “Код_студента” та “Оцінки” відносяться до типу цілих чисел, але їх неможливо порівнювати.

Під позначеннями Д1, …Д30 треба розуміти повні назви дисциплін учбового плану, наприклад, вища математика, фізика, програмування тощо.

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

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

37

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

Наприклад, якщо поставити поля так: Ім’я, По батькові, Прізвище, а потім Стипендія, то значення інформації не зміниться, може тільки ускладнитись робота з “паперовим” варіантом таблиці.

Таким чином, можна зробити висновок, що журнал успішності студентів, що його наведено у табл. 5.7, являє собою екземпляр коректної реляційної таблиці “Успішність”.

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

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

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

2)Кожна таблиця складається з однотипних записів і має унікальне ім'я.

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

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

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

6)При виконанні операцій з таблицею її поля та записи можна обробляти

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

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

Об'єкти реляційної БД – це сукупність таблиць, що містять всю ту інформацію, яка повинна зберігатися в БД.

Схема БД у структурному змісті – це набір іменованих структур таблиць, між яким можуть бути встановлені зв’язки. Як буде показано далі, ці зв’язки необхідні для реалізації цілісної частини РМД.

38

6ПРОЕКТУВАННЯ РЕЛЯЦІЙНИХ БАЗ ДАНИХ

6.1Універсальна таблиця

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

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

Отримана нами таблиця “Успішність” (табл. 5.7) може бути УТ для проектування такої БД, де буде зберігатися інформація про успішність студентів ВНЗ. Разом з тим у таблицю повинні включатися дані про кількість годин по кожній дисципліні, викладачах, датах іспитів і заліків, тощо. Така розширена таблиця і повинна використовуватися як початкова УТ при проектуванні БД.

Перед цим пояснимо ще одну рекомендацію, що витікає з практики використання РБД. Наприклад, розглянемо два варіанти подання фактичної виплати стипендії за останні роки. Варіант 1 представляє місячні дані про виплати по полях (табл. 6.1), а варіант 2 – по записах (табл. 6.2).

Таблиця 6.1 – Облік виплат (варіант №1)

Таблиця 6.2 – Облік виплат (варіант №2)

39

Уваріанті 1 кількість полів фіксована і складає 15. Для кожної пари (студент, рік) створюється один запис. У варіанті 2 для кожного студента кількість записів буде дорівнювати дорівнює кількості фактичних виплат. Наприклад, для студента, який щомісячно отримував стипендію протягом року, кількість записів буде становити 12. Таким чином, загальна кількість записів при варіанті 2 зростає.

Практика показала, що незважаючи на зростання кількості записів рекомендовано використовувати саме варіант 2 структури таблиці (табл. 6.2). Це значно спростить складання різних запитів до БД. Наприклад, при розрахунку загальних виплат за квартал у варіанті 1 необхідно складати 4 різних запити або формувати досить складну процедуру розрахунку для визначення необхідних полів для різних кварталів.

Сума1кв=М1+М2+М3;

. . .

Сума4кв=М10+М11+М12 (для вибраних року і студента);

Уваріанті 2 можна скласти лише один запит типу

СумаКв=Σ Кількість (для вибраних року, студента і місяців)

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

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

Подамо таку структуру таблиці, де дисципліни будуть подані по записах. В цьому разі отримаємо таблицю у вигляді, що наведено у табл. 6.3.

Таблиця 6.3 – Успішність студентів

Цей варіант таблиці “Успішність” можна розглядати як УТ для нашої ПО. Якби ми зробили спробу подати цю таблицю по структурі варіанту 1, то кількість полів наближалась би до безлічі. І при зміні учбового плану будь-якої спеціальності та додаванні хоча б однієї дисципліни нам би довелось кожного разу змінювати структуру таблиці та додавати нові поля.

До речі, поле Код_студента вже не може бути ключем, бо кожний студент може мати багато оцінок.

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

40

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

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

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

Розглянемо структуру таблиці Успішність.

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

Для наочності при іменуванні таблиць будемо завжди використовувати першу букву “т”. Поля, що складають ключ, будемо позначати знаком (*).

Первинний ключ (складовий):

Код_ст, Рік, Семестр, Код_дисц, Вид_контролю.

Поле Вид_контролю додано до ключа тому, що у студента в одну сесію не може бути передбачено залік або екзамен по одній тій самій дисципліні, а пари екзамен і курсова робота, екзамен і курсовий проект можуть бути.

6.2 Принципи нормалізації

Для проектування БД використовують метод послідовних наближень, названий нормалізацією. У розвиток нормалізації зробили свій внесок Е.Кодд, Бойс, Р.Фагін, І.Хез, К.Дейт, Д.Ульман, В.Амстронг та ін.

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

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

41

до двозначності чи втрати даних;

–корегування таблиць при додаванні нових полів повинно бути мінімальним;

–час обробки даних та маніпуляцій з ними повинний бути мінімальним;

–обсяг БД повинний бути мінімальним.

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

У теорії РБД існує ціла низка НФ. Їхні відносини між собою можна сформулювати так:

–при переході до наступної НФ властивості попередніх НФ зберігаються;

–кожна наступна НФ виключає недоліки та поліпшує властивості попередньої.

Якщо одну НФ показати як круг, то наступна НФ буде показана як круг меншого діаметру, що входить до першого кругу.

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

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

6.3 Перша нормальна форма

Ще раз коротко сформулюємо вимоги до РТ, які витікають з теорії відношень та були пояснені вище:

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

–відсутні записи, що повторюються;

–відсутні поля, що повторюються;

–записи не упорядковані;

–поля не упорядковані;

–жодне ключове поле в жодному запису не є порожнім.

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

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

Оскільки вимоги 1НФ в тУспішність виконані, то можна вважати, що вона знаходиться в 1НФ.

42

Така таблиця має деякі недоліки. Очевидна надмірність даних, бо значення полів ПІБ, Спеціальність, Група повторюються багато разів для кожної отриманої оцінки.

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

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

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

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

Ці проблеми усуваються шляхом виконання одного кроку нормалізації та переходу таблиці з 1НФ у 2НФ.

6.4 Друга нормальна форма

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

Нехай у таблиці Т(Р1,...,Рn) є поля X,Y; тобто поля X,Y належать {Р}. Вважають, що в таблиці Т поле Y функціонально залежить від поля X в

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

Поля X і Y можуть бути складовими полями, тобто реально складатися з декількох полів. При ФЗ в будь-який заданий момент часу для кожного з різних значень набору полів Х обов'язково існує тільки одне з різних значень набору полів Y.

ФЗ позначається як Т.X (r) Т.Y чи Т.X → Т.Y. Далі символ Т будемо пропускати.

Розрізняють повну і транзитивну ФЗ.

ФЗ називається повною, якщо X → Y. При цьому Y не залежить функціонально від будь-якої точної підмножини X. Нагадаємо, що точною підмножиною X називається будь-яка його підмножина, що не збігається з множиною X. Наприклад, якщо Х=(P1,P2,P3), то підмножиною може бути

(P1,P2), (P1,P3) або (P2,P3).

ФЗ називається транзитивною, якщо існує таке поле Y, для якого існує дві ФЗ X → Y, Y → Z. При цьому ФЗ Z → X повинна бути відсутньою, інакше ми отримували б “нецікаві” транзитивні залежності в будь-якій таблиці, що володіє декількома ключами.

ФЗ зручно зображати графічно. На рис. 6.1а показано дві повні ФЗ: X → Y, X → Z, а на рис. 6.1б – транзитивна ФЗ X → Y, Y → Z .

43