Вместо вступления.

Первая часть доступна по адресу: https://www.veeltech.ru/vozmozhnosti-oracle-sql-developer-data-modeler-sddm-chast-1

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

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

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

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

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

1. Создание нескольких дисплеев для отображения различных нотаций.

По-умолчанию используется нотация Баркера, её элементы мы используем в практике на занятиях. Но с внешними ключами без автоматического их создания удобнее работать в SDDM в нотации Бхмана.
Важно: рекомендуется использовать нотацию Баркера, суррогатные ключи, автоматически создаваемые первичные и внешние ключи.
Для удобства рассмотрения диаграммы, или при особых условиях проектирования, может потребоваться отобразить логическую модель в различных нотациях. Например, для отображения внешних ключей и проектирования без суррогатных ключей создаваемых SDDM автоматически.
Создайте два допонительных экрана отображения логической диаграммы – “Display”, и назовите их “Barker” и “Bachman”. В каждом “Display” выберите в меню “View” – “Logical Diagram Notation” выберите нотацию для представления диаграммы в соответствии с их именами.
Создать “Display”

Выбрать его правой клавишей, далее “Properties”

Выбор нотации для каждого “Display”

2. Естественные первичные ключи, или создаваемые вручную, их отображение.

Перейдите в созданный “Display” с именем “Bachman”, в нотации Бахмана можно отобразить внешние ключи на диаграмме: в меню “View” – “View Details” – “All Details”. Отобразятся все свойства сущностей и связей, определённые в логической модели.

• P уникальные атрибуты, UID
• F внешние ключи, Foregin keys
• В нижней части сущности первичный ключ с указанием вхоодящих в него атрибутов, PrimaryUID
• * обязательные атрибуты, свойство Mandatory

При создании связи между сущностями подразумевается связь между первичным уникальным идентификатором родительской сущности и одним из атрибутов дочерней сущности. При этом требуется, чтобы свойства атрибута дочерней сущности, объявляемого внешним ключом, были идентичны первичному уникальному идентификатору родительской сущности.
С целью облегчения проектирования, при создании логической модели SDDM автоматически создает атрибут для внешнего ключа в дочерней сущности. Самостоятельно его создавать не следует. Изменить это поведение нельзя. Имя создаваемого атрибута для вторичного ключа будет состоять из имени и имени первичного ключа родительской сущности с разделителем в виде символа нижнего подчеркивания “_”.
Две сущности, между ними создадим неопределяющую связь 1:N, рассмотрим свойство связи и созданный внещний ключ в свойствах дочерней сущности.
В дочерней сущности “Course” автоматически создан внешний ключ “Department_Dept_name”

Свойства созданного внешнего ключа нельзя изменить, они соответствуют свойству PUID родительской сущности. Можно изменить имя созданного атрибута для внешнего ключа.

В свойствах созданного атрибута для внешнего ключа можно указать изменить его обязательсть чекбокс “M” – это повлияет на свойство обязательности связи. Также можно внешний ключ включить в состав первичного ключа – в этом случае связь будет определяющей.

Удобнее смотреть свойства всех атрибутов в виде таблицы на вкладке “Overview”.

ВАЖНО: при логическом проектировании не требуется заранее определять атрибуты для внешних ключей. Цель логического проектирования – создание логической модели и приведение её минимум к третьей нормальной форме. Внешние ключи являются атрибутами, которые согласно анализу информации, будут являться характеристиками сущности, которые имеют транзитивную зависимость (вторая нормальная форма), поэтому при декомпозиции отношения они должны быть устранены из сущности в другую сущность. Если на логической диаграмме до создания связей в свойствах сущностей есть атрибуты для внешних ключей, то сущности не приведены к третье нормальной форме, а атрибуты на диаграмме дублируются. Дублирующихся атрибутов не должно быть.

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

3. Соответствие атрибутов связи – правила создания и отображения. Шаблоны именования внешних ключей и иных объектов при преобразовании в реляционную модель.

Создаваемые автоматически атрибуты внешних ключей, имена ограничений внешних ключей, первичные ключи, индексы и иные объекты, при преобразовании в реляционную модель не всегда имеют удобные для обработки человеком наименования. Если создаваемая база данных будет использоваться только информационными системами, такими как сетевые сервисы или серверы приложений, то лучше оставить автоматические имена. Это гарантирует их уникальность, а правила генерации имён отображают логику и понятный алгоритм их создания. Для удобства работы человека нужно использовать псевдонимы объектов – “Alias”, а также заранее создавать пакеты и процедуры.  При этом, в SDDM предусмотрен механизм настройки правил именования автоматически создаваемых объектов.

Выбрать модель, правой клавишей, “Properties”.

Шаблоны именований создаваемых автоматически объектов настриваются в разделе настроек “Settings” – “Naming Standart” – “Templates”. Все возможные переменные отобразятся при нажатии “Add Variable”.

Типы объектов — это термины из реляционной модели и должны быть понятны интуитивно. Переменные, доступные для использования в шаблонах имён, описаны в поле комментарий интерфейса. Дополнительная информация в официальной документации к SDDM.

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

Шаблон для реляционной модели называется “Column Foreign Key”:

• значение было {ref table}_{ref column}
• значение стало {ref column}

Шаблон для логической модели называется “Attribute Relation”:

• значение было {ref entity}_{ref attribute}
• значение стало {ref attribute}

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

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

Имена столбцов внешних ключей в реляционной модели.

4. Идентификационный столбец или автоматическое создание последовательностей

В зависимости от типа и версии используемой РСУБД, можно настроить, что бы автоматически создавались последовательности. Включить это можно в настройках. Начиная с версии 12с можно использовать простой механизм Identity collumns, подробнее в документации. Однако рекомендую использовать TRIGGER и SEQUENCE. Это более универсальный механизм, потому что SEQUENCE может использоваться для непересекающейся нумерации строк в разных таблицах, базах данных, на разных серверах.

Выбор механизма в настройках SDDM

5. Полезная настройка SDDM

Для работы с создаваемым кодом настройте формат создаваемого скрипта DDL. Выберите удобные вам отступы, формат, прописные или строчные буквы.

Todo.

Третья часть будет посвящена обзору методик именования объектов проектируемых баз данных.

Четвертая часть будет посвящена настройке связи (dblink) с SQL Server и MySQL

Пятая часть будет примером создания веб-сервиса API с использованиям ORDS в гетерогенной среде, т.е. с доступом к данным хранимым помимо Oracle, в SQL Server и MySQL