СОДЕРЖАНИЕ
1 Введение
2 Основная часть
2.1 Обследование предметной области
2.5 Запросы к БД
2.6 Машинная реализация программы
2.6.1Создание форм
2.7 Разработка механизмов защиты данных
2.8 Требования к техническому обеспечению
2.8.1 Требования к системе:
2.8.2 Требования к видам по:
2.8.3 Общие требования к системе
3 Заключение
4 Список использованной литературы
1 Введение
Сегодня трудно себе представить сколько-нибудь значимую информационную систему, которая не имела бы в качестве основы или важной составляющей базу данных. Концепции и технологии баз данных складывались постепенно и всегда были тесно связаны с развитием автоматической обработки информации. Создание баз данных после появления реляционного подхода превратилось из искусства в науку, но, как показала практика последних лет, все же окончательно его не исключившая. Тем не менее, сейчас это вполне сложившаяся дисциплина (хотя являющаяся скорее инженерной, чем чисто научной), основанная на достаточно формализованных подходах и включающая широкий спектр приемов и методов создания баз данных.
Данные существуют всегда, пока есть потребность в их использовании, хотя характер использования, как и пути извлечения практической пользы, могут быть самыми разными: от оперативной актуализации значений до уничтожения данных.
Достаточно консервативны и концепции баз данных. Эта консервативность – следствие не только свойства «долговечности», но и того факта, что базы вторичны по отношению к описываемым ими реальным процессам и объектам, достаточно стабильным и типичным. Кроме того, модели данных строились в значительной степени «по аналогии» с организационными и технологическими структурами – иерархическими, сетевыми, матричными.
Создание практически полезной «сырьевой» базы данных в равной степени зависит как от «фундаментальности» знаний разработчика в области концепций и технологий СУБД, так и от степени понимания им сегодняшних и будущих прикладных задач пользователя.
2 Основная часть
2.1 Обследование предметной области
В настоящее время процесс компьютеризации и автоматизации всего, что только можно захватил всю планету. Зачастую автоматизируются даже те области, в которых эта автоматизация приводит только к увеличению трудозатрат. Но в совершенно неожиданных местах мы можем обнаружить области деятельности человека, которые можно и нужно было бы автоматизировать, но в силу каких то причин, этой автоматизации проведено не было. Одной из таких областей является работа деканата и УМО.
Не секрет, что много времени работников занимает создание расписания занятий. Учет размеров аудиторий, занятости преподавателей, учет предпочтений и многие другие факторы делают эту задачу для человека очень сложной. В данной работе от человека требуется учет огромного числа факторов, одна запись которых на обыкновенной бумаге занимает не одну страницу, как следствие в расписаниях часто возникают ошибки и нестыковки. Если представить, что такой работой занимаются на каждом факультете, каждого ВУЗа по два, а то и четыре раза в год по несколько дней, выходит огромная сумма, как затрат по времени, так и денежных затрат на оплату этих работ. Созданная база должна существенно облегчить, а также частично автоматизировать работу составителей расписания.
Главная проблема, на сегодняшний день, которая стоит перед большинством учебных заведений – управление учебным процессом, которое включает в себя множество, казалось бы, не решаемых задач.
Одной из сложнейших является составление расписания занятий. Основная трудность её решения заключена в требованиях оперативности. В реальном масштабе времени необходимо создавать расписание и корректировать его. Дополнительные затруднения вносят многие факторы, к которым могут быть отнесены:
- «спринтерская гонка» при распределении нагрузок и комплектовании преподавателей в начале учебного года (с 25 августа по 1 сентября). Подобрать за этот период даже «условно переменную часть» преподавательского корпуса очень сложно. Это порождает изменения и после 1 сентября и в составе преподавателей, и в нагрузках. Что, естественно, отражается на расписании;
- наличие «сторонних преподавателей» создаёт «хроническую необходимость» вносить экстренные корректировки в течение всего учебного года;
- в условиях отсутствия резерва учебных помещений в проблему превращается составление расписания занятий заочного отделения.
Эти и многие другие факторы создают стрессовый характер в работе по составлению расписания занятий.
На сегодняшний день можно рассмотреть одно из придуманных решений этой проблемы. Использование текстового процессора Word позволяет «водрузить» составление расписания на одного работника. Но здесь возникает и ряд проблем:
- перегрузка этого рабочего места в пиковые периоды;
- неизбежные ошибки, связанные с отсутствием времени и средств контроля;
- невозможность взаимозаменяемости и, следовательно, отсутствие надежности.
В связи с этим, в этих условиях необходимо разработать информационную технологию, которая бы позволила:
- готовить большую часть исходной информации для составления расписания до 25 августа;
- распределить информацию, поступающую после 25 августа на несколько рабочих мест;
- обеспечить контроль входной и выходной информации.
Разработка базы данных является в данном случае наиболее подходящим способом решения всех проблем:
Большая часть информации для разработки расписания является практически постоянной:
- до 80% преподавателей;
- до 90% аудиторий;
- порядка 80-90% дисциплин;
- до 70% групп.
б) Изменения могут быть распределены для внесения в БД на несколько рабочих мест.
в) Информация в базе данных хранится в таблицах. СУБД контролирует целостность данных, вводимых в базу данных в соответствии с установленными связями.
Кроме этого можно будет контролировать программно типичные ошибочные ситуации:
- накладки занятий в одной аудитории, то есть проведение одновременно двух различных занятий;
- проведение занятий одним и тем же преподавателем одновременно в различных аудиториях и т.д.
- разрыв учебного процесса.
- возможность проведения занятий двух групп в одном кабинете и с одним преподавателем.
В соответствии с поставленной целью необходимо провести ряд работ.
Во-первых, нужно провести обследование процессов, связанных с составлением расписания для филиала СевКавГТУ в городе Кисловодске.
Во-вторых, на основании документов обследования разработать структуру базы данных для разработки расписания.
В результате проведенного обследования были получены следующие входные документы:
- расчёт учебных часов преподавателей (на кафедрах филиала);
- список преподавателей филиала с необходимыми данными:
Ф.И.О.,
должность,
предмет,
кафедра,
ограничения по времени проведения занятий и т.д.
- список аудиторий, содержащий данные: обозначение, назначение (предмет и вид занятий), количество мест;
- список групп: год группы, курс, семестр, форма обучения, специальность, число студентов, число подгрупп.
На основании анализа полученных документов был сделан выбор информационных объектов, составлен перечень сущностей (таблиц) и атрибутов, а также была разработана структурная схема базы данных.
Таблица 1 - Характеристика структуры таблиц
|Название таблицы |Описание поля |Название поля |Тип поля и размер |
|Dolzh |Код должности |IDDolzh |Int |
| |Наименование должности. |Naimen |Nchar(30) |
|Kafed |Код кафедры |IDKafed |Int |
| |Наименование кафедры |Naimen |Nchar(30) |
|Zvan |Код звания |IDZvan |Int |
| |Наименование звания |Naimen |Nchar(30) |
|Prepod |Код преподавателя |IDPrep |Int |
| | | | |
| | | | |
| |Код должности |IDDolzh |numeric |
| |Код звания |IDZvan |Numeric |
| |Код кафедры |IDKafed |Numeric |
| |Фамилия преподавателя |Family |Nchar(20) |
| |Имя преподавателя |Name |Nchar(20) |
| |Отчество преподавателя |Surname |Nchar(20) |
|Group |Код.группы |IDGroup |Int |
| |Наименование группы |Naimen |Nchar(10) |
| |Число студентов |Chisl_stud |numeric |
| |Число подгрупп |Chisl_podg |Numeric |
| |Год поступления |God_post |date |
|Disc |Код дисциплины |ID_disc |Int |
| | | | |
| |Наименование дисциплины |Naimen |Nchar(30) |
| |Количество часов |Kol_chas |numeric |
|Spec |Код специальности |IDSpec |Int |
| |Наименование специальности |Naimen |Nchar(30) |
|Semestr |Код семестра |IDSemestr |Int |
| |Наименование семестра |Naimen |Nchar(5) |
|Obuch |Код формы обучения |IDFobuch |Int |
| |Наименование формы обучения |Naimen |Nchar(10) |
|Vid_zan |Код условий вида занятий |IDVid |Int |
| |Наименование вида занятий |Naimen |Nchar(10) |
|Ucheb_Pl |Код учебного плана |IDUchPl |Int |
| |Код дисциплины |IDdisc |Numeric |
Таблица 2 Продолжение
| |Код специальности |IDSpec |Numeric |
| |Код вида занятия |IDVid |Numeric |
| |Код формы обучения |IDFobuch |Numeric |
| |Код семестра |IDSemestr |Numeric |
| |Год стандарта |God_stand |date |
| |Количество пар |Kol_par |numeric |
|Cel |Код цели |IDCel |Int |
| |Наименование цели |Naimen |Nchar(10) |
|Audit |Код аудитории |IDAud |Int |
| |Наименование аудитории |Naimen |Nchar(15) |
| |Количество мест |Kolv_mest |numeric |
| |Код цели |ID_cel |numeric |
|Pair |Код пары |IDPair |Int |
| |Начало пары |start |time(7) |
| |Конец пары |finish |time(7) |
|Day_of_week |Код дня недели |IDDay |Int |
| |Наименование дня недели |Naimen |Nchar(15) |
|PrePL |Код преподаватель-план |IDPrePL |Int |
| |Код преподавателя |IDPrep |numeric |
| |Код учебного плана |IDUchPL |Numeric |
|Raspisan |Код расписания |IDRasp |Int |
| |Код преподаватель-план |IDPrePL |Numeric |
| |Код дня недели |IDDay |Numeric |
| |Код группы |IDroup |Numeric |
| |Код пары |IDPair |Numeric |
| |Код аудитории |IDAuditorium |Numeric |
Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов.
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Мы определим его далее, а пока коснемся смысла этого понятия. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.