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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алгоритмы обработки.

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

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

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

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

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

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

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

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

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

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