Разработка базы данных оказания платных образовательных услуг

Разработка базы данных оказания платных образовательных услуг

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ВЯТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Кафедра автоматики и телемеханики

Курсовая работа

по дисциплине «Информационное обеспечение СУ»

РАЗРАБОТКА БАЗЫ ДАННЫХ ОКАЗАНИЯ ПЛАТНЫХ ОБРАЗОВАТЕЛЬНЫХ УСЛУГ

Разработал студент Балыбердин Д.С.

Руководитель работы Кислицын А.Б.

Киров 2010

Задание на курсовую работу

Разработать базу данных для заданной предметной области.

Масштабность и степень детализации разработки должны быть выбраны так, чтобы БД включала 7-10 типов информационных объектов (сущностей). Информация, включаемая в БД, должна быть взаимосвязана, иметь практическую пользу и достаточно полно описывать предметную область.

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

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

Дается текстовое описание предметной области, ее данных и способа работы с ними, могут представляться формы входных, внутренних и выходных документов.

. Инфологическое проектирование.

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

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

описание способа определения вычисляемых данных. При большом числе вычисляемых данных или сложном характере обработки это описание может быть вынесено в отдельный подраздел;

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

. Даталогическое проектирование

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

Также дается описание полученной модели, представляющее:

содержание отношений и атрибутов;

характеристики атрибутов (тип данных, обязательность, уникальность, ограничения);

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

Отношения полученной реляционной модели должны соответствовать третьей нормальной форме (3НФ).

. Реализация БД

.1. Реализация БД для СУБД Visual Foxpro

Должно быть дано графическое представление БД Visual Foxpro (распечатка окна Конструктора БД) и ее текстовое описание, описание реализации ограничений целостности и правил поддержки ссылочной целостности, описание и обоснование набора введенных индексов.

.2. Реализация БД для СУБД Interbase.

Представляется текст скрипта создания БД Interbase и описание особенностей реализации БД, описание реализации ограничений целостности и правил поддержки ссылочной целостности, описание и обоснование набора введенных индексов.

ПРИМЕЧАНИЕ: объем пояснительной записки должен составлять 20-30с.

Реферат

Балыбердин Д.С. Разработка базы данных оказания платных образовательных услуг: ТПЖА.220242.002 ПЗ: Курс. проект/ВятГУ, каф.АТ; рук. Кислицын А.Б. - Киров, 2010. ПЗ 20 с., 3 рис., 12 табл., 3 источника, 2 прил.

БАЗА ДАННЫХ, ПЛАТНЫЕ, ПЛАТНЫЕ ОБРАЗОВАТЕЛЬНЫЕ УСЛУГИ, ВЫСШЕЕ УЧЕБНОЕ ЗАВЕДЕНИЕ, ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ, ДАТАЛОГИЧЕСКАЯ МОДЕЛЬ, VISUAL FOXPRO, SQL, СУБД

Объект разработки - база данных оказания платных образовательных услуг.

Цель работы - освоить методы разработки баз данных.

Разработаны инфологическая и даталогическая модели, реализована база данных оказания платных образовательных услуг в СУБД Visual Foxpro и Interbase.

инфологический платный образовательный ссылочный

Содержание

Введение

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

2. Инфологическое проектирование

3. Даталогическое проектирование

4. Реализация БД

4.1 Реализация БД для СУБД Visual FoxPro

4.2 Реализация БД для СУБД Interbase

Заключение

Перечень сокращений

Библиографический список

Введение

Настоящая курсовая работа посвящена вопросам разработки базы данных оказания платных образовательных услуг.

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

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

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

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

инфологическое проектирование;

даталогическое проектирование;

реализация БД для СУБД Visual FoxPro;

реализация БД для СУБД InterBase.

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

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

Со студентом заключается договор, согласно которому и оказываются услуги. В договоре указывается дата, до которой студент должен сдать несданные дисциплины.

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

2. Инфологическое проектирование

Инфологическая модель строится на основе приведённого выше описания предметной области.

Разработанная модель представлена на рисунке 2.1

Рисунок 2.1 - Инфологическая модель

Сущность «Факультет» определяет факультеты вуза и содержит два свойства - «Название» и «Аббревиатура». Название и аббревиатура факультета заносятся в строковом виде. Аббревиатура - ключевое свойство.

Сущность «Специальность» определяет специальности вуза на каждом факультете. Свойства:

Шифр. Содержит шифр специальности. Является ключевым. Тип данных - строковый (хотя возможно использование целочисленного);

Название. Содержит полное название специальности. Тип данных - строковый.

Сущность «Группа» определяет группы специальностей и содержит одно свойство - «Шифр группы», являющееся ключевым. Тип данных для этого свойства - строковый.

Сущность «Слушатель» определяет данные об отчисленном студенте. В «минимальном» случае содержит два свойства:

Номер зачётной книжки. Является уникальным для каждого слушателя, следовательно, используем его в качестве ключа. Тип данных - строковый;

ФИО. Фамилия, имя и отчество слушателя заносятся в строковом виде;

Дата рождения;

Дата отчисления.

Сущность «Дисциплина» отражает список дисциплин вуза и содержит следующие свойства:

Название. Название дисциплины в строковом виде.

Код. Уникальный код дисциплины целочисленного типа. Является ключом;

Преподаватель. Содержит ФИО преподавателя данной дисциплины. Для простоты возьмём случай, при котором каждую дисциплину ведёт только один преподаватель. Тип данных - строковый.

Сущность «Услуга» содержит платные образовательные услуги.

Номер. Идентификационный номер услуги. Свойство введено для упрощения, так как названия некоторых видов услуг слишком длинны (при организации поиска будет упрощена работа). Является ключевым. Тип данных - целочисленный;

Вид. Содержит название вида услуги. Описание видов услуг приведено в пункте 1 «Описание предметной области». Тип данных - строковый;

Стоимость. Содержит стоимость услуги. Тип данных - числовой.

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

Номер. Номер договора является уникальным, поэтому используем его в качестве ключа. Тип данных - целочисленный;

Оплата. Сумма, внесённая слушателем за все занятия по договору. Тип данных - числовой;

Дата заключения договора;

Дата расторжения договора;

ФИО оплачивающего. Тип данных - строковый. Необходимость введения обусловлена тем, что оплачивать платные услуги может не сам слушатель. Данное положение отражается в договоре;

Количество услуг. Отражает количество оплаченных услуг. Тип данных - целочисленный. Должно быть больше нуля.

Все поля обязательны для заполнения.

Ассоциация «Занятие» является отражением прохождения занятия со слушателем и связывает сущности «Дисциплина», «Услуга», «Договор».

Рассмотрим внесённые связи.

Связь «Факультет-Специальность» - 1:М, обязательна с обеих сторон. Факультет содержит несколько специальностей. Специальность обязательно относится к какому-либо факультету.

Связь «Специальность-Группа» - 1:М, обязательна с обеих сторон. Специальность содержит несколько групп. Группа обязательно относится к какой-либо специальности.

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

Связь «Слушатель-Договор» - 1:1, необязательна с главной стороны.

Слушатель может пользоваться несколькими видами услуг сразу и оплачивать сразу несколько занятий, при чём все занятия прописаны в одном договоре. Этим объясняется множественность остальных связей «Дисциплина-Занятие», «Услуга-Занятие», «Договор-Занятие» со стороны ассоциации «Занятие». Данное связывание говорит о том, что отдельное занятие проводится с конкретным слушателем по определённой дисциплине по уникальному договору, причём указывается вид услуги.

Со стороны сущностей «Дисциплина», «Услуга», «Договор» связь является единичной. Необязательность объясняется тем, что данные сущности существуют вне зависимости от наличия занятия.

Рассмотрим ограничения целостности:

Номер договора и номер услуги не могут быть отрицательными;

Стоимость услуги и оплата не могут быть отрицательными или нулевыми;

Дата рождения не может быть позже даты отчисления;

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

3. Даталогическое проектирование

После перехода от сложных объектов к простым получим можно переходить непосредственно к даталогическому проектированию.

Примечания:

В модели отсутствуют сложные свойства.

В модели отсутствуют связи «Многие ко многим».

Модель соответствует форме 3НФ и, следовательно, не нуждается в нормализации.

Переход к реляционной модели осуществляется в два этапа:

Преобразование сущностей в отношения;

Формирование внешних ключей.

Доопределять первичные ключи не требуется.

Полная логическая модель представлена на рисунке 3.1.

Примечание - Все необязательные связи обусловлены сугубо практическим интересом - для облегчения ввода информации в таблицы.

Рисунок 3.1 - Даталогическая модель

Характеристики атрибутов приведены в таблицах 3.1 - 3.8.

Таблица 3.1 - Атрибуты отношения «Факультет»

Таблица 3.2 - Атрибуты отношения «Специальность»

Таблица 3.3 - Атрибуты отношения «Группа»

Таблица 3.4 - Атрибуты отношения «Слушатель»

Таблица 3.5 - Атрибуты отношения «Дисциплина»

Таблица 3.6 - Атрибуты отношения «Услуга»

Таблица 3.7 - Атрибуты отношения «Договор»

Таблица 3.8 - Атрибуты отношения «Занятие»

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

При внимательном рассмотрении базы данных было установлено, что действия для всех связок «Родительское отношение»-«Дочернее отношение» одинаковы, а именно:

При модификации записи в родительском отношении происходит каскадное изменение в дочернем отношении;

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

Запрещается новая запись, если ее идентификатор не соответствует ни одному из родительской записи;

Запрещается изменение в дочерней записи, если нарушается целостность.

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

4. Реализация БД

.1 Реализация БД для СУБД Visual FoxPro

Графическое представление БД Visual FoxPro (распечатка окна Конструктора БД) приведено на рисунке 4.1.

Рисунок 4.1 - Графическое представление БД в Visual FoxPro

В таблице 4.1 приведены данные, введенные для описания полей созданных таблиц

Таблица 4.1 - Описание полей таблиц

В таблице 4.2 приведено описание индексов таблиц.

Таблица 4.2 - Описание индексов таблиц

В таблице 4.3 приведены данные, описывающие реализованные ограничения целостности данных в таблицах.

Таблица 4.3 - Описание ограничений целостности данных в таблицах

Примечание - В выражении .NOT.EMPTY(…) вместо троеточия ставится название соответствующего столбца таблицы.

В таблице 4.4 приведены данные, задающие правила поддержки ограничений ссылочной целостности.

Таблица 4.4 - Правила поддержки ссылочной целостности

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

При изменении записи аббревиатуры abbreviatura в таблице факультетов table1_fakultet будут меняться соответствующие записи в таблице специальностей table2_specialnost (Cascade);

Невозможно удалить запись в таблице факультетов table1_fakultet, если в таблице специальностей table2_specialnost есть хотя бы одна запись с таким факультетом (Restrict);

Невозможно изменить запись в таблице специальностей table2_specialnost, если значение аббревиатуры abbreviatura не будет совпадать с аббревиатурой ни одного факультета таблицы table1_fakultet (Restrict);

Для таблиц «Специальность»- «Группа» и «Группа»-«Слушатель» ситуация аналогична;

При изменении значений KOD_DISC, KOD_USLUGI, NO_DOGOVOR в таблицах table5_disciplina, table6_usluga, table7_dogovor каскадно изменяются соответствующие значения в таблице table8_zanyatie (Cascade);

Запрещено удаление из таблиц 5, 6 записи, если в таблице 8 есть запись, связанная с этими таблицами (Restrict);

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

Запрещено изменение записей в table8_zanyatie, если запись не связывается ни с одной из таблиц 5, 6 (Restrict).

4.2 Реализация БД для СУБД Interbase

При реализации БД для СУБД Interbase использовались те же имена таблиц, столбцов и индексов, что и при реализации БД для СУБД Visual FoxPro.

Ограничения целостности и правила поддержки ссылочной целостности не изменились.

Ниже представлен скрипт создания спроектированной базы данных с комментариями.

CREATE DATABASE "C:\iosu_KR.gdb""SYSDBA" PASSWORD "masterkey";

/*Таблица "Факультет"*/

/*Столбец "Аббревиатура", строковый (10), ненулевой*/

/*Столбец "Название"", строковый (60), ненулевой*/

/*Проверка на уникальность абреввиатуры и названия*/

/* «Аббревиатура» - первичный ключ*/

CREATE TABLE table1_fakultet

(CHAR(10) NOT NULL ,CHAR(60) NOT NULL,(nazvanie),KEY (abbreviatura)

);

/*Таблица "Специальность"*/

/*Столбец "Аббревиатура", строковый (10), ненулевой*/

/*Столбец "Шифр специальности", строковый (10), ненулевой*/

/*Проверка на уникальность шифра специальности и названия*/

/* «Шифр специальности» - первичный ключ*/

/* «Аббревиатура» - внешний ключ, связан с таблицей «Факультет» («Аббревиатура»), при удалении записи из родительской таблицы - запрет, при изменении - каскад*/

CREATE TABLE table2_specialnost

(CHAR(10) NOT NULL,_spec CHAR(10) NOT NULL,CHAR(60) NOT NULL,(nazvanie),KEY (shifr_spec),KEY (abbreviatura)table1_fakultet (abbreviatura) ON UPDATE CASCADE

);

/*Далее - аналогично*/

/*Таблица "Группа"*/

CREATE TABLE table3_gruppa

(_spec CHAR(10) NOT NULL,_gr CHAR(10) NOT NULL,KEY (shifr_gr),KEY (shifr_spec)table2_specialnost (shifr_spec) ON UPDATE CASCADE

);

/*Таблица "Слушатель"*/TABLE table4_slushatel

(_gr CHAR(10) NOT NULL,_pasporta CHAR(20) NOT NULL,CHAR(30) NOT NULL,_rojdenia DATE NOT NULL,_otchislenia DATE NOT NULL,(data_rojdenia < data_otchislenia), /*Проверка целостности*/KEY (no_pasporta),KEY (shifr_gr)table3_gruppa (shifr_gr) ON UPDATE CASCADE

);

/*Таблица "Дисциплина"*/TABLE table5_disciplina

(_disc INTEGER NOT NULL,_disc CHAR(60) NOT NULL,CHAR(30) NOT NULL,(kod_disc >= 0),(nazvanie_disc, prepodavatel),KEY (kod_disc)

);

/*Таблица "Услуга"*/TABLE table6_usluga

(_uslugi INTEGER NOT NULL,_uslugi CHAR(20) NOT NULL,NUMERIC(10000,2) NOT NULL,(kod_uslugi >= 0),(stoimost > 0),(vid_uslugi),KEY (kod_uslugi)

);

/*Таблица "Договор"*/TABLE table7_dogovor

(_dogovora INTEGER NOT NULL,_pasporta CHAR(20) NOT NULL,NUMERIC(10000,2) NOT NULL,_zakluchenia DATE NOT NULL,_rastorjenia DATE NOT NULL,CHAR(30) NOT NULL,INTEGER NOT NULL,(no_dogovora >= 0),(oplata > 0),(kolichestvo > 0),(data_zakluchenia < data_rastorjenia),KEY (no_dogovora)KEY (kod_disc)table4_slushatel (no_pasporta)DELETE CASCADE ON UPDATE CASCADE,

);

/*Таблица "Занятие"*/TABLE table8_zanyatie

(_disc INTEGER NOT NULL,_uslugi INTEGER NOT NULL,_dogovora INTEGER NOT NULL,(kod_disc >= 0),(kod_uslugi >= 0),(no_dogovora >= 0),KEY (kod_disc)table5_disciplina (kod_disc)DELETE NO ACTION ON UPDATE CASCADE,KEY (kod_uslugi)table5_disciplina (table6_usluga)DELETE NO ACTION ON UPDATE CASCADE,KEY (no_dogovora)table6_usluga (table7_dogovor)DELETE CASCADE ON UPDATE CASCADE

);

/*Завершить транзакцию*/;

Заключение

Целью данной курсовой работы является разработка базы данных оказания платных образовательных услуг.

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

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

инфологическое проектирование;

даталогическое проектирование;

реализация БД для СУБД Visual FoxPro;

реализация БД для СУБД InterBase.

В ходе выполнения курсовой работы были получены основные навыки проектирования баз данных, а также приобретён некоторый опыт работы с СУБД Visual FoxPro и InterBase.

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

Перечень сокращений

БД - база данных;

СУБД - система управления базами данных;

НФ - третья нормальная форма;

:М - связь «один ко многим»;

FK - внешний ключ.

Библиографический список

СТП ВятГУ 101-2004. Общие требования к оформлению текстовых документов. Введ. 2004-01-01. - 29 с.

СТП ВятГУ 101-2004. Общие требования к структуре, представлению и оформлению курсовых проектов и работ. Введ. 2004-01-04. - 26 с.

Кислицын А.Б. Лекции по дисциплине «Информационное обеспечение СУ». Киров 2010.