Реляційні шаблони – ЧАСТИНА 2

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

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

Якщо партнер є клієнтом, то його додаткова інформація заноситься в сутність Customer якщо він постачальник-в сутність Supplier При цьому всі три сутності (Contact, Customer і Supplier) мають один і той же первинний ключ Один елемент в сутності Contact не обовязково може бути повязаний з одним елементом в сутності Customer і (або) з одним елементом в сутності Supplier (рис 24)

Рис 24 Ставлення один до одного повязує первинний ключ з іншим первинним ключем

Більшість моделей супертіп-підтип допускає наявність тільки одного елемента підтипу для кожного елемента супертіпа Водночас у наведеному прикладі інформації

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

Додаткова Модель супертіп-підтип дуже схожа з концепцією успадкування класів у інформація обєктно-орієнтованому аналізі Таким чином, якщо база даних містить кілька моделей супертіп-підтип, то база даних може вважатися кандидатом на обєктно-реляційний стиль замість реляційного Обєктно-реляційні СУБД для SQL Server можна завантажити з сайту www SQLServerBible com

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

Ставлення багато до багатьох

У відносинах типу багато до багатьох обидві сторони можуть бути повязані з безліччю елементів протилежної сторони Ставлення багато до багатьох часто зустрічається в реальному житті Наведу кілька прикладів

■ Замовлення може містити кілька товарів, а кожен товар може перебувати в безлічі замовлень

■ У базі даних турфірми Cape Hatteras Adventures екскурсовод може бути кваліфікований для ведення декількох турів, а кожен тур може мати кілька кваліфікованих екскурсоводів

■ У базі даних турфірми клієнт може брати участь у декількох турах, а кожен тур може мати безліч учасників

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

Відносини один до одного і багато до багатьох можуть проектуватися з обєктів, які користувачі здатні описати і зрозуміти У фізичній схемі відношення багато до багатьох не може бути змодельоване за допомогою тільки видимих ​​обєктів

Для дозволу відносини багато до багатьох використовується асоційована таблиця (рис 26), іноді звана стикувальній Ця таблиця штучно створює два відносини один до багатьох між двома сутностями

Puc 25 Логічна модель uбагато до багатьох містить безліч елементів з кожної зі сторін відносини

Рис 26 Фізична модель відносини багато до багатьох включає стикувальну таблицю, що має відношення один до багатьох до обох сутностей

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

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

Сутності категорій

Ще одним типом підтримуючої сутності є сутність категорій, іноді звана таблицею класифікаторів Ці сутності забезпечують цілісність домену в сенсі способу організації елементів Відмінним прикладом може служити таблиця штатів США Замість того щоб в таблиці клієнтів атрибут регіону міг приймати некоректні значення (наприклад, F1 або FLA для штату Флорида), ця таблиця повязана з таблицею штатів, в якій всі ці назви завідомо коректні Така цілісність даних прискорює і полегшує пошук і сортування даних

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

Зворотні відносини

У деяких випадках ставлення встановлюється між двома елементами одного і того ж типу Наведемо кілька прикладів

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

■ Список матеріалів деталізує, як один матеріал виходить з інших матеріалів

■ У базі даних сімей деяка особа має відношення до своєї матері та батька

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

Використовуючи базу даних сімей як приклад, кожен елемент в сутності Person представляє одну людину Кожна людина має (як правило) і матір, і батька, які також знаходяться в сутності Person Таким чином, зовнішні ключі MotherlD (ідентифікатор матері) і FatherlD (ідентифікатор батька) вказують відповідно на елементи матері і батька в тієї ж сутності

Так як первинним ключем є PersonID (ідентифікатор людини), a MotherlD – зовнішнім, встановлюється відношення один до багатьох (рис 27) Одна мати може мати кілька дітей, проте кожна дитина має одну і тільки одну матір

Рис 27 Зворотний, або рекурсивне, відношення являє собою відношення іодин до багатьох в межах однієї сутності

Більш складним прикладом є список матеріалів, так як кожен матеріал може бути створений на основі кількох вихідних і в той же час використовуватися для виготовлення ряду інших матеріалів на наступній стадії виробничого процесу Це рекурсивне ставлення багато до багатьох проілюстровано на рис 28

Рис 28 Логічна схема поворотного відносини багато до багатьох демонструє наявність кількох елементів на кожному кінці відносини

Для дозволу відносин багато до багатьох потрібно звязує сутність У прикладі таблиці матеріалів звязує сутність BillOfMaterials має два зовнішніх ключа, кожен з яких вказує на сутність Material (рис 29)

Перший зовнішній ключ вказує на створюваний матеріал, а другий – на вихідний

Puc 29 Фізична схема бази даних поворотного відносини багато до багатьох повинна містити звязує сутність, як і в звичайних відносинах

Нормалізація

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

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

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*