Выделение объектов учётной информации

Документ "План проведения занятий в группе" (рис. 2. 5) содер­жит сведения о занятиях, проводимых в каждой группе в теку­щем семестре. ЧАСЫ — это основная количественная характе­ристика занятия, т. е. описательный реквизит. Соответственно он является реквизитом, зависимым от идентификаторов заня­тия: номера группы, кода изучаемого предмета, идентификатора преподавателя и вида занятий, т. к. учёт ведется отдельно по лекциям и практическим занятиям.

Кроме того к описательным реквизитам занятия можно отнести расчетный реквизит — средний балл в группе по занятию, если его хранить в базе данных. В результате анализа взаимосвязей реквизитов этого документа можно выделить новый информа­ционный объект ИЗУЧЕНИЕ.

На основе анализа документа "Экзаменационная ведомость" мо­жет быть выделен другой объект учетной информации — УС­ПЕВАЕМОСТЬ.

Полный состав объектов учетной информации представлен в табл. 2. 5.

Информационный объект УСПЕВАЕМОСТЬ обеспечивает хра­нение в базе данных информации об итоговых оценках студента за семестр по каждому виду занятия, отображенному в объекте ИЗУЧЕНИЕ.

Соответственно такая оценка определяется с одной стороны идентификатором студента (НГ+ НС), а с другой сторо­ны идентификатором занятия (НГ+ КП+ ТАБН+ ВИДЗ).

Таким образом их объединение образует уникальный идентификатор объекта УСПЕВАЕМОСТЬ.

После проектирования таблиц необходимо определить и обозначить связи между ключевыми атрибутами объектов, как показано на схеме связей базы данных «Учебный процесс» (рис.4), что и является инфологической моделью, построенной по схеме «таблицы-связи»:

Рис.4 Инфологическая модель базы данных «Учебный процесс»

1.2.2 Даталогическая модель

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

Хотя даталогическое проектирование является логической структурой базы данных, на него влияют возможности физической организации данных, представляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.

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

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

Одно из требований — реляционная база данных должна быть нормализована. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (или к нормальной форме Бойса-Кодда).

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

Анализ предметной области обычно осуществляется на основании известных сведений о ней с учетом целей проектирования программной системы.

Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.

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

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

Единицей, хранящейся в БД информации, является таблица. Каждая таблица представляет собой совокупность строк и столбцов, где строки соответствуют экземпляру, а столбцы - атрибутам (признакам, характеристикам, параметрам объекта, события, явления).

В терминах БД столбцы таблицы называются полями, а ее строки - записями.

Нормализация выполняется поэтапно. Первые три шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г.

Первая нормальная форма (1НФ). Для нее требуется, чтобы таблица была плоской и не содержала повторяющихся групп. У плоской таблицы есть только две характеристики - длина (количество записей или строк) и ширина (количество полей или столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений.

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

Вторая нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.

В каждой таблице БД может существовать первичный ключ - поле или набор полей, однозначно идентифицирующий запись.

Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа.

Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. 2НФ позволяет удалить большую часть повторяющихся данных, которые часто остаются после первого этапа нормализации.

Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

Отношение находится в четвертой нормальной форме (4НФ), если в нем не присутствуют функциональные многозначные зависимости. Для 4НФ требуется, чтобы в одной таблице не содержались независимые элементы данных, если между ними существует отношение "многие-ко-многим".

Если в отношении имеется много функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (ЗНФ).

Разложение отношений из 4НФ в пятую нормальную форму должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.

Для большинства существующих СУБД необходимо представить проект базы данных в ЗНФ, так как этого вполне достаточно практически для всех обычных приложений. При разработке исключительно больших систем, когда необходимо максимальное сокращение объемов хранимых данных, желательно произвести дальнейшую нормализацию. Но в этом случае можно столкнуться с недостатками нормализации. Поскольку порог человеческого восприятия не позволяет одновременно анализировать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Другим недостатком нормализованной базы данных является необходимость считывать связанные данные из нескольких таблиц при выполнении одного запроса.

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

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

Адрес (Код, Индекс, Область_край, Населенный пункт, Улица, Дом, Телефон, Физическое лицо)

Аттестат (Код, Номер, Серия, Что закончил, Год окончания, Физическое лицо)

Вид документа (Код, Название)

Вид экзамена (Код, Название)

Вкладыш к диплому (Код, Номер, Серия, Университет, Факультет, Специальность, Год окончания, Физическое лицо)

Выписка из зачетки (Код, Университет, Факультет, Специальность, Год поступления, Физическое лицо)

Группа (Код, Форма обучения, Специальность, Курс, Физическое лицо)

Дисциплина (Код, Название)

Документ (Код, Номер, Дата, Примечание, Вид документа, Группа, Физическое лицо)

Категории (Код, Название)

Курс (Код, Название курса, Номер курса)

Национальность (Код, Название)

Подразделение (Код, Название, Владелец)

Подразделение обучает (Код, Подразделение, Специальность)

Семестр (Код, Номер семестра, Название семестра, Курс)

Семестровая ведомость (Код, Физическое лицо (студент), Дисциплина, Оценка, Вид экзамена, Дата сдачи, Физическое лицо (преподаватель), Семестр)

Специальность (Код, Название, Краткое название)

Трудовая книжка (Код, Последнее место работы, Физическое лицо)

Физические лица (Код, Фамилия, Имя, Отчество, Год рождения, Категория, Национальность)

Физическое лицо преподает (Код, Физическое лицо, Дисциплина)

Форма обучения (Код, Название)

Заявка (Код, Заявлено, Оплачено, Дата заявки, Физическое лицо, Дисциплина).