ПРОЕКТУВАННЯ БАЗИ ДАНИХ ЗА ДОПОМОГОЮ МЕТОДУ ER-МОДЕЛЮВАННЯ

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

Звичайні сутності

На рис 141 показані наступні звичайні типи сутностей

■&nbsp&nbsp&nbsp&nbsp DEPARTMENT

■&nbsp&nbsp&nbsp&nbsp EMPLOYEE

■&nbsp&nbsp&nbsp&nbsp SUPPLIER

■&nbsp&nbsp&nbsp&nbsp PART

■&nbsp&nbsp&nbsp&nbsp PROJECT

Кожен звичайний тип сутності відображається на базову змінну відносини Отже, розглянута база даних буде містити пять базових змінних відносини, наприклад, DEPT, EMP, s, P і J, відповідних цим пяти типам сутності Більше того, кожне з базових відносин матиме потенційний ключ (DEPT #, ОМР #, s #, Р # і J #), відповідний зазначеним на ER-діаграмі ключовим властивостям Для визначеності припустимо, що в кожній з створюваних змінних відносини відповідний потенційний ключ визначається як первинний Як приклад нижче наводиться визначення змінної отношеніяБЕРТ (у скороченому вигляді)

VAR DEPT BASE RELATION

{ DEPT# , .. } PRIMARY KEY { DEPT#

}

Читачеві пропонується в якості вправи записати визначення інших чотирьох змінних відносини

Примітка Безумовно, в документації також повинні бути зафіксовані визначення доменів і допустимих множин значень Однак подробиці тут не дано, оскільки, як уже зазначалося, безлічі значень на ER-діаграмах не відображаються

Звязки типу багато до багатьох

У розглянутому прикладі присутні наступні звязку типу багато до багатьох (Або багато до багатьох і до багатьох і тд)

4 В даний час існує безліч інструментів, що дозволяють виконати таке відображення (наприклад, з використанням ER-діаграми для генерації відповідного набору операторів CREATE TABLE на мовою SQL)

▪ PROJ_WORK (між працівниками та проектами)

■ SUPP_PART (між постачальниками і деталями)

■ SUPP_PART_PROJ (між постачальниками, деталями і проектами)

■ PART_STRUCTURE (між деталями-вузлами і деталями, що входять до їх складу)

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

VAR    SP    BASE    RELATION     SP

{    S#     ..     ,     P#     ..     ,     ..     }

FOREIGN KEY { S# } REFERENCES

S FOREIGN KEY { P# } REFERENCES P

Ясно, що така змінна відносини повинна включати два зовнішніх ключа (s # і Р #), що відповідають двом учасникам звязку (сутностей SUPPLIER і PART), і ці зовнішні ключі повинні посилатися на відповідні змінні відносини s і р Більше того, для кожного з зовнішніх ключів повинен бути заданий відповідний набір правил зовнішніх ключів, тобто правило поновлення UPDATE і правило видалення DELETE

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

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

VA R    S P    BA SE     RELATION     SP

{S # , Р # , }

FOREIGN KEY { S# } REFERENCES S ON DELETE RESTRICT

ON UPDATE CASCADE FOREIGN KEY { P# } REFERENCES P

ON DELETE RESTRICT

ON UPDATE CASCADE

Що можна сказати про первинному ключі цієї змінної стосунки Одним з можливих способів його визначення може бути застосування комбінації зовнішніх ключів, що ідентифікують учасників відповідної звязку (У випадку базовою змінною відносини SP ними є атрибути s # і Р #) Це можливо, якщо дана комбінація має унікальне значення для кожного примірника даної звязку (це умова може дотримуватися або не дотримуватися, але зазвичай воно дотримується) і якщо розробник бази даних не заперечує проти використання складених первинних ключів (на практиці вони в рівній мірі можуть застосовуватися і не застосовуватися) Як альтернативний варіант первинного ключа можна використовувати новий несоставнимі замісник атрибут, припустимо, номер поставки (Докладні відомості наведені в [1411] і [1421])

У даному прикладі буде використаний перший з двох описаних вище варіантів Таким чином, у визначення SP необхідно додати таке речення

PRIMARY  KEY   {   S#,    P#   }

Як вправа читачеві пропонується самостійно розглянути звязку

PROJ_WORK, PART_STRUCTURE І SUPP_PART_PROJ

Звязки типу багато до одного

У розглянутому прикладі присутні три звязку типу багато до одного.

■ PROJ_MANAGER (між проектами та їх керівниками)

■ DEPT_EMP (між працівниками та відділами)

■ EMP_DEP (між утриманцями і працівниками)

Тільки в останній з трьох звязків бере участь слабкий тип сутності (DEPENDENT), тоді як у двох інших беруть участь тільки звичайні типи сутностей Звязок зі слабким типом сутності обговорюватиметься дещо пізніше, а зараз розглянемо будь-яку з двох інших звязків, наприклад DEPT_EMP У даному випадку не потрібно вводити ніяких нових змінних отношенія5 Замість цього достатньо просто ввести наведений нижче зовнішній ключ в змінну відносини, розташовану з боку багато (ОМР), який буде посилатися на змінну стосунки на стороні один (DEPT)

VAR EMP BASE RELATION

{ОМР # .., DEPT # ..,

… } PRIMARY KEY { EMP#

}

FOREIGN KEY ( DEPT# ) REFERENCES DEPT ON DELETE .. ON UPDATE

У даному випадку можливості визначення правил видалення DELETE І оновлення UPDATE точно такі ж, як і у випадку зовнішнього ключа, що представляє учасника звязку типу багато до багатьох (У загальному випадку) Тут знову слід зазначити, що вони не показані на даній ER-діаграмі

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

типу один до одного наведено в [148]

Слабкі сутності

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

5 Хоча, можливо, це мало б певний сенс Як було зазначено в розділі 143, можуть існувати вагомі причини для такого розгляду певних звязків типу багато до одного, ніби на Насправді вони мають тип / багато до багатьох . Додаткову інформацію можна знайти в частині IV роботи [1919]

ON DELETE CASCADE

ON UPDATE CASCADE

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

VAR DEPENDENT BASE

RELATION {ОМР # .., ..

}

FOREIGN KEY ( EMP# ) REFERENCES EMP ON DELETE CASCADE ON UPDATE CASCADE

Що є первинним ключем даної змінної стосунки Як і у випадку звязків багато до багатьох, виявилося, що існує кілька варіантів Одним з варіантів є комбінація зовнішнього ключа і ключової властивості слабкої сутності, представленого на ER-діаграмі, знову ж таки, якщо розробник бази даних не заперечує проти використання складених первинних ключів Альтернативним варіантом первинного ключа є ключ на основі нового несоставнимізаміщуєатрибута (докладні відомості також наведені в [1411] і [1421]) У розглянутому прикладі ми застосуємо перший з двох наведених вище варіантів, для чого додамо у визначення базової змінної відносини DEPENDENT наступне речення

PRIMARY KEY { EMP#, DEP_NAME }

Тут DEP_NAME – імя утриманця даного працівника

Властивості

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

Супертіпи і підтипи сутностей

Оскільки на рис 141 не міститься ніяких супертіпа або підтипів, далі мова піде про прикладі, представленому на рис 142 Розглянемо типи сутностей EMPLOYEE і PROGRAMMER Припустимо для простоти, що програмісти мають навички роботи тільки з однією мовою программірованія6 (тобто властивість LANG є однозначним)

6 Тут, зокрема, слід зазначити, що ми не збираємося відображати типи сутностей EMPLOYEE і PROGRAMMER на якісь конструкції на зразок супертабліц або підтаблиць. У цьому полягає концептуальна трудність або, принаймні, пастка – з того, що на ER-діаграмі тип сутності Y є підтипом типу сутності X, не випливає, що реляційний аналог сутності Y є Підлеглим реляційного аналога сутності X, і це дійсно так Більш докладно дана тема розглядається в [1413]

■ Супертіп EMPLOYEE відображається на базову змінну відносини, наприклад ОМР, звичайним чином (тобто так, як вже було описано вище)

■ Підтип PROGRAMMER відображається на іншу базову змінну відносини, наприклад PGMR, з таким же первинним ключем, що і у змінної відносини її супертіпа, але з іншим набором атрибутів, відповідним властивостям, кото риє застосовуються для опису тільки працівників, які є программи стами (у нашому прикладі – LANG)

VAR PGMR BASE RELATION { EMP#

…, LANG .. } PRIMARY KEY { EMP# } ..

Більш того, первинний ключ змінної відносини PGMR є також зовнішнім ключем, який посилається на змінну відносини ОМР Отже, наведене вище визначення необхідно відповідним чином розширити (зокрема, зверніть увагу на визначення правил видалення та оновлення)

VAR PGMR BASE RELATION {ОМР # .., LANG ..} PRIMARY KEY {EMP #}

FOREIGN KEY { EMP# } REFERENCES EMP ON DELETE CASCADE ON UPDATE CASCADE

■ Нам також потрібно уявлення, наприклад, з імям EMP_PGMR, являющее ся зєднанням змінних відносини супертіпа і підтипу

VAR EMP_PGMR VIEW

ОМР JOIN PGMR

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

Така структура дозволяє виконувати описані нижче дії

■ За допомогою базової змінної відносини ОМР можна отримати доступ до тих властивостей, які є загальними для всіх працівників (наприклад, для ви вибірки даних або для їх застосування в деяких обмеженнях цілісності)

■ За допомогою базової змінної відносини PGMR МОЖНА отримати доступ до свій

ствам, характерним тільки для програмістів

■ За допомогою представлення EMP_PGMR можна отримати доступ до всьому набору властивостей програмістів

1 У базову змінну відносини ОМР можна вставляти відомості про працівників,

які не є програмістами

■ Відомості про працівників-програмістів можна вставляти в базу даних за допомогою представлення EM7P_PGMR

■ Відомості про будь працівниках (програмістів і не програмістів) можна уда лити з бази даних, видаливши їх з базової змінної відносини ОМР, а відомості

про працівників-програмістів можна видалити з бази даних, видаливши їх з уявлення EMP_PGMR

■ Властивості, загальні для всіх працівників, можна оновлювати в базовій змінної відносини ОМР, а властивості тільки працівників-програмістів – оновлювати і за допомогою представлення EMP_PGMR

■ Властивості, характерні тільки для програмістів, можна оновлювати в базовій пе пасової відносини PGMR

■ Статус співробітника, який не є програмістом, можна змінити на статус програміста за рахунок вставки відомостей про це співробітника в базову змінну відносини PGMR або ж в уявлення EMP_PGMR

■ Статус програміста можна змінити на статус співробітника, який не є програмістом, за рахунок видалення відомостей про це програміста з базової пе пасової відносини PGMR

Пропонуємо читачеві самостійно розглянути інші типи сутностей, показані на рис 142 (APPLICATION_PROGRAMMER І SYSTEM_PROGRAMMER)

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*