Перейти к содержимому

Data modeler oracle как работать

  • автор:

7 Управление подключениями к базам данных для построителя моделей данных

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

  • Подключения к базам данных для семантических моделей
  • Подключение к данным в базе данных Oracle Cloud
  • Защита подключений к базе данных с помощью SSL
  • Удаление файла бумажника SSL, загруженного для подключений к базе данных

Подключения к базам данных для семантических моделей

Построитель моделей данных в Oracle Analytics Cloud может обрабатывать данные, сохраненные в базах данных Oracle Cloud. Просто подключите Oracle Analytics Cloud к облачным источникам данных, чтобы начать моделирование данных.

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

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

Построитель моделей данных можно подключить к базам данных Oracle Cloud. Целевой базой данных должна быть Oracle Database Classic Cloud Service или Oracle Autonomous Data Warehouse.

Для семантических моделей, предустановленных вместе с Oracle Analytics Server, не требуется повторно вводить данные подключения к базе данных. Нередко сведения о подключении для этих моделей уже определено в семантической модели, которая загружается в Oracle Analytics Cloud. См. раздел «Загрузка семантических моделей из Oracle Analytics Server».

Если инструмент администрирования моделей используется для редактирования семантических моделей и загрузки их в Oracle Analytics Cloud, можно ссылаться на любые подключения к базе данных, которые вы определили в консоли «по имени» в диалоговом окне «Пул подключений». В инструменте администрирования моделей не требуется повторно вводить сведения о подключении. См. раздел «Подключение к источнику данных с помощью определенного в консоли соединения».

Подключение к данным в базе данных Oracle Cloud

Администраторы создают подключения к базам данных для построителя моделей данных, чтобы бизнес-аналитики могли анализировать данные, хранящиеся в Oracle Cloud.

  1. Нажмите Консоль .
  2. Нажмите Подключения .
  3. Нажмите Создать .
  4. Введите значимое Имя и Описание , которое легко запомнить и которое будет понятным для бизнес-аналитиков.
  5. Для параметра Подключить с помощью выберите свойства, которые необходимо использовать для подключения к базе данных.
  6. Укажите информацию о подключении к базе данных.
    1. В поле Хост укажите имя хоста или IP-адрес базы данных, к которой требуется подключиться.
    2. В поле Порт укажите номер порта, на котором база данных проверяет наличие входящих подключений.
    3. В поле Имя сервиса укажите имя сетевого сервиса базы данных.
    4. В поле SID укажите имя экземпляра базы данных Oracle.
    5. В поле Дескриптор TNS укажите дескриптор подключения TNS, определяющий местоположение базы данных и имя сервиса базы данных.

    Используйте следующий формат: DESCRIPTION=(ADDRESS=(PROTOCOL= protocol )(HOST= host ) (PORT= port )) (CONNECT_DATA=(SERVICE_NAME= service name )) Пример: DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhost.example.om)(PORT=1521))(CONNECT_DATA=(SERVICE NAME=sales.example.om))

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

    Необходимо загрузить накопитель с сертификатами SSL, если не сделали этого ранее.

    Разработчики бизнес-моделей могут сразу просмотреть новые подключения в построителе моделей данных и начать моделирование данных.

    Защита подключений к базе данных с помощью SSL

    Используйте SSL для защиты связи между Oracle Analytics Cloud и базой данных Oracle с настроенным протоколом SSL, Oracle Autonomous Data Warehouse или Oracle Autonomous Transaction Processing. Чтобы включить SSL для подключений Oracle Process Classic Cloud Service, необходимо получить и загрузить файл-накопитель, содержащий сертификаты SSL.

    1. Нажмите Консоль .
    2. Нажмите Подключения .
    3. Если этот шаг еще не выполнен, загрузите файл-накопитель с сертификатами SSL в Oracle Analytics Cloud.
      1. Выберите меню Действие , а затем Загрузить файл-накопитель .

      Чтобы обновить существующий файл-накопитель, нажмите Заменить контейнер .
      Выберите допустимый файл cwallet.sso .

      1. Создайте или отредактируйте подключение к базе данных.
      2. В диалоговом окне «Подключение» выберите Включить SSL .
      3. Нажмите ОК .

      Удаление файла бумажника SSL, загруженного для подключений к базе данных

      Если для подключения к базе данных, настроенного для вашей модели данных, требуется сертификат SSL, потребуется загрузить файл бумажника, содержащий необходимые сертификаты SSL, через консоль (страница «Подключения»). Можно удалить загруженный ранее и неиспользуемый файл бумажника.

      Например, может потребоваться удалить существующий файл бумажника, если БД Oracle Autonomous Data Warehouse, к которой подключена модель данных, настроена возможность подключения без использования бумажника .

      1. Нажмите Консоль .
      2. Нажмите Подключения .
      3. Выберите меню «Действие» и нажмите Удалить бумажник .

      Data modeler oracle как работать

      Татьяна пред окном стояла,

      На стекла хладные дышала,

      Задумавшись, моя душа,

      Прелестным пальчиком писала

      На отуманенном стекле

      Заветный вензель О да Е.

      А.С. Пушкин. Евгений Онегин, гл.3, XXXVII

      18.3.1. От моделирования данных до приложений

      Корпорация Oracle выпускает ряд продуктов и поддерживает технологии, которые ориентированы на разработчиков. Это инструменты и среды разработки, языки и концепции, которые могут быть использованы в процессе проектирования, разработки, тестирования и внедрения программных продуктов.

      Направления, в которых развиваются продукты Oracle, можно разделить на следующие группы:

      1. web-разработка (Интернет-приложения);
      2. java-разработка (десктоп-приложения);
      3. SOA-разработка (интеграция и управление);
      4. database-разработка (программирование в СУБД).

      Это разделение достаточно условно, так как некоторые продукты можно отнести одновременно к нескольким группам, другие продукты функционально дополняют друг друга в разных группах, т. к. практически все рассматриваемые нами инструменты являются частью единой платформы Oracle Fusion Middleware. Это большой плюс, т. к. взаимодействие различных компонентов конструируемой ИС уже отлажено и описано производителем. Рассмотрим некоторые продукты и технологии Oracle [ DM14 ].

      Упрощенный жизненный цикл разработки приложения включает пять фаз[ DM13 ]:

      1. моделирование;
      2. разработка;
      3. тестирование;
      4. развёртывание;
      5. мониторинг.
      18.3.1.1. 1 фаза. Моделирование данных с помощью Oracle SQL Developer Data Modeler

      Oracle SQL Developer Data Modeler – это комплексное решение, позволяющее разработчикам проектировать реляционные модели взаимосвязей объектов для последующего преобразования их в полноценные БД. Продукт поддерживает логическое, реляционное, многомерное моделирование и моделирование типов данных, предлагая возможности многоуровневого проектирования и построения концептуальных диаграмм сущностей и связей. Пользователи могут создавать, расширять и модифицировать модели, а также сравнивать их с уже существующими.

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

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

      Ускоренное преобразование ERD-моделей в реляционные модели – трансформация всех правил и решений, сделанных на концептуальном уровне, в реляционную модель, детали в которой уточняются и обновляются.

      Разделение реляционной и физической моделей – позволяет разработчикам создавать одну реляционную модель для разных версий базы данных или для разных баз данных, включая Oracle Database, IBM DB2 V7 и V8 для платформ Linux, UNIX, Windows и OS/390, а также Microsoft SQL Server 2000 и 2005.

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

      Продукт интегрируется с Oracle SQL Developer – популярным графическим инструментом Oracle для разработки баз данных, – чтобы предоставить разработчикам возможность открывать и просматривать созданные ранее структуры, а также выполнять запросы и формировать отчеты с использованием репозитория отчетов.

      Решение Oracle SQL Developer Data Modeler доступно для всех редакций Oracle Database 11g, 10g и работает в средах Windows, Linux и Mac OS X. Продукт лицензируется по пользователям [ DM14 ].

      18.3.1.2. 2 фаза. Разработка приложения с помощью Oracle SQL Developer и Oracle Application Express

      Oracle SQL Developer – бесплатный инструмент для написания SQL-запросов, разработки PL/SQL пакетов, процедур, функций, триггеров и т. п. Этот инструмент написан на языке Java и является кросс-платформенным. Oracle SQL Developer интегрируется с APEX для разработки и администрирования приложений.

      Возможности Oracle SQL Developer:

      1. интегрированная среда разработки БД;
      2. облегчённый интерфейс, упрощающий и улучшающий разработку БД;
      3. запуск и настройка SQL;
      4. разработка и отладка PL/SQL;
      5. просмотр объектов БД;
      6. интегрированная утилита миграции БД;
      7. выполнение и создание отчётов;
      8. просмотр, создание и редактирование данных в БД;
      9. интегрированная поддержка управления версиями;
      10. экспорт объектов БД в SQL скрипты;
      11. генерация SQL скриптов из словаря данных;
      12. чтение и форматирование трассировочных файлов;
      13. расширяемость через Java и XML.

      APEX является бесплатным продуктом, интегрированным с СУБД Oracle Database.

      Изначально APEX предназначался для создания HTML-интерфейса к базе данных. В настоящее время выпущена 4-я версия продукта, который стал полноценной средой проектирования и разработки web-приложений любой сложности с интегрированной БД. На базе APEX и бесплатной редакции Oracle Database eXpress Edition (XE) можно создавать сайты и порталы, которые не требуют затрат на лицензирование.

      Характерной особенностью этой среды разработки является то, что для работы с ней не требуется высокой квалификации в web-программировании и HTML-верстке. APEX представляет собой конструктор готовых блоков сайта. Фактически, минимально подготовленный пользователь может создавать рабочие сайты со встроенными средствами аутентификации и безопасности, современным дизайном и интерфейсом. С другой стороны, это гибкий инструмент, и квалифицированный разработчик может создавать страницы и сайты любого дизайна и структуры.

      Немаловажным является и то, что работоспособность этого сайта будет поддерживаться мощной и надежной базой данных Oracle Database. Сайты и порталы, разработанные на APEX, способны обслуживать сотни пользователей, т. е. отвечают требованиям, предъявляемым по масштабируемости к Интернет-приложениям [ DM14 ].

      В состав APEX входят следующие четыре основных компонента.

      1. Application Builder – собственно среда разработки web-страниц и бизнес-правил.
      1. SQL Workshop – среда управления объектами базы данных (индексы, таблицы, представления и т. п.). Включает мастер создания SQL запросов для пользователей, которые не обладают знаниями в языке SQL.
      2. Utilities – импорт и экспорт данных, генерация SQL-скриптов на изменение структуры базы данных, отчеты и восстановление удаленных объектов.
      3. Administration – управление пользователями, настройками, правами доступа и просмотр отчетов.

      APEX включает в себя следующие возможности:

      1. cреда разработки имеет простой и эффективный web-интерфейс, т. е. для начала разработки не требуется специализированных сред, разработка может вестись с любого компьютера с web-браузером;
      2. помощники миграции из настольных баз данных и электронных таблиц;
      3. встроенный мастер генерации отчетов в формате pdf;
      4. инструменты для интеграции и web-сервисами;
      5. большое количество шаблонов пользовательского интерфейса;
      6. интуитивно-понятное управление рабочим пространством;
      7. управление объектами по принципу drag & drop;
      8. графический помощник создания SQL-запро сов;
      9. защищенность данных сессии после авторизации пользователя;
      10. встроенный редактор PL/SQL;
      11. мастер создания диаграмм и отчетов на сайте;
      12. поддержка более 20 языков, включая русский.

      APEX является кросс-платформенной системой, т. е. он успешно работает как на операционной системе Windows, так и на Linux, Solaris, HP-UX, MAC OS и других.

      Одним из простейших примеров применения APEX на предприятии является переход от настольных баз данных и электронных таблиц (например, MS Access, MS Excel) к web-представлению этих баз и документов. Это бывает очень полезным, когда необходимо обеспечить одновременный доступ для редактирования одного и того же документа, особенно когда пользователи находятся в территориально удаленных офисах. В APEX встроен инструмент конвертации из таблиц Excel в таблицы APEX. После конвертации эти таблицы становятся доступны на корпоративном Интранет- или Интернет-сайте. Пользователь получает доступ к такой таблице после того, как вводит имя и пароль на сайте. Таким образом, можно организовать совместную работу над документом без пересылки его по электронной почте и т. п.

      Разработка в APEX может вестись на нескольких языках: PHP, Java, PL/SQL. При разработке на PL/SQL, внутреннем языке базы данных Oracle Database, можно обойтись без промежуточного звена в виде web-сервера Apache (Oracle HTTP Server), HTML-код будет выдавать непосредственно СУБД.

      Организация командной разработки структур баз данных

      Поддержание порядка в схеме БД — это важно, тем более если идёт живая разработка, количество таблиц и их взаимосвязей разрастается, и никто не может уже просто удержать в голове всю иерархию структур. Это понятно всем, ну понятно было и нам, когда мы приступили к разработке под 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 SQL Developer Data Modeler: новый инструмент для моделирования данных

      Корпорация Oracle представила решение Oracle SQL Developer Data Modeler, позволяющее разработчикам быстро и просто проектировать модели данных для Oracle Database.

      Это комплексное, автономное решение поддерживает логическое, реляционное, многомерное моделирование и моделирование типов данных, предлагая возможности многоуровневого проектирования и построения концептуальных диаграмм сущностей и связей (entity relationship diagram, ERD) и их превращения в реляционные модели. Пользователи могут создавать, расширять и модифицировать модели, а также сравнивать их с уже существующими моделями.

      «Успешная разработка любого приложения начинается с создания надежной модели данных, — отметил Майк Хичва (Mike Hichwa), вице-президент по разработке программного обеспечения корпорации Oracle. — Oracle SQL Developer Data Modeler предлагает не только графический метод разработки моделей данных, но и эффективный способ передачи существующих моделей данных разработчикам приложений».

      Oracle SQL Developer Data Modeler предлагает множество функциональных возможностей для моделирования данных и баз данных, включая: визуальное моделирование взаимосвязей между сущностями — поддерживает нотации Баркера (Barker) и Бахмана (Bachman), чтобы разработчики могли переключаться между моделями для удовлетворения потребностей клиентов или для создания и сохранения различных визуальных представлений моделей; ускоренное преобразование ERD-моделей в реляционные модели – трансформация всех правил и решений, сделанных на концептуальном уровне, в реляционную модель, в которой детали уточняются и обновляются; разделение реляционной и физической моделей — позволяет разработчикам создавать одну реляционную модель для разных версий базы данных или для разных баз данных, включая Oracle Database, IBM DB2 V7 и V8 для платформ Linux, UNIX, Windows и OS/390, а также Microsoft SQL Server 2000 и 2005; полный набор физических определений для баз данных — поддерживает такие физические определения, как секции, роли и табличные пространства для конкретных версий базы данных в средах с разными СУБД от разных производителей, обеспечивая согласованность и повышение продуктивности разработчиков.

      Олег Тремзин, Softline: За этот год значительный рост и развитие показали направления, связанные с техподдержкой и аутсорсингом

      Импортонезависимость

      Новый инструмент хорошо интегрируется с Oracle SQL Developer, графическим инструментом Oracle для разработки баз данных, чтобы предоставить разработчикам возможность открывать и просматривать созданные ранее структуры, а также выполнять запросы и формировать отчеты с использованием репозитория отчетов.

      Решение Oracle SQL Developer Data Modeler доступно для всех редакций Oracle Database 11g и работает в средах Windows, Linux и Mac OS X. Кроме того, предлагается версия для Oracle Database 10g. Инструмент Oracle SQL Developer Data Modeler уже поступил в продажу и доступен для загрузки с веб-сайта Oracle Technology Network (OTN).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *