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

Размещено на http://allbest.ru/

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

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

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

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

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

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

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

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

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

Киров 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.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.

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

Размещено на http://allbest.ru/

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

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

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Аббревиатура	Строковый	+	+	-
Название факультета	Строковый	+	+	-

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Аббревиатура	Строковый	-	+	-
Шифр специальности	Строковый	+	+	-
Название специальности	Строковый	+	+	-

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Шифр специальности	Строковый	-	+	-
Шифр группы	Строковый	+	+	-

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Шифр группы	Строковый	-	+	-
Номер паспорта	Строковый	+	+	-
ФИО	Строковый	-	+	-
Дата рождения	Дата	-	+	Дата рождения не может быть позже даты отчисления
Дата отчисления	Дата	-	+

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Код дисциплины	Целочисленный	+	+	Не может быть отрицательным
Название дисциплины	Строковый	+	+	-
Преподаватель	Строковый	+	+	-

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Код услуги	Целочисленный	+	+	Не может быть отрицательным
Вид услуги	Строковый	+	+	-
Стоимость	Числовой	-	+	Должно быть больше нуля

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Номер договора	Целочисленный	+	+	Не может быть отрицательным
Оплата	Числовой	-	+	Должно быть больше нуля
Номер паспорта	Строковый	+	+	-
Дата заключения	Дата	-	+	Дата заключения не может быть позже даты расторжения
Дата расторжения	Дата	-	+
ФИО оплачивающего	Строковый	-	+	-
Количество услуг	Целочисленный	-	+	Должно быть больше нуля

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

Атрибут	Тип	Уникальность	Обязательность заполнения	Прочие ограничения
Код дисциплины	Целочисленный	-	+	Не может быть отрицательным
Код услуги	Целочисленный	-	+	Не может быть отрицательным
Номер договора	Целочисленный	-	+	Не может быть отрицательным

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица	Описания полей
	Name	Type	Width
1	2	3	4
table1_fakultet	abbreviatura	Character	10
	nazvanie	Character	60
table2_specialnost	shifr_spec	Character	10
	nazvanie	Character	60
	abbreviatura	Character	10
table3_gruppa	shifr_gr	Character	10
	shifr_spec	Character	10
table4_slushatel	shifr_gr	Character	10
	no_pasporta	Character	20
	fio	Character	30
	data_rojdenia	Date
	data_otchislenia	Date
table5_disciplina	kod_disc	Integer
	nazvanie_disc	Character	60
	prepodavatel	Character	30
table6_usluga	kod_uslugi	Integer
	vid_uslugi	Character	20
table6_usluga	stoimost	Float	10000
table7_dogovor	no_dogovora	Integer
	oplata	Float	100000
	data_zakluchenia	Date
	data_rastorjenia	Date
	fio	Character	30
	kolichestvo	Integer
	no_pasporta	Character	10
table8_zanyatie	kod_disc	Integer
	kod_uslugi	Integer
	no_dogovora	Integer

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

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

Таблица	Описания индексов
	Name	Type	Expression
table1_fakultet	abb	Primary	abbreviatura
table2_specialnost	SHIFR_SPEC	Primary	shifr_spec
	abb	Regular	abbreviatura
table3_gruppa	SHIFR_SPEC	Regular	shifr_spec
	SHIFR_GR	Primary	shifr_gr
table4_slushatel	NO_ZACHETK	Primary	no_zachetki
	SHIFR_GR	Regular	shifr_gr
table5_disciplina	KOD_DISC	Primary	kod_disc
table6_usluga	KOD_USLUGI	Primary	kod_uslugi
table7_dogovor	NO_DOGOVOR	Primary	no_dogovora
	no_pasp	Regular	no_pasporta
table8_zanyatie	KOD_DISC	Regular	kod_disc
	KOD_USLUGI	Regular	kod_uslugi
	NO_DOGOVOR	Regular	no_dogovora

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

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

Таблица	Содержание ограничения	Вкладка	Задание ограничения
1	2	3	4
table1_fakultet	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
table2_specialnost	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
table3_gruppa	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
table4_slushatel	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
	Дата рождения не может быть позже даты отчисления	Table	Rule: data_otchislenia>data_rojdenia Message: "Неверно введены даты!"
table5_disciplina	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
	Код дисциплины не может быть отрицательным	Fields	Rule: kod_disc>=0 Message:"Некорректные данные!"
table6_usluga	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
	Код услуги не может быть отрицательным	Fields	Rule: kod_uslugi>=0 Message:"Некорректные данные!"
	Стоимость должна быть больше нуля	Fields	Rule: stoimost>0 Message:"Некорректные данные!"
table7_dogovor	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
	Номер договора не может быть отрицательным	Fields	Rule: no_dogovora>=0 Message:"Некорректные данные!"
	Оплата должна быть больше нуля	Fields	Rule: oplata>0 Message:"Некорректные данные!"
	Количество услуг должно быть больше нуля	Fields	Rule: kolichestvo>0 Message:"Некорректные данные!"
	Дата заключения не может быть позже даты расторжения	Table	Rule: data_rastorjenia>data_zakluchenia Message: "Неверно введены даты!"
table8_zanyatie	Наличие всех данных обязательно	Fields	Rule: .NOT.EMPTY(…) Message:"Данные не введены!"
	Код дисциплины не может быть отрицательным	Fields	Rule: kod_disc>=0 Message:"Некорректные данные!"
	Код услуги не может быть отрицательным	Fields	Rule: kod_uslugi>=0 Message:"Некорректные данные!"
	Номер договора не может быть отрицательным	Fields	Rule: no_dogovora>=0 Message:"Некорректные данные!"

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

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

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

Родительская таблица	Дочерняя таблица	Изм. в род. табл.	Удал. в род. табл.	Добавление и изменение в доч. табл.	Индекс в родительской таблице	Индекс в дочерней таблице
table1_ fakultet	table2_ specialnost	Cascade	Restrict	Restrict	abb
table2_ specialnost	table3_ gruppa	Cascade	Restrict	Restrict	SHIFR_SPEC
table3_ gruppa	table4_ slushatel	Cascade	Restrict	Restrict	SHIFR_GR
table4_ slushatel	table7_ dogovor	Cascade	Cascade	Restrict	no_pasp
table5_ disciplina	table8_ zanyatie	Cascade	Restrict	Restrict	KOD_DISC
table6_ usluga		Cascade	Restrict	Restrict	KOD_USLUGI
table7_ dogovor	table8_ zanyatie	Cascade	Cascade	Restrict	NO_DOGOVOR

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

При изменении записи аббревиатуры 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"

USER "SYSDBA" PASSWORD "masterkey";

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

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

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

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

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

CREATE TABLE table1_fakultet

(

abbreviatura CHAR(10) NOT NULL ,

nazvanie CHAR(60) NOT NULL,

UNIQUE (nazvanie),

PRIMARY KEY (abbreviatura)

);

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

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

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

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

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

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

CREATE TABLE table2_specialnost

(

abbreviatura CHAR(10) NOT NULL,

shifr_spec CHAR(10) NOT NULL,

nazvanie CHAR(60) NOT NULL,

UNIQUE (nazvanie),

PRIMARY KEY (shifr_spec),

FOREIGN KEY (abbreviatura)

REFERENCES table1_fakultet (abbreviatura) ON UPDATE CASCADE

);

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

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

CREATE TABLE table3_gruppa

(

shifr_spec CHAR(10) NOT NULL,

shifr_gr CHAR(10) NOT NULL,

PRIMARY KEY (shifr_gr),

FOREIGN KEY (shifr_spec)

REFERENCES table2_specialnost (shifr_spec) ON UPDATE CASCADE

);

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

CREATE TABLE table4_slushatel

(

shifr_gr CHAR(10) NOT NULL,

no_pasporta CHAR(20) NOT NULL,

fio CHAR(30) NOT NULL,

data_rojdenia DATE NOT NULL,

data_otchislenia DATE NOT NULL,

CHECK (data_rojdenia < data_otchislenia), /*Проверка целостности*/

PRIMARY KEY (no_pasporta),

FOREIGN KEY (shifr_gr)

REFERENCES table3_gruppa (shifr_gr) ON UPDATE CASCADE

);

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

CREATE TABLE table5_disciplina

(

kod_disc INTEGER NOT NULL,

nazvanie_disc CHAR(60) NOT NULL,

prepodavatel CHAR(30) NOT NULL,

CHECK (kod_disc >= 0),

UNIQUE (nazvanie_disc, prepodavatel),

PRIMARY KEY (kod_disc)

);

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

CREATE TABLE table6_usluga

(

kod_uslugi INTEGER NOT NULL,

vid_uslugi CHAR(20) NOT NULL,

stoimost NUMERIC(10000,2) NOT NULL,

CHECK (kod_uslugi >= 0),

CHECK (stoimost > 0),

UNIQUE (vid_uslugi),

PRIMARY KEY (kod_uslugi)

);

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

CREATE TABLE table7_dogovor

(

no_dogovora INTEGER NOT NULL,

no_pasporta CHAR(20) NOT NULL,

oplata NUMERIC(10000,2) NOT NULL,

data_zakluchenia DATE NOT NULL,

data_rastorjenia DATE NOT NULL,

fio CHAR(30) NOT NULL,

kolichestvo INTEGER NOT NULL,

CHECK (no_dogovora >= 0),

CHECK (oplata > 0),

CHECK (kolichestvo > 0),

CHECK (data_zakluchenia < data_rastorjenia),

PRIMARY KEY (no_dogovora)

FOREIGN KEY (kod_disc)

REFERENCES table4_slushatel (no_pasporta)

ON DELETE CASCADE ON UPDATE CASCADE,

);

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

CREATE TABLE table8_zanyatie

(

kod_disc INTEGER NOT NULL,

kod_uslugi INTEGER NOT NULL,

no_dogovora INTEGER NOT NULL,

CHECK (kod_disc >= 0),

CHECK (kod_uslugi >= 0),

CHECK (no_dogovora >= 0),

FOREIGN KEY (kod_disc)

REFERENCES table5_disciplina (kod_disc)

ON DELETE NO ACTION ON UPDATE CASCADE,

FOREIGN KEY (kod_uslugi)

REFERENCES table5_disciplina (table6_usluga)

ON DELETE NO ACTION ON UPDATE CASCADE,

FOREIGN KEY (no_dogovora)

REFERENCES table6_usluga (table7_dogovor)

ON DELETE CASCADE ON UPDATE CASCADE

);

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

COMMIT;

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Размещено на Allbest.ru