Разработка базы данных для АСУ «Компьютерные курсы»

 

АСУ «ВУЗ»

Программный продукт автоматизированной системы управления вузом (АСУ ВУЗ) «Universys WS 3.5» является программной платформой для создания и функционирования проектов АСУ ВУЗ для образовательных учреждений и организаций. 
 
Проекты, созданные на его базе состоят из следующих типовых модулей - виртуальных разделов:

• электронный ректорат;
• электронный деканат;
• электронная учебно-методическая часть;
• электронная канцелярия;
• электронный отдел кадров;
• электронная приемная комиссия;
• электронная бухгалтерия;
• электронная библиотека;
• электронный кабинет преподавателя;
• электронные личные кабинеты студентов.

ПП «Universys Web Server» представляет собой  программный комплекс, состоящий  из базы данных (БД) и программного обеспечения Web - интерфейса системы.

Проекты, построенные на базе ПП «Universys Web Server» позволяют автоматизировать следующие основные деловые процессы образовательного учреждения:

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

Проекты на базе ПО АСУ ВУЗ "Universys Web Server" становятся особенно полезными в случаях, если у образовательного учреждения:

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

1.4. Требования к разрабатываемой  базе данных

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

С данной базой данных могут работать следующие группы пользователей:

• заведующий – руководящая должность в учебном заведении;
• преподаватели – сотрудник учебного заведения;
• учащиеся – клиент учебного заведения;

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

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

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

• просматривать личную информацию о себе;
• просматривать список групп студентов;
• просматривать расписание;

При работе с базой данных студент может:

• просматривать расписание;

Выводы

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

В ходе обзора информационных технологий перечислены классы СУБД, приведены  примеры для каждого класса и  определены достоинства и недостатки следующих СУБД: Microsoft Access, SQLite, MySQL, Microsoft SQL Server.

Рассмотрены продукты-аналоги на рынке  информационных систем(АСУ «КОЛЛЕДЖ», АСУ «Учебное заведение», АСУ «ВУЗ») и даны описания данных систем.

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

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

 

Глава II. Проектирование базы данных

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

• иерархическая модель;
• сетевая модель;
• реляционная модель;
• объектно-ориентированная модель;

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

 

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

Структура данных.

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

• Атрибут(элемент данных) – наименьшая единица структура данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
• Запись – именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи – конкретная запись с конкретным значением элементов.
• Групповое отношение – иерархическое отношение между записями двух типов. Родительская запись(владелец группового отношения) называется исходной записью, а дочерние записи(члены группового отношения) – подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.

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

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

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

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

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

• ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.
• ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.
• УДАЛИТЬ некоторую запись и все подчиненные ей записи.
• ИЗВЛЕЧЬ:

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

В операции ИЗВЛЕЧЬ допускается  задание условий выборки(например, извлечь сотрудников с окладом  более 1 тысячи рублей).

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

Ограничения целостности.

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

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

Структура данных.

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

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

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

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