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

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

■ Строгість – кількість обєктів, які можуть існувати на кожному кінці відносини

■ Обовязковість – чи є ставлення обовязковим

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

Вторинні сутності та зовнішні ключі

Коли два обєкти повязані ставленням, одна з сутностей, як правило, є головною, а друга – підлеглою, чи вторинною Один обєкт у головній суті може бути повязаний з численними обєктами у вторинній, як показано на рис 21

Рис 21 Ставлення один до багатьох складається з головної та вторинної сутностей Зовнішній ключ вторинної сутності повязаний з первинним ключем головною

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

Строгість відносини

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

Існують різні можливі варіанти строгості всі вони перераховані в табл 22 У цьому розділі ми детально розглянемо кожен з цих варіантів

Таблиця 22 Строгість відносин

Тип відносини

Ключ першої сутності

Ключ другий сутності

Один до одного

Первинний ключ головною сутності – один

Первинний ключ головною сутності –

обєкт

один обєкт

Один до багатьох

Первинний ключ головною сутності – один

Зовнішній ключ вторинної сутності –

обєкт

безліч обєктів

Багато до багатьох

1 Зовнішній ключ головною сутності – мно

Зовнішній ключ вторинної сутності –

жество обєктів

безліч обєктів

Обовязковість відносин

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

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

■ Рядок замовлення без самого замовлення безглузда

■ Замовлення без замовника не має сенсу

■ У базі даних турагентства подія, не привязане до деякого туру, безглуздо

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

■ Замовник, який не має дисконтної картки, все одно залишається клієнтом

■ Замовлення може мати і не мати код пріоритету – в будь-якому випадку він залишається замовленням

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

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

У деяких окремих ситуаціях потрібно поставити обовязковість у залежність від деякої умови Залежно від правил відношення може встановлюватися в таких випадках

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

Якщо використовується атрибут ідентифікатор товару, то він повинен вказувати на коректний первинний ключ сутності товару

■ Якщо ж використовується атрибут замовного товару, то атрибут ідентифікатора товару залишається порожнім

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

Діаграма моделі даних

Ті, хто займається моделюванням даних для графічного відображення створюваних моделей, використовують кілька методів Популярним є ER-метод Чена, а система Visio Professional містить ще пять інших методів Метод, який віддаю перевагу особисто я, – найпростіший Він припускає замальовку схеми на дошці, як показано на рис 22 Строгість відносини відображається одним або трьома лініями (куряча лапа) Якщо відношення необовязкове, то близько зовнішнього ключа поміщається коло

Рис 22 Простий метод відображення на діаграмах логічних схем

Ще однією перевагою цього простого методу побудови діаграм є те, що він не вимагає установки розширеної версії програми Visio

Відносини один до багатьох

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

■ Кожен клієнт може розмістити безліч замовлень Кожне замовлення має свій унікальний первинний ключ OrderlD (ідентифікатор замовлення) сутність Order (замовлення) також має вторинний ключ Customer ID (ідентифікатор клієнта), який вказує

■ У базі даних турагентства Cape Hatteras Adventures кожен базовий табір може мати кілька турів, які беруть в ньому початок Кожен тур може починатися тільки з одного базового табору таким чином, один табір повязаний відношенням один до багатьох з декількома турами Ставлення встановлюється між первинним ключем сутності Base Camp (базові табори) і зовнішнім ключем сутності Tour (тури) (рис 23) Кожен атрибут зовнішнього ключа таблиці Tour містить копію первинного ключа таблиці Base Camp

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

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

■ Благодійна організація може отримувати щорічні внески своїх спонсорів Як тільки спонсор вносить щорічний платіж, він заноситься в другу сутність, яка може зберігати дані про внески за багато років Структура цієї сутності може бути наступною: DonorName, 2 001pledge, 2 002pledge, але можливі й інші варіанти

■ Замовлення може мати кілька рядків Первинний ключ сутності Order дублюється у вторинному ключі сутності OrderDetail Кожне замовлення має один елемент у сутності Order, але може мати безліч асоційованих елементів в сутності OrderDetail

Ставлення один до одного

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

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

Відносини між підтипом і супертіп

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

Джерело: Нільсен, Пол 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>

*

*