И объектно-реляционная модели. Реляционные базы данных и объектно-ориентированные среды
Реляционные БД vs Объектно-ориентированные БД
- Разработка веб-сайтов
К сожалению не нашел на хабре достаточно интересных стаей про объектно-ориентированные базы данных (ООБД). Хотелось бы поднять эту тему, т.к. в последнее время все больше и больше идет разговоров об ООБД. Однако в одну статью всю информацию уложить не получится, поэтому приведу для начала небольшой обзор и свои размышления на эту тему. В этой статье я не буду рассматривать конкретные решения, основанные на каждой из технологий, а только постараюсь сравнить сами технологии.
Предыстория
Я занимаюсь проектированием и разработкой баз данных уже порядка 6 лет. За это время у меня сложилось свое видение как лучше подходить к проектированию, как выбирать архитектуру системы, какие существуют особенности при нормализации и денормализации реляционных БД, как оптимизировать те или иные конструкции и запросы. В первый год работы я пришел к тому, что не хочу заниматься рутиной по написанию одних и тех же запросов. В результате я написал свой генератор хранимых процедур, который по структуре БД генерировал большинство рутинных запросов (если будет интересно, то могу написать статью на эту тему). Затем этот генератор эволюционировал из года в год, и, в итоге, я пришел к необходимости хранить объекты, как они есть, чтобы не заморачиваться переводом объектной модели в реляционную структуру. Т.е. фактически я пришел к генерации некой ORM надстройки. Конечно, Вы можете сказать, что уже создано достаточное количество качественных ORM надстроек и объектно-реляционных БД, которые можно успешно использовать (и я с Вами соглашусь, но с некоторыми оговорками). Но и это меня не устроило. И я решил пойти дальше.Влияние ORM
По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».Использование ORM несомненно ускоряет разработку продукта, снижает трудозатраты и бла-бла-бла. Однако, любая ORM это некая прослойка, которая всегда будет работать медленнее, нежели прямая работа (я тут отнюдь не призываю перенести все вызовы SQL запросов в приложение – везде должна быть золотая середина). Наличие ORM позволяет разработчикам не особо задумываться о работе СУБД (и они-таки не задумываются в большистве своем), что влечет за собой, мягко говоря, не совсем оптимальную работу приложения под нагрузкой. Для оптимизации приходится лезть руками в прослойку и настраивать запросы так, чтобы они стали работать быстрее, приходится лезть в базу данных и перенастраивать индексы и таблицы. Таким образом, для оптимальной работы приложения необходимо приложить больше усилий, нежели когда ORM отсутствует. В итоге мы сокращаем затраты на разработку и ускоряем выпуск первой версии продукта, но усложняем процесс оптимизации.
Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа . Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.
Что-то меня понесло в сторону. Надеюсь, я достаточно понятно изложил свою позицию относительно ORM. Давайте вернемся к сравнению (или, если кому угодно - противостоянию) реляционных и объектно-ориентированных БД.
Реляционные БД vs ООБД
Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.- Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
- Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
- Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
- Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.
Выводы и перспективы
В свете сложившейся в настоящее время ситуации в мире разработки, перспектива появления серьезных и популярных решений с использованием ООБД кажется весьма сомнительной (но от этого не менее желаемой) до тех пор, пока не будут разрешены фундаментальные вопросы (мат аппарат и стандарт языка запросов). Меня, как разработчика, это несколько печалит, ибо я пришел к выводу, что наличие мощной и удобной ООБД просто необходимо для дальнейшего качественного развития средств разработки баз данных.Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго. ООБД все равно не смогут заменить реляционные БД в полном объеме. В некоторых реальных задачах все же удобней и правильней хранить данные не в объектах, а в таблицах.
Таким образом, я считаю, что со временем ООБД отвоюет у реляционных БД кусок рынка коммерческих систем, однако добиться такого тотального преимущества, которое сейчас имеют реляционные БД им не под силу.
К сожалению не нашел на хабре достаточно интересных стаей про объектно-ориентированные базы данных (ООБД). Хотелось бы поднять эту тему, т.к. в последнее время все больше и больше идет разговоров об ООБД. Однако в одну статью всю информацию уложить не получится, поэтому приведу для начала небольшой обзор и свои размышления на эту тему. В этой статье я не буду рассматривать конкретные решения, основанные на каждой из технологий, а только постараюсь сравнить сами технологии.
Предыстория
Я занимаюсь проектированием и разработкой баз данных уже порядка 6 лет. За это время у меня сложилось свое видение как лучше подходить к проектированию, как выбирать архитектуру системы, какие существуют особенности при нормализации и денормализации реляционных БД, как оптимизировать те или иные конструкции и запросы. В первый год работы я пришел к тому, что не хочу заниматься рутиной по написанию одних и тех же запросов. В результате я написал свой генератор хранимых процедур, который по структуре БД генерировал большинство рутинных запросов (если будет интересно, то могу написать статью на эту тему). Затем этот генератор эволюционировал из года в год, и, в итоге, я пришел к необходимости хранить объекты, как они есть, чтобы не заморачиваться переводом объектной модели в реляционную структуру. Т.е. фактически я пришел к генерации некой ORM надстройки. Конечно, Вы можете сказать, что уже создано достаточное количество качественных ORM надстроек и объектно-реляционных БД, которые можно успешно использовать (и я с Вами соглашусь, но с некоторыми оговорками). Но и это меня не устроило. И я решил пойти дальше.Влияние ORM
По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».Использование ORM несомненно ускоряет разработку продукта, снижает трудозатраты и бла-бла-бла. Однако, любая ORM это некая прослойка, которая всегда будет работать медленнее, нежели прямая работа (я тут отнюдь не призываю перенести все вызовы SQL запросов в приложение – везде должна быть золотая середина). Наличие ORM позволяет разработчикам не особо задумываться о работе СУБД (и они-таки не задумываются в большистве своем), что влечет за собой, мягко говоря, не совсем оптимальную работу приложения под нагрузкой. Для оптимизации приходится лезть руками в прослойку и настраивать запросы так, чтобы они стали работать быстрее, приходится лезть в базу данных и перенастраивать индексы и таблицы. Таким образом, для оптимальной работы приложения необходимо приложить больше усилий, нежели когда ORM отсутствует. В итоге мы сокращаем затраты на разработку и ускоряем выпуск первой версии продукта, но усложняем процесс оптимизации.
Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа . Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.
Что-то меня понесло в сторону. Надеюсь, я достаточно понятно изложил свою позицию относительно ORM. Давайте вернемся к сравнению (или, если кому угодно - противостоянию) реляционных и объектно-ориентированных БД.
Реляционные БД vs ООБД
Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.- Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
- Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
- Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
- Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.
Выводы и перспективы
В свете сложившейся в настоящее время ситуации в мире разработки, перспектива появления серьезных и популярных решений с использованием ООБД кажется весьма сомнительной (но от этого не менее желаемой) до тех пор, пока не будут разрешены фундаментальные вопросы (мат аппарат и стандарт языка запросов). Меня, как разработчика, это несколько печалит, ибо я пришел к выводу, что наличие мощной и удобной ООБД просто необходимо для дальнейшего качественного развития средств разработки баз данных.Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго. ООБД все равно не смогут заменить реляционные БД в полном объеме. В некоторых реальных задачах все же удобней и правильней хранить данные не в объектах, а в таблицах.
Таким образом, я считаю, что со временем ООБД отвоюет у реляционных БД кусок рынка коммерческих систем, однако добиться такого тотального преимущества, которое сейчас имеют реляционные БД им не под силу.
Объектно-ориентированная модель данных
Объектно-ориентированная модель данных является расширением положений объектно-ориентированного программирования (в то время как реляционная модель возникла на основе теории множеств, именно как модель данных). Группой управления Объектно-ориентированных БД разработан стандарт ODMG-93 (Object DataBase Management Group). Этот стандарт полностью еще не реализован.
Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Видимая структура объекта определяется свойствами его класса. Класс включает в себя объекты, при этом структура и поведение объектов одного класса одинаковы. Каждый объект, а именно экземпляр класса считается потомком объекта, в котором он определен как свойство. Свойства объектов - или стандартный тип, например, string, или конструируемый пользователем тип class. Поведение объектов задается с помощью методов. Метод – это некая операция, которую можно применить к объекту.
В качестве примера рассмотрим БД «БИБЛИОТЕКА» (рис.4.4). Для каждого объекта определены свойства, их типы и значения. В БД:
«БИБЛИОТЕКА» – родитель (предок) для «АБОНЕМЕНТ», «КАТАЛОГ», «ВЫДАЧА»;
«КАТАЛОГ» – родитель для «КНИГА».
«КНИГА» – различные объекты могут иметь одного или разных родителей. Если один и тот же родитель (один автор), то инвентарные номера разные, но isbn, УДК, название и автор – одинаковы.
Логическая структура объектно-ориентированной БД похожа на иерархическую, основное отличие – в методах манипулирования данными. Над БД можно производить такие действия как логические операции, усиленные объектно-ориентированными методами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором определено. Так, если в «КАТАЛОГ» добавлено свойство телефон автора книги, то получаются аналогично в «АБОНЕМЕНТ» и «КАТАЛОГ». Смысл свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование ,наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа «КНИГА», являющимся потомками «КАТАЛОГ», можно приписать свойства родителя isbn, УДК, название и автор.
Полиформизм означает способность одного и того же программного кода работать с разнотипными данными. Иными словами, он означает допустимость в объектах разных типов иметь методы – процедуры и функции – с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Для БД «БИБЛИОТЕКА» это означает, что объекты класса «КНИГА», имеющие разных родителей из класса «КАТАЛОГ» может иметь разный набор свойств, т.е. программы работы с объектом класса «КНИГА» может содержать полиморфный код. В классе у метода нет тела, т. е. не определено, какие конкретно действия он должен выполнить. Каждый подкласс выполняет нужные операции. Инкапсуляция скрывает детали реализации от всех объектов вне данной иерархии.
Достоинствамиобъектно-ориентированноймодели в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов, отсутствие ограниченности в структурах хранения данных. В объектно-ориентированной БД может храниться не только структура, но и поведенческие аспекты данных. С использованием объектно-ориентированного подхода могут создаваться и БД с большими объемами семантической информации, такие как мультимедийные и специализированные для конкретных предметных областей (географические, проектные и др.).
К недостаткам данного подходаможно отнести высокую понятийную сложность, неудобство обработки данных и низкую скорость выполнения запросов.
В 90-е годы были созданы прототипы действующих объектно-ориентированных БД. Это POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.
Тема 5
Реляционный подход при построении информационно-логической модели: основные понятия
Реляционная модель данных. Основные понятия
Как было отмечено в разделе предыдущей лекции, реляционная модель в настоящее время является одной из наиболее распространенных моделей на рынке БД. Основу этой модели составляет набор взаимосвязанных таблиц (отношений).
Основные теоретические идеи реляционной модели были изложены в работах по теории отношений американского логика Чарльза Содерса Пирса (1839-1914) и немецкого логика Эрнста Шредера (1841-1902), а также американского математика Эдгара Кодда.
В работах Пирса и Шредера было доказано, что множество отношений замкнуто относительно некоторых специальных операций, совместно образующих абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными.
В 1970 г. появилась статья Э.Кодда о представлении данных, организованных в виде двумерных таблиц, называемых отношениями. Коддом впервые были введены основные понятия и ограничения реляционной модели как основы хранения данных, и показана возможность обработки данных с помощью традиционных операций над множествами и специальных введенных реляционных операций.
Основные понятия реляционной модели даны в табл. 3.1.
Объектами реляционной модели в основном являются таблицы (отношения). Целостность данных обеспечивается внешними и первичными ключами (см. п. «Реляционная целостность данных»).
Операторы в реляционной модели – это набор инструкций, которые обеспечивают выборку и манипуляцию над данными.
Таблица 5.1. Элементы реляционной модели
| Термин реляционной модели | Описание |
| База данных (БД) | Набор таблиц и других объектов, необходимых для абстрактного представления выбранной предметной области |
| Схема БД | Набор заголовков таблиц, взаимосвязанных друг с другом |
| Отношение | Таблица – совокупность объектов реального мира, которые характеризуются общими свойствами и характеристиками (поля таблицы) |
| Заголовок отношения | Заголовок таблицы – названия полей (столбцов) таблицы |
| Тело отношения | Тело таблицы – совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таблицы) |
| Схема отношения | Строка заголовков столбцов таблицы («шапка» таблицы) |
| Атрибут отношения | Наименование столбца таблицы (поле таблицы) |
| Кортеж отношения | Строка таблицы (запись) – однозначное представление объекта реального мира, созданное с использованием значений полей таблицы |
| Домен | Множество допустимых значений атрибута |
| Значение атрибута | Значение поля в записи (кортеже) |
| Первичный ключ | Один или несколько (в случае составного ключа) атрибутов, которые единственным образом определяют значение кортежа (значение строки таблицы) |
| Внешний ключ | Атрибут таблицы, значения которого соответствуют значениям первичного ключа в другой связанной (родительской, первичной) таблице. Внешний ключ может состоять как из одного, так и из нескольких атрибутов (составной внешний ключ). Если число атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего первичного ключа, то он называется усеченным (частичным) внешним ключом |
| Степень (арность) отношения | Количество столбцов таблицы |
| Мощность отношения | Количество строк (кортежей) таблицы |
| Экземпляр отношения | Множество записей (кортежей) для данной таблицы (отношения). С течением времени экземпляр может изменяться. Поскольку обычная БД в текущий момент времени работает только с одной версией отношения, то такой экземпляр отношения называется текущим |
| Тип данных | Тип значений элементов таблицы |
| Базовое отношение | Отношение, содержащие один или несколько столбцов, характеризующих свойства объекта, а также первичный ключ |
| Производное отношение | Не является базовым отношением, т.е. не характеризует свойства объекта и используется для обеспечения связей между другими таблицами, может не содержать первичного ключа. Если первичный ключ задан, то он состоит из внешних ключей, связанных с первичными ключами базового отношения |
| Связь | Устанавливает взаимосвязь между совпадающими значениями в ключевых полях – первичным ключом одной таблицы и внешним ключом другой |
| Связь «один-к-одному» (1:1) | При использовании этого вида связи запись в одной таблице может иметь не более одной связанной с нею записи в другой таблице. В обеих таблицах ключевые поля должны быть первичными. Используется для разделения таблиц с многочисленными полями или по требованию защиты данных |
| Связь «один-ко-многим» (1:M) | При использовании этого вида связи каждой записи одной таблицы может соответствовать несколько записей второй, но каждой записи второй таблицы соответствует лишь одна запись первой таблицы. В первой таблицы обязательно должен быть задан первичный ключ, во второй – внешний |
| Связь «многие-ко-многим» (N:M) | При данном типе связи одной записи в первой таблице может соответствовать несколько записей второй таблицы, но и одной записи второй таблицы может соответствовать несколько записей первой. Уникальность ключей для таких таблиц не требуется. В процессе проектирования схемы БД такие связи преобразуют. Для этого необходимо ввести вспомогательное отношение, позволяющее заменить связь «многие-ко-многим» на две связи типа «один-ко-многим» |
Структура данных реляционной модели предполагает представление предметной области рассматриваемой задачи в виде набора взаимосвязанных отношений.
В каждой связи одно отношение может выступать как основное (базовое, родительское), а другое – в роли подчиненного (производного, дочернего). Для поддержания этих связей оба отношения должны содержать набор атрибутов, по которым они связаны: в основном отношении это – первичный ключ отношения (однозначно определяет кортеж основного отношения); в подчиненном отношении должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Здесь этот набор атрибутов уже является вторичным ключом или внешним ключом, т.е. определяет множество кортежей производного отношения., связанных с единственным кортежем основного отношения.
Множество взаимосвязанных друг с другом таблиц образуют схему БД .
Итак, отношение R представляет собой двумерную таблицу, содержащую некоторые данные.
Математически N -арное отношение R – это множество декартова произведения D 1 ×D 2 ×…×D n множеств (доменов) D 1 , D 2 ,…,D n (n ≥1), необязательно различных:
R D 1 ×D 2 ×…×D n ,
где D 1 ×D 2 ×…×D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.
Домен представляет собой семантическое понятие, которое можно рассматривать как подмножество значений некоторого типа данных, имеющих определенный смысл.
Свойства домена :
Домен имеет уникальное имя (в пределах БД),
Определен на некотором простом типе данных или на другом домене,
Может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для этого домена,
Несет определенную смысловую нагрузку.
Основное значение доменов состоит в том, что они ограничивают сравнения: нельзя сравнивать значения из различных доменов, даже если они имею одинаковый тип данных.
Атрибут отношения представляет собой пару вида
<Имя_атрибута: Имя_домена> (либо <A:D >).
Имена атрибутов в пределах отношения уникальны. Часто имена атрибутов совпадают с именами соответствующих доменов.
Отношение R, определенное на множестве доменов, содержит две части: заголовок и тело.
Заголовок отношения – фиксированное кол-во атрибутов отношения, описывающее декартово произведение доменов, на котором задано отношение:
(<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >).
Заголовок статичен: не меняется во время работы с БД, Если в отношении изменены, добавлены, удалены атрибуты, то получается уже другое отношение. Даже при сохраненном имени.
Тело отношения содержит множество кортежей отношения.
Каждый кортеж представляет собой множество пар вида:
<Имя_атрибута: Значение атрибута>:
R (<A 1:Val 1 >, <A 2:Val 2 >, …, <A n: Val n >).
Таких, что значение Val i атрибута A i принадлежит домену D i .
Тело отношения представляет собой набор кортежей, т. Е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных, т. К. кортежи с течением времени могут изменяться, добавляться и удаляться.
Отношение обычно записывается в виде:
R (<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >),
либо сокращенно: R (A 1 , A 2 , …, A n ) или R .
Схема отношения представляет собой набор заголовков отношения, входящих в базу данных, т. Е. перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:
S R = (A 1 , A 2 , …, A n ), A i D i , i = 1,..., n .
Если атрибуты принимают значения из одного и того же домена, то они называются θ-сравнимыми, где θ - множество допустимых операций сравнений, заданных для данного домена.
Например, если домен содержит числовые данные, то для него допустимы все операции сравнения: θ == {=, <>,>=,<=,<,>}. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он также имеет полное множество операций сравнения.
Схемы двух отношений называются эквивалентными , если они имеют одинаковую степень, и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, т. Е. атрибуты, принимающие значения из одного домена.
Таким образом, для эквивалентных отношений выполняются следующие условия:
Наличие одинакового количества атрибутов;
Наличие атрибутов с одинаковыми наименованиями;
Наличие в отношениях одинаковых строк с учетом того, что порядок атрибутов может различаться;
Отношения такого рода есть различные изображения одного и того же отношения.
Свойства отношений непосредственно следуют из приведенного ранее определения отношения. В этих свойствах в основном и состоят различия между отношениями реляционной модели данных и простыми таблицами:
Уникальность имени отношения. Имя одного отношения должно отличаться от имен других отношений.
Уникальность кортежей. В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Каждая ячейка отношения содержит только атомарное (неделимое) значение.
Неупорядоченность кортежей. Кортежи не упорядочены (сверху вниз), т. К. тело отношения есть множество, а множество не упорядочено (для сравнения - строки в таблицах упорядочены). Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
Неупорядоченность атрибутов. Атрибуты не упорядочены (слева направо).
Уникальность имени атрибута в пределах отношения. Каждый атрибут имеет уникальное имя в пределах отношения, значит, порядок атрибутов не имеет значения (для сравнения - столбцы в таблице упорядочены). Это свойство несколько отличает отношение от математического определения отношения. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.
Атомарность значений атрибутов. Все значения атрибутов атомарны. Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения, т. Е. с каждым триибутом связана какая-то область значений (отдельный элементарный тип), значения атрибутов берутся из одного и того же домена. Схема и кортежи отношения - множества, а не списки, поэтому порядок их представления не имеет значения. Для сравнения - в ячейки таблицы можно поместить различную информацию: массивы, структуры, другие таблицы и т. Д.
Замечание:
Из свойств отношения следует, что не каждая таблица может быть отношением. Для того чтобы некоторая таблица задавала отношение, необходимо, чтобы таблица имела простую структуру (содержала только строки и столбцы, причем в каждой строке должно быть одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми.
Следует отметить, что реляционная модель представляет собой базу данных в виде множества взаимосвязанных отношений, которые называются схемой реляционной базы данных .
ВЛАДИМИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Имени Александра Григорьевича и Николая Григорьевича Столетовых
КАФЕДРА БИЗНЕС-ИНФОРМАТИКИ И ЭКОНОМИКИ
РЕФЕРАТ
по дисциплине «Базы данных»
на тему: «Объектно-ориентированные модели данных»
Выполнила:
студентка 3-го курса
группы БИ-114
Фадеева А.А.
Принял:
ст. пр. Виноградов Д.В.
Владимир 2016
Введение. 3
Общая характеристика объектно-ориентированных моделей данных. 4
Объектно-реляционная модель данных. 5
Пространственная модель данных. 8
Список литературы.. 13
Введение
В последнее время при разработке автоматизированных информационных систем широко применяется объектно-ориентированный (ОО) подход. В его основе лежит предположение о том, что человек видит окружающий мир как множество объектов. Объектно-ориентированные модели изначально строились с учетом ее эволюции и расширения. Эти модели базируются на основных понятиях и методах, разработанных в объектно-ориентированном програмировании (ОПП) и представленных в широко используемых языках объектно-ориентированного программирования, таких как С++, Java и др. Объектно-ориентированные модели данных являются расширением положений объектно-ориентированного программирования.
Данные модели связаны с развитием Интернет–технологий. В объектно-ориентированных моделях при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Общая характеристика объектно-ориентированных моделей данных
Один из основных подходов к построению БД – использование объектно-ориентированной модели данных (ООМД). Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).
При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:
· встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;
· расширение существующего языка работы с базами данных объектно-ориентированными функциями;
· создание объектно-ориентированных библиотек функций для работы с БД;
· создание нового языка и новой объектно-ориентированной модели данных.
К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.
Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.
В 2000 г. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.
Объектно-реляционная модель данных
Объектно-реляционная модель данных является гибридной моделью, сочетающей возможности реляционной модели с объектными свойствами данных.
1. Объекты, видимые на внешнем интерфейсе, отображаются в таблицы поддерживающей реляционной БД. И наоборот, объекты воспроизводятся из их представления в табличной среде хранения, когда они запрашиваются пользователями или приложениями (гибридный подход).
Такой подход был популярен в конце 80-х гг. и воплотился в программных продуктах для автоматизации программирования (CASE), для автоматизации проектирования (CAD), в репозитариях (БД, предназначенных для хранения не пользовательских, а системных данных).
2. Внутренние реляционные механизмы СУБД управления данными расширяются объектно-ориентированными возможностями (расширенный реляционный подход).
Этот подход технологически более продвинутый и предпочитаемый в настоящее время большинством разработчиков реляционных СУБД. Он воплотился в 1996-1997 гг. в ряде объектно-реляционных серверов БД.
Отличительная особенность объектно-реляционной модели от ООМД состоит в том, что она основана на стратегии реляционной модели. О включении объектов в реляционную модель можно говорить на данном этапе только как об общем направлении развития баз данных.
Вся возрастающая сложность приложений баз данных и ограниченность реляционной модели привели к развитию модели Кодда, которое сначала получило название расширенной реляционной модели, а позже получило свое развитие в объектно-реляционной модели данных. Базы данных, основанные на этих моделях, принято относить к 3-му поколению.
Основная идея объектно-реляционного подхода - это допущение использовать в качестве атрибутов не только простые, атомарные типы данных, но и составные, абстрактные типы данных, что противоречит классической концепции реляционных СУБД.
Объектно-реляционная модель данных (ОРМД) реализована с помощью реляционных таблиц, но включает объекты, аналогичного понятию объекта в объектно-ориентированном программировании. В ОРМД используются такие объектно-ориентированные компоненты, как пользовательские типы данных, инкапсуляция, полиморфизм, наследование, переопределение методов и т.п. В большинстве реализаций ОРМД объектами признаются агрегат и таблица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, которые являются процедурными объектами базы данных, и связаны с таблицами. На концептуальном уровне все данные объектно-реляционной БД представлены в виде отношений, и ОРСУБД поддерживают язык SQL. Объектно-реляционная модель данных характеризуется тем, что:
· классы объектов в объектно-реляционной БД соответствую таблицы
· объекты будут соответствовать отдельным записям в таблице
· в качестве первичного ключа для таблицы базового класса проще всего взять поле целочисленного типа. В таблицах - наследниках ему будет сопоставлено обычное целочисленное поле
· первичный ключ в таблице является идентификатором объекта
· каждый объект может собираться из записей нескольких таблиц базового класса и наследников
Базовый класс объектов должен уметь выполнять основные действия с единичным экземпляром объекта: создание, загрузка, сохранение, удаление. Базовый класс должен обеспечивать возможность изменения и удаления сразу множества объектов.
К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).
Сегодня практически все известные фирмы используют объектные технологии. IBM и Oracle доработали свои СУБД (DB2 и ORACLE8, соответственно, добавив объектную надстройку над реляционным ядром системы, т.е. преобразовали их в объектно-реляционные СУБД. Informix приобрела объектно-реляционную СУБД Illustra и встроила ее в свою СУБД, изменив ее название на универсальный сервер.
В настоящее время реляционные СУБД доминируют среди систем управления данными. Преимущества объектно-ориентированного подхода для создания сложных специализированных приложений с одной стороны, и стремление разработчиков систем управления базами данных с другой стороны расширить границы применения соответствующих СУБД обусловили включение объектно-ориентированных компонент (расширяемая пользователем система типов, инкапсуляция, наследование, полиморфизм и т. п.) в модель данных реляционной СУБД. Соответствующие СУБД, называемые объектно-реляционными , соединяют в себе лучшие качества реляционных и объектно-ориентированных баз данных. Отметим, что в разных СУБД реализован разный набор из перечисленных объектно-ориентированных компонент. Таким образом, не существует общепринятой объектно-реляционной модели, а скорее имеется несколько таких моделей, поддерживающих определенный набор объектно-ориентированных компонент. Однако, основой всех таких моделей являются реляционные таблицы, используется язык запросов, включено понятие объекта, а в некоторых дополнительно реализована возможность сохранения методов в базе данных.
Соответствующие изменения реляционной модели обусловили необходимость расширения стандарта языка запросов SQL. Первый вариант такого стандарта получил название SQL3. Работа над стандартом продолжается и в настоящее время.
В качестве примера в максимальной степени объектно-ориентированной СУБД можно указать исследовательскую СУБД Postgres{3].
Отметим считающиеся объектными расширениями элементы СУБД Microsoft Server 2008.
· Пользовательские расширения. Пользователи имеют возможность вмешиваться в изначально предоставляемый СУБД инструментарий, создавая, в частности, новые пользовательские типы данных.
· Хранение больших объемов данных . Наряду с теми данными, которые хранились в БД традиционно, Microsoft SQL Server 2008 позволяет хранить в столбцах таблицы данные больших размеров (поддерживаются соответствующие типы данных).
· Новые, ориентированные на определенные классы объектов, типы данных . В системе определены новые типы данных (geometry, geography), характерные для тех направлений, в которых объектно-ориентированный подход весьма эффективен и часто используется (картография и соответствующие приложения, геометрическое представление объектов самой разной природы).
· Хранимые процедуры. В определенном смысле хранимые процедуры также являются объектным расширением, осуществляя необходимые пользователю воздействия на данные (стандартный для ООП процедурный подход).
2. Распределенные базы данных
База данных – интегрированная совокупность данных, с которой работают много пользователей. Изложение всех предыдущих разделов предполагало единую базу данных, размещаемую на одном компьютере. Напомним основные принципы, положенные в основу теории баз данных:
· централизованное хранение данных;
· централизованное обслуживание данных (ввод, корректировка, чтение, контроль целостности).
Заметим, что базы данных появились в период господства больших ЭВМ. База данных велась на одной ЭВМ, все пользователи работали именно на ЭВМ (возможные режимы работы описаны в лекции 3). Других вариантов использования вычислительной техники в то время просто не существовало. Если проанализировать работу пользователей с данными в компаниях, организациях, предприятиях в «докомпьютерное» время, то нетрудно заметить, что на отдельных участках пользователи работали со «своими» данными (осуществляли сбор определенных данных, их хранение, обработку, передачу обработанных данных на другие участки или уровни управления).
У такой технологии были существенные недостатки, которые уже отмечались в предыдущих разделах: дублирование некоторых данных, отсутствие возможности сравнительного анализа данных всех участков. Однако у этой технологии были и существенные достоинства: данные вводились и хранились в местах их порождения; с этими данными работал пользователь, являющийся специалистом именно по этим данным, что позволяло ему вести эффективный контроль правильности данных на всех стадиях обработки; данные находились непосредственно у пользователя, что давало возможность их оперативной обработки. Централизация данных на одной ЭВМ, несомненно, дающая эффективные возможности хранения и обработки данных, не позволяла реализовывать вышеназванные достоинства.
Развитие вычислительных компьютерных сетей обусловило новые возможности в организации и ведении баз данных, позволяющие каждому пользователю иметь на своем компьютере свои данные и работать с ними и в то же время позволяющие работать всем пользователям со всей совокупностью данных как с единой централизованной базой данных. Соответствующая совокупность данных называется распределенной базой данных.
Термин «распределенная база данных » достаточно часто встречается в литературе . Однако в разных источниках под этим термином понимаются совершенно разные вещи. Часть авторов понимают под распределенной базой данных то, что имеется удаленный сервер, на котором расположены данные, а также клиентские компьютеры, расположенные территориально в другом месте. Такая трактовка нам представляется неправильной. Настоящая распределенная база данных располагается на нескольких компьютерах. При этом часть файлов расположена на одном компьютере, часть на другом и т.д. Более того, возможна и даже часто встречается ситуация, когда информация на этих компьютерах пересекается, дублируется.
Распределенная база данных – совокупность логически взаимосвязанных разделяемых данных (и описаний их структур), физически распределенных в компьютерной сети.