Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
отчет по ПДП_ver3.docx
Скачиваний:
6
Добавлен:
19.08.2019
Размер:
498.69 Кб
Скачать

2.1 Описание требований к системе и её основных функциональных модулей

Чтобы определиться какие основные проблемы будет решать будущая система мониторинга учебного процесса, были рассмотрены задачи, решаемые аналогичными системами, и переопределены для разработки. Таким образом, система мониторинга учебного процесса решит следующие задачи, упростив работу и учебу. Система позволит:

  • Автоматизировано вести личные дела студентов и сотрудников,

  • Организовать движение контингента студентов,

  • Вести журналы посещаемости и успеваемости студентов кафедры,

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

  • Даст возможность оперативно обмениваться учебной информацией между студентами и преподавателями,

  • Будет учтена гибкая система прав доступа, на основании различных автоматизированных рабочих мест (АРМ),

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

Было принято решение, что кафедральная система мониторинга учебного процесса должна включать в себя следующие подсистемы:

  • Модуль «Вход» (Авторизация, регистрация пользователей);

  • Модуль «Контингент» (Списки студентов, списки преподавателей);

  • Модуль «Статистика» (Сведения о посещаемости и успеваемости, список задолжников);

  • Модуль «Учебные планы» (Сведения о дисциплинах, расписание);

  • Модуль «Оперативная информация» (Приказы, указания, объявления, материалы преподавателя).

  • Модуль «Личные сообщения» (Личные сообщения пользователей, доска объявлений).

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

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

2.2 АНАЛИЗ СУЩЕСТВУЮЩИХ МОДЕЛЕЙ ДАННЫХ

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

Центральным объектом любой информационной системы является база данных (БД), то есть, совсем простым языком, хранилище, в которым хранятся данные подлежащие обработке.

БД – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области или разделе предметной области” [8].

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

Принято считать, что существуют три основных модели данных: иерархическая, сетевая и реляционная.

Иерархическая структура – это совокупность элементов, отношения между которыми подчинены правилу «родитель-потомок», то есть каждый элемент структуры подчинен определенному элементу более высшего уровня, но в свою очередь и сам является главенствующим элементом для более нижнего. Таким образом, данная связь элементов образует древовидную структуру [8]. Можно отметить, что самый верхний элемент принято называть корневым, а конечные элементы – листьями.

Достоинства:

  • эффективное использование памяти ЭВМ;

  • неплохие показатели времени выполнения основных операций над данными.

Недостатки:

  • громоздкость для обработки информации с достаточно сложными логическими связями;

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

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

Достоинства:

  • возможность эффективной реализации по показателям затрат памяти и оперативности;

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

Недостатки:

  • высокая сложность и жесткость схемы БД;

  • сложность для понимания и выполнения обработки информации в БД обычным пользователем;

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

И наконец, самая удобная форма представления данных в виде двумерных таблиц – реляционная структура. Где каждая таблица состоит из фиксированного числа столбцов и переменного числа строк. Причем, столбцы принято называть полями (реквизит объекта данных), а строки – записями [8].

Еще описывать реляционную структуру БД со стороны математической логики, то получим следующие утверждения. Строки таблиц можно представить в виде кортежа единиц данных, называемых атрибутами. Тем самым совокупность кортежей образует таблицу, которая и задает математическое отношение. Модель данных представлена множеством R-таблиц (поэтому, собственно, структура и получила название реляционной). Можно отметить, что в табличном представлении существует столбец или группа столбцов, от которых зависят значения в произвольно взятом кортеже. Считается, что реляционная БД состоит только из R-таблиц, и не может включать данные, представленные каким-либо иным способом (переменные, массивы и т.д.) [9].

Достоинства:

  • простота, понятность и удобство физической реализации на ЭВМ;

  • эффективность обработки данных.

Недостатки:

  • отсутствие стандартных средств идентификации отдельных записей;

  • сложность описания иерархических и сетевых связей. 

Эти три модели считаются классическими, но существуют также и, так сказать, вторичные модели БД, такие как:

  • постреляционная; 

  • многомерная;

  • объектно-ориентированная.  

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

Достоинства:

  • возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей;

  • повышение эффективности обработки данных, в связи с наглядностью представления.

Недостатки:

  • сложность решения проблемы;

  • сложность обеспечения целостности и непротиворечивости хранимых данных [10].

Многомерная модель данных появилась практически одновременно с реляционной. В 1993 году Э.Кодд в своей статье описал 12 основных требований к системе OLAP (OnLine Analytical Processing – оперативная аналитическая обработка), основную роль в которых играет правильное представление многомерных БД. Когда речь идет о системах оперативной обработки информации, то наиболее эффективной здесь бесспорно выступает реляционная модель БД. Однако, в системах аналитической обработки они оказываются недостаточно гибкими, и на помощь приходят многомерные БД.

Достоинства:

  • удобство и эффективность аналитической обработки больших объемов данных, связанных со временем.

Недостатки:

  • громоздкость для простейших задач обычной оперативной обработки информации [10].

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

Достоинства:

  • возможность отображения информации о сложных взаимосвязях объектов;

  • позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.

Недостатки:

  • высокая понятийная сложность;

  • неудобство обработки данных и низкая скорость выполнения запросов [10].

ВЫВОДЫ

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

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

2.3 ОПИСАНИЕ МНОГОМЕРНОЙ МОДЕЛИ ДАННЫХ И АЛГОРИТМЫ ОБРАБОТКИ

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

Рисунок 2.1 – Пример многомерной модели данных

Данный способ представления данных использует технология OLAP. OLAP (англ. OnLine Analytical Processing, аналитическая обработка в реальном времени) — технология обработки информации, использующаяся для составления и динамической публикации отчётов и документов. Эффективно применяется для быстрой обработки сложных запросов к базе данных.

Помимо базовой технологии существуют еще три типа OLAP — OLAP со многими измерениями (Multidimensional OLAP — MOLAP), реляционный OLAP (Relational OLAP — ROLAP) и гибридный OLAP (Hybrid OLAP — HOLAP).

Основной причиной использования данной технологии является скорость. Данные в реляционных БД хранятся, как известно, в таблицах и запросы в них выполняются с достаточной скоростью, если обращение происходит к одной-двум таблицам. В случае, когда запрос направлен на определенное множество таблиц, более подходящим вариантом становится использование пространственной модели и многомерных запросов. []http://wiki.auditory.ru/БД:Лекция_№11

Также причиной использования именно этой модели БД были такие ее характерные особенности, как агрегируемость, историчность, прогнозируемость. Агрегируемость – это характеристика, которая позволит представить информацию в обобщенном виде различной степени. Историчность позволит держать данные в статическом состоянии, а также привязать их ко времени. Прогнозируемость позволит узнать с помощью алгоритмов обработки прогноз состояния интересующих показателей в будущем[]http://www.neudov.net/4students/otvety-po-pive/modeli-predstavleniya-dannyx-mnogomernaya-model/ . Интересной возможностью для подобной системы является также иерархия в измерениях. С помощью иерархии, например, можно конкретизировать или обобщить период обучения (семестр, модуль, неделя и т.д.).

Существуют целые системы, которые работают с многомерными массивами данных, например SQL Server Business Intelligence Development Studio от Microsoft. Такие системы должны поддерживать специальный язык, такой как, MDX (Multidimensional Expressions) — язык запросов для простого и эффективного доступа к многомерным структурам данных.

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

Надо отметить, что модель данных гиперкуб является виртуальной, то есть данные не хранятся в гиперкубе, хранятся они в тех же таблицах, но, несмотря на это, таблицы должны подчиняться определенным правилам построения. Подходящая структура для многомерного представления данных в форме звезды (star model) или снежинки (snowflake model) и должна состоять из фактов (facts) и измерений (dimensions).

Факты – это фактические записи (records) о каком-то процессе, который мы хотим анализировать, например, успеваемость студентов или определенного студента.

Измерения – это определяющие атрибуты фактов, и обычно отвечают на всякие вопросы: когда произошел факт, над чем или с чем именно, кто был объектом или субъектом и т.п.[] http://habrahabr.ru/blogs/sql/67272/

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

Рисунок 2.2 – Схема «Снежинка»

Ещё одна технология, которую бы хотелось отметить, также используется применительно к многомерным моделям данных – «Data Mining».

Интеллектуальный анализ данных (Data Mining) — по сути, выявление скрытых закономерностей или взаимосвязей между переменными в больших массивах данных” []http://habrahabr.ru/blogs/sql/66356/

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

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