Проектирование системы тестирования знаний учащихся

2.1 Концептуальная и физическая модели баз данных

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

тестирование assistant база данные

Рис. 2.1 - Общий подход к созданию информационных систем на базе Case - технологий

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

Суть функционального разбиение хорошо отражена в известной формуле:

«Программа = данные + Алгоритмы».

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

Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: «разработка, основанная на компонентах» (Component Based Development - CBD). При этом используется другой принцип декомпозиции - система разбивается на «активную суть» - объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении «клиент/сервер». Сообщения, которые может принимать объект, определенные в его интерфейсе. В этом смысле посылка сообщения "объекта-сервера" эквивалентна вызова соответствующего метода объекта. Большинство существующих CASE-средств опираются в основном на структурные методологии.

Примером системы, в которой осуществляется функциональное разбиение является BPwin (система моделирования потоков данных), что поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес - процессов на предприятии и идеального состояния вещей - того, к чему нужно стремиться. Методология IDEF0 приказывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции).

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

На основе модели процессов BPwin с помощью другого CASE-средства ERwin можно построить модель данных. Принято выделять два уровня представления модели данных - логический и физический.

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

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Группа», «Фамилия студента». Объекты модели, представляемых на логическом уровне, называются сути и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Такая модель данных является универсальной и никак не связана с конкретной реализацией СУБД (системы управления базой данных). Построение логической модели ИС к ее программной разработки или до начала проведения архитектурной реконструкции так же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков.

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

Концептуальная модель БД Концептуальная модель (инфологична) наиболее полно отвечает потребностям проектирование баз знаний и построена на ряде принципов, которые мы сейчас рассмотрим. Есть две большие области понятий в концептуальной модели. Обе они построены по принципу иерархического дерева. Первая область - это дерево типов данных, вторая - дерево данных. Дерево типов описывает структуру данных дерева данных, поэтому без дерева типов нет никакой логической целостности дерева данных. Для начала, рассмотрим простой пример с телевизионной камерой. Отраженный свет попадает в объектив камеры, там он раскладывается на три составляющие: синий, красный, зеленый. Записывая уровень освещенности три составляющих света 25 раз в секунду, мы можем составить представление о освещенность и способность предметов, которые мы снимаем, что отражает. Теперь дадим основные определения.

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

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

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

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

Объект - совокупность типов и свойств, объединенных в один тип, способный описать объект реального мира. В нашем примере один тип достаточный для описания объекта, что снимается на камеру, но бывают случаи, когда одного типа недостаточно, или уровень упрощения слишком высок, чтобы можно было составить простую модель. Например, объект машина состоит из типов: кузов, рама, мотор, колеса и др. Эти типы, в свою очередь, тоже являются объектами, которые состоят из типов, например для колеса: обед, покрышка, камера и так далее Для камеры: оболочка, ниппель, давление воздуха и так далее Можно бесконечно углубляться в детали, но, как правило, это не нужно. Рассмотрим различные точки зрения пользователей на наши типы, в зависимости от состояния технологического процесса производства и продажи машины. Человек, который собирает колесо, рассматривает его как объект, состоящий из типов: оболочка, ниппель, давление воздуха. Он собрал колесо и передал его на главный конвейер. Далее колесо рассматривается как тип, что входит в состав объекта рама. На последней стадии сборки, нам уже не важно иметь в поле зрения свойства колесо, практически, мы потеряли его из видимости. Далее, мы рассматриваем тип рама, что входит как свойство в объект машина. Человек, который пришел покупать машину, может рассматривать его как объект том, как тип, что входит как свойство в объект материальное положение и так далее 3 этих рассуждений видно, что концептуальная модель очень гибкая и самодостаточная для описания внешнего мира. Мы можем двигаться от простого к сложному, описывая все, что входит в технологический процесс.

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

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

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

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

Сначала начали использовать иерархические даталогические модели.

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

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

Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типы под деревьев (каждый из которых является некоторым типом дерева). Тип дерева в целом является иерархически организованным набором типов записи.

Пример типа дерева приведен на рис. 2.2

Рис. 2.2 - Иерархическая модель данных

Здесь Отдел является предком для Начальника и Сотрудники, а Начальник и Сотрудники - потомки отдела. Между типами записи поддерживаются связи. Никакой потомок не может существовать без своего отца, причем предок должен быть один.

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

Сетевые модели также создавались для мало ресурсных ЭВМ.

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

Сетевая БД (6) состоит из набора записей и набора связей между этими записями, а если говорить точнее, из наборов экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи: предка и потомка.

Рис. 2.3 - Сетевая модель данных

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

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

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

* каждая ячейка в таблице представляет точно один элемент данных; нет групп, которые повторяются;

* каждая таблица имеет однородные столбце; все элементы в любом из столбцов одного и того же вида;

* каждому столбцу предназначено определенное имя;

* все строки различные дублировать; строки не разрешается;

* и строки и столбцы, не зависят от последовательности; просмотр в разной последовательности не может изменить информационное содержание отношение;

* каждая строка воплощает уникальный элемент данных, который ней и описывается;

* столбцами есть отдельные куски информации (атрибуты данных), которые известны на данный элемент.

Строки обычно называют записями, а столбцы - полями.

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

Рис. 2.4 - Реляционная модель данных

К достоинствам реляционного подхода можно отнести:

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

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

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

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

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

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

Как другие недостатки реляционных СУБД отмечаются следующие:

* негибкость структуры для развивающихся БД

* затруднения в построении концептуальной модели для объектов с многочисленными связями «многие - к - многим»

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

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

1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-нибудь класса. Класс определяется как совокупность свойств, методов, общедоступных и частных структур данных, а также программы, применимых к объектов (экземплярам) данного класса. Классы есть ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызываются для того, чтобы провести какие-либо действия с объектом (например, напечатать или скопировать себя). Свойства - это значение данных, которые связаны с каждым объектом класса, характеризуют его тем или иным образом (например, цвет, возраст).

2. Инкапсуляция: Внутреннее представление данных и деталей реализации общедоступных и частных методов (программ) является частью определения класса и известно только внутри этого класса. Доступ к объектам класса разрешен только через свойства и методы этого класса или его родителей (см. ниже "наследование"), а не путем использования знания подробностей внутренней реализации.

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

4. Полиморфизм: Несколько классов могут иметь совпадающие имена методов и свойств, даже если они считаются различными. Это позволяет писать методы доступа, которые правильно работать с объектами совершенно разных классов, чтобы соответствующие методы и свойства были в этих классах определены.

5. Сообщение: Взаимодействие с объектами осуществляется путем посылки сообщений с возможностью получения ответов.

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

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

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

2.2 Язык программирования PHP