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

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

2014-12-11

1.57 MB

657 чел.


Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск


Содержание

Введение 4

1 Задание на проектирование 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение 34

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

Приложение 1 36


Введение

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

Современной формой информационных систем являются базы данных.

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

Для работы с такой структурой данных используются специальные средства – Системы управления базами данных (СУБД). В качестве ознакомительной системы в ходе изучения курса  «Базы данных» была изучена СУБД 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) Ни одно из неключевых полей таблицы не зависит функционально от любого другого неключевого поля


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

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) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом


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

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) Все поля таблицы, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом

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

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
  6.  Шпак Ю. А. «Delphi 7 в примерах»
  7.  Бобровский С. И. «Delphi 7. Учебный курс»
  8.  Баженов И. Ю. «Delphi 7. Самоучитель программиста»
  9.  «Transact – SQL Help». – Microsoft, 2000.
  10.  Дьюсон Р. SQL Server 2000. Программирование. Пер. с англ. –М.:БИНОМ, 2002, - 812с., ил.

PAGE   \* MERGEFORMAT4



 

Другие похожие работы, которые могут вас заинтересовать.
5061. Создание базы данных поликлиники 2.4 MB
  Развитие средств вычислительной техники и информационных технологий обеспечило возможности для создания и широкого применения автоматизированных информационных систем (АИС) разнообразного назначения. Разрабатываются и внедряются информационные системы управления хозяйственными и техническими объектами
14200. Создание базы данных «Составление учебного плана» 1.62 MB
  База данных – это особым образом организованное хранилище информации, снабженное специальными программами. Эти программы позволяют вводить данные в БД, корректировать их, хранить. Кроме того, они реализуют информационные запросы пользователей, позволяя выбирать (группировать, фильтровать) нужную им информацию. Примером информационной системы может служить Справочная правовая система Консультант Плюс.
14064. Проектирование и создание базы данных «Архив МБУК Ижболдинский СДК» 24.67 KB
  Столбец таблицы содержит однотипную для всех записей информацию и называется полем. DBText – Используется для отображения но неизменения текущих текстовых полей набора данных. DBEdit – Предназначен для отображения и изменения текстовых полей набора данных. Подобен компоненту ComboBox страницы Stndrd но обслуживает текстовое поле БД.
19473. Создание базы данных для учета лекарственных средств и изделий медицинского назначения в аптеках стационаров 1.71 MB
  анная работа посвящена проектированию базы данных «Аптека» для учета лекарственных средств и изделий медицинского назначения, предназначенной для использования в аптеках стационаров лечебно-профилактических учреждений (ЛПУ) Нижегородской области и Нижнего Новгорода.
8064. Распределенные базы данных 43.66 KB
  Распределенные базы данных Под распределенной базой данных РБД понимается набор логически связанных между собой разделяемых данных которые физически распределены по разных узлам компьютерной сети. Доступ к данным не должен зависеть от наличия или отсутствия реплик данных. Система должна автоматически определять методы выполнения соединения объединения данных сетевой канал способный справиться с объёмом передаваемой информации и узел имеющий достаточную вычислительную мощность для соединения таблиц. СУРБД должна быть способной...
8032. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ 294.61 KB
  Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных
20319. БАЗЫ ДАННЫХ И ИХ ЗАЩИТА 102.86 KB
  Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.
6914. Понятие базы данных 11.56 KB
  Базой данных является представленная в объективной форме совокупность самостоятельных материалов статей расчетов нормативных актов судебных решений и иных подобных материалов систематизированных таким образом чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины Гражданский кодекс РФ ст. База данных организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных характеризующая актуальное состояние некоторой...
14095. Разработка базы данных библиотеки 11.72 MB
  Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД.
13542. Базы данных геологической информации 20.73 KB
  В последнее время широкими темпами происходит внедрение компьютерных технологий и, в частности баз данных, в научную сферу. Этот процесс не обходит стороной и геологию, так как именно в естественных науках имеется необходимость для хранения и обработки больших объемов информации.
© "REFLEADER" http://refleader.ru/
Все права на сайт и размещенные работы
защищены законом об авторском праве.