Реферат: Ооп бд объектно-ориентированная база данных

1.Основные факторы перехода на ООП БД
Объектно-ориентированная база данных (ООБД) — база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями. Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных также, как с объектами в программировании в ООЯП. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. ООСУБД используют точно такую же модель, что и объектно-ориентированные языки программирования.

Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

В манифесте ООБД[1] предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой БД.

Три класса характеристик:

Обязательные.

Необязательные.

Открытые — позволяют пользователю выбирать свойства.

СУБД

Долговременное хранение

Использование внешней памяти

Параллелизм

Восстановление

Нерегламентированные запросы

ОО характеристики

Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.

Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.

Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.

Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)

Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.

Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.

Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.

Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.

Необязательные:

Множественное наследование

Проверка типов

Распределение

Проектные транзакции

Открытые

Парадигмы программирования (процедурное, декларативное)

Система представления

Система типов

Однородность. Реализация — язык программирования — интерфейс.

Думаю этого хватит, но вот:не надо??

Преимущества:

1.                  Объекты в СУООБД могут хранить произвольное количество простых типов и других объектов. Поэтому можно организовать модель данных, как большой класс, содержащий подмножество меньших классов, содержащих в свою очередь другие подмножества классов и так далее. Использование реляционной модели приведет к созданию многочисленных таблиц, при работе с которыми придется постоянно организовывать объединения таблиц. Объект является наилучшей моделью отображения реального мира, нежели реляционные картежи. Особенно это касается сложных и многогранных объектов. СУООБД больше подходит для обработки комплексных, сложно взаимосвязанных данных и в зависимости от сложности данных может превосходить СУРБД по производительности в десятки, а то и в тысячи раз.

2.                  Данные в реальном мире обычно имеют иерархические характеристики. Известный пример с Сотрудниками, используемый в большинстве СУРБД, гораздо проще описать в СУООБД. Чтобы определить для сотрудника, является ли он менеджером или нет, в СУРБД обычно вводят дополнительное поле в таблице Сотрудников, ссылающееся на идентификатор сотрудника-менеджера или создают отдельную таблицу для определения взаимоотношения между Сотрудниками. В СУООБД класс Сотрудник просто является родительским классом для класса Менеджера.

3.                  Для доступа к данным из СУООБД не обязателен отдельный язык запросов, поскольку доступ происходит непосредственно к объектам. Тем не менее, возможность использовать запросы существует.

4.                  В типичном приложении, построенном на использовании объектно-ориентированного языка и СУРБД, значительное количество времени обычно тратится на взаимосвязывание таблиц и объектов. Также существуют различные проблемы, связанные с неполной совместимостью типов данных. При использовании СУООБД данная проблема полностью отпадает.


2.ODMG


При разработке методологии оо проектирование БД важное значение имеет стандарты, предложенные манифестом консорциума Object Database Management Group.

Основной исходной целью была выработка промышленного стандарта ООБД общей модели.

За основу принята базовая объектная модель OMG COM. В последствии были опубликованы 3 базовых версии стандарта, последняя из которых 3.0.
^ Архитектура ODMG


Предлагаемая архитектура определяет способ хранения данных и разные виды пользовательского доступа к хранилищу данных.

Единое хранилище данных доступно из языка ветвления данных, языка запросов и языков манипулирования данных.

Центральной в архитектуре является модель данных.

3 типа языков

ODL (dynamic language)

OQL (query language)

OML (manipulation language)

Модели данных хранятся в постоянном хранилище данных.

Язык определения объектов, запросов и манипулирования разработаны таким образом, что все их возможности опираются на модель данных.

Архитектура допускает существование разнообразных структур для хранения манипулируемых данных, причем все программные библиотеки и все поддерживающее инструментальные средства обеспечиваются в о рамках и должны сохранятся в согласовании с данными.

ODL используется для описание интерфейсов, это язык описания схем БД.

Для программировании я и реализации он не предназначен.

Код на ODL – набор определений типов, констант, исключительных ситуаций, модулей, интерфейсов типов.

Язык обеспечивает мощные возможности для определения литеральных типов, также с помощью него можно определять типы коллекций, существует 4-е разновидности типов коллекций:

Типы категории SET – обычные типы множеств

Типы категории B – типы мультимножеств, в значениях которых допускается элементы дубликатов.

Типы категории LIST – упорядоченные списки значений с возможностью дубликатов.

Значение типа Dictionary – множество пар «ключ - значение», все ключи должны быть различны, для определения типов используется рекурсия, например можно определить тип множества структур с элементами в виде списков мультимножеств.
^ 3. Особливості об'єктної моделі ODMG
В 1991 г. был образован консорциум ODMG (тогда эта аббревиатура раскрывалась как Object Database Management Group , но впоследствии приобрела более широкую трактовку – Object Data Management Group ).

В архитектуре ODMG определяются способ хранения данных и разные виды пользовательского доступа к этому “хранилищу данных”. Единое хранилище данных доступно из языка определения данных, языка запросов и ряда языков манипулирования данными.18 На рис. 2.1 ODL означает Object Definition Language (язык определения объектов), OQL – Object Query Language (язык объектных запросов) и OML – Object Manipulation Language (язык манипулирования объектами).


Основными компонентами архитектуры являются следующие.

Объектная модель данных. Все данные, сохраняемые ООСУБД, структуризуются в терминах конструкций модели данных. В модели данных определяется точная семантика всех понятий


ODL, OQL, OML -> Модель данных ODMG --> Хранилище (Библиотеки, БД, инструментальные компоненты)


Язык определения данных (ODL ). Схемы баз данных описываются в терминах языка ODL , в котором конструкции модели данных конкретизируются в форме языка определения. ODL позволяет описывать схему в виде набора интерфейсов объектных типов, что включает описание свойств типов и взаимосвязей между ними, а также имен операций и их параметров. ODL не является полным языком программирования; реализация типов должна быть выполнена на одном из языков категории OML . Кроме того, ODL является виртуальным языком в том смысле, что в стандарте ODMG не требуется его реализация в программных продуктах ООСУБД, которые считаются соответствующими стандарту. Допускается поддержка этими продуктами эквивалентных языков определения, включающих все возможности ODL , но адаптированных под особенности конкретной системы. Тем не менее, наличие спецификации языка ODL в стандарте ODMG является важным, поскольку в языке конкретизируются свойства модели данных.


Язык объектных запросов (OQL ). Язык имеет синтаксис, похожий на синтаксис языка SQL, но опирается на семантику объектной модели ODMG . В стандарте допускается прямое использование OQL и его встраивание в один из языков категории OML .


Языки манипулирования объектами (OML ). Для программирования реализаций операций и приложений требуется наличия объектно-ориентированного языка программирования. OML представляется собой интегрирование языка программирования с моделью ODMG ; это интегрирование производится за счет определенных в стандарте правил языкового связывания (language binding ). Дело в том, что в самих языках программирования, естественно, не поддерживается стабильность объектов. Чтобы разрешить программам на этих языках обращаться к хранимым данным, языки должны быть расширены дополнительными конструкциями или библиотечными элементами. Эту возможность и обеспечивает языковое связывание.


Введение в объектную модель ODMG


Модель ODMG является объектной моделью данных, включающей возможность описания как объектов, так и литеральных значений. На разработку модели повлиял тот факт, что она предназначена для поддержки работы с базами данных, так что особо важной является эффективность доступа к данным. Большинство других объектных моделей (см. например, матрицу объектных моделей Фрэнка Манолы [9]) ориентировано на языки программирования, расc читанных на работу со всеми данными в основной памяти. В этом случае допустимо представлять все данные как объекты. Но если требуется управлять большим объемом данных, расположенных во внешней памяти, то требуется некоторый компромисс между “чистотой” модели и требуемой эффективностью. Модель ODMG подстраивается под специфику систем баз данных следующим образом:

Для баз данных, схем и подсхем обеспечивается набор встроенных объектных типов.

Модель включает ряд встроенных структурных типов, позволяющих применять традиционные методы моделирования баз данных.

Модель одновременно включает понятия объектов и литералов20.

В модели связи между объектами отличаются от атрибутов объектов (аналогично тому, как это делается в ER -модели).
^ 4.Зв'язки в технології ODMG
Связи

В большинстве объектных систем связи неявно моделируются как свойства, значениями которых являются объекты. Например, если человек работает на некоторую компанию, то у каждого объекта-человека должно иметься свойство, которое можно назвать worksFor и значением которого является соответствующий объект-компания. Возникает проблема, если у объекта-компании имеется свойство, которое затрагивает множество служащих этой компании (например, employees – множество, включающее все объекты служащих данной компании). Эти два свойства являются несвязными, и поддержка их согласованности может вызывать значительную программистскую проблему.

В модели ODMG , подобно ER -модели, различаются два вида свойств – атрибуты и связи, хотя и несколько другим образом. Атрибутами называются свойства объекта, значение которых можно получить по OID объекта, но не наоборот. Значениями атрибутов могут быть и литералы, и объекты, но только тогда, когда не требуется обратная ссылка. Связи – это инверсные свойства. В этом случае значением свойства может быть только объект, поскольку литеральные значения не обладают свойствами. Поэтому возраст служащего обычно моделируется как атрибут, а компания, в которой работает служащий, – как связь.

При определении связи должна быть определена ее инверсия. В приведенном выше примере, если worksFor определяется как связь, должно быть явно указано, что инверсией является свойство employees объекта-компании, а при определении employees должна быть указана инверсия worksFor . После этого система баз данных должна поддерживать согласованность связанных данных, что позволяет сократить объем работы программистов приложений и повысить надежность их программ. Если в объекте-компании свойство employees не требуется, то свойство объекта-служащего employees может быть атрибутом.


^ 5. Об'єкти і літеральні типии
Объектные и литеральные типы

В модели ODMG база данных представляет собой коллекцию различимых значений (denotable values ) двух видов – объекты и литералы. Объекты обладают свойствами идентифицируемости и индивидуального существования, а литералы являются компонентами объектов. Модель данных содержит конструкции для спецификации объектных и литеральных типов. Объектные типы существуют в иерархии объектных типов; литеральные типы похожи на типы, характерные для обычных языков программирования (например, С или Pascal ). В модели ODMG не используется термин класс. Единственная классификационная конструкция называется типом, и типы описывают как объекты, так и литералы. То, что называлось классом в Первом манифесте, в ODMG называется объектным типом.

В модели поддерживается ряд литеральных типов – базовые скалярные числовые типы, символьные и булевские типы (атомарные литералы), конструируемые типы литеральных записей (структур) и коллекций. Конструируемые литеральные типы могут основываться на любом литеральном или объектном типе, но считаются неизменчивыми. Даты и время строятся как литеральные структуры. Подробнее о литеральных типах см. в следующем подразделе.

Объектный тип состоит из интерфейса и одной или нескольких реализаций.25 Интерфейс описывает внешний вид типа: какими свойствами он обладает, какие в нем доступны операции и каковы параметры у этих операций.26 В реализации определяются структуры данных, реализующие свойства, и программный код, реализующий операции. Интерфейс составляет общедоступную (public ) часть типа, а в реализации при необходимости могут вводиться дополнительные частные (private ) свойства и операции. Все объектные типы (системные или определяемые пользователем) образуют решетку (lattice ) типов, в корне которой находится предопределенный объектный тип Object .

Поскольку для определения реализации объектного типа требуется использовать один из языков OML , которые мы в этой статье не обсуждаем, ограничимся рассмотрением интерфейсной части типа. Интерфейс объектного типа состоит их следующих компонентов:

имя;

набор супертипов;

имя поддерживаемого системой экстента;

один или более ключей для ассоциативного доступа;

набор атрибутов,каждый из которых может быть объектом или литеральным значением;

набор связей, каждая из которых указывает на некоторый другой объект;

набор операций.


Атрибуты и связи совместно называются свойствами, а свойства и операции совместно называются характеристиками объектного типа (или объектов данного типа).

Точно так же, как имеются атомарные и конструируемые литеральные типы, существуют атомарные и конструируемые объектные типы. В стандарте ODMG 3.0 говорится, что атомарными объектными типа являются только типы, определяемые пользователями (см. ниже).. Конструируемые объектные типы включают структурные типы и набор типов коллекций.


^ 6.Мова визначення об‘єктів Понятие о DDL
Язык SQL имеет две составляющие: язык обращения с данными Data Manipulation Language (DML) и язык определения данных Data Definition Language (DDL). DML состоит из операторов, используемых для создания и получения данных. DDL состоит из операторов, используемых для создания объектов в базе данных и для установки свойств и значений атрибутов самой базы данных.

DML и DDL

Чем же отличаются эти две группы операторов? В то время, как операторы DML достаточно однотипны для различных реализаций SQL (что дает возможность каждому поставщику программной продукции вводить свои расширения), DDL имеет существенные различия для разных продуктов.
^ Создание объектов
Объекты базы данных создаются программным путем с помощью оператора CREATE. Точный синтаксис оператора CREATE различен для каждого объекта, однако объекты, которые вы можете создавать, а также базовый синтаксис оператора CREATE для каждого объекта, вы можете найти в таблице 22.1.

Таблица 22.1. Операторы CREATE.

Синтаксис оператора CREATE

Создаваемый объект

^ CREATE DATABASE <имя>

Создает базу данных

CREATE DEFAULT <имя> AS < выражение_константы >

Создает значение по умолчанию

^ CREATE FUNCTION <имя> RETURNS <возвращаемое_значение> AS <операторы_tsql>

Создает пользовательскую функцию (См. урок 30, "Пользовательские функции")

^ CREATE INDEX <имя> ON <таблица_или_представление> (<индексируемые_столбцы>)

Создает индекс в таблице или представление











































Из операторов CREATE, рассмотренных в таблице 22.1, только оператор CREATE TABLE является достаточно сложным. Это вызвано тем, что определение таблицы составляет несколько различных элементов. Вы должны определить столбцы, а каждый столбец должен иметь имя и тип данных. Вы можете задать для столбцов возможность использования нулевых (NULL) значений идентификационной строке или в GUID, значение по умолчанию, любые ограничения, применимые к столбцу, а также несколько других свойств, которые мы не будем здесь рассматривать. Упрощенная версия синтаксиса, для определения столбцов имеет следующий вид:

<имя_столбца> <тип_данных>

^ [NULL | NOT NULL]

[

[DEFAULT <значение_по_умолчанию>] |

[IDENTITY [(начальное_значение>, <шаг_увеличения>)[NOT FOR REPLLCATION]]]]

[ROWGUIDCOL]

[<ограничение_для_столбца>[, <ограничение_для_столбца>...]]


^ Изменение объектов

В то время как оператор CREATE создает новый объект, оператор ALTER предоставляет механизм для изменения определения объекта. Не все объекты, созданные с помощью оператора CREATE, имеют соответствующий оператор ALTER. В таблице 22.2 приведен синтаксис для объектов, которые могут быть изменены.

Таблица 22.2. Операторы ALTER

Синтаксис оператора ALTER

Действие

^ ALTER DATABASE <имя> <спецификация_файла>

Изменяет файлы, используемые для хранения базы данных

ALTER FUNCTION <имя>

RETURNS <возвращаемое_значение>

AS < операторы_tsql>

Изменяет операторы Transact-SQL, содержащие функцию

^ ALTER PROCEDURE <имя>

AS < операторы_tsql>

Изменяет операторы Transact-SQL, содержащие в себе хранимую процедуру (См. урок 28, "Хранимые процедуры")

^ ALTER TABLE <имя>

<определение_изменения>

Изменяет определение таблицы (В этом уроке мы подробно рассмотрим <определение_изменения>.)

^ ALTER TRIGGER <имя>

{FOR | AFTER | INSTEAD OF} <действие_dml>

Изменяет операторы Transact-SQL, содержащие в себе триггер (См. урок 29, "Триггеры")

^ ALTER VIEW <имя>

AS <оператор_выборки>

Изменяет операторы SELECT, которые создают представление

Оператор ALTER TABLE является составным по той же причине, почему и оператор CREATE TABLE: определение таблицы состоит из нескольких различных частей. Упрощенная версия синтаксиса для оператора ALTER TABLE приведена ниже:

^ ALTER TABLE <имя>

{

[ALTER COLUMN <определение_столбца>] |

[ADD <определение_столбца>] |

[DROP COLUMN <имя_столбца>] |

[ADD [WITH NOCHECK] CONSTRAINT <ограничение_для_таблицы>]

}


Ключевые слова CHECK (подразумевается) и NOCHECK перед ограничением таблицы, предписывают SQL Server тестировать или не тестировать имеющиеся в таблице данные с учетом нового ограничения. WITH NOCHECK используется лишь в крайне редких случаях.

^ Изменение столбцов

Ниже представлено несколько ограничений для фразы ALTER COLUMN. Столбец не может быть изменен, если он:

имеет тип данных text, image, ntext или timestamp;

определен в таблице как ROWGIDCOL;

является вычисляемым столбцом или используется в вычисляемом столбце;

является реплицированным;

используется в индексе – если только столбец не имеет тип данных varchar, nvarchar или varbinary; тип данных не изменяется и размер столбца не уменьшается;

используется в статистике, генерируемой оператором CREATE STATISTIC;

используется в ограничении PRIMARY KEY;

используется в ограничении FOREIGN KEY REFERENCES;

используется в ограничении CHECK;

используется в ограничении UNIQUE;

указывается как DEFAULT.
^ Удаление объектов
Оператор DROP удаляет объект базы данных. В отличие от операторов CREATE и ALTER, операторы DROP имеют простой и неизменный синтаксис:

DROP <тип_объекта> <имя>


7. Преимущества и недостатки Oracle
Основные достоинства Oracle:

используется для создания специализированных приложений баз данных с высокой интенсивностью запросов;

обеспечивает надежность хранения информации, безошибочность работы, защищенность управления данными, отказоустойчивость при работе на операционных системах Microsoft Windows 95, Microsoft Windows NT и UNIX;

обеспечивает высокоинтенсивную обработку в режиме online;

содержит механизмы поддержания ссылочной целостности и контроля вводимой информации;

имеет встроенную систему безопасности, избирательный доступ к объектам базы данных;

не содержит ограничений по количеству индексов;

обеспечивает резервное копирование on-line;

имеет встроенную поддержку русского языка;

если объем базы данных будет расти, а "железо" оставаться без изменений, то возможно разделение таблиц на несколько частей, находящихся при желании на нескольких физических дисках.

Основной недостаток Oracle:

сравнительно дорогая СУБД
RAC
Технология Real Application Cluster, появившаяся в 9-й версии СУБД Oracle, позволяет объединять сервера, обслуживающие СУБД в одну <большую базу данных>, что позволяет достичь двух ключевых целей:

Повышение производительности системы в целом путем добавления в кластер нового оборудования, без замены оборудования на более мощное. Производительность системы повышается пропорционально мощности подключенного узла. Следствием является сохранение инвестиций в оборудование, часто довольно существенных.

Повышение отказоустойчивости СУБД: при выходе из строя или плановом выключении одного из серверов, входящих в кластер, СУБД полностью сохраняет свою работоспособность.



Похожие технологии реализованы в Microsoft SQL Server 2008, но имеется одно существенное отличие: Microsoft Application Cluster позволяет повысить отказоустойчивость системы в целом, но без влияния на производительность.

Таким образом, использование RAC позволяет значительно повысить производительность системы, которая дошла до своего <физического потолка>, с сохранением средств, потраченных на это оборудование, и повысить отказоустойчивость системы. Как следствие – надежность и экономия.
RAT
Технология Real Application Testing позволяет значительно снизить затраты на проведение плановых изменений в конфигурации существующего программного или аппаратного обеспечения.

Суть технологии RAT заключается в воспроизведении нагрузки на тестовой базе данных в точном соответствии с нагрузкой на рабочем сервере.


^ Active Data Guard
Эта технология позволяет создать резервный сервер основной базы данных с применением всех изменений, сделанных на основном сервере. Получается система, где работают как минимум два сервера: основной и резервный. В случае выхода из строя или плановой остановки основного сервера в работу автоматически вступает резервный сервер, и все пользователи автоматически переключаются и продолжают работу на резервном сервере. Технология проста в реализации и настройке и не требует больших затрат на развертывание и оборудование. Физически резервный сервер может находиться в другом помещении, здании или даже городе. Все, что требуется, – это обычное сетевое соединение между двумя серверами.

Можно использовать несколько резервных серверов для одного рабочего сервера.Какие преимущества предоставляет использование этой технологии ?

Во-первых, очевидное – надежность. Живучесть и отказоустойчивость базы данных повышается на порядок.

Во-вторых, разгрузка рабочего сервера от резервного копирования, которое можно выполнять на standby (резервном) сервере, и разгрузка от отчетов и прочих операций <только на чтение>, которые также можно выполнять на резервном сервере.

В-третьих, плановое выключение резервного сервера, например, для обновлений, не затронет работу пользователей.

Похожие технологии реализованы и в DB2 и в MS SQL Server, но Oracle Data Guard выгодно отличается простотой реализации и возможностью использовать резервный сервер в работе и резервном копировании, а также поддержкой различных режимов синхронизации основного и резервного сервера: синхронный, асинхронный, отложенный.
^ Total Recall
Сутью технологии Total Recall является возможность разгрузки базы данных от информации устаревшей, но которую необходимо хранить по требованиям бизнеса или контролирующих органов с сохранением обычного доступа к этой информации.

Использование Total Recall позволяет разгрузить таблицы базы данных от накопленной и редко использующейся информации. Но сохраняется возможность выполнить обычный SQL запрос и получить такую информацию на любой момент в прошлом, т.е. не требуется вносить какие-то изменения в существующее приложение, работающее с базой. Помимо этого, Total Recall обеспечивает неизменность исторической информации и защиту от ее подделки.


Похожих или аналогичных технологий в других СУБД пока не реализовано.
^ In Memory Database Cache
Уникальная технология In Memory Database Cache реализована на базе существующей базы данных Oracle TimesTen in memory database. Эта СУБД за счет ряда применяемых уникальных решений позволяет увеличить скорость обработки транзакций и выдачи запросов более чем на порядок (т.е. в 10 раз), чем обычная СУБД Oracle Database. Эта СУБД ориентирована на хранение и обработку данных только в оперативной памяти сервера.


Начиная с 10-й версии Oracle Database, СУБД Oracle TimesTen может выступать в качестве промежуточного звена между клиентским приложением и Oracle Database. В этом случае TimesTen реализует функции сверхбыстрого кэша данных, принимая и обрабатывая транзакции и передавая обработанные данные на хранение в Oracle Database. Такая архитектура позволяет значительно повысить потенциал и расширить сферу применения Oracle Database. Фактически, в такой архитектуре Oracle Database способна справиться с любой транзакционной нагрузкой.
^ Automatic Storage Management
Технология ASM приносит принципиально новые концепции в управление дисковой подсистемой сервера базы данных. Суть этой технологии заключается в абстрагировании дисковой подсистемы СУБД от файлов на жестком диске в файловой системе и абстрагировании собственно сервера базы данных от расположения файлов на дисках. В ASM управление осуществляется не файлами на дисках, а разделом диска, не форматированным в файловой системе. Причем, если используется не один жесткий диск, а набор дисков или RAID-массивов, эти диски объединяются в группу ASM и выглядят для СУБД как один жесткий диск.


Решением задачи по распараллеливанию данных по жестким дискам для достижения оптимальной производительности занимается теперь не системный администратор, а экземпляр ASM в автоматическом режиме и эффективней, чем это мог бы сделать администратор БД. Также решается задача по обеспечению надежности за счет избыточности хранимых данных. Уровень избыточности задается системным администратором. Теперь возможно извлекать и добавлять жесткие диски для базы данных <налету>, путем выполнения простых команд ASM. Поскольку ASM – это отдельный экземпляр, т.е. отдельнаый программный комплекс, не связанный с СУБД, один экземпляр ASM может обслуживать несколько экземпляров СУБД.

Аналогичных решений в других СУБД пока не предложено. Вместе с тем, трудно оспаривать выгоды по производительности и упрощению (а значит повышению надежности) администрирования СУБД, использующей ASM.

На сегодняшний день существуют как проприетарные, так свободно используемые системы управления базами данных, например, такие как:

IBM DB2 UDB

Microsoft SQL Server

MySQL

PostgreeDB

FireBird

Каждая система имеет свои особенности, преимущества и недостатки и свою цену.

СУБД Oracle является старейшей СУБД, первая версия появилась в 1979 году. С тех пор Oracle  развивался, становился быстрее, надежней и удобней для разработчика и пользователя. Фактически, конкурирующие СУБД повторяют тот путь, который прошел в своем развитии Oracle, и реализуют у себя технологии, реализованные в Oracle Database с годичным и более отставанием и с различным успехом. Как уже было отмечено, на сегодняшний день Oracle обладает как минимум 4-мя уникальными технологиями, обеспечивающими конкурентное преимущество этой СУБД. О том, что Oracle Database является признанным лидером в этой отрасли производства ПО, свидетельствует тот факт, что по итогам 2007 года Oracle  Database принадлежит 47% мирового рынка систем управления базами данных.


^ 8.Основные объектные структуры данных в ОРАКЛ
Таблица (TABLE) является базовой структурой реляционной модели. Как известно, вся информация в реляционной базе данных хранится в таблицах. Полное имя таблицы в базе данных состоит из имени схемы и собственно имени таблицы:

ИМЯ_СХЕМЫ.ИМЯ_ТАБЛИЦЫ

Например:

ALL_ORACLE.ALL_ORACLE_USERS

Таблицы состоят из множества поименованных столбцов или атрибутов. Множество допустимых значений атрибута называют доменом значений или просто доменом. Множество допустимых значений столбца также может быть уточнено с помощью статических ограничений целостности. Таблицы могут быть связаны между собой отношениями ссылочной целостности.

Таблица может быть пустой или состоять из одной или более строк значений атрибутов. Строки значений атрибутов таблицы называются также кортежами. Для однозначной идентификации строки в таблице служит идентификатор (ROWID) — указатель, имеющий специальный формат. В Oracle 8 появились вложенные таблицы (NESTED TABLES), которые позволяют объявить таблицу как тип значения столбца родительской таблицы. Для  повышения скорости доступа к данным таблица может быть индексно организована (INDEX-ORGANIZED TABLE). Физическое пространство для хранения данных таблицы выделяется частями, называемыми экстентами. Размеры начального и дополнительных экстентов определяются при создании таблицы.


Индексы – это необязательные структуры, связанные с таблицами и кластерами, позволяющие увеличить скорость исполнения SQL операторов. Индексы работают наподобие оглавления или предметного указателя в книгах, и позволяют быстрее находить информацию. Индексы можно использовать без перезаписи запросов, результаты останутся такими же, но на исполнение уйдет меньше времени.

Oracle предоставляет несколько типов индексов:

Индексы в виде B-дерева (B-tree) – самые распространенные и используются по умолчанию

Кластерные индексы в виде B-дерева – определяются специально для кластера

Индексы хэш-кластера – определяются специально для хэш-кластера

Глобальные и локальные индексы – относятся к секционированным таблицам и индексам

Индексы с инвертированным ключом – полезны в среде Oracle Real Application Cluster

Битовые индексы – компактные, подходят для столбцов с небольшим набором значений

Индексы на базе функций – содержат заранее вычисленные значения функции/выражения

Индексы домена – зависят от приложения или картриджа

Индексы логически и физически независимы от данных таблицы с которой они связаны. Поскольку это независимые структуры, то они требуют физического пространства. Для индексов доступны операции создания и удаления. Это никак не влияет на базовые таблицы, приложения базы данных или другие индексы. Oracle автоматически ведет индексы при вставке, обновлении и удалении строк связанной с ним таблице. Если индекс удалить, то все приложения и запросы продолжат работать, однако доступ к проиндексированным данным может замедлиться.


Последовательности (Sequences) – объекты базы данных Oracle, которые используются для генерации целочисленных значений. Наиболее часто используются для генерации значений первичного ключа.

Это бывает очень удобно, и снимает с разработчика необходимость реализовывать алгоритм для создания значений первичного ключа. Каждое новое значение в последовательности создается на основании правил, указанных при создании. Общий синтаксис создания:

CREATE SEQUENCE [schema].sequence_name
[INCREMENT BY number]
[START WITH number]
[MAXVALUE number | NOMAXVALUE]
[MINVALUE number | NOMINVALUE]
^ [CYCLE | NOCYCLE]
[CACHE number | NOCACHE]
[ORDER | NOORDER] ;


Синоним (Synonym) – это альтернативное имя (псевдоним) для объекта схемы. Если для какого либо объекта базы данных Oracle существует синоним, то к объекту из SQL запроса можно обращаться либо по его настоящему имени, либо по синониму. Так же они обеспечивают некоторый уровень безопасности, поскольку скрывают имя объекта и его владельца, а так же делают прозрачным местоположение удаленных объектов распределенных баз данных.

Синонимы позволяют переименовывать и перемещать базовые объекты. При том переопределяется только синоним, а приложение не требует никаких модификаций.

Различают два типа синонимов:

Частный (PRIVATE)- синонимы содержаться в схеме конкретного пользователя и доступны только самому пользователю, и тем, кому он предоставил соответствующие права доступа.

Общий (PUBLIC)- этими синонимами владеет специальная группа пользователей – PUBLIC, в результате чего эти синонимы доступны всем пользователям базы данных.



Представления (VIEW) - это специализированный способ представления данных, содержащихся в одной или более таблиц, или в одном или нескольких представлениях. Результат запроса представляется в виде обычной таблицы.
Создание представлений
Для создания представлений, необходимо выполненить следующие условия:

Чтобы создать представление в своей схеме,