1Модель предметной области
Деканат – это организационный центр по управлению работой отдельно взятого факультета высшего учебного заведения. В его задачи входят координация и административное обеспечение учебного процесса, ведение делопроизводства.
По данным технического задания, необходимо рассмотреть следующую функцию деканата: контроль работы преподавателей и студентов на предмет соответствия учебному плану. Под этим понимается контроль успеваемости студентов для того, чтобы сделать вывод о возможности перевода студента на следующий курс, а так же распределение сил преподавательского состава.
Для нашей модели примем следующие правила:
Все студенты, обучающиеся на факультете, строго очной формы обучения;
Все студенты учатся на квалификацию Бакалавра;
Будем считать, что фамилия, имя и отчество это одна строка;
Студенты будут однозначно идентифицироваться по зачетным книжкам;
О студентах будет фиксироваться следующая информация: номер зачетки, ФИО, дата рождения, адрес прописки, контактный телефон, номер группы, сведения об обучении за границей, сведения о принадлежности к кафедре, сведения о принадлежности к группе;
Каждый преподаватель будет однозначно идентифицироваться номером;
О преподавателях будет фиксироваться следующая информация: ID (от англ. identifier), ФИО, должность, сведения о принадлежности к кафедре, контактный телефон, читаемые дисциплины;
Каждая дисциплина и каждая кафедра однозначно определяются уникальным идентификационным номером.
Также в разрабатываемой базе данных должно быть учтено, что:
один и тот же преподаватель может вести несколько предметов или не вести их вовсе;
разные группы могут посещать один и тот же предмет;
у одной группы не может быть ни одной дисциплины;
у нескольких групп может быть одинаковый набор экзаменов.
В общем случае информация о кафедре должна браться из отдельного отношения, а все группы факультета хранится в отдельном реестре, через который можно узнать о специальности студента и принадлежности к кафедре.
2Логическая модель данных
Деканат разрабатывает базу данных, чтобы иметь возможность быстрого доступа к информации о студентах, преподавателях, и предметах, читаемых на каждом курсе. Таким образом, мы имеем как минимум следующие сущности:
Сущность «Студент»;
Сущность «Преподаватель»;
Сущность «Дисциплина».
Рассмотрим возможные связи между сущностями. Далее будем преимущественно использовать нотацию Питера Чена для графического представления ER-диаграмм.
Начнем с сущностей «Студент» и «Преподаватель». Совершенно очевидно, что несколько студентов могут посещать лекции нескольких преподавателей, а несколько преподавателей могут вести предмет у нескольких студентов. Таким образом, мы имеем степень связи «многие-ко-многим». Так как преподаватель в общем случае может ничего не вести, у сущности «Преподаватель» необязательный класс принадлежности по отношению к сущности «Студент», напротив, студенты не могут ничего не изучать, поэтому у них класс принадлежности обязательный. Определим предварительный набор атрибутов отношений, которые впоследствии образуются из этих сущностей (таблица 2.1).
Таблица 2.1
-
Имя атрибута
Тип данных
Примечание
Сущность «Студент»
Номер зачетки
Текстовый
ключевой
ФИО
Текстовый
Дата рождения
Дата/время
Адрес прописки
Текстовый
Контактный телефон
Текстовый
Номер группы
Числовой
Обучение за границей
Логический
«Да» или «Нет»
Кафедра
Числовой
Сущность «Преподаватель»
ID
Текстовый
ключевой
ФИО
Текстовый
Должность
Текстовый
Кафедра
Числовой
Контактный телефон
Текстовый
Так как деканату важен только результат, полученный студентом на сессии, то совершенно бессмысленно связывать сущности «Дисциплина» и «Студент» напрямую, напротив, важно знать какой предмет ведет какой преподаватель.
В общем случае один преподаватель может вести несколько дисциплин, а одна дисциплина может вестись несколькими преподавателями, поэтому степень связи здесь тоже «многие-ко-многим». Так как преподаватель может ничего не вести, то по отношению к дисциплинам у него тоже необязательный класс принадлежности. Дисциплины тоже могут не вестись ни одним преподавателем, поэтому класс принадлежности так же необязательный по отношению к преподавателям.
Введем в сущность «Дисциплина» атрибуты (таблица 2.2) и поясним все сказанное выше, так называемой, диаграммой ER-типов (рисунок 2.1).
Таблица 2.2
-
Имя атрибута
Тип данных
Примечание
Сущность «Дисциплина»
ID
Числовой
порядковый номер записи, ключевой
Наименование
Текстовый
Количество часов
Числовой
Год обучения
Числовой
номер курса
Рисунок 2.1 Диаграмма ER-типов в нотации Чена
Далее атрибуты в диаграммах будем опускать в целях экономии места. Преобразуем степень связи «многие-ко-многим» в степень «один-ко-многим», введя промежуточную сущность. Для этого сущности «Преподаватель» и «Дисциплина» свяжем через сущность «Учебный год», при этом в одном учебном году у одной дисциплины может быть много экземпляров, которые ведутся разными преподавателями. При этом атрибуты «ID» в сущности «Преподаватель» и «ID» в сущности «Дисциплина» образовали составной внешний ключ в сущности «Учебный год». Таким образом, один преподаватель может иметь много учебных часов в учебном году и одна дисциплина может многократно читаться в учебном году (рисунок 2.2).
Если мы сейчас свяжем сущность «Преподаватель» и «Студент» через некоторую третью сущность, то продублируем данные о преподавателе в базе данных. Это означает, что преподаватель будет фигурировать в некоторой новой сущности и в сущности «Учебный год», а так как они никак не связаны, то это может породить аномалии в будущем. Чтобы этого не произошло, попытаемся «завязать» сущность «Студент» на уже готовой сущности «Учебный год», для чего поместим в нее атрибут «Номер зачетки», т.е. «завязав» через внешний ключ.
Рисунок 2.2 Введение сущности «Учебный год»
Таким образом, образом диаграмма ER-типов примет вид, показанный на рисунке 2.3. Так как студенты не могут не иметь дисциплин в учебном году, класс принадлежности «Учебный год» становится обязательным по всем направлениям (т.е. дисциплина не может никем не вестись). Нетрудно заметить появившуюся проблему в сущности «Учебный год», а именно, наш составной ключ теряет свойство уникальности: так как в группе может быть несколько студентов, то совершенно очевидно, что у всех них один предмет ведет один и тот же преподаватель. Однако, в данной ситуации это не так важно, потому что можно снова разбить степень связи «многие-ко-многим» вводом новой сущности. На рисунке 1.4 представлен результат разбиения путем введения новой сущности «Сессия».
Рисунок 2.3 Привязка сущности «Студенты»
Рисунок 2.4 Введение сущности «Сессия»
Введем атрибуты в сущности «Учебный год» и «Сессия» (таблица 2.3). В физической реализации удобней всего будет использовать простой первичный ключ, поэтому в сущность «Учебный год» искусственно введем атрибут «ID», который является строковым счетчиком.
Если формой сдачи дисциплины является зачет, то в поле оценка нужно ставить 2, если он не сдан, и 5, если сдан.
Анализируя таблицы 2.1 – 2.3 можно прийти к выводу, что условие целостности внешних ключей выполнено. Действительно, номер зачетной книжки повторяться, не может (согласно введенному нами правилу); каждый преподаватель имеет свой идентификационный номер; экземпляры дисциплин образованы строковым счетчиком, как и экземпляры сущности «Учебный год». Составной ключ сущности «Сессия» не может повториться, так как студент не может сдать за один период один и тот же предмет несколько раз.
Таблица 2.3
-
Имя атрибута
Тип данных
Примечание
Сущность «Учебный год»
ID
Числовой
порядковый номер записи, ключевой
Предмет
Текстовый
ID сущности «Дисциплина»
Преподаватель
Числовой
ID сущности «Преподаватель»
Сущность «Сессия»
Предмет
Числовой
ID сущности «Учебный год», ключ
Студент
Текстовый
ID сущности «Студенты», ключ
Результат
Числовой
от 2 до 5 или NULL
Форма сдачи
Текстовый
«Экзамен» или «Зачет»
Так как целостность внешних ключей выполняется, возьмем диаграмму 2.4 за базу и введем в нее сущности «Кафедра», «Группа факультета», «Специальность» и «Успеваемость». В сущности «Кафедра» будут фиксироваться все кафедры данного факультета; в сущности «Группа факультета» будут фиксироваться группы, еще не закончившие обучение; в сущности «Специальность» будут фиксироваться специальности, преподаваемые на факультете (используется главным образом для упрощения заполнения базы данных); в сущности «Успеваемость» будет фиксироваться средний балл каждого студента за каждый курс.
На рисунке 2.5 показан окончательный вариант диаграммы ER-типов, который будет реализован в следующей главе, а в таблице 2.4 описаны атрибуты и типы данных оставшихся сущностей. Все рассуждения, проведенные для сущностей «Преподаватель», «Студент» и «Дисциплина», справедливы и для этих сущностей. Отметим, что преподаватель в общем случае, может не принадлежать ни к какой кафедре факультета (например, он числится на другом факультете ВУЗа), сущность «Специальность» введена, чтобы не терять информацию о специальностях после выпуска студентов.
Выделим некоторые явные ограничения для поддержания целостности базы данных.
Экземпляры сущности «Успеваемость» не должны противоречить экземплярам сущности «Сессия». Например, студент не может иметь записей в сущности «Успеваемость», если он еще на первом курсе;
Значения домена «Результат» сущности «Сессия» должны иметь значения в виде целых чисел от 2 до 5 или иметь NULL значение;
В сущность «Успеваемость» заносится средний балл по всем экзаменам отдельно взятого студента. Если студент сессию не закрыл, то данные не вносятся (другими словами, экземпляры должны быть полностью укомплектованы).
Рисунок 2.5 Окончательная диаграмма ER-типов
Таблица 2.4
-
Имя атрибута
Тип данных
Примечание
Сущность «Кафедра»
ID
Числовой
порядковый номер записи, ключевой
Название кафедры
Текстовый
Контактный телефон
Текстовый
Сущность «Группа факультета»
Номер группы
Числовой
уникальный, ключевой
Год обучения
Числовой
номер курса
Код специальности
Текстовый
Выпускающая каф.
Числовой
ID сущности «Кафедры»
Сущность «Специальность»
Код специальности
Текстовый
ключевой
Наименование
Текстовый
Продолжительность
Числовой
Сущность «Успеваемость»
Студент
Текстовый
студенческий билет, ключевой
Год обучения
Числовой
номер курса, ключевой
Средний балл
Числовой