• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Стандарт ODMG.

ODMG (Object Data Management Group) - консорціум постачальників ООБД і інших зацікавлених організацій, створений в 1991 р. Його завданням є розробка стандарту на зберігання об'єктів в базах даних. В даний час опублікована друга версія стандарту, яку так і називають ODMG 2.0.

Розглянемо стисло основні положення цього документа.

Стандарт на зберігання об'єктів ODMG 2.0 розроблений на основі трьох існуючих стандартів: управління базами даних (SQL), об'єкти (стандарти OMG - Object Management Group і стандарти на об'єктно-орієнтовані мови програмування (C++, Smalltalk, Java).

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

Об'єктна модель -уніфікована основа всього стандарту. Вона розширює об'єктну модель консорціуму OMG (див. параграф 6.3.1) за рахунок введення таких властивостей як зв'язку і транзакції для забезпечення функціональності, потрібної при взаємодії з базами даних.

Ключові концепції об’єктної моделі ODMG:

- надання об'єктам таких властивостей як атрибути і зв'язки;

- методи об'єктів (поведінка);

- множинна спадковість;

- ідентифікатори об'єктів (ключі);

- визначення таких сукупностей об'єктів як списки, набори, масиви і так далі;

- блокування об'єктів і ізоляція доступу;

- операції над базою даних.

Мова опису об'єктів (ODL - Object Defifnition Language)- засіб визначення схеми бази даних (по аналогії з DDL в реляційних СУБД). ODL є розширенням IDL (Interface Definition Language - мова опису інтерфейсів) моделі OMG і надає засоби для визначення об'єктних типів, їх атрибутів, зв'язків і методів. ODL створює шар абстрактних описів так, що схема бази даних стає незалежна як від мови програмування, так і від СУБД. ODL розглядає тільки опис об'єктних типів даних, не удаючись до деталей реалізації їх методів. Це дозволяє переносити схему БД між різними ODMG-сумісними СУБД і мовами програмування, а також транслювати її в інші DDL.

Мова об'єктних запитів (OQL - Object Query Language)- SQL - подібна декларативна мова, яка надає ефективні засоби для витягування об'єктів з бази даних, включаючи високо рівневі примітиви для наборів об'єктів і об'єктних структур. Синтаксис оператора SELECT, визначений Sql-92, є підмножиною OQL. Oql-запити можуть викликатися з ОО-мови, точно також з OQL-запитів можуть робитися звернення до процедур, написаних на OО-мові. OQL надає засоби забезпечення цілісності об'єктів (виклик об'єктних методів і використання власних операторів зміни дані).

Зв‘язування з ОО-мовами. Стандарт ув'язки з C++, Smalltalk і Java визначає Object Manipulation Language (OML) - мова маніпулювання об'єктами, який розширює базові ОО-мови засобами маніпулювання і зберігання об'єктів. Також включаються OQL, засоби навігації і підтримка транзакцій. Кожна OО-мова має свій власний OML, тому розробник залишається в одному мовному середовищі, йому немає необхідності розділяти засоби програмування і доступу к даним.

3.4.7. Об'єктні розширення реляційних СУБД. Мова Sql-3.

Спроби сумістити засоби маніпулювання даними реляційної моделі і способи опису зовнішнього світу об'єктно-орієнтованої моделі отримали розвиток в мові Sql-3

Розглянемо способи визначення даних.

Розробники Sql-3 вважають, що характеристики об'єкту визначається описом рядка таблиці. Тому, вводиться спеціальна можливість опису нового типу даних:

Create type Address as object(
id number ,
street char (30),
aptno integer,
city char (30),
state char (2),
zip integer
) ;

На основі нового типу можуть бути визначені таблиці, наприклад:

Create table Addresses of Address;

Нові типи допускається використовувати і для визначення стовпців (тобто ігнорується вимога атомарності атрибутів реляційної моделі):

Create table People (
id number,
name char (30),
paddress Address,
birthdate date );

Спадковість визначається за допомогою посилання.

Create OR REPLACE type Employee as object(
empno number,
id ref Address );

Тут атрибут id є посиланням на об'єкт, що зберігається в таблиці Address. Тобто в поняттях реляційної моделі в цьому стовпці повинен бути записаний зовнішній ключ, що вказує на один з рядків таблиці Address. Насправді, в Sql-3 передбачається, що кожен об'єкт має унікальний ідентифікатор - OID, саме він використовується при створенні посилань на об'єкти.

create or replace type address_type

as object

(city varchar2(30),

street varchar2(30),

state varchar2(2),

zip number)

/

Type created.

create or replace type person_type

as object

(name varchar2 (30) ,

dob date,

home_address address_type,

work_address address_type)

/

Type created.

create table people of person_type

/

Table created.

Name Type

NAME VARCHAR2 (30)

DOB DATE

HOME_ADDRESS ADDRESS TYPE

WORK ADDRESS ADDRESS TYPE

Використовуємо створений тип

create table people

(name varchar2(10),

home_address address_type,

work_address address_type

)

/

Таblе created.

Declare

l_home_address address_type;

l_work_address address_type;

Begin

l_home_address := Address_Type('123 Main S t r e e t ' , null,

'Reston', 'VA', 45678);

l_work_address :=Address_Type('l OracleWay', null,

'Redwood', 'CA', 23456);

insert into people

(name, home_address, work_address)

Values

('TomKyte', l_home_address, l_work_address);

end;

/

CREATE OR REPLACE TYPE Point AS OBJECT (

- Точка определяется своими координатами в декартовой системе координат.

х NUMBER,

у NUMBER,

- Возвращает строку символов '(х, у)'.

MEMBER FUNCTION ToString RETURN VARCHAR2,

PRAGMA RESTRICT_REFERENCES(ToString, RNDS, WNDS, RNPS, WNPS),

- Возвращает расстояние между р и текущей Point (SELF).

- Если р не определена, то по умолчанию используется (О, О).

MEMBER FUNCTION Distance(p IN Point DEFAULT Point(0, 0)) RETURN NUMBER,

PRAGMA RESTRICT_REFERENCES( Distance, RNDS, WNDS, RNPS, WNPS),

- Возвращает сумму р и текущей Point.

MEMBER FUNCTION Plus(p IN Point) RETURN Point;

PRAGMA RESTRICT_REFERENCES(Plus, RNDS, WNDS, RNPS, WNPS),

- Возвращает текущую Point * n

MEMBER FUNCTION Times(n IN NUMBER) RETURN Point,

PRAGMA RESTRICT_REFERENCES(Times, RNDS, WNDS, RNPS, WNPS)

)

3.4.8. Об'єктно-реляційні СУБД

Інший спосіб об'єднання можливостей реляційного і об'єктно-орієнтованого підходу до управління даними запропонував відомий американський вчений Майкл Стоунбрейкер Згідно його переконанням реляційну СУБД потрібно просто доповнити засобами доступу до складних даних. При цьому ядро СУБД не вимагає переробки, як у випадку з Sql3, і зберігає всі властиві реляційним системам. Об'єктні розширення реалізуються у вигляді надбудов, які динамічно підключаються до ядра. На основі цієї ідеї під керівництвом М.Стоунбрейкера в університеті Берклі (Каліфорнія, США) була розроблена СУБД Postgres, яка має наступні ключові можливості:

1. Типи, оператори і методи доступу, визначувані користувачем. Наприклад для збереження інформації про земельну ділянку можна визначити новий тип даних "ділянка", необхідні операції над ним (наприклад, обчислення площі), а також метод доступу, оскільки за допомогою B-дерева не можна виконати двовимірний пошук в завданні про багатокутники, що перекриваються. Тут доцільно використовувати дерево вищої розмірності (R-дерево) або інші методи.

2. Підтримка складних об'єктів, що є наборами інших об'єктів.

3. Перевантаження операторів маніпулювання даними.

Наприклад, можливе створення такої конструкції

SELECT власник FROM ділянки WHERE розташування_ділянки IN заданна_область

4. Створення функцій, визначуваних користувачем.

5. Динамічне (тобто без переривання роботи СУБД) додавання нових типів даних, операторів, функцій і методів доступу. Опис всіх цих можливостей створюється на мові C і компілюється в об'єктний файл, який може динамічно завантажуватися сервером СУБД.

6. Спадковість даних і функцій. Наприклад, від типу "ділянка" ми можемо породити нащадків "звичайна ділянка" (сума_налогу, надходження_платежів) і "ділянка звільнена від податку" (сума_налогу, причина_звільнення). При цьому функція заборгованість(ділянка) повинна виконуватися для всіх типів ділянок.

7. Використання масивів як значень полів кортежів. Це необхідно, наприклад, для зберігання ставки податку, що змінюється залежно від пори року.

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

Проект Postgres розвивається зараз (2012 рік) міжнародною групою незалежних розробників. До можливостей СУБД додані підтримка SQL (у перспективі планується забезпечення сумісності із стандартом ANSI Sql-92), тому дещо було змінено назву СУБД - тепер це POSTGRESQL, оптимізатор запитів на основі генетичних алгоритмів і багато що інше. При цьому POSTGRESQL залишається вільно поширюваною системою, причому безкоштовно можна отримати як початковий код, так і бінарні файли, зібрані для тієї або іншої платформи (підтримуються практично всі різновиди ОС Unix).

Читайте також:

1. Американський стандартний код для обміну інформацією ASCII.
2. Британські стандарти новин.
3. Будова СВА. Стандарти практичного застосування.
4. Ведучий теленовин: стандарти професіоналізму
5. Вибір та застосування стандартів
6. Вивчення географії на рівні стандарту
7. Видавнича та пропагандистська діяльність Держстандарту
8. Визначення номера абонента, що дзвонить, у стандарті DTMF
9. ВИМОГИ ДЕРЖСТАНДАРТУ ДО ОФОРМЛЕННЯ ДОКУМЕНТІВ.
10. Вимоги міжнародних стандартів аудиту до аудиторської документації
11. Відмінності від стандартної версії
12. Вплив факторів на відхилення стандартних витрат

Переглядів: 965