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

Оглавление

Введение

 

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

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

Система тестирования знаний – программная система, призванная обеспечить проверку знаний учащихся. Во многих случаях разделяют использование таких систем для собственно контроля знаний и для самоконтроля (пробного тестирования).

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

Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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

Анализ эффективности  автоматизированного тестирования в высших и других учебных заведениях показывает, что многие преподаватели  настороженно и даже негативно относятся  к подобным системам. Подобное отношение обусловлено недоверием к результатам теста.

Необходимо четко понимать, что использование программ компьютерного  тестирования делает сам процесс  тестирования знаний студентов намного  проще и эффективней.

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

1. Всегда справедливость полученной оценки, расчет которой может производиться различными методами, исходя из назначения тестовой программы.
2. Эффективность и простота сбора данных тестирования. Так как все данные с тестовой программы хранятся на сервере, можно сделать вывод о том, что сбор данных о тестировании сводится лишь к загрузке данных с сервера.
3. Защита данных от несанкционированного доступа. Это также достигается за счет хранения данных каждого пользователя на сервере, а также методами криптографического и иного шифрования.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Концептуальная модель

 

Концептуальная модель — модель предметной области, состоящей  из перечня взаимосвязанных понятий, используемых для описания этой области, вместе со свойствами и характеристиками, классификацией этих понятий, по типам, ситуациям, признакам в данной области и законов протекания процессов в ней.

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

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

Далее, необходимо выделить основную рабочую информацию. В ПФ МГОУ информация по различным дисциплинам, включаемым в курс изучения конкретной специальности.

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

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

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

 

 

 

 

 

 

 

Рис. 1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. Инфологическая модель

 

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

Сущность – любой  различимый объект (объект, который  мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная  характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:

 

Красный, Синий, Банановый, Белая ночь и т.д.,

Однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

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

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

 

 

 

 

Таблица 1 – Инфологическая модель

Сущность	Атрибуты
Пользователи	Индивидуальный номер (ключ), логин, пароль (необходимы для  авторизации), ФИО, привилегии
Вопросы	Номер вопроса (ключ), собственно сам текст вопроса, четыре варианта ответов на данный вопрос, а также указание правильного ответа для сравнения в ходе выполнения программы
Голосование	Номер записи (ключ), сам  текст, его хранение
Результаты голосования	Номер записи (ключ), текст оставленного сообщения, время оставленного сообщения.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Реляционная модель

 

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

Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности  — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное  исчисление).

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

Реляционная модель данных является приложением к задачам  обработки данных таких разделов математики как теория множеств и  формальная логика.

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

Для лучшего понимания  РМД следует отметить три важных обстоятельства:

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

Основной структурой хранения является отношение – таблица  со следующими свойствами:

1. Каждый столбец содержит информацию одного типа.
2. Ячейки – поля – таблицы не содержат агрегатов (структур или массивов) данных.
3. Таблицы не содержат одинаковых строк.
4. Порядок строк и столбцов не имеет значения. Все операции используют содержательную сторону данных, а не их расположение внутри таблицы.

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