Створення та обробка баз даних на ПЕОМ (стр. 8 )

3.2. Модель “сутність-зв'язок”

Модель “сутність-зв'язок” є найбільш розповсюдженим у даний час підходом до побудови БД. Її застосування по суті справи стала діючим стандартом при інфологічному проектуванні БД. Загальноприйнятим стало скорочене найменування ER-модель (Essence – сутність, Relation – зв'язок).

ER-модель добре співвідноситься з концепцією об'єктно-орієнтованого проектування і тому використовується в різних програмних засобах автоматизованого проектування систем (у так званих CASE-системах). Найбільш розповсюдженими засобами інфологічного проектування на даний час є, наприклад, програмні системи ERwin, POWER DESIGNER та ін.

Розглянемо коротко базові поняття ER-моделі (багато з них вам покажуться знайомими, тому що вони зв’язані з поняттями реляційної моделі даних).

Поняттям сутність представляється клас однотипних об'єктів. Передбачається, що існує множина екземплярів даної сутності, що представляють реальні об'єкти предметної області. Об'єкт, якому відповідає дана сутність, має свій набір атрибутів – характеристик, що описують властивості даного об'єкта. При цьому набір атрибутів повинний бути таким, щоб можна було розрізняти конкретні екземпляри даної сутності. Графічно сутність прийнято зображувати прямокутником, у верхній частині якого записується ім'я сутності, а нижче перелічуються всі атрибути даної сутності. На Рис. 3.2 показаний приклад зображення сутності “Співробітник”.

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

Рис. 3.2. Зображення сутності “Співробітник”

Між сутностями завжди встановлюються зв'язки, тому що всі об'єкти реального світу зв'язані між собою. Зв'язкам привласнюються найменування. Наприклад, між сутностями “Студент” і “Викладач” може існувати зв'язок “Читає лекції”. На схемі моделі зв'язки позначаються лініями, що з'єднують значки відповідних сутностей. Наприклад, так, як це показано на Рис. 3.3.

Дипломне

проектування

 

Читає лекції

Рис. 3.3. Зображення зв'язку між сутностями

Зв'язки між сутностями можуть бути типів “один до одного” (1:1), “один до кількох” (1:М) чи “кілька до кількох” (М:М).

Зв'язок типу “один до одного” (1:1) означає, що один екземпляр першої сутності зв'язаний тільки з одним екземпляром другої сутності.

Зв'язок типу “один до кількох” (1:М) означає, що один екземпляр першої сутності може бути зв'язаний з декількома екземплярами другої сутності, але кожен екземпляр другої сутності - зв'язан тільки з одним екземпляром першої сутності.

Зв'язок типу “кілька до кількох” (М:М) означає, що один екземпляр першої сутності може бути зв'язаний з декількома екземплярами другої сутності і навпаки, кожен екземпляр другої сутності може бути зв'язаний з декількома екземплярами першої сутності.

У розглянутому вище прикладі зв'язок “Читає лекції” є зв'язком типу “один до кількох”, причому першою сутністю тут є “Викладач”, а другою – “Студент”.

У різних CASE-системах використовуються різні способи позначення типів зв'язків. Наприклад, у системі POWER DESIGNER прийнято зв'язок “один до кількох” позначати потрійною лінією з боку “кілька” (приблизно так, як це показано на Рис. 3.3). Між двома сутностями може бути встановлено як завгодно багато зв'язків. Наприклад, між сутностями “Студент” і “Викладач” ще може бути встановлений зв'язок “Дипломне проектування”. Очевидно, що цей зв'язок так само є зв'язком типу “один до кількох” – один викладач може керувати дипломною роботою декількох студентів, але кожен студент може мати тільки одного керівника дипломного проекту. Зв'язки будь-якого типу можуть бути обов'язковими чи необов'язковими. Якщо в даному зв'язку повинен брати участь кожен екземпляр сутності, то зв'язок у даному випадку є обов'язковим, а якщо не кожен екземпляр – то необов'язковим. При цьому зв'язок може бути обов'язковим з однієї сторони і необов'язковим з іншої сторони. Обов'язковий зв'язок на схемі прийнято позначати кружечком, а необов'язковий – перпендикулярною лінією, що перекреслює лінію зв'язку. На Рис. 3.3 зв'язок “Дипломне проектування” з боку студента є обов'язковим, а з боку викладача – необов'язковим. Дійсно, кожен студент-дипломник повинен обов'язково мати керівника дипломного проекту, але не кожен викладач є керівником дипломного проекту.

3.3. Наслідування сутностей

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

Пояснити ідею типів і підтипів можна на такому прикладі. Нехай, мається сутність “Цех”, у якій представлені атрибути, загальні для будь-яких цехів. На підприємстві є багато цехів, що істотно розрізняються по призначенню, складу устаткування і, отже, по атрибутах, за допомогою яких можна описувати їхні характеристики. У цьому випадку доцільно для сутності “Цех” увести підтипи, у яких визначити необхідні специфічні атрибути. Наприклад, підтипами тут можуть бути: “Інструментальний цех”, “Ливарний цех”, “Склад готової продукції” і т. д. На Рис. 3.4 зображено приклад діаграми, що описує підтипи сутності “Цех”.

Сутність, на основі якої будуються підтипи, часто називають супертипом. На діаграмах для зображення зв'язку супертипу з підтипами сутностей використовується вузол-дискримінатор, що зображується у виді півкола, зверненого опуклою стороною до супертипу (як на Рис. 3.4). Множина підтипів повинна бути вичерпною, тобто включати всі можливі варіанти представлення даної сутності в підтипах. Для цього, при необхідності, може вводитися підтип “Інші”. У результаті розробки інформаційно-логічної моделі повинний бути отриманий зв'язний граф, у вузлах якого розташовуються введені сутності, зв'язані необхідними зв'язками. В отриманому графі не повинне бути циклічних зв'язків. Наявність циклічних зв'язків свідчить про некоректність моделі.

У завершення даного розділу розглянемо простий приклад моделі “сутність-зв'язок”. Для прикладу візьмемо учбову БД, у якій необхідно зберігати інформацію про успішність студентів. Нехай у наслідок системного аналізу предметної області були визначені такі сутності: Група, Студент, Предмет, Викладач, Успішність.

 

Рис. 3.4. Діаграма підтипів сутності “Цех”

Розроблена схема моделі “сутність-зв'язок” може бути такою, що зображена на Рис. 3.5. Пояснимо найбільш важливі елементи й особливості цієї схеми.

Між сутностями “Група” і “Студент” мається зв'язок “Належить”. Зв'язок є обов'язковим і тип зв'язку – “один до кількох”. У кожну групу повинні обов'язково входити більш одного студента. Кожен студент обов'язково входить до складу якої-небудь однієї групи.

У сутності “Успішність” представляються оцінки, отримані студентами на заняттях у різний час. Зв'язок між сутностями “Студент” і “Успішність” має назву “Бере участь на заняттях”. Зв'язок має тип “1:М”, тому що один студент може мати кілька оцінок чи ні однієї. Тому зв'язок є обов'язкової з боку сутності “Успішність” і необов'язкової з боку сутності “Студент”.

Зв'язок між сутностями “Предмет” і “Успішність” може мати назву “Заняття по предметах”. Тип зв'язку – “1:М”. По кожному предмету можуть бути отримані ні однієї чи кілька оцінок, але кожна оцінка завжди відноситься до якого-небудь одного предмету.

Зв'язок між сутностями “Викладач” і “Предмет” має назву “Викладає”. Тип зв'язку можна вважати “1:М” з урахуванням того, що кожен предмет веде тільки один викладач (якщо викладачів два, то основний завжди один). Зв'язок є обов'язковим.

Первинні ключі сутностей виділено напівжирним шрифтом.

 

Належить Викладає

 

Студент

Група

 

Заняття

Бере участь по предметах