Sentences — название СУБД, поставляемой скромной по размеру английской компанией Lazy Software — стоит перевести как «предложение» в грамматическом смысле «фраза» или «часть речи». Sentences оригинальна. Она не использует ни одну из известных моделей, ни реляционную, ни постреляционную, ни объектно-ориентированную. Автор принципиально новой модели — Симон Вильямс, он же основатель и генеральный директор компании Lazy Software. Вильямс назвал свою модель ассоциативной. Именно предложение является в ней одной из основных синтаксических конструкций, следовательно, из множества значений слова sentence это — наиболее подходящее. В то же самое время, если судить по агрессии, с которой Вильямс доказывает преимущество своей модели, он с большим удовольствием согласился бы со значением «приговор» в отношении реляционной модели, против которой он активно выступает. Быть может, в этом и есть тайный смысл названия СУБД. Пока же Lazy Software в своем противостоянии с производителями признанных средств управления базами данных напоминает Давида. Библейскому герою победить Голиафа помогла природная смекалка и имевшаяся у него праща — у Вильямса же есть запас интеллекта и его ассоциативная модель.

В свое время Симон Вильямс был идеологом и разработчиком среды Synon/2 для компьютера IBM AS/400. Впоследствии Synon/2 и Obsydian были куплены компанией Computer Associates и продолжают жить под именами COOL:2E и COOL:Plex. Свое новое предприятие Вильямс создал в конце 90-х годов, положив в основу концепцию, которую он сам называет ассоциативной моделью (associative model). В нее он включает весь набор представлений, структур и методов, заложенных в основу СУБД Sentences. Ассоциативная модель создана Вильямсом с учетом результатов академических исследований в нескольких современных направлениях. Среди них — техника triple stores, используемая для работы с базами знаний и с объектно-ориентированными базами данных (перевода этого термина на русский язык я не встречал; содержательно же с ним можно познакомиться на сайте консорциума W3C по адресу www.w3.org/2001/01/dts). Также использован аппарат семантических сетей, двоично-реляционные техники и модель «сущность-отношение» (entity-relationship). Далеко не полное перечисление научных дисциплин, повлиявших на создание ассоциативной модели, показывает, насколько сложнее ее внутренняя логика по сравнению с почти тривиальной табличной логикой реляционной модели. На алгоритмы и структуры данных Вильямс получил несколько американских патентов, они составляют коммерческую тайну, подлинное внутреннее устройство Sentences не раскрывается.

Известно только, что технология программирования в Sentences — самая современная, в качестве языка для создания СУБД был избран язык Java, кроме того, активно используется XML.

Ассоциативная модель

Для сопоставления реляционной и ассоциативной моделей можно предложить следующую метафору. Реляционная модель — это некая бухгалтерская книга, состоящая из таблиц, понятных в случае реальной бухгалтерии обученному бухгалтеру, в информационной системе программе, которая «знает» структуру данных. Поэтому каждое новое приложение необходимо адаптировать («обучить») к этой структуре. Напротив, ассоциативная модель ближе к обычному тексту, причем кроме контента она содержит еще и метаданные, указывающие на то, как следует интерпретировать реальные данные. Следовательно, каждое вновь создаваемое приложение не обязано знать конкретную структуру, а всего лишь должно быть «обученным» манипулированию метаданными. Правила этого языка внутри СУБД Sentences стандартны, поэтому приложение не засвистит от данных, об этом речь пойдет ниже.

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

Структура предложения в языке Sentences мало отличается от структуры предложений в естественных языках. Например, обычное предложение в английском языке с учетом характерного для него порядка слов состоит из триады субъект — глагол — объект. В языке возможна вложенность предложений наподобие субъект — глагол — (субъект — глагол — объект) или (субъект — глагол — объект) — объект. Вот несколько простых предложений:

на английском:

The sky is coloured blue

Mary Murphy is sister to William Peters

Cows eat grass

Grass is a plant

Avis has a credit limit of ?10,000

London is located in the UK;

и на языке, который понимает Sentences:

Avis is a Customer

Avis has telephone number 0171 123 4567

Avis has credit limit ?10,000

Avis has outstanding balance of ?4,567

Boeing is a Customer

Boeing has telephone number 0181 345 6789

Boeing has credit limit ?2,500

Boeing has outstanding balance ?1,098.

Ядро ассоциативного моделирования заключено в дихотомии явлений реального мира, деление их на сущности и ассоциации. Все существующее в реальном переносится в информационный мир имен, предметов, описаний и связей между ними. Но что принципиально важно, так это то, что предметы и ассоциированные с ними другие предметы в Sentences представляют собой разные категории. Большинство (если не все) известных систем моделирования игнорируют эту разницу, особенно реляционные системы. В них, например, человек и покупатель выступают равновеликими понятиями, они не могут сохранить связь между человеком как таковым и им же в роли покупателя, работника, члена команды и т.д. Для выражения этой многозначности ассоциативные базы данных состоят из двух структур данных: набор элементов(item), каждый из которых имеет идентификатор, имя и тип; набор связей (link), каждая из которых имеет свой собственный идентификатор, а также три составляющих: источник (source), глагол (verb) и цель (target).

И источник, и глагол, и цель обладают вложенностью, т. е. могут являться элементом или связью. Так, во фразе «Flight BA1234 arrived at London Heathrow on 12-Dec-98 at 10:25am» семь элементов, из них четыре вещи (Flight BA1234, London Heathrow, 12-Dec-98, 10:24am) и три глагола (arrived at, on, at). В данном случае в роли глаголов используются и предлоги.

Для хранения данных требуется три связи:

Flight BA1234 arrived at 
Heathrow Airport
... on 12-Aug-98
... at 10:25am

В первой строке устанавливается связь между рейсом BA1234 и аэропортом Heathrow Airport, а во второй — ассоциация первой связи с 12-Aug-98. Синтаксис предписывает использовать три точки для указания того, что предыдущая связь является источником.

Предположим, что нужно создать некоторое приложение для компании, торгующей книгами (Book) через Internet с учетом того, что она работает за границей через местных агентов (Legal entity). Итак:

  • в соответствии с авторским правом и другим юридическим обстоятельствам в каждой из стран (Country) продается некоторое подмножество книг из общей номенклатуры книг;
  • каждой книге, поступающей в продажу с некоторой даты (Date), соответствует призовой бонус (Points);
  • чтобы приобрести книгу, клиент (Person) должен зарегистрировать себя;
  • с момента первого обращения (Date) клиент накапливает свой бонус (Points), размер которого не зависит от страны, где была совершена покупка.

В терминах Sentences схема ассоциативной модели будет выглядеть следующим образом:

Legal entity sells Book
... worth Points
... in Country
... from Date
... at Price
Person lives in Country
Person customer of Legal entity
... has earned Points
... orders Book
... on Date
... at Price

Это описание является в явной форме метаданными, а собственно данные по торговым агентам, книгам, покупателям и странам:

Amazon is a Legal entity
Bookpages is a Legal entity
Dr No is a Book
Simon Williams is a Person
Simon Williams lives in Britain
Mary Davis is a Person
Mary Davis lives in America
Britain is a Country
America is a Country
Spycatcher is a Book

Прейскурант:

Bookpages sells Dr No
... worth 35 points
... in Britain
... from 1-Jan-00
... at ?8
... in America
... from 1-Jan-00
... at $14
Bookpages sells Spycatcher
... worth 35 points
... in America
... from 1-Jun-00

Записи по покупателям:

Simon Williams customer of Bookpages
... has earned 1,200 points
... orders Dr No
... on 10-Oct-00
... at ?10
Mary Davis customer of Amazon
... has earned 750 points
... orders Spycatcher
... on 19-Oct-00
... at $12

На SQL описание этой же информационной структуры можно представить таким образом:

CREATE TABLE Person
( Person_id ,
Person_name ,
Country_id REFERENCES Country ,
PRIMARY KEY ( Person_id ) )
CREATE TABLE Country
( Country_id ,
Country_name ,
PRIMARY KEY ( Country_id ) )
CREATE TABLE Book
( Book_id ,
Book_name ,
PRIMARY KEY ( Book_id ) )
CREATE TABLE Legal_entity
( Legal_entity_id ,
Legal_entity_name ,
PRIMARY KEY ( Legal_entity_id ) )
CREATE TABLE Books_sold
( Legal_entity_id REFERENCES Legal_entity ,
Book_id REFERENCES Book ,
Points ,
PRIMARY KEY ( Legal_entity_id, Book_id ) )
CREATE TABLE Person
( Person_id ,
Person_name ,
Country_id REFERENCES Country ,
PRIMARY KEY ( Person_id ) )
CREATE TABLE Country
( Country_id ,
Country_name ,
PRIMARY KEY ( Country_id ) )
CREATE TABLE Book
( Book_id ,
Book_name ,
PRIMARY KEY ( Book_id ) )
CREATE TABLE Legal_entity
( Legal_entity_id ,
Legal_entity_name ,
PRIMARY KEY ( Legal_entity_id ) )
CREATE TABLE Books_sold
( Legal_entity_id REFERENCES Legal_entity ,
Book_id REFERENCES Book ,
Points ,
PRIMARY KEY ( Legal_entity_id, Book_id ) )

Как видим, ассоциативная модель, во-первых, отличается большей наглядностью записи, во-вторых, в нее включены метаданные. Здесь бросается в глаза полная аналогия с XML и метаданными в нем.

Еще одну аналогию с книгами для чтения можно найти в том, что данные в базе делятся на главы (chapter). Главы это верхний элемент иерархии, используя их, разработчик создает схемы хранения, ими же регламентируется доступ. Для каждого пользователя создается профиль, определяющий доступные ему главы. В приведенном выше примере глава А доступна всем, а главы B и C — соответственно английским и американским пользователям, поскольку в первом случае используется почтовый индекс Postcode, а во втором — Zip code.

Chapter A: Person first name Name
Seen by all users
Person family name Name
Seen by all users
Chapter B: Person postcode Postcode
Seen by UK users
Chapter C: Person zip code Zip code
Seen by U.S. users

Особенности ассоциативной модели

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

Компания Lazy Software решает примерно ту же задачу, но собственным путем. Что, в конечном счете, делают серверы приложений? Помимо прочего, они компенсируют неудобства работы с реляционными СУБД, не позволяющими разделить две логики, о которых постоянно говорят. Вильямс поступил радикально, обеспечив ровно то же самое, но средствами самой СУБД Sentences.

«Развязка» разработчика и СУБД, возможность использования данных разными приложениями обеспечивается метаязыком, на котором описывается схема хранения данных. Для того чтобы сделать запись на метаязыке не нужно быть специалистом по базам данных, не требуется знание внутренней структуры, работа ограничивается взаимодействием с описанием на метаязыке.

О реализации

Платформа Sentences состоит из среды разработки Application Development Environment (ADE) и собственно СУБД. Обе они подчинены идее разработки, ориентированной на данные (Data-Focused Application Development — D-FAD). Машина Sentences (Sentences Server) выполняет Java-сервлеты, установленные как часть Web-сервера, она автоматически обрабатывает запросы, поступающие от клиента (Sentences Client), работающего как Java-апплет в браузере. Sentences GUI состоит из трех частей:

  • Sentences Explorer - основное рабочее место, аналогичное по функциональности Windows Explorer;
  • Dataform - средство для работы c сущностями, ассоциациями и связями между ними.
  • Query Editor - средство для работы с языком запросов, напоминающим SQL.

С сайта компании можно загрузить персональную версию и соответствующую документацию. Полная стоимость продукта составляет примерно 80 тыc. долл., включая обучение персонала, а версия Try & Buy стоит менее 20 тыс. с возможностью модернизации до полной версии.

В документации можно найти множество аргументов в пользу превосходства ассоциативной модели перед реляционной. Некоторые из них довольно спорны; например, утверждается, что скорость разработки возрастает в 30 раз. Такая точность напоминает рекламу, например крема, обеспечивающего омоложение кожи на 37%. На фоне вложенных за три десятилетия в реляционные СУБД инвестиций утверждения эти выглядят, прямо скажем, не очень убедительно.

Но на одно обстоятельство следует обратить очень серьезное внимание, а именно на простоту кластеризации. В отличие от реляционной модели модель Вильямса изначально задумывалась для работы на кластерных конфигурациях, и это может оказаться решающим фактором для успеха Sentences. В этой СУБД данные сегментированы по главам, а то, на каком сервере находится та или иная глава, не имеет никакого значения, а с таблицами наблюдаются явные сложности. С появлением в ближайшие годы кластерных серверов, набитых или сотнями серверов-лезвий, потребность в кластеризуемом программном обеспечении будет постоянно возрастать. Пока ни Real Application Clusters в Oracle 9i, ни средства кластеризации в IBM DB2 не стали массовыми. Может быть это дает дополнительный шанс Lazy Software с ее СУБД Sentences?