Введение

Актуальность темы курсовой работы

В условиях современной жизни требуется ускорение процессов обработки информации. Для решения этих задач требуется использование различных программных продуктов, в частности систем управления базами данных (СУБД). В связи с этим в рамках данной курсовой работы была создана база данных для студенческого общежития №3 ЮКГУ им. М.Ауезова. Основное назначение спроектированной базы данных состоит в предоставлении основной информации о проживающих в общежитии студентов, об условиях их проживания, а также предоставление перечня приказов на вселение и отчетов об оплате в простой и удобной форме.

Курсовая работа выполнялась в соответствии в госбюджетной НИР Б-16-01-06 «Разработка интеллектуальных автоматизированных систем для технологических и учебных процессов». Раздел 1. Разработка программного обеспечения для дисциплин специальности 5В070200 учебного процесса НИР кафедры.

Новизна и практическая значимость работы

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

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

Оценка современного состояния решаемой проблемы

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

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

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

• систематизировать информационные потоки и процессы выбранной предметной области;

• составить модели данных и осуществить их нормализацию;

• разработать прикладную программу для реализации и эксплуатации базы данных.

Объектом разработки является общежитие №3 ЮКГУ им. М.Ауезова.

1 Описание предметной области

Наименование организации: общежитие №3 ЮКГУ им. М.Ауезова

Наименование предметной области: управление общежитием, оперативное слежение за прибытием и отъездов студентов, организация оперативного, своевременного учета оплаты студентами проживания в общежитии.

Точка зрения: комендант общежития.

Перечень процессов, составляющих деятельность общежития:

1. При поступлении в учебное заведение абитуриент обозначает в договоре то, что он нуждается или не нуждается в общежитии.

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

3. При переходе на последующий курс договор продлевается или перезаключается (возможно, изменение оплаты и т.д.).

4. Каждому студенту объявляется сумма оплаты за проживание в месяц. Оплата за комнату зависит от качества и определяется наличием дополнительных удобств, количества проживающих и т.д. Студент расписывается в журнале коменданта общежития.

5. Комендант общежития подает отчет в деканаты факультетов о заселении студентов.

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

7. Об отъезде из общежития студент должен сообщить коменданту заранее, не позднее 20-ти дневного срока. В этот срок он должен оплатить (погасить) задолженности, если таковые имеются.

8. Если студент не вносит оплаты за комнату более чем в 30-ти дневной срок, то рассматривается вопрос об его выписке из общежития.

9. При нарушении режима общежития студентом, рассматривается вопрос об исключении его из университета.

10. Если студента исключают из университета, то в 10-ти дневный срок он обязан освободить комнату и съехать из общежития.

11. При выезде студента из общежития, комендант отмечает в журнале дату выезда.

Описание процессов, поддерживаемых в рамках данного исследования:

• учет прибывших, выбывших студентов – постоянно;

• ведение журнала коменданта общежития – постоянно;

• учет своевременной оплаты сумм – ежемесячно;

• оперативный учет свободных мест – постоянно, по мере прибытия (выбытия) студентов;

• информирование деканата – в отчетный период.

На рисунке 1.1 показана схема взаимосвязи процессов и информационных потоков.

Рисунок 1.1. Схема взаимосвязи процессов и информационных потоков

2 Моделирование потоков данных

2.1 Концептуальная модель предметной области

В результате обследования предметной области были определены следующие входные данные:

- информация о студентах,

- информация о документах на вселение,

- информация о платежах,

- информация об условиях проживания в комнате.

На рисунке 1.2 представлена концептуальная модель данных.

Рисунок 1.2. Концептуальная модель данных

2.2 Инфологическая модель базы данных

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

Сущность (объектное множество, таблица) – это собирательное понятие, абстракция реально существующего процесса, объекта или явления, о котором необходимо хранить информацию [3,4].

Атрибут (реквизит) – поименованная характеристика сущности [7].

Связь – ассоциирование двух и более сущностей. Если бы назначением БД было только хранение отдельных, не связанных между собой данных, то ее структура могла быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по назначениям других, для чего необходимо установить между ними определенные связи [8].

Приведем список сущностей с соответствующими атрибутами:

1. Студент (ФИО, номер зачетной книжки, факультет, специальность, курс, номер удостоверения, фото, прописка, наличие регистрации – для иностранных студентов).

2. Договор (Код договора, номер зачетной книжки, дата заключения (продления), сумма оплаты за месяц).

3. Комната (Номер комнаты, количество мест, количество свободных мест, качество, примечание).

4. Журнал коменданта (Номер записи, Номер комнаты, Код договора, дата въезда-выезда, факт проживания, факт оплаты, номер квитанции).

5. Квитанция (Номер квитанции, номер записи, сумма, дата оплаты).

На основании выявленных сущностей построим модель «сущность - связь».

Рисунок 1.3. Модель «сущность-связь» проектируемой базы данных

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

Перейдем от инфологической модели данных к реляционной. Как видно из рисунка 1.3 связи между сущностями 1: М (один ко многим). В этом случае строится по одному отношению для каждой сущности. Ключ односвязной сущности добавляется в качестве внешнего ключа в другое отношение.

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

Первая нормальная форма: отношение находится в первой нормальной форме, если значения всех ее полей атомарные и в ней отсутствуют повторяющиеся группы полей. Приведем наши данные к первой нормальной форме. Для этого разобьём поле ФИО в отношении Студент на три составляющие: Фамилия, Имя, Отчество. Далее в целях исключения избыточного дублирования данных необходимо добавить два новых отношения Факультет и Специальность, поскольку значения этих полей не являются атомарными, оставив в данном отношении код факультета и код специальности.

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

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

В целях обеспечения защиты данных добавим отношение Пользователи, обеспечивающие 2 уровня доступа к базе данных.

Получим следующие отношения:

1. Студент (Номер зачетной книжки, Фамилия, Имя, Отчество, код факультета, код специальности, номер удостоверения, фото, прописка, наличие регистрации).

2. Факультет (Код факультета, название, короткое название, порядок следования в документах, Фамилия, Имя, Отчество декана, телефон).

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

4. Договор (Код договора, номер зачетной книжки, курс, дата заключения (продления), сумма оплаты за месяц).

5. Комната (Номер комнаты, количество мест, количество свободных мест, качество, примечание).

6. Журнал коменданта (Номер записи, Номер комнаты, Код договора, дата въезда-выезда, факт проживания, факт оплаты, номер квитанции).

7. Квитанция (Номер квитанции, номер записи, сумма, дата оплаты).

8. Пользователи (Логин, пароль).

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