Моделювання та проектування баз даних в інформаційних системах. Частина 3, CASE-засоби (моделювання), Програмування, статті

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

СТАВЛЕННЯ

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


Кожен тип відносин описує особливий спосіб зв’язку двох порцій даних.


Відношення “один до одного”


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


Відношення “один до багатьох”


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


Відношення “багато до багатьох”


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


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


ДОМЕНИ


У ході розробки моделі даних та визначення атрибутів для кожної сутності майже завжди знаходяться атрибути, які існують в декількох сутності, оскільки є досить загальними типами даних. Наприклад, можна зберігати в базі даних адреси клієнтів, постачальників і співробітників. Кожен з цих об’єктів представляє собою явну і окрему сутність, і для кожного з них необхідно зберігати адресу. Щоб забезпечити несуперечність, можна створити домени атрибутів, які будуть однаковими у всіх сутності. Домен – це визначення атрибута, яке міститься в логічній моделі, але не прив’язане безпосередньо до якої-небудь даної сутності. Якщо ви створили домен, то можете додати цей домен до відповідних сутностей, після чого даний домен відображається в даних сутності як атрибут. Однак такий атрибут не можна змінювати в даній сутності до тих пір, поки він не буде виділений з домена. Це дозволяє гарантувати цілісність даних у всіх сутності, що мають одні й ті ж атрибути. Отже, ми можемо створити домен “адреса”, що визначає тип даних і довжину поля для запису адреси. Це трохи спростить код програми, так як завжди відомо, як саме вводити інформацію про адресу, незалежно від сутності.


НОРМАЛИЗАЦИЯ


Нормалізація – це процес групування даних логічним чином, що дозволяє уникнути дублювання та ускладненості даних. Існує багато рівнів (або форм) нормалізації, кожен наступний рівень є більш суворим, ніж попередній; ми розглянемо всі форми, щоб вам було легше розібратися, в які моменти в процес втручаються обмеження реального світу. Перші правила нормалізації були розроблені Е. Ф. Коддом (EF Codd), співробітником дослідного сектора IBM. Правила застосовуються як послідовний ряд форм моделі даних, причому кожна наступна форма є більш суворою, ніж попередня. Спочатку було розроблено всього три форми, а проте в ході подальших досліджень були виявлені деякі потенційні проблеми з оновленням даних, тому були додані ще дві форми, що дозволяють уникнути цих проблем. Загальне назва форм – нормальні форми; їх назви відповідають їх положенню в послідовності за невеликим винятком, про який мова піде далі.


Перша нормальна форма (1НФ) Щоб модель даних відповідала 1 нормальній формі, все сутності в моделі повинні мати первинні ключі. Первинний ключ сутності являє собою атрибут або набір атрибутів, що визначають унікальний примірник у цій сутності. Очевидно, що первинний ключ ніколи не може мати значення null, оскільки це атрибут, який визначає всі екземпляри. Крім того, ніякі два примірники не можуть мати однакові значення в якості своїх первинних ключів. 1 нормальна форма також вимагає, щоб в моделі не було повторюваних груп. Повторювана група – це група, в якій будь-який атрибут має кілька значень, пов’язаних з одним значенням в іншому атрибуті того ж примірника. Якщо, наприклад, у нас є сутність Виконавці, в якій зберігається інформація про записуючих альбоми виконавців, ймовірно, у нас є і назви записаних ними альбомів. Якщо який-небудь виконавець записав більше одного альбому, то ми могли б створити атрибут НазваніеАльбома, в якому зберігалися б назви альбомів для кожного виконавця. Однак насправді у вас є кілька значень одного атрибута (НазваніеАльбома), які пов’язані з одним значенням (ІмяІсполнітеля) для одного екземпляра. Щоб виправити ситуацію, вам доведеться виділити альбоми в окрему сутність і створити відношення між цими двома сутностями.


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


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


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


Наприклад, у нас є сутність Виріб, первинним ключем якої є ІдентіфікаторІзделія (числовий ідентифікатор вироби), НазваніеІзделія і ІдентіфікаторСклада (що дозволяє ідентифікувати місце зберігання вироби). Решта атрибути в даній сутності – це АдресСклада, ОпісаніеІзделія, НазваніеПоставщіка і ІдентіфікаторПоставщіка. Очевидно, що атрибут АдресСклада не пов’язаний безпосередньо з ім’ям вироби, тому що склад має адресу незалежно від того, які вироби в ньому зберігаються. Тому цілком імовірно, що потрібно створити сутність Склад, а сутність Вироби буде мати відношення до цієї суті, визначальною місце зберігання кожного виробу.


Читати частина 4

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


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

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

Ваш отзыв

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

*

*