Кількість сутностей на кожній стороні зв'язку називається. Модель даних «сутність-зв'язок. Контрольний список питань до атрибутів

Однією з найбільш популярних засобів формалізованого представлення предметної області систем, орієнтованих на обробку фактографічної інформації, є модель «сутність - зв'язок», яка покладена в основу значної кількості комерційних CASE-продуктів, що підтримують повний цикл розробки систем баз даних або окремі його стадії. При цьому багато хто з них не тільки підтримують стадію концептуального проектування предметної області розробляється, але і дозволяють здійснити на основі побудованої їх засобами моделі стадію логічного проектування шляхом автоматичної генерації концептуальної схеми бази даних для обраної СУБД, наприклад, схеми бази даних для будь-якого SQL -сервера або об'єктної СУБД.

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

Семантичну основу ER-моделі складають такі припущення:

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

кожна сутність має характеристичні властивості (атрибутами), що відрізняють її від інших сутностей і дозволяють її ідентифікувати;

суті можна класифікувати за типами сутностей: кожен екземпляр сутності (що представляє деякий об'єкт) може бути віднесений докласу - типу сутностей,кожен екземпляр якого володіє загальними для них і відрізняють їх від сутностей інших класів властивостями;

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

взаємозв'язку об'єктів можуть бути представлені як зв'язку-суті,які служать для фіксування (подання) взаємозалежності двох або декількох сутностей.

Тут слід ще раз підкреслити інформаційну природу поняття сутністьі його співвідношення з матеріальними або уявними об'єктами предметної області. Будь-який об'єкт предметної області має властивості, частина з яких виділяється як характеристичні - значущі з точки зору прикладної задачі. При цьому, наприклад, в процесі аналізу і систематизації предметної області зазвичай виділяються класи -сукупності об'єктів, що володіють однаковим набором властивостей, що задаються у вигляді наборів атрибутів(Значення атрибутів для об'єктів одного класу, природно, можуть змінюватися). Відповідно, на рівні уявлення предметної області (т. Е. Її инфологической моделі) об'єкту, що розглядається як поняття (об'єкт у свідомості людини), відповідає поняття сутність;об'єкту, як частини матеріального світу (і існуючого незалежно від свідомості людини), відповідає поняття екземпляр сутності;класу об'єктів відповідає поняття тип сутності.

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

ER-модель,як опис предметної області, повинна визначити об'єкти і взаємозв'язки між ними, т. е. встановити зв'язки наступних двох типів.

1. Зв'язки між об'єктами і наборами характеристичних властивостей, і таким чином визначити самі об'єкти.

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

Як було зазначено раніше, ER-моделювання предметної області базується на використанні графічних діаграм, як простого (звичного), наочного і в той же час інформативного та багатоаспектного способу відображення компонентів проекту. Тому виклад основних положень ER-моделі буде ілюструватися матеріалом прикладу ER-діаграми, наведеного на рис. 5.4.

Сутність.Сутність, за допомогою якої моделюється клас однотипних об'єктів, визначається в як «предмет, який може бути чітко ідентифікований». Так само як кожен об'єкт унікально характеризується набором значень властивостей, сутність повинна визначатисятаким набором атрибутів,який дозволяв би розрізняти окремі екземпляри сутності. Кожен екземпляр суті повинен бути відрізнити від будь-якого іншого примірника тієї ж сутності (це вимога аналогічно вимогу відсутності кортежів-дублікатів в реляційних таблицях). Наприклад, для однозначної ідентифікації кожного екземпляра сутності «Співробітник» вводиться атрибут «Табельний номер», який внаслідок своєї природи буде завжди мати унікальне значення в рамках підприємства. Тобто, унікальним ідентифікатором сутності може бути атрибут, комбінація атрибутів, комбінація зв'язків або комбінація зв'язків та атрибутів, однозначно що відрізняє будь-який екземпляр сутності від інших екземплярів сутності того ж типу.

сутність має ім'я,унікальне в межах моделі. При цьому ім'я сутності -це ім'я типу,а не деякого конкретного екземпляра.

Сутності поділяються на сильніі слабкі.Сутність є слабкою, якщо її існування залежить від іншої сутності сильної по відношенню кней. Наприклад, сутність «Підлеглий» є слабкою по відношенню досуті «Співробітник»: якщо буде відсутній запис, відповідна деякого співробітникові, що має підлеглих, то відомості про підпорядкування також повинні бути видалені.

Властивості.Природа властивості, як характер зв'язкувластивості з сутністю (об'єктом), може бути різною. Розглянемо основні види властивостей.

Властивість може бути множиннимабо одиничним -т. е. атрибут, що задає властивість, може одночасно мати кілька значень або, відповідно, тільки одне. Наприклад, співробітник може мати кілька спеціальностей, але єдине значення - «Табельний номер».

Властивість може бути простим(Що не підлягає подальшому поділу з точки зору прикладних задач) або складовим -якщо його значення складається зі значень простих властивостей. Наприклад, властивість «Рік народження» є простим, а властивість «Адреса» - складовим, так як включає значення простих властивостей «Місто», «Вулиця», «Дім».

У деяких випадках корисно розрізняти базовіі похіднівластивості. Наприклад, «Постачальник» може мати властивість «Загальна кількість поставляються деталей», яке обчислюється підсумовуванням кількості деталей, що поставляються їм за проектом.

Якщо наявність деякого властивості для всіх примірників суті не є обов'язковим, то така властивість називається умовним.Наприклад, не всі співробітники мають властивість «вчений ступінь».

Значення властивостей можуть бути постійними - статичнимиабо динамічними,т. е. змінюватися з часом. Наприклад, властивість «Табельний номер» є статичним, а «Адреса» - динамічним. Властивість може бути невизначеним,якщо воно є динамічним, але його поточне значення ще не задано.

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

Зв'язки.Крім зв'язків між об'єктом і його властивостями, інфологіческая модель відображає зв'язки між об'єктами різних класів. В зв'язоквизначається як «асоціація, яка об'єднує кілька сутностей». Ця асоціація завжди може існувати між різними сутностями або між сутністю і яку сама ж (рекурсивна зв'язок).

Як і сутність, зв'язок є типовимпоняттям, т. е. все екземпляри пов'язують сутностей підкоряються правилам зв'язування типів. Принциповість відмінності типів зв'язків між типами і екземплярами ілюструється ER-діаграммамідля типів і примірників, представленими на рис. 5.5.

Суті, що об'єднуються зв'язком, називаються учасниками. ступінь зв'язкувизначається кількістю учасників зв'язку.

Якщо кожен екземпляр сутності бере участь, принаймні, в одному екземплярі зв'язку, то така участь цієї сутності називається повним(або обов'язковим);в іншому випадку - неповним(або необов'язковим).

Кількісний характер участі примірників сутностей (один або багато) задається типом зв'язку(або потужністю зв'язку),Можливі наступні типи: "один до одного"(1:1), «Один до багатьох»(1: М), «Багато до одного»(М: 1), «Багато до багатьох»(М: М).

Слід зазначити, що інструмент зв'язків - це засіб представлення складних об'єктів,кожен з яких може розглядатися як безліч певним чином взаємопов'язаних простих об'єктів.Розподіл на прості і складні об'єкти, також як і характер взаємозв'язку, є умовним і визначається особливостями аналізу предметної області, т. Е. В кінці концов- характером використання даних опредметіть в розв'язуваних прикладних задачах. При цьому з точки зору, наприклад, конструктора, ДЕТАЛЬ є складним об'єктом, а з точки зору постачальника - простим.

Серед багатьох різновидів взаємозв'язків найбільш частими є такі відносини ієрархічного типу, як «частина - ціле», «рід - вид».

Ставлення «частина - ціле» використовуються для подання складових об'єктів.Наприклад, МАШИНИ складаються з ВУЗЛІВ, ВУЗЛИ складаються з ДЕТАЛЕЙ. Тут можливі як відносини «Один до багатьох»,так і «Багато до багатьох».

Ставлення «рід - вид» - для подання узагальнених об'єктів. Наприклад, СПІВРОБІТНИКИ поділяються за професією на КОНСТРУКТОРІВ, ПРОГРАМІСТІВ, РОБОЧИХ; ПРОГРАМІСТИ - на ПРИКЛАДНИХ ПРОГРАМІСТІВ і СИСТЕМНИХ ПРОГРАМІСТІВ. Ієрархічні відносини, і зокрема - «родо-видові», зазвичай використовуються як основа класифікації об'єктів за розділами характеристичних ознак. Причому «видові» об'єкти успадковуютьвластивості «родових».

Інший широко використовуваним різновидом взаємозв'язку є агрегування - об'єднання простих об'єктів в складний за принципом їх належності агрегатуабо їх спільної участі в деякому процесі. Агрегування, що розглядається тут як більш загальний випадок ієрархічних відносин, об'єднує об'єкти різної природи з єдиним спільним властивістю «спільна участь». Агреговані об'єкти іменуються зазвичай віддієслівним іменниками, наприклад, «Склад»:ПІДРОЗДІЛ складається зСПІВРОБІТНИКІВ; «Поставка»:ПОСТАЧАЛЬНИК поставляєДЕТАЛІ.

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

Сутність, на основі якої визначаються підтипи, називається супертіп.Підтипи повинні утворювати повне безліч, т. Е. Будь-який екземпляр супертіпа повинен ставитися до деякого підтипу. Іноді для повноти безлічі треба визначати додатковий підтип, наприклад, ІНШІ.

Підтип успадковує властивості і зв'язку супертіпа. Наприклад, тип сутності ПРОГРАММИСТє підтипом суті СПІВРОБІТНИК.Програмісти мають всі властивості співробітників і беруть участь у всіх зв'язках, проте зворотні твердження невірні.

Тип сутності, його підтипи, підтипи цих підтипів і т. Д. Утворюють ієрархію типів суті,приклад якої наведено на рис. 5,6.

У реальному проектуванні структури бази даних застосовується метод - так зване, семантичне моделювання. Семантичне моделювання являє собою моделювання структури даних, спираючись на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм сутність-зв'язок(ER - Entity-Relationship).

Перший варіант моделі сутність-зв'язок був запропонований в 1976 р Пітером Пін-Шен Ченом. Надалі багатьма авторами були розроблені свої варіанти подібних моделей (нотація Мартіна, нотація IDEF1X, нотація Баркера та ін.). Крім того, різні програмні засоби, Що реалізують одну й ту ж нотацію, можуть відрізнятися своїми можливостями. По суті, всі варіанти діаграм сутність-зв'язок виходять з однієї ідеї - малюнок завжди наочніше текстового опису. Всі такі діаграми використовують графічне зображення сутностей предметної області, їх властивостей (атрибутів), і взаємозв'язків між сутностями.

Ми опишемо роботу з ER-діаграмами близько до нотації Баркера, як досить легкою в розумінні основних ідей. Дана глава є скоріше ілюстрацією методів семантичного моделювання, ніж повноцінним введенням в цю область.

Основні поняття ER-діаграм

визначення 1: сутність- це клас однотипних об'єктів, інформація про яких повинна бути врахована в моделі.
Кожна сутність повинна мати найменування, виражене іменником в однині. Прикладами сутностей можуть бути такі класи об'єктів як "Постачальник", "Співробітник", "Накладна". Кожна сутність в моделі зображується у вигляді прямокутника з найменуванням:

Мал. 1

визначення 2: примірник сутності- це конкретний представник даної суті.
Наприклад, представником суті "Співробітник" може бути "Співробітник Іванов". Примірники сутностей повинні бути помітні, тобто суті повинні мати деякі властивості, унікальні для кожного екземпляра цієї сутності.

визначення 3: Атрибут суті- це іменована характеристика, що є деяким властивістю сутності.
Найменування атрибута повинно бути виражено іменником в однині (можливо, з характеризують прикметниками). Прикладами атрибутів сутності "Співробітник" можуть бути такі атрибути як "Табельний номер", "Прізвище", "Ім'я", "По батькові", "Посада", "Зарплата" і т.п. Атрибути зображуються у межах прямокутника, що визначає сутність:

Мал. 2

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

Мал. 3

визначення 5: зв'язок- це деяка асоціація між двома сутностями. Одна сутність може бути пов'язана з іншого сутністю або сама з собою.
Зв'язки дозволяють по одній сутності знаходити інші сутності, пов'язані з нею. Наприклад, зв'язку між сутностями можуть виражатися наступними фразами - "СПІВРОБІТНИК може мати кілька ДІТЕЙ", "кожен СПІВРОБІТНИК зобов'язаний числитися рівно в одному ВІДДІЛІ". Графічно зв'язок зображується лінією, що з'єднує дві сутності:

Мал. 4

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

Кожна зв'язок може мати один з наступних типів зв'язку:

Мал. 5

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

зв'язок типу один-ко-многимозначає, що один екземпляр першої суті (лівою) пов'язаний з декількома екземплярами другої суті (правою). Це найбільш часто використовуваний тип зв'язку. Ліва сутність (з боку "один") називається батьківської, Права (з боку "багато") - дочірньої. Характерний приклад такого зв'язку наведено на Рис. 4.

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

Кожна зв'язок може мати одну з двох модальностей зв'язку:

Мал. 6

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Кожна зв'язок може бути прочитана як зліва направо, так і справа наліво. Зв'язок на Рис. 4 читається так:

Зліва направо: "кожен співробітник може мати кілька дітей".
Справа наліво: "Кожна дитина має належати рівно одному співробітнику".

Приклад розробки простий ER-моделі

При розробці ER-моделей ми повинні отримати наступну інформацію про предметну область:

1. Список сутностей предметної області.
2. Список атрибутів сутностей.
3. Опис взаємозв'язків між сутностями.

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

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

Наприклад, в ході бесіди з менеджером з продажу, з'ясувалося, що він (менеджер) вважає, що проектована система повинна виконувати наступні дії:

• Зберігати інформацію про покупців.
• Друкувати накладні на відпущені товари.
• Стежити за наявністю товарів на складі.

Виділимо всі іменники в цих пропозиціях - це будуть потенційні кандидати на сутності й атрибути, і проаналізуємо їх (незрозумілі терміни будемо виділяти знаком питання):

• Покупець - явний кандидат на сутність.
• Накладна - явний кандидат на сутність.
• Товар - явний кандидат на сутність
• (?) Склад - а взагалі, скільки складів має фірма? Якщо кілька, то це буде кандидатом на нову сутність.
• (?) Наявність товару - це, швидше за все, атрибут, але атрибут будь сутності?

Відразу виникає очевидний зв'язок між сутностями - "покупці можуть купувати багато товарів" і "товари можуть продаватися багатьом покупцям". Перший варіант діаграми виглядає так:

Мал. 7

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

Куди помістити суті "Накладна" і "Склад" і з чим їх пов'язати? Запитаємо себе, як пов'язані ці сутності між собою і з сутностями "Покупець" і "Товар"? Покупці купують товари, отримуючи при цьому накладні, в які внесені дані про кількість і ціну купленого товару. Кожен покупець може отримати кілька накладних. Кожна накладна зобов'язана виписуватися на одного покупця. Кожна накладна повинна містити кілька товарів (не буває порожніх накладних). Кожен товар, в свою чергу, може бути проданий декільком покупцям через кілька накладних. Крім того, кожна накладна повинна бути виписана з певного складу, і з будь-якого складу може бути виписано багато накладних. Таким чином, після уточнення, діаграма буде виглядати наступним чином:

Мал. 8

Пора подумати про атрибути сутностей. Розмовляючи з співробітниками фірми, ми з'ясували наступне:

• Кожен покупець є юридичною особою і має найменування, адреса, банківські реквізити.
• Кожен товар має найменування, ціну, а також характеризується одиницями виміру.
• Кожна накладна має унікальний номер, Дату виписки, список товарів з кількостями і цінами, а також загальну суму накладної. Накладна виписується з певного складу і на певного покупця.
• Кожен склад має своє найменування.
• Знову випишемо всі іменники, які будуть потенційними атрибутами, і проаналізуємо їх:
• Юридична особа - термін риторичне, ми не працюємо з фізичними особами. Чи не звертаємо уваги.
• Найменування покупця - явна характеристика покупця.
• Адреса - явна характеристика покупця.
• Банківські реквізити - явна характеристика покупця.
• Найменування товару - явна характеристика товару.
• (?) Ціна товару - схоже, що це характеристика товару. Чи відрізняється ця характеристика від ціни в накладній?
• Одиниця виміру - явна характеристика товару.
• Номер накладної - явна унікальна характеристика накладної.
• Дата накладної - явна характеристика накладної.
• (?) Список товарів в накладній - список не може бути атрибутом. Ймовірно, потрібно виділити цей список в окрему сутність.
• (?) Кількість товару в накладній - це явна характеристика, але характеристика чого? Це характеристика не просто "товару", а "товару в накладній".
• (?) Ціна товару в накладній - знову ж таки це має бути не просто характеристика товару, а характеристика товару в накладній. Але ціна товару вже зустрічалася вище - це одне й те саме?
• Сума накладної - явна характеристика накладної. Ця характеристика не є незалежною. Сума накладної дорівнює сумі вартостей усіх товарів, що входять в накладну.
• Найменування складу - явна характеристика складу.

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

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

Точно також зробимо зі зв'язком, що з'єднує сутності "Склад" і "Товар". Введемо додаткову сутність "Товар на складі". Атрибутом цієї сутності буде "Кількість товару на складі". Таким чином, товар буде значитися на будь-якому складі і кількість його на кожному складі буде своє.

Тепер можна внести все це в діаграму:

Мал. 9

Концептуальні і фізичні ER-моделі

Розроблений вище приклад ER-діаграми є прикладом концептуальної діаграми. Це означає, що діаграма не враховує особливості конкретної СУБД. З цієї концептуальної діаграмі можна побудувати фізичну діаграму, Яка вже будуть враховуватися такі особливості СУБД, як допустимі типи і найменування полів і таблиць, обмеження цілісності і т.п. Фізичний варіант діаграми, наведеної на Рис. 9 може виглядати, наприклад, наступним чином:

Мал. 10

На даній діаграмі кожна сутність являє собою таблицю бази даних, кожен атрибут стає колонкою відповідної таблиці. Звертаємо увагу на те, що в багатьох таблицях, наприклад, "CUST_DETAIL" і "PROD_IN_SKLAD", відповідних сутностей "Запис списку накладної" і "Товар на складі", з'явилися нові атрибути, яких не було в концептуальної моделі - це ключові атрибути батьківських таблиць, мігрувалив дочірні таблиці для того, щоб забезпечити зв'язок між таблицями за допомогою зовнішніх ключів.

Легко помітити, що отримані таблиці відразу знаходяться в 3НФ.

висновки

Реальним засобом моделювання даних є не формальний метод нормалізації відносин, а так зване семантичне моделювання.

Як інструмент семантичного моделювання використовуються різні варіанти діаграм сутність-зв'язок(ER - Entity-Relationship).

Діаграми сутність-зв'язок дозволяють використовувати наочні графічні позначення для моделювання сутностей і їх взаємозв'язків.

розрізняють концептуальніі фізичніER-діаграми. Концептуальні діаграми не враховують особливостей конкретних СУБД. Фізичні діаграми будуються по концептуальним і являють собою прообраз конкретної бази даних. Суті, певні в концептуальній діаграмі стають таблицями, атрибути стають колонками таблиць (при цьому враховуються допустимі для даної СУБД типи даних і найменування стовпців), зв'язку реалізуються шляхом міграціїключових атрибутів батьківських сутностей і створення зовнішніх ключів.

При правильному визначенні сутностей, отримані таблиці будуть одночасно перебувати в 3НФ. Основна перевага методу полягає в тому, модель будується методом послідовних уточнень первинних діаграм.

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

логічна модель (Сутнісна) даних є незалежним логічним поданням даних.

фізична модель (Табличная) даних містить визначення всіх реалізованих об'єктів в конкретній базі даних для конкретної СУБД.

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

У минулій лекції ми познайомилися з методологіями IDEF0 і DFD які дозволяють описати бізнес-процеси протікають в інформаційній системі. У моделі DFD ми розглянули елемент - сховище даних, який показує типи інформації, якою оперує система. Однак ця методологія не призначена для опису структури інформації, що зберігається. Для цього більше підходять різні Entity Relationship - діаграми (сутнісні діаграми), метою яких є опис структури збережених даних і взаємозв'язків між ними. Розроблено методики, які дозволяють перетворити такі дані в набір команд, який створить необхідні сховища (таблиці) всередині бази даних інформаційної системи.

ER-моделювання

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

Основні переваги ER-моделей:

• Точний і зрозумілий формат документування структури інформації.
• Дозволяє вказати вимоги до даних і зв'язків між ними.
• Дозволяє наочно показати структуру сховища для полегшення проектування бази даних.
• Існують методи відображення ER-моделей в таблиці БД і назад.
• Закладають основу для інтеграції з іншими додатками.

Основні типи об'єктів на ER-діаграмі:

• Сутність (Entity) - тип об'єктів, інформація про які буде зберігається в БД. Наприклад: відділи, співробітники, товари, накладні.
• Атрибут (Attribute) - елементи з яких складаються суті. Наприклад, для сутності «товари» атрибутами можуть бути «назва», «опис», «кількість», «ціна» та інші, в залежності від потреб інформаційної системи. Залежно від нотації ER-діаграми поруч з атрибутом, крім його імені вказують тип і обов'язковість заповнення. На слайді представлена \u200b\u200bER-діаграма в нотації «Information Engineering», згідно з якою для атрибута вказується ім'я, тип, і є він зовнішнім і / або первинним кличем.
• Зв'язок (Relationship) показують зв'язки між сутностями. Наприклад співробітник працює у відділі, де «відділ» і «відділ» - сутності.

Сутність - набір об'єктів реального світу, кожен з яких має наступні характеристики:

• Унікальний (може бути відділений від усіх інших будь-яким чином)
• грає певну роль в моделюється системі
• Може бути описаний одним або більше елементом інформації (Атрибутом)

Приклад: люди, персонал, події, замовлення, продажу, покупці, постачальники

Атрибут описує деякі властивості сутності. Сутність може мати багато атрибутів, але вибираються тільки ті, які важливі для системи. Атрибути діляться на ключові (Entity Keys) і описові (Entity Descriptors). Ключові атрибути повинні унікальним чином ідентифікувати екземпляри сутності. Для кожного атрибута має бути вказаний домен (тип, предметна область).

На слайді показані, як записуються сутності й атрибути в різних нотациях ER-моделей. У всіх нотациях сутність це об'єкт прямокутної форми, у верхній частині якого вказується ім'я сутності. Під ім'ям сутності перераховуються атрибути.

Давайте докладніше розберемося, що таке ключові атрибути. Це важливо для розуміння типів зв'язків між сутностями.

базові терміни

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

• "Тип даних" (type, domean - домен) - безліч допустимих величин ( "область визначення") і операцій. Для всіх типів існують операції порівняння і присвоєння. Величинам не заборонено мати структуру, наприклад, об'єкта.
• "Відношення" (relation) - безліч атрибутів: унікальних імен з уточненням типу даних; плюс безліч "наборів величин" ( "рядів"), відповідних атрибутів. Величини в наборах можуть бути представлені тільки одиничними значеннями відповідних атрибутів типів, тобто бути скалярами ( "1-я нормальна форма").
• "Ключ" (key) - група атрибутів, значення яких у всіх наборах щодо різні, але жодна підгрупа цих атрибутів таку властивість вже не володіє (властивість "мінімальності" ключа). Зокрема, група може складатися з єдиного атрибута. Ключ щодо повинен бути завжди, а якщо їх декілька, один з них зобов'язаний бути призначений "первинним" (primary).
• "Зовнішній ключ" (foreign key) - група атрибутів, значення яких в кожному наборі величин відносини мають співпадати зі значеннями ключа можливо іншого ставлення. Зовнішні ключі можуть стосуватися не обов'язкові і проголошуються за потребами моделювання.
• "Операції" (operation) - безліч спільних дій над відносинами, що дають в результаті знову-таки відносини ( "замкнутість операцій"). Використовуються для отримання нових відносин в потребах подальшого моделювання або при вилученні з бази потрібних даних. Перелік операцій можна визначати по-різному; в перших реченнях моделі наводилося вісім операцій (проекції, з'єднання, відбору та ін.), вже не мінімальний набір, як компроміс між відсутністю надмірності і зручністю вживання.
• " Реляційна база даних" (Relational database) - набір відносин.

"Тип даних" іноді називають "доменом" (domain), але іноді під "доменом" розуміють тільки "область визначення" величин. "Набір величин" (tuple) по-російськи інакше називають "кортежем" або "n-кою".

Для зручності відносини часто зображують у вигляді таблиць, хоча таке уявлення неправомірно (щодо не визначений ні порядок атрибутів, ні порядок наборів величин, на відміну від таблиці). У SQL, на основі якого побудована в тому числі СУБД Oracle, поняття "відносини" як інструменту моделювання замінено якраз на "таблицю". Іншим поданням даних відносини може бути гіперкуб, і до нього теж іноді зручно вдаватися в міркуваннях про наявну БД.

Якщо відмовитися від определительного слова-кальки "реляційний", то термін "реляційна БД" можна перевести як "БД відносин" (точніше, "БД побудована за допомогою відносин "; відносин як інструменту, а не об'єкта моделювання: інакше вихідний термін був би relation database). Точно так же термін" реляційна модель "можна перевести як" модель відносин ", тобто" система понять для побудови моделі предметної області у вигляді набору відносин ". По ряду причин, в тому числі історичного і мовного характерів, цього не було свого часу зроблено.

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

Наведений погляд на реляційну БД (набір відносин і операції) характерний для реляційної алгебри. Це не єдина точка зору. Кожен набір величин в змінної відносини можна розуміти як справжнє висловлювання ( "предикат"): є такий-то співробітник з такими-то властивостями; такий-то відділ і так далі. Тим самим реляційна база даних в кожен момент часу являє собою набір справжніх висловлювань про предметну область, сформульований через відносини. По суті, набір висловлювань в змінних відносин і утворює модель предметної області, представлену базою даних. Такий погляд на реляційну БД характерний для реляційного числення. Обидва погляду на реляційну модель добре вивчені і доведена їх виразна равносильность.

Для термінів, перерахованих на попередньому слайді є неформальні еквіваленти, для того щоб простіше було зрозуміти і запам'ятати їх зміст:

• Ставлення → Таблиця
• Кортеж → Рядок, запис
• Кардинальність → Показати #
• Атрибут → Стовпець, поле
• Ступінь → Кількість стовпців
• Первинний ключ → Ідентифікатор
• Домен → Область допустимих значень

Ключові поля

Частина з атрибутів відносини є ключовими або ключами. Виділяють кілька типів ключів:

• Простий ключ - складається з одного атрибута, складовою - з декількох.
• потенційний ключ - атрибут або набір атрибутів, які можуть ідентифікувати кожен з кортежів відносини. Наприклад щодо паспортного столу ( «Номер паспорта») і ( «ПІБ» і «Дата народження») - потенційні ключі, які дозволяють унікальним чином ідентифікувати кожної людини.
• В кожному відношенні може бути тільки один первинний ключ - атрибут або набір атрибутів значення якого унікальним чином ідентифікую кожну запис. Якщо такими властивостями володіють кілька наборів атрибутів, то один з них вибирається первинним, а всі інші - альтернативними.
• Зовнішній ключ - зберігає значення первинного ключа іншого ставлення. Зовнішні ключі використовуються для зв'язку між відносинами.

Первинний ключ

• Кожне реляционное відношення має тільки 1 первинний ключ, всі інші - альтернативні.
• Значення всіх атрибутів первинного ключа нЕ може бути не визначене. Наприклад, ставлення зберігає інформацію про жителів міста. Первинний ключ - складовою (ІМ'Я, ПРІЗВИЩЕ, дата народження). Інформаційну систему встановили в Ісландії, де не використовують прізвищ, значить атрибут «прізвище» для більшості кортежів буде порожнім. Незважаючи на це складовою первинний ключ буде продовжать унікальним чином ідентифікувати кожен з кортежів. Однак неприпустимо, щоб значення одночасно всіх атрибутів первинного ключа були порожніми.
• Значення первинного ключа не впливає на розташування кортежів в табличному вигляді відносини. Навіть якщо значення первинного ключа - число (наприклад 1,2,3 ...) в загальному випадку це не гарантує, що кортежі всередині БД зберігаються в тому ж порядку і будуть виводиться в такому ж порядку. У «загальному випадку» означає, що іноді через специфіку конкретної СУБД рядки можуть зберігається впорядковано по первинному ключу, але це швидше виняток. У разі виведення результатів запиту ми повинні явно вказувати порядок, в якому потрібно виводити рядки, якщо такий порядок важливий. Результати запиту «дай мені перших 5 чоловік» непередбачуваний, якщо ми не вкажемо, за яким критерієм вони повинні бути «першими».
• Первинний ключ не впливає на доступ до атрибутів кортежу. Наприклад щодо «паспортний стіл» разом з ПІБ і датою народження зберігається адреса реєстрації людини. Ми можемо попросити БД витягти всі адреси, не знаючи ПІБ та дату народження.

зовнішній ключ

Зовнішній ключ використовується для встановлення зв'язків між відносинами. Наприклад візьмемо два відносини «Власники» (первинний ключ «номер паспорта») і «Нерухомість». Щоб встановити, хто володіє кожним з об'єктів нерухомості ми зв'яжемо ці відносини за значенням атрибута «номер паспорта». На відміну від первинного ключа значення зовнішнього ключа може бути невизначено (рядок 4 на слайді) - якщо ми не знаємо власника нерухомості ми його не вказуємо. На відміну від первинного ключа значення зовнішнього ключа може повторяться (стоки 1,3 на слайді) - у одного власника може бути кілька об'єктів нерухомості. Однак те що атрибут «номер паспорта» щодо «Нерухомість» є зовнішнім ключем на первинний ключ відносини «Власник» гарантує що значенням атрибута «номер пастора» можуть бути тільки значення з первинного ключа. Ми не можемо вказати в якості значення атрибута номер пасторат людини, якого ще немає в відношенні «Власник» (рядок 5).

Встановлюючи зовнішній ключ можна явно задати поведінку СУБД, якщо змінити значення первинного ключа або видалити кортеж. Однак при цьому зберігається правило «в зовнішньому ключі зберігаються тільки значення, які є в первинному ключі або невизначений значення (NULL)».

Зовнішній ключ між відносинами задається, зазвичай, при проектуванні БД. Однак він може бути знятий в будь-який момент часу або встановлений заново, якщо додавання цього обмеження не суперечить властивостям зовнішнього ключа. Зняття / встановлення зовнішніх ключів зазвичай роблять при вставці дуже великих обсягів даних, для прискорення цього процесу - СУБД не може зберігати неконсістентних (неправильних, помилкових) даних, тому перевіряє кожне обмеження при вставці кожного з рядків.

ЕR-моделі: зв'язку

На ER-моделях зовнішні ключі відображаються у вигляді зв'язків.

Кожна зв'язок характеризується 4 властивостями - силою, потужністю, ступенем і участю суті в зв'язку.

Розберемо ці характеристики.

Участь суті в зв'язку

Позначається на зв'язку поперечною лінією або гуртком.

Поперечна лінія означає обов'язкове (mandatory) Участь суті в зв'язку, а гурток - необов'язкове (optional).

У разі обов'язкової участі суті в зв'язку в описі такого зв'язку використовують дієслово " повинен". При необов'язковий участю суті в зв'язку використовують дієслово" може".

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

Ступінь зв'язку ( relationship degree) вказує на число асоційованих сутностей. Бінарна зв'язок ( binary relationship) Описує асоціації двох сутностей. тернарного зв'язок (ternary relationship) Має місце, коли зв'язуються три сутності. унарна зв'язок (unary relationship) Описує асоціації всередині єдиної сутності.

Найбільш поширені бінарні зв'язку - вони пов'язую дві різні сутності ( «Відділ» - «Співробітник», «Замовлення» - «Товари», «Курс» - «Лекції», «Група» - «Студенти»). Менш поширеними, але все-таки часто використовуваними є унарні зв'язку. З їх допомогою звичайно задають відношення вкладеності на однотипних об'єктах (відношення «Деталі» - можемо вказати складовою частиною якої деталі є дана, ставлення «Співробітники» - можемо вказати, хто з працівників є начальником для даного).

Потужність зв'язку показує, яке число примірників однієї сутності пов'язано з екземплярами іншої сутності.

Потужність може бути:

• один до одного (1: 1) - в групі студентів один староста;
• один-ко-многим (1: N) - в одному відділі працює багато співробітників;
• багато-до-багатьох (M: N) - один покупець купив багато товарів, товарів купували багато покупців.

Сила зв'язку: сильна зв'язок (Identifying Relationship)

Дочірня сутність не може існувати без батьківської. (Не буває відповіді без питання, не буває товару в кошику користувача, якщо не існує самої кошика)

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

На діаграмі сильний зв'язок відображається нерозривному лінією між сутностями.

Сила зв'язку: Слабкий зв'язок (Nonidentifying Relationship)

Батьківська і дочірня суті пов'язані, але дочірня сутність може бути створена раніше. (Вантаж належить замовлення, але вантаж може бути на складі, до того як створений замовлення).

Первинний ключ мігрує з батьківської сутності в дочірню і не входить до складу первинного ключа (стає просто зовнішнім ключем).

На діаграмі сильний зв'язок відображається пунктирною лінією між сутностями.

Рекурсивна-зв'язок (унарна зв'язок)

Найчастіше використовується для побудова ієрархій.

Постачальник МОЖЕ працювати з нулем або БІЛЬШЕ замовників (id_Customer).

Замовник МАЄ працювати з одним постачальником (id_Sup).

Але постачальник і замовник - це фірма чи організація - об'єкти одного типу і тому зберігаються в одному відношенні.

Зв'язок багато-до-багатьох.

Приклад: постачальники можуть поставляти багато типів товарів. Різні постачальники можуть поставляти однакові типи товарів.

Зв'язок багато-до-багатьох допустима з точки зору ER-моделі, але не може бути безпосередньо відображена в термінах реляційної алгебри.

Неоднозначність зв'язку дозволяється введенням перехідних сутностей, як показано на слайді.

ER-моделі і реальність

При найближчому розгляді зв'язку типу "один до одного" майже завжди виявляється, що A і B являють собою в дійсності різні підмножини одного і того ж предмета або різні точки зору на нього, просто мають відмінні імена і по-різному описані зв'язку та атрибути.

Уявімо, що А - постачальник, B - товар.

Mandatory-mandatory.Для прикладу, який наведено на слайді цей зв'язок означає, що кожен постачальник (Supplier) повинен постачати тільки один унікальний набір товарів (Invoice). З точки зору теорії тут все добре. На практиці це не припустимо: ні хто не буде шукати нового постачальника, якщо перевірений вами постачальник може надати декілька номенклатур товару. А тепер про емоції, кіт буде відчувати оператор при спробі введення даних про новий постачальника. Він не зможе ввести дані ні в одну з таблиць. Так що весь багаж непристойної лексики буде спрямований на вашу адресу.

Optional-mandatory. Приклад зв'язку наведені на слайді. Як бачимо у оператора тепер все добре: дані вводити він може. У бізнесу знову проблема: він повинен шукати нового постачальника, навіть якщо перевірений вами постачальник може надати декілька номенклатур товару. А бізнесу потрібні проблеми? Ні. Він повинен функціонувати. Як задовольнити бізнес? Відповідь проста. При проектуванні БД потрібно думати про нормалізацію. Якщо Supplier - сутність, то використовуйте зв'язку типу optional-mandatory (mandatory-optional) або optional-optional. Хоча найчастіше зв'язку один-до-одного - це помилка.

Optional-optional. Як бачимо у оператора знову все добре, а у бізнесу знову проблема. Підіб'ємо підсумки для зв'язку один-до-одного. Якщо суті беруть участь в зв'язку як: - mandatory-mandatory, то такий зв'язок не має права на життя; - optional-mandatory (mandatory-optional) або optional-optional, то супровід бізнесу проблематично.

Зв'язок один-до-багатьох mandatory-mandatory - досить сильна конструкція, що припускає, що входження суті B не може бути створено без одночасного створення щонайменше одного пов'язаного з ним входження суті A. Найчастіше це невірна зв'язок.

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

Зв'язок один-до-багатьох optional-optional - Як A, так і B можуть існувати без зв'язку між ними.

У термінах попереднього слайда ці діаграми можна проілюструвати на таких прикладах.

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

Mandatory-mandatory.Для прикладу, який наведено на слайді цей зв'язок означає, що кожен постачальник (A) повинен поставляти один або більше наборів товарів (B). З точки зору теорії тут все добре. Однак на практиці оператор не зможе ввести дані ні в одну з таблиць, оскільки записи необхідно одночасно вводити в обидві таблиці.

Optional-mandatory.В цьому випадку у оператора тепер все добре: дані вводити він може, а у бізнесу можуть виникнути проблеми. Справа в тому, що зв'язок optional-mandatory передбачає, що постачальник (A) повинен постачати один або більше наборів товарів (B), в той час як B може належати постачальнику. Іншими словами, товари можуть існувати без постачальника, в той час як у постачальника є товари. Тобто можливо неконтрольоване ведення бізнесу: хто поставив товар? З кого питати? А бізнесу проблеми потрібні? Ні. Він повинен давати прибуток. В цьому випадку краще використовувати mandatory-optional: постачальник може постачати один або більше наборів товарів, в той час як товар повинен належати постачальнику. Іншими словами, товар має постачальник, а дані про постачальників, які колись постачали товар будуть збережені. І вівці цілі і вовки ситі - оператор може вводити дані і бізнесмен в кусі справ.

Optional-optional.Як бачимо у оператора знову все добре, а у бізнесу проблема - безконтрольний: Товар може існувати без постачальника і постачальник без товару.
Підіб'ємо підсумки для зв'язку один-ко-многим. Якщо суті беруть участь в зв'язку як: - mandatory-mandatory, то такий зв'язок не має права на життя, оскільки вводити записи одночасно в обидві таблиці неможливо; - optional-optional, то супровід бізнесу проблематично.

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

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

Багато-до-багатьох mandatory-optional - застосовується рідко. Такі зв'язку завжди підлягають подальшій деталізації.

Рекурсивні зв'язку. Ці зв'язки припускають, що записи таблиці можуть бути логічно пов'язані між собою.

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

Optional-optional один-ко-многим. Приклад зв'язку наведені на слайді. Це класична ієрархія (деревоподібна структура). Зв'язок, наведену на слайді можна інтерпретувати, наприклад, так: будь-який співробітник може бути підпорядкований тільки одному менеджеру, в той час як менеджер може керувати одним або багатьма співробітниками.

Optional-optional М: М Приклад зв'язку наведені на слайді 3. Це мережева структура.

Контрольний список питань до сутностей

• Чи відображає ім'я сутності суть даного об'єкта?
• Чи немає перетину з іншими сутностями?
• Чи є хоча б два атрибути?
• Всього атрибутів не більше восьми?
• Чи є синоніми / омоніми даної суті?
• Сутність визначена повністю?
• Чи є унікальний ідентифікатор?
• Чи є хоча б одна зв'язок?
• Чи існує хоча б одна функція по створенню, пошуку, коригування, видалення, архівування та використання значення сутності?
• Чи ведеться історія змін?
• Чи має місце відповідність принципам нормалізації даних?
• Чи немає такої ж суті в інший прикладної системі, можливо, під іншим ім'ям?
• Чи не має сутність занадто загальний зміст?
• Чи достатній рівень узагальнення, втілений в ній?

Контрольний список питань до атрибутів:

• Чи є найменування атрибута іменником однини, що відображає суть позначається атрибутом властивості?
• Не включає чи в себе найменування атрибута ім'я сутності (цього бути не повинно)?
• Чи має атрибут тільки одне значення в кожен момент часу?
• Відсутні чи повторювані значення (або групи)?
• Описано чи формат, довжина, допустимі значення, Алгоритм отримання і т.п.?
• Чи не може цей атрибут бути пропущеної сутністю, яка стала б у пригоді для іншої прикладної системи (вже існуючої або передбачуваної)?
• Не може він бути пропущеної зв'язком?
• Чи немає де-небудь посилання на атрибут як на "особливість проекту", яка при переході на прикладний рівень повинна зникнути?
• Чи є необхідність в історії змін?
• Чи залежить його значення тільки від даної суті?
• Якщо значення атрибута є обов'язковим, чи завжди воно відомо?
• Чи є необхідність у створенні домену для цього і йому подібних атрибутів?
• Чи залежить його значення тільки від якоїсь частини унікального ідентифікатора?
• Чи залежить його значення від значень деяких атрибутів, які не включені в унікальний ідентифікатор?

Модель сутність-атрибут-зв'язок була запропонована Петером Пін-Шен Ченов в 1976 р На використанні різновидів ER моделі засновано більшість сучасних підходів до проектування баз даних (головним чином реляційних). Моделювання предметної області базується на використанні графічних діаграм, що включають невелику кількість різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в CASE системах, Що підтримують автоматизоване проектування реляційних баз даних.

Базовими поняттями ER-моделі є сутність, атрибут і зв'язок.

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

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

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

Як і сутність, зв'язок - це типове поняття, всі екземпляри обох пар пов'язують сутностей підкоряються правилам зв'язування. На рис. 1. наведено приклад зображення сутностей і зв'язку між ними. Дана діаграма може бути інтерпретована наступним чином:

Кожен СТУДЕНТ навчається тільки в одній ГРУППЕ;

Будь-яка ГРУПА складається з одного або більше СТУДЕНТІВ.

Мал. 1. Зв'язок між сутностями

На рис. 2 зображена сутність ЛЮДИНА з рекурсивної зв'язком, що зв'язує її з нею ж самою. Лаконічній усній трактуванням зображеної діаграми є наступна:

Кожен ЛЮДИНА є сином одного і тільки одного ЛЮДИНИ;

Кожен ЛЮДИНА може бути батьком для одного або більше ЛЮДЕЙ ( "людина").

Мал. 2. Рекурсивна зв'язок

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

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

Зв'язки "багато-до-багатьох". Іноді буває необхідно зв'язувати суті таким чином, що з обох кінців зв'язку можуть бути присутні кілька екземплярів сутності (наприклад, всі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку "багато-до-багатьох".

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

Каскадні видалення екземплярів сутностей. Деякі зв'язку бувають настільки сильними (звичайно, в разі зв'язку "один-ко-многим"), що при видаленні опорного екземпляра сутності (відповідного кінця зв'язку "один") потрібно видалити і всі екземпляри сутності, відповідні кінця зв'язку "багато". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні сутності.

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

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

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

При переході до наступного етапу - моделювання схеми БД - перед розробником виникає проблема вираження концептуальної моделі предметної області в термінах застосовуваної моделі даних (наприклад, реляційної). Існує три підходи до вирішення цієї проблеми.

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

У другому підході реалізується автоматизована компіляція концептуальної моделі предметної області в схему БД (найчастіше реляційну). Відомі два типи підходу:

підхід, заснований на явному поданні концептуальної моделі предметної області як вихідної інформації для компіляції;

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

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

нарешті, третій підхід -це безпосередня робота з базою даних у семантичній моделі, тобто застосування СУБД, заснованих на семантичних моделях даних. При цьому знову розглядаються два варіанти.

Перший варіант - забезпечення призначеного для користувача інтерфейсу на основі семантичної моделі даних з автоматичним відображенням конструкцій в реляційну модель даних (це завдання приблизно такого ж рівня складності, як автоматична компіляція концептуальної моделі предметної області в схему БД).

Другий варіант - пряма реалізація СУБД, заснована на будь-якої семантичної моделі даних.

Найближче до другого варіанту знаходяться сучасні об'єктно-орієнтовані СУБД, моделі даних яких за багатьма параметрами близькі до семантичним моделям (хоча в деяких аспектах вони більш потужні, а в деяких - слабші). Хоча в цілому можна сказати, що цей підхід ще не вийшов за межі дослідницьких та експериментальних проектів.

В даний час на ринку програмного забезпечення з'явилося досить багато універсальних (не прив'язаних до будь-якої конкретної СУБД) пакетів автоматизованого проектування БД, що дозволяють виробляти концептуальне моделювання предметної області. В основі практично всіх систем такого роду лежить та чи інша інтерпретація ER-моделі. Такі системи є реалізацією другого з розглянутих вище підходів. Одним з найбільш популярних програмних продуктів в цій області є ERwin компанії Platinum.

моделі даних

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

Найпростіший тип - це список - структура даних у вигляді лінійної послідовності.

Деревовидні ієрархічні структури широко використовуються в повсякденному людської діяльності. Ієрархічні моделі даних базуються на використанні графовой і табличній форм представлення даних. У графічної діаграмі схеми бази даних вершина графа використовується для інтерпретації типів сутностей, а дуги - для інтерпретації типів зв'язків між типами сутностей. При реалізації вершини представляються таблицями описів примірників сутностей відповідного типу. На рис. 3 показаний приклад ієрархічної деревоподібної структури БД.

Мал. 3. Ієрархічна деревоподібна структура БД

Основними внутрішніми обмеженнями ієрархічної моделі даних є наступні:

- всі типи зв'язків повинні бути функціональними, тобто 1: 1, 1: М, М: 1;

- структура зв'язків повинна бути деревовидної.

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

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

Кореневе дерево як орієнтований граф можна визначити наступним чином:

- є єдина особлива вершина, яка називається коренем, в яку не входить жодне ребро;

- в усі інші вершини заходить тільки одне ребро, а виходить довільну кількість ребер;

- немає циклів.

Ієрархічна деревоподібна структура, орієнтована від кореня, задовольняє таким умовам:

- ієрархія завжди починається з кореневого вузла;

- на першому рівні ієрархії може перебувати тільки кореневий вузол;

- на нижніх рівнях знаходяться породжені (Залежні) вузли;

- кожен породжений вузол, що знаходиться на рівні L , пов'язаний тільки з одним безпосередньо вихідним вузлом (безпосередньо батьківським вузлом), що знаходяться на більш верхньому (L - 1) -му рівні ієрархії дерева;

- кожен вихідний вузол може мати один або кілька безпосередньо породжених вузлів, званих подібними;

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

- існує єдиний ієрархічний шлях доступу до вузла починаючи від кореня дерева (рис. 4).

Мал. 4. Ієрархічний шлях доступу до вузла

Іншими словами, ієрархічна модель подання знань (або дерево) - структура даних, в якій кожен вузол має тільки одного "батька", тобто панівний вузол (крім самого верхнього вузла) і необмежену кількість "нащадків", тобто вузлів, над якими даний вузол панує.

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

Мал. 5. мережева структура

У 70-х роках почали активно проводитися теоретичні дослідження реляційної моделі даних. З появою персональних ЕОМ реляційні моделі стали домінувати на ринку інформаційних систем. Реляционное уявлення знань- уявлення знань у вигляді відносин.

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

логічне проектування

У запропонованій методології проектування баз даних весь процес розробки розділяється на три основні фази: концептуальне, логічне і фізичне проектування. Логічне проектування баз даних - це процес конструювання загальної інформаційної моделі підприємства на основі окремих моделей даних користувачів, яка є незалежною від особливостей реально використовуваної СУБД та інших фізичних умов.

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

1. Видалення зв'язків типу M:N.

2. Видалення складних зв'язків.

3. Видалення рекурсивних зв'язків.

4. Видалення зв'язків з атрибутами.

5. Видалення множинних атрибутів.

6. Повторна зв'язків типу 1: 1.

7. Видалення надлишкових зв'язків.

1. Видалення зв'язків типу M: N.Якщо в концептуальній моделі присутні зв'язку типу M:N ( "Багато-до-багатьох"), то їх слід усунути шляхом визначення деякої проміжної сутності. зв'язок типу M:N замінюється двома зв'язками типу 1: М, Що встановлюються з новоствореної сутністю.

Як приклад розглянемо наступну M:N зв'язок: газета друкує оголошення про об'єкти, що здаються в оренду (рис. 6)

Мал. 6. M: N зв'язок

З метою усунення зв'язку з цим ми визначаємо проміжну сутність ОГОЛОШЕННЯ і створюємо дві нові зв'язки типу 1: М. В результаті зв'язок типу M:N буде замінена двома зв'язками (рис. 7).

Мал. 7. Зв'язки типу 1: M

2. Видалення складних зв'язків.Складною називається зв'язок, що існує між трьома і більше типами сутностей. Якщо в концептуальній моделі присутня складна зв'язок, її слід усунути за допомогою проміжної сутності. Складна зв'язок замінюється необхідною кількістю бінарних зв'язків типу 1: М, Що встановлюються з новоствореної сутністю. Наприклад, потрійний зв'язок "Здається в оренду" (зображується ромбом) відображає відносини, що існують між оформляють оренду працівником компанії, земельною ділянкою та орендарем (рис. 8).

Мал. 8. Складна зв'язок

Цю складну зв'язок можна спростити шляхом введення нової сутності і визначення бінарних зв'язків між нею і кожної з вихідних сутностей складної зв'язку.

У нашому прикладі зв'язок "Здається в оренду" можна усунути за допомогою введення нової слабкою суті з ім'ям Угоду. Новостворена сутність буде пов'язана з вихідними сутностями трьома новими бінарними зв'язками (рис. 9).

Мал. 9. Спрощення складної зв'язку

3. Видалення рекурсивних зв'язків.Рекурсивними називаються такі зв'язки, в яких сутність деякого типу взаємодіє сама з собою. Якщо концептуальна модель містить рекурсивні зв'язку, вони повинні бути усунуті за допомогою визначення деякої проміжної сутності. Наприклад, для відображення ситуації, коли один з працівників керує групою інших працівників, може бути встановлена \u200b\u200bрекурсивна зв'язок типу "один-ко-многим" (1: М).

4. Видалення зв'язків з атрибутами.Якщо в концептуальній моделі присутні зв'язку, які мають власні атрибути, вони повинні бути перетворені шляхом створення нової сутності. Наприклад, розглянемо ситуацію, коли потрібно фіксувати кількість робочих годин, відпрацьованих тимчасовим персоналом кожного з відділень підприємства. Зв'язок "Працює в" має атрибут з ім'ям "Відпрацьовано годин". Перетворимо зв'язок "Працює в" в сутність з ім'ям "Розподіл по відділам", якій призначимо атрибут "Відпрацьовано годин", після чого створимо дві нових зв'язку типу 1: М.

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

6. Повторна зв'язків типу1:1. У процесі визначення сутностей могли бути створені дві різні сутності, які насправді представляють один і той же об'єкт в предметної області додатки. Наприклад, могли бути створені дві сутності "Відділ" і "Департамент", які насправді представляють один і той же тип об'єкта. Іншими словами, ім'я "Відділ" є синонімом імені "Департамент". У подібному випадку слід об'єднати ці дві сутності в одну. Якщо первинні ключі об'єднуються сутностей різні, виберіть один з них в якості первинного, а другий вкажіть як альтернативний ключ.

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

При усуненні надмірності доступу велике значення мають тимчасові показники. Наприклад, розглянемо ситуацію, коли необхідно змоделювати зв'язку між сутностями "Чоловік", "Жінка" і "Дитина". Очевидно, що між сутностями "Чоловік" і "Дитина" є два шляхи доступу: один - через безпосередній зв'язок “ Є батьком "і інший - через зв'язку “ Одружений на "і" Є матір'ю ". На перший погляд здається, що зв'язок “ Є батьком "надлишкова. Однак це твердження може виявитися помилковим з двох причин. По-перше, батько може мати дітей від попереднього шлюбу, а ми моделюємо тільки поточний шлюб батька (через зв'язок 1: 1). По-друге, батько і мати можуть бути взагалі не одружені або батько може бути одружений на жінці, яка не є матір'ю даної дитини (або ж мати може бути одружена з чоловіком, який не є батьком дитини). Тому всі існуючі взаємини не можуть бути змодельовані без використання зв'язку типу "Є батьком" (рис. 10).

Мал. 10. Зв'язок між сутностями "Чоловік", "Жінка", "Дитина"

Схожа інформація.