Файл: Характеристика места прохождения практики 2 Краткое описание и анализ результатов проделанной работы 3 1.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 23.11.2023
Просмотров: 82
Скачиваний: 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. Выполнение запросов
Виды запросов в информационной системе:
1. Вывести список студентов, которые не сдавали указанную сессию, то есть не делали ни одной попытки сдать хотя бы один экзамен. Результат запроса представлен на рисунке 23.
select фа_ст
from ст left outer join
ведомость
on ст.ном_зач = ведомость.ном_зач
where ст.ном_зач != all
(select ном_зач
from ведомость
where сем_тр =1);
Рисунок 23 – Запрос 1
2. Вывести список всех студентов указанной группы, сдавших и не сдавших экзамен (оценку)/зачет по указанной дисциплине. Результат запроса представлен на рисунке 24.
select distinct ст.фа_ст as “фамилия”, ведомость.оценка, ведомость.номер_дисц,
(select н_гр from ст where н_гр =531 ) as “номер группы”
from ст inner join ведомость
on ст.ном_зач = ведомость.ном_зач
where номер_дисц =1;
Рисунок 24 – Запрос 2
3. Вывести для указанного преподавателя общее число студентов, сдавших экзамен по указанной дисциплине для каждой группы. Результат запроса представлен на рисунке 25.
select фамилия_пр,count(ведомость.ном_зач) as “кол-во ст”
from преподаватель inner join ведомость on преподаватель.номер_преп=ведомость.номер_преп
where оценка = ‘удовл’ or оценка = ‘хор’ or оценка = ‘отл’ or оценка = ‘зачет’ and номер_дисц = 1
group by фамилия_пр
having фамилия_пр =’алексеев’;
Рисунок 25 – Запрос 3
4. Вывести список преподавателей, подчиняющихся указанному заведующему. Результат представлен на рисунке 26.
select s.фамилия_пр as “зав_каф”,n.фамилия_пр as “препод”
from преподаватель s
inner join преподаватель n
on s.номер_преп = n.подчиняется;
Рисунок 26 – Запрос 4
5. Вывести список преподаватель и число дисциплин, которые он преподает. Результат представлен на рисунке 27.
select фамилия_пр,count(номер_дисц) as “кол-во предметов”
from преподаватель inner join дисц_преп on преподаватель.номер_преп=дисц_преп.номер_преп
group by фамилия_пр;
Рисунок 27 – Запрос 5
В результате выполнения работы была спроектирована информационная система Вуза. Данный проект удовлетворяет основным требованиям, предъявленным в задании.