2.1 Проектирование системы «Деканат» для управления филиалом педагогического ВУЗа

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

Обратимся к определению, согласно толковому словарю Ушакова филиал - это отделение крупного отделения или организации [38]. Юридический словарь дает следующее определение - филиал (от лат. filialis - сыновний) - по гражданскому законодательству РФ обособленное подразделение юридического лица (предприятия), расположенное вне места его нахождения и осуществляющее все его функции или их часть, в том числе функции представительства [38]. Если перенести данные понятия на образование, то получим, что филиал учебного заведения - это подразделение вуза, которое находиться в другом населенном пункте и частично или полностью выполняет функции головного вуза.

Анализируя полученное определение можно выделить следующие задачи и направления деятельности филиала:

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

удовлетворение потребностей общества и государства в высококвалифицированных специалистах высшей квалификации;

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

подготовка, переподготовка и повышение квалификации специалистов и руководящих работников;

накопление, сохранение и приумножение нравственных, культурных и научных ценностей общества;

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

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

Объединения все вышесказанное можно выделить преимущества и недостатки филиалов. К преимуществам можно отнести:

возможность для студента обучаться в родном городе или регионе,

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

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

для головного вуза филиал предоставляет дополнительные ресурсы, как духовные, так и марериальные.

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

В настоящий момент филиале КГПУ им.В.П.Астафьева в г. Канске обучаются студенты по нескольким специальностям и профилям подготовки. Одним из направлений является специальность «Информатики», по которой ведётся очное обучение. Из этого следует, что в филиале осуществляется весь перечень деятельноти которые организуются в головном вузе для обучения студентов.

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

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

Целью работы является разработка и внедрение адаптированной автоматизированной системы управления работы со студентами для филиала ВУЗа, которая позволит обеспечить:

повышение эффективности работы кафедры;

сокращение времени получения информации, требуемой для принятия решения;

автоматизацию заполнеения ряда отчетов, табелей, планов и прочей ддокументации.

С точки зрения реализации проектируемая система должна удовлетворять следующим требованиям:

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

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

Разработка инфологической модели

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

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

корректность схемы БД(адекватное отображение моделированной ПО);

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

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

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

Для автоматизированной системы управления «Деканат» на основе проведенного системного анализа предметной области выделены следующие сущности:

Преподаватель - сущность содержит информацию о преподавателях;

Студент - сущность содержит информацию об учащихся в данном учебном заведении (конкретно филиале);

Дисциплина - сущность содержит информацию о доступных курсах обучения;

Сессия - сущность содержит необходимую, для студентов и преподавателей, информацию;

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Рис.1 Инфологическая модель предметной области

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

Обоснование выбора модели данных

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

Существуют несколько разновидностей даталогических моделей данных [8]:

иерархическая модель;

сетевая модель;

реляционная модель;

объектно-ориентированная модель;

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

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

Организация данных в СУБД иерархического типа определяется в терминах:

Атрибут(элемент данных) - наименьшая единица структура данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

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

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

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

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

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

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

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

Операции над данными, определенные в иерархической модели:

ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.

ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

УДАЛИТЬ некоторую запись и все подчиненные ей записи.

ИЗВЛЕЧЬ корневую запись по ключевому значению (допускается также последовательный просмотр корневых записей);

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

Сетевая модель данных

На разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.) [2].

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

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

Каждый экземпляр группового отношения характеризуется следующими признаками [2]:

способ упорядочения подчиненных записей:

произвольный,

хронологический(очередь),

обратный хронологический(стек),

сортированный.

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

режим включения подчиненных записей:

автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;

ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем;

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

Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи-владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.

Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.

Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи-владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Реляционная модель данных

Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД [11].

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

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

Определения:

Декартово произведение: Для заданных конечных множеств (не обязательно различных) декартовым произведением называется множество произведений вида: , где

Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2)

 Отношение: Отношением R, определенным на множествах называется подмножество декартова произведения .

Отношения удобно представлять в виде таблиц. На рис. 2 представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам [22]. Каждая строка фактически представляет собой описание одного объекта реального мира (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

Рис.2. Основные компоненты реляционного отношения.

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

Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на рис.2 атрибуты "Оклад" и "Премия" определены на домене "Деньги". Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов "Табельный номер" и "Оклад" является семантически некорректным, хотя они и содержат данные одного типа [22].

Именованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами [11].

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

Рис.3. База данных о подразделениях и сотрудниках предприятия.

Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе.

Объектно-ориентированная модель данных

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