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

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

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

 

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

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

 

 

 

 

 

 

 

Выполнила:

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

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

шифр

 

 

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

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

 

 

 

 

 

 

 

 

Могилев 2009

 

Содержание

 

 

Введение

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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