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

Обновлено: 15.01.2025

Я хочу использовать Oracle SQL Developer для создания диаграммы ER для моих таблиц БД, но я новичок в Oracle и этом инструменте.

Каков процесс создания диаграммы ER в SQL Developer?

ОТВЕТЫ

Ответ 1

Чтобы создать диаграмму для существующей схемы базы данных или ее подмножества:

Файл → Data Modeler → Импорт → Словарь данных → выберите соединение DB (добавьте, если нет) → Next → последние несколько шагов интуитивно понятны.

(SQL Developer версии 3.2.09.23.)

Ответ 2

Так как SQL Developer 3, это довольно просто (они могли бы сделать это проще).

Перейдите к & View → Data Modeler → Браузер & RAQUO;. Браузер будет отображаться как одна из вкладок вдоль левой стороны.
Нажмите "& Браузер & raquo; вкладку, разверните дизайн (возможно, называемый Untitled_1 ), щелкните правой кнопкой мыши & laquo; Relational Models & raquo; и выберите" Новая реляционная модель".
Щелкните правой кнопкой мыши на вновь созданной реляционной модели (возможно, Relational_1 ) и выберите & laquo; Show & raquo;.
Затем просто перетащите нужные таблицы (например, вкладка "Подключения & raquo;" ) на модель. Обратите внимание, когда вы нажимаете на первую таблицу на вкладке "Подключения", SQLDeveloper открывает эту таблицу справа: выберите все таблицы слева, затем убедитесь, что вкладка Relational_1 (или любое другое имя) является активной в rhs перед вами перетащите их, потому что он, вероятно, переключился на одну из таблиц, нажатых в lhs.

Ответ 3

Для диаграммы классов с использованием oracle db используйте следующие шаги

Ответ 4

Процесс создания диаграммы Entity-Relationship в Oracle SQL Developer описан в Oracle Magazine Джеффом Смитом (ссылка).

Диаграмма отношений сущностей

Начало работы

Импорт словаря данных

Ответ 5

Существует вспомогательный инструмент Oracle Data Modeler, на который вы можете взглянуть. На сайте есть онлайн-демонстрации, которые помогут вам начать работу. Раньше это была добавленная стоимость, но я заметил, что она снова бесплатна.

На странице обзора Data Modeler:

SQL Developer Data Modeler - бесплатный инструмент моделирования данных и проектирования, доказательство полный спектр данных и базы данных инструменты моделирования и утилиты, включая моделирование для Entity Диаграммы взаимосвязей (ERD), Реляционные (дизайн базы данных), данные Тип и многомерное моделирование, с форвардной и обратной конструкцией и генерации кода DDL. Данные Modeler импортирует и экспортирует в разнообразие источников и целей, обеспечивает разнообразие форматирования варианты и проверки моделей через предопределенный набор дизайна правила.

Ответ 6

Легко перейти к File - Data Modeler - Импорт - Словарь данных - Соединение DB - OK

Ответ 7

В Oracle использовался компонент SQL Developer с именем Data Modeler . Он больше не существует в продукте с по крайней мере 3.2.20.10.

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

Ответ 8

Я запускаю SQL Developer 17.2.0.188 build 188.1159, который действительно содержит возможности моделирования данных. Я просто создал диаграмму реляционной модели через меню: Файл- > Модель данных- > Импорт- > Словарь данных. .

У меня также есть автономный Data Modeler, который делает то же самое.

Рисунок 4: Реляционная модель и диаграмма для HR

Сгенерированная диаграмма не является ERD. Логические модели - это более высокие абстракции. ERD представляет сущности и их атрибуты и отношения, тогда как реляционная или физическая модель представляет таблицы, столбцы и внешние ключи.

Эта статья и её продолжение появились благодаря вопросам студентов на семинарах по СУБД. Каждый студент должен был выбрать тему для проектирования базы данных, реализовать полный цикл проектирования от логической и физической диаграммы в Oracle SQL Developer Data Modeler ( SDDM ) до работающей базы данных в СУБД Oracle с использованием APEX. Затем стать пользователем своей разработки: заполнить схему данными и написать аналитические запросы. Некоторые возможности SDDM оказались неочевидными и мы потратили полтора занятия, что бы рассмотреть самое необходимое.

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

Не надо сразу делать таблицы. Порядок разработки следующий:

анализ данных, процессов обработки информации и бизнес-правил, документирование собранной информации
выявление и определение сущностей
выявление, описание атрибутов сущностей, определение типов атрибутов
выявление, описание и определение типов связей между сущностями
создание матрицы связей и проверка идеи на прочность анализом матрицы связей, документирование бизнес-правил и ограничений
создание логической диаграммы сущность-связь (ERD) в SDDM, в свойствах атрибутов и связей в том числе отражаются бизнес-правила и ограничения, те что не могут быть реализованы в СУБД описываются отдельным документом и реализуются на прикладном уровне триггерами

Статью готовил я, Присада Сергей Анатольевич, сейчас работаю в Финансовом университете при Правительстве РФ, почта sergey.prisada на яндексе.

Рассмотрим на некоторых абстрактных отношениях следующие возможности:

Домены атрибутов.
Глоссарий имен.
Суррогатные (искусственные) первичные ключи.
Комментарии к атрибутам. Комментарии к сущностям.

Задачи

Создать домен атрибутов содержащий 4 значения (Value List).
Создать 3 сущности, каждая с 4 атрибутами. В каждой сущности 1 атрибут использует домен значений. 2 атрибута обязательные, два не обязательные, один атрибут уникальный, но не первичный UID. Сущности используют суррогатные (искусственные) ключи, первичные ключи вручную не устанавливаем. Каждому атрибуту и сущности сделать комментарий для RDBMS.
Создать связи между сущностями 1:N и в свойствах связей установить использование суррогатных ключей.
Создать и применить глоссарий имен.
Преобразовать в реляционную, затем в физическую модель. Изучить код, при наличии ошибок выяснить причину и устранить.
Отобразить комментарии на диаграмме для улучшения читаемости.

1. Создать домен атрибутов с 4 значениями (Value List). Указать строковый тип и параметры типа.

Меню “Tools” – “Domains Administrator”

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

Создать список допустимых значений домена.

Домены атрибутов сохраняются в файл defaultdomains.xml в каталоге с настройками Oracle Data Modeler профиля пользователя, или в каталоге с установленной программой – зависит от операционной системы.

Файл с доменами атрибутов необходимо сохранить в каталоге с моделью с новым именем, подключить его в настройках и сохранить модель. Для этого открыть настройки доменов:

Меню “Tools” – “Domains Administrator”, выбрать файл

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

домен «Имя» определен, тип строковые данные, перечень атрибутов «Иванов», «Петров», «Сидоров» как принадлежащие этому домену
домен «Почтовый индекс», тип данных NUMBER длиной 6 символов
домен «SMS to client», тип строковые данные длинной 100 символов

2. Создать 3 сущности, каждая с 4 атрибутами. В каждой сущности 1 атрибут использует домен значений. 2 атрибута обязательные, два не обязательные, один атрибут уникальный, но не первичный UID. Сущности используют суррогатные ключи, первичные ключи не устанавливаем. Каждому атрибуту и сущности сделать комментарий для RDBMS.

Первичные ключи указывать не нужно, только уникальные атрибуты в разделе “Uniaue Identifiers”.

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

Домен атрибутов и комментарий к атрибуту, параметр Mandatory (обязательности) устанаваливаем у двух из четырех.

Комментарий в свойствах сущности. Он появится на логической диаграмме, отобразится в свойствах таблицы и будет создан в физической модели.

Первичных и уникальных ключей сами не создаем (пусто на вкладке)

Создать связи между сущностями 1:N и в свойствах связей установить использование суррогатных (Искусственных) ключей “Use surrogate keys”. Свойства связи: переносимость Transferable, обязательность Optional и кардинальность Cardinality выбираем какие угодно, это же пример.

3. Создать и применить глоссарий имён.

Использование глоссария облечает работу с правилами именования в модели данных. Имя сущности должно быть в единственном числе, производная из неё таблица во множественном. Имя атрибута может быть длинным и понятным при разработке, но имя производного столбца должно быть кратким для уменьшения кода и удобства работы с запросами. Как правило, для имени столбца используют аббревиатуру имени атрибута. Имя атрибута сущности для автоматически создаваемого первичного ключа будет состоять из имени сущности с добавлением “_id”. Также в Oracle Data Modelerотдельно есть настройки правил для формирования имён внешних ключей, составных первичных ключей, индексов, ограничений уникальности.

Глоссарий имён можно создать новый, но также можно создать шаблон из уже разработанной логической

Предварительно необходимо сделать настройки имён в свойствах Oracle Data Modeler.

В настройках в Oracle Data Modeler, убрать чек-бокс.

Создать глоссарий имен из готовой логической диаграммы. Сохранить его как файл в каталоге с моделью.

Глоссарий обязательно должен содержать множественную форму для имени каждой сущности и аббревиатуру для каждого атрибута. Большие глоссарии можно редактировать выгрузив их в таблицу Excel. Меню редактирования глоссария находится в меню “Tools” – “Glossary Editor”. Используйте глоссарий во множестве проектов, нарабатывайте его в своей практике.

Меню сохранения глоссария

В настройках модели подключить глоссарий.

И примените правила именования к логической модели.

Преобразовать в реляционную.

Результат преобразования будет содержать имена из глоссария, комментарии.

Преобразовать реляционную модель в физическую.

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

В настройках генерации физической модели можно указать множество параметров, например выбрать только определенные объекты модели (например вы разработали только представления View). Обязательно установить чек-боксы как на картинке. Все подробности в документации.

Результат – DDL файл с инструкциями для создания схемы в базе данных. Внимательно изучите его, найдите все элементы, которые были созданы в логической диаграмме, при наличии ошибок выяснить причину и устранить. Например домены атрибутов, каким образом создаются ограничения и т.п.

Этот скрипт готов для импорта в базу данных.

4. Отображение комментариев.

Отображение комментариев в логической и реляционной моделях делает диаграммы более читаемыми во время работы.

При открытой логической диаграмме в меню Oracle Data Modeler включить в меню отображение комментариев.

5.Скачайте пример

Изучите её как пример, создайте аналог, прочтите дополнительно документацию и примените знания в своём проекте.

Я хочу использовать Oracle SQL Developer для создания диаграммы ER для моих таблиц БД, но я новичок в Oracle и в этом инструменте.

Каков процесс создания ER-диаграммы в SQL Developer?

Вы также можете сделать это с помощью ER Diagram Tool в dbForge Studio for Oracle. Попробуйте бесплатное экспресс-издание.

Создайте диаграмму для существующей схемы базы данных или ее подмножества следующим образом:

Нажмите Файл → Data Modeler → Импорт → Словарь данных .
Выберите соединение с БД (добавьте одно, если оно отсутствует).
Нажмите Далее .
Проверьте одно или несколько имен схем.
Нажмите Далее .
Отметьте один или несколько объектов для импорта.
Нажмите Далее .
Нажмите Готово .

Экспортируйте диаграмму следующим образом:

Нажмите Файл → Data Modeler → Распечатать диаграмму → В файл изображения .
Найдите и выберите расположение файла экспорта.
Нажмите Сохранить .

Диаграмма экспортируется. Чтобы экспортировать в векторный формат, используйте To PDF File . Это позволяет упростить редактирование с использованием Inkscape (или другого редактора векторных изображений).

Эти инструкции могут работать для разработчиков SQL с 3.2.09.23 по 4.1.3.20.

Не работает для меня Разработчик SQL 3.2.20.09 отображает не все таблицы, но отображает другие объекты, такие как представления и т. Д. Есть идеи? @sataniccrow: согласен, инструмент для разработки sql в целом не прост в использовании и глючит, делает любую работу болезненной. но имеет много функций, с другой стороны. У меня была проблема при создании нового соединения с базой данных при создании модели ER. При выборе TNS в качестве Типа соединения в раскрывающемся списке Псевдоним сети не было ожидаемых записей в моем файле tnsnames.ora. Чтобы обойти это, я выбрал тип подключения «Базовый» и ввел нужные значения «Имя хоста», «Порт» и «Имя службы» из файла tnsnames.ora, который работает иначе. Может быть, есть место, где мы можем указать файл tnsnames.ora для SQL Modeler, но я не смог найти такого места через SQL Developer (Инструменты-> Настройки-> Data Modeler). После этого все было просто. Примечание: вы должны быть внутри инструмента Data Modeler, иначе «Data Modeler» не будет доступен в меню «Файл». Предположим, я сгенерировал диаграмму, а затем обновил одну из исходных таблиц. Как мне «обновить» диаграмму, чтобы показать изменения, которые я внес в исходную таблицу?

Начиная с SQL Developer 3, это довольно просто (они могли бы сделать это проще).

Перейдите к «View → Data Modeler → Browser» . Браузер будет отображаться как одна из вкладок с левой стороны.
Нажмите на вкладку «Браузер» , разверните дизайн (возможно, называется Untitled_1 ), щелкните правой кнопкой мыши «Реляционные модели» и выберите «Новая реляционная модель» .
Щелкните правой кнопкой мыши по вновь созданной реляционной модели (возможно Relational_1 ) и выберите «Показать» .
Затем просто перетащите нужные таблицы (например, из вкладки «Соединения» ) на модель. Обратите внимание, что при нажатии на первую таблицу на вкладке «Подключения» SQLDeveloper открывает эту таблицу справа: выберите все таблицы слева, а затем убедитесь, что Relational_1 вкладка (или любое другое имя) является активной в правой части окна, прежде чем перетаскивать их потому что он, вероятно, переключился на одну из таблиц, которые вы щелкнули в lhs.

Это звучит просто - но так грустно - перетаскивание не работает для меня (WinXP / SQLDesigner 3.2.09). Предложения? Я использовал Oracle SQL Developer, извините, это была опечатка выше написания SQLDesigner. Просто оставив здесь комментарий, потому что я потратил полчаса, чтобы понять, как экспортировать диаграмму в png или pdf. И я не хотел бы делать это снова в следующий раз, когда мне это понадобится (. это не первый раз). В любом случае, процедура такая же, как и в ответе @ Sergei выше: Нажмите «Файл» → «Моделировщик данных» → «Распечатать диаграмму» → «В файл изображения (или в файл PDF)»

Процесс создания диаграммы Entity-Relationship в Oracle SQL Developer был описан в Oracle Magazine Джеффом Смитом ( ссылка ).

Диаграмма отношений сущностей

Начиная

Для работы с примером вам понадобится экземпляр Oracle Database с образцом схемы HR, который доступен при установке базы данных по умолчанию. Вам также нужна версия 4.0 Oracle SQL Developer, в которой вы получаете доступ к Oracle SQL Developer Data Modeler через подменю Data Modeler [. ]. В качестве альтернативы вы можете использовать автономный Oracle SQL Developer Data Modeler. Функциональные возможности моделирования идентичны в двух реализациях, и обе доступны для бесплатной загрузки из Oracle Technology Network.

В Oracle SQL Developer выберите View -> Data Modeler -> Browser. На панели «Браузер» выберите узел «Реляционные модели», щелкните правой кнопкой мыши и выберите «Новая реляционная модель», чтобы открыть пустую панель диаграммы модели. Теперь вы начинаете с того же места, что и тот, кто использует автономный Oracle SQL Developer Data Modeler. Импорт словаря данных

Импорт словаря данных

Любой разработчик, имеющий дело с генерацией отчётности из баз данных, регулярно сталкивается с построением громоздких запросов. Часто это бывает связано с ошибками проектирования БД, и, ещё чаще, со сложностями преобразования извлекаемых данных. К последним можно отнести применение итерационных методов вычисления, подсчёт промежуточных итогов по подгруппам, расчёты, в которых используются значения соседних строк выборки, сложное форматирование строк и подобные задачи. Такие преобразования часто выносятся с уровня БД на уровень сервера приложений или клиента, что сказывается на производительности и удобстве сопровождения кода. Для решения этих задач SQL СУБД Oracle предоставляет аналитические функции и оператор MODEL — о нём и пойдёт речь в этой статье.

Это расширение конструкции SELECT стало доступно с СУБД версии 10g. MODEL позволяет обращаться к данным выборки как к многомерным массивам, изменять и добавлять элементы, проводить сложную агрегацию, а также решать ряд задач, которые до этого требовали использования PL/SQL. При этом языковые конструкции остаются читабельными и декларативными. Одним словом — Excel-like, плюс вся нагрузка ложится на плечи сервера БД.

Синтаксис

MODEL [ IGNORE NAV ] [ RETURN UPDATED ROWS ]
[ PARTITION BY (partition_column_1, . )]
DIMENSION BY (dimension_column_1, . )
MEASURES (measured_column_1, . )
RULES [ AUTOMATIC ORDER | ITERATE (value) [ UNTIL (expression)]] (
rule_1, .
);

Оператор MODEL обрабатывается в числе последних, после него только DISTINCT и ORDER BY. В результате применения столбцы выборки отображаются в массивы measured_column_* c измерениями dimension_column_*. Необязательный параметр PARTITION BY определяет паритиции, аналогичные используемым в аналитических функциях (каждая из них обрабатывается правилами rule_* как независимый массив). Правила применяются в порядке перечисления.

Простейшие примеры

Для начала смоделируем выборку чисел 1, 2 и 3:

SELECT *
FROM dual
MODEL DIMENSION BY (0 dimension)
MEASURES (dummy)
RULES (
dummy[5] = 1,
dummy[6] = 2,
dummy[7] = 3
);

В данном случае, по трём правилам заполняется массив dummy с измерением dimension. Алиас 0 dimension определяется для того, чтобы добавить новый столбец. Разберём преобразование подробнее. Первым делом происходит определение и отображение столбцов выборки (0 dimension в DIMENSION, dummy в MEASURES), затем по этим столбцам происходит выборка (возвращается строка dummy = X, dimension = 0) и только после этого выполняются правила. Сначала ищется строка с dimension = 5, но т.к. она не находится, создаётся новая и заполняется dummy = 1, аналогично для оставшихся двух правил. Если необходимо, с помощью директивы RETURN UPDATED ROWS можно вывести только обновлённые строки:

SELECT result, dummy
FROM dual
MODEL RETURN UPDATED ROWS
DIMENSION BY (dummy)
MEASURES (0 result)
RULES (
result[5] = 1,
result[6] = 2,
result[7] = 3
);

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

SELECT sequence
FROM dual
MODEL DIMENSION BY (0 dimension)
MEASURES (0 sequence)
RULES ITERATE (100500) UNTIL (sequence[iteration_number] > 10) (
sequence[iteration_number] =
CASE iteration_number
WHEN 0 THEN 0
WHEN 1 THEN 1
ELSE sequence[iteration_number - 2] + sequence[iteration_number - 1]
END
);

ITERATE задаёт количество итераций цикла (начиная с 0), а необязательная директива UNTIL — условие выхода из него (которое сработало, судя по тому что вы ещё не нажали Ctrl + End). Доступ к счётчику осуществляется через переменную iteration_number.

Диапазоны и агрегирование

cnt[day < 6, type LIKE 'latt%']
cnt[day IN (3, 6), cv(type)]
cnt[day BETWEEN 1 AND 16, regexp_like(type, '^.+(sso|tte)$')]

cnt[2, 'black']
cnt[7, 'latte']

Рассмотрим таблицу, хранящую информацию о выпитом в течение недели кофе:

TYPE CNT DAY
-------------------- ---------- ----------
turkish 1 1
espresso 1 1
turkish 2 2
black 1 2
espresso 1 2
latte 3 3
black 2 4
ice 1 4

Предположим, мы хотим вывести отчёт о том сколько всего чашек кофе выпито в каждый из дней и в общем, заодно учтём, что в четверг порции чёрного кофе были двойными. Итак, запрос:

SELECT *
FROM coffee
MODEL DIMENSION BY (day, type)
MEASURES (cnt)
RULES (
cnt[4, 'black' ] = cnt[cv(day), 'black' ] * 2,
cnt[ FOR day FROM 1 TO 4 INCREMENT 1, ' total for day' ] = sum<(cnt)[cv(day), ANY ],
cnt[ NULL , 'GRAND TOTAL' ] = sum(cnt)[ ANY , ' total for day' ]
)
ORDER BY day, type DESC ;

DAY TYPE CNT
--------- -------------------- ---------
1 turkish 1
1 espresso 1
1 total for day 2
2 turkish 2
2 espresso 1
2 black 1
2 total for day 4
3 latte 3
3 total for day 3
4 ice 1
4 black 4
4 total for day 5
GRAND TOTAL 14

Разберём правила подробнее. Первое удваивает количество выпитого в четверг кофе. Функция cv(dimension_name) возвращает текущее значение индекса по измерению dimension_name для обрабатываемого элемента (т.е., в данном случае, вместо cv(day) можно было указать day = 4 или, при желании, сослаться на предыдущий день как day = cv(day) — 1). Второе правило вычисляет подытоги с понедельника по четверг. Кроме цикла (который и так нагляден), здесь используются ссылки на диапазоны элементов в правых частях равенств. Указывать диапазоны можно теми же способами, что и проверки в конструкции WHERE, дополнительное ключевое слово ANY служит для выбора любых значений индекса. Ссылки на диапазоны в правой части равенства необходимо агрегировать, в данном случае используется функция sum. И, наконец, третье правило считает сумму подытогов.

SELECT *
FROM coffee
MODEL DIMENSION BY (day, type)
MEASURES (cnt)
RULES (
cnt[ NULL , FOR type IN ( SELECT DISTINCT type FROM coffee)] = sum(cnt)[ ANY , cv(type)],
cnt[ NULL , 'GRAND TOTAL' ] = sum(cnt)[ NULL , ANY ],
cnt[ NULL , ' drank ' || cnt[2, 'latte' ] || ' cups of latte on 2 day' ] = NULL ,
cnt[ NULL , CASE
WHEN cnt[3, 'espresso' ] IS PRESENT THEN ' ACHIEVED'
ELSE ' FAILED'
END || ': drank espresso on 3 day' ] = NULL
)
ORDER BY day, type DESC ;

DAY TYPE CNT
---------- ---------------------------------------- ----------
1 turkish 1
1 espresso 1
2 turkish 2
2 espresso 1
2 black 1
3 latte 3
4 ice 1
4 black 2
turkish 3
latte 3
ice 1
espresso 2
black 3
GRAND TOTAL 12
drank cups of latte on 2 day
FAILED: drank espresso on 3 day

В первом правиле используется цикл с итерациями по значениям выборки. Вложенные запросы, используемые внутри MODEL должны быль некореллированными. Следующее правило вычисляет итоговую сумму. Обратите внимание на строку «drank cups of latte on 2 day». Т.к. элемент cnt[2, 'latte'] не был найден, мы получили NULL по ссылке. Это поведение можно изменить директивой IGNORE NAV (добавляется после слова MODEL), тогда вместо ненайденных элементов и NULL, в расчёты будут подставляться: 0 для чисел, 1 января 2001 года для дат, пустая строка для строковых типов и NULL для всего остального. И, наконец, четвёртое правило демонстрирует использование выражения IS PRESENT, оно возвращает истину в случае, если заданный элемент существует, но, увы, эспрессо в среду не было выпито.

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

Читайте также: