Недавно в нашей организации очень насущным стал вопрос командной разработки (около 10 человек) схемы данных для БД Oracle. Работали мы по-старинке с помощью небезызвестного продукта Erwin семейства 3.5.x и до поры до времени были вполне удовлетворены его возможностями, разместив файлик в централизованной системе управления версиями и блокируя его по мере надобности, тем самым избежав коллизий параллельной разработки. Но всё течёт, всё меняется, команда разрастается, да и XXI век на дворе, вот и решили мы воспользоваться более современными средствами. Собственно ниже представлен рассказ о процессе перевода схемы в новый формат (хотя и того же производителя) и организации средств коллективной разработки и поддержки версионности, разбавленный рассуждениями о продукте в целом и паттернами использования его в нашей работе в частности. Без подводных камней описанный процесс не прошёл, так что возможно опыт подобного перехода будет кому-то полезен.
План повествования:
Поддержание порядка в схеме БД — это важно, тем более если идёт живая разработка, количество таблиц и их взаимосвязей разрастается, и никто не может уже просто удержать в голове всю иерархию структур. Это понятно всем, ну понятно было и нам, когда мы приступили к разработке под Oracle. Дело было давнее, и в фаворе был инструмент для проектирования от тогда ещё фирмы Platinum под названием Erwin 3.5.2. Этот инструмент изучался (кстати, до сих пор изучается — узнавал у знакомых студентов) на компьютерных специальностях в университетах и на курсах разработчиков БД. Именно эта версия получила некоторую популярность, ну и надо сказать вполне оправданную. Будучи ровесником Windows'98 он вполне работоспособен, справляется со схемами приличных размеров, гибко настраивается благодаря макросам и генерирует корректные скрипты под современные версии Oracle, хотя рассчитан всего на 8 версию, справляется, кстати, и с reverse engeneering с базы. У нас он использовался до последнего времени, и особых сбоев замечено не было. Однако минусы есть. Во-первых, он почему-то совсем не дружит с сетевыми принтерами. Если в качестве принтера по-умолчанию настроен сетевой принтер, то первоначальная загрузка схемы будет очень медленной, если принтер подлючён напрямую к машине или используется виртуальный принтер, та же схема загружается значительно быстрее. Во-вторых, как я уже упоминал, рассчитан он на работу с Oracle 8 (да и вообще выбор версий БД не особо там велик, MySQL или Postgree нет в принципе) и потому тонкая настройка структур таблиц под новые версии, например использование партиций, невозможна. В-третьих, поддержку командной разработки мы в нём настроить не смогли. Потенциально поддержка ModelMart уже есть в этой версии, но в своё время никто не озаботился (собственно команда то была в 2 человека), ну а позже его и не найти было как отдельный продукт. Опять же, особенностью средств ModelMart (сейчас зовётся Model Manager) является хранение схемы в БД, т.е. как дружат старые версии этого продукта с новыми версиями БД — это тот ещё вопрос. Остальные недостатки не являются определяющими, хотя конечно порой проявляют себя и весьма раздражают (например, поиск подмодели по названию возможен только по первой букве, причём по первому вхождению; поиск таблицы для добавления в подмодель возможен только по наименованию физического уровня, тогда как в отчётах, которые генерируются, отображается иногда только логический уровень; ограничение прав возможно только на уровне доступа к файлу схемы; нет выравнивания объектов по сетке и прочие нюансы).
Настал некий переломный момент, и появилась точная определённость в необходимости перехода на современную версию Erwin. Руководство даже согласилось купить продукт, ну а само собой никаких старых версий не продаётся. Но важным условием для перехода является необходимость поддержки всех старых наработок. Старые наработки — это один файл со всей схемой данных (примерно 20Mb и 7-м лет разработки). Мы всегда использовали Erwin сугубо для моделирования структур, и логика работы туда не попадает. Таким образом, не стоит задачи развернуть базу с нуля скриптом, сгенерированным из программы — для развёртывания новых инстанций служит эталонная база со структурами, логикой и всеми техническими настройками. Если бы мы хранили логику, проблема обновления версий появилась бы гораздо раньше, потому как pl/sql в восьмой версии и pl/sql в 10, это две большие разницы. В итоге удалось оттянуть момент. Так как нас интересуют только структуры и связи — чистим схему от разного «мусора» (при использовании reverse engeneering в схему попадают триггера, связанные с таблицей, их легко найти через отчёт Entity Reports->Entity/Trigger options), скачиваем с сайта разработчиков триал версии 7.3 «на попробовать» и ожидаем, что схема откроется в новом формате (на самом деле утрирую, конечно, никто не ожидал, что будет легко). Ан нет, формата ER1 третьей версии седьмая версия не видит.
Настала пора поругаться про форматы. Erwin 3.5.x хранит схему в одном файле формата .ER1 (плюс backup .BK1). Это такой закрытый двоичный формат, если открыть его на просмотр — ну знакомые буквы будут, но не более. Седьмая версия Erwin Data Modeler понимает некий формат .ER1, однако с примечанием, что это формат четвёртой версии, а не третьей. Вызвано это наверное тем, что именно с четвёртой версии продукт фирмы Platinum был перекуплен Computer Associates (или CA как они официально обозначаются сейчас). Приходится идти на хитрость, ибо Erwin 4.1.x официально никак не распространяется и никаких пробных версий не найти (и уж тем более не купить). Значит, с чистой совестью скачиваем пиратскую версию оттуда, где сможем найти. Вообще странно, что для такого известного и дорогого продукта компания CA не предусмотрела утилитку для конвертирования между форматами версий. Переконвертирование происходит в памяти непосредственно в момент открытия. Изначально файл занимал около 20 Mb, конвертирование заняло пару минут. После этой операции файл стал весить уже 60 Mb. Однако надо отдать должное, загружается это дело вроде бы быстрее, чем в третьей версии.
Затем устанавливаем Erwin Data Modeler 7.3 (в комплекте с Erwin Model Navigation 7.3), а затем отдельно Erwin Model Manager 7.3. Сама установка трудностей не вызывает, однако перед первым запуском ModelMart необходимо настроить БД, где будут храниться все объекты erwin-овской схемы. Об этом позаботилась фирма CA и в дистрибутиве есть два guid'а — нас интересует Implementation Guide (во втором, Administrator Guide ничего особо интересного кстати). Необходимо создать (у нас oracle — поэтому всё сказанное касается именно работы с этой СУБД) tablespace для хранения модели, индексный tablespace, роль пользователя, который будет производить инсталляцию моделей, пользователя администратора моделей (этому пользователю можно и выдать роль по инсталляции) ну и роль для пользователей Model Manager (кстати, надо не забыть выдать этим пользователям и dba). Собственно при первом запуске административной части Model Manager это всё и спросят — необходимо войти под созданным администратором, указать tablespace для данных и для индексов и подождать пока программа создаст необходимые для работы таблицы и процедуры. С инициализацией проблем нет, а вот при необходимости удалить созданные настройки (само собой экспериментировать не на рабочей же сразу версии) у меня возникла ошибка и тотальный глюк, после которого подключиться к Model Manager не удавалось с сообщениями об ошибке (такая же ерунда происходит и при попытке обновить лицензию — с триальной на рабочую, если модель уже создана в триальной). Полечилось следующим образом — удалил все объекты пользователя администратора моделей и запустил скриптик MMartInit.ora в SQL Navigator из папки с программой с режимом игнорирования ошибок. Что-то в этом скриптике повыполнилось, что-то нет, но после запуска админской консоли Model Manager программа смогла худо-бедно подключиться к базе и сообщила, что дескать у меня что-то есть, но повреждено и это в силах восстановить. После подтверждения с моей стороны структура таблиц заново пересоздалась и всё заработало. Надо бы поругать CA за этот момент: естественно перед покупкой столь дорогого продукта организация хочет опробовать весь бизнес-процесс заранее, благо триальные версии с полным функционалом доступны непосредственно от производителя. И конечно после того как всё настроено и опробовано, процесс обновления лицензий на полнофункциональные не должен вызывать никаких проблем.
Следует сказать несколько слов по поводу выбора базы для работы. Лучше создать новый экземпляр, ибо индексы разрастаются для больших моделей, а сами операции по управлению моделями довольно ресурсозатратны. Так наиболее критичным является удаление модели из библиотеки. Вообще у нас используется экземпляр БД с некоторой дополнительной нагрузкой кроме Model Manager, но конечно это не продакшен сервер.
Итак, все предварительные настройки выполнены. Следующим шагом будет перевод схемы в 7.x версию. Процесс этот на удивление очень долгий и очень требовательный к оперативной памяти. Однако, просто так оставить на ночь работы тоже не получится, т.к. Erwin периодически отчитывается о результатах работы и спрашивает всякие мелочи (например, старая схема работала с Oracle 8, а новая поддерживает Oracle 10/11, отсюда неминуемый вопрос от программы «Переведём на новый оракл, или выберем что-нибудь другое?», и прочее в таком духе). Так что, стоит запастись терпением. По итогам работы сформировался log-файл выявленных ошибок в схеме (у меня таких набралось не так много — несколько дублированных объектов и инвалид foreign key, что легко чинится после переконвертации). Надо отметить, что к валидации свежий Erwin относится очень серьёзно — нашёл разные косяки в духе «varchar(50» (отсутствие закрывающей скобки в определении типа), которые никак не были замечены ранними версиями. Итоговая схема заимела расширение .erwin и разрослась в размерах до 112 Mb. Итоговый прирост почти в шесть раз по сравнению с начальным размером. Загружается это дело средне по скорости, не быстро конечно, но не критично медленно.
Далее начинается то, ради чего всё и затевалось по большому счёту — перевод схему на хранение в БД и организация командной работы. Для этого, открыв файл схемы в Erwin, подключаемся к Model Manager под админским пользователем и выбираем пункт Save model. После выбора места объекта в иерархической схеме библиотек моделей происходит загрузка схемы в БД. Опять же всё предсказуемо — процесс не быстрый. Но рано или поздно он выполнится, и вот наша схема уже хранится в БД и готова к командной разработке. Однако первая же попытка открыть какую-либо подмодель из созданной модели (не забыв вначале закрыть файл, из которого модель создавалась, иначе ничего не получится) приводит к зависанию минут на 30. Это конечно не вариант. Подключаемся к БД и смотрим схему администратора моделей (допустим EADMIN, как в руководстве). Таблицы созданы, индексы созданы, но статистика по таблицам не собрана. Как результат: DBMS_STATS.GATHER_SCHEMA_STATS ('EADMIN'). Дальше разбираемся с таблицами. Собственно самыми большими являются две из них m7object и m7objectproperty. Как очевидно из названия: первая хранит объекты (собственно все сущности, таблицы, подмодели в иерархическом порядке), вторая их свойства. Посмотрев на данные таблицы свойств, я заметил достаточно много записей со значением «Imported from a previous version of ERwin.» в поле stringvalue. Можно и почистить, только аккуратно, размер сократится конечно не в разы, но всё же.
Исходная схема была разбита на множество подсхем (subject areas в нотации третьей версии), каждая такая подсхема может по идее открываться независимо. Но, блокировка возможна только на уровне схемы, это раз. При сохранении и слиянии изменений с репозиторием всё равно придётся подгружать схему целиком, это два. И, наконец, открытие всей схемы занимает столько же времени (и чуть больше памяти), чем открытие отдельной подсхемы, это три. Так что про возможность работы с отдельной подсхемой можно сразу же забыть. Итого имеем около 700 mb оперативки занятой на загруженную схему. Что-то пока всё безрадостно. Однако возможности конечно хороши — здесь и подробный мерджинг с репозиторием, и откат между сохраняемыми версиями, и фовард инжиниринг и реверс инжиниринг с базой, с другой схемой или с файлом, сохранение всех настроек сравнения и генерации скриптов прямо в схеме и прочее.
Минус один — скорость работы. Все махинации с базой и настройками позволили лишь слегка ускорить процесс. Помониторили работу с базой — все запросы примитивны (хотя и слегка нелогичны), но сами по себе таблицы большие. Попробовали обратиться к официальному дистрибьютору в России для консультации, обозначив видимые гипотезы проблем. В результате получили ответ, что универсального решения для проблем производительности при переводе старых моделей в Erwin новой версии нет. В итоге пока находимся на распутье между хорошей функциональностью и плохой производительностью, ещё продолжаем бороться, но уже смотрим на продукты конкурентов.
План повествования:
- Рассуждения о продукте, замечания на тему шаблонов использования, ругань на форматы.
- Подготовительные работы, шаманство в БД.
- Организация командной разработки, оптимизация быстродействия.
Рассуждения о продукте, замечания на тему шаблонов использования, ругань на форматы
Поддержание порядка в схеме БД — это важно, тем более если идёт живая разработка, количество таблиц и их взаимосвязей разрастается, и никто не может уже просто удержать в голове всю иерархию структур. Это понятно всем, ну понятно было и нам, когда мы приступили к разработке под Oracle. Дело было давнее, и в фаворе был инструмент для проектирования от тогда ещё фирмы Platinum под названием Erwin 3.5.2. Этот инструмент изучался (кстати, до сих пор изучается — узнавал у знакомых студентов) на компьютерных специальностях в университетах и на курсах разработчиков БД. Именно эта версия получила некоторую популярность, ну и надо сказать вполне оправданную. Будучи ровесником Windows'98 он вполне работоспособен, справляется со схемами приличных размеров, гибко настраивается благодаря макросам и генерирует корректные скрипты под современные версии Oracle, хотя рассчитан всего на 8 версию, справляется, кстати, и с reverse engeneering с базы. У нас он использовался до последнего времени, и особых сбоев замечено не было. Однако минусы есть. Во-первых, он почему-то совсем не дружит с сетевыми принтерами. Если в качестве принтера по-умолчанию настроен сетевой принтер, то первоначальная загрузка схемы будет очень медленной, если принтер подлючён напрямую к машине или используется виртуальный принтер, та же схема загружается значительно быстрее. Во-вторых, как я уже упоминал, рассчитан он на работу с Oracle 8 (да и вообще выбор версий БД не особо там велик, MySQL или Postgree нет в принципе) и потому тонкая настройка структур таблиц под новые версии, например использование партиций, невозможна. В-третьих, поддержку командной разработки мы в нём настроить не смогли. Потенциально поддержка ModelMart уже есть в этой версии, но в своё время никто не озаботился (собственно команда то была в 2 человека), ну а позже его и не найти было как отдельный продукт. Опять же, особенностью средств ModelMart (сейчас зовётся Model Manager) является хранение схемы в БД, т.е. как дружат старые версии этого продукта с новыми версиями БД — это тот ещё вопрос. Остальные недостатки не являются определяющими, хотя конечно порой проявляют себя и весьма раздражают (например, поиск подмодели по названию возможен только по первой букве, причём по первому вхождению; поиск таблицы для добавления в подмодель возможен только по наименованию физического уровня, тогда как в отчётах, которые генерируются, отображается иногда только логический уровень; ограничение прав возможно только на уровне доступа к файлу схемы; нет выравнивания объектов по сетке и прочие нюансы).
Настал некий переломный момент, и появилась точная определённость в необходимости перехода на современную версию Erwin. Руководство даже согласилось купить продукт, ну а само собой никаких старых версий не продаётся. Но важным условием для перехода является необходимость поддержки всех старых наработок. Старые наработки — это один файл со всей схемой данных (примерно 20Mb и 7-м лет разработки). Мы всегда использовали Erwin сугубо для моделирования структур, и логика работы туда не попадает. Таким образом, не стоит задачи развернуть базу с нуля скриптом, сгенерированным из программы — для развёртывания новых инстанций служит эталонная база со структурами, логикой и всеми техническими настройками. Если бы мы хранили логику, проблема обновления версий появилась бы гораздо раньше, потому как pl/sql в восьмой версии и pl/sql в 10, это две большие разницы. В итоге удалось оттянуть момент. Так как нас интересуют только структуры и связи — чистим схему от разного «мусора» (при использовании reverse engeneering в схему попадают триггера, связанные с таблицей, их легко найти через отчёт Entity Reports->Entity/Trigger options), скачиваем с сайта разработчиков триал версии 7.3 «на попробовать» и ожидаем, что схема откроется в новом формате (на самом деле утрирую, конечно, никто не ожидал, что будет легко). Ан нет, формата ER1 третьей версии седьмая версия не видит.
Настала пора поругаться про форматы. Erwin 3.5.x хранит схему в одном файле формата .ER1 (плюс backup .BK1). Это такой закрытый двоичный формат, если открыть его на просмотр — ну знакомые буквы будут, но не более. Седьмая версия Erwin Data Modeler понимает некий формат .ER1, однако с примечанием, что это формат четвёртой версии, а не третьей. Вызвано это наверное тем, что именно с четвёртой версии продукт фирмы Platinum был перекуплен Computer Associates (или CA как они официально обозначаются сейчас). Приходится идти на хитрость, ибо Erwin 4.1.x официально никак не распространяется и никаких пробных версий не найти (и уж тем более не купить). Значит, с чистой совестью скачиваем пиратскую версию оттуда, где сможем найти. Вообще странно, что для такого известного и дорогого продукта компания CA не предусмотрела утилитку для конвертирования между форматами версий. Переконвертирование происходит в памяти непосредственно в момент открытия. Изначально файл занимал около 20 Mb, конвертирование заняло пару минут. После этой операции файл стал весить уже 60 Mb. Однако надо отдать должное, загружается это дело вроде бы быстрее, чем в третьей версии.
Подготовительные работы, шаманство в БД
Затем устанавливаем Erwin Data Modeler 7.3 (в комплекте с Erwin Model Navigation 7.3), а затем отдельно Erwin Model Manager 7.3. Сама установка трудностей не вызывает, однако перед первым запуском ModelMart необходимо настроить БД, где будут храниться все объекты erwin-овской схемы. Об этом позаботилась фирма CA и в дистрибутиве есть два guid'а — нас интересует Implementation Guide (во втором, Administrator Guide ничего особо интересного кстати). Необходимо создать (у нас oracle — поэтому всё сказанное касается именно работы с этой СУБД) tablespace для хранения модели, индексный tablespace, роль пользователя, который будет производить инсталляцию моделей, пользователя администратора моделей (этому пользователю можно и выдать роль по инсталляции) ну и роль для пользователей Model Manager (кстати, надо не забыть выдать этим пользователям и dba). Собственно при первом запуске административной части Model Manager это всё и спросят — необходимо войти под созданным администратором, указать tablespace для данных и для индексов и подождать пока программа создаст необходимые для работы таблицы и процедуры. С инициализацией проблем нет, а вот при необходимости удалить созданные настройки (само собой экспериментировать не на рабочей же сразу версии) у меня возникла ошибка и тотальный глюк, после которого подключиться к Model Manager не удавалось с сообщениями об ошибке (такая же ерунда происходит и при попытке обновить лицензию — с триальной на рабочую, если модель уже создана в триальной). Полечилось следующим образом — удалил все объекты пользователя администратора моделей и запустил скриптик MMartInit.ora в SQL Navigator из папки с программой с режимом игнорирования ошибок. Что-то в этом скриптике повыполнилось, что-то нет, но после запуска админской консоли Model Manager программа смогла худо-бедно подключиться к базе и сообщила, что дескать у меня что-то есть, но повреждено и это в силах восстановить. После подтверждения с моей стороны структура таблиц заново пересоздалась и всё заработало. Надо бы поругать CA за этот момент: естественно перед покупкой столь дорогого продукта организация хочет опробовать весь бизнес-процесс заранее, благо триальные версии с полным функционалом доступны непосредственно от производителя. И конечно после того как всё настроено и опробовано, процесс обновления лицензий на полнофункциональные не должен вызывать никаких проблем.
Следует сказать несколько слов по поводу выбора базы для работы. Лучше создать новый экземпляр, ибо индексы разрастаются для больших моделей, а сами операции по управлению моделями довольно ресурсозатратны. Так наиболее критичным является удаление модели из библиотеки. Вообще у нас используется экземпляр БД с некоторой дополнительной нагрузкой кроме Model Manager, но конечно это не продакшен сервер.
Итак, все предварительные настройки выполнены. Следующим шагом будет перевод схемы в 7.x версию. Процесс этот на удивление очень долгий и очень требовательный к оперативной памяти. Однако, просто так оставить на ночь работы тоже не получится, т.к. Erwin периодически отчитывается о результатах работы и спрашивает всякие мелочи (например, старая схема работала с Oracle 8, а новая поддерживает Oracle 10/11, отсюда неминуемый вопрос от программы «Переведём на новый оракл, или выберем что-нибудь другое?», и прочее в таком духе). Так что, стоит запастись терпением. По итогам работы сформировался log-файл выявленных ошибок в схеме (у меня таких набралось не так много — несколько дублированных объектов и инвалид foreign key, что легко чинится после переконвертации). Надо отметить, что к валидации свежий Erwin относится очень серьёзно — нашёл разные косяки в духе «varchar(50» (отсутствие закрывающей скобки в определении типа), которые никак не были замечены ранними версиями. Итоговая схема заимела расширение .erwin и разрослась в размерах до 112 Mb. Итоговый прирост почти в шесть раз по сравнению с начальным размером. Загружается это дело средне по скорости, не быстро конечно, но не критично медленно.
Организация командной разработки, оптимизация быстродействия
Далее начинается то, ради чего всё и затевалось по большому счёту — перевод схему на хранение в БД и организация командной работы. Для этого, открыв файл схемы в Erwin, подключаемся к Model Manager под админским пользователем и выбираем пункт Save model. После выбора места объекта в иерархической схеме библиотек моделей происходит загрузка схемы в БД. Опять же всё предсказуемо — процесс не быстрый. Но рано или поздно он выполнится, и вот наша схема уже хранится в БД и готова к командной разработке. Однако первая же попытка открыть какую-либо подмодель из созданной модели (не забыв вначале закрыть файл, из которого модель создавалась, иначе ничего не получится) приводит к зависанию минут на 30. Это конечно не вариант. Подключаемся к БД и смотрим схему администратора моделей (допустим EADMIN, как в руководстве). Таблицы созданы, индексы созданы, но статистика по таблицам не собрана. Как результат: DBMS_STATS.GATHER_SCHEMA_STATS ('EADMIN'). Дальше разбираемся с таблицами. Собственно самыми большими являются две из них m7object и m7objectproperty. Как очевидно из названия: первая хранит объекты (собственно все сущности, таблицы, подмодели в иерархическом порядке), вторая их свойства. Посмотрев на данные таблицы свойств, я заметил достаточно много записей со значением «Imported from a previous version of ERwin.» в поле stringvalue. Можно и почистить, только аккуратно, размер сократится конечно не в разы, но всё же.
Исходная схема была разбита на множество подсхем (subject areas в нотации третьей версии), каждая такая подсхема может по идее открываться независимо. Но, блокировка возможна только на уровне схемы, это раз. При сохранении и слиянии изменений с репозиторием всё равно придётся подгружать схему целиком, это два. И, наконец, открытие всей схемы занимает столько же времени (и чуть больше памяти), чем открытие отдельной подсхемы, это три. Так что про возможность работы с отдельной подсхемой можно сразу же забыть. Итого имеем около 700 mb оперативки занятой на загруженную схему. Что-то пока всё безрадостно. Однако возможности конечно хороши — здесь и подробный мерджинг с репозиторием, и откат между сохраняемыми версиями, и фовард инжиниринг и реверс инжиниринг с базой, с другой схемой или с файлом, сохранение всех настроек сравнения и генерации скриптов прямо в схеме и прочее.
Минус один — скорость работы. Все махинации с базой и настройками позволили лишь слегка ускорить процесс. Помониторили работу с базой — все запросы примитивны (хотя и слегка нелогичны), но сами по себе таблицы большие. Попробовали обратиться к официальному дистрибьютору в России для консультации, обозначив видимые гипотезы проблем. В результате получили ответ, что универсального решения для проблем производительности при переводе старых моделей в Erwin новой версии нет. В итоге пока находимся на распутье между хорошей функциональностью и плохой производительностью, ещё продолжаем бороться, но уже смотрим на продукты конкурентов.