Эти средства гарантируют, что создаваемая вами база данных будет тщательно продумана и сможет эффективно работать. Использовать их относительно просто. На основании заданных условий они могут генерировать программы на языке SQL. Однако для применения подобных программ необходима большая предварительная работа по планированию.
Допустим, вы собираетесь строить дом. Рисуя его в своем воображении, вы представляете, как он будет выглядеть, а также прикидываете, какие материалы пойдут на его строительство и отделку. Но, даже если вы продумали конструкцию "дома своей мечты" до мельчайших подробностей, у вас вряд ли хватит решимости отрицать необходимость разработки его чертежа. Создание большой, сложной базы данных (БД) во многом напоминает постройку дома. Работа без определенного плана может привести к тому, что проектируемая база быстро превратится в весьма "неуклюжее" произведение.
Информационные отделы ряда компаний обращаются к средствам моделирования данных, которые позволяют разрабатывать модель БД в графическом виде и обеспечивают полное соответствие разработанной базы первоначальному замыслу. Основываясь на заданных вами правилах, они автоматически генерируют схемы БД.
Мы протестировали четыре продукта для Windows, три из которых выбраны нашими читателями (и являются лидерами рынка): S-Designor Enterprise 4.2.1 компании Powersoft, Erwin ERX 2.5 (Logic Works) и пакет программ Bachman's Solution (Bachman Information Systems). Мы рассмотрели также Vivid Clarity 1.1 (Intek Technologies), поскольку этот продукт предоставляет аналогичные функциональные возможности при необычайно низкой цене, что может оказаться немаловажным фактором. К сожалению, в период проведения тестирования его последняя версия InfoModeler (Asymetrix) находилась на стадии бета-тестирования.
В целом, все четыре продукта позволяют выполнять одни и те же действия: разрабатывать логическую и физическую модели данных, генерировать схему, по крайней мере, для трех БД и проводить сопровождение баз данных. Отличие - в используемой методологии: Erwin и Clarity объединяют логические и физические модели, а Bachman's Solution и S-Designor воспринимают каждую из них по отдельности.
Потратьте время - окажетесь в выигрыше. Вы преуспеете в работе со средствами моделирования, только если все как следует обдумаете и спланируете. Необходимо четко определить классы и отношения между данными. Пренебрежение подготовительным этапом может дорого вам стоить.
Поскольку от проявления интереса к средствам моделирования данных до их внедрения в повседневную практику путь не близкий, ни Dataquest, ни IDC не приходилось наблюдать использование этого инструментария отдельно от более широкой категории средств анализа и проектирования, известных под названием CASE.
Исследования IDC показывают, что доля крупных и средних компаний США, применяющих CASE-средства, выросла с 8% в 1994 году до 12% в 1995 году. Старший аналитик IDC Эван Куин объясняет это главным образом применением так называемых "легких" CASE-средств, в число которых входят средства моделирования. Хотя для их освоения и придется потрудиться, идея не нова, и заинтересованные программисты смогут научиться достаточно быстро. Компании, использующие CASE-средства или принявшие их методологию, восприимчивы к технологии моделирования данных.
Сущность
Обычные CASE-средства обеспечивают структурированный подход, который также используется в процессе моделирования. Для моделирования данных характерны два общих понятия: диаграммы "сущности-связи" (схема представления отношений между объектами), которые называются также ER-диаграммами (entity-relationship), часто используемые для проектирования реляционных баз данных, и ролевое моделирование, заключающееся, по существу, в описании отношений между объектами на естественном языке. Большинство средств моделирования опирается на ER-модели.
Некоторые средства, подобные Erwin, могут применяться со множеством разнообразных структур БД, однако обозначения, используемые для описания ER-диаграмм, иногда различаются от модели к модели. Есть средства моделирования, подобные Designor 2000 компании Oracle, предназначенные для конкретных систем. Как в случае с Designor 2000 и поддержкой разработанных Oracle баз данных, иногда успех средства моделирования объясняется его связями с другими продуктами. Например, своей популярностью средство разработки PowerBuilder компании Powersoft обязано интересу к S-Designor, который Powersoft приобрела у фирмы SDP Technologies в прошлом году.
Пользователей и аналитиков привлекает также простота использования средств моделирования и применение в них графических команд.
Долгосрочные выгоды
"Пока рано судить, смогут ли, в конце концов, облегчить нашу жизнь средства моделирования данных, поскольку мы еще не завершили разработку своего приложения", - говорит Питер Гамбед, аналитик по базам данных из отдела информационных систем Massachusetts State Water Authority (Бостон). Однако эти средства помогают ему "распутывать" инфраструктуру сложной системы анализа сточных вод и отслеживать отдельные их компоненты, используя БД компании Oracle. Как указывает Пол Кабедж, старший аналитик Dataquest, при расширении проекта склада данных модели данных помогут обеспечить более гладкий переход.
"Их польза станет ощутима позднее, когда система сильно "разрастется", - сказал Кабедж. - Когда в компании имеются громадные "завалы" данных и приходится тратить время просто на изучение этой информации и ее структуры, ценность моделирования данных становится очевидной".
IDC оценивает годовой доход небольшого, но многообещающего рынка моделирования БД на уровне 40 млн. долл. Эти продукты применяются в информационных отделах корпораций в том числе благодаря интересу университетов к операционной системе Unix, языку C и компьютерам Macintosh. Просто новая технология нуждается в авторитетном проповеднике.
Возможности, предоставляемые средствами моделирования данных, небезынтересны для членов сообщества специалистов по ИС, однако лишь немногие готовы использовать их прямо сейчас.
Как мы тестировали
Средства моделирования БД обещают сгладить некоторые шероховатости, возникающие между вами и сконструированным вами складом данных. Мы подготовили набор тестов, включающих разработку логических моделей, генерацию физических моделей данных и схем БД, а также сопровождения существующей базы данных. Были проанализированы возможности продуктов по составлению отчетов. Для того чтобы протестировать продукты, мы разработали схему для бухгалтерской задачи, поскольку, по мнению наших читателей, это наиболее часто используемый тип SQL-БД. База данных состояла из 30 таблиц, содержащих свыше 200 полей. При тестировании была оставлена без внимания методология, лежащая в основе продукта, зато делался акцент на точности и эффективности инструментария.
Эксплуатационные характеристики
Разработка логической модели данных
Логическая модель данных - сердце любого проекта базы данных. Логическая модель содержит все спецификации для сущностей, атрибутов, правил и отношений между данными. Необходимо, чтобы продукт легко "схватывал" всю эту информацию.
Испытания были начаты с определения таблиц, столбцов внутри таблиц, атрибутов для этих столбцов и отношений между таблицами и столбцами. Затем мы тестировали возможности каждого продукта по редактированию: добавление, удаление или видоизменение сформированных таблиц и столбцов и определение ключей поиска.
Если продукт не мог выделить все элементы, определяющие базу данных, он получал оценку "неудовлетворительно". Мы ставили оценку "плохо" продуктам, которые, несмотря на то, что при их функционировании обнаруживались серьезные ошибки, выделяли все необходимые определения сущностей и правил. Оценку "удовлетворительно" получали продукты, выделявшие все элементы БД и при этом работавшие без ошибок. Чтобы заслужить оценку "хорошо", продукт должен был выполнить все тесты и, кроме того, иметь графические средства разработки и дружественный пользовательский интерфейс. Если продукт к тому же "улавливал" неправильно сформулированные правила и имел простые средства редактирования, а также требовал непродолжительного обучения, мы ставили ему оценку "очень хорошо". Получить "отлично" мог продукт, автоматически преобразующий правила в ER-диаграмму, оснащенный превосходными средствами редактирования и имевший возможность определения допустимости правил.
Мы добавляли призовые баллы продуктам, позволявшим создавать словарь данных или предоставлявшим гибкие возможности просмотра диаграммы логической модели. Мы снимали баллы за неподвижное изображение диаграммы модели или отсутствие функции undo (отменить).
Составление отчета о логической модели данных
Проектировщики баз данных используют отчеты для разъяснения структуры БД конечным пользователям. Как только проектировщиком и конечными пользователями согласован окончательный вариант логической структуры БД, для документирования логической модели используется отчет. Мы тестировали возможности продуктов, запрашивая вывод 12 диаграмм и шести отчетов, содержавших различные комбинации таблиц, столбцов, отношений между данными и ключей поиска.
Если продукт не мог сгенерировать больше трех диаграмм или двух отчетов из нашего списка, он получил оценку "неудовлетворительно". Оценка "плохо" ставилась продуктам, которые выводили отчеты или диаграммы, но работали с серьезными ошибками или имели плохой интерфейс пользователя. На "удовлетворительно" оценивались продукты, которые без ошибок формировали все запрашиваемые отчеты или диаграммы. Чтобы заслужить оценку "хорошо", продукт должен был выполнить все тесты, иметь понятный интерфейс пользователя и предоставлять достаточное количество заранее заготовленных отчетов-шаблонов.
Если продукт также позволял печатать отчеты о выбранных фрагментах моделей данных, он получал оценку "очень хорошо". Продукты, которым мы поставили "отлично", прошли все наши тесты без заминок, предлагали графические средства "буксировки" (drag-and-drop), имели простую последовательность настройки отчета, обеспечивали гибкие и мощные функции составления отчета и были оснащены многочисленными предварительно заготовленными шаблонами отчетов.
Мы начисляли призовые баллы продуктам, которые могли выводить отчет в формате какого-либо текстового процессора, и снимали их, если продукт имел "неуклюжие" средства форматирования отчета, не давал возможности настраивать отчеты или не позволял предварительно просматривать отчет.
Генерация физической модели данных
Физическая модель данных содержит все детали, необходимые базе данных для создания эффективного определения данных, - типы данных столбцов, значения столбцов по умолчанию и т.п. Для тестирования этих возможностей мы формировали физическую модель данных, а также выполняли просмотр и изменение получавшихся в итоге определений таблиц, индексов и столбцов.
Если продукт создавал некорректную физическую модель данных и мы не могли изменить определения, он получал оценку "неудовлетворительно". Мы давали оценку "плохо" продуктам, которые генерировали неправильные физические модели, но позволяли нам модифицировать определения. На "удовлетворительно" оценивались продукты, создававшие правильные физические модели данных и обеспечивавшие полезные средства редактирования, которые позволяли модифицировать физическую модель.
Чтобы заслужить "хорошо", продукт должен был формировать точную физическую модель, обеспечивать графические средства редактирования и предоставлять полный контроль за просмотром физической модели. Продукт, плюс ко всему автоматически генерировавший индексы, основанные на определенных нами ключах поиска, получал оценку "очень хорошо". Продукты, которым мы ставили оценку "отлично", генерировали безошибочные физические модели данных, позволяли нам устанавливать для физической модели значения по умолчанию и предоставляли мощный набор возможностей просмотра и редактирования с дружественным графическим интерфейсом пользователя.
Мы добавляли призовые баллы, если продукт имел простые средства, минимизирующие ввод избыточной информации, а также снижали оценку продуктам, имевшим неудобные средства редактирования или не поддерживавшим базовые определения физического уровня, такие как ключи и триггеры.
Составление отчета о физической модели
В отличие от отчетов о логических моделях, физические модели данных содержат обширные детали относительно конкретных атрибутов таблиц и столбцов. Важность этих отчетов объясняется тем, что они дают проектировщикам информацию, необходимую для отладки и настройки баз данных. Возможности продуктов для решения этой задачи проверялись путем создания шести диаграмм и четырех отчетов о физической модели данных.
Если продукт позволял просматривать меньше трех диаграмм и печатать меньше двух отчетов, он получал оценку "неудовлетворительно". Мы давали оценку "плохо" продуктам, у которых возникали трудности при выполнении тестов или был неудачно спроектирован интерфейс. Оценка "удовлетворительно" ставилась продуктам, успешно составившим все диаграммы и отчеты. Чтобы заслужить оценку "хорошо", продукт должен был выполнить все тесты и предоставить дружественную среду пользователя. Если продукт также обеспечивал составление диаграмм и отчетов по сегментам физической модели данных и предлагал набор предварительно заготовленных форм отчетов, мы ставили ему оценку "очень хорошо". Продукты, получившие "отлично", предоставляли мощный набор разнообразных функций, простые в использовании графические средства, возможность установки по принципу drag-and-drop и шаблоны отчетов.
Призовые очки начислялись продуктам, позволявшим сохранять отчеты в формате текстового процессора или настраивать форматы отчетов. Мы снижали оценки, если не могли предварительно просмотреть отчет перед выводом на печать, либо он имел громоздкий пользовательский интерфейс.
Генерация схемы базы данных
Одно из преимуществ средств моделирования состоит в том, что их применение избавляет проектировщиков БД от необходимости программировать "вручную" все операторы определения данных. Вместо этого инструментарий автоматически генерирует сценарий на языке DDL. Это существенно сокращает цикл разработки. Кроме того, возможность настройки на различные серверы БД обеспечивает проектировщика гибкими и простыми средствами переноса баз данных на другой сервер.
Для этого теста был отобран фрагмент физической модели. Мы генерировали сценарии на языке DDL для БД Oracle 7.2 (Oracle) и для SQL Server 6.0 и Access 2.0 (Microsoft). Проверяя сценарии на точность, выполняли их на намеченных БД, генерируя реальные схемы баз данных. Мы вносили изменения непосредственно в DDL-сценарии и повторно генерировали схему.
Если продукт не мог генерировать точные DDL-сценарии для любой из трех выбранных нами БД, он получал оценку "неудовлетворительно". Оценку "плохо" мы ставили продуктам, формировавшим точный DDL-сценарий только для одной или двух БД. Оценка "удовлетворительно" присуждалась продуктам, которые позволяли управлять назначением целевой БД, генерировали точные DDL-сценарии для всех трех тестовых БД и обеспечивали возможности просмотра и изменения результирующих DDL-сценариев. Для получения оценки "хорошо" продукт должен был выполнять все тесты по генерации DDL-сценариев и предоставлять пользователю дружественный интерфейс для их редактирования. Если генерируемые продуктом сценарии можно было легко читать, мы давали ему оценку "очень хорошо". Продукты, получившие оценку "превосходно", создавали правильные, легкие для чтения DDL-сценарии для всех трех БД, предоставляли простой интерфейс (типа point-and-click) для выбора сервера БД и запуска процесса, позволяли просматривать и изменять сценарии с помощью графических средств, а также выводить сценарии на печать или в файл.
Мы повышали оценку продуктам, имевшим средства подтверждения правильности DDL-сценариев, которые выгодно отличались простотой переключения между целевыми серверами. Оценка продуктов снижалась, если они не имели собственных или отвечавших спецификации Open Database Connectivity (ODBC) средств соединения с целевыми БД, отличались сложностью применения средств генерации DDL-сценариев либо не позволяли предварительно их просматривать или изменять.
Сопровождение баз данных
Проектировщики БД выполняют два типа задач сопровождения: обновление существующих логических и физических моделей данных и обратное проектирование существующей схемы базы данных. Обратное проектирование облегчает поддержку БД, позволяя разработчику превратить недокументированную устаревшую схему в логические и физические модели, снабженные необходимой документацией. Простота сопровождения БД имеет особую важность на уровне предприятий, где наблюдается постоянное изменение структуры БД.
Мы выполняли два теста по сопровождению, которые давали возможность оценить отдельно, а затем усреднить соответствующие оценки для получения рейтинга продукта в этой категории. Первый тест состоял в переработке учетной базы InfoWorld - простой системы, состоящей из 14 таблиц, которые хранятся на сервере SQL Server 6.0. Если продукт не мог создать логической и физической моделей из схемы БД, он получал оценку "неудовлетворительно". Мы ставили оценку "плохо" продуктам, которые выполняли обратное проектирование, но имели серьезные ошибки при функционировании. Оценка "удовлетворительно" давалась продуктам, точно и полностью выполнявшим обратное проектирование и оснащенным собственными или ODBC-драйверами для соединения моделирующего инструментария с базой данных.
Чтобы заслужить оценку "хорошо" продукт должен был выполнять все тесты и иметь дружественный пользовательский интерфейс. Если продукт также предоставлял управление ER-диаграммой физического уровня, он получал оценку "очень хорошо". Продукты, оцененные на "превосходно", успешно воссоздавали схему БД, формировали ER-диаграмму на физическом уровне, обеспечивали полное управление просмотром ER-диаграммы, позволяли выводить диаграмму в файл или на печать, предоставляли простые графические средства и поддерживали широкий набор серверных баз данных.
Второй тест включал в себя выполнение характерных задач сопровождения на существующих логических и физических моделях и генерации DDL-сценария и схемы.
Если продукт не позволял вносить какие-либо изменения в логические и физические модели, он получал оценку "неудовлетворительно". "Плохо" ставили продуктам, которые с трудом выполняли наши задачи сопровождения и имели особенно "недружественный" интерфейс пользователя, "удовлетворительно" - продуктам, успешно выполнившим все тестовые задачи сопровождения. Чтобы заслужить оценку "хорошо", продукт должен был выполнить все тесты и предоставить дружественную пользователю среду со специальными возможностями, например синхронизацией хранения модели данных с реальной базой данных. Если продукт предоставлял дополнительно какие-либо возможности для отслеживания изменений в моделях и соответствующей схеме, мы ставили ему оценку "очень хорошо". Продукты, получившие оценку "превосходно", позволяли быстро и легко выполнять все тестовые задачи по сопровождению, одновременно отображать логические и физические модели в соседних окнах, отслеживать изменения и выбирать модель, используемую для генерации схемы.
Продукт получал призовые очки, если он мог хранить изменения, внесенные непосредственно в физическую модель данных. Дополнительные баллы присуждались также за обновление логической модели данных на основе изменений физической модели. Мы снимали баллы за чрезмерную сложность процесса сопровождения.
Поддержка и цены
Документация
Документация, как минимум, должна обеспечивать полную и точную информацию обо всех основных функциях продукта. Мы начисляли дополнительные баллы, если в документации содержались основы теории реляционных баз данных или советы по формулировке правил и ограничений. Наличие учебных пособий, краткого справочника, словаря, экранных подсказок, системы помощи - за все это добавляли призовые очки. Ошибки, устаревшая или недостаточная информация, неудачная организация материала, плохой указатель или оглавление заставляли нас снижать оценку.
Поддержка
Оценкой за поддержку определялись общая политика поставщиков и качество обслуживания, которое мы получали, делая анонимные звонки. Дополнительные баллы присуждались, если технический специалист давал полезные советы или делал контрольные звонки, чтобы выяснить, справились ли мы со своей проблемой. Для того чтобы получить оценку "удовлетворительно", поставщик, составляя программу по поддержке пользователей, должен был включить сюда, по крайней мере, 30-дневную бесплатную поддержку и некоторую альтернативу телефонной связи - форум CompuServe, узел Internet или электронную почту, факсимильную службу либо фирменную BBS. Мы повышали оценки при наличии бесплатной междугородной линии, гарантии возврата денег или специально выделенных "часов поддержки".
Цена
Общая оценка складывалась из стоимости всех продуктов, необходимых для выполнения наших тестов. Например, если для выполнения теста по составлению отчета продукт нуждался в генераторе отчета или базе данных, мы добавляли стоимость соответствующего продукта сторонней фирмы. Мы также включали сюда стоимость драйвера базы данных, поскольку он часто требуется средствам моделирования для доступа к данным. Оценка "отлично" ставилась, если общая стоимость не превышала 2000 долл., "очень хорошо" - при общей стоимости от 2000 до 3999 долл., "хорошо" - от 4000 до 5999 долл., "удовлетворительно" - от 6000 до 7999 долл., "плохо" - от 8000 до 9999 долл. и оценку "неудовлетворительно" - свыше 10000 долл.
Обзор продуков
Bachman's Solution
Основанная в 1983 году, компания Bachman Information Systems продает комплект продуктов для проектирования баз данных и модификации продуктов для мэйнфреймов и систем архитектуры клиент-сервер. В отличие от других компаний, продукты которых участвовали в тестировании, компания Bachman предлагает свое решение в виде отдельных модулей. В частности, проектирование БД на логическом и физическом уровнях выполняется самостоятельными инструментальными модулями.
Bachman's Solution содержит наиболее полный набор функциональных возможностей, но, чтобы полностью его использовать, придется потратить много времени на обучение.
Комплект ПО состоит из GroundWorks 1.21 - средства моделирования деловой сферы, Terrain 1000 6.1.1 - среды проектирования, в которой создаются и изменяются структуры данных, TerrainMap 6.1.1 - инструмента, объединяющего возможности моделирования и проектирования БД, присущие GroundWorks и Terrain, и Reports 4.32 - модуля для составления отчетов, требующего для работы наличия БД Access (Microsoft). Пакет Bachman's Solution был единственным среди сравниваемых нами продуктов, который обеспечивал встроенную поддержку для баз данных DB2 (IBM), Sybase (Sybase) и Oracle.
Он предназначен для администраторов БД, разрабатывающих и управляющих в масштабе предприятия критически важными базами данных с архитектурой клиент/сервер.
Erwin ERX 2.5
Компания Logic Works образована в 1988 году с целью разработки программных решений в области проектирования БД в архитектуре клиент/сервер и перепроектирования деловых процессов. Ее "флагманский" продукт, Erwin ERX, был выпущен в 1989 году. В самой последней версии - 2.5 - расширены возможности печати, реализована функция On-Diagram Editing, позволяющая разработчикам редактировать объекты прямо в окнах диаграмм, и функция Relationship Auto Layout, которая автоматически следит за линиями, обозначающими отношения между сущностями, и соответствующим образом изменяет их при перемещении.
Erwin обеспечивает поддержку для многих БД, а для пользователей Oracle7, Sybase System 10 и Microsoft SQL Server - расширенную поддержку. Благодаря этому, Erwin предоставляет типы данных, свойственные конкретной БД, в отличие от пакета фирмы Bachman, преобразующего эти типы в общепринятые форматы. Кроме того, Erwin отличается от Bachman тем, что объединяет логические и физические модели.
Семейство продуктов Erwin работает также с PowerBuilder (Powersoft), OracleCASE, SQL Windows (Gupta) и Visual Basic (Microsoft). Помимо Erwin ERX в семейство продуктов входит Erwin SQL, позволяющий выполнять "прямое проектирование" (forward-engineering) для настольных БД и баз данных на основе SQL, и Erwin Desktop, содержащий возможности Erwin ERX, в том числе прямое и обратное проектирование.
S-Designor Enterprise 4.2.1
В мае 1995 года компания Powersoft (подразделение Sybase) приобрела фирму SDP Technologies, разработавшую продукт под названием S-Designor, который выпускался в двух версиях: Professional и Enterprise.
Их основное отличие состояло в том, что версия Enterprise включала многопользовательский репозитарий.
Имеется также версия S-Designor для PowerBuilder, которая может генерировать объекты запросов для приложений PowerBuilder и хранить расширенные атрибуты PowerBuilder в репозитарии S-Designor. Кроме того, компания Powersoft продает продукт StarDesignor, основанный на S-Designor, но без моделирования на логическом уровне или возможностей PowerBuilder. StarDesignor позволяет индивидуальному разработчику заниматься прямым и обратным проектированием и сопровождением баз данных.
S-Designor обеспечивает поддержку средств разработки для БД Uniface (Uniface), Progress (Progress Software), SQL Windows, Axiant и PowerHouse (Cognos) и NS-DK. Компания Powersoft предлагает свой продукт профессионалам в области систем класса клиент/сервер, заинтересованным в создании высококачественных баз данных. По мнению специалистов компании, интеграция процессов проектирования БД и разработки приложений приобретает все большую важность для деловой сферы, и продукт S-Designor ориентирован на поддержку этой тенденции.
Vivid Clarity 1.1
Компания Intek Technologies - новичок в области продуктов класса клиент/сервер. Она планирует поставлять серию дешевых программных средств для Windows, получившую название Vivid. Clarity - это первый продукт данного семейства.
Intek делает акцент на совместимости с БД масштаба предприятий Oracle и Sybase и содержит поддержку спецификации ODBC.
Clarity предоставляет графическое окно для рисования ER-диаграмм и разновидность репозитария, который не только дает возможность хранить элементы БД, но также использует автоматизацию для OLE-компонентов с целью переходов на взаимосвязанные текстовые документы, спецификации, графики производства и т.д.
Vivid Clarity 1.1 поставляется с октября прошлого года. Среди новых особенностей этой версии - поддержка OLE 2.0, расширенные возможности составления отчетов, образцы форм отчетов и возможность генерации всех основных типов окон данных для PowerBuilder.
Разработка логической модели данных
Bachman's Solution
ХОРОШО
При первом знакомстве с пакетом напрашивается аналогия со средой Unix: поначалу работать с ним трудно, но для того, чтобы оценить его мощность, достаточно только ознакомиться с его командами. GroundWorks - очень мощное средство, но его "кривая обучения" гораздо круче, чем у других продуктов, главным образом, из-за имеющихся в нем нескольких способов определения одной и той же информации для логической модели. Например, мы могли определить сущность через функцию Create Entity (Создать сущность) или через форму модели данных. К сожалению, без обучения или знакомства со всем материалом руководства легко "заблудиться". Большая часть данных логической модели хранится в формах. Однако процесс определения информации через формы очень запутан, поскольку GroundWorks позволяет только добавлять атрибуты в формы сущностей, переименовывать или удалять их. Для определения атрибутов, принадлежащих сущности, мы должны использовать другую форму. Bachman's Solution - единственный продукт, который заставил нас определять домены.
Он обеспечивает большинство вариантов отношений между сущностями. Не только обычные отношения (такие как один-с-одним или один-с-многими), но и менее известные варианты типа XOR (исключающее ИЛИ) или IOR (включающее ИЛИ).
Мы почувствовали, что для моделирования данных в масштабе отдела многие варианты отношений были лишними и только осложняли работу с продуктом.
GroundWorks позволял разделить атрибут на множество элементов. Мы нашли, что эта особенность очень полезна при установке ключей сущностей. Например, вместо одновременного создания в сущности основных ключей LASTNAME и FIRSTNAME в качестве основного ключа мы устанавливали NAME. Как и S-Designor, GroundWorks позволяет успешно объединять две различные логические модели в одну. Кроме того, модуль GroundWorks был единственным продуктом, помогавшим нормализовать объекты. Эта функция обеспечила сокращение в логической модели избыточных данных.
Она позволяет также экономить дисковое пространство, отводимое базе данных при ее создании.
Наконец, с помощью Bachman's Solution, единственного среди всех тестировавшихся продуктов, можно было отменять (пользуясь функцией undo) не только одно действие, но и целую последовательность. Основные недостатки комплекта - "недружественность" интерфейса пользователя и, нередко, спиральное движение к результату.
Erwin ERX 2.5
ОЧЕНЬ ХОРОШО
Безусловно, компания Logic Works, разрабатывая Erwin, думала о пользователе.
Установка отношений между сущностями очень проста, в основном, за счет использования нормальных типов отношений: один-с-одним, один-с-многими и многие-с-многими. В продукте имеются средства предварительной установки предпочтений для среды разработки, облегчающие чтение моделей данных, а также функция перехода Go-to, приводящая к любой запрашиваемой сущности модели. Erwin позволяет определить не только главные, но и альтернативные ключи и гарантирует использование лишь правильных типов данных, поскольку входящие в продукт средства редактирования отображают исключительно те типы данных, которые поддерживаются целевой БД.
Erwin дает возможность создавать модель, состоящую из одного или нескольких листов, и разрабатывать ER-диаграммы для каждого субъекта. Однако, в отличие от S-Designor, с помощью Erwin можно определять отношения между субъектами. Это облегчает просмотр отношений между подмоделями. Мы обнаружили, что отсутствует функция undo, а это создало немалые трудности при случайном удалении сущности: продукт не позволил восстановить его. Чужие ключи (foreign key) S-Designor не видимы до тех пор, пока не сгенерирована физическая модель, что усложняет верификацию корректности отношений между сущностями. В Erwin и Bachman's Solution отношения становятся видимыми в логической модели данных, как только между двумя сущностями будет установлена связь. Erwin выпускается вместе с обширным набором средств редактирования и обеспечивает пользователю большую гибкость и контроль над моделью.
S-Designor Enterprise 4.2.1
ХОРОШО
Создание простых логических моделей данных в S-Designor показалось нам достаточно легким. Однако для успешного построения сложных логических моделей необходимо хорошо разбираться в теории реляционных баз данных, в противном случае работать с ER-диаграммами будет трудно.
Чтобы построить простую логическую модель, мы использовали графические средства, позволяющие вычерчивать, именовать и определять сущности. Мы определяли атрибуты данных в каждой сущности, затем изображали ее и определяли отношения между сущностями. Далее устанавливались правила для объектов модели и определялся универсальный словарь данных, включая элементы данных и правила. В процессе работы необходимо часто вносить изменения в диаграммы: S-Designor оснащен множеством средств редактирования, дающих возможность безболезненно производить корректировки. Нам понравилось всплывающее меню для редактирования отобранных из диаграммы объектов и редактор выравнивания сущностей.
Как и в случае с простой логической моделью данных, модель для сложной практической задачи можно было создавать в единой рабочей таблице. Но она оказалась слишком запутанной (и переполненной), было трудно отслеживать отношения между объектами, и мы были вынуждены разделить модель на подмодели. При использовании S-Designor понимание сущности ER-диаграмм совершенно необходимо, поскольку существующая система помощи достаточно сложна.
Несмотря на то что S-Designor может создавать логическую модель на базе правил, определение самих правил весьма затруднено. S-Designor генерирует чужие ключи, основанные на отношениях между сущностями. Однако до окончания генерации физической модели не было возможности определить, какие из атрибутов не могли быть чужими ключами.
Vivid Clarity 1.1
УДОВЛЕТВОРИТЕЛЬНО
Работа с Clarity по определению сущностей, атрибутов и отношений утомительна и отличается отсутствием гибкости. Приходится входить в режим работы с таблицами, переносить сущность в зону чертежа, присваивать имя и повторять эти процедуры снова и снова. Мы были несколько удивлены, обнаружив в Clarity противоречия в последовательности выполняемых действий. Например, все таблицы попадали в список табличных объектов Object Gallery только в том порядке, в котором они создавались.
Мы не могли упорядочить этот список по алфавиту или каким-либо другим способом.
Более того, изменение таблицы в видимой модели вызывало отображение соответствующих изменений в Object Gallery, которое заменяло создание новой версии таблицы. Это устраняло любую вероятность создания "родовой" таблицы и ее переименования в зависимости от различных целей.
Также имелась возможность создавать собственные типы данных и добавлять их в Object Gallery.
Составление отчета о логической модели данных
Bachman's Solution
ОЧЕНЬ ХОРОШО
Такой дорогой продукт, как Bachman's Solution, не должен требовать для работы каких-либо дополнительных продуктов, однако модуль Reports не может функционировать без БД Access (Microsoft). К счастью, если собрать вместе все необходимые модули, то пакет предоставит наиболее мощные возможности для составления отчетов по сравнению с остальными тремя продуктами.
Собственные средства составления отчетов у модуля GroundWorks весьма ограничены. Среди этих возможностей - просмотр определений логической модели через ее диаграмму или формы определения, регулирование глубины отображения информации в диаграмме и возможность выбора типов форм. Но GroundWorks позволяет печатать только диаграмму логической модели. Для печати отчетов о других определениях модели приходится импортировать созданную логическую модель в модуль Reports. В этом модуле существует много заранее заготовленных форм отчетов, причем процесс их выбора отличается ясностью и простотой. Кроме того, имеется уникальная особенность, позволяющая разработчику включать или исключать определения из отчета. Как и в случае с S-Designor и Erwin, Reports позволяет предварительно просматривать отчеты перед печатью, а также устанавливать их заголовки. Созданные отчеты могут быть сохранены в текстовом формате Excel (Microsoft).
Erwin ERX 2.5
ХОРОШО
Erwin содержит несколько базовых форм отчетов, "начинку" каждого из которых можно изменять. Например, в отчете об объектах мы могли включить все объекты, либо только их часть и отношения между ними или просто ограничиться именами объектов. Нельзя изменить формат заранее заготовленных отчетов, но можно создать собственный отчет.
Erwin облегчает создание отчетов, содержащих диаграммы логических моделей и определения моделей, поскольку делит диаграмму логической модели на страницы. Мы могли печатать диаграмму логической модели, но были ограничены размером страниц: нельзя выводить диаграмму по частям. Наконец, можно также выводить диаграммы моделей и отчеты в файлы текстового процессора типа Microsoft Word и WordPerfect.
S-Designor Enterprise 4.2.1
ХОРОШО
Если для составления отчетов вам хочется иметь гибкие средства, то в этом случае безусловно подойдет S-Designor, поскольку он дает возможность создавать неограниченное число заказных отчетов. Он также содержит небольшое количество шаблонов для них.
S-Designor позволяет просматривать и печатать все диаграммы и отчеты и, подобно Erwin, способен выводить диаграмму полностью или по частям.
В S-Designor имеется архив, в котором можно сохранить заказные отчеты для будущего использования. Отчеты могут легко сохраняться в файлах текстового процессора за счет простого изменения опции вывода. Несмотря на то что существует возможность предварительно просматривать диаграмму модели перед выводом ее на печать, сделать то же самое с отчетами нельзя.
Vivid Clarity 1.1
ПЛОХО
Clarity не имеет каких-либо заранее заготовленных отчетов. Единственный способ создания отчетов - использование текстового процессора. Как и в случае с Reports из Bachman's Solution, Clarity требует для работы БД Access (Microsoft).
Однако возможности составления отчетов в Clarity значительно уступают соответствующим средствам Reports. Clarity обеспечивает связи с Access, позволяющие проектировщикам создавать отчеты об определениях модели данных.
Мы могли или печатать таблицы БД Access, составленные на основе определений нашей модели данных, или делать запросы к этим таблицам для получения желаемых определений данных.
Генерация физической модели данных
Bachman's Solution
ХОРОШО
Пакет успешно генерировал физическую модель, к тому же он позволяет изменять определение модели на графическом уровне.
При переключении из GroundWorks в TerrainMap практически приходилось начинать все сначала. Во-первых, мы должны были определить, какая именно логическая модель в GroundWorks была исходной, и какая физическая модель в TerrainMap должна была быть целевой. Модуль TerrainMap позволял определять установки для генерации физической модели (такие как установка префиксов или суффиксов для таблиц и опций для создания определенных пользователем типов данных). Подобно S-Designor, TerrainMap отображал состояние процесса генерации, причем соответствующие сообщения могли быть сохранены в файле для последующих справок. Мы не проводили формальных тестов на скорость, но TerrainMap затрачивал на генерацию физической модели данных значительно больше времени, чем другие продукты.
TerrainMap позволяет проверить результат генерации, но единственный способ просмотреть или изменить сгенерированную физическую модель - вносить изменения и в другой модуль - на этот раз в Terrain.
Большинство определений модели могли быть изменены. Однако каждый раз при добавлении нового объекта приходилось возвращаться к логической модели, добавлять новые отношения и регенерировать физическую модель.
Erwin ERX 2.5
ХОРОШО
С интерфейсом типа WYSIWYG Erwin облегчает изменение определения физической модели и обеспечивает обширный набор средств редактирования для поддержки этого процесса.
Объединение двух моделей в одну упрощает для новичков проектирование БД, поскольку в этом случае отпадает необходимость генерации физической модели, хотя "борцы за чистоту идеи" обычно предпочитают хранить логическую модель данных отдельно от физической (облегчая сопровождение и возможную миграцию данных в другие БД).
Как и S-Designor, Erwin позволяет в любой момент в процессе разработки модели назначать целевой сервер и устанавливать значения по умолчанию с учетом целостности на уровне ссылок. При необходимости значения по умолчанию могут быть изменены, и Erwin автоматически преобразует модель с тем, чтобы она соответствовала новому целевому серверу и значениям по умолчанию. Физическая модель генерируется сразу же после создания логической, и они обе могут быть отображены. Как и в случае S-Designor, когда в Erwin удаляется таблица или объект, все отношения, связанные с этой таблицей, исчезают. Однако, в отличие от S-Designor, исчезают также и все столбцы, основанные на этих отношениях. Индекс, созданный Erwin на базе главных и чужих ключей, не может быть модифицирован. Наконец, если мы хотели избавиться от создаваемого индекса, Erwin не позволял удалить его при условии, что он был главным или чужим ключом.
S-Designor Enterprise 4.2.1
УДОВЛЕТВОРИТЕЛЬНО
S-Designor генерирует корректные физические модели.
Продукт предлагает много средств редактирования для модификаций моделей. S-Designor позволяет выбирать между сохранением старого варианта модели и запоминанием только новой, измененной. После генерации модели отображаются любые обнаруженные в процессе ее выполнения ошибки и предупреждения. Эти сообщения можно сохранить. S-Designor был единственным продуктом, который давал возможность автоматически переименовывать атрибуты с дублирующими именами. Однако это автоматическое переименование следовало бы оформить в виде дополнительной опции.
S-Designor был также единственным продуктом, который не позволил нам установить обязательные отношения один-с-одним в меню Relationship Definition (Установление отношений). Когда мы удаляли таблицу, ее отношения с сущностями и другими таблицами удалялись автоматически. К сожалению, S-Designor не удаляет столбцы, созданные ранее в других таблицах при установлении отношений.
Vivid Clarity 1.1
ПЛОХО
Мы снизили оценку Clarity из-за нескольких серьезных изъянов и отсутствия целого ряда функций.
Clarity объединяет логическую и физическую модели в один проектный цикл. В Clarity вместо объекта используется таблица, а вместо атрибута - столбец. Единственное, что осталось общим, - создание индексов.
После завершения разработки мы захотели получить прямой доступ к элементам с целью внесения изменений, и в этом случае в Clarity возник сбой. Object Gallery содержит списки таблиц и отношений между объектами, однако из Object Gallery нет пути, связывающего эти списки с определениями таблиц или отношениями между ними. Для внесения изменений приходится просматривать ER-диаграмму, что довольно неудобно.
Мы столкнулись с несколькими недостатками ER-диаграммы. Она чрезмерно сжата, 95% диаграммы просто не видны, либо таблицы обозначены маленькими прямоугольниками площадью 2 кв.мм, которые совершенно неудобочитаемы. Несмотря на то что главные ключи выделены на схемах с помощью подчеркивания, символы, обозначающие, например, наличие чужих ключей или индексов, отсутствуют.
Мы не могли установить домены данных, редактировать маски или значения по умолчанию без применения PowerBuilder (Powersoft). Clarity предоставляет также средства для установки пользовательского интерфейса баз данных, однако при попытке использования этих функций мы постоянно получали сообщение об ошибке - "General Protection Fault".
Составление отчета о физической модели данных
Bachman's Solution
ОЧЕНЬ ХОРОШО
Этот пакет имеет наиболее мощный набор возможностей для создания отчетов. Подобно GroupWorks, модуль Terrain позволял нам просматривать физическую модель в виде ее диаграммы или формы определения модели. Мы могли также управлять отображением данных в диаграмме модели. С помощью Terrain мы обнаруживали в модели данных любой объект, в то время как S-Designor и Erwin предоставляли возможность находить только таблицу или логический объект.
В комплекте имеются два окна - Neighbors (Соседи) и Path (Путь), позволяющих рассматривать все таблицы, связанные с помощью выбранного отношения.
Они облегчают просмотр таблицы и связанных с ней сущностей. Terrain оказался единственным, у которого имелась такая возможность.
Для составления отчета о физической модели можно использовать Terrain или Reports. Однако составление отчетов и средства, необходимые для этого, в модуле Reports значительно лучше. Terrain позволил создать все тестовые отчеты и сохранить их для последующих применений. Для каждого отчета можно было использовать фильтры для сохранения любых необходимых определений. Была возможность распечатать экран диаграммы физической модели, но для печати фрагментов диаграммы надо было создать новую диаграмму и использовать технику "буксировки" для печати желаемого фрагмента. Для составления других отчетов мы импортировали нашу физическую модель в Reports.
Erwin ERX 2.5
ХОРОШО
Erwin предлагает много способов для составления отчета физической модели данных. Поскольку Erwin объединяет логическую и физическую модели, составление отчета о физической модели очень напоминает тот же процесс по отношению к логической модели. К счастью, мы могли переключать отображение модели с логического уровня на физический. В отличие от S-Designor, Erwin не приводит размеры выбранных таблиц в соответствие с размером экрана.
Как в S-Designor, в Erwin мы заполняли информацией каждый заранее заготовленный отчет. Готовые формы отчетов для физической и логической моделей были одни и те же, поэтому мы могли печатать определения логической и физической модели в одном и том же отчете. Порадовала возможность предварительного просмотра каждого отчета перед печатью. Отчеты могут быть сохранены в файле текстового процессора.
S-Designor Enterprise 4.2.1
ХОРОШО
Как и у других продуктов, определение физической модели в S-Designor настраивалось и просматривалось многими способами.
Однако S-Designor идет на один шаг дальше и автоматически изменяет масштаб просмотра, определяемый количеством выбранных для просмотра таблиц. Можно печатать любой фрагмент физической диаграммы и управлять появляющейся в ней информацией.
Как и в случае логической модели, физическая позволила нам создавать и сохранять свои собственные отчеты (в том числе заголовки и нижние колонтитулы) с несколькими определениями модели.
S-Designor дает возможность печатать отчет или сохранять его в файле формата текстового процессора. Мы нашли, что формат файла текстового процессора в S-Designor гораздо проще для чтения, чем у Erwin.
К сожалению, у продукта отсутствует функция печати конкретных индексов таблиц, доменов или правил. К тому же занимает много времени печать всей таблицы в том случае, когда требуется только часть.
Vivid Clarity 1.1
ПЛОХО
Программа не позволяла составлять какие-либо отчеты о физической модели, за исключением тех, которые можно создавать и поддерживать с помощью внешнего (по отношению к продукту) текстового процессора.
Когда мы пытались вставить документ, созданный с помощью Microsoft Word, в папку Object Gallery, то получили сообщение об ошибке, указывающее на то, что имеется проблема с Word. Но мы не обнаружили никаких трудностей при загрузке документа непосредственно в текстовый процессор.
Когда мы вернулись в среду Clarity, программа добавила открытый документ в Object Gallery. Затем мы смогли запустить Word и отредактировать документ из Object Gallery. Если "закрывать" Clarity без предварительного выхода из Word, внесенные в документ изменения теряются.
Генерация схемы базы данных
Bachman's Solution
ХОРОШО
Bachman's Solution не только генерирует корректные сценарии схемы БД для Microsoft SQL Server, Oracle и Microsoft Access, но и позволяет просматривать и изменять сценарии на языке DDL (Data Definition Language). Однако, когда мы соединялись с сервером БД через драйверы ODBC, создание главных и чужих ключей для таблиц становилось не совсем понятным.
Существуют два способа генерировать схемы базы данных в Terrain. Первый - с помощью функции Export Direct. В этом случае создаются DDL-сценарии, которые можно просмотреть, отредактировать и выполнить, но не сохранить.
Второй способ - использование функции Create DDL File, создающей DDL-сценарий, который можно не только просмотреть и отредактировать, но и сохранить. Но для того, чтобы выполнить этот DDL-сценарий, необходима отдельная функция. Тем не менее мы предпочитали второй подход, поскольку он позволял сохранять внесенные в DDL-сценарий изменения.
Bachman's Solution оказался единственным продуктом, предоставившим полный контроль над преобразованием типов данных с помощью специальной таблицы-подсказки, показывающей соответствие между типами данных в физической модели и в БД. Это предоставляло возможности выбора желаемого типа данных. Мы могли также выбирать таблицу физической модели, которая могла быть создана в DDL-файлах. Например, мы могли создать DDL-файл для таблицы работающего персонала, для любой таблицы, связанной с персоналом, или для всех таблиц физической модели. Затем в DDL-файле могли быть созданы объекты. Во время выполнения сценария паспорт состояния (status log) отображался на экране, и после выполнения можно было просмотреть файл регистрации и сохранить его для будущей справки.
Erwin ERX 2.5
ХОРОШО
Erwin имеет простые в использовании средства генерации схемы, полезный редактор сценариев и корректируемые сценарии схем.
Изменение целевой базы в Erwin отличается немного большей гибкостью, чем в S-Designor. Вместо автоматического преобразования типа данных из одной базы в другую, Erwin позволяет решать, нужно ли вообще это преобразование. Мы могли также печатать отчет, используя непреобразованные типы данных. Как и в случае с S-Designor, Erwin давал возможность просмотреть и изменить сценарии перед выполнением схемы и выводить сценарии на принтере или в файл текстового процессора. Содержание отчета о генерации схемы могло быть сохранено для дальнейшего применения. Erwin был единственным продуктом, который позволил делать паузы во время выполнения сценария.
Erwin успешно генерировал схемы БД для всех трех баз данных и создавал главные ключи для Oracle и SQL Server. Наконец, у Erwin имеются некоторые полезные для отладки сценария средства.
S-Designor Enterprise 4.2.1
УДОВЛЕТВОРИТЕЛЬНО
S-Designor генерировал понятные и легко читаемые сценарии схем. С его помощью можно выбрать всю физическую модель, для которой желательно сгенерировать DDL-сценарий или фрагмент. Сформированные сценарии схемы БД изменяются с помощью используемого по умолчанию редактора - Notepad (встроенного в S-Designor). К сожалению, Notepad может работать только с маленькими текстовыми файлами и выдает сообщение об ошибке, если файл сценария слишком велик для него.
Перед тем, как мы сгенерировали нашу схему БД, S-Designor позволил нам выбрать элементы структуры базы данных, которые необходимо было создать с помощью сценария схемы: таблицы, главные ключи, чужие ключи и индексы. Однако, когда мы использовали синтаксис ODBC при генерации сценариев для БД Access, опции для генерации главных и чужих ключей стали недоступными.
Если мы использовали синтаксис ODBC при генерации сценариев для Oracle и SQL Server, опции Create and Open Database и Create Storage также становились недоступными, заставляя разрабатывать сценарии вручную.
S-Designor генерировал корректные сценарии схем для создания таблиц и индексов на всех трех БД. Но после добавления правил проверки для столбцов таблицы, определенных пользователем типов данных и доменов, в сгенерированных сценариях появились изъяны. Сценарий для Access содержал сообщения об ошибке в столбцах, названных Note. S-Designor не позволял также создавать главные ключи для таблиц, сформированных в Access, и мы получили от сценария для SQL Server сообщение об ошибке, касающееся определенных пользователем типов данных. Сценарий для Oracle был единственным, который не столкнулся с серьезными проблемами. Сопутствующий файл сообщений облегчал определение ошибок в сценарии и их отладку.
Vivid Clarity 1.1
ПЛОХО
Clarity содержит неполные и неправильные шаблоны DDL для генерации сценариев схемы баз данных. Мы обнаружили, что используемые по умолчанию шаблоны содержат только частные операторы Create. Операторы типов данных отсутствовали совсем. Код, использовавшийся для создания главных ключей для Oracle, вызывал сообщения об ошибках. Нам пришлось внести в шаблоны обширные исправления, что потребовало хороших знаний SQL-сценариев. Поскольку мы писали код для DDL-шаблона, второй набор сценариев, сгенерированных Clarity, оказался более совершенным.
Поддержка баз данных
Bachman's Solution
УДОВЛЕТВОРИТЕЛЬНО
ПЕРВОЕ
Для выполнения этой задачи используется множество различных модулей, необходимо наличие блок-схемы для правильного управления.
Мы могли импортировать схему БД с сервера в Terrain, но для обратного проектирования импортированной модели надо было использовать GroundWorks.
Для того чтобы обратить схемы базы данных в логическую модель, нам приходилось трижды переключаться между модулями.
С другой стороны, мы могли выбирать тип ключа (главный или чужой), который хотели обратить, и имели возможность управления обращением типов данных в схеме БД (как при генерации схемы БД).
Подобно другим продуктам, которые мы сравнивали, Terrain отказывался обращать правила подтверждения правильности столбцов. Когда мы пытались обратить физическую модель обратно в логическую, то получили сообщения об ошибках, связанные с отменой чужих ключей. Тем не менее после устранения этой проблемы Terrain выполнил задачу.
ВТОРОЕ
При изменении логической и физической моделей данных Bachman's Solution работает "гладко".
Так как он хранит логическую и физическую модели раздельно, любое изменение, внесенное в ту или иную модель, не влияет на другую до тех пор, пока не будет выполнено прямое или обратное проектирование. Среди полезных особенностей: информация о последнем обновлении модели (кто и когда его производил), возможность сохранять новую версию для БД и средства для восстановления несохраненной модели. Как и у Erwin, в Terrain и GroundWorks отсутствует контроль за версией модели.
Erwin ERX 2.5
УДОВЛЕТВОРИТЕЛЬНО
ПЕРВОЕ
Если не выбрать целевую БД перед тем, как заниматься ее обращением, Erwin станет использовать ту базу данных, с которой работала ранее. Подобно
S-Designor, Erwin позволяет выполнять обратное проектирование на SQL-сценариях и БД, а также выбирать таблицы и табличную информацию, которая должна быть обращена. Опции Erwin для обращения информации табличной не настолько детализированы, как у S-Designor, однако обеспечивают необходимый минимум.
Erwin формирует отчет, отражающий количество обращенных таблиц и столбцов. По запросу он должен автоматически выводить обращенную модель. Erwin успешно обратил табличные определения и отношения между ними, а также правила подтверждения правильности для столбцов при использовании БД SQL Server и Oracle.
ВТОРОЕ
Erwin облегчает внесение изменений в логические и физические модели.
Так как он объединяет логическую и физическую модели, то при изменении данных на логическом уровне соответственно изменяются данные и на физическом. После изменения отношений между таблицами Erwin автоматически согласует столбцы этих таблиц. Он является единственным продуктом, обладающим возможностью синхронизации, которая устраняет необходимость регенерировать измененную схему БД. Несмотря на то что возможности синхронизации пользовательского интерфейса БД не кажутся простыми, они порадовали нас своей мощностью и избавили от необходимости регенерировать сценарии схемы. Erwin не осуществляет контроль за версией модели данных, но совместим с PVCS компании Intersolv.
S-Designor Enterprise 4.2.1
УДОВЛЕТВОРИТЕЛЬНО
ПЕРВОЕ
Пользовательский интерфейс S-Designor для обратного проектирования отличается ясностью и простотой применения. Однако формируемая им модель имеет изъяны.
Мы смогли обратить сценарий SQL или существующую БД. Но перед этим S-Designor позволил нам выбрать таблицы и связанную с ними табличную информацию, которую мы хотели обратить. Сообщение, отображающее ход процесса, могло быть распечатано или сохранено. S-Designor создал физическую модель данных, основанную на обращенной информации. К сожалению, он не обращает правила подтверждения правильности для столбца из существующей БД, поэтому пришлось сделать это вручную.
ВТОРОЕ
S-Designor эффективно отрабатывает "эволюцию" моделей данных при внесении в них изменений. Когда мы удалили отношение между двумя таблицами, столбцы, созданные благодаря этому отношению, пришлось удалять вручную. Каждый раз, когда обновлялась логическая модель, нужно было регенерировать физическую модель. S-Designor, однако, единственный из продуктов, позволивший сохранить изменения, внесенные в текущую физическую модель.
Как и Erwin, S-Designor обеспечил архивирование модели данных. Это полезно для внесения изменений в существующую БД. Нам понравилось, что
S-Designor сравнивал архивные модели с текущими и генерировал сценарий схемы только для тех позиций, которые были изменены. При модификации логической модели S-Designor не изменял автоматически связанную с ней физическую модель.
Vivid Clarity 1.1
УДОВЛЕТВОРИТЕЛЬНО
ПЕРВОЕ
В отличие от Erwin и S-Designor, Clarity имеет собственные драйверы для Sybase, Microsoft SQL Server и Oracle, а также поддерживает драйверы ODBC. Мы предпочитали использовать собственные драйверы, поскольку в случае применения драйверов ODBC нельзя было выбрать БД на сервере баз данных: вас автоматически соединят с базой данных по умолчанию. Используя собственные драйверы Clarity, мы смогли обратить желаемую БД обратно в физическую и логическую модели. В Clarity имеются также фильтры для выбора определения схемы, которое надо обратить. Но некоторые фильтры предназначены только для PowerBuilder (например правила подтверждения правильности, маска редактирования столбца и начальное значение столбца). Проверяя эти фильтры, при выполнении обращения мы получили сообщение об ошибке.
ВТОРОЕ
Подобно Erwin, Vivid Clarity объединяет логическую и физическую модели, так что требуется менять модель данных только один раз. Мы могли изменить большинство основных определений модели, однако Clarity не позволяла редактировать некоторые специальные характеристики столбцов, поскольку они были доступны только для PowerBuilder. Подобно другим продуктам, Clarity может генерировать схему БД только для измененных таблиц. Однако Clarity был единственным продуктом, не считая PowerBuilder, который не мог выполнять сгенерированную схему для БД.
Чтобы выполнять сценарии для любой другой БД, необходимо сохранить сценарии на дискете и выполнить их через фактическую базу данных.
Краткие итоги тестирования
Логическое моделирование данных - это итеративный процесс, который отличается тем, что может развиваться почти до бесконечности. Оно требует тщательной проработки и планирования.
По-настоящему хорошее средство моделирования данных автоматически преобразует правила в модель. Ни один из прошедших тестирование продуктов не мог выполнить эту процедуру.
Эффективное использование любого из этих продуктов невозможно без ясного понимания сущности ER-диаграмм и данных, которые в них содержатся.
Мы также обнаружили, что, хотя инструментарий для моделирования данных помогает проектировать БД с самого начала, при обновлении существующей базы данных он доставляет больше хлопот, чем хотелось бы. Это объясняется главным образом тем, что ни один из продуктов не смог успешно "вытянуть" ни одного определения из существующей БД, поэтому мы были вынуждены выполнять эту процедуру вручную. Erwin ERX 2.5 компании Logic Works набрал наибольшее количество баллов, поскольку он справлялся с нашими правилами и отношениями между данными наиболее понятным и эффективным способом. Это ПО позволяет устанавливать отношения предпочтения для среды разработки, реализует функцию Go-to, упрощающую "маневрирование" вокруг модели, и предоставляет другие функции, облегчающие жизнь пользователей. Высокая оценка Erwin в категории составления отчетов и генерации физической модели данных и схемы БД повлияла на конечный результат ее тестирования.
Erwin отличается от других продуктов тем, что объединяет логическую и физическую модели, таким образом отпадает необходимость отдельной генерации физической модели. Однако обе модели не хранятся по отдельности, поэтому сопровождение и перевод данных в форматы других БД оказываются затруднены. По этой причине Erwin наилучшим образом подходит для моделирования баз данных на уровне отделов компаний.
Для создания большой БД предприятия лучше всего подходит комплект компании Bachman Information Systems, составленный из пакетов GroundWorks 1.21, Reports 4.32, Terrain 1000 6.1.1 и TerrainMap 6.1.1.
Оценки продукта досточно противоречивы. Он слишком объемен, то есть для его изучения требуется значительно больше времени. Он содержит сложные функции, и, кроме того, для выполнения любой задачи приходится использовать слишком много компонентов. Логическая и физическая модели хранятся отдельно, к тому же компания Bachman поставляет свой продукт в виде самостоятельных модулей. Казалось бы, это хорошо: достаточно купить только необходимые продукты. Однако не торопитесь с оценкой - для нормальной работы нужны все модули. Кроме того, попытки следить за тем, какие функции выполняет каждый модуль, отнимают много времени и просто раздражают. К счастью, к тому времени, когда вы разберетесь в функционировании Bachman" Solution, у вас появится возможность оценить его мощность по достоинству. Стоимость этого пакета, которая значительно выше,