Создание логической модели данных

Во время анализа информационной структуры был выделен ряд подсистем, функционирование которых требуется автоматизировать:

- студенты;

- преподаватели;

- кафедры;

- специальности;

- предметы;

- ведомости.

Определим одноименные сущности для проектируемой ИС.

Часто в средствах логической разработки используются связи типа сущность-связь – ER диаграммы.

Каждый студент учится по своей специальности, следовательно, прослеживается связь между сущностями «Студенты» и «Специальность». Каждый студент находятся в группе – сущность «Группы».

Каждый преподаватель закреплен за определенной кафедрой и ведет свои предметы, следовательно, имеется связи между сущностями «Преподаватели», «Кафедры» и «Предметы». Каждый преподаватель имеет свою ученую степень на основе, которой ему начисляется заработная плата. Для этого потребуется создать отдельную сущность «Ученые степени» и связать её с сущностью «Преподаватели».

Сущность «Ведомости» формируется за счет сущностей «Предметы» «Преподаватели», «Группы» и «Студенты». Общая логическая модель данных представлена на Рис 2.11.

Рис 2.11 Общая логическая модель данных

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

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

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

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

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

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

информационный моделирование база данных

Таблица находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса и не содержит нетривиальных многозначных зависимостей.

Отношение находится в пятой нормальной форме, когда каждая нетривиальная зависимость соединения в нём определяется потенциальным ключом этого отношения.

Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.

Выделим ключевые атрибуты для каждой сущности (Таблица 1)

Таблица 2.1

Атрибуты сущностей

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

Таблица 2.2

Таблица «Студенты»

Таблица 2.3

Таблица «Преподаватели»

Таблица 2.4

Таблица «Кафедры»

Таблица 2.5

Таблица «Предметы»

Таблица 2.6

Таблица «Специальности»

Таблица 2.7

Таблица «Ученые степени»

Таблица 2.8

Таблица «Группы»

Таблица 2.9

Таблица «Список ведомостей»

Таблица 2.10

Таблица «Ведомости»

Концептуальная модель базы данных информационной системы изображена на рис. 2.12.

Рис. 2.12 Концептуальная модель базы данных информационной системы

Выводы

Во второй главе осуществлено проектирование информационной системы для филиала РГГУ г. Всеволожск.

Проведено проектирование содержания и функционала информационной системы. При помощи CASE-средств построены диаграммы, описывающие функционал и работу системы. Проведено UML моделирование основных функций информационной системы.

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