Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Приклад проектування з використанням ролей

Правило 8

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

Сформуємо попередні відношення для зв'язку керує:

Службовець (ТНС, …)

Майстер (ТНМ, …)

Складальник (ТНЗб, …, ТНМ)

Тепер без утруднень розподіляємо не ключові атрибути сутностей:

Службовець (ТНС, С_пр, Д_тел, С_адр)

Майстер (ТНМ, Р_тел, Оклад, Сф_ком)

Складальник (ТНЗб, Ставка, Код_зб, ТНМ)

У всіх відношеннях один ключ, який є детермінантою, отже, всі три відношення знаходяться в НФБК.

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

 

Припустимо, що необхідно спроектувати БД для дитячого спортивного товариства (ДСТ) "Буревісник". Цією БД будуть користуватися члени Центральні ради ДСТ. Центральна рада повністю контролює діяльність ДСТ. В БД повинні розглядатися наступні питання:

· Складання календаря для усіх спортивних змагань.

· Перевірка всіх спортсменів, адміністраторів, тренерів всіх інститутів, що входять в ДСТ.

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

· Для кожного ВУЗу, вхід в ДСТ: назва ВНЗ, назву стадіону, місткість стадіону, число студентів, усі види спорту, культивовані даним навчальним закладом. Дані по персоналу: Прізвище, Адреса, Робочий та Домашній телефон ректора інституту, проректора по спорту, зав зі спортивної інформації і головного тренера по кожному культивованим виду спорту.

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

· Список усіх студентів спортсменів, що містить інформацію: Прізвище, домашня адреса, стать, дата вступу до ВНЗ, види спорту, якими займається студент, скільки років займався ними.

· Розклад змагань на поточний рік, містять інформацію: команда виступає в даній зустрічі в ролі господаря, команда виступає в ролі гостя, дати і час зустрічі кожної команди, призначені судді, вид спорту.

· По кожному виду спорту культивованого в ДСО мається комітет з правилами та їх головний тренер, призначеного лігою в якості представника цього комітету.

 

2. Обмеження накладаються на предметну область:

· Розклад складається на весь наступаючий сезон,

· Головний тренер тренує тільки по одному виду спорту,

· Деякі ВНЗ беруть участь не у всіх видах спорту, що культивуються ДСО,

· Деякі люди мають спільні службові телефони.

 

3. Виділення сутностей:

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

Ми будемо виділяти п'ять вихідних сутностей: Суддя, ВУЗ, Службовець, Вид спорту, Студент. У сутності Службовець одна роль Головний тренер. У сутності ВУЗ дві ролі ВУЗ-Гість і ВУЗ-Господар.

Запишемо ключові атрибути сутностей і їх ролей:

Н_ВУЗ - Назва ВУЗу
Н_Госп - Назва команди господаря
Н_Г - Назва команди гостей
ВИД_СП - Вид спорту
НОМ_СТ - Номер студента
НОМ_СЛ - Номер службовця
НОМ_ТРЕН - Номер тренера
НОМ_СУД - Номер судді

 

4. Сформуємо відношення по правилам:

Зв'язок в ВУЗі працюють СЛУЖБОВЦІ:

Вуз (Н_ВУЗ, …)

Службовець (НОМ_СЛ, …, Н_ВУЗ)

Зв'язок СТУДЕНТ вчиться у ВУЗі:

Студент (НОМ_СТ, …, Н_ВУЗ)

Вуз (Н_ВУЗ, …)

Зв'язок ВУЗ культивує ВИД СПОРТУ:

Вуз (Н_ВУЗ, …)

Вид_сп (ВИД_СП, …)

Культивує (Н_ВУЗ, ВИД_СП, …)

Зв'язок РОЗКЛАД:

Суддя (НОМ_СТ, …)

ВУЗ_гість (Н_Г, …)

ВУЗ_господар (Н_Госп, …)

Розклад (НОМ_СТ, Н_Г, Н_Госп, ВИД_СП, …)

Зв'язок СТУДЕНТ займається СПОРТОМ:

Студент (НОМ_СТ, …)

Вид спорту (ВИД_СП, …)

Приймає участь (ВИД_СП, НОМ_СТ, …)

Зв'язок ГОЛОВНИЙ ТРЕНЕР тренує ВИД СПОРТУ:

Вид_сп (ВИД_СП, …)

Тренер (НОМ_ТР, …, ВИД_СП)

Звзок ГОЛОВНИЙ ТРЕНЕР є головою по правилам даного ВИДУ СПОРТА:

Вид_сп (ВИД_СП, …, НОМ_ТР)

Тренер (НОМ_ТР, …)

Зв'язок СУДДЯ судить:

Суддя (НОМ_СТ, …)

Вид_сп (ВИД_СП, …)

 

6. Викреслюємо з отриманих відношень повторювані і переписуємо що залишилося:

Вуз (Н_ВУЗ, …)

Службовець (НОМ_СЛ, …, Н_ВУЗ)

Студент (НОМ_СТ, …, Н_ВУЗ)

Вид_сп (ВИД_СП, …, НОМ_ТР)

Культивує (Н_ВУЗ, ВИД_СП, )

Суддя (НОМ_СУД, …)

Вуз_гість (Н_Г, …)

Вуз_господар (Н_Госп, )

Приймає участь (ВИД_СП, НОМ_СТ, …)

Розклад (НОМ_СУД, Н_Г, Н_Госп, ВИД_СП, …)

Тренер (НОМ_ТР, …, ВИД_СП)

 

7. Потім дописуємо в відношення атрибути які обумовлювалися в умові:

Вуз (Н_ВУЗ, Н_СТАД, МІСЦЕ, ЧИСЛО_СТ)

Службовець (НОМ_СЛ, Н_ВУЗ, ПР, АДР, Д_ТЕЛ, Р_ТЕЛ, ПОСАДА)

Студент (НОМ_СТ, Н_ВУЗ, СТАТЬ, ДАТА_НАРОДЖ, ПРІЗВ, АДР_СТ, ДАТА_ВСТУПУ)

Вид_сп (ВИД_СП, НОМ_ТР)

Культивує (Н_ВУЗ, ВИД_СП)

Суддя (НОМ_СУД, ПР_СУД, АДР_СУД, ДТЕЛ_СУД, ВИД_СП_СУД)

Вуз_гість (Н_Г)

Вуз_господар (В_Госп)

Приймає участь (ВИД_СП, НОМ_СТ)

Розклад (НОМ_СУД, Н_Г, Н_Госп, ВИД_СП, ДАТА_ЗУСТР, ЧАС_ПОЧАТКУ)

Тренер (НОМ_ТР, ВИД_СП)

 

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

Усі вісім залишилися відношень знаходяться в НФБК. Розглянемо варіант коли одну зустріч можуть судити кілька суддів одночасно, тоді верхня частина рисунка 7.55 виглядала б наступним чином:

Рис. 7.56 – Діаграма ER-типу для зв’язку розклад,

у випадку якщо одну зустріч судить декілька суддів

Зустріч (ID_зустріч, н_гість, н_господар, вид_сп, дата, час)

Судить (ID_зустріч, ном_с)

 

 

8. ПОСТРЕЛЯЦІЙНІ БАЗИ ДАНИХ

8.1. ОБМЕЖЕННЯ РЕЛЯЦІЙНИХ БАЗ ДАНИХ

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

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

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

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

 

Недоліки реляційних баз даних

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

· За визначенням в реляційної моделі поля кортежу можуть містити лише атомарні значення. Однак, в таких додатках як САПР (системи автоматизованого проектування), ГІС (геоінформаційні системи), штучний інтелект системи оперують зі складно-структурованими об'єктами.

· У тому випадку, коли складний об'єкт вдається "укласти" в реляційну базу даних, його дані розподіляються, як правило, за багатьма таблицями. Відповідно, витяг кожного такого об'єкта вимагає виконання багатьох операцій з'єднання, що значно уповільнює роботу СУБД.

Обійти ці обмеження можна було б у тому випадку, якщо б реляційна модель допускала:

· можливість визначення нових типів даних

· визначення наборів операцій, пов'язаних з даними певного типу.

Перші роботи, у яких відзначалися ці та ряд інших недоліків, з'явилися вже на початку 80 - х років. У наступних розділах ми розглянемо деякі способи подолання зазначених недоліків.

 

8.2. СИСТЕМИ УПРАВЛІННЯ БАЗАМИ ДАНИХ НАСТУПНОГО ПОКОЛІННЯ

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

· Напрямок Postgres. Основна характеристика: максимальне проходження (наскільки це можливо з урахуванням нових вимог) відомим принципам організації СУБД (якщо не вважати корінний переробки системи управління зовнішньою пам'яттю).

· Напрямок Exodus / Genesis. Основна характеристика: створення власне не системи, а генератора систем, найбільш повно відповідають потребам додатків. Рішення досягається шляхом створення наборів модулів зі стандартизованими інтерфейсами, причому ідея поширюється аж до самих базисних шарів системи.

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

В цілому можна сказати, що СУБД наступного покоління - це прямі спадкоємці реляційних систем. Тим не менш, різні напрямки систем третього покоління варто розглянути окремо, оскільки вони володіють деякими різними характеристиками.

 

Абстрактні типи даних

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

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

Зауважимо, що в середині 1995 р. компанія Sun Microsystems оголосила про випуск нового продукту - мови і сімейства інтерпретаторів під назвою Java. Мова Java є розширеним підмножиною мови Сі + +. Основні зміни стосуються того, що мова є пооператорно інтерпретується (в стилі мови Бейсік), а програми, написані на мові Java, гарантовано безпечні (зокрема, при виконанні будь-якої програми не може бути пошкоджений інтерпретатор). Для цього, зокрема, з мови видалена арифметика над покажчиками. У той же час Java залишається потужним об'єктно-орієнтованою мовою, включає розвинені засоби визначення абстрактних типів даних. Компанія Sun просуває мову Java з метою розширення можливостей служби Всесвітньої Павутини (World Wide Web) Internet (основна ідея полягає в тому, що з сервера WWW в клієнти передаються не дані, а об'єкти, методи яких запрограмовані на мові Java і інтерпретуються на стороні клієнта; цей підхід, зокрема, вирішує проблему нестандартизованого представлення мультимедійної інформації). Однак, інтерпретується і безпечний мову типу Java може бути успішно застосований і в системах баз даних, що допускають зберігання даних з типами, визначеними користувачами.

 

Генерація систем баз даних, орієнтованих на програми прикладного рівня

Ідея дуже проста: ніколи не стане можливо створити універсальну систему управління базами даних, яка буде достатня і не надлишкова для застосування в будь-якому додатку. Наприклад, якщо подивитися на використання універсальних комерційних СУБД (наприклад, Oracle або Informix) в російській дійсності, то можна легко побачити, що принаймні в 90% випадків застосовується не більше ніж 30% можливостей системи. Тим не менш, додаток несе всю тяжкість підтримуючої його СУБД, розрахованої на використання в найбільш загальних випадках.

Тому дуже заманливо виробляти не закінчені універсальні СУБД, а щось на зразок компіляторів компіляторів (compiler compiler), що дозволяють зібрати систему баз даних, орієнтовану на конкретний додаток (або клас додатків). Бажано вміти генерувати систему баз даних, можливості (і відповідні накладні витрати) якої в достатній мірі відповідають потребам додатка. На сьогоднішній день на комерційному ринку такі "генераційні" системи відсутні (наприклад, при виборі сервера системи Oracle ви не можете відмовитися від будь-яких непотрібних для вашого застосування його властивостей або зажадати наявності деяких додаткових властивостей). Однак існують як мінімум два експериментальних прототипу - Genesis і Exodus. Обидві ці генераційні системи засновані насамперед на принципах модульності і точного дотримання встановлених інтерфейсів. По сутності справи, системи складаються з мінімального ядра (розвиненою файлової системи у випадку Exodus) і технологічного механізму програмування додаткових модулів. У проекті Exodus цей механізм ґрунтується на системі програмування Е, яка є простим розширенням С++, що підтримує стабільний зберігання даних у зовнішній пам'яті. Замість готової СУБД надається набір "напівфабрикатів" з узгодженими інтерфейсами, з яких можна згенерувати систему, що максимально відповідає потребам додатка.

 

8.3. ОРІЄНТАЦІЯ НА РОЗШИРЕНУ РЕЛЯЦІЙНУ МОДЕЛЬ

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

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

 

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

 

Розширена реляційна модель

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

 

9. ОБ`ЄКТНО-ОРІЄНТОВАНІ СУБД

 

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

Приклад об'єктно-орієнтованої СУБД - ObjectStore яка забезпечує довготривале зберігання в базі даних об'єктів, створених програмами на мовах С++ і Java.

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

 

9.1. ОБЄКТНО-ОРІЄНТОВАНА ПАРАДИГМА

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

Структура:

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

· Інкапсуляція

· Наслідування

· поліморфізм

Цілісність даних:

Для підтримки цілісності об'єктно-орієнтований підхід пропонує використовувати такі засоби:

• автоматична підтримка відношень спадкування.

• можливість оголосити деякі поля даних і методи об'єкта як "приховані", не видимі для інших об'єктів; такі поля і методи використовуються тільки методами самого об'єкта.

• створення процедур контролю цілісності всередині об'єкта.

 

Засоби маніпулювання даними:

На жаль, в об'єктно-орієнтованому програмуванні відсутні загальні засоби маніпулювання даними, такі як реляційна алгебра або реляційне числення. Робота з даними ведеться за допомогою одного з об'єктно-орієнтованих мов програмування загального призначення, зазвичай це SmallTalk, С++ або Java.

 

9.2. АНАЛІЗ ЕФЕКТИВНОСТІ ОБЄКТНО-ОРІЄНТОВАНИХ БАЗ ДАНИХ

Переваги об’єктно-орієнтованих баз даних

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

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

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

 

Недоліки об’єктно-орієнтованих баз даних

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

• замість чисто декларативних обмежень цілісності (типу явного оголошення первинних і зовнішніх ключів реляційних таблиць за допомогою ключових слів PRIMARY KEY і REFERENCES) або полудекларатівних тригерів для забезпечення внутрішньої цілісності доводиться писати процедурний код.

Очевидно, що обидва ці недоліку пов'язані з відсутністю розвинених засобів маніпулювання даними. Це завдання вирішується двома способами:

• Розширення ОО-мов в бік управління даними (стандарт ODMG)

• Додавання об'єктних властивостей в реляційні СУБД (SQL-3, а також так звані об'єктно-реляційних СУБД).

 

<== предыдущая лекция | следующая лекция ==>
Використання ролей | Стандарт ODMG
Поделиться с друзьями:


Дата добавления: 2014-01-11; Просмотров: 340; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.08 сек.