Автор: Детлеф Овербик (Detlef Overbeek)
Мне кажется, статью необходимо начать с описания того, что же такое база данных. Поэтому сначала будут описаны основные модели. Это позволит углубиться в эту тему, а в самом конце мы сделаем настоящее открытие: объектно-ориентированные базы данных не мертвы, как я раньше считал
(мнение было основано на негативных откликах,услышанных мной во время написания этой статьи).
Напротив, они процветают и мне удалось найти несколько крупных компаний, которые их используют. И что еще более захватывающе — я нашел объектную базу данных совместимую с Delphi и (или) языком Pascal, и на сайте Blaise Pascal Magazine вы сможете найти немного кода по этой теме на языке Pascal на DVD образе (.iso), также, при желании, вы можете заказать этот DVD. Итак, давайте попытаемся разобраться в многообразии моделей баз данных.Иерархическая модель
Иерархическая модель данных — это модель, в которой данные описываются в виде деревьев. Эти структуры? позволяют дублировать информацию используя связи вида «предок-потомок», где каждый предок может иметь множество потомков, но каждый потомок только одного предка. Все атрибуты каждой записи описываются типом сущности. В базе данных тип сущности подобен таблице, где каждая запись представляется в виде строки, а атрибут — в виде столбца. Типы сущностей связаны друг с другом с помощью отображения 1:N, также известном как связь «один-ко-многим». Наиболее признанными и востребованными иерархическими базами данных являются IMS, разработанная IBM и реестр ОС Windows, разработанный Microsoft.
(из Википедии).Данные в иерархической модели организованы в виде деревьев. Сегменты данных включаются в иерархию в виде родителей и потомков. Особенностью этих структур является то, что записи могут содержать дублирующую информацию (в основном это относится к дочерним узлам).
Данные сохраняются в записях, содержащих наборы значений прикрепленных к ним полей. Эта иерархия содержит все экземпляры определенной записи, определяя, тем самым, тип этой записи. Типы записей эквивалентны таблицам реляционной модели, а конкретные записи - строкам.
Для реализации связей между типами записей в иерархической модели используются связи "Родитель-Потомок".
Связь 1: N между типами записей реализуется в виде дерева (подобно теории множеств, используемой в реляционной модели). Этот подход позаимствован из математики.
Сетевая модель
Сетевая модель данных — это модель, разработанная для гибкого представления объектов и их взаимосвязей. Её отличительной особенностью является то, что схема данных рассматривается в виде графа, где объекты представляются узлами, а связи дугами. Внешний вид графа не ограничивается видом иерархии или решетки. Основоположником сетевой модели является
Чарльз Бочман(Charles Bachman)
(из Википедии).Популярность сетевой модели совпала с популярностью иерархической модели данных. Поскольку, некоторые данные более естественно моделируется с использованием нескольких родителей для каждого потомка, сетевая модель позволяет моделировать связи многие-ко-многим. Эта модель данных была официально представлена в 1971 году на Конференции по языкам систем обработки данных (CODASYL). Основной единицей моделирования данных в сетевой модели является множество. Оно состоит из имени, типа записи предка и типа записи элемента. Тип записи элемента может состоять из нескольких множеств, за счет этого и реализуются связи с несколькими предками.
Тип записи предка может также быть элементом или владельцем в другом множестве. Модель данных представляет из себя сеть, в которой могут существовать связи и пересечения типов записей
(также называемых записями TDMS),
а также несвязанные ни с кем множества.Таким образом, связи сетевой модели образуются парами множеств, в каждой из которых несколько (или
один)
типов записей могут быть владельцами(находятся на «хвосте» стрелки связи)
и одного или нескольких типов записей элементов(находятся на «наконечнике» стрелки связи).
Обычно множество определяет связь 1:M, связь 1:1 также возможна.Сетевая модель CODASYL основана на математической теории множеств.
(РСУБД — система управления реляционными базами данных). База данных основанная на реляционной модели впервые была создана Е. Ф. Коддом (E.F. Codd). Реляционные базы данных позволяют описывать структуры данных, выполнять операции хранения и поиска данных, поддерживают ограничения целостности. Данные и связи между ними организованы в таблицы. Таблицы состоят из строк и каждая строка содержит некоторое количество полей.
Свойства реляционных таблиц:
Атрибуты атомарны
Каждая строка уникальна
В столбцах хранятся значения одного типа
Последовательность столбцов не имеет значения
Последовательность строк не имеет значения
Каждый столбец имеет уникальное имя
Рисунок 3: реляционная модель
Некоторые поля могут быть определены в качестве ключей, это означает, что они будут проиндексированы для ускорения поиска значений. Если поля в двух разных таблицах хранят значения из одного множества, то можно выполнить операцию соединения и выбрать соответствующие записи из обоих таблиц по одинаковым значениям этих полей. Обычно такие поля называются одинаково в обеих таблицах. Например, таблица «продажи» (Orders) содержит поля «Покупатель-ID» (CustomerlD) и «код-продукта» (ProductID), а таблица «товары» содержит поля «код-продукта» и «цена»". Для того чтобы посчитать сколько заплатил каждый покупатель за все свои покупки нужно соединить обе таблицы по полю «код-продукта». Аналогично можно соединить несколько таблиц по нескольким полям. Поскольку такие отношения существуют только во время выборки данных, реляционные базы данных классифицируются как динамические системы управления базами данных. Модель реляционных баз данных основана на реляционной алгебре.
Объектно-реляционная модель
Объектно-реляционные базы данных (ОБД) или системы управления объектно-реляционными базами данных (СУОРБД) подобны реляционным БД и реализуют объектно-ориентированную модель: объект, классы и наследование
поддерживаются на уровне схемы БД и языка запросов.
Кроме того они поддерживают расширения модели данных пользовательскими методами и типами данных. Можно сказать, что объектно-реляционные базы данных являются промежуточным звеном между реляционными базами данных и объектно-ориентированными (ООСУБД). В объектно-реляционных базах данных хранение и манипулирование данными, по существу, аналогично реляционным базам данных, запросы пишутся также на языке запросов. С другой стороны существуют ООСУБД, где базы данных являются хранилищами объектов приложений, написанных на объектно-ориентированных языках программирования. Для них существуют API для хранения и извлечения объектов, с минимальной поддержкой запросов или без таковой
(из Википедии).
Рисунок 4: пример объектно-ориентированной модели данных
Системы управления объектно-реляционными базами данных добавили новые возможности хранения объектов в реляционные системы, являющихся основой современных информационных систем. Были добавлены новые средства управления полями данных: поддержка таких сложных объектов, как временные ряды, геопространственные данные и разнообразные бинарные данные: аудио, звук, изображения и апплеты. Методы инкапсуляции структур баз данных, позволяют серверам СУОРБД выполнять сложные аналитические операции, операции манипулирования данными для поиска и преобразования элементов мультимедиа и других сложных объектов.
Как очередной шаг в эволюции технологий, объектно-реляционный подход унаследовал надежность транзакций и управление производительностью от реляционного, а гибкость от объектно-ориентированного подходов. Проектировщики баз данных могут работать со знакомыми им уже табличными структурами и языками определения данных (DDL), а также осваивать новые возможности управления объектами. Запросы, процедурные языки и вызовы интерфейсов в ОРСУБД стандартны: SQL3, процедурные языки от производителя БД, ODBC, JDBC, а также вызовы собственных интерфейсов - все они являются расширениями языков и интерфейсов РСУБД. Ведущие производители хорошо известны, это - IBM, Informix, и Oracle.
Объектно-ориентированная модель
Объектно-ориентированное программирование (ООП) — это парадигма, которая основана на понятии «объект» - структуры данных состоящие из полей и методов, объединенных во взаимодействии, используются для проектирования и создания компьютерных программ. Методы программирования могут включать такие возможности как абстракция, инкапсуляция, модульность, полиморфизм и наследование. Многие современные языки в настоящее время поддерживают ООП
(из Википедии).Объект представляет собой дискретное объединение процедур и функций, обычно относящееся к какому-то понятию из реальной жизни вроде «владелец банковского счета» или «хоккеист». Другие части программы могут получить доступ к объекту только через вызов его процедур и функций, для которых разрешен вызов извне.
Большое количество специалистов соглашается с тем, что изолирование объектов облегчает управление и сопровождение ПО. Однако, значительное число специалистов считает иначе: программное обеспечение постоянно усложняется и становится все труднее поддерживать документацию, даже во время начала работы на проектом.
Условия при которых ООП превалирует над альтернативными технологиями (и наоборот) часто очень трудно определить, это затрудняет рациональное обсуждение этой темы и часто приводит к острым дискуссиям.
История
Объектно-ориентированное программирование уходит своими корнями в 60-е годы. В те времена аппаратная и программная части становились все более сложными и их управление часто вызывало проблемы. Исследователи начали изучать качество способов поддержки программного обеспечения и объектно-ориентированное программирование было частью решения общих проблем, т.к. оно уделяло большее внимание некоторым из них, включая повторное использование программной логики. Эта технология сфокусирована на данных, а не на процессе, программы состоят из самостоятельных модулей
(«классов»),
каждый экземпляр которых(«объект»)
содержит всю необходимую информацию для манипуляции собственными структурами данными («членами»).Это основное отличие от модульного программирования, которое доминировало много лет и было сфокусировано на понятии
«функция модуля»,
а не на конкретных данных, оно также предполагает повторное использование кода и основано на повторно используемых модулях программной логики и возможности связи одного модуля(подпрограммы)
с другими. Этот более традиционный подход, который можно встретить и в наши дни предполагает рассматривать данные отдельно от поведения.Совокупность взаимодействующих объектов
Объектно-ориентированная программа может рассматриваться как совокупность взаимодействующих объектов (в отличии от процедурной модели, где программа рассматривается как список задач
(подпрограмм),
которые нужно выполнить).В ООП каждый объект способен принимать сообщения, обрабатывать данные и посылать сообщения другим объектам.
Каждый объект может рассматриваться как независимый «механизм» со своей собственной ролью и возможностями. Действия
(методы)
этих объектов полностью ассоциируются с понятием «объект». Например, структуры данных ООП выполняют только собственные операторы(или, по крайней мере, унаследованные от подобных объектов или классов).
В процедурной модели данные и операции над ними не имеют между собой такой жесткой связи.
Объектные СУБД дополняют функциональность базы данных объектно-ориентированными языками программирования. Они дают намного больше чем просто хранение объектов языка программирования. Объектные СУБД расширяют семантику таких объектно-ориентированных языков как С++, Smalltalk и Java для полноценного обеспечения возможностей программирования баз данных, сохраняя при этом стандартные возможности языка.Основным преимуществом такого подходя является унифицированный подход к разработке приложений и баз данных в рамках единой модели данных и языкового окружения. В результате для написания приложения требуется меньше кода, используемый код легче обслуживать, а при моделировании используются более естественные структуры данных.
Разработчики могут создавать законченные приложения баз данных, затрачивая при этом минимальное количество усилий.
Как сказал Рао (Rao) в 1994 году: «Парадигма объектно-ориентрованных баз данных
(ООБД)
— это сочетание систем объектно-ориентированных языков программирования(ООЯП)
и традиционных систем» . Мощь ООБД заключается в одинаковом способе обработки как постоянных данных (находятся в БД), так и изменчивых данных (находятся в выполняемых приложениях).По сравнению с реляционными СУБД, где сложные структуры данных должны быть модифицированы, чтобы сохраниться в таблицах, а потом, при выборке, объединится из этих таблиц, чтобы образовать необходимые структуры в памяти, объектные СУБД не несут накладных расходов на сохранение и выборку сети или иерархии взаимосвязанных объектов.
Взаимно-однозначное отображения объекта языка программирования к объекту базы данных имеет два преимущества по сравнению с другими подходами к хранению: оно обеспечивает более высокую производительность управления объектами, что, в свою очередь, позволяет эффективнее управлять сложными взаимосвязями между объектами. В совокупности, это обеспечивает лучшую поддержку объектов СУБД со стороны таких приложений как, системы анализа финансовых рисков, приложения телекоммуникационных услуг, структуры всемирной паутины, системы проектирования и производства, системы записи пациентов медицинских учреждений, которые имеют сложные взаимоотношения между структурами данных.
Рисунок 6: обзор истории
Частично-структурированная модель
Частично-структурированная модель — это модель базы данных.
В этой модели нет разделения на данные и схему данных, а количество
используемых структур зависит от решаемых задач.
Ниже перечислены преимущества этой модели:
Она может представлять информацию из источников данных, не ограниченных схемой.
Она предоставляет гибкий формат обмена данными между различными типами баз данных.
Она может быть полезна для просмотра структур данных в виде частично-структурированных (для целей изучения).
Схему изменить очень просто.
Можно изменить формат передачи данных.
Основной компромисс использования модели частично-структурированных баз данных связан с тем, что запросы не могут быть обработаны так же эффективно, как запросы в реляционной модели с жестко структурированными данными. В частично-структурированных записях данные, обычно, сохраняются вместе с идентификаторами, которые связаны с указателями на их расположение на диске. Это делает навигацию и выполнение запросов, основанных на путях (path-based queries) достаточно эффективными, однако выборка среди множества записей (что характерно в SQL), не настолько эффективна, т.к. необходимо осуществлять поиск на диске по указателям.
Одним из стандартом описания частично-структурированных данных является Object Exchange Model (OEM), другим — XML
(из Википедии).В частично-структурированной модели данных информация и описывающая ее схема хранятся вместе, это в некоторых источниках называют «самоописанием». В таких базах данных нет четкого деления между данными и схемой, а степень, до которой оно структурировано, зависит от приложения.
Во-первых, есть такие источники данных (например, Web), которые было бы желательно рассматривать в виде баз данных, но нет возможности описать в виде схемы.
Во-вторых, есть потребности иметь гибкие форматы передачи данных между разнородными базами данных.
В-третьих, даже при работе со структурированным наборами данных может оказаться полезным для целей анализа просматривать их в виде частично-структурированных данных.
Ассоциативная модель
Еще одной альтернативной моделью систем баз данных является ассоциативная модель. Другие модели, вроде реляционной и объектной, основаны на записях. Эта модель включает в структуру записи описательные атрибуты о сущностях (например, «автомобиль»). Атрибутами могут быть «регистрация», «цвет», «марка», «модель» и др. В ассоциативной модели, все, что имеет «дискретное независимое существование» моделируется в виде сущностей, а связи между ними
-
в виде ассоциаций. Детализация представления данных подобна детализации представления схемы Чена (Chen) в «модели сущность-связь (Entity-relationship model)»; Браччи (Bracchi), Паолини (Paolini) и Пелогатти (Pelagatti) в «бинарных отношениях (Binary Relations)} и Сенко (Senko) в «модели множества сущностей (The Entity Set Model)».
Особенности этой модели были описаны Симоном Вильямсом (Simon Williams) в книге « The Associative Model of Data», где были перечислены отличия ассоциативной модели от более традиционных моделей
(из Википедии).Ассоциативная модель делит данные о реальных вещах на два вида: Независимые дискретные сущности.
Сущности, чье существование ни от чего не зависит.
Ассоциации являются таким типом связи, который отражает зависимость нескольких элементов, и, если один из них прекращает свое существование, то и сама связь прекращает свое существование, либо теряет смысл.
Ассоциативные базы данных состоят из двух видов данных:
1. Набор элементов, имеющих уникальный идентификатор, имя и тип.
2 Набор ссылок, имеющих уникальный идентификатор, наряду с еще тремя уникальными идентификаторами, характеризующих источник, глагол и цель факта, описывающего данные в базе данных.
Все эти три понятия могут быть представлены как в виде ссылки, так и в
Рисунок 7: таблицы ассоциаций
виде элемента.
В некоторых формах частично-структурированных данных схема не выделена, в других, ее отделяют, но только для участков данных с отсутствием ограничений. Частично-структурированные данные обычно моделируют в терминах графов, которые состоят из надписей, определяющих семантику внутренней структуры. Такие базы данных поддерживают новейшие расширения от плоских реляционных баз данных до вложенных баз данных, которые поддерживают вложенность (или инкапсуляцию) сущностей, и объектных баз данных, которые поддерживают еще и циклические связи между объектами. Частично-структурированные данные, по ряду причин, в последнее время приобретают особую важность.
Модель данных Сущность-Атрибут-Значение
Модель «сущность-атрибут-значение (EAV)» — это модель данных, где для описания сущности может применятся огромное количество атрибутов (свойств и параметров), но для описания какого-то конкретного элемента необходима лишь некоторая часть из них В математике такую модель называют разреженной матрицей. EAV также известна как модель сущность-атрибут-значение с открытой схемой.
(из Википедии)Наилучший способ понять проектные обоснования EAV — это разобрать моделирование строк (row modelling), обобщенной формой чего и является EAV. Рассмотрим для примера базу данных супермаркета, в которой хранятся тысячи наименований товаров и брендов, многие из которых существуют в течение определенных промежутков времени. Из этого становится очевидным, что название товара не может быть таким постоянным как название столбца таблицы базы данных. Вместо этого, описание продукта хранится в таблице Products, а операции покупки и продажи конкретных товаров сохраняются в других таблицах в виде строк, имеющих ссылку (ID) на товар из этой таблицы. Концептуально дизайн EAV состоит из одной таблицы с тремя колонками, сущности
(например, ссылка (ID) на «обонятельный рецептор»),
атрибута(то, на что ссылается указатель в таблице метаданных)
и значения атрибута(например, «мышь»).
В EAV одна строка хранит один факт
По сравнению с обычными таблицами, где один столбец соответствует одному атрибуту, здесь одна строка хранит множество фактов. Использование EAV имеет смысл в тех случаях, когда число потенциальных параметров сущности намного превышает число параметров какого-то конкретного примера этой сущности. Более подробную информацию о модели данных EAV/CR можно найти по адресу:
http://ycmi.med.yale.edu/nadkarni/eav_cr_contents.htm
Кое-что особенное: Контекстная модель
Контекстная модель данных сочетает в себе все ранее перечисленные возможности других моделей данных. Её можно рассматривать как коллекцию объектно-ориентированной, сетевой и частично-структурированной моделей или как подвид объектной базы данных. Другими словами, это гибкая модель, которую можно использовать в виде любого типа базы данных в зависимости от решаемых задач. Такая модель данных реализована в СУБД ConteXt.
КЛАСС - основной модуль хранения информации в ConteXt Класс содержит МЕТОДЫ и описывает ОБЪЕКТ. Объект содержит ПОЛЯ и СВОЙСТВА.
Поле может быть составным и может содержать другие поля. Свойством является множество полей, относящихся к конкретному объекту
(как в базах AVL).
Другими словами поля — это постоянная часть объекта, в то время как свойства — это его изменчивая часть.
Заголовок класса содержит определение внутренней структуры объекта, которая включает описание каждого поля (тип, размерность, атрибуты и имя).
Контекстная модель данных представляет собой набор предопределенных типов и типов, определенных пользователем.
Предопределенные типы включают в себя не только строки символов, числа и тексты, но также указатели
(ссылки)
и агрегатные типы(структуры).
Контекстная модель состоит из трех основных типов данных: ОБЫЧНЫЙ, ВИРТУАЛЬНЫЙ и ССЫЛОЧНЫЙ. Обычное(локальное)
поле может быть быть АТОМАРНЫМ или СОСТАВНЫМ. Атомарное
поле не имеет внутренней структуры в отличии от составных, которые могут иметь сложную структуру и их тип описывается в заголовке класса.
Составные поля делятся на СТАТИЧЕСКИЕ и ДИНАМИЧЕСКИЕ.
Информация о типе статичного составного поля сохраняется в заголовке и не изменяется. Описание типа динамичного составного поля хранится внутри объекта и может изменятся от объекта к объекту.
Подобно сетевым базам данных, помимо полей непосредственно хранящих информацию, в контекстных БД имеются поля, позволяющие узнать, где она может быть найдена, это УКАЗАТЕЛИ (или ссылки) на объекты того или иного класса.
Поскольку основным модулем контекстной БД является объект, то указатель может ссылаться только на объект, а не на его поля. Указатели также бывают двух видов: СТАТИЧЕСКИЕ и
ДИНАМИЧЕСКИЕ.
Все указатели относятся к одному типу статичных указателей на классы одного типа
(хотя, возможно, ссылаются на разные объекты).
В этом случае имя класса является неотъемлемой частью указателя. Тип динамических указателей описывает указатели, которые могут ссылаться на различные классы. Классы, которые могут быть связаны через указатели, могут находится как на одном компьютере, так и на разных компьютерах в локальной сети.Между классами не существует никакой иерархии, поэтому указатели могут ссылаться на любой из них, в том числе и на самих себя.
В отличии от объектно-ориентированных баз данных, контекстные базы данных не так тесно связаны с языками программирования и не поддерживают напрямую вызовы из методов. Вместо этого, вызов методов поддерживается посредством концепции ВИРТУАЛЬНЫХ полей.
Виртуальное поле подобно обычному: его можно записать и прочитать. Однако эти поля физически не хранятся в базе данных и не имеют описывающего их типа в схеме. СУБД перехватывает операцию чтения виртуального поля и вызывает метод, связанный с этим полем, а в качестве результата возвращает результат этого метода. Если с полем не связан ни один метод, то будет возвращено пустое значение. МЕТОДОМ является подпрограмма написанная на С++ программистом приложения. Аналогично, операция записи виртуального поля вызывает соответствующий метод, который может изменить значение поля. Текущее значение виртуального поля поддерживается запущенным процессом и не сохраняется между сессиями. В терминах объектно-ориентированного подхода, виртуальное поля представляет только два публичных (public) метода для чтения и записи. Однако, опыт показывает, что этого вполне достаточно для функционирования приложений. С точки зрения СУБД, виртуальные поля предоставляют прозрачный интерфейс для методов, включенных разработчиками в свои приложения.
Контекстную базу данных, которая не имеет составных полей, полей-указателей и свойств можно считать реляционной. Со статичными составными полями и полями-указателями, контекстная база данных становится объектно-ориентированной. Если же она имеет только свойства, то в данном случае является базой данных EAV. С динамичными составными полями, ее можно назвать частично-структурированной. Если в базе данных имеются все перечисленные типы, то тогда она становится контекстной.
Этим летом я взял много интервью у различных людей по теме объектно-ориентированных баз данных.
Самое интересную информацию я получил от InterSystems. Это фирма работает по всему миру, офис находится в Бельгии и есть филиал в Амстердаме. Они создали мощную ООБД, названную CACHE.
Они были очень рады проведенной мной долгой беседы с одним из их специалистов. Я многое узнал о объектно-ориентированных базах данных, и относящемуся к ним сегменту рынка. ООБД заняли серьезную нишу на рынке баз данных. Одним из выявленных мной фактов, было то, что InterSystems добавило язык запросов в свою ООБД, сделав ее тем самым похожей по функциональности на обычные базы данных. Мне также рассказали кое-что об особых клиентах фирмы:
Полиция Бельгии
Ужасное преступление в 1996 году (возможно, имеется ввиду «процесс века» над педофилом-убийцей Марком Дютру, прим. пер.) дало толчок началу радикальных реформ полиции Бельгии. Новые законы были приняты в 1998 году и объединили 196 независимых бельгийских полицейских участков (использующих информационные системы лоскутного типа), федеральную полицию (с ее собственной информационной системой) и уголовный розыск (Criminal Investigation Department) в единую интегрированную двухуровневую (федеральная и местная полиция) систему.
Объектно-ориентированные базы данных (продолжение 4)
Закон также призвал федеральную полицию использовать единую архитектуру программных и аппаратных средств. В качестве основной инфраструктуры управления данными была выбрана промышленная СУБД Cache.
Эдди Майлерт (Eddy Muylaert), директор по информационным технологиям федеральной полиции, контролирует разработку нового семейства Cache-приложений. В него входят следующие модули: «Транспорт (Transit)», «Бюро расследований (Investigation Management)» и «Денежные переводы (Money Transfer)» с доступом к приложениям через защищенный Web-портал. Cache также используется приложениями для повседневных операций, таких как управление файлами, человеческими ресурсами, логистикой, платежными ведомостями, телефонным справочником и др. Когда все эти приложения будут полностью развернуты «они будут использоваться круглосуточно 7 дней в неделю примерно 4500 агенствами на 24000 персональных компьютеров» - говорит Майлерт - « Сочетание Cache с оборудованием от Intel под управлением Red Hat Linux является достаточно быстрым и абсолютно надежным».
Модуль «Бюро расследований» предоставляет следователям широкие возможности обзора элементов в случаях обобщение информации о событиях, людях, транспорте, местах и др. деталей в различных форматах, поддерживая перекрестные ссылки при анализе данных. «Это приложение отражает то, насколько инновационен объектно-ориентированный подход, реализованный в Cache, который позволяет нам обычным образом работать с этой базой данных» - говорит Майлерт «Выбор Cache не был для нас естественным, т.к. обычным в наши дни является выбор реляционной базы данных» - продолжает Майлерт -«Ключевым для нас стало не только производительность и надежность Cache, а также минимальные требования к аппаратному обеспечению, но и возможность легкой миграции данных, метаданных и хранимых процедур из использованных нами до этого систем, основанных на базах данных Sybase и Informix».
Cache можно использовать совместно с Delphi (для этого понадобится драйвер ODBC). Вы можете загрузить пробную версию по адресу: http://download.intersystems.com/download/register.csp
Технические детали
Cache-объекты, основанные на пострляционных базах данных Cache идеально подходят для создания высокопроизводительных приложений создаваемых при помощи Web или объектно-ориентированных технологий. Используя объектную технологию Cache, программисты могут создавать значимые структуры данных, отражающие реальный мир, и рационализировать процесс разработки.
Cache-объекты предоставляют быструю разработку в целях ускорения производства ПО. Эта технология поддерживает такие концепции как наследование, инкапсуляция и полиморфизм.
Наследование - это возможность получить объекты одного класса из другого. Новый класс
(класс-потомок)
всегда состоит в отношении «является» с классом-предком.Например, собака «является» млекопитающим, поэтому класс «Собака» может унаследовать все свойства и методы класса «Млекопитающее», а также содержать свойства и методы, присущие только собакам. Множественное наследование означает, что класс-потомок может быть создан на основе нескольких предков. Так, собака помимо того, что «является» млекопитающим, также «является» домашним животным, поэтому класс «Собака» может наследовать атрибуты обоих классов «Млекопитающее» и «Домашнее животное».
Инкапсуляция означает то, что с точки зрения приложения классы рассматриваются в виде «черных ящиков». Независимо о того, насколько они сложны, классы имеют конечное число свойств и методов. После объявления класса, приложению нет необходимости знать его внутреннюю реализацию. Приложение взаимодействует с классом только через его свойства и методы.
Метод «черного ящика» дает два важных преимущества
Классы модульны. Программисты могут улучшить внутреннею работу классов, не влияя на оставшуюся часть приложения.
Классы совместимы.
Классы могут быть разделены между приложениями, поскольку их интерфейс (свойства и методы) не изменяется.
Полиморфизм основан на факте того, что методы разных классов могут использовать общий интерфейс, даже если основная часть их реализации различна. Например, в приложении имеются три разных класса: «Письмо», «Почтовый ярлык» (этикетка с именем и адресом получателя, которая прикрепляется к почтовому отправлению, от англ. «Mailing Label» прим. пер.), и «Удостоверение личности», в каждом из которых есть метод PrintAddress. При этом нет необходимости хранить в приложении специальные инструкции для форматирования строки адреса для каждого вида объектов.
Модель объектов Cache подобна реальному миру
Объектная технология Cache пытается описать данные подобно тому как люди думают о данных и используют их. Это достигается путем связывания воедино данных и кода, который показывает как используются данные. На языка объектов, различные данные, содержащиеся в классе, называются «свойства», а секции кода, описывающие поведение данных, называются «методы».
Объектная технология Cache способствует натуральному описанию данных и не ограничивает описание свойств только при помощи простых, используемых компьютерами типов данных.
Классы могут содержать другие классы или ссылаться на другие классы, это облегчает создание полезных и значимых моделей данных. Вот пример:
Создание объектов
Cache Studio позволяет быстро создавать и редактировать классы. Studio представляет собой IDE и позволяет разработчикам делать все необходимые операции при разработке приложений. Для задач моделирования она позволяет устанавливать свойства, кодировать и отлаживать методы объектов, определять специализированные типы данных. Поддержка таких передовых объектных концепций, как одиночное и множественное наследование, встроенные объекты, ссылки на объекты, коллекции, связи и полиморфизм, делают Studio мощным и продуктивным окружением для моделирования данных и бизнес-процессов.
Импорт и экспорт моделей данных
В Studio присутствует мастер для облегчения создания Cache-классов, но существуют также несколько способов импорта и экспорта определений классов.
Cache RoseLink позволяет импортировать в Cache классы, созданные в популярном инструменте моделирования Rose компании Rational Software. Аналогично определение классов может быть экспортировано из Сache в Rose.
В Cache также можно создавать объекты на основе DDL-файлов с реляционной структурой данных. Полученные классы будут очень простыми: типы свойств будут соответствовать типам соответствующих полей, а методы - поддерживать операции чтения и записи с диска. Однако, благодаря унифицированной архитектуре данных Cache, даже эти простые классы могут быть сразу же использованы в объектных языках программирования и могут быть использованы в качестве строительных блоков для создания более сложных моделей данных.
XML предоставляет другой способ обмена определениями классов между приложениями, которые могут быть загружены или выгружены как XML-документы.
Скриптовые языки
Методы Сache-объектов кодируются при помощи Cache ObjectScript или Cache Basic. Оба языка позволяют разработчикам одновременно использовать все способы доступа к Сache-данным: объекты, SQL и многомерность.
Интегрирование объектов с другими технологиями
Мощность унифицированной архитектуры данных Cache состоит в том, что ее классы доступны в виде реляционных таблиц при использовании технологий ODBC и JDBC, а при использовании наследования Cache-классы могут быт легко адаптированы для использования совместно с XML и объектно-ориентированными технологиями. Cache Server Pages
Существует класс для работы с Cache Server Page, содержащий все необходимые методы для управления web-сессиями, у него также имеется метод «OnPage()», где разработчики могут разместить код для определения содержания страницы. XML
Наследование свойств и методов класса %XML.Adaptor (от InterSystems) позволяет импортировать и экспортировать данные в формате XML. Cache автоматически настраивает отображение Cache-объектов на структуру XML документа, при этом разработчики могут создавать свои собственные схемы отображения. COM
При помощи одной команды Cache Studio можно создать COM-классы на основе Cache-классов для использования в таких инструментах как Visual Basic, Delphi и другом ПО поддерживающим технологию COM. Cache также предоставляет COM Gateway, что позволяет использовать COM-объекты в Cache-приложениях. C+ +
Аналогично при помощи одной команды можно создать проекцию
классов языка C++ на cache-классы
Java
При помощи одной команды также можно конвертировать Cache-классы в Java-классы. Cache также предоставляет программистам языка Java библиотеку доступа к Cache-объектам в базе данных Cache. EJB
Аналогично при помощи одного щелчка в Cache Studio можно создать проекцию EJB. Cache предоставляет разработчикам преимущества Bean-Managed Persistence, облегчающей утомительное кодирование проекции Java-классов на реляционные таблицы. Cache поддерживает сервер BEA's WebLogic.
| < Предыдущая | Следующая > |
|---|
