Объект – уникально определяемая сущность, которая содержит атрибуты, описывающие состояния объекта реального мира и связанные с ними действия (правила поведения). Во многом объект и сущность РБД совпадает по свойствам, однако сущность моделирует только состояние, а объект инкапсулирует и правила поведения.
Среди атрибутов объекта выделяется ссылочный атрибут: он содержит значение/коллекцию значений, которое само является объектом. Иначе говоря, ссылочный атрибут концептуально аналогичен внешнему ключу в РБД или указателям в ЯП.
Каждому объекту в момент создания присваивается идентификатор объекта OID. Он обладает следующими свойствами:
1. Генерируется системой
2. Уникально обозначает этот объект
3. Его нельзя изменить пока объект продолжает существовать
4. После создания объекта его идентификатор нельзя использовать повторно в дальнейшем при любых условиях.
5. Не зависит от значений атрибутов объекта, т.е. 2 объекта могут и иметь одинаковое состояние, но они всегда обладают разными OID.
6. В идеале – OID скрыто от пользователей.
За счет OID целостность сущностей гарантируется автоматически.
Объект инкапсулирует не только данные, но и функции (методы). В объектной базе методы могут изменять состояние объекта за счет изменения значений атрибутов или для создания запроса по отношению к определенным значениям конкретных атрибутов.
Сообщения – средство взаимодействия объектов. Содержательно сообщения – запрос одного объекта (отправителя) к другому (получателю), где второму объекту предлагается выполнить один из его методов.
Классы – группировка одинаковых объектов.
Наследование – один класс определяется как частный случай (подкласс) более общего класса (суперкласс). Подкласс наследует все свойства суперкласса + доп. определяет свои собственные атрибуты и методы. Все экземпляры под класса являются экземплярами суперкласса. Принцип подстановки: экземпляр под класса всегда может пользоваться любым методом/атрибутом суперкласса или в любой конструкции, где используется суперкласс. Понятие под-, суперкласса и наследования существует также в расширенной РБД модели. Однако в чисто объектной модели наследование относится и к состоянию и к поведению.
Перегрузка позволяет повторно использовать имя метода в одном или нескольких методах класса. Частный случай перегрузки – перекрытие. Оно позволяет заново определить имя свойства в некотором подклассе.
Динамическое связывание позволяет отложить линковку до выполнения.
Объектные модели
Объектная модель поволяет решить некоторые проблемы связанные с некоторыми реляционными базами.
Проблемы:
1. Поддержка нескольких версий
Управление версиями- это процесс сопровождения эволюциями объекта.
Механизм отслеживания версий должен управлять изменениями свойств объектов так, чтобы ссылки на объект всегда указывали на правильную версию.
Для управления версиями выделяются три типа версий: 1) временная версия- считается нестабильной, может быть удалена или обновлена, хранится в закрытом рабочем пространстве разработчика проекта.
2) Рабочая версия — считается более стабильной, не может быть обновлена, но может быть удалена ее создателем, так же хранится в закрытом рабочем пространстве разработчика.
3) Выпущенная версия (релиз)-считается стабильной, не может быть обновлена или удалена, хранится в открытой базе и помещается туда в следствии извлечения рабочей версии из закрытого пространства разработчика.
2. Поддержка продолжительных транзакций
Для пользователя который инициировал долговременную транзакцию важно сохранять какие то промежуточные результаты на случай сбоя транзакции, например из за конфликта блокировок.
Вырианты решения проблем: 1) вводится протокол управления параллельным выполнением с временными метками.
Для каждого элемента данных в базе хранятся тройки величин соответствующих каждой смене значения элемента. Мы храним собственное значение элемента версии, мы храним последнюю отметку открытия версии, временную отметку записи версии.
В этом случае нескольким транзакциям разрешается читать и записывать разные версии одного и того же элемента данных.
Версии могут быть удалены сразу после полного завершения всей транзакции.
1) Определяется временная отметка самой старой транзакции в системе, все то ниже этой транзакции удалятется.
2) Вводятся усовершенствованные модели транзакциий. (полная транзакция раскладывается в древовидную структуру сумм транзакций которые выполняются в параллельном режиме.
3) Использование точек сохранения и эммуляция вложенных транзакций. (Точкой сохранения называется некоторой точкой плоской транзакции, которая используется как точка промежуточного перезапуска.
4) Механизм хроник (саги) субд гарантирует что либо все входящие в хронику транзакций будут завершены, либо будут запущены компенсирующие транзакции.
3. Поддержка эволюции проекта т.е. Имеются гибкие средства динамического определения и изменения схемы базы.
Для этого применяются различные креативные подходы, например в некоторых продуктах вводятся инвариантные схемы, которые недолжны изменяться при любой модификации.
В целом методы модификации базы основываются на наличии или искуственном введении в объекты системы частично частичной упорядоченности (упорядоченности типа #) это невозможно в реляционных базах.
Недостаток: практически объектная база пишется в ручную.
В объектной базе имеются аналогии с основными приемами работы в реляционной базе.
Нормализация в объектной базе означает — каждый атребут объекта, должен зависеть от идентификатора объекта.
Связи в объектной базе предствалены с помощью ссылочных атребутов.
Ссылочная целостность.
Варианты управления: 1) пользователю запрещается явно удалять объекты, система сама удаляет объекты которые становятся недоступными.
2) пользователю разрешается удалять объекты когда они становятся ненужными, тогда система автоматически обнаруживает недействительные ссылки и присваивает недействительную ссылку NULL.
3) пользователю разрешается изменять и удалять объекты, а система использует обратные атребуты.
ОБЩАЯ ХАРАКТЕРИСТИКА ОБЪЕКТНО РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ
Общая идея ОР модели состоит в дополнении Р модели объектно ориентированными возможностями, а именно добавляется расширяемая пользователем система типов данных, добавляется инкапсуляция, наследование и полиморфизм, добавляется использование сложных объектов, и добавляется идентификация объектов.
Приемущества: повторное и совместное использование стандартных компонентов.
Сервер субд дополняется стандартными функциями которые ненужно писать в виде исполняемого кода в составе отдельных приложений.
Пример поддерки линейного программирования, когда функции исполняются центролизованно.
Возможность постепенного перехода к объектным методам с повышением уровня квалификации пользователей.
Недостатки: Искажение объектной идеологии.
РАСШИРЕННЫЙ СТАНДАРТ SQL 3. ОСНОВА ДЛЯ ПОСТРОЕНИЯ ОБЪЕКТНО РЕЛЯЦИОННЫХ БД
Включает: конструкторы типов, строка целиком может сохраняться в виде переменных или передаваться как параметр или возвращаться в результата вызова функции.
Разрешаются определяемые пользователем типы, процедуры, функции, операторы.
Как правило процедуры или функции пишутся вне СУБД, и вызываются в SQL с помощью оперотора CALL.
Конструкторы для типов коллекции: создается единственная таблица в которой имеется несколько уровней вложенности.
Поддержка больших объектов. Большой объект — поле таблицы которое содержитпрои значительное количество данных.
В стандарте SQL содержится три топа больших объектов:
1) большой двоичный объект
2) большой символьный объект
3) Unicode
В стандарте SQL 3 допускается выполнение некоторых операций с объектами: например оператор конкатенации — возвращает символьную строку образованную соединением символьных строк в указанном порядке.
Есть функции извлечения символьной подстроки:
Функция перекрытия строк.
Функция свертки преобразования регистра.
Функция вычисления длины строки.
МОДЕЛЬ ХРАНИЛИЩА ДАННЫХ
Хранилище данных- это предметно ориентированный, интегрированный, привязанный ко времени и не изменяемый набор данных, предназначенный для поддержки принятия решений.
Хранилище данных имеет много общего с реляционной моделью.
Отличия:
1) Хранилище данных организуется не вокруг областей деятельности, а вокруг (предметов, товаров и др.).
2) Данные не обновляются, а только пополняются.
3) Реляционная база проектируется с целью обеспечения интенсивной обработки небольшого количества транзакций, хранилище данных проектируется для обработки единичных произвольных запросов.
4) Базовым объектом модели хранилища является привязанный ко времени факт.
5) Основная операция это агрегирование и основная проблема максимальная скорость доступа к факту.
Хранилище данных.
Базы данных в концепции хранилища описываются с использованием метода «моделирование размерностей».
Каждая модель такого метода состоит из таблицы с составным первичным ключем (таблица фактов), к которому привязан набор небольших фактов (таблиц размерностей).
Каждая таблица размерностей имеет не составной(простой) первичный ключ, который точно соответствует одному из компонентов составного ключа в таблице фактов
Схема звезда — логическая структура в центре которой находится таблица фактов, окруженная содержащими ссылочные данные таблица размерностей, при этом таблицы размерностей, как правило, нормализованы. (посмотреть схему звезды)
Таблицы фактов, как правило, имеют огромный размер по сравнению с таблицами размерностей, большая часть в таблице фактов это числовые данные и результаты сложения чисел.
В хранилищах данных практически никогда не происходит к единичным записям, базовая операция для них это агрегирование.
В тоже время таблица размерностей обычно содержит описательную текстовую информацию, при это атрибуты размерностей используются в качестве ограничений в запросах к хранилищу данных.
Применимость концепции хранилища данных находится в прямой зависимости от удачного структурирования таблицы размерностей.
Схема звезда позволяет ускорить выполнение запросов путем денормализации, т. к. выделяет сущности, к которым часто осуществляется доступ, но денормализацию не следует применять, если дополнительные данные требуются не очень часто.
Схема снежинка — вариант схемы звезда, в которой каждая размерность может иметь своих собственные размерности.
Приимущество хранилищ данных:
1. Эффективность — единообразие структуры обеспечивает более эффективный доступ к данным, независимо от средств доступа.
2. Все размерности в равной степени обеспечивают доступ к таблице фактов, следовательно проект обладает большей способность поддерживать произвольные запросы пользователя.
3. Расширяемость — типичные изменения:
1. Добавление новых фактов, это можно делать при условии, что они имеют такую же степень детализации, как и таблица фактов.
2. Добавление новых размерностей — возможно при условии, что имеется единственное значение данной размерностей, определенное для каждой существующей записи в таблице фактов.
3. Добавление новых атрибутов.
4. Разбиение существующих размерностей на записи с меньшим уровнем детализации, н начиная с определенного момента времени.
Модель данных OLAP
Таблица в реляционной СУБД представляет многомерные данных только в 2-х измерения, теория многомерных кубов использует, которые удобно представлять в виде пространства с размерностью n, каждая сторона такого куба может быть интерпретирована как двумерная таблица.
В каждой ячейке куба находится отдельный факт, а совокупность координат этой ячейки представляет собой полный массив данных об этом факте.
Плюсы:
1. Многомерные БД очень компактны, они обеспечивают простые средства просмотра и манипулирования элементам и данных.
2. Куб легко расширяется, можно каждую ячейку куба развернуть в подкуб.
3. Существует мощнейший мат аппарат для работы с многомерными кубами, это матрицы.
Минусы:
1. С ростом числа размерностей кол-во ячеек в кубе возрастает экспоненциально, время обработки многомерного запроса увеличивается.
2. Как правило такие структуры представляют собой сильно разреженные матрицы. Много NULL.
Для создания эффективной многомерной базы возможно несклолько путей:
1. Выявить иерархическую структуру в данных.
2. Выявить другие порядки типа решетка типичных размерностей.
3. Разбиение гиперкуба на много маленьких кубов с заполненными ячейками.
Таким образом независимо от структуры хранения эффективность определяется метаданными, тоесть ожидаемыми вариантами размещения данных.
Модель слабоструктурированных данных
Слабостр. - называются данные, которые обладают определенной структурой, но эта структура оказывается непостоянна, недостаточно изученной или неполной. Как правило, такие данные не м. б. описаны с помощью одной неизменной схемы.
Если в СУБД должны храниться слабоструктурированные данные, то субд должна формировать схему на основе этих данных.
Большенство подходов к управлению такими данными использует языки запросов, обеспечивающие прохождение по древовидному, размеченному графу. Соответственно выполнение запросов становиться не деклоративными, а традиционными.
Варианты записи слабоструктурированных данных:
1. Модель обмена объектными данными OEM. Модель представления множенных объектов, определяется сама через себя. Позволяется отобразить данные с нерегулярной структурой и неопределенным типом. Представляется собой размеченный, ориентированный граф, в узлах которого находятся особые объекты (объекты OEM), для каждого объекта задаются уникальный идентификатор, описательная текстовая метка, тип, значение. Объекты подразделяются на элементарные и составные. Элементарные — это листья, они на графи отображаются без исходящих ребер. все остальные называются составными, при чем один и тот же объект может иметь произвольное число родительских объектов. Тип конкретного объекта определен как множество ИД объекта. Работать с конструкциями подобного типа тяжело, т. к. невозможно выделить пустую структуру графа.
2. Язык XML — мета язык, язык для описания других языков. Система определения структурированных типов документов и языков разметки, представляющих экземпляры документов данного типа. Достоинтсва:
1. Может применяться для разметки любых документов, в том числе текстовых и мультимедийных.
2. Позволяется наглядно описать структуру данных. Можно использовать для описания гетерогенных (разнородны) БД.
3. Позволяет хранить содержимое документа и отдельно (независимо) способ его представления.
Реляционная алгебра и реляционное исчисление
Язык SQL поддерживает алгеброические формулировки выполнения запроса, алгеброическая формулировка является процедурной, то есть она в явном виде задает последовательность действий для выполнения запроса.
Существует альтернативный вариант для описания запроса который называется логические исчисления.
Существует два варианта реляционной логики — это исчисление кортежей, и исчисление доменов.
Исчисление кортежей — переменной является кортеж(строчка) тела отношения.
Для формирования условий выборки из набора отношений используются так называемые правильно построенные формулы (well formed formula) — это условия накладываемые на кортежные переменные.
Пример: СЛУЖАЩИЙ СЛ_НОМ= НАЧАЛЬНИК НАЧ_НОМ
Для построения WFF используются логические связки и правила мат логики.
Механизм работы: Система перебирает все имеющиеся в бд комбинации кортежей, например для каждого кортежа проект, просматривается облать определений кортежей служащих и выделяет те сочетания кортежей для которых WFF верно.
Таким образом это эквивалентно тому, что система по умолчанию выполняет операцию join.
Исчисление доменов: Основное формальное отличие исчисления доменов от исчисления кортежей — это наличие дополнительного множества предикатов, позволяющих выделить условие членства.
Сопостовление Реляционной алгебры и Реляционного исчисления.
Формально между ними есть отличия, однако с точки зрения исполняющей системы реляционная алгебра и реляционные исчисления логически эквивалентны. Каждое выражение реляционной алгебры может быть однозначно преобразованно в выражение реляционного исчисления и наоборот.
Примеры: Субд которые работают на линукс это INGRES (Integratie graphics retrielale System)(хз че написано у нее подчерк кривой).
И язык табличная форма Query by Example