Разработка модели оценки знаний

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

2 ПОСТАНОВКА ЗАДАЧИ

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

      определить метод оценивания знаний, который позволит оценить знания по принципу рейтингового контроля;

      полученная при автоматизированном тестировании оценка должна отвечать уровню знаний респондента и соответствовать традиционной пятибалльной шкале оценивания (или иметь тип «зачтено» - «не зачтено»);

      обеспечить наполнение базы данных тестирования таким образом, чтобы предотвратить угадывания;

  реализовать предложенный метод оценивания знаний в виде диалога между системой и пользователем в удобной и понятной форме.

3 ОБЗОР ВОЗМОЖНЫХ СРЕДСТВ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ

3.1 Концепция баз данных

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

        поддержание логически согласованного набора файлов;

        обеспечение языка манипулирования данными;

        восстановление информации после разного рода сбоев;

        реально параллельная работа нескольких пользователей.

Можно считать, что если прикладная информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных. Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры [3]. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банками данных, а затем базами данных (БД). Приведем типовую схему организации работы с СУБД.

Рисунок 3.1 – Связь программ и данных при использовании СУБД

3.2 Архитектура СУБД

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

        физическом размещении в памяти данных и их описаний;

        механизмах поиска запрашиваемых данных;

        проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

        способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

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

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

              Рисунок 3.2 – Уровни моделей данных

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

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

Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных [4].

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

3.3 Инфологическая модель данных "Сущность-связь"

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

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

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

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

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

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

3.4 Построение инфологической модели предметной области методом ER–диаграммы

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

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. ER-модель можно рассматривать как семантическое расширение РМД, поскольку основные структуры данных (множества сущностей и связей) могут быть представлены отношениями реляционной БД [5].

Диаграмма П. Чена, используемая в модели  «сущность-связь», используется и сейчас, т.к. ее наглядность помогает дальнейшему логическому программированию РБД. Известно, что в логической схеме РБД семантика данных передается посредствам первичных и внешних ключей, функциональных зависимостей. Этих возможностей недостаточно для передачи смысла данных, хранимых в СУБД.

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

– прежде всего следует задать множество семантических концепций (понятий), которые полезны при неформальном моделировании предметной области;

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

–  нужно вывести множество формальных правил целостности для работы с такими формальными объектами;

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

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

При построении семантической модели БД следует учитывать следующие основные правила структурирования в ER-модели:

      свойство всегда связано с одним определенным типом объектов, т.е. одно и то же свойство не может характеризовать несколько типов (если только они не являются подчиненными общему типу);

      одни и те же объекты-сущности могут агрегироваться в любое количество связей;

      сущность может агрегироваться в некоторой связи несколько раз.  В этом случае каждое вхождение сущности в связь характеризуется ее ролью в этой связи;

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

Формально структурная спецификация ER-модели задается следующим образом. Прежде всего, вводится множество E={E1,...,Em} типов сущностей, где Ei={ei1,..., eiMi} - множество сущностей. Введем теперь множество R={R1,..., Rp} типов связей. Пусть (E1,..., En) - совокупность сущностей (не обязательно различных), агрегируемых в n-арную связь Rj, Lj={lj1,...,ljn} - множество ролей каждого типа сущности Ek в типе связи Rj. Тогда Rj={(lj1/e1 ,..., ljn/en) | e1ÎE1 ,..., enÎEn}, где ljk/ek обозначает поименованную ролью ljk  сущность ek. Поскольку сущности в связи сопровождаются своей ролью, порядок их расположения не значим. По аналогии с РМД множества  Е и R считаются конечными,  но не  фиксируются.

Пусть теперь V1 ,..., Vn - множества скалярных значений.  Многозначное агрегатное свойство можно определить как  отображение ji:Ei®(V1´...´VK)q  или jj: Rj®(V1´...´VK)q, где К - число агрегированных простых свойств, показатель декартовой степени q - число повторений агрегата. При К =1 получаем простое свойство. При  q =1 свойство является однозначным.

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