Вместо вступления.
Эта статья и её продолжение появились благодаря вопросам студентов на семинарах по СУБД. Каждый студент должен был выбрать тему для проектирования базы данных, реализовать полный цикл проектирования от логической и физической диаграммы в 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.Скачайте пример
Модель из статьи вы можете скачать по ссылке на Github: https://github.com/saprisada/odm
Изучите её как пример, создайте аналог, прочтите дополнительно документацию и примените знания в своём проекте.