СУБД для бизнес-систем.Часть 2

добавлено: 28 мар 16
понравилось:0
просмотров: 1402
комментов: 2

теги:

Автор: U-gene

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

Объектно-ориентированное управление реляционными данными.

В традиционных реляционных БД данные о бизнес-объекте, как правило, распределены по нескольким таблицам. Например, данные об отгрузке будут храниться в двух таблицах.

Картинка с другого сайта.

Подразумевается, что пользователь, управляющий таким данными, должен сам "знать" (возможно, с использованием внешней системы), как эти данные должны быть собраны в единый объект. Без этого "знания", существующего вне БД, невозможно построить выразительную МБ.

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

Картинка с другого сайта.

Фактически, речь идет об изощренном способе управления традиционными реляционными данными. Реализующий его механизм использует информацию об ассоциациях записей из разных таблиц, которая, вместе с другими метаданными, хранится в каталоге БД. Схема такой БД фактически является описанием МБ.

Сложная гетерогенная схема данных.

RxO СУБД сохраняет все возможности и для работы с традиционными таблицами, если такие таблицы созданы пользователем явно. Таким образом, в базе данных в RxO СУБД могут сосуществовать одновременно и таблицы (Т), и сложные (0NF) уникальные объекты разных классов(С); таблицы и классы могут быть связанны между собой ключами и ссылками.

Картинка с другого сайта.

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

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

Классы.

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

Для описания классов и управления объектами пользователь в прототипе "RxO system" реализован набор команд,
расширяющих традиционный SQL.

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

Классы создаются командой CREATE CLASS

CREATE CLASS Goods{			
GoodsID STRING; //Scalar attribute
Turnover SET OF //Table attribute
{
Buyer STRING;
Qty INTEGER;
}KEY unB (Bayer); //Table field key
}KEY unID (ID)//Class key

CREATE CLASS Sales{
DocN STRING; //Scalar attr
Buyer STRING;// Scalar attr
...
Items SET OF //Table field
{
Art Goods; //Reference to some Goods object
Qty INTEGER;
}KEY uArt (Art); //Table field key
PostIt(inDate DATETIME); //Method
}KEY uniqDocN (DocN)//Class key

Интерфейс классов может быть изменен командами
ALTER CLASS ... ADD ...  
,
ALTER CLASS ... REMOVE ...  
и
ALTER CLASS ... RENAME ...
.

Реализация должна быть определена для каждого элемента интерфейса, и для атрибутов, и для методов класса. Реализация задается командой
ALTER CLASS ... IMPLEMENT ...
.

Атрибуты могут быть реализованы как

- хранимые. Значения таких атрибутов хранятся, подобно тому, как они хранятся в таблицах БД.
ALTER CLASS Sales 
IMPLEMENT DocN, Items AS STORED;

- вычисляемые. Описание такой реализации подобно описанию вида или описанию определяемой пользователем функции.

ALTER CLASS Goods
IMPLEMENT Turnover AS
BEGIN
RETURN SELECT
Buyer, SUM(Items.Qty)
FROM SHIPMENTS
WHERE Items.Art = this
GROUP BY Buyer
END;

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

Реализация методов подобна определяемым пользователем процедурам и функциям.

ALTER CLASS Sales 
IMPLEMENT PostIt(inDate DATETIME) AS
BEGIN ... END;

Команда
ALTER CLASS ... IMPLEMENT ...

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

CREATE CLASS SpecialSales EXTENDS Sales {...}

При наследовании классов реализация атрибутов и методов может меняться.

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

Последняя особенность позволяет по-новому взглянуть на проблему избыточных данных, существенную для СУБД, где описывая данные, мы подразумеваем, что они являются хранимыми (так, команда CREATE TABLE описывает структуру хранимой таблицы). На примере наших классов, если бы речь шла исключительно о хранимых данных, то табличный атрибут Turnover класса Goods был бы избыточным на фоне класса Sales. В RxO СУБД такая избыточность отсутствует из-за того, что атрибут Turnover класса Goods реализуется как вычисляемый. Это позволяет пользователю фокусироваться, в первую очередь, на создании выразительной МБ, избегая тяжелых компромиссов между требуемой выразительностью и оптимальной схемой хранения данных.

Операции с объектами.

Объекты в RxО СУБД персистентны и существуют с момента создания до момента явного уничтожения. Для создания объектов используется привычная операция NEW. Существует вариант использования этой команды в непроцедурной операции
NEW Sales WITH BEGIN 
DocN := "Doc01";
END;

В этом примере ссылка на созданный объект не сохраняется. Эта возможность существенно отличает RxO систему от традиционных ОО языков программирования, где ссылка (или указатель) является единственным способом доступа к объекту. В RxO СУБД реализован принцип "класс является именованным множеством персистентных объектов". Любой созданный объект, даже если на него отсутствует ссылка, доступен в классе. Благодаря этому, нет необходимости явно создавать какие-либо дополнительные структуры для доступа к персистентным объектам (подобные экстентам в модели ODBMS[]).

Эта возможность является основой непроцедурного доступа к объектам в командах управления базой данных. Для манипуляций над объектами используется команда FOR, в которой для действия над атрибутами объектов используются известные операции, соответствующие типам этих атрибутов. Например, так выглядит команда, изменяющей значение хранимого табличного атрибута объекта, созданного предыдущей командой (здесь атрибут Art инициализируется ссылкой на ранее созданный объект класса Goods).

FOR SHIPMENTS[.DocN = "Doc01"] 
INSERT INTO Items (Art, Qty)
VALUES(FIRST OF GOODS[ID = "Tie"], 10);

Команда FOR может использоваться, что бы исполнить последовательность действий (batch) или метод класса

FOR SHIPMENTS[...] BEGIN ... END; 
FOR SHIPMENTS[...] EXEC DoShip(...);

При этом, команда FOR позволяет оперировать группами объектов, в том числе целым классом.

FOR SHIPMENTS[.DocN LIKE ...] ...;
FOR SHIPMENTS EXEC ...;

Продолжение следует...

Комментарии


  • Изобретаете [a href="http://virtuoso.openlinksw.com/"] Openlink Virtuoso Server [/a]? И вот в Википедии: [a href=""] https://en.wikipedia.org/wiki/Virtuoso_Universal_Server [/a]. Вообще, идея давно уж бродит в умах, вот корейцы родили: [a] http://www.cubrid.org/ [/a], тоже объектная ориентированность, сервер приложений внутри СУБД, и доступ ко всему функционалу снаружи через ODBC и JDBC.
    Теперь вопрос: чем Ваша система лучше? Как протолкнётесь на рынок?
    Практичные разработчики возьмут то, что умеют (Firebird, PostgreSQL, MySQL, ${NameItYourOwn}), прикрутят к этому триггеры, хранимые процедуры и виды (view) и запустят в продакшын.

  • Sega.Bu

    В предыдущей записи я про отличия немного написал.

    В существующих СУБД ОО-возможности реализуются через подсистемы и слои (например, "CUBRID's 3-tier architecture" и т.д.). Мы даем решение на уровне логики описания данных. Говоря образно, в существующих системах есть CREATE TABLE и вокруг накручено много разных технологий. Мы ничего не пытаемся накрутить в плане технологий, но даем для описания данных альтернативу самому CREATE TABLE, а вместе с этим - новые возможности для создания выразительных и гибких схем данных непосредственно в СУБД (и безотносительно возможных технологий).



Необходимо войти на сайт, чтобы оставлять комментарии