Новые одежды знакомых СУБД: Объектная реальность, данная нам

Минувшим летом компьютерный (ПО) мир пережил выдающееся событие: поступила в продажу новая версия 8 СУБД фирмы Oracle, крупнейшего в мире производителя систем своего класса. Об этой версии давно и много говорилось, главным образом в связи с одним ее качеством: объектностью. Вероятно уже этой осенью отечественные разработчики начнут получать ее как штатную поставку2, и вопрос возможностей и свойств версии станет для многих в практической плоскости; пока же есть время мысленно подготовится к этому ответственному моменту.

В такой подготовке, кажется, есть резон. Знакомство с "объектной версией" по публикациям (см., например, статьи из Oracle Magazine/Russian Edition # 2/1997 [1,2,3], а также [13]) говорит о том, что с ожиданиями, вскультивированными в предверии этой версии, и сформировавшимися безотносительно к ней конкретно, не так все просто.

Какие впечатления остаются от этого заочного знакомства с "новой" Oracle ? Первый основной вывод в общем-то не нов, но с появлением "восьмерки" он приобрел "официальность" и статус свершившегося: объектные свойства в Oracle8 реализованы "в соответствии со стандартом SQL3". По поводу того, хорошо это, или плохо, существуют разные мнения, хотя само наличие этих разных мнений не очень уж активно отображается массовой3 компьютерной прессой - SQLn (n = 1, 2, 3) поддерживается всеми крупнейшими поставщиками СУБД. Тут как бы два основных вопроса: само направление развития языка работы с СУБД, называемого SQL, и способ реализации работы с объектами в SQL3.

SQL против реляционности

Oracle пошел по пути SQL, и нужно сразу оговориться, что всем пользователям придется приноравливаться к тому, что предлагает фирма, так как она - единственный и полноправный системный разработчик "реляционной" СУБД Oracle. Но все же нелишне помнить (в первую очередь разработчикам, прикладных систем), что замечательных во всех отношениях средств разработки нет, и что свои изъяны имеются и у языка SQL как такового (со всеми его версиями). Желающие могут, например, обратиться к статье "Соответствие стандартам SQL" Карла Дадли в [5]. В ней, а так же у некоторых других авторов (Фабиан Паскаль [8], Крис Дейт) отмечается, что "натяжка" произошла уже с первых версий SQL, поскольку если считать за определения реляционности системы давние формулировки "отца-основателя" Э. Кодда (а других и не было), то SQL - не реляционный язык вовсе4 ! Реляционных СУБД в мире до сих пор нет, а тех, которые называют себя таковыми, естественнее называть "реляционно-ориентированным", или же "SQL"-системами. Это, казалось бы, казуистическое наблюдение, на самом деле, глубоко практично с одной стороны, а с другой - весьма характерно.

В самом деле, известная с 70-х годов обширная математическая проработка реляционных систем в SQL-системах осталась практически невостребованной. Возможно, самым выдающимся "реляционным" явлением SQL-систем (т.е. максимумом из того реляционного, что можно было реализовать) можно считать внешний ключ в его понимании SQL-системами. А ведь в "реляционных работах" 70-х и 80-х годов речь шла как раз о проектировании информационных систем! Сознательно лишив SQL "теоретического наследства", разработчики этого языка, встали на путь компромиссов и лишили SQL заодно и выразительности, эффективности, удобства, надежности и пр. программирования. Вот например: отказ от реализации основного для реляционных систем принципа разделения данных и прикладных программ стоит до сих пор разработчикам на SQL постоянной головной боли от поисков места, куда бы поместить проверку целостности (выражаясь теперешним арго, бизнес-правила на клиенте чи то на сервере ?). В реляционной теории такому вопросу места нет: там все проблемы оптимизации выполнения запросов передаются СУБД, а проблемами программиста (точнее, в реляционном понимании, уже не "программиста", а "разработчика") становятся проблемы моделирования прикладной области. Нету в прикладной области и такой волшебной вещи, как индекс, который проник в SQL сразу с двух сторон: с парадного подъезда языка и с черного хода псевдокомментариев (этот чудесный инструмент моделирования в языке определяется, но фактически нигде не используется!). Вместе с реляционными таблицами, доменами (до "реляционной эпохи" слово "domain" переводилось на русский язык в математике как "область определения"; таким образом речь идет об описании правил существования объектов базы данных, т.е. пресловутых "бизнес-правил") и реляционными операциями5 в SQL-системах пропала и возможность (очень развитая в математических журналах) проверки корректности построенной модели.

В чем проявляется "потеря выразительности" SQL, "эффективности и пр.", сказано уже немало, и вряд ли стоит это подробно повторять. Для тех, кто не пишет на SQL и не читал чужих текстов на SQL, можно привести три простых примера.

Вот пример не самого непринужденного соответствия формулировки естественного для многих автоматизируемых систем запроса агломерату, получаемому в SQL. Запрос "Выдать отдел с максимальными затратами" по наблюдению упоминавшегося Карла Дадли выглядит примерно как

SELECT dept.deptno, dname, SUM(sal + NVL(comm,0)) compensation
FROM emp, dept
WHERE emp.deptno = dept.deptno
GROUP BY dept.deptno, dname
HAVING SUM(sal + NVL(comm, 0)) = 
(SELECT MAX(SUM(sal) + NVL(comm, 0)))
 FROM emp
 GROUP BY deptno);

(Здесь это выражение из [5] несколько упрощено.)

А вот как получить в SQL ответ на запрос "Для отдела 30 выдать список, содержащий среднюю зарплату сотрудников, которые получают зарплату, средние комиссионные сотрудников, которые получают комиссионные, и среднюю зарплату плюс комиссионные только тех сотрудников, которые получают комиссионные и зарплату одновременно":

SELECT AVG(sal), AVG(comm), AVG(sal + comm)
FROM emp
WHERE deptno = 30;

Язык, которым сформулированы оба "прикладных" запроса здесь практически формален, к нему не предъявишь претензии типа "это трудно выразить словами", и поэтому имеющееся налицо несоответствие сложности запросов получающимся фразам на SQL не может вдохновлять разработчика, т.к. не помогает его работе. В реляционном варианте оба запроса, скорее всего, были бы простыми обращениями к выводимым таблицам (view), про каждую из которых известно, что одна из них - это перечень отделов с указанием их затрат, вторая - перечень сотрудников, получающих зарплату и т.д. Заведение же view в SQL-системе, по меньшей мере, не улучшает эффективность, и часто ограничивает возможности манипуляции с данными, почему и служит там более как техника ограничения доступа, нежели чем как техника моделирования.

Еще один пример - сравнительная пара SQL-запросов, дающих чаще всего неодинаковый результат, и провоцирующая бессознательную ошибку:

SELECT * FROM emp WHERE mgr IS NULL;

и

SELECT * FROM emp WHERE mgr = NULL;

Сюда же можно добавить, что фраза

UPDATE emp SET mgr = NULL WHERE empno = 7369;

в SQL существует, а фраза

UPDATE emp SET mgr = NULL WHERE empno IS 7369;

- нет.

Наконец, отсутствие в SQL-системах операции разбиения (partition) приводит к достаточно изощренному виду SQL-запроса, если требуется узнать "пять сотрудников с наибольшими окладами":

SELECT ename, -sal, sal
FROM 
(SELECT DISTINCT -sal, sal, ename, empno 
 FROM emp)
WHERE ROWNUM <= 5;

Последний пример взят из [4] причем автор примера, И. Филимонов, утверждает, что при обсуждении правильной формулировки этого запроса в Internet многие профессионалы в области СУБД (администраторы и консультанты по Oracle) приводили неправильные ответы. Пример характерен еще и тем, что использует побочный эффект упорядочения при указании DISTINCT.

Из приведенных примеров ясно, что по крайней мере, используя SQL, разработчик не в состоянии концентрироваться на прикладной области и вынужден немалую часть времени тратить на чисто технические вопросы. В [15] приводится высказывание Дейта о том, что [часто] специалист не может быстро сказать, правильно или нет составлено SQL-выражение: для этого требуется кошмарный бессистемный поиск в справочных руководствах, и это касается даже тех, кто эти руководства писал сам!

Почему современные крупные фирмы реализуют SQL, а не реляционный язык? Кажется, главный довод в относительно хорошей стандартизации SQL, составляющей, как отмечают некоторые авторы, его основное достоинство. Но нелишне напомнить, что другой довод, приводимый обычно представителями фирм-разработчиков в качестве основного, а именно: теория - это хорошо, а практика все-таки лучше6, хотя в реальности и справедлив (реализовать SQL действительно проще, чем реляционную систему), может вызывать некоторую неуверенность ввиду того, что и с практикой разработки информационных систем дела обстоят совсем не благополучно: например по данным исследований правительства США (принципиально не расходящимися с оценками других организаций и частных лиц), в настоящее время примерно 60% американских проектов разработки ПО не выдерживают график, 50% превышают планируемые затраты, а 45% проектов дают неиспользуемый результат [14]. И не от подобных ли практических результатов на глазах выросла волна объектности как поиска новых технологий программирования?

SQL3 против объектности

Вопроса выбора пути я еще коснусь позже, а пока хотелось бы прокомментировать реализацию работы с объектами в SQL3. Апологетика этой реализации активно звучит, что неудивительно, в статьях авторов из Oracle, и поэтому для баланса следовало бы привести альтернативные точки зрения. По части последних, пожалуй наиболее известным (хотя и не единственным) их выразителем является такой признанный специалист по базам данных, как Крис Дейт, чья публичная полемика по затронутой теме с другим известным специалистом, но в области SQL, Джо Силко, привлекла два года тому назад внимание читателей журнала DBMS (см., например, [7,9,11]. Основной посылкой Криса Дейта [7] является то, что имеется два способа объединения реляционного и объектного подходов: полагать классом объектов область определения (и, соответственно, объектом - элемент области определения столбца) и полагать классом отношение (соответственно объектом - строку таблицы).

Заблуждением разработчиков SQL3, по мнению Дейта, следовало бы признать выбор второго способа, приведшего впоследствии к путанице, трудностям моделирования, понимания и реализации. Дейт, безусловно, подкреплял правильность, по его мнению, первого способа развернутой аргументацией, с которой желающие могут ознакомиться из общедоступных источников. Мне его доводы представляются более убедительными, а его концепция - более цельной и логичной, чем представления его оппонентов. В частности, первый способ позволяет объединить реляционность с объектностью совершенно без ущерба для того и другого, проводя вместе с тем четкую границу между одним и другим. На "верхнем" уровне пользователь имеет реляционные таблицы и знакомые методы работы с ними, а на "нижнем", там где в таблице встретился объект, мы переходим на полноценный аппарат работы с объектами. Где провести границу между уровнями - зависит от проектировщика конкретной прикладной системы7. Реляционная система служит своего рода интерфейсом для работы с объектами, знакомом пользователю, и дополняющим предлагаемые способы работы с объектами. Вместо этого из описания реализации Oracle8 мы видим, что сочетание объектов и реляционнности в SQL3 не оставляет впечатления логической ясности. Трудно, например, понять, в чем смысл различения объекта-строки и объекта-элемента таблицы, подразумевающих разные операции и свойства, но в чем-то и одинаковых (для объектов-строк существует оператор REF, позволяющий получить ссылку на объект, OID - вероятно имеется в виду, что аналогом этого оператора в случае объекта-элемента таблицы служит немыслимый в реляционной теории SQL-оператор ROWID, позволяющий найти ссылку на строку с объектом; очевидно, что разработчиками приложений предлагается чересчур резкая разница между двумя способами помещения объектов в таблицу, не оставляющая возможности "плавной" модификации работающей системы).

В ссылке OID явно просматривается неинтуитивность объектного расширения SQL, в том смысле что навыки работы с (внешними) ключами в обычном SQL совершенно бесполезны при работе с объектами. Несмотря на то, что суть ссылок на объект и ключей в SQL одна - идентификация объекта работы - они пришли из разных умопостроительных конструкций, и логично объединяться никак не хотят. В объектном подходе считается принципиальным идентификация системным суррогатным ключем, а в реляционном - явной пользователю комбинацией значений. В результате ведут они себя совершенно по-разному. Например, в SQL-системах соответствие ссылок реально имеющимся записям проверяется автоматически, а в SQL3 - нет, и должно устанавливаться вручную.

Пусть, к примеру, имеются соответствующие таблицы для типов Сотрудник, Коллектив и Отдел:

CREATE TYPE Сотрудник AS OBJECT
(фио VARCHAR(40),
 ...);
CREATE TYPE Коллектив AS TABLE OF Сотрудник;
CREATE TYPE Отдел AS OBJECT 
(название VARCHAR(30),
 сотрудники Коллектив,
 ...);

(Иначе говоря, тип Отдел содержит список ссылок на сотрудников, пользуясь возможностью OID и ссылки REF(OID)).

Пусть в отделе продаж имеется два сотрудника, так что запрос (*)

SELECT COLUMN_VALUE.фио
FROM THE
(SELECT сотрудники
FROM отделы

WHERE название = 'Отдел продаж');

дает
Иванов А. Б.
Петров В. Г.

После удаления Иванова из базы данных запрос (*) выдаст в Oracle8 сообщение "Объект не существует или помечен для удаления". Более того, запрос (*) не выдаст информации о сотрудниках вообще, даже если его изменить, чтобы он запрашивал только Петрова (сведения взяты из [13]). Чтобы запрос к списку сотрудников в отделе стал работоспособным вновь, требуется выдать специальное SQL3-предложение. Естественно, такой способ работы со ссылками на объект далек от соблюдения целостности ссылок на записи в SQL(1,2).

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

Действительно, пусть имеется запись "команда_рейса", в описание которого входит описание записи "пилот", в описание которой, в свою очередь - описание записи "личность", имеющей поле "возраст". Тогда для указания возраста пилота, входящего в команду рейса самолета в системе вложенных записей Oracle8 будет нужно сказать (I):

команда_рейса.пилот.личность.возраст.

Вероятно, нужно полагать, что объект типа "пилот" наследует свойства (по крайней мере структуру) объекта "личность", а "команда_рейса" - свойства объекта "пилот". На объектном языке Delphi приведенная ситуация будет указана конструкцией (II):

личность.пилот.команда_рейса.возраст,

но допустимы и конструкции личность.возраст или личность.пилот.возраст, поскольку свойство "возраст" наследуется и "пилотом", и "командой_рейса". В Oracle8 нет возможности написать пилот.возраст, и нужно указывать всю цепочку разворачивания записей, что фактически означает навигацию. К паре (I) и (II) можно добавить для сравнения третью конструкцию, которая не используется ни в Oracle8, ни в Delphi (III):

возраст.личность.пилот.команда_рейса.

Три приведенные конструкции читаются так:

(I) "В команде рейса есть пилот, который является личностью, имеющей возраст ..."

(II) "Личность, являющаяся пилотом, входящем в команду рейса, имеет возраст ..."

(III) "Возраст личности, являющейся пилотом, входящим в команду рейса"

Очевидно в (I) (Oracle8) мы имеем дело с перевернутой записью, характерной для некоторых восточных языков. В остальном, за исключением чисел9, Oracle-диалект SQL3 не относится к этим языкам. В (II) запись более естественная (и для человека, и для объектного подхода), а в (III) она становится еще и более логичной (последовательной). Выбор перевернутой записи для указания объектов - это, конечно, не фатальный недостаток Oracle8, но, во-первых, он может создавать некоторые технические трудности на манер трудностей программирования форматирования выдачи текстов вперемешку с числами. По меньшей мере обратная запись не делает текст более читаемым, а если допустить, что объектные языки претендуют на моделирующую роль, то требование читаемости для них по сравнению с языками программирования возрастают. Во-вторых, с объектной точки зрения более логично использовать прямую запись, а не обратную.

Наконец, имеющаяся в Oracle8 реализация объектности может создавать проблемы проектирования ввиду отсутствия для нее методологии разработки, а также усложнить технологию разработки. Если отбросить мифологию, то можно вспомнить, что решающим качеством, обеспечившим в свое время возвышение "реляционных" систем перед их тогдашними конкурентами (СУБД с иерархической и сетевой структурами данных), была возможность безболезненной реструктуризации схемы данных существующей базы10. Так вот, в Oracle8 эта возможность снова исчезает, по крайней мере для объектов. Что если в процессе эксплуатации прикладной системы выясняется, что мы не совсем удачно спроектировали структуру вложенных записей? Или изменились требования прикладной области? Мы снова возвращаемся к 20-летнему механизму решения проблемы путем разгрузки и загрузки данных, приводившему в уныние разработчиков прошлых лет.

Нет никаких методик построения схемы базы данных при том, что ответственность этапа построения схемы многократно возрастает по сравнению с SQL-системами. Если мы имеем записи двух типов для характеристики лица и сведений служебного пропуска, то какая запись должна включать в себя какую: "лицо" - "пропуск", или "пропуск" - "лицо" ? Очевидно, при проектировании системы для отдела охраны (допустим, что вахта работает с пропусками, выдавая или забирая их при проходе) будет естественно использовать конструкцию типа (А)

CREATE TYPE Пропуск AS OBJECT
(номер NUMBER,
дата_выдачи DATE,
лицо Лицо,
...);

А при проектировании системы для отдела кадров - конструкцию типа (Б)

CREATE TYPE Лицо AS OBJECT
(фио VARCHAR(40),
должность VARCHAR(30),
пропуск Пропуск,
...);

Вопрос же о том, какие объектные конструкции нужно будет использовать для объединенной информационной системы отдела кадров и отдела охраны пока остается без ответа. А если мы должны объединять две работающие системы с уже существующими данными, указанная трудность осложнится еще и проблемой реструктуризации, о которой только что упоминалось. К сказанному можно добавить, что отмеченным трудностям нету места в "настоящем" объектном подходе, дух симметричности которого (в некотором роде равноправия объектов) противоречит несимметричным конструкциям типа (А) или (Б).

Многие из сложности подобного рода, связанные с объектностью SQL3, не являются исключительным достоянием этого стандарта. Многие авторы идут дальше и сомневаются в зрелости объектного подхода вообще, а значит и его реализаций в частности. Действительно не всегда понятно, то ли эти реализации опережают теоретическую проработку, то ли отстают от нее. Читая описания объектного подхода11 бывает трудно отделаться от ощущения, что слова-то новые, а вот понятия старые. Более того, такие понятия как абстрактный тип данных и модульное программирование или даже сетевая модель данных были еще лет 15 назад теоретически или технически более проработаны, чем нынешние объект или инкапсуляция. А вот современные, объектные, по-первоначалу звучат, вроде бы, толково, да в уточнении вызывают затруднения. Тот же Дейт в [7] ссылается на учебник по объектному подходу, автор которого признается в отсутствии общепринятого представления о том, что такое наследование, и приводит 8 разумных, но различных способов понимания этого явления. Никлаус Вирт предлагает вернуться не только к старым понятиям, но и к относительно хорошо исследованным терминам, рекомендуя употреблять тип, а не класс, переменная и процедура, а не экземпляр и метод (см., например, [6]). Важно понять, что это не просто игра в слова, а стремление иметь действительно качественный и надежный инструмент разработки, в котором бы отсутствовала недоработаность, задрапированная красивым, но непонятным, или же обманчивым лексиконом, хотя бы и происходящим "из Лондона или Сан-Франциско". Форсирование распространения новых подходов (по тем или иным причинам) ранее их созревания может привести совсем не к ожидаемым последствиям. У объектного подхода в нынешнем его понимании есть много привлекательных свойств, но разработчики, работавшие с конкретными реализациями в виде даже таких продвинутых в объектном отношении систем, как Delphi фирмы Borland или Rose фирмы Rational, не всегда способны сохранить энтузиазм первоначальных ожиданий.

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

И наконец, последний вопрос. Если, с точки зрения авторитетных специалистов, пути развития средств разработки приложений, выбираемые промышленностью, подвержены такой серьезной критике, то почему же промышленность эти пути выбирает ? Вопрос не нов, и обсуждается в узких кругах достаточно давно. Критика, с которой лет 20 назад выступал Никлаус Вирт (при вручении ему премии Тьюринга) в адрес фирмы Intel, в связи с форсированным выпуском на рынок недоработанных версий процессоров, повторяется в наши дни этим же специалистом в адрес производителей системного программного обеспечения. По мнению Вирта (и это мнение разделяет ряд других известных специалистов), негативную в конечном счете для пользователей роль играет именно коммерческий, рыночный фактор, заставляющий зачастую разработчиков делать не то, что правильно, а то, что нужно сейчас, а так же, говоря языком для нас прошлого, в сжатые сроки "гнать план", спущеный сверху. Это не неожиданно для коммерческих фирм, которым не надо объяснять, что длительные проработки требуют длительных инвестиций с проблематичной отдачей, типа тех, что существовали в Советском Союзе. Поэтому вопрос, насколько пути, выбираемые промышленностью, неизбежны, для меня, например, вопросом так и остается. Он переводит разговор в другие сферы, на обсуждение которых статья не претендует.

Выводы

У американцев есть в общем-то неплохой (если им не злоупотреблять) обычай: сопровождать статью, выступление и пр. явной формулировкой того, что читатель или слушатель обретет, ознакомившись с тем, что ему предлагают, т.е. явной формулировкой возможной прагматики. Эта статья, к моему разочарованию, не содержит четких алгоритмов, имеющих читателя как входной параметр. Тем не менее, и она не сводится только к сетованию на несовершенство бытия. И поскольку не хотелось бы здесь целиком вставать на позицию a la Ходжа Насреддин, вроде "Пусть те, кто понял из этой статьи, что надо делать разработчикам, расскажет это тем, кто не понял", можно привести хотя бы несколько (явных) слов в отношении того, что делать.

Прежде всего следует заметить, что речь в этой статье вовсе не об Oracle. Просто Oracle8 - это удобная конкретизация некой типичной Системы Х, к которой сказанное относится с теми или иными вариациями. Oracle мне чуть более остальных СУБД знаком, и поэтому разговор более предметен. Что касается объектности и реляционности, то разработчики на Informix, Sybase, DB2 или Progress едва ли чувствуют себя более или же менее комфортно, нежели их коллеги на Oracle.

Реляционные системы - это классический пример чередования благих теорий нередко противоположной по духу реализацией, сохраняющей некоторые формальные признаки своей предшественницы. Об отрицательных моментах таких изменений говорилось выше. Здесь важно и другое: если реляционный подход фактически является средством моделирования, то SQL - это явный язык программирования. Он временами не лишен своего изящества, но работа на нем - это типичное программирование. В жизни SQL не может существовать без инструментов более высокого уровня, и такие инструменты действительно в определенное время появились. Например, для SQL-систем была приспособлена методика проектирования баз данных "сущность-связь" и имеется множество автоматизирующих работу по этой методике инструментальных систем систем (CASE разного уровня). У реляционного подхода есть своего рода "буква" ("правила Кодда реляционности" [10]) и "дух" (реляционные теории и трактовки [8]). И то и другое в SQL оказалось не соблюдено.

В объектном подходе к базам данных тоже есть своего рода "буква" (свойства объектных систем, например, в [1]) и "дух" (методологические принципы объектного подхода [12]). Есть опасения, что с интервалом в 20 лет метаморфоза того и другого произойдет уже с объектной сменщицей реляционных систем. Не случится ли так, что пользователи снова получат под знакомой оберткой (к которой они оказались приучены внушением) не соответствующее обертке содержание? Вместо инструмента моделирования, инструмент программирования? Безотносительно к тому, слишком ли идеалистична теория, или груба реализация, неразличение расхождений между одним и другим вряд ли благотворно отразится на разработке.

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

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

Благодарности

Автор благодарен главному редактору журнала Oracle Magazine/Russian Edition А. Резниченко (более известного как главного редактора бывшего журнала Мир Oracle), без которого эта статья не появилась бы, и Е. Зиндеру, давшему ряд полезных советов относительно текста.

1. Кто разумно смотрит на мир, на того и мир смотрит разумно. Гегель.
2. Статья писалась осенью 1997 года, и в январе 1998 Oracle8 действительно поставлялась у нас в стране.
3. Прилагательное "таблоидный" в случае определенной категории компьютерной прессы не совсем верно квалифицирует действительность.
4. Не составляющий секрета перечень противоречия SQL Коддовской реляционности можно было бы естественно начинать с того, что результат выборки в SQL не обязан быть реляционной таблицей.
5. Отсутствует, например, операция деления ("какие студенты посещают все курсы?") или разбиения ("какие пять служащих в отделе наиболее оплачиваемы?"), поневоле порождающие соревнования в искусстве написания SQL-запросов (см. дискусии в Интернете и заметки в журналах).
6. В одном известном мне коллективе разработчиков бытовало высказывание "Если бы это было просто, то было бы давно уже сделано".
7. Мне кажется, что проведение этой границы - и есть слабое место такого подхода. Ведь всю прикладную область можно смоделировать и реляционно, и объектно, но где методика проведения границы? Кроме того, такая граница имеет и некоторые технические трудности. Возможно, что вытекающие из этого неприятности и привели к тому, что, как утверждают, в последнее время Дейт переменил свою точку зрения на объединение двух способов моделирования, переместив ее в область скепсиса. С другой стороны, неприятностей не возникает, если на реляционную систему действительно смотреть как на интерфейс работы с объектами. Нужно еще учесть, Дейт - реляционный пурист, а следует различать теорию и практику.
8. По некоторым утверждениям, наследуемость будет реализована в версии 8.1 СУБД Oracle.
9. На обратную запись чисел в европейских языках, скалькированную из арабского, где она является прямой, обратил внимание в 80-х годах В. И. Филиппов.
10. В большинстве сетевых систем связи между объектами базы организовывались прямыми системными (внутренними) ссылками, и поэтому, когда объект перемещался в процессе реструктуризации на другое место в памяти (например, на другой блок, в результате своего роста при добавлении новых полей), требовалось найти все ссылки на него и их поменять, что очень неудобно. В SQL же -системах, если не принимать во внимание индекс, не являющийся реляционным моделирующим средством, ссылки делаются явно по значению атрибутов объекта, и поэтому не зависят от физического расположения объекта в памяти; при перемещении объекта их нет нужды менять. Индекс тоже не сильно осложняет дело, так как вход в него осуществляется по значению. Таким образом, легкость реструктуризации данных перевесила преимущество более эффективного доступа по прямым ссылкам, которым СУБД с сетевой моделью обладают, по отношению к SQL-СУБД, и в наше время.
11. Представляется, что для систем, обладающих известным набором четырех (или трех) признаков, более подходяще прилагательное объектный, нежели традиционное объектно-ориентированный. Объектно-ориентированный - это более мягкая форма, годная для описания систем, в которых какие-то из этих признаков не реализованы, или недореализованы. Например, объектно-ориентированной системой в этом смысле является MS DOS (она же - экспертная система, система искуственного интеллекта и т.д.).

Литература