Области применения файлов. Предметная область - экзамены

Государственное учреждение высшего профессионального образования

«БЕЛОРУССКО-РОССИЙСКИЙ УНИВЕРСИТЕТ»

Кафедра «Экономическая информатика»

Пояснительная записка

к курсовой работе по дисциплине

«Технология организации  хранения и обработки данных» на тему:

Области применения файлов. Предметная область «Экзамены»

Выполнила:

Купцова Олеся Васильевна.

группа ЭУПЗС-081

шифр

Руководитель:

Лобанова Татьяна Михайловна

Могилев 2009

Содержание

Введение

Во многих областях человеческой деятельности используются базы данных. В общем  смысле термин «база данных» (БД) можно применить к любой совокупности связанной информации, объединенной вместе по определенному признаку, т.е. к набору структурированных данных (организованных определенным образом). При этом большинство БД использует табличный способ представления, где данные располагаются по строкам (которые называются записями) и столбцам (которые называются полями), все записи должны состоять из одинаковых полей и все данные одного поля должны иметь один тип. В настоящее время существует множество систем управления базами данных (СУБД), основанных на реляционной модели. Одной из наиболее доступных из них является СУБД MS Access, которую мы и будем использовать в этой работе. Итогом работы должна стать база данных для обработки информации об успеваемости студентов. Для выполнения поставленной задачи следует последовательно пройти все этапы разработки базы данных: от анализа предметной области через проектирование модели данных и до реализации системы, включающей создание и связывание таблиц, создание необходимых запросов, отчетов и форм. 

1. Области применения файлов.

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

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

Файлы с текстами программ используются как входные тексты компиляторов, которые в свою очередь формируют  файлы, содержащие объектные модули. С точки зрения файловой системы, объектные файлы также обладают очень простой структурой - последовательность записей или байтов. Система программирования накладывает на эту структуру более сложную и специфичную для этой системы структуру объектного модуля. Логическая структура объектного модуля неизвестна файловой системе, эта структура поддерживается программами системы программирования.

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

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

При файловой организации  данных в ИС файл представляется как линейная последовательность записей, при этом пользователи могут выполнить над ним ряд стандартных операций:

• создать файл (требуемого типа и размера);
• открыть ранее созданный файл;
• прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);
• записать в файл на место текущей записи новую;
• добавить новую запись в конец файла.

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

Поскольку файловые системы являются общим хранилищем файлов, принадлежащих разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. В большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX. В этой ОС каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к которой относится этот пользователь, и его собственный идентификатор в группе. При каждом файле хранится полный идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить его создатель, какие действия с файлом доступны для других пользователей той же группы и что могут делать с файлом пользователи других групп. Администрирование режимом доступа к файлу в основном выполняется его создателем-владельцем. Для множества файлов, отражающих информационную модель одной предметной области, такой децентрализованный принцип управления доступом вызывал дополнительные трудности. И отсутствие централизованных методов управления доступом к информации послужило еще одной причиной разработки СУБД.

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

2. Постановка задачи  на разработку базы данных

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

База данных для обработки информации об успеваемости студентов должна предусматривать ведение данных о студентах, преподавателях и об экзаменах.

Каждый студент характеризуется следующими параметрами:

• Номер зачетной книжки (уникальный);
• ФИО;
• Номер группы.

Каждый студент входит в состав какой-либо группы, которая характеризуется следующими параметрами:

• Номер группы (уникальный);
• Специальность.

Каждый преподаватель характеризуется следующими параметрами:

• ФИО;
• Должность;
• Ученая степень.

Каждый экзамен назначается для конкретной группы и по конкретной дисциплине и характеризуется следующими параметрами:

• Дисциплина;
• Дата;
• ФИО преподавателя;
• Номер группы.

Кроме того, в результате сдачи экзаменов студентам выставляются оценки, которые характеризуются следующими параметрами:

• Собственно оценка (балл);
• Номер зачетной книжки;
• ФИО студента;
• Дисциплина;
• Дата.

Необходимо  предусмотреть следующие ограничения  на информацию, хранимую в БД:

• Каждый клиент должен иметь ФИО, номер зачетки, номер группы, специальность, причем номер зачетки должен быть уникален;
• Каждый экзамен должен быть назначен по конкретной дисциплине и для конкретной группы, должен иметь дату и приниматься конкретным преподавателем;
• Каждая оценка должна быть привязана к конкретному студенту и за конкретный экзамен и не может быть пустой;
• Преподаватель может выставлять оценку студенту только  из группы, которая сдает ему данный экзамен.

2.2 Требования к информационной системе

В соответствии с анализом предметной области из раздела 2.1 можно полагать, что с  разрабатываемой базой данных должны работать следующие категории пользователей:

• Руководство учебного заведения;
• Преподаватели, принимающие экзамены;

Работая с базой данных, представители руководства должны иметь возможность:

• Составлять расписание экзаменов;
• Просмотреть результаты экзаменов;
• Получить информацию о средней оценке студента за сессию;
• Получить информацию о средней оценке по группе;
• Просмотреть список должников (т.е. тех студентов, у которых отсутствуют оценки по экзаменам из расписания).

Работая с базой данных, преподаватели должны иметь возможность решать следующие задачи

• Вводит в базу данных результаты по экзамену, который они принимают;
• Просмотреть результаты экзамена.

3. Проектирование  модели данных

3.1 Семантическая модель  данных

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

Прежде всего, выделим сущность «Студент». Каждый экземпляр этой сущности будет соответствовать конкретному студенту, обучающемуся в данном учебном заведении. Каждому студенту присваивается уникальный номер зачетки, который будет однозначно идентифицировать студента, поэтому он будет ключевым атрибутом сущности «Студент». Дополнительными атрибутами сущности «Студент» будут являться: «ФИО», «Номер группы».

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

Далее выделим сущность «Преподаватель». Каждый экземпляр этой сущности будет соответствовать конкретному преподавателю, принимающему экзамены в данном учебном заведении. Атрибутами сущности «Преподаватель» будут являться: «ФИО», «Должность», «Ученая степень». Поскольку данные атрибуты не могут однозначно идентифицировать преподавателя (возможен вариант, когда два преподавателя-однофамильца имеют одинаковые должности), добавим атрибут «Код преподавателя», который будет являться ключевым атрибутом сущности «Преподаватель».

После этого выделим сущность «Экзамен». Каждый экземпляр этой сущности будет соответствовать конкретному экзамену, проводимому в данном учебном заведении. Атрибутами сущности «Экзамен» будут являться: «Дисциплина», «Дата», «ФИО преподавателя», «Номер группы». Для однозначной идентификации добавим атрибут «Номер экзамена», который будет являться ключевым атрибутом сущности «Экзамен».

И наконец, выделим сущность «Оценка». Каждый экземпляр этой сущности будет соответствовать оценке, полученной конкретным студентом за конкретный экзамен. Атрибутами сущности «Оценка» будут являться: «Балл», «Номер зачетки», «Дисциплина», «Дата», «Преподаватель», «Номер экзамена». Поскольку оценку за каждый конкретный экзамен студент получает только один раз,  экземпляр сущности «Оценка» однозначно идентифицируется по составному атрибуту: «Номер экзамена» + «Номер зачетки».

Определенные наборы атрибутов сущностей сведем в таблицу 1. Ключевые атрибуты выделены жирным шрифтом.

В рассматриваемой нами модели существуют связи между сущностями. Связь представляет взаимодействие между сущностями. На основании этих связей создадим семантическая модель предметной области «Экзамены», представленную на рисунке 1.

Таблица 1 Наборы атрибутов сущностей семантической модели

Между сущностями «Преподаватель» и «Экзамен» существует связь (1:М), обязательная со стороны сущности «Экзамен». Каждый преподаватель принимает, как правило, несколько экзаменов, поэтому используем связь (1:М). При этом подразумеваем, что конкретный экзамен принимает только один преподаватель. Со стороны сущности «Экзамен» связь обязательная, так как экзамен не может проводиться без преподавателя. Предполагаем также, что в базе могут быть введены преподаватели, которые экзаменов не принимают, поэтому со стороны сущности «Преподаватель» связь необязательная.

Между сущностями «Студент» и «Оценка» существует связь (1:М), обязательная со стороны сущности «Оценка». Каждый студент получает много оценок, поэтому используем связь (1:М). Со стороны сущности «Оценка» связь обязательная, так как не может быть выставлена оценка, не принадлежащая конкретному студента. Со стороны сущности «Студент» связь необязательная, т.к. студент может не иметь оценок (первокурсник).

Между сущностями «Группа» и «Студент» существует связь (1:М), обязательная со стороны сущности «Студент». Каждая группа состоит из многих студентов, поэтому используем связь (1:М). Со стороны сущности «Студент» связь обязательная, так как не может быть студента, не включенного в конкретную группу. Со стороны сущности «Группа» связь будем считать необязательной (не удалось набрать нужное количество абитуриентов).

Между сущностями «Группа» и «Экзамен» существует связь (1:М), обязательная со стороны сущности «Экзамен». Каждая группа должна сдавать много экзаменов, поэтому используем связь (1:М). Со стороны сущности «Экзамен» связь обязательная, так как не может быть экзамен, не назначенного конкретной группе. Со стороны сущности «Группа» связь будем считать необязательной (экзамены для группы не назначены).

Рисунок 1 Семантическая  модель предметной области «Экзамены»

Между сущностями «Экзамен» и «Оценка» существует связь (1:М), обязательная со стороны сущности «Оценка». На каждом экзамене выставляется много оценок, поэтому используем связь (1:М). Со стороны сущности «Оценка» связь обязательная, так как не может быть выставлена оценка, не полученная на конкретном экзамене. Со стороны сущности «Экзамен» связь необязательная, т.к. дата экзамена может еще не наступить, соответственно оценки по нему отсутствуют. Все рассмотренные связи отражены на рисунке 1.

3.2 Логическая модель  данных

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

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

Правило 2. Если связь  типа (1:1) и степень участия одной  сущности является обязательной, а другой – необязательной, то нужно создать две таблицы – по одной для каждой сущности. Первичные ключи таблиц соответствуют первичным ключам сущностей. Поскольку связи типа (1:1) в нашей модели отсутствуют, она соответствует данному правилу.

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

Правило 4. Если связь  типа (1:М) и степень участия сущности на стороне М является обязательной, то необходимо создать две таблицы – по одной для каждой сущности. Первичные ключи таблиц соответствуют первичным ключам сущностей. Для установления связи между ними необходимо добавить в подчиненную таблицу копию ключевого атрибута из главной таблицы, который станет внешним ключом подчиненной таблицы. Данное правило для построенной нами модели данных выполняется для следующих связей (1:М):

• «Студент – Оценка», поскольку сущность «Оценка» содержит копию ключевого атрибута «Номер зачетки» сущности «Студент»;
• «Группа – Студент», поскольку сущность «Студент» содержит копию ключевого атрибута «Номер группы» сущности «Группа»;
• «Группа – Экзамен», поскольку сущность «Экзамен» содержит копию ключевого атрибута «Номер группы» сущности «Группа»;
• «Экзамен – Оценка», поскольку сущность «Оценка» содержит копию ключевого атрибута «Номер экзамена» сущности «Экзамен».

Однако правило 4 не выполняется для связи «Преподаватель – Экзамен», поскольку сущность «Экзамен» не содержит копию ключевого атрибута «Код преподавателя» сущности «Преподаватель». Чтобы устранить это, следует заменить атрибут «ФИО преподавателя» сущность «Экзамен» на атрибут «Код преподавателя».

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

 Правило 6. Если связь типа (M:N), то необходимо создать три таблицы – по одной для каждой сущности и одну для связи. Первичные ключи исходных таблиц соответствуют первичным ключам сущностей. Они передаются как внешние ключи в таблицу связи. Поскольку связи подобного типа в нашей модели отсутствуют, она соответствует данному правилу.

При создании модели БД необходимо предусмотреть минимизацию избыточности данных. В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах. Вследствие этого память компьютера используется неэкономно и времени на корректировку данных тратится больше. Для разработанной нами модели избыточная информация может содержаться в поле «Дисциплина» таблицы «Экзамены». Чтобы устранить этот недостаток, следует создать отдельную таблицу «Дисциплины» с полями «Код дисциплины» (первичный ключ) и «Наименование дисциплины», а в таблице «Экзамены» заменить поле «Дисциплина» на поле «Код дисциплины» (внешний ключ) с созданием соответствующей связи.

Проверим полученные отношения на соответствие нормальным формам (до третьей нормальной формы включительно):

Определение 1НФ: Таблица находится в 1НФ, если все ее поля содержат только неделимые значения. Для созданной нами модели это выполняется.

Определение 2НФ: Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. На соответствие второй нормальной форме проверяются только отношения, имеющие составной первичный ключ. Для нашей модели данных составной ключ имеет сущность «Оценка». Ее атрибуты «Дисциплина» и «Дата» зависят только от номера экзамена и не зависят от номера зачетки. Данные атрибуты следует удалить из таблицы, соответствующей сущности «Оценка», после чего она будет соответствовать 2НФ.

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

Достижение третьей нормальной формы обычно является достаточным для окончания процесса нормализации отношений. После приведения созданной модели в соответствие рассмотренным правилам мы получили логическую модель данных, которая приведена в Приложении А (в виде схемы данных из СУБД Microsoft Access).

3.3 Определение физических  характеристик атрибутов

Определяем параметры каждого атрибута построенной нами логической модели базы данных:

• Тип;
• Размер;
• Обязательность либо необязательность их заполнения. 

Параметры атрибутов для всех таблиц базы данных представлены в таблице 2.

Таблица 2 Атрибуты таблиц базы данных

4. Реализация системы

4.1 Создание, связывание  и заполнение таблиц

Реализацию системы в СУБД MS Access выполняем на основании разработанной в разделе 3 модели данных, с учетом приведенных в таблице 2 параметров атрибутов. В среде MS Access создаем новую базу данных с именем «Экзамены» и далее создаем таблицы в режиме конструктора в следующей последовательности:

• Таблица «Дисциплины» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Код дисциплины» выбираем как ключевое;

Рисунок 2  Таблицы Дисциплины, Преподаватели, Группы ( режим Конструктор)

• Таблица «Преподаватели» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Код преподавателя» выбираем как ключевое;
• Таблица «Группы» (см.рис.2): типы полей и их параметры берем из раздела 3.3. Поле «Номер группы» выбираем как ключевое;
• Таблица «Студенты» (см.рис.3): типы полей и их параметры берем из раздела 3.3. Поле «Номер зачетки» выбираем как ключевое. Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы»;

Рисунок 3 Таблицы Студенты, Оценки, Экзамены ( режим Конструктор)

• Таблица «Оценки» (см.рис.4): типы полей и их параметры берем из раздела 3.3. Поля «Номер экзамена» и «Номер зачетки» выделяем и указываем как ключевые. Для поля «Балл» используем «Мастер подстановок», в котором вводим фиксированный набор значений: от 0 до 10. Для поля «Номер экзамена» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Экзамены». Для поля «Номер зачетки» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Студенты»;
• Таблица «Экзамены» (см.рис.3): типы полей и их параметры берем из раздела 3.3. Поле «Номер экзамена» выбираем как ключевое. Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы». Для поля «Номер группы» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Группы». Для поля «Код преподавателя» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Преподаватели». Для поля «Код дисциплины» выбираем тип элемента управления – поле со списком, и в качестве источника строк – таблицу «Дисциплины».

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