10 февраля в редакции PC Week/ RE прошел круглый стол, посвященный перспективам развития реляционных и объектных СУБД. В нем приняли участие представители компаний: Александр Гвоздев и Ховард Залкин (Informix), Михаил Елашкин (Oracle), Дмитрий Носов и Андрей Чернышев (“Информ Икс”); представители фирм-разработчиков: Дмитрий Безруков (“Форс”), Валерий Мазнев (“Галактика”), Константин Сунцов (“АйТи”); независимые эксперты: Сергей Кузнецов (журнал СУБД), Владимир Пржиялковский (ВЦ РАН), а также сотрудники PC Week/RE - ведущая Елена Монахова, научный редактор отдела СУБД Александр Ливеровский и обозреватель Сергей Бобровский.
Реляционный тупик?
Елена Монахова: Есть в огромном компьютерном мире области, по сей день окутанные тайной. Речь идет вовсе не о тех секретах, которые стремятся скрыть до поры до времени разработчики, дабы их не обогнали конкуренты, а о технологиях, появившихся уже сравнительно давно, но до сих пор воспринимающихся как место только для избранных. Таковы, на наш взгляд, объектные СУБД - разговоров вокруг них много, но все время остается впечатление, что их апологеты чего-то недоговаривают и даже намеренно утаивают. Чтобы подтвердить (или опровергнуть) собственные впечатления, научные редакторы PC Week/RE пригласили в редакцию известных российских специалистов в области СУБД на круглый стол: “Реляционная и объектная модель данных. Как сделать правильный выбор?”.
Встреча, как нам кажется, удалась. Прочитав подготовленный по ее следам материал, вы сможете тоже окунуться в эту дискуссию и задать волнующие вас вопросы из области проектирования и администрирования СУБД по адресу: editorial@pcweek.ru.
Андрей Чернышев: Тезисы моего выступления умышленно будут достаточно резкими - чтобы “зажечь” присутствующих.
Итак: модель данных оказывает существенное влияние на технологии в целом, вплоть до интерфейса пользователя; реляционная модель была ошибкой и продолжает оказывать дурное влияние на развитие баз данных (БД); объектная модель данных и соответствующие инструменты для создания приложений легко реализовать в существующих средах, для этого не надо самим разрабатывать СУБД. Такая практика существует и успешно применяется.
В свое время, изучая философию, я пришел к выводу, что БД - очень интересная область знаний. Я много раз перечитывал труды Кодда (Э. Кодд предложил в 1970 г. реляционную модель данных. - Прим. ред.), Чена (П. Чен придумал ER-нотацию “сущность - связь”, на основе которой строятся сегодня многие CASE-системы. - Прим. ред.), большое влияние на меня оказали работы отечественных специалистов. Хотя реляционных СУБД тогда еще не было, уже в те годы у меня сложилось впечатление, что математика не выполнила возложенной на нее задачи, и я пришел к выводу, что реляционную модель нельзя использовать ни для каких приложений вообще.
В 1985 - 1986 гг. объектная модель данных уже сформировалась, и я не мог понять, почему не реализована эта нормальная модель - объекты, явные семантические связи между ними, отношения “многие ко многим”, как есть в жизни. Потом закрутилась машина реляционных СУБД, а сейчас опять начали возвращаться к объектам.
Давление реляционной модели ощущалось с момента ее появления. Когда читаешь Чена, то думаешь - это нормальная модель данных, ее бы сразу отразить и в логической модели. А потом чувствуешь, что и на него давит “перспективность реляционной модели на ближайшие 20 лет”. В результате так и получилось. Появились нотации IDEF1X и др., в которых модели “сущность - связь” служили мостиком к реляционной модели.
Подчеркну, что я говорю здесь исключительно о моделях данных. Не надо сейчас вести речь об объектно-ориентированном программировании.
Е. М.: Итак, задание присутствующим: опровергнуть или подтвердить это мнение. Кроме того, хотелось бы услышать определение - что такое объектная модель данных.
Сергей Кузнецов: Я могу утверждать абсолютно точно - объектной модели данных не существует. Существует модель, используемая компаниями Informix, IBM, существует модель, которую применяете вы, но нет общей объектной модели. Можно говорить о метамодели объектов, о некоем наборе средств, описывающих нечто конкретное, применяемое нами в конкретных технологиях. Об объектной технологии говорить можно, нужно и полезно. Об объектной модели говорить очень хотелось бы (т. е. дать четкий конкретный набор понятий, который описывает родовые сущности систем, основанных на этой модели), но пока не получается.
Мы подразумеваем очень разные вещи под словами “объект”, “тип”, “класс”, “атрибут”, “связь”. Это все очень плохо формализуется. Вместе с тем, если говорить про объектные технологии, нельзя разделять объектное проектирование и объектное программирование. Эта проблема комплексная, никуда от нее не деться.
А. Ч.: Значит, проблема заключается именно в формализации?
С. К.: Формализация сводится к тому, что привлекается аппарат алгебраической теории категорий, а это самая абстрактная алгебра из всех, какие только есть. Можно говорить, что Кодд допуcтил ошибку, которая повергла человечество в упадок, но Кодд сделал понятную вещь, и это самое главное, что нам дают реляционные БД.
А. Ч.: При чем здесь математика и формализация? Реляционная модель не соответствует жизни.
С. К.: Это другой вопрос.
Ховард Залкин: Я сейчас работаю в Informix, а раньше работал в фирме, которая продавала Informix, и мне больно слышать, что реляционные базы данных не имеют никакой связи с реальной жизнью. Одно из преимуществ реляционной базы для прикладных программистов состоит в том, что не надо задумываться, где физически располагаются данные. Важно, чтобы пользователь мог сосредоточиться на прикладных возможностях системы, не заботясь о том, как управлять памятью, как хранятся данные.
С одной стороны, объектная модель является естественной моделью окружающего нас мира. С помощью связей, несущих смысловую нагрузку, можно строить сколь угодно сложные структуры данных. С другой стороны, из-за этой сложности теория объектных баз данных практически не разработана.
Показательно, что для объектных БД существует промышленный стандарт ODMG 2.0. Он допускает использование java-объектов и позволяет описывать структуру базы на абстрактном уровне, что является несомненным преимуществом объектного подхода, в то время как работа с реляционными СУБД сегодня немыслима без использования SQL.
Практика - критерий истины
Александр Гвоздев: Если мы хотим обсуждать эти вопросы, нам нужно иметь за столом и Кодда, и Чена, и Стоунбрекера. На вопрос, почему Informix избрала именно такой подход, ответить очень сложно. Я разговаривал с нашими разработчиками, по их мнению, преимущества реляционного подхода в том, что благодаря ясному математическому аппарату оптимизатор и все внутренние механизмы наших СУБД программируются достаточно четко, ясно и в приемлемые сроки. Поэтому критерием здесь в какой-то мере может служить практика. Если подавляющее большинство современных СУБД построено по реляционной модели, это означает, что она имеет свои преимущества.
Константин Сунцов: Одна из причин, по которой ER-модель победила иерархические модели, состоит в том, что она позволяет достаточно просто перестраивать БД. Не получается на практике, чтобы, единожды создав базу, сразу внедрить ее у заказчика - базу постоянно приходится модернизировать (я могу согласиться с тем, что это происходит из-за плохого моделирования структуры БД, хотя в этом случае что такое хорошо и что такое плохо определить трудно). Поэтому коммерческие РСУБД данных имеют оптимизатор запросов, который способен частично компенсировать последствия некачественного проектирования.
По поводу применения реляционной и объектной БД. Не стоит их противопоставлять друг другу. Реляционные базы данных замечательно ведут себя в связках “один ко многим”, и большое число бизнес-данных укладывается в эту схему. Другое дело, если данные усложняются, например при обработке HTML-страниц.
Простота РСУБД общеизвестна. Их легко разрабатывать благодаря развитому математическому аппарату, реляционные базы быстро модифицируются, и это качество РСУБД незаменимо для разработчиков корпоративных систем. Однако очень трудно эффективно спроектировать БД для большой прикладной задачи, мысля в рамках реляционной теории, и одновременно написать быстродействующий программный код. Другой вопрос, способны ли объектные базы данных снять это противоречие. Надо подождать, пока появится больше объектных и объектно-реляционных СУБД, а их число неуклонно растет. Кроме того, существует огромный рынок настольных СУБД для конечных пользователей-непрофессионалов, работающих с небольшими БД. Реляционная модель им не всегда понятна.
Не забывайте про интерфейс
К. С.: Ранее был приведен такой постулат: модель данных определяет пользовательский интерфейс. Я с этим не согласен - эти понятия обязательно надо разделять, т. е. должно быть некое промежуточное звено. В противном случае вы не получите гибкого решения.
А. Ч.: Объясняю, почему я настаиваю на том, что модель данных определяет всю технологию, которая используется при разработке приложений. Это известные споры между сторонниками объектной и реляционной моделей, которые были изложены в известных манифестах 1989 и 1991 гг. Второй манифест назывался “СУБД 3-го поколения”, его авторы говорили, что “в результате этих споров получается то, что нельзя назвать реляционной моделью, но это же совершенно естественно!”.
Например, мы в своей системе поддерживаем как обычные функциональные интерфейсы, так и объектные - когда пользователь видит меню доступных ему объектов, а не функций. Если меняется структура данных, добавляется или удаляется объект, интерфейс остается прежним. Поэтому, на мой взгляд, модель данных определяет всю технологию разработки приложений и никакого противоречия здесь нет.
Должна ли модель данных определять пользовательский интерфейс? Сторонники реляционной модели считают - нет, может быть, потому, что программировать интерфейс при работе с реляционными структурами неудобно. Но практически все сегодняшние РСУБД - это мощные технологические комплексы со своими средствами разработки конечных приложений, поддерживающих на клиентских местах самые разные ОС. Для обеспечения переносимости создателям РСУБД волей-неволей приходится привязывать интерфейс к своим моделям данных.
Теория или искусство
Дмитрий Безруков: Говорить о том, что реляционная модель данных устарела или вредна, как-то бессмысленно. Все ею пользуются. Она имеет под собой твердую теорию, для нее легко делать оптимизатор и удобно применять непроцедурные языки. Чем она плоха? Тем, что при ее использовании “плясать” приходится от данных. Объект - это таблица, а объекты реального мира отражаются N-табличками и связями между ними, что, естественно, неудобно. Объектно-ориентированная модель данных и объектно-ориентированные языки программирования не имеют под собой никакой теории. Это, прежде всего, - способ мышления, это - искусство.
Реляционная модель хороша для бизнес-задач. Но сейчас эта область сильно усложнилась, и поэтому Oracle и Informix придумали свой объектно-реляционный подход, который ничего общего с объектно-ориентированным подходом не имеет. Oracle теперь реализует поддержку графического языка моделирования UML в своей CASE-системе - это попытка внести объектность в реляционную модель. И вот SQL 3, с одной стороны, базируется на SQL, а с другой - в нем есть чисто объектные дополнения. Из-за несоответствия парадигм писать на нем трудно, хотя он и работает с объектами.
Е. М.: Попробуйте, пожалуйста, дать определение объектной модели данных.
Д. Б.: А его нет!
Михаил Елашкин: Почему появились реляционные базы? Потому, что люди платили деньги за их удобство. А согласятся ли разработчики, которые здесь присутствуют, переписывать все свои приложения на объектные БД?
Моя точка зрения такова: сделать основной технологию объектно-реляционных БД сегодня невозможно. Теории объектно-реляционных баз нет, существует некоторая рабочая схема ее реализации. Она имеет ряд достоинств и ряд недостатков. К тому же рынок не готов ее принять, да и предложить пока нечего. Есть Universal Server - сервер, поддерживающий помимо стандартных типов данных также видео, текст, изображение. Вот это люди согласны покупать и покупают в достаточно больших количествах. А возможность строить собственные объектные схемы привлекает их гораздо меньше.
Александр Ливеровский: Так из этого объектного направления выйдет когда-нибудь наука или все останется на уровне импровизации?
А. Ч.:А разве была какая-то теория в иерархических моделях данных?
С. К.: А иерархических моделей и не было.
А. Ч.: Тогда почему объектные базы не могут жить, как живут иерархические СУБД?
С. К.: Они могут жить, только живется им плохо. Но у объектно-реляционных СУБД есть шанс именно потому, что за ними стоят три монстра (имеются в виду, по-видимому, Oracle, Informix, IBM. - Прим. ред.).
А. Ч.: Я еще с одной стороны попытаюсь подойти к моделям и проектированию данных. Разве при проектировании реляционной БД не играет роли искусство проектировщика?
К. С.: Как правило, в средней базе данных не менее 800 сущностей и работать с таким объемом информации человеку трудно. Естественно, проектирование - искусство, и, как во всяком искусстве, неважно, какую модель вы создаете, да и вообще чем вы занимаетесь.
Реляционная теория сама по себе хороша и эффективна, но она плохо отражает связи реального мира. Для объектных СУБД такую теорию пока не придумали, но зато они более понятны и естественны. Но нужна ли разработчикам эта естественность? Пока основная область применения СУБД - бизнес-приложения, схемы данных в которых достаточно абстрактны, их трудно формализовать в любой модели. Здесь сказывается привычка и многолетний опыт использования РСУБД, когда проектировать реляционную БД легче, чем объектную.
Что мешает программисту?
Валерий Мазнев: Как происходит процесс разработки? Сначала готовятся структуры данных, после проектировщиков за дело принимаются программисты, и выясняется, что структуры данных вступают в противоречие с быстродействием программы. То, что хорошо спроектировано, не очень хорошо алгоритмизируется, и наоборот. То есть реляционные базы данных очень плохо соотносятся с обычными языками программирования. Чтобы программировать, надо обладать одной логикой, чтобы строить запросы - другой. У реляционной модели очень хорошая теория, но на практике все с этой теорией и борются. Оптимизатор хорош просто потому, что мы не можем нормально спроектировать систему.
С. К.: Единственное, на чем сходятся разработчики объектно-ориентированных систем - это расширение SQL (OQL). Но SQL - не наука, а лишь достаточно кривой язык, критиковать его можно с самых разных позиций.
М. Е.: Проблема в том, как состыковать процедурный язык с непроцедурным.
Дмитрий Косов: На мой взгляд, SQL не лучший способ получения данных из базы. Обрабатывать данные с помощью SQL трудно, программисты начинают использовать курсоры, которые ничего общего с SQL не имеют. То есть у РСУБД - проблемы несовместимости подходов к программированию и хранению данных. Объектные базы - это хороший компромисс между хранением и обработкой, ведь данные нужны только для того, чтобы их можно было быстро и удобно обрабатывать.
А. Ч.: То, что данные должны быть отделены от программ, совершенно естественно, и противоречия здесь нет. Ведь я сразу предложил отбросить объектно-ориентированное программирование.
К. С.: Но без программирования законченного решения не бывает.
Где сейчас применяются объектные базы? Одна из областей - объектные репозитории. Одно время их строили на РСУБД. Но тут было правильно сказано - очень трудно программистам, которые работают с объектными средствами, мыслить в ER-модели. В “АйТи” использовались разные системы, поддерживающие IDEF-нотации, и было абсолютно противоестественно моделировать программный код и в то же время работать с БД. Может быть, поэтому репозитории на основе старых реляционных баз не прижились и их постепенно перенесли на объектные СУБД. В репозитории обычно хранится сам объект, т. е. его описание, методы.
Объектные базы применяются в качестве брокеров объектных запросов (ORB, Object Request Broker), когда объектная база поставляет готовый объект. Не нужно путать ORB - поставщик объектов - с репозиторием, который служит для хранения и описания объектов.
Мы столкнулись с объектными БД года три назад, когда пытались внедрить у себя базу данных Illustra, применить ее как средство коллективной разработки объектов. Не все там так просто. Правильно было сказано, что работа с объектами - это искусство. В жизни, в бизнес-процессах выделить, что является объектом, очень трудно. Мы создали бухгалтерское приложение - оно прекрасно взаимодействует с реляционной базой, но конечным продуктом является документ, отчетная форма, которая отлично ложится в LotusNotes. То есть на LotusNotes очень трудно написать бухгалтерское приложение, но он хорошо функционирует с документом как с единым целым.
Мы с интересом отнеслись к выходу Oracle 8.0, так как разрабатываем приложения на Oracle. Гибридное решение (Oracle + поддержка объектов) - для нас вполне естественное решение. Но, к сожалению, оно сейчас дорого. Это одна из причин, почему мы не перешли на подобные БД. По зарубежным данным, рабочее место, построенное на основе объектной БД, стоит около 2,5 тыс. долл. Нельзя забывать и то, что мы действуем не в вакууме. У заказчика уже есть отдел разработчиков, и часть задач мы всегда перекладываем на их плечи, а они имеют дело с реляционными базами, и объяснить им, что такое объект, очень непросто.
На мой взгляд, естественно, объектные СУБД имеют право быть, но это не панацея от всех бед. У них есть своя ниша, а у реляционных СУБД своя.
При разработке крупных систем проектировщикам и программистам нередко бывает трудно понять друг друга. Проектировщику при построении базы надо учитывать, какие конкретно запросы будут применять программисты, а программистам - понимать принципы реляционной теории при обработке запросов. Проблема скорее не в недостатках объектного или реляционного подходов, а в отсутствии специалистов.
Язык OQL принес объектным технологиям только вред. Он на 90% совместим с SQL, который неудобен даже при работе с РСУБД, и не позволяет использовать всей потенциальной мощи объектного подхода.
Больной скорее жив, чем мертв
Владимир Пржиялковский: Есть США, где производят какие-то программные продукты. Есть мы, потребители этих продуктов. Надо понять - то, что там разрабатывают, мы и будем потреблять.
Почему возникла реляционная модель, - загадка. То, что она больна, было ясно с самого начала. В чем роль теории, сказать трудно, так как ее можно придумать и для сетевой модели данных. Основная причина победы реляционной БД - возможность ее легкой реструктуризации. Это решающий момент, потому что перестраивать сетевую базу данных очень трудно. В то же время реляционная модель - инструмент очень сомнительный: возникает много трудностей с модельным описанием и при взаимодействии с пользователем.
Сетевая модель была очень хорошо проработана комитетом КОДАСИЛ, более развита, чем реляционная, но она стала слишком сложна для программистов. Но поскольку сегодня появился как бы некоторый реляционный тупик, то все эти искания опять всплыли - возник объектный крен, а это в значительной степени возврат к старому. Чем-то старое приукрашено, чем-то надстроено. Объектно-реляционные СУБД еще не созрели, так как с ними сейчас сложно иметь дело, поэтому их с трудом воспринимают разработчики. СУБД - не только модель, это технологический комплекс, который включает в себя режимы, скажем так, эксплуатации, и объектная часть пока не готова к уровню эксплуатации, который достигнут для реляционных систем. Поэтому можно сказать, что на развитие СУБД в ближайшем будущем никакого влияния эти системы не окажут.
К. С.: Я согласен со сказанным по поводу эксплуатации. Но мы используем объектно-ориентированные языки программирования, нам нравится этот подход, и не только нам. Это не просто мода, объекты снимают многие проблемы и дают устойчивое решение.
М. Е.: Создание объектных СУБД требует серьезных капиталовложений. Объектная идеология нужна для больших хранилищ данных. Но понадобятся ли они рынку?
А. Г.: Когда Михаил говорит про большие деньги, это правда. Всегда выигрывают преемники последователей. То есть если не будет движения, не будет риска, то не будет и всего остального. Моя точка зрения - проблемы, которые возникли у Informix после того, как очень много средств было вложено в Universal Server, это скорее проблема маркетинга. Продукт был заявлен очень рано. Но 20 января Informix зарегистрировал тысячную организацию, которая купила Universal Server. По мнению Informix, необходимо время, чтобы идеи, возможности и продукты, которые строятся на Universal Server, были востребованы массами. Реально почти все наши партнеры сейчас находятся в состоянии активной разработки систем на Universal Server.
Преимущества объектно-реляционного подхода в том, что вы можете переходить на объекты постепенно. Любое приложение, написанное с помощью старой системы, полностью работает на новой версии. Наши крупные партнеры - PeopleSoft, SAP - создают свои внутренние модули с использованием концепции абстрактных типов данных - это то, что дает Universal Server. Я считаю, что в ближайшее время никакой революции в области СУБД не произойдет, скорее всего, будет развиваться то, что предлагают Oracle, Informix, IBM.
В. П.: Политика больших компаний достаточно своеобразна. Были попытки свести все к идиллическим отношениям с пользователями (выпускаем только то, что им надо). Но это не всегда возможно, это - бизнес, он живет по своим законам. Я не большой знаток этих законов, но я знаю несколько нововведений Oracle, которые внедрялись насильственно. Например, когда Oracle переходила с символьных форм на графические. Правда, пользователь сам не всегда понимает, что ему нужно. И сейчас никто не даст гарантии, что те шаги, которые делаются по включению объектности в РСУБД, к чему-то приведут. Не исключено, что они будут напрасными, потому что объектный подход тоже по-своему болен. Очень сильно возрастет трудоемкость проектирования схемы данных в объектной базе. Если в реляционной модели можно идти на какие-то уступки - что-то можно потом переделать, то в объектном подходе это малопозволительно, потому что переделки становятся ужасно болезненными.
Рынок объектных и объектно-реляционных БД растет достаточно активно. Поддержка объектного подхода в той или иной степени реализуется практически во всех СУБД. Поэтому ОСУБД для нас разработают обязательно, и стоить они будут, как сегодняшние РСУБД. За инвестициями дело не станет - объектная идеология сегодня настолько популярна, что характеристика “объектный” считается необходимым условием продвижения средства разработки на рынке.
Интересны объектные технологии Microsoft. Сотрудников этой фирмы (как и представителей IBM, которые создают объектные расширения DB2) на круглом столе явно не хватало. Характерно, что разработчики, основные покупатели тяжелых СУБД, используют решения Microsoft.
Недостатков у объектного подхода немало. Не меньше их, впрочем, и у реляционного подхода. Разработчиков не устраивает сложность проектирования объектных БД и трудность общения с пользователями на реляционном языке. Но недостатки РСУБД хорошо известны, и с ними остается только мириться. А возможности объектных СУБД пока изучены плохо. Но необходимость по крайней мере присовокупления приставки к своим СУБД термина “объектная” (или “объектно-реляционная”) осознали все крупные компании.
Рано или поздно какую-нибудь удачную - именно благодаря отсутствию теории - реализацию ОСУБД по достоинству оценят и разработчики.
