2.3 Связи
Теперь рассмотрим связи между сущностями.
Все связи в БД являются связями один-ко-многим. Связи между сущностями Личн_дан и Студент, Личн_дан и Родители, Личн_дан и Студ_комн, Личн_дан и Неуплата, Студент и Студ_груп, Группа и Студ_груп, Изменения и Студ_измен, Студент и Студ_измен являются идентифицирующими, так как вторичный ключ попадает в атрибуты первичного ключа другой сущности.
Сущности Форм_об и Тарифы, Статус и Тарифы, Факультет и Группа, Спефиальность и Группа, Студент и Тарифы, Студ_комн и Комната, Личн_дан и Архив соединены неидентифицирующими связями, так как вторичный ключ попадает в список неключевых атрибутов.
Физическая модель
На рисунке 2 представлена физическая модель БД с указанными типами данных. Физическая модель – СУБД-ориентированная модель БД. Она жестко связана с конкретной СУБД. Появляются таблицы, реальные типы данных, ограничения и т.п.
Рисунок 2 – Физическая модель
Отчет по ошибкам изValidator
Проверим разработанную физическую модель базы данных на ошибки средствами Validator. На рисунке 3 приведен результат первой проверки ошибок.
Рисунок 3 – Первая проверка
Validator обнаружил 25 ошибок, из которых 3 ошибки моделирования колонок (столбцов), 16 ошибок моделирования индексов и ограничений, 5 ошибок нормализации и 1 ошибка моделирования связей. Исправим эти ошибки.
Начнем с исправления ошибок моделирования колонок.
Рисунок 4 – исправлены ошибки моделирования колонок
Осталась 21 ошибка. Исправляем ошибки моделирования индексов и ограничений.
Рисунок 5 – Исправлены ошибки моделирования индексов и ограничений
Теперь приступаем к исправлению ошибок нормализации.
Рисунок 6 – Исправлены ошибки нормализации
И, наконец, исправляем последнюю ошибку – ошибку моделирования связей.
Рисунок 7 – Исправлена ошибка моделирования связей
Все ошибки исправлены, что и представлено на рисунке 8
Рисунок 8 – итоговая проверка
Прямое проектирование
Теперь, когда исправлены все ошибки, найденные Validator, проведем прямое проектирование нашей базы данных в Oracle.
Рисунок 9 – итог прямого проектирования
После проверки наличия ключевых полей, значений по умолчанию, условий проверки вводимых пользователем значений, связей между таблицами проверяем работоспособность базы данных. Для этого введем данные в таблицы БД. На рисунках 10 – 25 представлены заполненные данными таблицы.
Рисунок 10 – Форм_об
Рисунок 11 - Статус
Рисунок 12 - Факультет
Рисунок 13 - Специальность
Рисунок 14 - Комната
Рисунок 15 - Тарифы
Рисунок 16 - Группа
Рисунок 17 – Личн_дан
Рисунок 18 - Изменения
Рисунок 19 – Студент
Рисунок 20 – Студ_измен
Рисунок 21 – Студ_груп
Рисунок 22 – Студ_комн
Рисунок 23 - Архив
Рисунок 24 - Неуплата
Рисунок 25 – Родители
Так как с данной базой данных могут работать три типа пользователей, необходимо каждому типу пользователей предоставить определенные права, то есть разрешить или запретить совершать определенные действия с базой данных. Данную функцию можно осуществить при помощи команды DCL (Data Control Language) GRANT – добавить привилегию.