Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Методика проектування простих реляційних баз даних
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Досин Д.Г.
МЕТОДИКА ПРОЕКТУВАННЯ
ПРОСТИХ РЕЛЯЦІЙНИХ БАЗ ДАНИХ
За матеріалами книги Glenn A. Jackson "Relational Database Design With Microcomputer Applications"
У 1965 р. з'явилися перші результати в області управління базами даних (роботи Чарльза Бахмана). З тієї пори технології баз даних пройшли великий шлях. Сімдесяті роки ознаменувалися розробкою трьох основних моделей даних - ієрархічної, мережевої і реляційної, кожна з яких знайшла своїх активних прихильників і послідовників. У міру розвитку обчислювальної техніки на базі цих трьох підходів було побудовано велике число СУБД. У восьмидесяті роки з розвитком мікропроцесорної техніки і широким розповсюдженням персональних комп'ютерів виникла нова хвиля інтересу до баз даних, їх проектування і реалізації.
На ринку СУБД для персональних комп'ютерів домінує реляційний підхід, для якого характерними є простота основних понять і строгість математичних основ. Широке застосування комп'ютерів у повсякденному житті примушує велике число користувачів займатися проблемами організації баз даних. Готова СУБД є лише інструментом реалізації спроектованої бази даних і роботи з нею, тоді як принципові труднощі починаються з моменту ухвалення рішення про необхідність створення бази даних. Ця методика є практичним керівництвом до проектування баз даних на персональному комп'ютері на основі реляційної моделі.
В ній викладено метод побудови відношень у нормальній формі Бойса-Кодда на основі поняття функціональної залежності (зручного для невеликих баз даних з малою кількістю атрибутів). На відміну від великого числа відомих аналітичних методів пропоновані правила зводять число необхідних відношень в базі до мінімуму. Добре формалізована процедура перевірки отриманого проекту. Методика буде корисна всім користувачам персональних комп'ютерів і вдало доповнить керівництво до конкретних СУБД.
ПЕРЕДМОВА
Дана методика є вступом в проектування реляційних баз даних (БД). Мета її - опис процесу проектування баз даних на доступній для середнього користувача мові.
Початківцю реляційна БД представляється як набір таблиць (насправді відношень, як буде показано пізніше). Якщо ці таблиці спроектовані некоректно, дані в БД можуть бути помилково змінені або видалені при використанні СУБД. Тут можуть виникнути наступні типові проблеми:
1. Користувач намагається видалити інформацію про партії товару від деякого постачальника. Команда на видалення цієї інформації завершується також видаленням імені та адреси постачальника (крім інформації про поставку).
2. Користувач намагається виправити написання імені клієнта. Проте він забуває, що ім'я зберігається в трьох різних місцях. В результаті тільки одне з трьох імен змінюється, правильне написання імені клієнта викликає сумнів.
Це тільки два прості приклади типових проблем, які можуть виникнути у разі непродуманого проектування відношень в БД. І навпаки, саме ці проблеми будуть виключені у разі правильного проектування БД.
Теорія проектування реляційних БД грунтується на математичній теорії відношень. Ця теорія використовується при розробці алгоритмічних методів проектування, що є однією з головних причин широкого визнання реляційного підходу до проектування БД. Оскільки більшість користувачів мікрокомп'ютерних систем БД не є професійними математиками, в методиці детально розглянуті принципи проектування при мінімумі математичного формалізму. У цьому полягає одна з цілей пропонованої методики, хоча деякий математичний формалізм в ній міститься, оскільки цього практично неможливо уникнути при обговоренні відношень, проте він представлений у формі, зрозумілій для більшості читачів.
Представлений в досить стислому об'ємі матеріал буде корисний будь-якому початкуючому проектувальнику БД. Книга може послужити довідником для керівного персоналу, який відповідає за створення конкретних прикладних СУБД.
1. БАЗИ ДАНИХ, ВІДНОШЕННЯ І РЕЛЯЦІЙНІ БАЗИ ДАНИХ
1.1. Базові концепції
Базу даних можна визначити як уніфіковану сукупність даних, що спільно використовується усім персоналом підприємства, банку або учбового закладу. Задача БД полягає у зберіганні всіх даних, які становлять інтерес для деякого підприємства в одному місці, причому у такий спосіб, який явно виключає їх надлишковість. Зберігання численних копій даних в різних місцях підприємства загрожує виникненням розузгоджень між імовірно ідентичними наборами даних. В добре спроектованій БД надлишковість даних виключається, і вірогідність збереження суперечливих даних мінімізується.
У великих комп'ютерних системах до даних, що зберігаються в БД, доступ може здійснюватися одночасно сотнею і більше користувачів. БД у таких випадках може мати сотні полів даних з мільйонами одиниць інформації. Такі системи можуть містити буквально всі дані, потрібні для управління підприємством. БД на мікрокомп'ютерних системах мають набагато менший масштаб. Тут до конкретної БД в деякий момент часу звичайно здійснює доступ один користувач і кожна БД містить тільки деяку підмножину даних, потрібних підприємству. Одна БД розробляється, скажімо, для зберігання фінансової інформації, інша - даних про персонал. Чи БД, що розробляється, розміщуватиметься на великій ЕОМ або на мікрокомп'ютері - функції СУБД в обох випадках однакові. СУБД є програмно-апаратним пакетом, що забезпечує користувачам простий доступ до БД. Програмна частина СУБД, яку деякі виготовлювачі називають менеджером БД, виступає в ролі інтерфейсу між користувачем і БД (Рис. 1.1). Менеджер БД забезпечує програмні засоби, необхідні для створення, завантаження, запиту і оновлення даних. Менеджер також контролює всі дії, пов'язані з управлінням внесенням-читанням і пам'яттю БД, а на великих ЕОМ на нього покладається і вирішення проблем безпеки і сумісного використовання даних. Коротше кажучи, добре спроектована СУБД надає програмне забезпечення, яке спрощує для користувача спілкування з БД.
Рис. 1.1. Основні компоненти архітектури СУБД.
Інша схожість між великими і малими СУБД полягає в тому, що в обох випадках сама БД повинна бути добре спроектована, якщо ми хочемо, щоб система баз даних як єдине ціле функціонувала належним чином. Мета методики полягає у виділенні і описі деяких базових процедур проектування для реляційних БД. Передбачається, що користувач встановлюватиме БД на мікрокомп'ютерній системі, проте ті ж алгоритми проектування застосовні до БД, проектованих для великих комп'ютерних систем.
1.2. Визначення відношення
Математично відношення означається наступним чином:
Нехай дано "N" множин Dl, D2 ...,DN, тоді R є відношення над цими множинами, якщо R є множина впорядкованих n-кортежей виду <d1, d2, ..., dn>, де d1 - елемент з D1, d2 - елемент з D2... і dn - елемент з DN. Dl, D2 ..., DN називаються доменами відношення R.
Рис. 1.2. Відношення з математичної точки зору.
Значення даного визначення найбільш просто пояснити графічно (Рис. 1.2). Тут показано 4 домени. Домен D1 - це множина цілих чисел; D2 - символьних рядків, що є назвами предметів; D3 - символьних рядків, що є назвами кольорів; D4 - ще одна множина цілих чисел. Відношення R складається з 6-ти кортежів. Кожний кортеж - з 4 елементів, які вибираються кожний з свого домена. Зверніть увагу на порядок елементів в кортежі: перший елемент кожного кортежу вибраний з домена D1, другий елемент - з домена D2 і т.д.
Рис. 1.3. Відношення з погляду обробки даних
Погляд на відношення з погляду обробки даних характеризує Рис. 1.3. Чотири домени, представлені на Рис. 1.2, співвідносяться з чотирма елементами реального світу: номером деталі, її назвою, кольором і вагою. Відношення приймає вид таблиці або файлу, де кортежі - рядки таблиці або записи у файлі.
Імена стовпців (з погляду обробки даних - поля в записі) називаються атрибутами, а індивідуальні значення, що з'являються в окремих кортежах - значеннями атрибутів. Таким чином, перший елемент першого кортежу має значення атрибута, рівне 101 і узяте з домена Дном.
Наступні набори термінів використовуватимуться по черзі:
1) відношення, таблиця і файл;
2) кортеж, рядок і запис;
3) атрибут, стовпець і поле;
так само як і в більшій частині документації по мікрокомп'ютерних БД.
Слід зробити одне зауваження з приводу відмінності між математичним визначенням відношення і дійсним зберіганням відношень в мікрокомп'ютерних системах БД. За визначенням відношення не може мати двох ідентичних кортежів. Не дивлячись на те, що більшість великих СУБД не допускає зберігання ідентичних кортежів (записів) у відношенні (файлі), багато мікрокомп'ютерних СУБД це допускають (якщо не використовується спеціальна техніка програмування, що запобігає виникненню вказаної ситуації).
Слід згадати два додаткові терміни, що стосуються відношень. Число стовпців у відношенні називають ступенем. Поточне число кортежів у відношенні називається потужністю. Ступінь відношення звичайно не змінюється після створення відношення, але потужність коливатиметься у міру додавання нових і видалення старих кортежів.
1.3. Визначення реляційної БД
Реляційна БД є не що інше, як сукупність відношень, що містять всю інформацію, яка повинна зберігатися в БД. На Рис. 1.4 наведено приклад дуже маленької БД, названої Постачальник-Деталі.
Ця база містить три типи інформації про будівельну компанію БД Постачальник-Деталі - гарний приклад невеликої за об'ємом реляційної БД, який часто використовується в літературі.
:
1. Інформація про постачальників, що поставляють деталі підприємству. Сюди відносяться номер постачальника (передбачається унікальним), а також його прізвище, статус і місце проживання (не є унікальними). Ця інформація міститься у відношенні ПОСТАЧАЛЬНИК.
Деталь
Постачальник
Рис. 1.4. База даних Постачальник-Деталі.
2. Інформація про деталі, що використовуються на підприємстві. Сюди відносяться номер деталі, що є унікальним, назва, колір і вага, що не є унікальними. Ця інформація міститься у відношенні ДЕТАЛЬ.
3. Інформація про номери і кількість деталей від кожного постачальника. Ця інформація міститься у відношенні ПД.
Кожне відношення в БД зберігається в окремому файлі. Структура файлу, що використовується для зберігання відношення, досить проста, оскільки всі записи мають однаковий формат. У великих СУБД кожне відношення зберігається у вигляді індексованого файлу, де індекс є атрибутом або набором атрибутів, специфікованим при конструюванні відношення.
Набір атрибутів, що використовується як індекс, називається первинним ключем відношення. Первинний ключ визначається як такий атрибут, або набір атрибутів, який може бути використаний для однозначної ідентифікації конкретного кортежу. Первинний ключ не повинен мати додаткових атрибутів. Це значить, що якщо одиничний довільний атрибут виключити з первинного ключа, атрибутів, що залишилися, буде недостатньо для однозначної ідентифікації окремих кортежів. В БД Постачальник-Деталі первинними ключами є <Пном> для відношення ПОСТАЧАЛЬНИК, <Дном> для відношення ДЕТАЛЬ і пара атрибутів <Пном, Дном> для відношення ПД.
Можна переконатися, що кожний первинний ключ є достатнім для однозначної ідентифікації кожного кортежу у відношенні. Наприклад, відносно ПД, якщо Пном - П1 і Дном - 101, можна знайти не більше одного кортежу з вказаними значеннями атрибутів. На Рис. 1.4 дані значення містить кортеж <П1, 101, 9>. Спроба зберегти інший кортеж з тим же первинним ключем, скажімо, <П1, 101, 11>, приводить до виникнення конфліктної ситуації, оскільки стає незрозумілим скільки деталей з номером 101 поставляє П1 - 9 або 11 (а може 9+11=20?). В повністю розробленій СУБД при спробі користувача записати кортеж, що має первинний ключ, співпадаючий з первинним ключем іншого кортежу, вже включеного у відношення, генерується повідомлення про помилку. В багатьох реалізаціях СУБД, призначених для мікрокомп'ютерів, кортежі із співпадаючими первинними ключами і навіть повністю ідентичні кортежі можна занести у відношення, і це не приводить до виникнення помилки СУБД. У зв'язку з цим можуть виникнути деякі проблеми.
В багатьох СУБД індекс файлу, що містить відношення, не створюється автоматично, і користувач повинен виконати команду INDEX для його створення. Індексація файлів значно прискорює виконання деяких команд. Можлива індексація відношення з використанням атрибутів, відмінних від первинного ключа. Даний тип індексу називається вторинним індексом і застосовується в цілях зменшення часу доступу при знаходженні даних у відношенні. Простий приклад індексного файлу приведений на Рис. 1.5. Зверніть увагу, що якщо саме відношення не впорядковано яким-небудь чином і в ньому можуть бути присутні рядки, що залишилися після видалення деяких кортежів, то індексний файл, навпаки, відсортований. Структура індексного файлу може бути різною, але звичайно використовується деякий варіант деревовидної структури, що забезпечує швидкий пошук. Для пояснення вибрана структура індексного файлу, показаного на Рис. 1.5, але її не слід сприймати як зразок практичного проектування.
Постачальник (індексний файл) Постачальник (файл даних)
Рис. 1.5. Простий приклад індексного файлу
Число відношень в БД і конкретні атрибути, приписувані кожному відношенню, визначаються в процесі проектування. Власне процес проектування може бути досить тривалим. Проте після завершення етапу проектування створення БД засобами СУБД можна виконати досить швидко. У разі БД Постачальник—Деталі структура її повністю специфікується коротким набором тверджень, приведеним на Рис. 1.6. Цей стислий опис називається концептуальною моделлю БД і містить всю інформацію, необхідну для створення повної структури БД незалежно від того, яка конкретно СУБД буде використана. Кожне з відношень в БД Постачальник-Деталі створюватиметься аналогічним чином. Зверніть увагу на те, що вся інформація, необхідна для створення ПОСТАЧАЛЬНИК, міститься в концептуальній моделі.
Назва БД: Постачальник_Деталі
Атрибути і тип:
Пном симв(3),
Пфам симв(6),
статус цілий,
місто симв(10),
Дном цілий,
Дназ симв(6),
колір симв(6),
вага цілий,
шт цілий.
Відношення і <Первинні ключі>:
Рис. 1.6. Концептуальна модель БД Постачальник-Деталі.
Побудоване відношення є незаповненим, і його необхідно завантажити покортежно за допомогою відповідних команд запису.
Лістинг вмісту відношення або всіх відношень в БД, подібний до наведеного на Рис. 1.4 для БД Постачальник-Деталі, слід розглядати як фотографію стану відношень в деякий момент часу. Слід пам'ятати, що вміст всіх відношень динамічно змінюється, оскільки кортежі можуть бути додані, видалені або модифіковані протягом життєвого циклу відношень. Окремий лістинг деякого відношення в певний момент часу називається екземпляром цього відношення.
Первинний ключ, визначений для відношення, настільки важливий, що атрибути або набір атрибутів, що формують первинний ключ, як правило певним чином позначаються при математичній формі запису відношень. В даному випадку атрибути, що формують первинний ключ, підкреслюються. Наприклад, визначене на Рис. 1.6 відношення ПД буде записане, у вигляді ПД(Пном, Дном, шт). Це означає, що пара атрибутів <Пном, Дном> є первинним ключем для даного відношення.
НЕОБХІДНІСТЬ ПРОЕКТУВАННЯ БАЗ ДАНИХ
2.1. Цілі проектування
Перш ніж приступати до розгляду специфічних алгоритмів і проблем проектування, має сенс намітити деякі цілі проектування. Зокрема, в чому полягає бажаний кінцевий результат процесу проектування реляційних БД? Серед множини цілей, що стоять перед проектуванням, наступні видаються найважливішими:
1. Можливість зберігання всіх необхідних даних в БД.
2. Виключення надмірності даних.
3. Зведення числа збережених в БД відношень до мінімуму.
4. Нормалізація відношень для спрощення рішення проблем, пов'язаних з оновленням і видаленням даних.
Мета 1: Можливість зберігання всіх необхідних даних в БД
Ця мета здається очевидною, проте вона дуже важлива. Передбачається, що БД повинна містити всі дані, що представляють інтерес для підприємства, так що при проектуванні слід передбачити можливість розміщення в БД всіх необхідних даних. Першим кроком в процесі проектування є визначення всіх атрибутів, які згодом будуть поміщені в БД. Після визначення атрибутів проектувальник обдумує, скільки відношень необхідно і які атрибути включати у які відношення.
Мета 2: Виключення надлишковості даних
Сутність цієї мети зовсім не очевидна для початкуючого проектувальника БД. Ключ до її розуміння полягає у з'ясуванні чіткої відмінності між дублюванням даних і надмірним дублюванням даних. Наприклад, звернемося до відношення С-Н, приведеного на Рис. 2.1 (а). Відношення має два атрибути - Слжб# (табельний номер службовця) і Начк (начальник). У відношенні містяться дані, які вказують на безпосереднього начальника кожного службовця підприємства. Прізвища начальників можуть неодноразово з'являтися у відношенні. Насправді прізвище начальника з'являється один раз для кожного підлеглого йому службовця. Зверніть увагу, на те, що хоча "Мельник" і "Гірняк" з'являються двічі в екземплярі С-Н, наведеному в на Рис. 2.1 (а), жодне з дубльованих прізвищ не є надмірним. Причина відсутності надмірності полягає в тому, що при видаленні одного з прізвищ з відношення буде загублена інформація. Наприклад, на Рис. 2.1(6) показано вигляд екземпляра відношення С-Н при видаленні дубльованих прізвищ. В цьому випадку немає можливості довідатися про прізвища начальників службовців з номерами #195 і #200.
С-Н С-Н
Рис. 2.1. Дубльовані дані, що не є надмірними
На Рис. 2.2 (а) наведено приклад відношення з надмірним дублюванням даних. Відношення С-Н-Т схоже на відношення С-Н, але включає додатковий атрибут Нтел, що є номером телефону начальника. Передбачається, що кожний начальник має тільки один телефонний номер. В цьому екземплярі відношення номера телефонів Мельника і Гірняка з'являться більш ніж один раз і дубльована інформація про телефонні номери є надмірною. Причина надмірності в тому, що якщо, скажімо, видалити один з номерів Мельника, ця інформація може бути отримана з інших кортежів відношення. На Рис. 2.2(6) наведено приклад того, як виглядатиме відношення С-Н-Т у разі заміщення дубльованих телефонних номерів "нулями".
С-Н-Т С-Н-Т
С-Н
Н-Т
(в)
Рис. 2.2. Виключення надмірних даних.
Зрозуміло, що телефонні номери Мельника і Гірняка не загублені, оскільки кожний з них виявляється в одному з кортежів відношення. Даний метод управління надмірністю незадовільний з двох причин. По-перше, порожніх полів в БД слід уникати, оскільки необхідні додаткові зусилля при програмуванні, направлені на визначення реальних значень "нулів". В даному випадку читання третього кортежу <195,Гірняк,-> відношення не дозволяє вияснити телефонний номер Гірняка. Користувач повинен уміти знаходити у відношенні інший кортеж, для якого значенням атрибута Начк є Гірняк, а значення атрибута Нтел не є нульовим. По-друге, що більш важливо, відношення, представлене на Рис. 2.2(6), має структуру, що загрожує виникненням серйозних проблем при видаленні інформації. Якщо службовець з номером Слжб# = 125 звільняється з підприємства і кортеж <125, Мельник, 3051> буде видалений з відношення при належній реєстрації факту звільнення, відбудеться втрата телефонного номера Мельника, оскільки ніде більше у відношенні він не представлений.
Рис. 2.2(в) показує кращий спосіб виключення надмірності телефонних номерів. Тут відношення С-Н-Т замінюється двома відношеннями, одне з яких містить інформацію про табельні номери службовців і прізвища керівників, а інше - інформацію про телефонні номери начальників. В наступному розділі буде показано, що розбиття відношень є стандартною процедурою проектування, яка повинна здійснюватися при дотриманні певних обмежень. Як випливає з Рис. 2.2(в), службовець з номером #125 тепер може бути видалений з відношення С-Н без втрати номера телефону колишнього начальника цього службовця, що зберігається у відношенні Н-Т.
Мета 3: Зведення числа відношень, які зберігаються в БД до мінімуму.
Ця мета обумовлена тим, що розбиття одного відношення на два або більше менших відношень бажане з погляду виключення певних проблем, але це незручно для користувача. Таким чином, не можна допускати необмежене зростання числа відношень.
Мета 4: Нормалізація відношень
Для деяких відношень дуже важлива проблема видалення і оновлення (наприклад, втрата телефонного номера керівника, що обговорювалася вище в 2-й меті). Проектувальник повинен уміти знаходити ці потенційно небезпечні відношення і "нормалізувати їх" за допомогою розбиття належним чином. Нормалізація є розбиттям одного відношення на два або більше відповідно до спеціальної процедури визначення розбиття. Нормалізація обговорюватиметься в наступному розділі.
Цілі 3 і 4 суперечать одна одній, тому тут потрібен взаємний компроміс. Це буде частиною завершального етапу проектування.
2.2. Універсальне відношення
Припустімо, необхідно розробити невелику БД для консультанта університету. У консультанта є багато консультованих ним студентів, які живуть на території університетського містечка, причому всі ці студенти вчаться на основному факультеті.
Перший крок процесу проектування полягає у визначенні як всіх атрибутів, необхідних консультанту, так і зв'язків між атрибутами. Ця інформація виходить від консультанта у результаті ряду детальних обговорень, що не залишають сумнівів в тому, що він знає які дані повинні бути в БД, яким чином БД використовуватиметься і яку інформацію консультант планує одержувати від БД. Після декількох бесід з консультантом імена і умови, пов'язані з атрибутами, зберігання яких передбачається, були визначені таким чином:
Сном: Номер студента. Ціле значення, унікальне для кожного студента університету.
Сфам: Прізвище студента. Кожний студент має тільки одне прізвище, але можливо, що одне прізвище носять декілька студентів.
Кном: Номер кімнати в гуртожитку містечка. Кожний студент живе на території містечка і має кімнату. В одній кімнаті може проживати більше одного студента.
Тном: Номер телефона студента. Кожна кімната гуртожитку має один телефон і ним користуються всі студенти, що проживають у цій кімнаті.
Курс: Номер курсу. Це ідентифікаційний номер курсу, відвідуваного студентом. Прикладом може служити номер МТН122. Консультант зберігатиме дані тільки про курси, завершені студентом.
Семестр: Університетський семестр. Є семестром, в якому даний курс був завершений студентом. Можливо, що студент вивчав один і той же курс в різних семестрах.
Оцінка: Оцінка за курс. Оцінка, отримана студентом за певний курс в даному семестрі.
На Рис. 2.3 представлено зразок даних, концептуалізованих консультантом для їх зберігання в БД. Хоча на малюнку наводиться приклад у вигляді таблиці даних, які можуть зберігатися в БД в деякий момент часу, вказана таблиця не є відношенням.
КОНСУЛЬТАНТ
Рис. 2.3. Дані, необхідні консультанту.
Рис. 2.4. Один "рядок" таблиці, наведеної на Рис. 2.3.
Для ілюстрації того, чому таблиця на Рис. 2.3 не є відношенням, виділимо один "рядок" з таблиці (Рис. 2.4). На цьому малюнку значення чотирьох полів Сном, Сфам, Кном і Тном - атомарні, тоді як значення в полях Курс, Семестр і Оцінка - множинні. Даний "рядок" очевидним чином відрізняється формою від кортежів, представлених в простих відношеннях і розглянутих вище. Відмінність в тому, що не всі поля рядка містять атрибути, значення яких є атомарними. Для представлення даних, наведених на Рис. 2.3, у формі відношення необхідно реконструювати їх так, щоб кожний елемент кортежу мав атомарне значення. Звичайно це вдається зробити за допомогою простого процесу вставки (результат для даного випадку показаний на Рис. 2.5). В результаті цього процесу додається великий об'єм надлишкових даних - усунення надлишковості досягається на наступних етапах проектування.
КОНСУЛЬТАНТ
Рис. 2.5. Дані з таблиці, приведеної на Рис. 2.3, поміщені в коректне відношення
Таблиця на Рис. 2.5 є екземпляром коректного відношення. Його називають універсальним відношенням проектованої БД. В одне універсальне відношення включаються всі атрибути, що становлять інтерес, і воно може містити всі дані, які передбачається розміщувати в БД в майбутньому. Для малих БД (що містять не більше 15 атрибутів) універсальне відношення може використовуватися як відправний пункт при їх проектуванні.
2.3. Проблеми, що виникають при використанні єдиного відношення
Початкуючий проектувальник, намагатиметься застосовувати відношення КОНСУЛЬТАНТ (Рис. 2.5) як завершену БД. Це виглядає достатньо послідовним. Навіщо розбивати відношення КОНСУЛЬТАНТ на декілька більш дрібних відношень, якщо воно здатне містити в собі усі дані? Існує декілька причин, чому не слід використовувати дане відношення як єдине в БД. Це обумовлено тим, як використовуватиметься БД, і яку дію на дані у відношенні КОНСУЛЬТАНТ матимуть певні операції. Розрізняються три специфічні проблеми:
проблема, пов'язана з оновленням (модифікацією) даних в БД;
проблема, обумовлена необхідністю видалення кортежів;
проблема, обумовлена необхідністю включення нових кортежів.
Виділені проблеми звичайно називають аномаліями вставки, видалення і оновлення, маючи на увазі під аномалією відхилення від норми.
Проблема вставки
Якщо у консультанта з'являється новий консультований ним студент, що ще не закінчив курс, для нього необхідно включити в БД кортеж з нульовими (порожніми) значеннями атрибутів Курс, Семестр і Оцінка. Як вже не раз наголошувалося, нульових значень слід уникати. Отже, включення в БД нового студента неможливе аж до завершення ним курсу.
На Рис. 2.6 (а) показано приклад того, як виглядатиме відношення КОНСУЛЬТАНТ у разі примусового включення в нього інформації про студента, що не завершив жодного курсу. Порожні символьні рядки представляються пробільними полями (Курс і Семестр), тоді як нульове чисельне значення в полі Оцінка інтерпретується dBASE II як 0.0. Рис. 2.6(6) ілюструє можливі наслідки появи 0.0 за відсутності інформації. Отримана відповідь на запит "Видати список Сном і Сфам для всіх студентів, що отримали хоча б одну оцінку нижче 2.0". В число таких студентів потрапив ХоумерХ, хоча він не закінчив жодного курсу.
. use консультант
. list
(а)
. display off Сном, Сфам for Оцінка < 2.0
3215 Дзера Г.
3567 Хомин Д.
7890 Хміль М.
(б)
Рис. 2.6. а - результат вставки запису з порожніми полями;
б - помилковий результат виконання запиту, викликаний наявністю порожніх полів.
Проблема оновлення
У відношенні КОНСУЛЬТАНТ велике число надмірних даних. Надлишковість даних завжди свідчить про можливість модифікації тільки частині необхідних даних за допомогою операції оновлення.
Відношення КОНСУЛЬТАНТ характеризується як явною, так і неявною надмірністю. Явна надлишковість полягає в тому, що прізвище даного студента, номер кімнати і номер телефону можуть з'явитися у відношенні кілька разів. В екземплярі відношення КОНСУЛЬТАНТ, приведеному на мал. 2.5, номер кімнати ДжонсГ з'являємося чотири рази. Якщо вона звернеться до свого консультанта і повідомить його про зміну номера її кімнати, то консультант буде вимушений прослідити зміну цього номера у всіх чотирьох кортежах щоб уникнути суперечності даних.
неявна надлишковість виявляється в тому, що один і той же номер телефону мають всі студенти, що живуть в одній кімнаті. На мал. 2.5 телефонний номер для кімнати 120DH з'являється в поєднанні з іменами ДжонсГ і ХаузДж. Припустимо, ДжонсГ сповістить свого консультанта про те, що її номер телефону змінений на 7777, забувши при цьому повідомити про подругу по кімнаті. Якщо консультант змінить телефонний номер тільки в тих кортежах, які містять номер телефону ДжонсГ, то правильний номер телефону, розташованого в кімнаті 120DH, буде фактично загублений, оскільки у відношенні будуть присутні два різні телефонні номери для однієї кімнати.
Мал. 2.7 ілюструє останню аномалію оновлення. На мал. 2.7 (а) телефонний номер для ДжонсГ змінюється на 7777. На мал. 2.7 (би) приводиться відповідь dBASE II на запит "Вивести перелік номерів телефонів для кімнати 120DH". Відповідає на запит містяться два номери, що свідчить про помилку, оскільки в кожній кімнаті є один телефон з одним телефонним номером. Зверніть увагу, що dBASE II вивела на друк дубльовані відповіді на запит. Кожний з телефонних номерів 2136 і 7777 міститься в трьох різних кортежах екземпляра обговорюваного відношення КОНСУЛЬТАНТ, і всі шість значень були роздруковано СУБД. При програмуванні деяких СУБД в них закладається функція придушення дублювання у відповідях на запити, якщо необхідність дублювання не обмовляється спеціально.
. display
Тном for Кнон - 42ODH'
7777
7777
7777
7777
2136
2136
2136
(би)
Мал. 2.7. а - зміна номера телефону деякого студента, би - помилковий результат виконання запиту» викликаний зміною номера телефону
Проблеми видалення
В екземплярі відношення КОНСУЛЬТАНТ (мал. 2.5) присутній тільки один кортеж, в якому Сном*4756. Цей кортеж відповідає студенту з ім'ям Алекськ. Припустимо, що консультант взнає, що цей студент не закінчив курс MUS389, як це відзначено, і видаляє цей кортеж з відношення. Оскільки це єдиний кортеж з інформацією про цього студента, його видалення приведе до виключення студента з БД. Якщо консультант вслід за даною операцією видалення запитає список містяться у відношенні КОНСУЛЬТАНТ імен всіх консультованих, то імені Алекськ в цьому списку він не знайде.
3. ФУНКЦІОНАЛЬНА ЗАЛЕЖНІСТЬ
3.1. Перша нормальна форма (1НФ)
В гл. 2 вже було відзначено, що складовою частиною проектування реляційної БД є процес розбиття відношень з незадовільними властивостями (з погляду аномалій) на нові відношеньи. У зв'язку з цим процесом слід поставити декілька питань.
1. З якого джерела Ви одержуєте відношення (або відношеньи) перед початком процесу?
2. Яким чином Ви можете розпізнати відношеньи, потребуючі в розбитті?
3. Яким чином Ви здійснюватимете розбиття?
4. Що є ознакою завершення процесу розбиття?
Відповіді на ці питання будуть дані в справжньому розділі і більш поглиблений в гл. 4.
Для БД з числом атрибутів меншим 20 початковою точкою вказаної процедури може служити універсальне відношення. Це відношення містить всі представляючі інтерес атрибути, і має структуру, в якій кожний кортеж складається з атомарних елементів. Це означає, що всі екземпляри відношень повинні мати форму, показану на мал. 2.5, а не подібну тієї, яка приведена на мал. 2.3. Говорять, що відношення знаходиться в першій нормальній формі (або 1НФ), якщо кожний його елемент має і завжди матиме атомарне значення. Відношення повинне бути в 1НФ навіть раніше постанов-ки питання об його розбиття на два або більш відношеньи.
3.2 Концепція функціональної залежності
Процес розбиття відношення з метою зменшення вірогідності виникнення аномалій називається декомпозицією. Ключовий для здійснення деком по-зиции логічним методичним шляхом є концепція функціональної залежності між атрибутами в даному відношенні.
Функціональна залежність (ФЗ) визначається таким чином:
Якщо дано два атрибути А і В, то говорять, що У функціонально залежить від А,,если для кожного значення А існує рівно одне пов'язане з ним значення В (у будь-який момент часу). А і В можуть бути складовими, тобто вони можуть бути не одиничними атрибутами, а групи, що складаються з двох і більш атрибутів.
З практичної точки зору значення даного визначення полягає в тому, що якщо У функціонально залежить від А, то кожний з кортежів, що мають одне і те ж значення А> повинен мати також одне і те ж значення В. Значения А і В можуть змінюватися час від часу, але при цьому вони повинні змінюватися так, щоб кожне унікальне значення А мало тільки одне значення В, пов'язане з ним. ФЗ описуються за допомогою декількох різних способів нотації. Два найбільш часто що використовуються способу показані на мал. 3.1.
А -> В (Математична форма запису)
(Діаграма або графічна форма запису)
Мал. 3.1. Два можливі способи запису того, що атрибут У функціонально залежить від атрибута А
В конкретній ситуації ФЗ визначається шляхом деталізації властивостей всіх атрибутів у відношенні і висновку висновку про те, як атрибути співвідносяться між собою. ФЗ не можуть бути доведені шляхом простого перегляду окремого екземпляра відношення і знаходження двох атрибутів, що мають ті ж значення в більш ніж одному кортежі. Це може служити ключем до того, в якому напрямі слід вести пошук ФЗ, але не доказом. ФЗ необхідно отримати виходячи з базових властивостей самих атрибутів.
Як приклад знов звернемося до атрибутів я відношенні КОНСУЛЬТАНТ (мал. 2.5) і, зокрема, до докладного пояснення того, як ці атрибути зв'язані між собою (разд. 2.2). Після вивчення описів атрибутів може бути виведені залежність, приведена на мал. 3.2.
(би)
Мал. 3.2. Різні способи уявлення ФЗ, існуючих між атрибутами отиошения КОНСУЛЬТАНТ
Міркування, що привели до цих ФЗ, в деталях обговорюються нижче.
1. Номери студентів є унікальними. Кожному студенту призначається номер Сном» причому всі номери різні. Таким чином, якщо ви знаєте Сном студента» ви знаєте, що з ним може бути зв'язано тільки одне прізвище Сфам; Сном -> Сфам, Зворотне не є вірним. Сфам -> Сном не є правильної ФЗ, оскільки декілька студентів можуть мати одне прізвище.
2. Кожний студент прикріплений до однієї кімнати об* шежития, але в одній кімнаті може проживати бо-
леї ніж один студент. Таким чином, Сном -> Кном є вірним, а Кном -> Сном - ні.
3. Оскільки в кожній кімнаті тільки один телефон і кожний телефон, у свою чергу, має унікальний номер, одержуємо Кном -> Тном і Тном -> Кном. Дана ситуація звичайно позначається у вигляді Сном <-> Тном, і говорять, що Сном і Тном взаимозависимы.
А. Поскольку в кожній кімнаті тільки один телефон і цей телефон має унікальний номер, отже тільки один телефонний номер може бути пов'язаний з даним студентом, або інакше Сном -> Тном.
5. Остання ФЗ є прикладом складного набору атрибутів, що входять у ФЗ. Залежність Сном, Курс, Семестр -> Оцінка означає, що оцінка однозначно визначається тільки в тому випадку, якщо відомий Сном студента, що вивчає даний Курс в даному Семестрі. (Необхідно пам'ятати, що студент може повторити проходження учбового курсу і отримати при цьому іншу оцінку).
Читачу слід перевірити відношення КОНСУЛЬТАНТ (мал. 2,5) і переконатися в тому, що дані в цьому відношенні узгоджуються з функціональною залежністю, представленою на мал. 3.2. Наприклад, відзначимо, що Кном • 120DH і Тном • 2136 завжди мається свій в розпорядженні пара (Киом <-> Тном); також Сном-3215 пов'язаний тільки з одним прізвищем, саме "ДжонсГ", як і повинно бути, оскільки Сном -> Сфам. Інші ФЗ слідує верифицировать аналогічним чином. Читачу слід також відзначити, що в екземплярі відношення КОНСУЛЬТАНТ, показаному на мал. 2.5, тільки один номер Сном пов'язаний з кожним ім'ям Сфам; проте це не доводить Сфам -> Сном, що є помилковим. Це говорить тільки про те, що в даний час немає двох консультованих з одним прізвищем. В майбутньому може трапитися так, що двох студентів з одним прізвищем будуть включено у відношення КОНСУЛЬТАНТ.
3.3. Нормальна форма Бойса-Кодда (НФБК)
Досвідченому проектувальнику БД достатньо побіжного погляду на діаграму, приведену на мал. 3.2(6), щоб зробити висновок про те, що відношення КОНСУЛЬТАНТ не можна вважати "хорошим". Проектувальник прийде до такого висновку, дивлячись на ФЗ, отримані для відношення КОНСУЛЬТАНТ, і звертаючи увагу на деякі їх небажані властивості. Перед обговоренням цих властивостей необхідно визначити два терміни, ФЗ, що стосуються.
1. Можливий ключ. Можливий ключ є атрибутом або набором атрибутів, який може бути використаний для даного відношення як первинний ключ. Первинний ключ завжди є можливим ключем; проте не виключена наявність інших можливих ключів, які могли б бути, але не були використані як первинний ключ.
2. Детермінант. Якщо А -> В є ФЗ і В не залежить функціонально від будь-якої підмножини А, то говорять, що А є детермінантом В.
З мал. 3.2 можна укласти, що відношення КОНСУЛЬТАНТ має тільки один можливий ключ, а саме набір атрибутів <Сном,Курс,Семестр>. Цей висновок отриманий шляхом знаходження мінімального набору значень атрибутів, які, якщо вони відомі, визначають значення всіх інших атрибутів кортежу. За допомогою ФЗ, представлених на мал. 3.2, легко бачити, що один номер Сном визначає Сфам, Кном і Тном і для визначення Оцінки повинен бути відомий весь набір Сном, Курс і Семестр. Таким чином, якщо відомі значення атрибутів даного вище можливого ключа, то значення всіх інших атрибутів кортежу, що містить вказаний можливий ключ, будуть однозначно специфіковані.
Детермінанти у відношенні КОНСУЛЬТАНТ визначити легко: ними є ліві частини всіх ФЗ у відношенні. Детермінантами в КОНСУЛЬТАНТ є <Сном,Курс,Семестр>, <Сном>, <Кном> і <Тном>. Детермінанти укладені в кутові дужки для того, щоб в даному випадку виділити чотири різні детермінанти. Слід помітити, що взаємна залежність дає два детермінанти.
Одним з найперших, але і одним з найважливіших результатів в області реляційних БД стало
доведене Коддом твердження про те, що більшість потенційних аномалій в БД буде усунена у разі належної декомпозиції кожного відношення в нормальну форму Бойса-Кодда (НФБК). Ця форма визначається таким чином:
відношення знаходиться в НФБК, якщо і тільки якщо кожний детермінант відношення є можливим ключем.
Хоча існують нормальні форми більш високого рівня, які накладають навіть більш сильні обмеження на відношеньи, що розробляються, на практиці більшість проектувальників прагне отримати відношеньи в НФБК. Ця мета переслідуватиметься і в пропонованій книзі.
Відношення КОНСУЛЬТАНТ не знаходиться в НФБК. Це легко знайти, якщо розташувати поряд перелік всіх детермінантів і перелік всіх можливих ключів і подивитися, чи є каж-, дый детермінант можливим ключем.
Оскільки не кожний детермінант у відношенні КОНСУЛЬТАНТ є можливим ключем, отже, КОНСУЛЬТАНТ не знаходиться в НФБК і його необхідно піддати декомпозиції.
3.4. Загальний підхід до декомпозиції
До цього моменту все готово для загального опису одного методу, що визначає, як слід здійснювати за допомогою декомпозиції проектування реляційних БД. Далі буде показано, що цей метод повинен бути вдосконалений для подолання деяких подальших утруднень.
1. Розробка універсального відношення для БД.
2. Визначення всіх ФЗ між атрибутами відношення.
3. Визначення того, чи знаходиться відношення в НФБК. Якщо так, проектування завершується; якщо ні, відношення повинне бути розкладено на два відношення.
4. Повторення кроків 2 і 3 для кожного нового відношення, отриманого в результаті декомпозиції. Проектування завершується, коли всі відношеньи знаходитимуться в НФБК.
Запропонований вище метод не визначає, як здійснювати декомпозицію відношення, не приведеного до НФБК, на два відношення. Це здійснюється за допомогою ФЗ таким чином:
Хай відношення R(A,B.C,D,E..) не приведено до НФБК. Визначається ФЗ, наприклад З -> D, про яку відомо, що вона є причиною того, що відношення R не знаходиться в НФБК. (З є детерминатом, але не є можливим ключем.) Створюються дм нових відношення: R1(A.B.C.E...) і R2(C,D), де зависимостная частина ФЗ була виділена з R і опущена при формуванні відношення R1 і ФЗ була використана повністю при формуванні відношення R2. Тепер необхідно перевірити, чи знаходяться в НФБК відношеньи R1 і R2. Про відношення R2(C,D) говорять, що воно є проекцією відношення R. Цей тип декомпозиції називається декомпозицією без втрат при прир...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора