Как посмотреть связи таблиц oracle sql developer
В главе использованы материалы [apex_lab1 ].
Иметь установленное приложение Oracle SQL Developer Data Modeler 3.1
Иметь доступ к Oracle Database 11g или 10g
15.1.1. Установка Oracle SQL Developer Data Modeler
1. Устанавливаем JDK: см. [MIND ], 3.2-3.3.
2. Устанавливаем Oracle SQL Developer Data Modeler: см. [MIND ], 3.4-3.5.
3. Устанавливаем Oracle SQL Developer: см. [MIND ], 3.6-3.7.
Если выдает ошибку “cannot access nls data files or invalid environment specified” добавляем “AddVMOption -Duser.region=US” во все файлы “sqldeveloper.conf“
4. Устанавливаем Oracle 10g XE: см. [MIND ], 3.8.
15.1.2. Импорт таблиц из HR схемы
В этом разделе создадим соединение с HR схемой. Используя это соединение импортируем таблицы EMPLOYEES и DEPARTMENTS в SQL Developer Data Modeler.
1. Запустите Oracle SQL Developer Data Modeler: выберите Пуск > Программы > DataModeler (или откройте каталог С:\datamodeler, выберите datamodeler.exe, М2).
2. Импортируем таблицы из словаря данных, выберите File > Import > Data Dictionary.
3. Окно Data Dictionary Import Wizard открыто. Создадим соединение с БД, выберите Add.
4. Окно New / Update Database Connection открыто. Введите следующие параметры соединения c локальной СУБД или серверной СУБД и выберите Test.
Connection Name: hr
Connection Name: hr252
5. Статус должен быть Success. Выберите Connect.
6. В окне Data Dictionary Import Wizard выберите hr соединение и нажмите Next.
7. Импортируйте из HR схемы: выберите HR схема и нажмите Next.
8. Выберите таблицы DEPARTMENTS и EMPLOYEES и нажмите Next.
9. Нажмите Finish для генерация модели.
10. Просмотрите log файл создания и нажмите Close.
11. EMPLOYEES и DEPARTMENTS таблицы удачно импортированы в реляционную модель SQL Developer Data Modeler.
Рисунок 15.1. Таблицы EMPLOYEES и DEPARTMENTS импортированы в реляционную модель SQL Developer Data Modeler
 |
15.1.3. Просмотр физической модели
В этом разделе просмотрим физичекую модель автоматически созданную при импорте объектов из словаря данных.
13. В Nagivation Browser раскройте Relational Models > Relational_1.
14. Вы видите физическую модель. Раскройте Physical Models > Oracle Database 10g.
15. Раскройте Tables > HR.DEPARTMENTS > Columns. Просмотрите список. Обратите внимание на другие объекты представленные в физической модели.
Рисунок 15.2. Физическая модельв SQL Developer Data Modeler
 |
15.1.4. Создание таблицы
В этом разделе создадим таблицу PROJECTS. В таблице PROJECTS четыре столбца: PROJECT_ID, PROJECT_NAME, PROJECT_START_DATE, и PROJECT_END_DATE.
16. Выберите New Table в toolbar.
17. Выберите незанятое пространство на диаграмме.
18. Окно Table Properties открыто. Введите PROJECTS для Name и выберите Columns в левом навигаторе.
19. Добавим столбец, выберите Create Column.
20. Введите PROJECT_ID для Name. Выберите Logical для Datatype и NUMERIC для Type.
21. Введите 6 для Precision. Определим PROJECT_ID столбец как первичный ключ. Выберите PK и нажмите Create Column.
22. Введите PROJECT_NAME для Name. Выберите Logical для Datatype иVARCHAR для Type.
23. Введите 100 для Size и нажмите Create Column.
24. Введите PROJECT_START_DATE для Name. Выберите Logical для Datatype и Date для Type. Выберите Create Column.
25. Введите PROJECT_END_DATE для Name. выберите Logical для Datatype и Date для Type. Нажмите OK для создания таблицы.
26. Таблица удачно создана.
Рисунок 15.3. Создание таблицы в SQL Developer Data Modeler
 |
15.1.5. Соединение новой таблицы с выходной таблицей
В этом разделе создадим внешний ключ между таблицами PROJECTS и DEPARTMENTS.
27. Выберите New FK Relation в toolbar.
28. Создадим внешний ключ в таблице PROJECTS, выберите таблицу DEPARTMENTS и выберите таблицу PROJECTS.
29. Окно Foreign Key Properties открыто. Выберите Associated Columns в левом навигаторе.
30. DEPARTMENTS_DEPARTMENT_ID выберите для Child Column и нажмите OK.
31. Выберите Arrow в toolbar. FK Relation создана. Буква 'F' напротив DEPARTMENTS_DEPARTMENT_ID в таблице PROJECTS определяет этот столбец как внешний ключ.
32. Сделаем FK необязательным, выберите линию соединения двух таблиц, МП, выберите Properties.
33. Отключите Mandatory и нажмите OK.
36. FK теперь необязателен. Это означает, что можно иметь проект без отдела.
Рисунок 15.4. Соединение таблиц в SQL Developer Data Modeler
 |
15.1.6. Модификация выходной таблицы
В этом разделе добавим столбец COST_CENTER в таблицу DEPARTMENTS.
37. На диаграмме выберите таблицу DEPARTMENTS. М2.
38. Выберите Columns в левом навигаторе.
39. Создадим новый столбец, выберите Create Column.
40. Введите COST_CENTER для Name, выберите Logical для Datatype, VARCHAR для Type и введите 25 для Size. Нажмите OK для создания столбца.
41. Столбец COST_CENTER создан в таблице DEPARTMENTS.
Рисунок 15.5. Создание столбца в SQL Developer Data Modeler
 |
15.1.7. Создание логической модели
В этом разделе перепроектируем реляционную модель созданием логической модели.
42. Выберите Engineer to Logical Model в toolbar.
43. Окно Engineer to Logical Model открыто. Раскройте Tables. Просмотрите сущности которые будут созданы в логической модели. Нажмите Engineer.
44. Логическая модель создана. Просмотрите сущности и атрибуты. Диаграмма логической модели называется Entity Relationship Diagram (ERD).
Рисунок 15.6. Создание логической модели в SQL Developer Data Modeler
 |
15.1.8. Модификация логической модели
В этом разделе модифицируем логическую модель.
45. Добавим атрибуты в сущность PROJECTS. Выберите сущность PROJECTS, М2.
46. Выберите Attributes в левом навигаторе.
47. Выберите '+' для добавления атрибута.
48. Введите STATUS для Name, выберите Logical для Datatype, выберите VARCHAR для Type, и введите 30 для Size. Выберите атрибут DEPARTMENT_DEPARTMENT_ID из списка.
49. Этот атрибут показывает результат связи между сущностями DEPARTMENTS и PROJECTS. Заметьте, что мы не можем изменить имя этого атрибута. Для этого необходимо изменить параметры настройки. Нажмите OK.
50. Заметьте, что атрибут STATUS добавленный в сущность PROJECTS для связи с DEPARTMENT не показывается на диаграмме. Это происходит так как текущая нотация Barker не показывает такие атрибуты.
51. Изменим значение по умолчанию для атрибутов связи. Выберите Tools > Preferences.
52. Раскройте Data Modeler > Model и выберите Logical. Отключите Keep as the name of the Originating attribute.
54. Выберите сущность PROJECTS, М2.
55. Выберите Attributes.
56. Выберите атрибут DEPARTMENT_DEPARTMENT_ID из списка.
57. Заметьте, что теперь можно изменять имя. Измените имя на PROJECT_DEPT и нажмите OK.
58. Изменим нотацию на Bachman. Выберите свободное пространство на диаграмме, МП, выберите Bachman Notation.
59. Нотация изменена. Теперь мы видим атрибуты связи (с буквой 'F') как и первичные атрибуты. Символ '*' перед именем атрибута означает обязательность атрибута.
60. Добавим сущность в логическую модель. Выберите New Entity icon в toolbar.
61. Выберите свободное пространство на диаграмме.
62. Введите TASKS для Name и выберите Attributes.
63. Выберите '+' для добавления атрибута.
64. Введите TASK_ID для Name, выберите Logical для Datatype, выберите NUMERIC для Type, введите 6 для Precision и выберите Primary UID. Выберите '+'.
65. Введите TASK_NAME для Name, выберите Logical для Datatype, выберите VARCHAR для Type и введите 255 для Size. Выберите '+'.
66. Введите COST для Name, выберите Logical для Datatype, выберите NUMERIC для Type и введите 6 для Precision. Выберите '+'.
67. Введите BUDGET для Name, выберите Logical для Datatype, выберите NUMERIC для Type и введите 6 для Precision и нажмите OK для создания сущности и атрибутов.
68. Создадим две связи между EMPLOYEES и TASKS, и между the PROJECTS и TASKS сущностями. Выберите New 1:N Relation в toolbar.
69. Выберите сущность EMPLOYEES и выберите сущность TASKS.
70. Нажмите OK для создания связи.
71. Создадим вторую связь. Выберите сущность PROJECTS и выберите сущность TASKS.
72. Нажмите OK для создани ясвязи.
73. Изменим имя связи в сущности TASKS. Выберите сущность TASKS, М2.
74. Выберите Attributes свойства.
75. выберите атрибут EMPLOYEES_EMPLOYEE_ID из списка.
76. Измените имя на ASSIGNED_TO и выберите атрибут PROJECTS_PROJECT_ID из списка.
77. Изменим имя на PROJECT_ID и нажмите OK.
78. Изменение логической модели закончено.
Рисунок 15.7. Создание логической модели в SQL Developer Data Modeler
 |
15.1.9. Синхронизация логической модели с реляционной моделью
В этом разделе синхронизируем логическую модель с реляционной моделью.
79. Выберите Engineer to Relational Model.
80. Окно Engineer to Relational Model открыто. Раскройте Entities > PROJECTS > Attributes. Обратите внимание на различия. Нажмите Engineer.
81. Обратите внимание на новый столбец STATUS, измененное имя внешнего ключа PROJECT_DEPT, и новую таблицу TASKS.
Рисунок 15.8. Синхронизация логической модели с реляционной моделью в SQL Developer Data Modeler
 |
15.1.10. Генерация DDL обновления БД
Теперь модели готовы и можно синхронизировать словарь данных с моделью и сгенерировать DDL-скрипт.
82. Выберите Synchronize Data Dictionary with Model в toolbar.
83. Окно Compare Models открыто. Узлы где есть изменения отмечены символом( ). Раскройте Tables узел и увидите новые таблицы PROJECTS и TASKS. Обратите внимание что таблица DEPARTMENTS изменена.
84. Раскройте DEPARTMENTS > Columns. Столбец COST_CENTER добавлен. Нажмите DDL Preview.
85. Сгенерированный код выведен. Просмотрите команды CREATE и ALTER. Заметьте, что таблицы PROJECTS и TASKS создаются и дополняются первичными ключами.
В Oracle SQL Developer, если я просматриваю информацию о таблицу, я могу просматривать ограничения, которые позволяют мне видеть внешние ключи (и, следовательно, на какие таблицы ссылается эта таблица), и я могу просматривать зависимости, чтобы увидеть, какие пакеты и такие ссылки ссылаются на таблицу. Но я не уверен, как найти, какие таблицы ссылаются на таблицу.
Например, скажем, я смотрю на таблицу emp . Существует еще одна таблица emp_dept , которая фиксирует, какие сотрудники в каких отделах работают, и которая ссылается на таблицу emp через emp_id , первичный ключ таблицы emp . Есть ли способ (через какой-либо элемент пользовательского интерфейса в программе, а не через SQL) обнаружить, что таблица emp_dept ссылается на таблицу emp , без необходимости знать, что таблица emp_dept существует ?
Нет. В Oracle SQL Developer такой возможности нет.
Вы должны выполнить запрос вручную или использовать другой инструмент (например, у PLSQL Developer есть такая возможность) . PLSQL Developer использует следующий SQL:
Где r_owner - это схема, а r_table_name - это таблица, для которой вы ищете ссылки. Имена чувствительны к регистру
Будьте осторожны, потому что на вкладке отчетов Oracle SQL Developer есть опция «Все таблицы / зависимости», это из ALL_DEPENDENCIES, который относится к" зависимостям между процедурами, пакетами, функциями, телами пакетов и триггерами, доступными текущему пользователю, включая зависимости от представлений, созданных без любые ссылки на базу данных. ". Тогда этот отчет не имеет значения для вашего вопроса.
Чтобы добавить это в SQL Developer в качестве расширения, сделайте следующее:
- Сохраните приведенный ниже код в XML-файл (например, fk_ref.xml):
Добавьте расширение в SQL Developer:
Перейдите к любой таблице, и теперь вы должны увидеть дополнительную вкладку рядом с таблицей SQL, помеченную FK References, которая отображает новую информацию FK.
Замените [Your TABLE] на emp в запросе ниже
Вы можете запросить это из представления ALL_CONSTRAINTS :
В SQL Developer 4.1, выпущенном в мае 2015 года, добавлена вкладка «Модель», на которой показаны внешние ключи таблицы, которые ссылаются на вашу таблицу в формате диаграммы отношений сущностей.
Это было в продукте в течение многих лет, хотя в продукте этого не было в 2011 году.
Но просто нажмите на страницу модели.
Убедитесь, что у вас установлена как минимум версия 4.0 (выпущенная в 2013 году), чтобы получить доступ к этой функции.
Как насчет чего-то вроде этого:
Чтобы добавить к приведенному выше ответу для плагина разработчика sql, использование приведенного ниже xml поможет получить столбец, связанный с внешним ключом.
Мне нравится делать это с помощью простого SQL-запроса, а не возиться с приложением SQL Developer.
Вот как я это сделал. Лучше всего прочитать это и понять, что происходит, чтобы вы могли настроить его под свои нужды .
Надеюсь из прошлых, почти полностью теоретических, изложений стало немного яснее, что же все-таки есть реляционные данные и все, что с ними связано. Давайте сейчас попробуем просмотреть все это практически. Наша с вами учебная БД в схеме miller содержит, пять таблиц. Все они в принципе отвечают требованиям 3НФ. Но, когда я их создавал, я не связал столбцы этих таблиц между собой с помощью стандартных средств. А, вот сейчас давайте мы с вами это сделаем. Итак для примера организуем связь, которая чаше всего рекомендована к применению, типа один-ко-многим. Ярким примером для построения такой связи служит две из наших пяти таблиц это CUSTOMERS и SALESREPS. Оператор CREATE TABLE их DDL определений записан следующим образом:
Таблица CUSTOMERS:
Таблица SALESREPS:
При просмотре данных, этих таблиц почти сразу видно, что столбец таблицы SALESREPS - EMPL_NUM есть отношение один-ко-многим столбца CUST_REP для таблицы CUSTOMERS. Для определения связи между таблицами воспользуемся оператором ALTER TABLE и запишем вот такую конструкцию:
Все, связь между столбцами таблиц установлена! Все достаточно просто. Теперь действует ограничение ссылочной целостности и нарушить его нам с вами не позволят! Можно убедиться в этом. Столбец таблицы SALESREPS - EMPL_NUM содержит следующее множество значений 101 .. 110 и отдельно 120. Попробуйте что-нибудь вроде:
После ввода, получаем:
Естественно ошибка ORA-02291! А все потому, что множество 101 .. 110 и отдельно 120 не содержит числа 150! И по этому в данном случае не допустимо! Вот и получилось жесткое отношение один-ко-многим! Так же, можно и удалить связь, между столбцами таблиц применив оператор DROP. Но, нужно узнать имя ссылочной целостности в системе. Сейчас мы его знаем благодаря ошибке. А что если, в процессе работы нужно удалить ссылочную целостность, а потом снова восстановить ее! Для этого обратимся к представлению в вашей схеме USER_CONSTRAINTS. Оно содержит все имена ваших ограничений. Дадим такой запрос:
Там где поле CONSTRAINT_TYPE содержит значение R и есть наше ограничение (по моему от REFERENCES, точно не помню!) Получаем имя ограничения - SYS_C003548 (тоже номер был и в ошибке помните?). Вот теперь давайте от него избавимся:
Вот теперь ограничение снято. Повторим наш предыдущий запрос и посмотрим, что содержит USER_CONSTRAINTS сейчас:
Хорошо видно, что осталось только ограничение первичного ключа таблицы CUSTOMERS имеющее имя SYS_C003506. Кроме того, таблица может содержать ограничение на саму себя например все с той же таблицей SALESREPS можно проделать следующее:
Теперь таблица, как бы это лучше сказать - "самоограничилась", хотя это не всегда оправдано, но вполне применимо и может использоваться! Можете сами с этим всем поработать и определить приоритеты, при проектировании БД, оптимизации и определении ссылочных целостностей таблиц! Но, слишком не увлекайтесь, границы сознания не бесконечны и не стоит выходить за границы понимания, а уж во всяком случае выпускать за них свою БД. :)
PL/SQL Developer для работы с запросами Oracle, автоматическая генерация запросов в Query Builder, интеграция справки Oracle, экспорт результатов выполнения запроса
SQL*Plus — во многих ситуациях незаменимая программа, однако при написании в ней кода SQL и PL / SQL приходится выполнять множество лишних действий, например, писать вручную код, который можно сгенерировать автоматически, или постоянно проверять имена таблиц, столбцов, связи между таблицами и т.п.
Поэтому профессиональные разработчики часто используют программные средства третьих производителей, которые позволяют упростить работу по написанию кода SQL и PL / SQL .
Одним из таких программных средств является PL / SQL Developer производства фирмы Allround Automations . В нем предусмотрено множество программных средств, которые могут существенно упростить работу по созданию кода SQL и PL / SQL . Например, представим себе следующую ситуацию. Нам нужно выбрать информацию о номере сотрудника, его имени, должности и отделе, к которому он относится. При этом информация о сотруднике (столбцы empno , ename и job ) хранится в таблице SCOTT . EMP , а информация об отделах — в таблице SCOTT . DEPT . Обе таблицы связаны по столбцу DEPTNO (в EMP — внешний ключ, в DEPT — первичный).
В SQL*Plus нам потребовалось бы вначале определить структуру таблиц и связи между ними (средствами SQL*Plus или другими способами), потом записать весь код вручную и запустить его на выполнение. В PL / SQL Developer для создания такого запроса код можно не писать вообще (и ничего не знать о структуре базы данных и отношениях между таблицами).
Выглядеть последовательность действий может следующим образом:
1. После запуска PL / SQL Developer в меню File нужно выбрать New | SQL Window. Откроется окно для создания запросов SQL .
2. Из меню Tools запускаем Query Builder (построитель запросов можно также запустить, если выбрать команду Query Builder из контекстного меню для пустого пространства в окне SQL ).
3. В окне Query Builder в списке объектов слева нужно выбрать требуемые таблицы и перетащить их в центр экрана. Можно предварительно настроить фильтр для отображения объектов, например, выбрав My Objects . Если таблицы связаны между собой отношениями, вам будет предложено подтвердить использование этих отношений в специальном окне (см. рис. 1.3.1-1).
Если нужные связи по каким-то причинам автоматически не были определены, их можно настроить вручную, перетащив столбец из одной таблицы на соответствующий столбец другой.
4. После того, как связи будут настроены, осталось выбрать нужные столбцы и настроить дополнительные параметры запроса в нижней части окна Query Builder — фильтр WHERE , сортировку и т.п. После нажатия на кнопку OK окно Query Builder будет закрыто, а сгенерированный код запроса помещен в окно SQL . Запустить на выполнение запрос можно при помощи кнопки F 8 (или при помощи меню Session | Execute) .
Отметим важную особенность, связанную с отображением возвращаемых результатов в PL / SQL Navigator . По умолчанию для экономии памяти PL / SQL Navigator отображает только то количество строк, которое умещается в окне результатов. Чтобы показать все результаты, после выполнения запроса нужно нажать Alt | End или воспользоваться кнопкой Fetch last page в заголовке окна результатов. В противном случае можно не понять, сколько всего записей возвращает запрос.
В PL / SQL Developer предусмотрено множество очень полезных возможностей (особенно для создания программных модулей PL / SQL ). Ниже будут перечислены только самые важные из них:
· предусмотрена интеграция с официальной документацией Oracle (любых последний версий). Для этого в меню Help нужно выбрать HTML Manuals и определить каталог файловой системы, в которой находится документация (можно также просто скачать ее из Интернета). После этого справку по ключевым словам SQL и PL / SQL , например, по встроенным функциям Oracle можно будет получать просто установив указатель ввода на ключевое слово и нажав на клавишу F 1;
· вся информация об объектах базы данных Oracle (как пользовательских. так и служебных) представлена в специальном окне Browser . В этом окне можно просмотреть структуру объектов, внести в них изменения, автоматически генерировать различные команды и т.п. При необходимости можно настроить фильтры для отображения объектов (команды меню Tools | Browser Folder и Tools | Browser Filters );
· в PL / SQL Developer предусмотрена подсветка синтаксиса и подсказка по именам объектов (см. рис. 1.3.1-2). Создание программного кода также упрощает набор встроенных шаблонов с наиболее часто встречающимися синтаксическими конструкциями SQL и PL / SQL . Открыть окно шаблонов можно при помощи меню Tools | Template List .
Рис. 1.3.1-2 Подсказка при вводе программного кода в PL/SQL Developer
· в PL / SQL Developer предусмотрены мощные средства отладки и тестирования создаваемого кода (в основном они сосредоточены в меню Debug ). Вы можете использовать точки останова с пошаговым выполнением и просмотром значений переменных, а также использовать встроенные средства Oracle , такие, как dbms _ trace ;
· предусмотрены средства оптимизации производительности создаваемого кода. Например, в PL / SQL Developer выводится информация о времени выполнения кода, затраченных ресурсах центрального процессора, количестве логических и физических операций чтения и записи и т.п. Можно выбирать цель оптимизатора, просматривать предлагаемые планы выполнения и т.п.
· для анализа отношений между таблицами в PL / SQL Developer предусмотрены средствами для работы с диаграммами. Созданные диаграммы можно например, сохранить как изображение, а можно использовать в качестве рабочей области для обычных операций с объектами базы данных Oracle (например, генерации скриптов);
· результаты выполненя запросов можно экспортировать в пользовательские форматы, например, CSV (чтобы открыть в Excel ) или XML ;
· предусмотрены средства поиска объектов базы данных, импорта и экспорта объектов, сравнения объектов, генерации данных в таблицах и т.п.
Статьи появились благодаря вопросам студентов на семинарах по СУБД. Каждый студент должен был выбрать тему для проектирования базы данных, реализовать полный цикл проектирования от логической и физической диаграммы в Oracle SQL Developer Data Modeler ( SDDM ) до работающей базы данных в СУБД Oracle с использованием APEX. Затем стать пользователем своей разработки: заполнить схему данными и написать аналитические запросы. Некоторые возможности SDDM оказались неочевидными и мы потратили полтора занятия, что бы рассмотреть самое необходимое.
Некоторым студентам, имеющим некоторый стихийно накопленный опыт разработки приложений с использованием СУБД, тяжело перестраиваться на анализ предметной области, трудно понять важность методик проектирования реляционной модели. Потому статья начнется с напоминания порядка разработки.
Не надо сразу делать таблицы. Порядок разработки следующий:
- анализ данных, процессов обработки информации и бизнес-правил, документирование собранной информации
- выявление и определение сущностей
- выявление, описание атрибутов сущностей, определение типов атрибутов
- выявление, описание и определение типов связей между сущностями
- создание матрицы связей и проверка идеи на прочность анализом матрицы связей, документирование бизнес-правил и ограничений
- создание логической диаграммы сущность-связь (ERD) в SDDM, в свойствах атрибутов и связей в том числе отражаются бизнес-правила и ограничения, те что не могут быть реализованы в СУБД описываются отдельным документом и реализуются на прикладном уровне триггерами
Статью готовил я, Присада Сергей Анатольевич, сейчас работаю в Финансовом университете при Правительстве РФ, почта sergey.prisada на яндексе.
План работы.
- Создание нескольких дисплеев для отображения различных нотаций.
- Естественные первичные ключи, или создаваемые вручную, их отображение.
- Соответствие атрибутов связи – правила создания и отображения. Шаблоны именования внешних ключей и иных объектов при преобразовании в реляционную модель.
- Идентификационный столбец или автоматическое создание последовательностей
- Полезная настройка SDDM
1. Создание нескольких дисплеев для отображения различных нотаций.
Выбрать его правой клавишей, далее “Properties”
Выбор нотации для каждого “Display”
2. Естественные первичные ключи, или создаваемые вручную, их отображение.
Перейдите в созданный “Display” с именем “Bachman”, в нотации Бахмана можно отобразить внешние ключи на диаграмме: в меню “View” – “View Details” – “All Details”. Отобразятся все свойства сущностей и связей, определённые в логической модели.
При создании связи между сущностями подразумевается связь между первичным уникальным идентификатором родительской сущности и одним из атрибутов дочерней сущности. При этом требуется, чтобы свойства атрибута дочерней сущности, объявляемого внешним ключом, были идентичны первичному уникальному идентификатору родительской сущности.
С целью облегчения проектирования, при создании логической модели SDDM автоматически создает атрибут для внешнего ключа в дочерней сущности. Самостоятельно его создавать не следует. Изменить это поведение нельзя. Имя создаваемого атрибута для вторичного ключа будет состоять из имени и имени первичного ключа родительской сущности с разделителем в виде символа нижнего подчеркивания “_”.
Две сущности, между ними создадим неопределяющую связь 1:N, рассмотрим свойство связи и созданный внещний ключ в свойствах дочерней сущности.
В дочерней сущности “Course” автоматически создан внешний ключ “Department_Dept_name”
Свойства созданного внешнего ключа нельзя изменить, они соответствуют свойству PUID родительской сущности. Можно изменить имя созданного атрибута для внешнего ключа.
В свойствах созданного атрибута для внешнего ключа можно указать изменить его обязательсть чекбокс “M” – это повлияет на свойство обязательности связи. Также можно внешний ключ включить в состав первичного ключа – в этом случае связь будет определяющей.
Удобнее смотреть свойства всех атрибутов в виде таблицы на вкладке “Overview”.
ВАЖНО: при логическом проектировании не требуется заранее определять атрибуты для внешних ключей. Цель логического проектирования – создание логической модели и приведение её минимум к третьей нормальной форме. Внешние ключи являются атрибутами, которые согласно анализу информации, будут являться характеристиками сущности, которые имеют транзитивную зависимость (вторая нормальная форма), поэтому при декомпозиции отношения они должны быть устранены из сущности в другую сущность. Если на логической диаграмме до создания связей в свойствах сущностей есть атрибуты для внешних ключей, то сущности не приведены к третье нормальной форме, а атрибуты на диаграмме дублируются. Дублирующихся атрибутов не должно быть.
Поэтому нет возможности при логическом проектировании свободно назначить атрибут для внешнего ключа. Это задача проектирования реляционной модели. Следует создать сущности в третьей нормальной форме без повторения атрибутов в сущностях на диаграмме, а затем построить связи в соответствии с матрицей связей.
3. Соответствие атрибутов связи – правила создания и отображения. Шаблоны именования внешних ключей и иных объектов при преобразовании в реляционную модель.
Создаваемые автоматически атрибуты внешних ключей, имена ограничений внешних ключей, первичные ключи, индексы и иные объекты, при преобразовании в реляционную модель не всегда имеют удобные для обработки человеком наименования. Если создаваемая база данных будет использоваться только информационными системами, такими как сетевые сервисы или серверы приложений, то лучше оставить автоматические имена. Это гарантирует их уникальность, а правила генерации имён отображают логику и понятный алгоритм их создания. Для удобства работы человека нужно использовать псевдонимы объектов – “Alias”, а также заранее создавать пакеты и процедуры. При этом, в SDDM предусмотрен механизм настройки правил именования автоматически создаваемых объектов.
Выбрать модель, правой клавишей, “Properties”.
Шаблоны именований создаваемых автоматически объектов настриваются в разделе настроек “Settings” – “Naming Standart” – “Templates”. Все возможные переменные отобразятся при нажатии “Add Variable”.
Типы объектов — это термины из реляционной модели и должны быть понятны интуитивно. Переменные, доступные для использования в шаблонах имён, описаны в поле комментарий интерфейса. Дополнительная информация в официальной документации к SDDM.
В качестве примера изменим значение шаблона именования атрибута внешнего ключа, что бы создаваемое имя совпадало с именем атрибута первичного ключа родительской сущности. Изменять надо два шаблона: для логической и реляционной модели
Шаблон для реляционной модели называется “Column Foreign Key”:
Шаблон для логической модели называется “Attribute Relation”:
Пересоздадим связь между сущностями, преобразуем в реляционную модель и рассмотрим имена созданных атрибутов в логической модели и внешних ключей в реляционной модели.
Имена атрибутов связи в логической модели.
Имена столбцов внешних ключей в реляционной модели.
4. Идентификационный столбец или автоматическое создание последовательностей
В зависимости от типа и версии используемой РСУБД, можно настроить, что бы автоматически создавались последовательности. Включить это можно в настройках. Начиная с версии 12с можно использовать простой механизм Identity collumns, подробнее в документации. Однако рекомендую использовать TRIGGER и SEQUENCE. Это более универсальный механизм, потому что SEQUENCE может использоваться для непересекающейся нумерации строк в разных таблицах, базах данных, на разных серверах.
Выбор механизма в настройках SDDM
5. Полезная настройка SDDM
Для работы с создаваемым кодом настройте формат создаваемого скрипта DDL. Выберите удобные вам отступы, формат, прописные или строчные буквы.
Третья часть будет посвящена обзору методик именования объектов проектируемых баз данных.
Четвертая часть будет посвящена настройке связи (dblink) с SQL Server и MySQL
Пятая часть будет примером создания веб-сервиса API с использованиям ORDS в гетерогенной среде, т.е. с доступом к данным хранимым помимо Oracle, в SQL Server и MySQL
Читайте также: