Инфологическая модель базы данных "Тестирование" (стр. 2 из 3)

Переход от индивидуального организации теста к коллегиальной экспертной подготовке всех его этапов, что увеличит доверие конечных пользователей к АСКЗ и повысит валидность результатов тестирования.

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

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

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

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

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

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

2. Инфологическое проектирование

2.1. Модель «сущность-связь»

Инфологическая модель применяется после словесного описания предметной области. На основании анализа предметной области выделим следующие сущности модели «сущность-связь» («EntityRelationship» - ER-модели).

Вопросы

Код вопроса

Раздел

Глава

Параграф

Текст вопроса

Код ответа

Пользователь

Код пользователь

Тип пользователя

Права пользователя

Пароль

Ответы

Код ответа

Код вопроса

Балл

Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.

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

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

Рассмотрим сущности проектируемой предметной области.

2.2. Связи между сущностями

Связи делятся на три типа по множественности: один-ко-одному (1: 1), один-ко-многим (1: М), многие-ко-многим (М: М).

Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

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

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

Определим связи между выявленными сущностями.

1 М М 1

В разных нотациях мощность связи изображается по-разному. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWERDESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что, по крайней мере, один экземпляр сущности участвует в этой связи.

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов – сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип, называемый условно «Прочие», который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не конкретного экземпляра.

Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности – сильной по отношению к ней.

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

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

Заключение

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

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