Сравнение синтаксических моделей данных. Пример.
Сравнение по структуре
РМД: Объекты и взаимосвязи представлены единообразно, в виде плоских двумерных таблиц. Связи между объектами представлены неявно, через совпадение ключевых атрибутов в разных таблицах.
ИМД: Объекты представляются в виде древовидной структуры, описывающей связи типа главный-подчиненный между ними. Связи не именуются => возможны аномалии как в 1NF в РМД. Кроме того, необходимо дублировать информацию в случае в случае представления связи М:М. Обратные запросы очень неэффективны.
СМД: Объекты и связи представлены в виде сети, где в отличие от ИМД у узла может быть несколько родителей. Связи между объектами именуются (имена наборов) => возможно использование связи М:М.
Сравнение по ОЦ
Контроль за уникальностью первичного ключа и областью допустимых значений возможен во всех этих МД.
РМД: Дополнительно возможен контроль ссылочной целостности. Все остальные явные ОЦ нужно программировать при помощи ХП и триггеров.
ИМД: Явных ОЦ больше нет. Внутренним ОЦ является невозможность представления связи М:М.
СМД: Очень мощный контроль за членством в группе при включении и удалении из нее записей.
Сравнение по доп. операциям
Навигационные операции, когда перед добавлением/удалением изменением/модификацией записи нужно установить текущую поддерживается во всех этих МД.
РМД: Широкая поддержка спецификационных операций: реляционной алгебры и исчислений – через поддержку языка SQL.
|
|
|
ИМД: Благодаря поддержанию порядка следования записей в дереве возможны операции: next, last, prev.
Спецификационный язык реализуется только на практике.
СМД: Доступ к нужной возможен через также через наборы указанием владельца или критерия отбора.
Сравнение преимуществ и недостатков
1. Самой простой и понятной конечным пользователям является РМД, затес ИМД, а потом СМД.
2. Высокий уровень независимости Д достигается в РМД, в СМД – не очень высокий.
3. Высокая эффективность реализации в РМД достигается за счет сложной индексации, в ИМД – за счет невысокой надстройки над функциями ФС.
4. Связь М:М легко представить в РМД и в СМД.
5. Мощный спецификационный язык предусмотрен только в РМД.
6. РМД – наиболее формализована.
7. Наибольшее число явных ОЦ – в СМД.
Пример:
ИМД:
Проект (№, название)
Поставщик (№, название, адрес)
Деталь (№, название, кол-во, вес)
СМД:
Проект, поставщик и деталь связаны с поставкой ( каждые по отдельности)
РМД:
Проект (№1*, название)
Поставщик (№2*, название)
Деталь (№3*, название, вес)
Поставка (№1*, №2*, №3*, кол-во)
Объектно-ориентированные и реляционно-объектные СУБД. Общая структура и примеры. Постреляционные СУБД. Парадигма NoSQL.
|
|
|
Данный тип БД возник еще в середине 80-х и в 90-х ему были выданы большие авансы как средству улучшения реляционной технологии. Основным преимуществом ООБД по сравнению с реляционными принято называть, прежде всего, близость проекта БД с предметной областью. Наибольшее первичное влияние на ООБД оказал язык Smalltalk. Однако ООБД на сегодняшний день выданных авансов не оправдал, конкурировать с реляционными системами ни один подобный проект не может.
В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные средства для отображения реального мира, чем реляционная модель:
• естественное представление данных. В реляционной модели все отношения принадлежат одному уровню, именно это осложняет преобразование иерархических связей модели "сущность-связь" в реляционную модель. ОО-модель можно рассматривать послойно, на разных уровнях абстракции.
• имеется возможность определения новых типов данных и операций с ними.
В то же время, ОО-модели присущ и ряд недостатков:
• отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста.
|
|
|
• вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.
Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).
Появление объектно-ориентированных СУБД вызвано потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделенного сервера базы данных крайне редки.
|
|
|
ODMG (Object Data Management Group) - консорциум поставщиков ООБД и других заинтересованных организаций, созданный в 1991 г. Его задачей является разработка стандарта на хранение объектов в базах данных. В настоящее время опубликована вторая версия стандарта, которую так и называют ODMG 2.0. Рассмотрим кратко основные положения этого документа.
Стандарт на хранение объектов ODMG 2.0 разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG - Object Management Group) и стандарты на объектно-ориентированные языки программирования (C++, Smalltalk, Java).
ODMG добавляет возможности взаимодействия с базами данных в объектно-ориентированные языки программирования: определяются средства долговременного хранения объектов и расширяется семантика языка, вносятся операторы управления данными. Стандарт состоит из нескольких частей:
• Объектная модель - унифицированная основа всего стандарта. Она расширяет объектную модель консорциума OMG (см. параграф 6.3.1) за счет введения таких свойств как связи и транзакции для обеспечения функциональности, требуемой при взаимодействии с базами данных. Ключевые концепции объектной модели ODMG:
- наделение объектов такими свойствами как атрибуты и связи
- методы объектов (поведение)
- множественное наследование
- идентификаторы объектов (ключи)
- определение таких совокупностей объектов как списки, наборы, массивы и т.д.
- блокировка объектов и изоляция доступа
- операции над базой данных
• Язык описания объектов (ODL - Object Defifnition Language) - средство определения схемы базы данных (по аналогии с DDL в реляционных СУБД). ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования, а также транслировать ее в другие DDL.
• Язык объектных запросов (OQL - Object Query Language) - SQL - подобный декларативный язык, который предоставляет эффективные средства для извлечения объектов из базы данных, включая высокоуровневые примитивы для наборов объектов и объектных структур. Синтаксис опретора SELECT, определенный SQL-92, является подмножеством OQL, это гарантирует, что SELECT-утверждения, выполняемые над реляционными таблицами, сохранят работоспособность и с наборами объектов ODMG. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).
• Связывание с ОО-языками. Стандарт связывания с C++, Smalltalk и Java определяет Object Manipulation Language (OML) - язык манипулирования объектами, который расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программмирования и доступа к данным.
Уже к концу 80-х годов существовавшая тогда реляционная модель перестала удовлетворять разработчиков в силу ряда ограничений. Ответом на возрастающую сложность приложений баз данных стали два новых направления развития СУБД: объектно-ориентированные СУБД и объектно-реляционные СУБД.
В 1991 г. был образован консорциум ODMG (Object Database Management Group ), основной целью которого стала выработка промышленного стандарта объектно-ориентированных баз данных. Последняя версия стандарта имеет индекс 3.0. К концу 90-х существовало около десяти компаний, производящих коммерческие продукты, позиционируемые на рынке как ООСУБД. Наиболее известными системами данного класса стали Objectivity, Versant производства одноименных компаний, а также СУБД Jasmine, выпущенная компанией CA. Несмотря на преимущества, позволяющие более эффективно решать определенный ряд задач, объектно-ориентированные системы так и не смогли завоевать значимую долю рынка СУБД, оставшись «нишевым» продуктом.
Поставщиками традиционных реляционных СУБД также была проведена значительная работа по объединению объектно-ориентированных и реляционных систем. Разработчики постарались расширить язык SQL, чтобы включить в него концепции объектно-ориентированного подхода, сохраняя преимущества реляционной модели (объектные расширения языка SQL были зафиксированы в стандарте SQL:1999). Основной принцип – это эволюционное развитие возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения.
NoSQL (not only SQL) – это совокупность подходов, проектов, направленных на реализацию моделей баз данных, имеющих существенные отличия от используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Описание схемы данных в случае использования NoSQL-решений может осуществляться через использование различных структур данных: хеш-таблиц, деревьев и др. Сторонники этой концепции подчеркивают, что она не является полным отрицанием языка SQL и реляционной модели. Основная цель данного подхода – расширить возможности БД там, где SQL недостаточно гибок, например, при работе с данными очень большого объема в проектах с высокой нагрузкой.
NoSQL – это концепция, предназначенная для осуществления доступа к группированным данным, не использующая реляционную модель данных. Фундаментальные различия кроются в способе осуществлении доступа и актуализации данных, а также их размещении. Например, когда вы должны были бы хранить данные о каком-то счете, то вам требовалась специальная таблица, работа с которой предусматривала знание особого серверного языка для того, чтобы преобразовать эти данные в реальные объекты. Используя NoSQL, вам нужно хранить только данные о счёте.
Дата добавления: 2018-05-13; просмотров: 521; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!