Анотація: Лекція присвячена семантичним моделям, які використовуються в сучасних CASE-системах
Инфологическая модель застосовується на другому етапі проектування БД. тобто після словесного опису предметної області. Навіщо потрібна інфологіческая модель і яку користь вона дає проектувальникам? Ще раз хочемо нагадати, що процес проектування тривалий, він вимагає обговорень з замовником, з фахівцями в предметної області. Нарешті, при розробці серйозних корпоративних інформаційних систем проект бази даних є тим фундаментом, на якому будується вся система в цілому, і питання про можливе кредитуванні часто вирішується експертами банку на підставі саме грамотно зробленого інфологічне проекту БД. Отже, інфологіческая модель повинна включати таке формалізоване опис предметної області. яке легко буде "читатися" не тільки фахівцями по базах даних. І це опис має бути настільки ємним, щоб можна було оцінити глибину і коректність опрацювання проекту БД. і звичайно, як говорилося раніше, воно не повинно бути прив'язане до конкретної СУБД. Вибір СУБД - це окреме завдання, для коректного її вирішення необхідно мати проект, який не прив'язаний ні до якої конкретної СУБД.
Інфологіческое проектування перш за все пов'язано зі спробою уявлення семантики предметної області в моделі БД. Реляційна модель даних в силу своєї простоти і лаконічності не дозволяє відобразити семантику, тобто зміст предметної області. Ранні теоретико графові моделі більшою мірою відображали семантику предметної області. Вони в явному вигляді визначали ієрархічні зв'язки між об'єктами предметної області.
Проблема подання семантики давно цікавила розробників, і в сімдесятих роках було запропоновано кілька моделей даних, названих семантичними моделями. До них можна віднести семантичну модель даних. запропоновану Хаммером (Hammer) і Мак-Леоном (McLeon) в 1981 році, функціональну модель даних Шипман (Shipman), також створену в 1981 році, модель "сутність-зв'язок", запропоновану Ченом (Chen) в 1976 році, і ряд інших моделей . У всіх моделей були свої позитивні і негативні сторони, але випробування часом витримала лише остання. І зараз саме модель Чена "сутність-зв'язок", або "Entity Relationship", стала фактичним стандартом при инфологической моделюванні баз даних. Загальноприйнятим стало скорочена назва ER-модель, більшість сучасних CASE-засобів містять інструментальні засоби для опису даних в формалізмі цієї моделі. Крім того, розроблені методи автоматичного перетворення проекту БД з ER-моделі в реляційну, при цьому перетворення виконується в даталогіческую модель, відповідну конкретної СУБД. Всі CASE-системи мають розвинені засоби документування процесу розробки БД. автоматичні генератори звітів дозволяють підготувати звіт про поточний стан проекту БД з докладним описом об'єктів БД і їх відносин як в графічному вигляді, так і у вигляді готових стандартних друкованих звітів, що істотно полегшує ведення проекту.
На даний момент не існує єдиної загальноприйнятої системи позначень для ER-моделі і різні CASE-системи використовують різні графічні нотації, але розібравшись в одній, можна легко зрозуміти і інші нотації.
Модель "сутність-зв'язок"
Як будь-яка модель, модель "сутність-зв'язок" має кілька базових понять, які утворюють вихідні цеглинки, з яких будуються вже більш складні об'єкти за заздалегідь визначеними правилами.
Ця модель найбільшою мірою узгоджується з концепцією об'єктно-орієнтованого проектування, яка в даний момент безсумнівно є базовою для розробки складних програмних систем, тому багато понять вам можуть здатися знайомими, і якщо це дійсно так, то тим простіше вам буде освоїти технологію проектування баз даних , засновану на ER-моделі.
В основі ER-моделі лежать наступні базові поняття:
- Сутність, за допомогою якої моделюється клас однотипних об'єктів. Сутність має ім'я, унікальне в межах системи, що моделюється. Так як сутність відповідає деякому класу однотипних об'єктів, то передбачається, що в системі існує безліч екземплярів даної сутності. Об'єкт, якому відповідав би поняття сутності, має свій набір атрибутів - характеристик, що визначають властивості даного представника класу. При цьому набір атрибутів повинен бути таким, щоб можна було розрізняти конкретні екземпляри сутності. Наприклад, у сутності Співробітник може бути наступний набір атрибутів: Табельний номер, Прізвище, Ім'я, По батькові, Дата народження, Кількість дітей, Наявність родичів за кордоном. Набір атрибутів, однозначно ідентифікує конкретний екземпляр сутності. називають ключовим .Для суті Співробітник ключовим буде атрибут Табельний номер, оскільки для всіх співробітників даного підприємства табельні номери будуть різні. Екземпляром сутності Співробітник буде опис конкретного співробітника підприємства. Одне із загальноприйнятих графічних позначень суті - прямокутник, у верхній частині якого записано ім'я суті, а нижче перераховуються атрибути, причому ключові атрибути позначаються, наприклад, підкресленням або спеціальним шрифтом (рис. 7.1):
Мал. 7.1. Приклад визначення сутності в моделі ER
Між сутностями можуть бути встановлені зв'язки - бінарні асоціації. показують, яким чином сутності співвідносяться або взаємодіють між собою. Зв'язок може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок) .Вона показує, як пов'язані екземпляри сутностей між собою. Якщо зв'язок встановлюється між двома сутностями, то вона визначає взаємозв'язок між екземплярами однієї й іншої сутності. Наприклад, якщо у нас є зв'язок між сутністю "Студент" та сутністю "Викладач" і цей зв'язок - керівництво дипломними проектами, то кожен студент має тільки одного керівника, але один і той же викладач може керувати великою кількістю студентів-дипломників. Тому це буде зв'язок "один-ко-многим" (1: М), один з боку "Викладач" і багато з боку "Студент" (див. Рис. 7.2).
Мал. 7.2. Приклад відносини "один-ко-многим" при зв'язуванні сутностей "Студент" та "Викладач"
У різних нотациях потужність зв'язку зображується по-різному. У нашому прикладі ми використовуємо нотацію CASE системи POWER DESIGNER, тут множинність зображується шляхом поділу лінії зв'язку на 3. Зв'язок має загальне ім'я "Дипломне проектування" і має імена ролей з боку обох сутностей. З боку студента ця роль називається "Пише диплом під керівництвом", з боку викладача цей зв'язок називається "Керує". Графічна інтерпретація зв'язку дозволяє відразу прочитати зміст взаємозв'язку між сутностями, вона наочна і легко інтерпретованих. Зв'язки діляться на три типи по множинності: один-до-одного (1: 1), один-ко-многим (1: M), багато-до-багатьох (M: M). Зв'язок один-до-одного означає, що екземпляр однієї сутності пов'язаний тільки з одним екземпляром іншої сутності. Зв'язок 1: M означає, що один екземпляр сутності. розташований зліва по зв'язку, може бути пов'язаний з декількома екземплярами сутності, розташованими праворуч по зв'язку. Зв'язок "один-до-одного" (1: 1) означає, що один екземпляр однієї сутності пов'язаний тільки з одним екземпляром іншої сутності, а зв'язок "багато-до-багатьох" (M: M) означає, що один екземпляр першої суті може бути пов'язаний з декількома екземплярами другої суті, і навпаки, один примірник другої сутності може бути пов'язаний з декількома екземплярами першої сутності. Наприклад, якщо ми розглянемо зв'язок типу "Вивчає" між сутностями "Студент" та "Дисципліна", то це зв'язок типу "багато-до-багатьох" (M: M), тому що кожен студент може вивчати кілька дисциплін, а й кожна дисципліна вивчається безліччю студентів. Такий зв'язок зображена на рис. 7.3.
Мал. 7.3. Приклад моделювання зв'язку "багато-до-багатьох"
Мал. 7.4. Приклад обов'язкової і необов'язкової зв'язку між сутностями