Итоговая проверка качества ER - диаграммы.

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

  1. выравнивать четырехугольники, отображающие КО;
  2. линии связи прямые и направленные вверх, по горизонтали и по диагонали;
  3. для диагональных линий использовать углы в 30 или 60 градусов, это упрощает чтение, если связи пересекаются;
  4. избегать большого количества параллельных линий, их трудно отслеживать;
  5. избегать сокращений и жаргонов;
  6. добавлять прилагательные для облегчения понимания;
  7. выравнивать текст по горизонтали;
  8. имена связей указывать на концах линий с разных сторон от неё

 

  1. стараться упрощать чтение диаграммы рекомендуется располагать "воронью лапу" слева и сверху линии, т.е. самые динамичные и объемные объекты всегда располагать ближе к верхней и левым частям диаграммы – "мертвые вороны летят на восток";
  1. до тех пор, пока связь М:М не будет разрешена, один конец должен указывать вниз или направо;
  2. необходимо делать диаграмму запоминающейся;
  3. нежелательно вычерчивать диаграмму на сетке;
  4. для улучшения вида уменьшать или увеличивать прямоугольники.

ER-диаграмма должна читаться как непрерывное предложение, начиная с любого места. Используются такие связывающие фразы как "что является" или "каждый из которых".
Готовая ER-диаграмма должна легко читаться и иметь смысл с точки зрения бизнеса.

Проверка законченности и качества модели

Прежде чем переходит к следующему этапу проектирования БД необходимо убедиться в законченности и качестве ER-модели.

Классы объектов:1) четырехугольник с закругленными углами; 2) название в единственном числе, заглавными буквами; 3) может иметь необязательное имя - синоним; 4) обязательно имеет уникальный идентификатор.
Свойства: 1) имя пишется строчными буквами и не должны включать имя сущности; 2) атрибут имеет одну из меток * - обязательный атрибут, о – необязательный атрибут, # - свойство входит в УИ.
ПОДТИПЫ: 1) полностью описывают сущность; 2) не перекрывают друг друга; 3) существование каждого типа должно быть оправдано (разные свойства, разные связи).
СВЯЗИ: 1) каждая сторона должна иметь имя (пишется строчными буквами), мощность и опциональность.

Связь между классами объектов А и В

Частота появления

Замечание

 

очень распространена

Каждому объекту из КО А д. соответствовать обязательно один объект из КО В.
Каждому объекту из КО В м. соответствовать 0, 1 или более объектов КО А.

 

 


распространена

Каждому объекту из КО А м. соответствовать один объект из КО В.
Каждому объекту из КО В м. соответствовать 0, 1 или более объектов КО А.

 

довольно часто

Каждому объекту из КО А м. соответствовать один объект из КО В.
Каждому объекту из КО В д. обязательно соответствовать 0, 1 или более объектов КО А.

 

 

редко

Каждому объекту из КО А д. соответствовать обязательно один объект из КО В.
Каждому объекту из КО В д. соответствовать обязательно 0, 1 или более объектов КО А.

 

распространена на начальных этапах

требует разрешения

 

распространена на начальных этапах

требует разрешения

 

 

очень маловероятна

требует разрешения

 

 

редко

возможно это один и тот же КО

 

 

редко

возможно это один и тот же КО

 

 

маловероятно

возможно это один и тот же КО

Поверка рекурсивных связей

Действительные связи

 

Недействительные связи
 

Проверка взаимоисключающих связей (арк)

Действительные связи

 

Недействительные связи

 

Проверка опциональности связей.

Необходимо проверить:

  1. обязательные связи – действительно ли связь должна существовать, т.е. объект не м.б. создан без одновременного создания связи;
  2. необязательные связи – действительно ли связь только может существовать, может ли объект существовать без этой связи.

Пример
 

Может ли Служащий существовать без Табеля?
Может ли Служащий существовать без Работы?

Проверка свойств КО

1 Все ли свойства разбиты на мельчайшие атомарные компоненты? (ФИО, адрес и т.п.)
2 Все ли атрибуты имеют только одно значение?
Пример

 

Свойство "дата контакта" может иметь несколько значений для одного и того же Клиента. Поэтому необходимо создать дополнительный КО.

3 Каждый ли атрибут зависит от всего УИ (уникального идентификатора) класса объектов?

Пример
1)
 

Должность – это отдельный КО, у неё есть код (классификатор), название, краткое название. И эти все свойства уже не зависят от УИ – Номер работы.

2)
 

Это нормализация (приведение ко 2 и 3 НФ) на уровне построения ИЛМ предметной области – чем больше отдельных существительных предметной области выделено, тем более нормализованной будет схема будущей БД.

Перекрестная проверка ER-модели.

Перекрестная проверка – это проверка полученной модели данных на соответствие выполнения определенной иерархии функций разрабатываемой АИС.

Пример
Предметная область – «Аренда помещений»
Выявлена следующая иерархия функций решения задачи:


Соединение с БД

 

 

 

 

 

 

 

Ведение справочных данных

 

 

 

 

Помещение

Добавление/Обновление

Ф1

 

 

Просмотр

Ф2

 

 

 

 

Ведение учетных данных

Фирма

Добавление/Обновление

Ф3

 

 

Просмотр/Печать

Ф4

 

 

 

 

 

Физическое лицо

Добавление/Обновление

Ф5

 

 

Просмотр/Печать

Ф6

 

 

 

 

 

Договор

Добавление/Обновление

Ф7

 

 

Просмотр/Печать

Ф8

 

 

 

 

Формирование отчетов

 

 

 

 

Отчет 1

Формирование

Ф9

 

 

Просмотр/Печать

Ф10

 

 

 

 

 

Отчет 2

Формирование

Ф11

 

 

Просмотр/Печать

Ф12

 

 

 

 

 

Отчет 3

Формирование

Ф13

 

 

Просмотр/Печать

Ф14

Отчет 1 – Список физических лиц (Номер, Ф, И, О), когда-либо заключавших договоры на аренду помещений.
Отчет 2 – Количество договоров на аренду, заключенных за заданный период времени.
Отчет 3 – Список арендаторов (фирм и физических лиц), заключавших когда-либо договора на аренду для заданного помещения.
Построена следующая модель предметной области – рисунок

 

Рисунок – ER-диаграмма предметной области «Аренда помещений»

Перекрестную проверку удобно осуществлять, используя такую таблицу:


Класс объектов/
Функция

ПОМЕЩЕНИЕ

ФИРМА

ФИЗИЧЕСКОЕ ЛИЦО

ДОГОВОР НА АРЕНДУ

Ф1

I, R, U

 

 

 

Ф2

R

 

 

 

Ф3

 

I, R, U

 

 

Ф4

 

R

 

 

Ф5

 

 

I, R. U

 

Ф6

 

 

R

 

Ф7

R

R

R

I

Ф8

R

R

R

R

Ф9

 

 

R

R

Ф10

 

 

R

R

Ф11

 

 

 

R

Ф12

 

 

 

R

Ф13

R

R

R

R

Ф14

R

R

R

R

где:


I -

Insert (добавление);

U -

Update(обновление);

R -

Read (чтение).

Формализованная с помощью таблицы проверка позволяет сделать следующие выводы:
- если в таблице присутствуют пустые столбцы, то получена избыточная модель данных – выявленный класс объектов не используется ни одной функцией;
- если в таблице присутствуют пустые строки, то модель является недостаточной – для реализации функций автоматизированной информационной системы в предметной области не определены классы объектов;
- если в таблице нет пустых строк и столбцов, то модель является достаточной.

Яндекс.Метрика