Проектирование базы данных

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

• сущность «Студенты» имеет ключ «Номер_зачетки».
• Сущность «Документ_на_вселение» имеет ключ «Код_приказа».
• Сущность «Комната» имеет  ключ «номер_комнаты».
• Сущность «Ведомость» имеет ключ «Номер_кассового_чек».
• Сущность «Хобби» имеет ключ «Номер_зачетки».

 

2.5 Нормализация  отношений

 

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

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

• все таблицы находятся в первой нормальной форме, так как все атрибуты в них атомарны.
• Все таблицы находятся во второй нормальной форме, так как они находятся в первой нормальной форме и удовлетворяют дополнительному условию.  Рассмотрим таблицы «Студенты», «Ведомость», «Документ_на_вселение», «Комната» и «Хобби». Таблицы не имеют составного первичного ключа, поэтому они однозначно определены во второй нормальной форме.
• Все таблицы находятся в третьей нормальной форме, так как они находятся во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа, что видно из выявленных функциональных зависимостей.

 

3 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

 

3.1 Состав  таблиц базы данных

 

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

Таблица 3.1.1 «Сведения о студентах»

Имя атрибута	Тип данных	Размер  поля (байт)	Допустимость неопределенных  значений
Номер_зачетки	текстовый	10	нет
Фамилия	текстовый	30
Имя	текстовый	30
Отчество	текстовый	30
День_рождения	числовой	байт
Месяц_рождения	числовой	байт
Год_рождения	числовой	байт
Пол	текстовый	3
Факультет	текстовый	255
Специальность	текстовый	255
Курс	числовой	байт
Наличие_регистрации	текстовый	10
Прописка	текстовый	255
Номер_телефона	текстовый	11

 

 

Таблица 3.1.2 «Сведения о приказах»

Имя атрибута	Тип данных	Размер  поля (байт)	Допустимость неопределенных  значений
Номер_приказа	текстовый	10	нет
Дата_подписания	дата/время	8
Дата_вселения	дата/время	8
Дата_выселения	дата/время	8
Номер_комнаты	числовой	длинное целое
Номер_зачетки	текстовый	10	нет

 

Таблица 3.1.3 «Сведения о платежах»

Имя атрибута	Тип данных	Размер  поля (байт)	Допустимость неопределенных  значений
Номер_кассового_чека	текстовый	10	нет
Сумма	денежный	8
Месяц_платы	текстовый	8
Дата_оплаты	Дата/время	8
№_зачетки	текстовый	10	нет

 

 

Таблица 3.1.4 «Сведения о комнатах»

Имя атрибута	Тип данных	Размер  поля (байт)	Допустимость неопределенных  значений
Номер_комнаты	числовой	длинное целое	нет
Кол_мест	числовой	байт
Кол_своб_мест	числовой	байт
Стул_шт	числовой	байт
Стол_шт	числовой	байт
Кровать_шт	числовой	байт
Шкаф_шт	числовой	байт
Полка_шт	числовой	байт
Тумба	числовой	байт

 

Таблица 3.1.5 «Сведения об увлечениях»

Имя атрибута	Тип данных	Размер  поля (байт)	Допустимость неопределенных  значений
Номер_зачетки	текстовый	10	нет
Спортивные_секции	текстовый	225
Вокальные_студии	текстовый	225
Художественные_студии	текстовый	225
Хореография	текстовый	225
Владение_музыкальными_инструментами	текстовый	225
Членство_в_общественных_организациях	текстовый	225
Волонтерское_движение	текстовый	225

 

 

3.2 Средства поддержания  целостности данных

 

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

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

Выделяют три группы правил целостности:

• целостность по сущностям;
• целостность по ссылкам;
• целостность, определяемая пользователем.

Существуют  правила целостности:

• не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
• Значение внешнего ключа должно либо:
• быть равным значению первичного ключа цели;
• быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.

 

• Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5), принадлежность набору значений (пол "М" или "Ж").

 Для поддержания третьего вида целостности введены контроль следующих полей таблиц базы данных:

• таблица «Документ_на_вселение»:
• поле «дата_подписания<= дата_вселения», иначе выводится сообщение "Некорректная дата!"
• поле «дата_вселения <= дата_выселения», иначе выводится сообщение "Некорректная дата!".
• Таблица «Студенты»: поле «курс <6 AND курс>0», иначе выводится сообщение «Недопустимый курс проживания в общежитии!».
• Таблица «Комната»: поле «количество_мест ≥ количество_свободных мест», иначе выводится сообщение «Некорректное число!».

 

3.3 Запросы  и отчеты в БД

 

Запросы предназначены  для выборки нужных данных из одной  или нескольких связанных таблиц.

Перечень возможных  запросов к базе данных:

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

Рис.3 Запрос, отображающий список студентов без регистрации

 

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

Перечень возможных  отчетов:

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

 

ЗАКЛЮЧЕНИЕ

 

Реляционная модель  данных в настоящее время приобрела наибольшую популярность и практически все современные СУБД ориентированы именно на такое представление данных.

Реляционную модель можно представить как особый метод рассмотрения данных, содержащий  и данные (в виде таблиц),  и  способы работы, и манипуляции с ними (в виде связей). В реляционной модели БД, в отличие от других моделей, пользователь сам указывает,  какие данные для него необходимы, а какие нет. По этой причине процесс перемещения и навигации по БД в реляционных системах является автоматическим. Также реляционная СУБД выполняет функцию каталога, в котором хранятся описания всех объектов, из которых состоит БД.