Области применения файлов. Предметная область - экзамены

После этого выделим сущность «Экзамен». Каждый экземпляр этой сущности будет соответствовать конкретному экзамену, проводимому в данном учебном заведении. Атрибутами сущности «Экзамен» будут являться: «Дисциплина», «Дата», «ФИО преподавателя», «Номер группы». Для однозначной идентификации добавим атрибут «Номер экзамена», который будет являться ключевым атрибутом сущности «Экзамен».

И наконец, выделим сущность «Оценка». Каждый экземпляр этой сущности будет соответствовать оценке, полученной конкретным студентом за конкретный экзамен. Атрибутами сущности «Оценка» будут являться: «Балл», «Номер зачетки», «Дисциплина», «Дата», «Преподаватель», «Номер экзамена». Поскольку оценку за каждый конкретный экзамен студент получает только один раз,  экземпляр сущности «Оценка» однозначно идентифицируется по составному атрибуту: «Номер экзамена» + «Номер зачетки».

Определенные наборы атрибутов сущностей сведем в таблицу 1. Ключевые атрибуты выделены жирным шрифтом.

В рассматриваемой нами модели существуют связи между сущностями. Связь представляет взаимодействие между сущностями. На основании этих связей создадим семантическая модель предметной области «Экзамены», представленную на рисунке 1.

 

 

 

 

Таблица 1 Наборы атрибутов сущностей семантической модели

СТУДЕНТ	ГРУППА	ПРЕПОДАВАТЕЛЬ	ЭКЗАМЕН	ОЦЕНКА
Номер зачетки	Номер группы	Код преподавателя	Номер экзамена	Номер экзамена
ФИО	Специальность	ФИО	Дисциплина	Номер зачетки
Номер группы		Должность	Дата	Балл
Специальность		Ученая степень	ФИО преподавателя	Дисциплина
			Номер группы	Дата

 

Между сущностями «Преподаватель» и «Экзамен» существует связь (1:М), обязательная со стороны сущности «Экзамен». Каждый преподаватель принимает, как правило, несколько экзаменов, поэтому используем связь (1:М). При этом подразумеваем, что конкретный экзамен принимает только один преподаватель. Со стороны сущности «Экзамен» связь обязательная, так как экзамен не может проводиться без преподавателя. Предполагаем также, что в базе могут быть введены преподаватели, которые экзаменов не принимают, поэтому со стороны сущности «Преподаватель» связь необязательная.

Между сущностями «Студент» и «Оценка» существует связь (1:М), обязательная со стороны сущности «Оценка». Каждый студент получает много оценок, поэтому используем связь (1:М). Со стороны сущности «Оценка» связь обязательная, так как не может быть выставлена оценка, не принадлежащая конкретному студента. Со стороны сущности «Студент» связь необязательная, т.к. студент может не иметь оценок (первокурсник).

Между сущностями «Группа» и «Студент» существует связь (1:М), обязательная со стороны сущности «Студент». Каждая группа состоит из многих студентов, поэтому используем связь (1:М). Со стороны сущности «Студент» связь обязательная, так как не может быть студента, не включенного в конкретную группу. Со стороны сущности «Группа» связь будем считать необязательной (не удалось набрать нужное количество абитуриентов).

Между сущностями «Группа» и «Экзамен» существует связь (1:М), обязательная со стороны сущности «Экзамен». Каждая группа должна сдавать много экзаменов, поэтому используем связь (1:М). Со стороны сущности «Экзамен» связь обязательная, так как не может быть экзамен, не назначенного конкретной группе. Со стороны сущности «Группа» связь будем считать необязательной (экзамены для группы не назначены).

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 1 Семантическая  модель предметной области «Экзамены»

Между сущностями «Экзамен» и «Оценка» существует связь (1:М), обязательная со стороны сущности «Оценка». На каждом экзамене выставляется много оценок, поэтому используем связь (1:М). Со стороны сущности «Оценка» связь обязательная, так как не может быть выставлена оценка, не полученная на конкретном экзамене. Со стороны сущности «Экзамен» связь необязательная, т.к. дата экзамена может еще не наступить, соответственно оценки по нему отсутствуют. Все рассмотренные связи отражены на рисунке 1.

3.2 Логическая модель  данных

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

 

Правило 1. Если связь типа (1:1) и  степень участия в связи обеих сущностей является обязательной, то необходима только одна таблица. Первичным ключом этой таблицы может быть первичный ключ любой из двух сущностей. Поскольку связи типа (1:1) в нашей модели отсутствуют, она соответствует данному правилу.

Правило 2. Если связь  типа (1:1) и степень участия одной  сущности является обязательной, а другой – необязательной, то нужно создать две таблицы – по одной для каждой сущности. Первичные ключи таблиц соответствуют первичным ключам сущностей. Поскольку связи типа (1:1) в нашей модели отсутствуют, она соответствует данному правилу.

Правило 3. Если связь  типа (1:1) и степень участия обеих  сущностей является необязательной, то необходимо создать три таблицы – по одной для каждой сущности и одну для связи. Первичные ключи таблиц соответствуют первичным ключам сущностей. Поскольку связи типа (1:1) в нашей модели отсутствуют, она соответствует данному правилу.

Правило 4. Если связь  типа (1:М) и степень участия сущности на стороне М является обязательной, то необходимо создать две таблицы – по одной для каждой сущности. Первичные ключи таблиц соответствуют первичным ключам сущностей. Для установления связи между ними необходимо добавить в подчиненную таблицу копию ключевого атрибута из главной таблицы, который станет внешним ключом подчиненной таблицы. Данное правило для построенной нами модели данных выполняется для следующих связей (1:М):

• «Студент – Оценка», поскольку сущность «Оценка» содержит копию ключевого атрибута «Номер зачетки» сущности «Студент»;
• «Группа – Студент», поскольку сущность «Студент» содержит копию ключевого атрибута «Номер группы» сущности «Группа»;
• «Группа – Экзамен», поскольку сущность «Экзамен» содержит копию ключевого атрибута «Номер группы» сущности «Группа»;
• «Экзамен – Оценка», поскольку сущность «Оценка» содержит копию ключевого атрибута «Номер экзамена» сущности «Экзамен».

Однако правило 4 не выполняется для связи «Преподаватель – Экзамен», поскольку сущность «Экзамен» не содержит копию ключевого атрибута «Код преподавателя» сущности «Преподаватель». Чтобы устранить это, следует заменить атрибут «ФИО преподавателя» сущность «Экзамен» на атрибут «Код преподавателя».

 Правило 5. Если связь типа (1:М) и степень участия сущности на стороне М является необязательной, то необходимо создать три таблицы – по одной для каждой сущности и одну для связи. Первичные ключи исходных таблиц соответствуют первичным ключам сущностей. Поскольку такие связи в нашей модели отсутствуют, она соответствует данному правилу.

 Правило 6. Если связь типа (M:N), то необходимо создать три таблицы – по одной для каждой сущности и одну для связи. Первичные ключи исходных таблиц соответствуют первичным ключам сущностей. Они передаются как внешние ключи в таблицу связи. Поскольку связи подобного типа в нашей модели отсутствуют, она соответствует данному правилу.

При создании модели БД необходимо предусмотреть минимизацию избыточности данных. В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах. Вследствие этого память компьютера используется неэкономно и времени на корректировку данных тратится больше. Для разработанной нами модели избыточная информация может содержаться в поле «Дисциплина» таблицы «Экзамены». Чтобы устранить этот недостаток, следует создать отдельную таблицу «Дисциплины» с полями «Код дисциплины» (первичный ключ) и «Наименование дисциплины», а в таблице «Экзамены» заменить поле «Дисциплина» на поле «Код дисциплины» (внешний ключ) с созданием соответствующей связи.

Проверим полученные отношения на соответствие нормальным формам (до третьей нормальной формы включительно):

Определение 1НФ: Таблица находится в 1НФ, если все ее поля содержат только неделимые значения. Для созданной нами модели это выполняется.

Определение 2НФ: Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. На соответствие второй нормальной форме проверяются только отношения, имеющие составной первичный ключ. Для нашей модели данных составной ключ имеет сущность «Оценка». Ее атрибуты «Дисциплина» и «Дата» зависят только от номера экзамена и не зависят от номера зачетки. Данные атрибуты следует удалить из таблицы, соответствующей сущности «Оценка», после чего она будет соответствовать 2НФ.

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

Достижение третьей нормальной формы обычно является достаточным для окончания процесса нормализации отношений. После приведения созданной модели в соответствие рассмотренным правилам мы получили логическую модель данных, которая приведена в Приложении А (в виде схемы данных из СУБД Microsoft Access).

3.3 Определение физических  характеристик атрибутов

Определяем параметры каждого атрибута построенной нами логической модели базы данных:

• Тип;
• Размер;
• Обязательность либо необязательность их заполнения. 

Параметры атрибутов для всех таблиц базы данных представлены в таблице 2.

 

Таблица 2 Атрибуты таблиц базы данных

Имя атрибута	Тип	Размер	Обязательный
Таблица СТУДЕНЫ
Номер зачетки	Числовой	Длинное целое	Да
ФИО	Текстовый	20 символов	Да
Номер группы	Числовой	Длинное целое	Да
Таблица ПРЕПОДАВАТЕЛИ
Код преподавателя	Счетчик	Длинное целое	Да
ФИО	Текстовый	20 символов	Да
Должность	Текстовый	50 символов	Нет
Ученая степень	Текстовый	50 символов	Нет
Таблица ГРУППЫ
Номер группы	Числовой	Длинное целое	Да
Специальность	Текстовый	50 символов	Да
Таблица ДИСЦИПЛИНЫ
Код дисциплины	Числовой	Длинное целое	Да
Наименование  дисциплины	Текстовый	50 символов	Да
Таблица ОЦЕНКИ
Номер экзамена	Числовой	Длинное целое	Да
Номер зачетки	Числовой	Длинное целое	Да
Балл	Числовой	Длинное целое	Да
Таблица ЭКЗАМЕНЫ
Номер экзамена	Числовой	Длинное целое	Да
Дата	Дата/время	Краткий формат даты	Да
Код дисциплины	Числовой	Длинное целое	Да
Код преподавателя	Числовой	Длинное целое	Да
Номер группы	Числовой	Длинное целое	Да

 

 

4. Реализация системы

4.1 Создание, связывание  и заполнение таблиц

Реализацию системы в СУБД MS Access выполняем на основании разработанной в разделе 3 модели данных, с учетом приведенных в таблице 2 параметров атрибутов. В среде MS Access создаем новую базу данных с именем «Экзамены» и далее создаем таблицы в режиме конструктора в следующей последовательности:

• Таблица «Дисциплины» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Код дисциплины» выбираем как ключевое;

Рисунок 2  Таблицы Дисциплины, Преподаватели, Группы ( режим Конструктор)

• Таблица «Преподаватели» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Код преподавателя» выбираем как ключевое;
• Таблица «Группы» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Номер группы» выбираем как ключевое;
• Таблица «Студенты» (см.рис.3): типы полей и их параметры берем из раздела 3.3. Поле «Номер зачетки» выбираем как ключевое. Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы»;

Рисунок 3 Таблицы Студенты, Оценки, Экзамены ( режим Конструктор)

• Таблица «Оценки» (см.рис.4): типы полей и их параметры берем из раздела 3.3. Поля «Номер экзамена» и «Номер зачетки» выделяем и указываем как ключевые. Для поля «Балл» используем «Мастер подстановок», в котором вводим фиксированный набор значений: от 0 до 10. Для поля «Номер экзамена» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Экзамены». Для поля «Номер зачетки» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Студенты»;
• Таблица «Экзамены» (см.рис.3): типы полей и их параметры берем из раздела 3.3. Поле «Номер экзамена» выбираем как ключевое. Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы». Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы». Для поля «Код преподавателя» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Преподаватели». Для поля «Код дисциплины» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Дисциплины».

После создания всех таблиц необходимо установить связи между ними. Для создания связей нажимаем кнопку «Схема данных» на панели инструментов и добавляем все созданные нами таблицы. Согласно построенной нами логической схеме данных создаем связи между таблицами, перетягивая мышью соответствующие поля таблиц: