Создание базы данных "Деканат ВУЗа"

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

Содержание

• Введение
• 1 Задание на проектирование
• 2 Разработка структуры БД
• 2.1 Описание предметной области
• 2.3 Создание инфологической модели БД
• 2.3.1 Процедура нормализации сущностей
• 2.4 Создание даталогической модели
• 2.5 Выбор технических и программных средств реализации БД и клиентского приложения
• 3 Создание базы данных «Деканат ВУЗа»
• 3.1 Описание структуры базы данных
• 3.2 Описание свойств таблиц БД
• 3.3 Описание связей между таблицами БД и условий целостности данных
• 3.4 Описание хранимых процедур
• 4 Создание пользовательского интерфейса информационной системы
• 4.1 Пользовательское меню
• 4.2 Формы как средство добавления, удаления, просмотра, изменений данных в БД
• 4.3 Формирование запросов к базе данных
• Заключение
• Список использованных источников
• Введение
• В настоящее время успешная работа различных предприятий, организаций и коллективов, а также отдельных их сотрудников подразумевает, как правило, разработку и использование информационной системы (ИС). На ИС возлагают задачи сбора, хранения и обработки необходимых данных об организации, ее сотрудниках и т. п.
• Современной формой информационных систем являются базы данных.
• База данных (БД) - это совокупность взаимосвязанных, хранящихся вместе на внешних носителях памяти компьютера данных, при наличии такой организации и минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений; данные запоминаются и используются так, чтобы они были независимы от программ, использующих эти данные, а программы были независимы от способа и структуры хранения данных.
• Для работы с такой структурой данных используются специальные средства - Системы управления базами данных (СУБД). В качестве ознакомительной системы в ходе изучения курса «Базы данных» была изучена СУБД Microsoft SQL Server 2008.
• Целью данной курсовой работы является систематизация, накопление, закрепление знаний о построении инфологической модели и построение и реализация инфологической модели базы данных «Деканат».
• 1 Задание на проектирование
• Создать реляционную базу данных, в соответствии с индивидуальным вариантом задания, средствами СУБД MS SQL Server 2000. Разработать клиентское исполняемое приложение с удобным пользовательским интерфейсом (сопровождающееся меню и справочной системой) для обеспечения следующих задач:
• - Ввод, анализ введенных пользователем данных, их просмотр, корректировку и удаление;
• - Логики обработки данных;

- Формирования запросов и отчетов с возможностью вывода результатов на экран монитора или принтер (или экспорт данных в документы MS Office).

2 Разработка структуры БД

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

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

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

В деканате составляется расписание занятий. Деканат контролирует работу преподавателей и студентов на предмет её соответствия учебному плану, осуществляет общее руководство научной работой студентов.

В деканате ведется учет кафедр, сотрудников, групп и студентов. Сведения о кафедре включают:

- Код кафедры;

- Наименование;

- Код сотрудника_зав.кафедрой.

Сведения о сотрудниках включают:

- Код сотрудника;

- ФИО;

- Код кафедры.

Данные о группах содержат параметры:

- Код группы;

- Наименование;

- Код кафедры;

- Код студента_старосты;

- Сумма оплаты за обучение.

Информация о студентах характеризуется следующими параметрами:

- Код студента;

- ФИО;

- Код группы;

- Вид обучения;

- Накопленная сумма оплаты за обучение.

Расписание, результаты экзаменов и оплата студентами за обучение фиксируются в одноименных таблицах. Также есть таблицы учета дисциплин, по которым сдаются экзамены, и оценок, полученных во время сессии.

Таблица «Дисциплины» включает параметры:

- Код предмета;

- Наименование.

Таблица «Расписание» включает параметры:

- Признак [экзамен/зачет];

- Дата;

- Код группы;

- Код предмета;

- Код преподавателя;

- Численность группы;

- Аудитория;

- Время.

Сведения о результатах включают параметры:

- № ведомости;

- Признак [экзамен/зачет];

- Дата;

- Код группы;

- Код предмета;

- Код преподавателя;

- Кол-во аттестованных;

- Из них кол-во пятерок;

- Кол-во четверок;

- Кол-во троек;

- Кол-во неаттестованных;

- Кол-во неявок.

Таблица «Результат_оценка» включает в себя:

- № ведомости;

- Код студента;

- Код оценки.

Сведения об оценках, полученных при сдаче экзаменов, включают параметры:

- Код оценки;

- Наименование [2/3/4/5/неявка/зачет/незачет];

- Тип оценки [положительная, неудовлетворительная].

В таблице «Оплата» представлены следующие параметры:

- Код студента;

- Дата;

- Сумма.

С информационной системой должны работать следующие группы пользователей:

- Декан;

- Заместитель декана.

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

- просматривать содержащуюся в БД информацию;

- составлять расписание экзаменов;

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

2.2 Анализ информационных потоков

2.2.1 Входные данные

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

Условно-постоянные:

- Кафедра (Код кафедры, наименование, код сотрудника_ зав.кафедрой);

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

- Студенты (код студента, ФИО, код группы, вид обучения, накопленная сумма оплаты за обучение);

- Дисциплины (Код предмета, наименование);

- Сотрудники (Код сотрудника, ФИО, код кафедры);

- Оценки (Код оценки, наименование [2/3/4/5/неявка/зачет/незачет], тип оценки [положительная, неудовлетворительная]).

- Оперативные:

- Расписание (признак [экзамен/зачет], дата, код группы, код предмета, код преподавателя, численность группы, аудитория, время);

- Результаты (№ ведомости, признак [экзамен/зачет], дата, код группы, код предмета, код преподавателя, кол-во аттестованных, из них кол-во пятерок, кол-во четверок, кол-во троек, кол-во неаттестованных, кол-во неявок);

- Результат_оценка (№ ведомости, код студента, код оценки);

- Оплата (Код студента, дата, сумма).

2.2.2 Выходные данные

Выходными данными в данной системе являются:

Запросы:

- Количество экзаменов запланированных ежедневно в сессию;

- Средний балл сессии студентов «i-го» типа обучения;

- Список преподавателей, принимавших экзамены «i-го» числа;

- Список студентов-задолжников по результатам сессии (двойки, н/зач, неявки);

- Список дисциплин, по которым сдавались экзамены и зачеты в названии которых встречается слово «основы».

Отчет:

- Экзаменационная ведомость на «i-ю» дату по «j-му» предмету «k-ой» группе.

2.3 Создание инфологической модели БД

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

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

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

На концептуальном уровне оперируют понятиями: сущность, атрибут, связь. Инфологическая модель подсистемы «Деканат ВУЗа» на основе данных понятий приведена в таблицах 2.1 - 2.10.

Таблица 2.1 - Инфологическая модель таблицы «Кафедра»

Имя сущности	Кафедра	Тип сущности	Обозначение
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код кафедры	ключевой	простой	однозначный	основной
Наименование	описательный	простой	однозначный	основной
Код сотрудника	ключевой	простой	однозначный	основной

Таблица 2.2 - Инфологическая модель таблицы «Группы»

Имя сущности	Группы	Тип сущности	Стержень
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код группы	ключевой	простой	однозначный	основной
Наименование	описательный	простой	многозначный	основной
Код кафедры	ключевой	простой	однозначный	основной
Код студента	ключевой	простой	однозначный	основной
Сумма оплаты	описательный	простой	однозначный	основной

Таблица 2.3 - Инфологическая модель таблицы «Студенты»

Имя сущности	Студенты	Тип сущности	Стержень
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код студента	ключевой	простой	однозначный	основной
ФИО	описательный	составной	однозначный	основной
Код группы	ключевой	простой	однозначный	основной
Вид обучения	описательный	простой	однозначный	основной
Накопл.сумма опл.за обучение	описательный	простой	однозначный	основной

Таблица 2.4 - Инфологическая модель таблицы «Дисциплины»

Имя сущности	Дисциплины	Тип сущности	Стержень
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код предмета	ключевой	простой	однозначный	основной
Наименование	описательный	простой	однозначный	основной

Таблица 2.5 - Инфологическая модель таблицы «Сотрудники»

Имя сущности	Сотрудники	Тип сущности	Характеристика
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код сотрудника	ключевой	простой	однозначный	основной
ФИО	описательный	составной	однозначный	основной
Код кафедры	ключевой	простой	однозначный	основной

Таблица 2.6 - Инфологическая модель таблицы «Расписание»

Имя сущности	Расписание	Тип сущности	Стержень
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Признак[экз/зачет]	ключевой	простой	однозначный	основной
Дата	описательный	составной	однозначный	основной
Код группы	ключевой	простой	однозначный	основной
Код предмета	ключевой	простой	однозначный	основной
Код преподавателя	ключевой	простой	однозначный	основной
Числ.группы	описательный	простой	однозначный	основной
Аудитория	описательный	простой	однозначный	основной
Время	описательный	простой	однозначный	основной

Таблица 2.7 - Инфологическая модель таблицы «Результаты»

Имя сущности	Результаты	Тип сущности	Ассоциация
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
№ ведомости	ключевой	простой	однозначный	основной
Признак[экз/зачет]	ключевой	простой	однозначный	основной
Дата	описательный	составной	однозначный	основной
Код группы	ключевой	простой	однозначный	основной
Код предмета	ключевой	простой	однозначный	основной
Код преподавателя	ключевой	простой	однозначный	основной
Кол-во аттест.	описательный	простой	однозначный	основной
Кол-во пятерок	описательный	простой	однозначный	основной
Кол-во четверок	описательный	простой	однозначный	основной
Кол-во троек	описательный	простой	однозначный	основной
Кол-во неаттест.	описательный	простой	однозначный	основной
Кол-во неявок	описательный	простой	однозначный	основной

Таблица 2.8 - Инфологическая модель таблицы «Результат_оценка»

Имя сущности	Результат_оценка	Тип сущности	Ассоциация
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
№ ведомости	ключевой	простой	однозначный	основной
Код студента	ключевой	простой	однозначный	основной
Код оценки	ключевой	простой	однозначный	основной

Таблица 2.9 - Инологическая модель таблицы «Оценки».

Имя сущности	Оценки	Тип сущности	Обозначение
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код оценки	ключевой	простой	однозначный	основной
Наименование	описательный	простой	многозначный	основной
Тип оценки	описательный	простой	однозначный	основной

Таблица 2.10 - Инфологическая модель таблицы «Оплата»

Имя сущности	Оплата	Тип сущности	Стержень
Имя атрибута	Свойства атрибута
	Ключевой/ описательный	Составной/ простой	Однозначный/ многозначный	Основной/ производный
Код студента	ключевой	простой	однозначный	основной
Дата	описательный	составной	однозначный	основной
Сумма	описательный	простой	однозначный	основной

Инфологическая модель базы данных на языке «Таблицы - связи» и на языке ER-диаграмм представлена на первом и четвертом графическом листе.

2.3.1 Процедура нормализации сущностей

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

В теории реляционных баз данных обычно выделяется 5 нормальных форм и нормальная форма Бойса-Кодда. В таблице 2.11 отражено, в каких нормальных формах находятся таблицы базы данных «Деканат ВУЗа».

Таблица 2.11 - Нормализация таблиц базы данных «Деканат ВУЗа»

Название таблицы	Первичный ключ	Функциональные зависимости	Нормальная форма	Обоснование
Kafedra	Kod_kaf	Kod_kaf Name Kod_sotr	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Gruppa	Kod_gr	Kod_gr Name_gr Kod_kaf Kod_stud Sum_god	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Students	Kod_stud	Kod_stud Fio Kod_gr Vid_ob Nak_sum	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Distcipliny	Kod_pr	Kod_pr Name	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Sotrudniki	Kod_sotr	Kod_sotr Fio Kod_kaf	2NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом
Raspisanie	Priznak	Priznak Date Kod_gr Kod_pr Kod_prepod Chislo_gr Aud Time	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Results	Kod_prepod	Num_vedom Priznak Date Kod_gr Kod_pr Kod_prepod Kol_att Kol_five Kol_four Kol_three Kol_neatt Kol_nya	5NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом 3) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля
Result_otsenka	Num_vedom	Num_vedom Kod_stud Kod_ots	3NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом
Otsenka	Kod_ots	Kod_ots Name Type	2NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом
Oplata	Kod_stud	Kod_stud Date Sum	2NF	1) Ни одна из строк таблицы не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто 2) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом

2.4 Создание даталогической модели

Второй этап проектирования базы данных называется логическим проектированием базы данных.

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

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

Описание сущностей предметной области для даталогической модели базы данных «Деканат ВУЗа» приведено в таблицах 2.12 - 2.21.

Таблица 2.12 - Даталогическая модель таблицы «Кафедра»

Имя сущности	Кафедра
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, первичный или внешний)	Индексированное поле (да/нет, указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код кафедры	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Наименование	varchar	2	Да, внешний	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Код сотрудника_ зав.кафедрой	int	2	Да, внешний	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1

Таблица 2.13 - Даталогическая модель таблицы «Группы»

Имя сущности	Группы
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, если да, то указать первичный или внешний)	Индексированное поле (да/нет, если да, то указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код группы	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Наименование	varchar	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 30 символов
Код кафедры	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 30 символов
Код студента_старосты	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 30 символов
Сумма оплаты за обучения	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 30 символов

Таблица 2.14 - Даталогическая модель таблицы «Студенты»

Имя сущности	Студенты
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, указать первичный или внешний)	Индексированное поле (да/нет, указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код студенты	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
ФИО	varchar	50	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов
Код группы	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов
Вид обучения	varchar	50	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов
Накопленная сумма оплаты за обучение	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов

Таблица 2.15 - Даталогическая модель таблицы «Дисциплины»

Имя сущности	Дисциплины
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, указать первичный или внешний)	Индексированное поле (да/нет, указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код предмета	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Наименование	varchar	50	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов

Таблица 2.16 - Даталогическая модель таблицы «Сотрудники»

Имя сущности	Сотрудники
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, указать первичный или внешний)	Индексированное поле (да/нет, тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код сотрудника	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
ФИО	varchar	50	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 40 символов
Код кафедры	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 40 символов

Таблица 2.17 - Даталогическая модель таблицы «Расписание»

Имя сущности	Кассета
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, если да, то указать первичный или внешний)	Индексированное поле (да/нет, если да, то указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Признак [экзамен/зачет]	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Дата	date	4	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?1
Код группы	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?1
Код предмета	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?1
Код преподавателя	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?0
Численность группы	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?0
Аудитория	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?0
Время	time	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?0

Таблица 2.18 - Даталогическая модель таблицы «Результаты»

Имя сущности	Результаты
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет)	Индексированное поле (да/нет)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
№ ведомости	int	2	Да, первичный	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Признак [экзамен/зачет]	varchar	50	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 50 символов
Дата	date	4	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 30 символов
Код группы	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Код предмета	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Код преподавателя	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во аттестованных	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во пятерок	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во четверок	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во троек	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во неаттестованных	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов
Кол-во неявок	int	2	Нет	Нет	Да	NULL-значения не допустимы. Значение поля не должно превышать 12 символов

Таблица 2.19 - Даталогическая модель таблицы «Результат_оценка»

Имя сущности	Результат_оценка
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет)	Индексированное поле (да/нет)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
№ ведомости	int	2	Да, внешний	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Код студента	int	2	Да, внешний	Да, простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Код оценки	int	4	Нет	Нет	Да	NULL-значения не допустимы.

Таблица 2.20 - Даталогическая модель таблицы «Оценки»

Имя сущности	Оценки
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, если да, то указать первичный или внешний)	Индексированное поле (да/нет, если да, то указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код оценки	int	2	Да, внешний	Да, первичный простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Наименование [2/3/4/5/неявка/зачет/незачет]	varchar	2	Да, внешний	Да, первичный простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Тип оценки [положительная, неудовлетворительная]	varchar	2	Да, внешний	Да, первичный простой	Да	NULL-значения не допустимы. Значение должно быть ?1

Таблица 2.21 - Даталогическая модель таблицы «Оплата»

Имя сущности	Оплата
Имя атрибута	Тип данных	Длина	Ключевое поле (да/нет, если да, то указать первичный или внешний)	Индексированное поле (да/нет, если да, то указать тип индекса)	Обязательное поле (да/нет)	Ограничение домена (условие на значение)
Код студента	int	2	Да, внешний	Да, вторичный простой	Да	NULL-значения не допустимы. Значение должно быть ?1
Дата	Date	2	Нет	Нет	Да	NULL-значения не допустимы. Значение должно быть ?1
Сумма	int	4	Нет	Нет	Да	NULL-значения не допустимы.

2.5 Выбор технических и программных средств реализации БД и клиентского приложения

Для реализации базы данных информационной системы «Деканат ВУЗа» было принято решение использовать СУБД «Microsoft SQL Server 2008».

Для написания клиентского приложения была выбрана интегрированная среда разработки Borland Delphi 7.0.

Требования к составу и параметрам технических средств:

1. Система должна работать на IBM-совместимых компьютерах;

2. Минимальная конфигурация:

– тип процессора - Pentium 200

– объем оперативного запоминающего устройства - 128 Mb;

– HDD;

– принтер (струйный, лазерный), совместимый с ОС Win32

Оптимальная конфигурация:

– тип процессора - Pentium 2400 и выше;

– объем оперативного запоминающего устройства - 256 Mb и выше;

– HDD;

– принтер (струйный, лазерный), совместимый с ОС Win32

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

– система должна работать под управлением семейства операционных систем Win32 (Windows 2000/NT/Server 2003/XP и т.д.);

– наличие на ПК установленной SQL Server 2008, Enterprise Edition;

– наличие пакета MS Office для формирования отчетов

3 Создание базы данных «Деканат ВУЗа»

3.1 Описание структуры базы данных

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

База данных «Деканат ВУЗа» является реляционной. В процессе ее разработки были созданы следующие таблицы:

– Kafedra (Кафедра);

– Gruppa (Группы);

– Students (Студенты);

– Distciplina (Дисциплина);

– Sotrudniki (Сотрудники);

– Raspisanie (Расписание);

– Results (Результаты);

– Result_otsenka (Результат_оценка);

– Otsenka (Оценка);

– Oplata (Оплата).

Также в базе данных имеются хранимые процедуры, реализованные на языке T-SQL.

Также в базе данных определены следующие хранимые процедуры:

– Dbo.pr1

– Dbo.pr2

3.2 Описание свойств таблиц БД

база данные таблица интерфейс

Таблицы в БД - это объекты базы данных, предназначенные для хранения пользовательских данных.

Описание свойств таблиц БД «Деканат ВУЗа» представлено на рисунках 3.1 - 3.10

Рисунок 3.1 - Свойства таблицы Kafedra

Рисунок 3.2 - Свойства таблицы Gruppa



Рисунок 3.3 - Свойства таблицы Students

Рисунок 3.4 - Свойства таблицы Distcipliny



Рисунок 3.5 - Свойства таблицы Sotrudniki

Рисунок 3.6 - Свойства таблицы Raspisanie



Рисунок 3.7 - Свойства таблицы Results

Рисунок 3.8 - Свойства таблицы Result_otsenka



Рисунок 3.9 - Свойства таблицы Otsenka

Рисунок 3.10 - Свойства таблицы Oplata

3.3 Описание связей между таблицами БД и условий целостности данных

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

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

Когда созданы отношения (связи) между таблицами, база данных достигла той точки, когда данные в одной таблице начинают зависеть от данных в другой таблице. SQL Server дает возможность увидеть, зависит ли некая таблица от других или нет. Отображение зависимостей можно получить при помощи диаграммы базы данных. Диаграмма базы данных в простейшей форме отображает таблицы (с перечислением атрибутов этих таблиц) и отношения между таблицами. На рисунке 3.11 представлена диаграмма базы данных «Деканат ВУЗа».



Рисунок 3.11 - Диаграммы базы данных "Деканат ВУЗа"

3.4 Описание хранимых процедур

Хранимая процедура - это набор операторов T-SQL, который компилируется системой SQL Server в единый «план исполнения». Хранимые процедуры T-SQL аналогичны процедурам в других языках программирования в том смысле, что они допускают входные параметры и возвращают выходные значения в виде параметров или сообщения о состоянии (успешное или неуспешное завершение). Все операторы процедуры обрабатываются при вызове процедуры. Они могут использоваться различными пользователями для согласованного повторяемого выполнения одинаковых задач и даже в различных приложениях.

В курсовом проекте представлены следующие хранимые процедуры:

Хранимая процедура 1 - Из таблицы Студенты выбрать строки по условию: список студентов «I-ой» группы

USE [Dekanat]

GO

CREATE PROCEDURE proc1

AS

SELECT fio,kod_gr FROM Students

WHERE kod_gr='2'

GO

EXEC proc1

Хранимая процедура 2 - Вставить три новых строки в таблицу Дисциплины

USE [Dekanat]

GO

CREATE PROCEDURE proc_2

AS

INSERT

INTO Distcipliny

VALUES ('11','новая строка'),('12','новая строка'),('13','новая строка')

GO

EXEC proc_2

4 Создание пользовательского интерфейса информационной системы

4.1 Пользовательское меню

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

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

Внешний вид окна подключения к серверу показан на рисунке 4.1.

Рисунок 4.1 - Окно подключения к БД программы "Деканат ВУЗа"

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

Рис. 4.2 Окно подтверждения программы «Деканат ВУЗа»

После подключения базы появится главное окно программы «Деканат ВУЗа», представленное на рисунке 4.3.

Рисунок 4.3 - Главное окно программы «Деканат ВУЗа»

Пользовательское меню программы «Деканат ВУЗа» содержит следующие пункты и подпункты:

- Действия

- Выход

- Таблицы

- Кафедра

- Группы

- Студенты

- Дисциплины

- Сотрудники

- Расписание

- Результаты

- Результат_оценка

- Оценки

- Оплата

- Запросы

- Хранимые процедуры

- Помощь

- О программе

4.2 Формы как средство добавления, удаления, просмотра, изменений данных в БД

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

В режим работы с таблицами базы данных можно войти при помощи пункта Таблицы главного меню программы. На рисунке 4.5 показан внешний вид главного окна приложения в режиме просмотра таблицы Студенты.

Рисунок 4.5 Вид главного окна приложения при выборе таблицы Студенты

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

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

4.3 Формирование запросов к базе данных

Для перехода программы в режим запросов, необходимо выбрать пункт Запросы главного меню программы. На рисунке 4.6 показан внешний вид окна Запросы.

Рисунок 4.6 - Входная форма «Запросы» программы «Деканат ВУЗа»

Окно Запросы содержит следующие элементы:

- набор радиокнопок - служит для выбора запроса

- главное меню

- кнопку Выполнить запрос

- кнопку Назад для возвращения в главное окно программы

- таблицу для отображения результатов запроса.

Программа содержит следующие запросы:

Запрос 1 - Количество экзаменов запланированных в сессию

SELECT COUNT(*) FROM Raspisanie WHERE priznak='экзамен';

Запрос 2 - Средний балл сессии студентов i-го вида обучения

SELECT AVG(convert(int,name)) FROM Otsenka

INNER JOIN Result_otsenka ON Result_otsenka.kod_ots=Otsenka.kod_ots

INNER JOIN Students ON Students.kod_stud=Result_otsenka.kod_stud

WHERE Result_otsenka.kod_ots BETWEEN '1' and '4' and vid_ob='очный'

Запрос 3 - Список преподавателей, принимавших экзамены i-го числа

SELECT Sotrudniki.kod_sotr,fio,Raspisanie.date FROM Sotrudniki

INNER JOIN Kafedra on Kafedra.kod_sotr=Sotrudniki.kod_sotr

INNER JOIN Gruppa on Gruppa.kod_kaf=Kafedra.kod_kaf

INNER JOIN Raspisanie on Raspisanie.kod_gr=Gruppa.kod_gr

WHERE priznak='экзамен' and date='2014-05-05';

Запрос 4 - Список студентов-задолжников по результатам сессии (двойки, н/зач, неявки)

SELECT fio,Otsenka.name FROM Students

INNER JOIN Result_otsenka on Result_otsenka.kod_stud = Students. kod_stud

INNER JOIN Otsenka on Otsenka.kod_ots=Result_otsenka.kod_ots

WHERE Otsenka.name in ('2','неявка','не зачет');

Запрос 5 - Список дисциплин, по которым сдавались экзамены и зачеты в названии которых встречается слово «основы»

SELECT Distcipliny.name FROM Distcipliny

WHERE Distcipliny.name like '%Основы%'

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

Пример выполнения запроса 3 показан на рисунке 4.7.



Рисунок 4.7 - Результат выполнения запроса 3

Заключение

В ходе реализации курсового проекта выполнены следующие виды работ:

- разработка структуры базы данных;

- создание базы данных;

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

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

Список использованных источников

1. Гофман В., Хомоненко А. «Delphi- экспресс курс » - СПб БХВ-Петербург, 2005

2. Фаронов В. «Система программирования Delphi» - СПб: БХВ-Петербург, 2005

3. Фаронов В. «Программирование баз данных в Delphi 6» - СПб: Питер, 2002

4. Культин Н.Б. «Delphi в задачах и примерах». - СПб БХВ-Петербург, 2003

5. Архангельский А. Я. «Программирование в Delphi 7»

6. Шпак Ю. А. «Delphi 7 в примерах»

7. Бобровский С. И. «Delphi 7. Учебный курс»

8. Баженов И. Ю. «Delphi 7. Самоучитель программиста»

9. «Transact - SQL Help». - Microsoft, 2000.

10. Дьюсон Р. SQL Server 2000. Программирование. Пер. с англ. -М.:БИНОМ, 2002, - 812с., ил.

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