Управление проектами - статьи

         

Быстрые методы для объектных баз данных


Скотт Амблер, Ambysoft Inc.,

Перевод -

Предисловие переводчика

Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала www.odbms.org (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).

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

Автор выдвигает три тезиса:

  1. технологическое несоответствие объектной технологии, на которой, в основном, базируется быстрая разработка, и технология реляционных баз данных;

  2. культурное несоответствие объектных разработчиков и специалистов, называемых автором “профессионалами в области данных”;

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

Что касается первого тезиса (technology impedance mismatch), то именно он лежал в основе , опубликованного в конце 1990-х и способствовавшего в то время развитию технологии объектно-ориентированных баз данных.
Тогда под несоответствием понималось, главным образом, серьезное различие в системах типов, поддерживаемых в языках программирования и реляционных (SQL-ориентированных) СУБД. С той поры прошло уже много лет, и в современном стандарте языка SQL (и основных реализациях РСУБД) поддерживается очень развитая система типов (во многом схожая с системой типов языка Java). Поэтому об этой разновидности технологического несоответствия говорить уже не приходится, и автор напирает на несоответствие по причине потребности в “объектно-реляционном” отображения, если разработка ведется в объектной технологии, а базы данных используются реляционные. Но и об этом нужно говорить более точно и аккуратно. У языка SQL имеется своя объектная модель, и SQL-ориентированную базу данных (по крайней мере, если использовать IBM DB2 или Oracle) можно спроектировать и использовать в объектном стиле. Так что, похоже, что в действительности речь идет о том, что при использовании в быстрых методах языка SQL нужно хорошо знать этот язык, а быстро узнать его у агилистов не получается.

Со вторым тезисом до сих пор мне сталкиваться не приходилось. По-видимому, “профессионалами в области данных” автор называет специалистов, которые умеют производить логическое и физическое проектирование баз данных. Мне всегда казалось, что при создании приложения, для которого создается собственная база данных, должен вестись единый проект, поскольку особенности конструкции базы данных должны соответствовать общим требованиям к приложению. Какой подход выбирается для реализации всего проекта – это вопрос предпочтений проектной группы. И вот выясняется, что в группе, выполняющей проект быстрыми методами, проектировщики реляционной базы данных не вписываются в коллектив разработчиков. Очень может быть, что автор руководствуется своим личным опытом, но приводимые им доводы не очень убедительны. Фактически он утверждает, что “профессионалы в области данных” не хотят (или не могут) пользоваться быстрыми методами и поэтому нужно отказаться от реляционных баз данных и перейти на использование объектных баз данных (для разработки которых, по всей видимости, профессионалы не требуются).





Мне кажется, что этот тезис открывает простор для дискуссии (и это одна из причин, по которой мы решили опубликовать перевод статьи Амблера).

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

В конце статьи, наконец, выясняется, к чему ведет автор. Около года тому назад компания db4objects объявила о выходе своей объектно-ориентированной СУБД db4o, доступной с исходными кодами (система написана на языке Java) по лицензии GPL. Вернее, компания придерживается подхода двойного лицензирования: для клиентов, желающих использовать систему для построения коммерческих приложений, обеспечивается специальная коммерческая лицензия. По этому поводу (как и в случае MySQL) разработка системы ведется исключительно силами сотрудников компании. Суть последнего раздела статьи Амблера в этом контексте сводится к тому, что использование db4o при быстрой разработке приложений баз данных снимает все противоречия и делает жизнь агилистов счастливой. Дай Бог, чтобы это так и было! Но только у меня имеются сомнения.

Я не слишком глубоко познакомился с техническим устройством db4o, но у меня уже создалось впечатление, что серьезных технологических новшеств в этой системе нет. Подобно тому, как когда то разработчики одной из самых успешных объектно-ориентированных СУБД Object Store начинали свой проект с полной привязки с среде языка C++, разработчики db4o ориентируются на среды Java и .NET. Как и раньше, основными козырями системы объявляется возможность сохранения в базе данных объектов произвольно сложной структуры, с которыми можно работать так же, как если бы они создавались в соответствующей программной среде во время выполнения приложения.


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

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

Предисловие получилось несколько длинноватым, но мне хотелось предостеречь читателей от слишком больших ожиданий, которые могут появиться после прочтения статьи агилиста-энтузиаста Амблера. Надеюсь, что в совокупности с этим текстом статья окажется более понятной и полезной.

Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.



В этой статье приводится обзор набора быстрых методов для разработки программного обеспечения, ориентированного на работу с данными. В большинстве работ, посвященных этому предмету, в частности, в моих книгах Agile Database Techniques (John Wiley Publishing, 2003) и Database Refactoring (Prentice Hall PTR, January 2006), предполагается использование объектной технологии, например, Java или C# в клиентской части приложения и технологии реляционных баз данных, например, Oracle или DB2 в серверной части. К сожалению, по причинам наличия несоответствия между объектной и реляционной парадигмами и отсутствия в настоящее время соответствующего инструментария, возможности применения быстрых методов здесь ограничены. Как вы увидите, гораздо легче применять быстрый подход при использовании технологии объектных систем управления базами данных (ОСУБД).

Прежде всего, обсудим методы быстрой разработки, которые следует применять при разработке баз данных. Эти методы включают следующее:


    Рефакторинг


  1. Быстрое моделирование


  2. Постоянное регрессионное тестирование


  3. Конфигурационное управление


  4. «Песочницы» (sandbox) разработчиков



Содержание раздела