КОРОТКИЙ АНАЛІЗ ER-МОДЕЛІ

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

ER-модель як основа реляційної моделі

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

1 Виявлення корисних семантичних концепцій

2 Визначення формальних обєктів

Визначення формальних правил підтримки цілісності даних (Метаограніченій)

3 Визначення формальних операторів

Зверніть увагу на те, що ці етапи цілком застосовні і для розробки реляційної моделі (а також будь-який інший формальної моделі даних), а не тільки розширених моделей, подібних ER-моделі Інакше кажучи, для того щоб створити формальну базову реляційну модель, Кода перш за все повинен був виявити деякі неформальні корисні семантичні концепції. Ці концепції в основі своєї повинні були бути близькі ідеям ER-моделювання або чомусь дуже схожому з ними Дійсно, роботи Кодда підтверджують це припущення, оскільки в його першій статті (в самій ранній версії роботи [61], яка була опублікована в 1969 році), присвяченій реляційної моделі, є наступні рядки

“Безліч сутностей заданого типу сутності можна розглядати як відношення, і таке ставлення ми будемо називати ставленням типу сутності .. Решта стосунки .. між типами сутностей .. називаються межсущностнимі відносинами .. Найважливішою властивістю кожного межсущностного відносини є те, що [воно містить принаймні два зовнішніх ключа, які] посилаються на різні типи сутностей або на загальний тип сутності, що виконує кілька ролей .

Тут Коду явно пропонує використовувати відносини для моделювання тасутностей, і звязків Але найголовніше полягає в тому (дуже важливе зауваження), Що відносини є формальними обєктами, а реляційна модель формальною системою Цінність наукового внеску Кодда полягає в тому, що він знайшов вдалу формальну модель для певних аспектів реального світу

На противагу цьому, ER-модель НЕ є формальною моделлю (або, принаймні, є такою не в першу чергу) Фактично вона складається з набору переважно неформальних концепцій, відповідних тільки перший з чотирьох наведених вище етапів (Більше того, її формальні аспекти насправді не дуже значно відрізняються від відповідних аспектів основний реляційної моделі обговорення цього питання буде продовжено в наступному підрозділі) Для проектування бази даних, безумовно, корисно мати у своєму розпорядженні, крім усього іншого, набір концепцій, визначених на етапі 1 Однак безсумнівним залишається той факт, що проектування бази даних не може бути завершено без застосування формальних обєктів і правил, представлених на етапах 2 і 3, а безліч інших завдань і зовсім не може бути вирішено без використання формальних операторів, що визначаються на етапі 4

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

Чи є ER-модель моделлю даних

З викладеного вище не зовсім ясно, чи є ER-модель насправді моделлю даних, принаймні, у зазначеному в справжній книзі сенсі (тобто формальної системою, що включає структурні аспекти, а також аспекти підтримки цілісності і маніпулювання даними) Безумовно, термін ER-моделювання зазвичай використовується для позначення процесу вибору тільки структури бази данних7, хоча вище, в розділах 143-145, розглядалися і деякі аспекти цілісності (вони в основному ставилися до

7 Фактично основна слабкість тут полягає в тому, що ER-модель за винятком деяких приватних (але, за загальним визнанням, дуже важливих) випадків абсолютно непридатна для роботи з обмеженнями цілісності або бізнес-правилами Процитуємо типове висловлювання на цей рахунок з роботи [1432]: Декларативні процеси дуже складні для того, щоб їх можна було виразити у вигляді частини бізнес-моделі, а тому вони повинні бути визначені окремо аналітиком-розробником . При цьому все ще залишається в силі такий довід, що проектування бази даних має бути процесом точного визначення прийнятних обмежень (див [921], [922] і [1422] – [1424])

проблеми використання ключів) Але при більш уважному читанні роботи [146] можна припустити, що ER-модель дійсно є моделлю даних, але такий, яка представляє собою лише невелике додаток до реляційної моделі (і, безумовно, не може замінити реляційну модель, як хотілося б деяким авторам) Це твердження можна обгрунтувати наведеними нижче доводами

■ Фундаментальний елемент даних в ER-моделі, тобто її фундаментальний фор мальний обєкт, що існує на противагу неформальним обєктам

{Сутностей, звязків і тд), – це відношення ступеня п

■ Оператори ER-моделі в основному є операторами реляційної алгебри (Дійсно, роботу [146] не можна назвати дуже чітко розяснює цю думку, але в ній пропонується менш потужне порівняно з реляційної алгебрами рій безліч операторів, серед яких, наприклад, не існує обєднання і явно заданого зєднання)

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

Порівняльний аналіз сутностей і звязків

У цій книзі вже кілька разів зазначалося, що звязку найкраще розглядати просто як сутності особливого роду І навпаки, обовязковою умовою використання ER-моделі є те, що ці два поняття повинні якимось чином відрізнятися На думку автора, будь-який підхід, при якому переслідується такий поділ, володіє серйозними недоліками, оскільки, як зазначалося вище, в розділі 142, один і той же обєкт може цілком обгрунтовано розглядатися як сутність одними користувачами і як звязок – іншими Зокрема, розглянемо наведений нижче приклад з укладенням шлюбу

■ З одного боку, очевидно, що шлюбом називається певний звязок між двома людьми Як приклад можна привести запит: З ким одружилася Елізабет Тейлор в 1975 .

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

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

В якості ще однієї ілюстрації розглянемо наступне твердження з навчального посібника по ER-моделювання [1422]

“Зазвичай на першому етапі в процесі розробки концептуальної схеми прийнято представляти деякі звязки у вигляді атрибутів [під цим маються на увазі саме зовнішні ключі] Потім ці атрибути перетворюються у звязку в міру подальшої розробки проекту та поглиблення розуміння його особливостей .

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

Заключні зауваження

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

141&nbsp&nbsp&nbsp&nbsp РЕ ЗЮМЕ

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

1 Виявлення корисних семантичних концепцій

2 Визначення формальних обєктів

Визначення формальних правил підтримки цілісності даних (Метаограніченій)

3 Визначення формальних операторів

Як приклад корисних семантичних концепцій можна назвати концепції сутності, властивості, звязки і підтипу

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

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

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

Основна мета досліджень в області семантичного моделювання полягає в тому, щоб зробити СУБД більш інтелектуальними. А більш конкретна мета полягає в наданні деякого систематичного підходу до вирішення проблеми проектування бази даних У справжній главі було описано застосування однієї з семантичних моделей, запропонованої Ченом для вирішення зазначеної проблеми, а саме – моделі Сутність-звязок, інакше званої ER-моделлю

У звязку зі сказаним вище стоїть повторити думку про те, що перша стаття про ER-моделюванні [146] насправді містила два різних, більш-менш незалежних, пропозиції: саму ER-модель, а також технологію діаграмного ERмоделірованія Як було відзначено в розділі 144, широку популярність ER-моделі, швидше за все, можна пояснити саме наявністю цієї технології використання діаграм, а не який-небудь іншою причиною Однак для використання технології ER-діаграм зовсім не обовязково підтримувати всі ідеї цієї моделі Дані діа грами можна застосовувати в якості основи в будь методикою проектування, наприклад заходів, в методиці на основі RM / T-моделі, описаної в [147] Ця особливість часто не беруть до уваги при порівнянні зручності використання ER-моделі та інших методик, розроблених для проектування бази даних

Порівняємо тепер ідеї семантичного моделювання (і ER-моделі зокрема) з методом нормалізації, описаним в розділах 12 і 13 Метод нормалізації передбачає приведення великих змінних відносини до набору змінних відносини меншого розміру При цьому передбачається, що на вихідному етапі є невелика кількість великих змінних відносини, які до завершального етапу після виконання певних операцій будуть перетворені в безліч малих змінних відносини, тобто відбудеться перетворення великих відносин в малі (це, звичайно ж, дуже приблизна формулювання) Однак метод нормалізації не дає ніяких рекомендацій, що стосуються того, яким саме чином можуть бути отримані вихідні великі змінні відносини Спадні методики, подібні описаної в цій главі, призначені для вирішення саме цієї проблеми, тобто вони дозволяють відобразити деяку предметну область реального світу на набір великих змінних відносини Інакше кажучи, ці два підходи (спадний проектування і нормалізація) доповнюють один одногоТаким чином, загальна процедура проектування бази даних включає два описаних нижче етапи

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

2 Використання ідей подальшої нормалізації для розбиття створених

“Великих змінних відносини на малі.

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

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

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*