Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Базы_данных_29.09.05.doc
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
3.29 Mб
Скачать

2.3. Тенденции развития субд

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

  • автоматизация проектирования (CAD);

  • автоматизация производства (CAM);

  • автоматизация разработки программного обеспечения (CASE);

  • геоинформационные системы (GIS);

  • офисные информационные и мультимедийные системы (OSI).

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

  1. внедрение идей объектно-ориентированного подхода в организацию информации. Создание объектно-реляционных и объектно-ориентированных СУБД;

  2. унификация подходов к организации слабоструктурированной информации. Создание XML-ориентированных СУБД, предназначенных для хранения документов.

2.3.1. Объектно-ориентированные СУБД

Начнем с основной парадигмы объектно-ориентированного подхода к программированию и к СУБД:

объектно-ориентированный подход = абстрактные типы данных + наследование + идентичность объектов;

объектно-ориентированная СУБД = объектно-ориентированный подход + возможности СУБД.

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

Коротко охарактеризуем основы ОО подхода. Основным компонентом БД является объект – уникально идентифицируемая сущность, которая содержит атрибуты, описывающие состояние объектов реального мира и связанные с ним действия. При описании атрибутов используется понятие типа данных. Тип может быть сложно структурированным (множество, список, массив). Каждому объекту присваивается уникальный идентификатор. Объект инкапсулирует данные и функции в замкнутом пакете. Функции – это методы, которые определяют поведение объекта. Они могут изменять состояние объекта за счет изменения значений его атрибутов. Метод состоит из имени и тела, которое обеспечивает поведение. Сообщение является свойством взаимодействия объектов. Это запрос, направляемый одним объектом другому, чтобы тот выполнил один из своих методов. Обращение к методу: <имя объекта>.<имя метода> (<параметры>). Класс –- это шаблон для определения набора подобных объектов. Интерфейс – это спецификация класса, методы которого не хранят никакого кода. Связи (зависимость, ассоциация/использование, агрегация/включение, наследование/обобщение, реализация) определяются между парами классов. При этом поддерживается иерархия классов и наследование. Наследование позволяет определить один класс на основе другого. Совокупность связей, ведущих от одного типа к другому, называется навигацией.

Связи организуются за счет хранения идентификаторов объектов (например, в классе на конце «много» определяется атрибут, в котором хранится идентификатор объекта-родителя; в классе-родителе хранится атрибут с множеством значений идентификаторов соответствующих объектов). В объявлении связи указывается другой ее конец:

relationship <тип набора> <связываемый класс> <имя связи>

inverse <связываемый класс>::<имя связи в связываемом классе>.

Пример:

/*описание класса

class Person {

/* определение атрибутов

struct Pname {string fname, string lname};

struct Addr {string street, string city, string state};

attribute Pname name;

attribute Addr address;

attribute string tel;

attribute string sex;

attribute date date_of_birth;

/* определение связей

relationship set <Child> children

inverse Child::parent};

/*определение класса

class staff:Person

(extent staffs)

{

};

/*выборка информации

select struct (lname: x.name.lname, sex:x.sex)

from x in staff

where x.address.city = 'London';

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

Несколько фирм – разработчиков образовали группу ODMG (Object Database Management Group) в целях определения стандартов ОО СУБД. При этом унифицирована объектная модель (Object Model – OM). Разработан стандарт языка определения объектов (Object Definition Language – ODL) и языка запроса объектов (Object Query Language – OQL). Ниже приведены обязательные характеристики ОО СУБД, декларированные ODMG:

  • поддержка составных объектов;

  • поддержка идентичности объектов;

  • поддержка инкапсуляции (доступ к объекту только через интерфейс);

  • поддержка типов или классов;

  • поддержка наследования классов;

  • поддержка динамического связывания (методы должны применяться к объектам разных типов);

  • поддержка языка OQL, обладающего вычислительной полнотой;

  • поддержка расширяемого набора типов;

  • поддержка перманентности данных (данные существуют после завершения работы приложения);

  • поддержка больших БД;

  • поддержка параллельной работы многих пользователей;

  • обеспечение восстановления после сбоев;

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

Разработан ряд нотаций объектных моделей, в том числе нотаций Йордана-Кода, Шлеера-Меллора, Дж.Рамбо (ОМТ). Последней самой универсальной нотацией, охватывающей все аспекты объектно-ориентированного проектирования систем, является нотация UML (Unified Modeling Language).

2.3.2. Объектно-реляционные субд

Мощные серверы БД, такие как Oracle, Informix, DB2, начиная с версий 8X, наряду с поддержкой реляционно-полной модели, включают объектные расширения. Однако работа с объектами не унифицирована на уровне языка SQL. В каждом конкретном случае приняты свои решения по манипулированию объектами. Так компания Informix в свое время одна из первых развила комплекс ОО технологий в СУБД, приобретя компанию Illustra Software. При этом появился продукт Informix Universal Server. Корпорация Oracle также ввела в функциональность своего сервера ОО технологию, начиная с версии продукта Oracle 8.

Перечислим основные объектные расширения реляционно-полных серверов БД:

  • большие объекты (блобы) для хранения документов, аудио-видио клипов, Web-страниц и т.д.;

  • абстрактные типы данных;

  • таблицы в таблицах (столбцы таблицы включают структуры или целые таблицы);

  • атрибуты - коллекции (множества, списки, массивы);

  • хранимые процедуры;

  • уникальные идентификаторы записей и объектов.

В качестве примера проиллюстрируем работу с объектами в СУБД Oracle. Так тип объекта (Address_Type) описывается на SQL и используется для описания других объектов:

CREATE TYPE Address_Type AS OBJECT (

Street VARCHAR (50),

City VARCHAR (25),

State VARCHAR (25),

Zipcode VARCHAR (10),

Country VARCHAR (50));

CREATE TABLE sales.customers (

ID INTEGER PRIMARY KEY,

Last_name VARCHAR (50),

First_name VARCHAR (50),

Address Address_Type );

При манипулировании объектами применяется точечная запись:

SELECT Id, Last_name, First_name, Address.street, Address.city

FROM sales.customers;

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

CREATE

OR REPLACE TYPE sales.item_type

AS OBJECT (item.id INTEGER

Quantity INTEGER);

CREATE

OR REPLACE sales.item_list

AS TABLE OF sales.item_type;

CREATE TABLE sales.orders (

Id INTEGER PRIMARY KEY,

Order_date DATE,

Ship_date DATE,

Line_items sales.item_list);

NESTED TABLE line_items

STORE AS items;

SELECT item_id, quantity

FROM THE (SELECT line_items

FROM sales.orders WHERE id=1)

ORDER BY item_id;

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

2.3.3. XML-ориентированные СУБД

Расширяемый язык разметки (eXtensible Markup Language – XML) – это язык описания документов. XML во многом похож на язык разметки гипертекста (HyperText Markup Language – HTML), который повсеместно используется для конструирования Web-страниц. В обоих случаях существует некий набор тегов, встраиваемых в текст. HTML состоит из набора предопределенных «тегов», заставляющих программы-браузеры выполнять над документом определенные действия. Обычно эти теги описывают аспекты представления, такие как стили и размеры шрифтов, размещение строк и т. д. Некоторые теги также идентифицируют ссылки на другие страницы, рисунки и графику. При этом любой браузер знает, как интерпретировать теги.

Теги HTML прежде всего предназначены для представления данных, а не их структуры. XML же позволяет описывать структуру и природу информации, представленной документом (XML-документом). Ниже, в качестве примера, приведен XML-документ, соответствующий заказу товаров на оптовом складе:

<?XML version=”1.0”>

<!-- **** Purchasing ****-->

<PURCHASE_ORDER>

<ISSUED_TO_CUSTOMER>

<customer_id>43582</ customer_id>

<name>ООО «Восторг»</name>

<surname></surname>

<director>Иванов М.И.<director>

</ISSUED_TO_CUSTOMER>

<po_number>896702</po_number>

<order_date>12.01.2001</order_date>

<LINE_ITEM>

<line_number>1</line_number>

<quantity>12</quantity>

<price>540</price>

<product_service_flag>product </product_service_flag>

<PRODUCT>

<product_code>A-34</product_code>

<description> Карамель</description>

<unit price>45.00</unit_price>

</PRODUCT>

</LINE_ITEM>

<LINE_ITEM>

<line_number>2</line_number>

<quantity>1</quantity>

<price>12.75</price>

<product_service_flag>service</product_service_flag>

<SERVICE>

<service_id>B-87</service_id>

<description>Доставка</description>

<rate_per_hour>12.00</rate_per_hour>

</SERVICE>

</LINE_ITEM>

</PURCHASE_ORDER>

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

Смысл тегов может определяться в отдельном файле, называемом описанием типа документа (Document Type Declaration – DTD). DTD определяет набор базовых элементов, идентифицирует подчиненные элементы и определяет атрибуты для каждого из них. DTD для предыдущего примера выглядит следующим образом:

<!DOCTYPE PURCHASE_ORDER [

<!ELEMENT PURCHASE_ORDER (ISSUED_TO_CUSTOMER, po_number, order_date, LINE_ITEM*)>

<!ELEMENT ISSUED_TO_CUSTOMER (customer _id, name, customer_type, surname?, director?)>

<!ELEMENT customer_id (#PCDATA)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT customer_type (#PCDATA)>

<!ELEMENT surname (#PCDATA)>

<!ELEMENT director (#PCDATA)>

<!ELEMENT po_number (#PCDATA)>

<!ELEMENT order_date (#PCDATA)>

<!ELEMENT LINE_ITEM (line_number, quantity, price,

product_service_flag, PRODUCT?, SERVICE?)>

<!ELEMENT line_number (#PCDATA)>

<!ELEMENT quantity (#PCDATA)>

<!ELEMENT price (#PCDATA)>

<!ELEMENT product_service_flag (#PCDATA)>

<!ELEMENT PRODUCT (product_code, description,

unit_price)>

<!ELEMENT product_code (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT unit_price (#PCDATA)>

<!ELEMENT SERVICE (service_id, description, rate_per_hour)>

<!ELEMENT service_id (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT rate_per_hour (#PCDATA)>

]

При этом в определении элемента сначала указывается название элемента, а затем модель его содержимого – набор предикатов, которые определяют, какие другие элементы или типы данных могут встречаться внутри него. Содержимое элемента может также определяться при помощи специального маркера PCDATA (что означает parseable character data – любая информация, с которой может работать программа-анализатор). Символ “?” означает, что предикат необязателен, т. е. может отсутствовать. Символ “*” указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же может совсем не использоваться.

XML является мощным средством унифицированного представления любой информации. Так, например, OMG сформировала набор тегов описания метаданных (XML Metadata Interchange – XMI) для ведения репозитариев хранилищ данных и организации информационных взаимодействий между CASE-средствами. Комитетом Learning Technology Standards Committee (LTSC) IEEE разработана спецификация метаописания образовательных ресурсов Learning Object Metadata (LOM).

Для доступа к информации XML-документов разработано большое количество компонентных расширений языков высокого уровня, основанных на соответствующих моделях обработки документов (например, DOM, SAX). При этом с помощью специализированного обработчика (парсера) содержимое документа считывается в объектную модель (объектное дерево) и выполняется навигация по этой структуре для выборки информации.

XML широко используется для обмена информацией между автоматизированными системами. Кроме того, ряд производителей серверов баз данных (в частности,Oracle 9i, DB2) поддерживают возможность организации баз данных, ориентированных на хранение XML-документов.

Вопросы к разделу 2

  1. Дать определение основным функциям СУБД.

  2. Охарактеризовать методы доступа, поддерживаемые СУБД.

  3. Что относится к средствам управления базой данных?

  4. Охарактеризовать потребительские качества серверов БД.

  5. Привести краткую характеристику основных конструкций унифицированного языка для работы с базами данных SQL.

  6. Как организован прикладной интерфейс СУБД?

  7. Охарактеризовать основные функции реляционно-полного сервера баз данных.

  8. В чем тенденции развития серверов баз данных? Охарактеризовать применение объектно-ориентированного подхода в СУБД.

  9. Как обеспечивается доступ к информации в сети Интернет?

  10. Охарактеризовать применение языка XML для обработки информации.

Р аздел

В этом разделе…