Создание информационной системы

Практическая работа 1

«Приемная комиссия в ВУЗ»

Анализ предметной области

Разработка базы данных состоит их двух этапов: проектирования БД и создания БД. Проектирование включает в себя:

· Системный анализ предметной области

· Анализ данных и построение модели данных

Создание БД в памяти ЭВМ происходит в среде опреде­ленной СУБД и состоит из:

· создания структуры базы данных;

· заполнения базы данными.

Дальнейшее изучение информационных систем и баз дан­ных будем проводить на примере разработки информацион­ной системы для приемной комиссии вуза. Пусть это будет классический университет. Назовем создаваемую информа­ционную систему «ИС Приемная комиссия».

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

Во-первых, опишем исследуемую систему, которую назо­вем «Приемная кампания в университете». В этой системе выделим следующие элементы: «Абитуриенты», «Прием­ная комиссия». Абитуриенты — это выпускники школ и других средних учебных заведений, решившие поступать в данный университет. Приемная комиссия — это админист­ративное подразделение университета, занимающееся орга­низацией приема в вуз. Весь процесс взаимодействия в ходе приемной кампании между абитуриентами и прием­ной комиссией будем рассматривать как сложное информа­ционное взаимодействие, включающее передачу абитуриен­тами анкетных данных приемной комиссии, информирова­ние абитуриентов об условиях приема, прием экзаменов и выставление оценок и пр. (подробнее об этом будет сказано позже). В самом общем виде схема такой системы выглядит следующим образом:

Здесь стрелки обозначают двунаправленный информаци­онный обмен.

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

Члены приемной комиссии — это персонал, включаю­щий в себя административных работников (председателя, секретарей и др.) и экзаменаторов. Для упрощения задачи мы не будем далее углубляться в структуру приемной ко­миссии.

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

Приемная кампания в вузе — это процесс, происходящий во времени. Разделим его на последовательные этапы. Та­ких этапов четыре:

1. Подготовительный этап.

2. Этап приема документов у абитуриентов.

3. Этап приема экзаменов.

4. Этап зачисления в университет.

Отметим для каждого из этих четырех этапов происходя­щие информационные процессы:

Анализ данных

Ядром будущей информационной системы является база данных. Мы будем использовать табличную модель данных и, следовательно, строить реляционную БД.

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

1. Подготовительный этап. На этом этапе от нашей ИС в первую очередь потребуются сведения о плане приема в уни­верситет: на каких факультетах какие специальности от­крыты для поступления; сколько человек принимается на каждую специальность. Кроме того, абитуриентов (и их ро­дителей) интересует, какие вступительные экзамены сдают­ся на каждом факультете. Рис. 2. Иерархическая структура университета

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

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

Введение кодов факультета и специальности создает определенные удобства. Название может быть достаточно длинным (например «Радиофизика и электроника»), а код — короткий. Длинные названия факультетов и спе­циальностей записаны только в таблицах «Факультеты» и «Специальности». Во всех других таблицах их можно заме­нить кодами, которые всегда можно расшифровать.

2. Этап приема документов у абитуриентов. В это время абитуриенты пишут заявления о допуске к поступлению, сдают необходимые документы (копию паспорта, школьного аттестата и другие), заполняют анкету. Каждому абитуриен­ту присваивается его личный идентификатор — регистраци­онный номер. Далее под этим номером он будет фигуриро­вать во всех документах. Многочисленную информацию об абитуриенте сведем в две таблицы. Первая будет содержать анкетные данные (включим лишь их часть). Вторая — дан­ные, которые потребуются в ходе экзаменов и могут потре­боваться при зачислении:

В таблице «Абитуриенты» поле «Медаль» имеет логичес­кий тип. Значение «ИСТИНА» этого поля будет отмечать абитуриентов, получивших золотую или серебряную медаль по окончании школы. Медалисты имеют льготы при поступ­лении: если медалист сдаст профилирующий предмет (а эк­замен по нему обычно бывает первым) на 5, то остальные эк­замены ему не надо сдавать (за них он автоматически получает пятерки).

3. Этап приема экзаменов. Основная информация, пред­ставляющая интерес на этом этапе, — результаты сдачи экза­менов абитуриентами. Безусловно, в реальной системе фигу­рируют данные о делении абитуриентов на экзаменационные группы, о датах и месте проведения экзаменов, об экзамена­торах и пр. Но мы ограничимся лишь одной таблицей, содер­жащей оценки, полученные каждым абитуриентом:

4. Этап зачисления в университет. Здесь нас будет интере­совать окончательный список с информацией о том, кто из абитуриентов принят в университет, а кто — нет:

Построение модели данных

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

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

Факультеты (КОД_ФАК, ФАКУЛЬТЕТ, ЭКЗАМЕН_1, ЭКЗАМЕН 2, ЭКЗАМЕН З)

Специальности (КОД_СПЕЦ, СПЕЦИАЛЬНОСТЬ, КОД_ФАК, ПЛАН)

Абитуриенты (РЕГ_НОМ, КОД_СПЕЦ, МЕДАЛЬ, СТАЖ)

Анкеты (РЕГ_НОМ, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДATА_РОЖД, ГОРОД, УЧЗАВЕДЕНИЕ)

Оценки (РЕГ _НОМ, ОЦЕНКА_1, ОЦЕНКА_2, ОЦЕН- КА_3)

Итоги (РЕГ_ НОМ, ЗАЧИСЛЕНИЕ)

Чтобы эти шесть таблиц представляли собой систему, между ними должны быть установлены связи.

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

Для явного указания связей между таблицами должна быть построена схема базы данных. В схеме указывается на­личие связей между таблицами и тип связей. Схема для на­шей системы представлена на рис. 3.

Рис. 3. Схема базы данных

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

Связь «один ко многим» — это связь между двумя сосед­ними уровнями иерархической структуры. А таблицы, свя­занные отношениями «один к одному», находятся на одном уровне иерархии. В принципе, все эти четыре таблицы мо­гут быть объединены в одну таблицу, поскольку главный ключ у них один — «РЕГ_НОМ». Однако с такой таблицей работать будет неудобно — слишком много полей. Каждая из четырех таблиц в отдельности лучше обозревается, кроме того, каждая из них имеет самостоятельный смысл.

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

Система не допустит, чтобы одноименные поля в разных связанных между собой таблицах имели разные значения. Ввод данных автоматически контролируется. В связанных таблицах может быть установлен режим каскадной замены: если в одной из таблиц изменяется значение поля, по которо­му установлена связь, то в других таблицах автоматически изменятся значения одноименных полей. Аналогично дейст­вует режим каскадного удаления: достаточно удалить запись из одной таблицы, чтобы связанные записи исчезли из всех остальных таблиц. Это естественно, поскольку, например, если закрывается какой-то факультет, то исчезают и все его специальности. Или если у абитуриента сменили регистраци­онный номер в таблице «Абитуриенты», то автоматически его номер должен обновиться и в других таблицах.

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

Связь между таблицами осуществляется через одноименные поля. Связь «один к одному» - через общий главный ключ; связь «один ко многим» - через главный ключ в одной таблице и одноименное поле в другой таблице – такое поле называют внешним ключом.

На этом проектирование базы данных завершено. Это был теоретический этап. Дальнейшая работа будет происходить в среде СУБД MS Access.

Создание базы данных в среде MS Access

Создание базы данных начинается с открытия файла, в котором она будет храниться. Для этого в MS Access нуж­но произвести следующие действия:

выполнить команду => Файл => Создать БД => Новая БД; => в файловом окне указать путь и имя файла «При­емная комиссия».

После этого на экране откроется основное окно с заголов­ком «Приемная комиссия: база данных». Дальнейшая рабо­та состоит из двух этапов:

· построение структур таблиц;

· ввод данных в таблицы.

Сначала надо описать структуры таблиц. Следует начать с таблиц, которые создаются на первом, подготовительном этапе работы приемной комиссии. Главной здесь является таблица «Факультеты».

Описать структуру таблицы — значит указать имена всех полей, а также тип и свойства каждого поля; назначить главный ключ. В режиме Таблица надо выполнить команду => Создать. Из списка предлагаемых способов создания таб­лицы следует выбрать => Конструктор. На экране откроется окно конструктора таблиц. На рис. 4 показано заполнен­ное окно конструктора для таблицы «Факультеты».

Имена полей указываются в графе «Имя поля», соответ­ствующие им типы — в графе «Типы данных». Графу «Опи­сание» заполнять не обязательно. В нижней половине окна конструктора присутствует таблица «Свойства поля». В ней указываются размер поля, формат поля и некоторые другие свойства. Смысл каждого параметра поясняется комменти­рующим текстом. Кроме того, всегда можно обратиться к справочнику, нажав на клавишу F1. На рис. 1.8 отражены свойства поля «Факультет». Основным свойством текстового поля является его длина. Предельное значение длины — 255 символов. В данном случае выбрана длина 30. С одной стороны, длину текстового поля нужно задавать такой, чтобы в него поместилось любое возможное значение этого поля, с другой стороны, нужно помнить, что лишняя длина – это расход памяти компьютера, которая конечна.

Для поля КОД_ФАК указан текстовый тип и длина, равная 2. Значениями этого поля будут числа, поэтому для него можно было бы выбрать и числовой тип в целом формате. Однако числовой тип обычно присваивают тем полям, со значениями которых возможны в дальнейшем какие-то вычислительные действия, полям, обозначающим размерные величины. Над кодом специальности не имеет смысла выполнять вычисления, поэтому его можно определить как двухсимвольное поле (цифры – тоже символы). Все остальные поля имеют текстовый тип и длину 30 символов.

Выбор главного ключа производится следующим образом: указатель устанавливается на ключевое поле «КОД_ФАК» и выполняется команда: | Правка, Ключевое поле. То же самое происходит, если щелкнуть по кнопке с изображением ключа на панели инструментов.

В дальнейшем информацию о структуре каждой таблицы будем представлять в табличной форме. На примере таблицы «Факультеты» она выглядит так:

После выполненных действий на вкладке «Таблицы» окна базы данных появятся названия созданных таблиц: «Факультеты» и «Специальности».

Теперь организуется ввод данных в эти таблицы. Вводить данные можно непосредственно в бланк таблицы или в ре­жиме формы. Использовать форму для ввода данных и про­смотра таблицы удобно в тех случаях, когда в таблице очень много полей и запись в развернутом виде не помещается на экране. Две первые таблицы небольшие, поэтому можно обойтись без формы. Чтобы начать ввод данных в таблицу «Факультеты», нужно выделить название таблицы на экра­не и выполнить команду => Открыть. На экране появится бланк таблицы, содержащий заголовки столбцов и пустую строку. Далее следует заполнять таблицу. После заполнения она примет вид, представленный в табл. 5

Таблица 5. Факультеты

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

выполнить команду => Сервис => Схема данных; => откроется окно «Добавление таблицы»; выделить название таблицы «Факультеты»; выполнить команду => Добавить; => выделить название таблицы «Специальности»; выполнить команду => Добавить => Закрыть.

В результате на поле окна «Схема данных» появятся об­разы двух таблиц. Нажав левую клавишу мыши, следует пе­ретащить имя ключевого поля «КОД_ФАК» из образа таб­лицы «Факультеты» на это же имя в образе таблицы «Специальности»:

Откроется окно «Связи». Надо последовательно активи­зировать флажки «Обеспечить целостность данных», «Ка­скадное обновление связанных полей» и «Каскадное удале­ние связанных записей». Тип связи «один ко многим» будет выбран автоматически. Далее следует выполнить команду => Создать. Схема готова!

Осталось ее сохранить и закрыть окно.

Теперь, чтобы вывести на экран любую из созданных таб­лиц, нужно щелкнуть мышью по ее имени на закладке «Таблицы» и выполнить команду => Открыть. Открытую таблицу можно просматривать, редактировать, можно до­бавлять в нее новые записи. Если вам потребуется изменить структуру таблицы, то нужно перейти в режим конструкто­ра и внести изменения.