ВВЕДЕНИЕ
Информатизация общества и связанное с ней широкое распространение вычислительной техники и средств коммуникации устанавливают максимальный приоритет задаче, для создания специальных методов обработки данных: их поиск, защиту, обработку и хранение.
Целью данной статьи является проектирование информационной системы Вуза. Данная тема является актуальной, так как в современных условиях внутренний контроль любой корпорации должен присутствовать на всех уровнях управления, а практически эффективная система внутреннего контроля – это гарантия успешной деятельности учебного заведения.
Информационная система Вуза предполагает учет успеваемости студентов различных групп.
В соответствии с поставленной целью в работе предполагается решить следующие задачи:
1. Проанализировать заданную предметную область и создать логическую модель базы данных. Проверить модель на удовлетворение требованиям нормализации;
2. Создать физическую модель базы данных, предусмотрев значения по умолчанию и условия вводимых пользователем значений;
3. Провести прямое проектирование;
4. Проверить базу данных в Oracle;
5. Провести обратное проектирование базы данных из Oracle;
6. Проверить модель средствами Validator и устранить ошибки;
7. Написать запросы.
1 ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
1.1. Предметная область
Предметной областью данной работы является база данных вуза.
Рассматривая данную тему, необходимо выделить основные объекты, которые являются ключевыми для создания модели данной системы.
БД хранить информацию о студентах разных групп и специальностей, учебном плане с указанием дисциплины, количества часов на каждый вид занятий по дисциплине, и формы контроля.
Студенты разных специальностей, форм обучений и факультетов сдают соответствующий зачет или экзамен на оценку преподавателю, которая заносится в ведомость.
Преподаватели относятся к определенной кафедре и факультету, и подчиняются заведующему кафедры.
1.2. Инфологическая модель
В рассматриваемой системе можно выделить следующие сущности:
-
СТ включает в себя информацию о студенте (Номер_зачетки, Дата_поступления, Номер_группы, Паспорт_ст, Фамилия, ст, Имя_ст, Отчество_ст, Факультет, Форма_обуч)
-
Группа включает в себя информацию о группе (Номер_группы, Направление)
-
Ведомость хранит информацию о сданных зачетах и экзаменах (Дата_сдачи, Семестр, Оценка, Номер_зачетки, Номер_дисц, Номер_преп, Форма_контр)
-
Дисциплина включает в себя информацию об учебном предмете (Номер_дисц, Наименование)
-
Учебный план хранит информацию о том, для студентов каких специальностей читается данная дисциплина (Код_уч_пл, Код_спец)
-
Часы включает в себя информацию о количестве часов на каждый вид занятий по определенной дисциплине (Курс, Семестр, Вид_зан, Номер_дисц, Часы, Код_уч_пл)
-
Преподаватель включает информацию о преподавательском составе вуза (Номер_преп, Фамилия_пр, Имя_пр, Отчество_пр, Должность, Факультет_пр, Паспорт_пр, Номер_каф, Подчиняется)
-
Кафедра включает в себя информацию о кафедре (Номер_каф, Наименование)
-
Специальность включает в себя информацию о специальности (Код_спец, Название)
-
Дисц_Пред включает в себя информацию о том, какую дисциплину ведет каждый преподаватель (Номер_дисц, преп)
-
Дисц_уч_план включает в себя информацию какая дисциплина прописана в каждом учебном плане (Номер_дисц, Код_уч_пл)
Между сущностями существуют следующие связи:
- В одной группе может учится много студентов, но один студент может учится только в одной группе (1:М).
- Один студент может сдавать экзамены и зачеты по многим дисциплинам, но по одной дисциплине могут сдавать экзамены и зачеты много студентов (М:М).
- В учебном плане хранится информация о многих дисциплинах, но одна и та же дисциплина может быть указана в нескольких учебных планах (М:М).
- Один преподаватель может работать на определенной кафедре, но на одной кафедре может работать много преподавателей (1:М).
- Один преподаватель может подчиняться заведующему кафедры, который также может преподавать, но у одного заведующего кафедры в подчинении может находиться много преподавателей (Унарная связь).
- Один преподаватель может вести много дисциплин, одну дисциплину может вести много преподавателей (М:М)
Логическая модель базы данных представлена на рисунке 1.
Рисунок 1- Логическая модель
1.3. Нормализация отношений
Согласно требованию первой нормальной формы, в таблице все строки должны быть различны и все элементы внутри ячеек должны быть атомарны[1]. Отсюда следует, что спроектированная модель находится в первой нормальной форме.
Таблицы также находятся и во второй нормальной форме, так как любое её поле, не входящее в состав первичного ключа, функционально полно зависит от первичного ключа[1].
Также можно сказать, что эти таблицы будут находиться в третьей нормальной форме, потому что неключевые атрибуты зависят от составного ключа нетранзитивно, эти атрибуты взаимно не зависимы, что удовлетворяет правилу третьей нормальной формы[1].
2. Датологическое проектирование
2.1. Физическая модель с указанными типами данных
Для реализации связи М:М (многие ко многим) вводятся ассоциативные таблицы:
Для связи между таблицами Дисциплина и Учебный_план вводится таблица Дисц_Уч_план.
Для связи между таблицами Преподаватель и Дисциплина вводится таблица Дисц_Преп.
Физическая модель с указанными типами данных представлена на Рисунке 2.
Рисунок 2 – Физическая модель
Для поля Часы вводится значение по умолчанию. Для некоторых полей предусмотрено условия проверки вводимых пользователем значений. Результаты представлены на рисунках 3 и 4 соответственно.
Рисунок 3–Наложение значений по умолчанию
Рисунок 4 – Наложение условия проверки вводимых значений
2.2. Отчет по ошибкам из Validator
После проверки созданной модели программой ERwin Data Model Validator, ошибок обнаружено не было. Результат представлен на рисунке 5.
Рисунок 5 – Диагностика модели в Validator
2.3. Прямое проектирование
Было проведено прямое проектирование, в результате которого создаются объекты базы данных в Oracle. На рисунках 6 и 7 соответственно представлено начало и результат прямого проектирования.
Рисунок 6 – Начало прямого проектирования
Рисунок 7- Результат прямого проектирования
2.4. Заполнение таблицы
Таблицы БД SQL Developer необходимо заполнять данными в определенной последовательности. Сначала надо заполнять главные таблицы, а затем подчиненные. Заполнение таблиц для базы данных вуза целесообразно выполнять в такой последовательности: Группа, СТ, Дисциплина, Кафедра, Преподаватель, Ведомость, Специальность, Учебный_план, Часы, Дисц_уч_план, Дисц_Преп.
На рисунках с 8 по 18 включительно представлены заполненные таблицы в указанной последовательности.
Рисунок 8 – Таблица Группа
Рисунок 9 –Таблица СТ
Рисунок 10 – Таблица Дисциплина
Рисунок 11 – Таблица Кафедра
Рисунок 12 – Таблица Преподаватель
Рисунок 13 – Таблица Ведомость
Рисунок 14 – Таблица Специальность
Рисунок 15 – Таблица Учебный_план
Рисунок 16 – Таблица Часы
Рисунок 17 – Таблица Дисц_Уч_План
Рисунок 18 – Таблица Дисц_Преп
2.5. Проверка работоспособности
Для некоторых полей вводятся значения по умолчанию и условия проверки вводимых пользователем значений. Если при заполнении таблицы не учитывать эти ограничения SQL Developer выдает ошибку “check constraint”.
Для поля Оценка в таблице ведомость должно быть условие Оценка = ‘отл’ or оценка = ‘хор’ or оценка = ‘удовл’ or оценка = ‘плохо’ or оценка = ‘зачет’ or оценка = ‘незачет’. Для поля Форма_контроля должно быть условие форма_контроля=’зачет’ or форма_контроля=’экзамен’.
Результат представлен на рисунке 19.
Рисунок 19 – Проверка условий для полей Оценка и Форма_контроля
Для полей Курс и Семестр в таблице Часы значения должны быть положительными. Результат представлен на рисунке 20.
Рисунок 20 – Проверка условий для полей Курс и Семестр
Для поля Вид_зан условие должно быть Вид_зан=’Лекция’ or Вид_зан=’Семинар’ or Вид_зан=’ЛР’ or Вид_зан=’КР’. Результат представлен на рисунке 21.
Рисунок 21 – Проверка условий для поля Вид_зан
Для поля Часы в таблице Часы установлено значение по умолчанию, равное нулю. Результат представлен на рисунке 22.
Рисунок 22 – Проверка условия по умолчанию для поля Часы
2.6. Выполнение запросов
Виды запросов в информационной системе:
select фа_ст
from ст left outer join
ведомость
on ст.ном_зач = ведомость.ном_зач
where ст.ном_зач != all
(select ном_зач
from ведомость
where сем_тр =1);
Рисунок 23 – Запрос 1
select distinct ст.фа_ст as “фамилия”, ведомость.оценка , ведомость.номер_дисц,
(select н_гр from ст where н_гр =531 ) as “номер группы”
from ст inner join ведомость
on ст.ном_зач = ведомость.ном_зач
where номер_дисц =1;
Рисунок 24 – Запрос 2
select фамилия_пр,count(ведомость.ном_зач) as “кол-во ст”
from преподаватель inner join ведомость on преподаватель.номер_преп=ведомость.номер_преп
where оценка = ‘удовл’ or оценка = ‘хор’ or оценка = ‘отл’ or оценка = ‘зачет’ and номер_дисц = 1
group by фамилия_пр
having фамилия_пр =’алексеев’;
Рисунок 25 – Запрос 3
select s.фамилия_пр as “зав_каф”,n.фамилия_пр as “препод”
from преподаватель s
inner join преподаватель n
on s.номер_преп = n.подчиняется;
Рисунок 26 – Запрос 4
select фамилия_пр,count(номер_дисц) as “кол-во предметов”
from преподаватель inner join дисц_преп on преподаватель.номер_преп=дисц_преп.номер_преп
group by фамилия_пр;
Рисунок 27 – Запрос 5
ЗАКЛЮЧЕНИЕ
В результате выполнения работы была спроектирована информационная система Вуза. Данный проект удовлетворяет основным требованиям, предъявленным в задании.
В процессе выполнения работы была проанализирована заданная предметная область, выполнена проверка базы данных, в результате которой аномалий выявлено не было, все таблицы были нормализованы. Была построена модель базы данных в ERwin, были предусмотрены значения по умолчанию и условия вводимых пользователем значений. Спроектированная модель была проверена в ERwin Validator, обнаруженные ошибки были устранены.
Было произведено прямое и обратное проектирование, были заполнены таблицы и написаны SQL запросы.
Библиографический список
- Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. – Уфа, 1999. – 138 с. – ISBN 5-7477-0351-X.
Количество просмотров публикации: Please wait