Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

Розширені ОРБД

До розширеним ОРБД відноситься СУБД Informix Universal Server [41,42]. За допомогою цього різновиду ОРБД вирішують дві групи завдань: 1) зберігання в БД даних великого об'єму; 2) трансформація реляційної моделі (власне БД) в об'єктно-реляційну модель даних.

Обговоримо стан вирішення цих завдань.

Завдання 1. Спочатку графічні бази даних створювалися так: окремо формувалися графічні файли, а в стовпцях СУБД були лише посилання на ці файли. Це вимагало від програміста знання не тільки БД, а й системи файлів. У зв'язку з цим до складу СУБД були спочатку введені "прості великі об'єкти" (рис. 8.6) TEXT і BYTE з об'ємом до 1 Гбайт.

Незабаром з'ясувалося, що і така розмірність поля часом недостатній, і були створені інтелектуальні великі об'єкти Binary Large Object (BLOB) і CLOB розміром до 4 Тбайт. Робота з такими об'єктами можлива тільки "по частинах", для чого довелося створити спеціальні додаткові технології.

Великі об'єкти

Рис. 8.6. Великі об'єкти

Завдання 2. Ідею розширення (системи даних) зручно ілюструвати на прикладі [41] програми (середа Delphi, мову Object Pascal):

unit polimor_;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

StdCtrls;

type

TForml = class (TForm)

Editl: TEdit;

Edit2: TEdit;

GroupBoxI: TGroupBox;

RadioButtonl: TRadioButton;

RadioButton2: TRadioButton;

Label 1: TLabel;

Label2: TLabel;

Button1: TButton;

Button2: TButton;

procedure Button 1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

type

TPerson = class

fname: string; {ім'я}

constructor Create (name: string);

function info: string; virtual;

end;

TStud = class (TPerson)

fgrrinteger; {номер групи} constructor Create (name: string; gr: integer); function infoistring; override;

end;

TProf = class (TPerson)

fdep: string; {назва кафедри}

constructor Create (name: string; dep: string);

function info: string; override;

end;

const

SZL = 10; // Розмір списку

var

Forml: TFormt;

List: array [1 ..SZL] of TPerson; // Список

n: integer; // К-ть людей в списку

implementation

{$ R * .DFM}

constructor TPerson.Create (name: string);

begin

fname: = name;

end;

constructor TStud. Create (name: string; gr: integer);

begin

inherited create (name);

fgr: = gr;

end;

constructor TProf.create (name: string; dep: string);

begin

inherited create (name);

fdep: = dep;

end;

function TPerson.lnfo: string;

begin

result: = fname;

end;

function TStud.lnfo: string;

begin

result: = fname + 'гр.' + lntT oStr (fgr);

end;

function TProf.lnfo: string;

begin

result: = fname + 'каф.' + fdep;

end;

procedure TForml .Button1Click (Sender: TObject);

begin

if n <= SZL then begin

if Radiobutton 1 .Checked

then // створимо об'єкт TStud

List [n]: = TStud.Create (Edit1.Text, StrTolnt (Edit2.Text))

else

List [n]: = TProf.Create (Edit1.Text, Edit2.Text);

n: = n + 1;

end

else ShowMessage ('Список заповнений!');

end;

procedure TForml .Button2Click (Sender: TObject);

var

i: integer;

st: string;

begin

for i: = 1 toSZL do

if list [i] <> NIL then st: = st + list [i] .info + # 13;

ShowMessage ('Список' + # 13 + st);

end;

end.

З неї видно, що класи "Студент" (TStud) і "Професор" (TProi) є похідними від класу "Особистість" (TPerson). В якості

методів доступу до них виступають функції TStud.Info.string, TProf.Info.string і TPerson.lnfo.string відповідно.

Мова програмування Object Pascal рідко використовується для формування об'єктно-орієнтованої моделі бази даних. Найчастіше для цих цілей застосовують мови С ++ і SQL.

Покажемо на прикладах використання мови SQL3 в СУБД Informix Universal Server.

У SQL3 використовуються ті ж типи даних, що і в SQL2. Однак SQL3 оперує не таблицями, як SQL2, а об'єктами. В якості таких об'єктів виступають нові (абстрактні) типи даних і система таблиць, що утворюють ієрархію.

А. Абстрактні типи даних (рис. 8.7). Абстрактні типи даних, що отримали останнім часом назву "типи даних, визначені користувачем" [2], - типи, що задають характеристики [3], але не реалізації, успадковані підтипом. Вони безпосередньо не породжують примірників.

В ієрархії типів беруть участь (рис. 8.7) ROW (неіменовані рядка), ROW TYPE (іменовані рядка), SET (невпорядкований набір одного типу без повторення даних), MULTISET (те ж, що і SET, з можливістю повторення даних), LIST ( упорядкований набір неунікальний даних одного типу, фактично - одновимірний масив). Різнорідні структури додають щоразу по одному рядку до попереднього рядка, тоді як однорідні структури можуть додавати по кілька рядків до кожної попередньому рядку.

Нові абстрактні типи даних

Рис. 8.7. Нові абстрактні типи даних

Використання нових типів розглянемо на системі таблиць, показаних на рис. 8.8. Ієрархія вимагає множинного спадкоємства. Оскільки воно не реалізовано в рамках СУБД Informix Universal Server, обмежимося розглядом частині ієрархії, обведеної на рис. 8.8 пунктиром.

Ієрархія абстрактних типів даних і таблиць

Рис. 8.8. Ієрархія абстрактних типів даних і таблиць

Мова повинна піти про побудову типів даних, їх заповненні та оновлення. Спочатку покажемо використання типу даних ROW для елементів ієрархії "Деканат", "Група", "Студент", "Кафедра". Для ілюстрації в кожному структурному елементі використовуємо тільки по два поля, а назви таблиць і полів виконаємо російською мовою.

CREATE ROW TABLE Деканат (

Шіфр_деканата integer,

Назва varchar (15),

Група ROW (

Шіфр_группи varchar (8),

Названіе_группи varchar (5),

Студент ROW (Шіфр_студента varchar (8),

Прізвище varchar (15)),

Кафедра ROW (

Шіфр_кафедри integer,

Названіе_кафедри varchar {50))

);

Вибірка даних здійснюється наступним чином.

SELECT шіфр_деканата, группа.названіе_группи, группа.студент.фамілія

FROM Деканат

WHERE группа.названіе_группи = 'И5';

Заповнення (вставка) в таку структуру проводиться так:

INSERT INTO Деканат

VALUES (1 / ПТІО ',

ROW ('І-99', 'І4',

ROW ('І-99/15', 'Петров')),

ROW (1, 'ІіУС'));

У типі даних ROW структура рядки (записи) щоразу повинна визначатися окремо. Це не дозволяє використовувати структуру ROW багаторазово.

Таку можливість надає іменована запис ROW TYPE. У цьому випадку попередня структура "Деканат" задається інакше.

Спочатку формуються іменовані запису.

CREATE ROW TYPE Студент_TYРЕ (

Шіфр_студента varchar (8),

Прізвище varchar (15)

);

CREATE ROW TYPE Гpyппa_TYPE (

Шіфр_группи varchar (8),

Названіе_группи varchar (5),

Студент Студент_ТУРЕ

);

CREATE ROW TYPE Кафедра_TYPE (

Шіфр_кафедри integer,

Названіе_кафедри varchar (50)

);

З іменованих записів складається структура "Деканат"

CREATE ROW TABLE Деканат (

Шіфр_деканата integer,

Назва varchar (15),

Г руппа Гpyппa_TYPE,

Кафедра Кафедра TYPE

);

При цьому сформується таблиця з нелінійної структурою (табл. 8.1).

Таблиця 8.1

Сформована таблиця "Навчальний процес"

Шифр деканату

Назва деканату

Група

Студенти

Кафедра

Шифр групи

Назва групи

Шифр студента

Прізвище

Шифр кафедри

Назва кафедри

1

ПТіО

І-99

І4

І-99/12

Петров

1

ІіУС

1

ПТіО

І-99

І4

І-99/11

Смирнов

1

ІіУС

...

...

...

...

...

...

...

...

Можна таблицю побудувати і іншим способом.

CREATE ROW TYPE Деканат_ТУРЕ (

Шіфр_деканата integer,

Назва varchar (15),

Група Гpynna_TYPE,

Кафедра Кафедра_ТУРЕ

);

і

CREATE TABLE Деканат OF TYPE Деканат_ТУРЕ;

Остання таблиця отримала назву типизированной. Зауважимо, що при вставці в тип ROW проблем не виникає:

INSERT INTO Деканат

VALUES (',' ПТІО ',

ROW ('І-99', 'І4',

ROW ('І-99/15',

'Петров') :: Студент_ТУРЕ) :: Группа_Туре,

ROW (1, 'ІіУС') :: Кафедра_ТУРЕ);

де знак :: позначає переклад записи в елемент ROW.

Оператори заповнення ROW TYPE складніше, ніж ROW, і вимагають написання збережених процедур або функцій. Наприклад, список груп в деканаті формується таким чином:

CREATE FUNCTION Спісок_групп (Деканат.ГpyппaTYPE)

RETURNS (varchar (8), varchar (5)) AS

RETURN (группа.Шіфр_группи, Группа.Названіе_группи)

END FUNCTION;

Ієрархія абстрактних типів даних (спадкування)

Рис. 8.9. Ієрархія абстрактних типів даних (спадкування)

Таблицю "Викладач" на рис. 8.8 тимчасово замінимо на таблицю "Працюючий", маючи на увазі, що викладач одночасно і викладач, і (науковий) співробітник (рис. 8.9).

CREATE ROW TYPE адрес_ТУРЕ (

Місто varchar (15),

Вулиця varchar (15),

Будинок integer,

Корпус integer,

Квартира integer

);

CREATE ROW TYPE Работающій_ТУРЕ (

Шіфр_работающего integer,

Прізвище varchar (15),

Адреса адрес_ТУРЕ

);

У складі "Працюючий" є підлеглі йому елементи "Викладач" і "Співробітник". Тоді ієрархія підпорядкування (успадкування) типів даних формується так:

CREATE ROW TYPE Преподаватель_ТУРЕ (

Дисципліна varchar (20),

Від_занятій varchar (10),

UNDER Працюючий TYPE;

CREATE ROW TYPE Сотруднік_ΤΥΡΕ (

Шіфр_работи varchar (5),

Назва роботи varchar (40),

UNDER Работающій_TYРЕ;

Тоді типізовані таблиці мають вигляд:

CREATE TABLE Викладач OF TYPE Преподаватель_ТУРЕ;

CREATE TABLE Співробітник OF TYPE Сотруднік_ТУРЕ;

Два останніх визначення можуть включати і зовнішні ключі.

Фактично сформована система таблиць. Вона відрізняється тим, що заповнення таблиць йде автономно. Якщо заповнюються поля в таблиці "Співробітник", то однойменні поля в таблиці "Працюючий" не заповнюються.

Б. Ієрархія таблиць. Зазначене заповнення деколи незручно і тому використовують спадкування не абстрактних типів даних, а таблиць, які пов'язують так:

CREATE TABLE Викладач

OF TYPE Преподаватель_ТУРЕ

UNDER Працюючий;

CREATE TABLE Співробітник

OF TYPE Сотруднік_ТУРЕ

UNDER Працюючий;

У цьому випадку таблиці стають вкладеними (рис. 8.10).

Якщо створити запит

SELECT * FROM Працюючий;

то будуть видані поля як об'єкта "Працюючий", так і об'єктів "Викладач" і "Співробітник".

Для отримання даних лише з певної таблиці (наприклад, "Співробітник") необхідно створити запит

SELECT * FROM ONLY (Співробітник);

Аналогічно і з процедурами поновлення

Приклад вкладеної таблиці

Рис. 8.10. Приклад вкладеної таблиці

DELETE FROM ONLY (Співробітник)

WHERE Шіфр_работи = 254;

Дотепер використовувалися (див. Рис. 8.6) різнорідні структури. Однак таблиці можуть бути поповнені і однорідними структурами (колекціями).

Додамо до таблиць "Співробітник" і "Викладач" колекції:

а) участь співробітника в наукових темах:

ALTER TABLE Співробітник

ADD Проект SET (integer);

б) навчальні посібники викладача:

ALTER TABLE Викладач

ADD Посібники MULTISET (ROW (

Назва varchar (30),

Год_ізданія integer)

);

Зауважимо, що MULTISET складається з наборів ROW.

Тоді таблиця "Викладач" отримує новий вид (табл. 8.2).

Таблиця 8.2

Нова таблиця "Викладач"

Шифр працюючого

Прізвище

Шифр предмета

Вид заняття

Адреса

Посібники

Місто

Вулиця

будинок

Корпус

Квартира

Назва

Рік видання

28

Петров

1

Лекції

СПб

Кіма

21

2

321

А

Б

У

+1999

  • 1 998
  • 1995

Відзначимо також, що колекція - поняття гнучке. Вона може бути полем записи і в той же час запису можуть грати роль елементів колекції.

Запити до колекцій можуть бути складені лише в найпростіших випадках. Запит на вибірку для таблиці "Викладач" має вигляд

SELECT шіфр_работающего, прізвище,

Пособія.Названіе

FROM Викладач WHERE 1 999 IN (Посібники);

Вставка може здійснюватися таким оператором

INSERT INTO Викладач

VALUES (',' Іванов ', 1,' викладач ',

ROW ('CПб', 'Московський', 137, 2, 118),

ROW ('Інформатика', 'лекція'),

"MULTISET {ROW ('A1', 1996),

ROW ('AZ, 1997),

ROW ('A4', 1997)} ");

Слід зазначити, що в СУБД Informix Universal Server введено новий тип змінної COLLECTION, в якій в процесі роботи програми (збереженої процедури) можуть зберігатися значення даних.

Для більш складних запитів потрібно використовувати збережені процедури, можливо, з циклами.

За допомогою збережених процедур формуються і необхідні додаткові методи, оскільки в СУБД Informix Universal Server немає механізму перетворення збережених процедур в методи. Таким чином, мова SQL3 володіє значно більшими можливостями в порівнянні з мовою SQL2.

У той же час розробників БД, мабуть, насторожує більш складна структура об'єктів і, головне, методів. Крім того, SQL3 характеризується неповнотою операторів: частина операторів розробнику доводиться створювати самому в рамках збережених процедур, для чого необхідно добре знати мову SQL2.

Названі обставини і інерційність звичного, широко розповсюдженого реляційного мислення пояснюють, по всій видимості, той факт, що розширені ОРБД не знайшли поки масштабного застосування.

Разом з тим широке поширення набула гібридна різновид ОРБД, що є серйозним удосконаленням реляційних БД.

Розширені ОРБД - серйозний крок у напрямку об'єктно орієнтованих баз даних. Сфера застосування таких ОРБД буде, на думку авторів, рости. Вони формують кошти як для революційного переходу до ООБД, так і для поступового, еволюційного руху в майбутнє баз даних.

Щоб зрозуміти перспективи розвитку ОРБД, слід оточити їх достоїнства і недоліки

До переваг слід віднести [2]:

  • • усунення ряду недоліків реляційних БД (див. § 8.1);
  • • повторне використання компонентів;
  • • використання накопичених знань з реляційних БД.

До недоліків ОРБД можливо віднести:

  • • ускладнення структури БД і часткову втрату простий видимістю результатів, як у реляційних БД;
  • • складність побудови абстрактних типів даних і методів, що зв'язують типи в ієрархію;
  • • менш широкий набір типів зв'язків, що визначаються мовою програмування SQL, ніж в об'єктно-орієнтованих БД;
  • • менш продуманий, налагоджений і стандартизований набір типів даних, ніж в ООБД.

ОРБД, мабуть, будуть існувати ще досить довго, чому є щонайменше два пояснення.

  • 1. Швидке накопичення за допомогою ОРБД досвіду, який можна використовувати при створенні ООСУБД.
  • 2. Необхідність мати кошти для поступового еволюційного "перекладу" численних реляційних БД в розряд ООБД, за якими, мабуть, майбутнє.
 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук