Составление расписания в учебном отделе ВУЗа

Рис. 2.2. Декомпозиция контекстной диаграммы «Организация учебного процесса»

Исходя из рисунка 2.2. видно, что процесс «Организация учебного процесса» делится на:

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

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

• учебные планы за прошлые учебные годы.

 

Далее декомпозируем процесс  «Составление расписания» (рис.2.3.).

Рис. 2.3. Декомпозиция процесса  «Составление расписания»

Исходя из рисунка 2.3. видно, что процесс «Составление расписания» делится на:

• анализ поступающих данных;
• распределение групп студентов по сетке аудиторного фонда;
• выверка накладок, перераспределение студентов по сетке аудиторного фонда.

 

На рисунке 2.4. рассмотрим диаграмму дерева узлов.

Рис.2.4. Диаграмма  дерева узлов модели процессов ИС

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

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

Процесс «Составление расписания»  включает в себя:

• анализ поступающих данных;
• распределение групп студентов по сетке аудиторного фонда;
• выверка накладок, перераспределение студентов по сетке аудиторного фонда.

 

 

 

2. Модель данных ИС предприятия с использованием стандарта IDEF1Х

 

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

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

На рисунке 2.5. изображена логическая модель базы данных информационной системы автоматизации составления расписания. Серым цветом помечены таблицы, имеющие непосредственное отношение к составлению расписания, а белым – справочные таблицы. Данная модель представляет собой совокупность взаимосвязанных сущностей и их атрибутов. Элементы этой модели данных и взаимосвязи между ними представляются 11 таблицами базы данных. Связанные отношениями таблицы взаимодействуют по принципу главная-подчиненная. Значения первичных ключей в таблицах базы данных уникальны, что облегчает установление связей между ними. На модели отображены реляционные связи «один-ко-многим» и «один к одному».

На логической модели отображены следующие сущности Отделение, Факультет, Курс, ДН, Время, Вид Дисциплины, Дисциплина, Преподаватель, Группа, Аудитория, Расписание.

Рис. 2.5. Логическая модель базы данных информационной системы  «Составление расписания в учебном  отделе»

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

Рис. 2.6. Физическая модель базы данных информационной системы  «Составление расписания в учебном  отделе»

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

3. Программная реализация ИС

 

Для того, чтобы получить физическую модель базы данных «Учет товаров на складе» в Oracle из полученной в ERwin логической модели генерируется физическая модель через встроенные процедуры Erwin. Сначала выбирается сервер.

Генерация физической модели базы данных склада в из ERwin отображена на рис. 2.7.-

В меню DataBase / Choose Database указываем СУБД:

Рис.2.7. Выбор базы данных Oracle для генерации

Затем в меню Tools/Forward Engineer/Shema Generation выбираем:

Рис.2.8. Генерация физической модели базы данных склада в Oracle из ERwin

По кнопке Generate выбираем базу, в которую необходимо перенести таблицы:

Предварительно  создадим пользователя базы данных Oracle (см. рис.2.9).

Рис.2.9. Создание  пользователя базы данных Oracle

Рис.2.10. Генерация физической модели базы данных склада в Oracle из ERwin

В строке Connection String указываем имя рабочей машины.

По кнопке Generate генерируется SQL – код создания БД в Oracle:

Рис.2.11. Сгенерированный SQL код в Oracle из ERwin

Заходим в Oracle в базу данных, в которую сгенерированы таблицы. В Object Browser просматриваем сгенерированные таблицы.

Рис.2.12. Сгенерированные таблицы в Oracle

Заполняем справочные и операционные таблицы в меню Data / Insert Row:

Заполняем таблицу AUDITORIYA:

Рис.2.14. Таблица AUDITORIYA в Oracle

Далее представлен программный  код таблицы AUDITORIYA:

 

CREATE TABLE  "AUDITORIYA"

   ( "NAME" VARCHAR2(20) NOT NULL ENABLE,

"AUDITORIYA_ID" NUMBER(*,0) NOT NULL ENABLE,

"ADRESS" VARCHAR2(50),

"PHONE" NUMBER(*,0),

CONSTRAINT "XPKАУДИТОРИЯ" PRIMARY KEY ("AUDITORIYA_ID") ENABLE

   )

/

 

CREATE OR REPLACE TRIGGER  "TD_AUDITORIYA" AFTER DELETE ON AUDITORIYA for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- DELETE trigger on AUDITORIYA

DECLARE NUMROWS INTEGER;

BEGIN

    /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

    /* AUDITORIYA Relationship_266 RASPISANIE on parent delete no action */

    /* ERWIN_RELATION:CHECKSUM="0000d4c5", PARENT_OWNER="", PARENT_TABLE="AUDITORIYA"

    CHILD_OWNER="", CHILD_TABLE="RASPISANIE"

    P2C_VERB_PHRASE="Relationship_266", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="AUDITORIYA_id" */

    SELECT count(*) INTO NUMROWS

      FROM RASPISANIE

      WHERE

        /*  %JoinFKPK(RASPISANIE,:%Old," = "," AND") */

        RASPISANIE.AUDITORIYA_id = :old.AUDITORIYA_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20001,

        'Cannot DELETE AUDITORIYA because RASPISANIE exists.'

      );

    END IF;

 

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TD_AUDITORIYA" ENABLE

/

 

CREATE OR REPLACE TRIGGER  "TU_AUDITORIYA" AFTER UPDATE ON AUDITORIYA for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- UPDATE trigger on AUDITORIYA

DECLARE NUMROWS INTEGER;

BEGIN

  /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

  /* AUDITORIYA Relationship_266 RASPISANIE on parent update no action */

  /* ERWIN_RELATION:CHECKSUM="000103ef", PARENT_OWNER="", PARENT_TABLE="AUDITORIYA"

    CHILD_OWNER="", CHILD_TABLE="RASPISANIE"

    P2C_VERB_PHRASE="Relationship_266", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="AUDITORIYA_id" */

  IF

    /* %JoinPKPK(:%Old,:%New," <> "," OR ") */

    AUDITORIYA.AUDITORIYA_id <> AUDITORIYA.AUDITORIYA_id

  THEN

    SELECT count(*) INTO NUMROWS

      FROM RASPISANIE

      WHERE

        /*  %JoinFKPK(RASPISANIE,:%Old," = "," AND") */

        RASPISANIE.AUDITORIYA_id = :old.AUDITORIYA_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20005,

        'Cannot update AUDITORIYA because RASPISANIE exists.'

      );

    END IF;

  END IF;

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TU_AUDITORIYA" ENABLE

/

 

Далее заполняем таблицу DN:

Рис.2.15. Таблица DN в Oracle

 

Далее представлен программный  код таблицы DN:

 

CREATE TABLE  "DN"

   ( "DN_ID" NUMBER(*,0) NOT NULL ENABLE,

"ADRESS" VARCHAR2(50),

"PHONE" NUMBER(*,0),

"SURNAME" VARCHAR2(20),

CONSTRAINT "XPKДН" PRIMARY KEY ("DN_ID") ENABLE

   )

/

 

CREATE OR REPLACE TRIGGER  "TD_DN" AFTER DELETE ON DN for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- DELETE trigger on DN

DECLARE NUMROWS INTEGER;

BEGIN

    /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

    /* DN Relationship_265 RASPISANIE on parent delete no action */

    /* ERWIN_RELATION:CHECKSUM="0000dd07", PARENT_OWNER="", PARENT_TABLE="DN"

    CHILD_OWNER="", CHILD_TABLE="RASPISANIE"

    P2C_VERB_PHRASE="Relationship_265", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="DN_id" */

    SELECT count(*) INTO NUMROWS

      FROM RASPISANIE

      WHERE

        /*  %JoinFKPK(RASPISANIE,:%Old," = "," AND") */

        RASPISANIE.DN_id = :old.DN_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20001,

        'Cannot DELETE DN because RASPISANIE exists.'

      );

    END IF;

 

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TD_DN" ENABLE

/

 

CREATE OR REPLACE TRIGGER  "TU_DN" AFTER UPDATE ON DN for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- UPDATE trigger on DN

DECLARE NUMROWS INTEGER;

BEGIN

  /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

  /* DN Relationship_265 RASPISANIE on parent update no action */

  /* ERWIN_RELATION:CHECKSUM="0001060e", PARENT_OWNER="", PARENT_TABLE="DN"

    CHILD_OWNER="", CHILD_TABLE="RASPISANIE"

    P2C_VERB_PHRASE="Relationship_265", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="DN_id" */

  IF

    /* %JoinPKPK(:%Old,:%New," <> "," OR ") */

    DN.DN_id <> DN.DN_id

  THEN

    SELECT count(*) INTO NUMROWS

      FROM RASPISANIE

      WHERE

        /*  %JoinFKPK(RASPISANIE,:%Old," = "," AND") */

        RASPISANIE.DN_id = :old.DN_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20005,

        'Cannot update DN because RASPISANIE exists.'

      );

    END IF;

  END IF;

 

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TU_DN" ENABLE

/

 

Далее заполняем таблицу FAKULTET:

Рис.2.16. Таблица FAKULTET в Oracle

 

Далее представлен программный  код таблицы FAKULTET:

 

CREATE TABLE  "FAKULTET"

   ( "NAIMENOVANIE_FAKULTETA" VARCHAR2(20) NOT NULL ENABLE,

"FAKULTET_ID" NUMBER(*,0) NOT NULL ENABLE,

"ADRESS" VARCHAR2(50),

"PHONE" NUMBER(*,0),

CONSTRAINT "XPKПОСТАВЩИКИ" PRIMARY KEY ("FAKULTET_ID") ENABLE

   )

/

 

CREATE OR REPLACE TRIGGER  "TD_FAKULTET" AFTER DELETE ON FAKULTET for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- DELETE trigger on FAKULTET

DECLARE NUMROWS INTEGER;

BEGIN

    /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

    /* FAKULTET Relationship_264 GRUPPA on parent delete no action */

    /* ERWIN_RELATION:CHECKSUM="0000e308", PARENT_OWNER="", PARENT_TABLE="FAKULTET"

    CHILD_OWNER="", CHILD_TABLE="GRUPPA"

    P2C_VERB_PHRASE="Relationship_264", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="FAKULTET_id" */

    SELECT count(*) INTO NUMROWS

      FROM GRUPPA

      WHERE

        /*  %JoinFKPK(GRUPPA,:%Old," = "," AND") */

        GRUPPA.FAKULTET_id = :old.FAKULTET_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20001,

        'Cannot DELETE FAKULTET because GRUPPA exists.'

      );

    END IF;

 

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TD_FAKULTET" ENABLE

/

 

CREATE OR REPLACE TRIGGER  "TU_FAKULTET" AFTER UPDATE ON FAKULTET for each row

-- ERwin Builtin 15 мая 2012 г. 15:53:49

-- UPDATE trigger on FAKULTET

DECLARE NUMROWS INTEGER;

BEGIN

  /* ERwin Builtin 15 мая 2012 г. 15:53:49 */

  /* FAKULTET Relationship_264 GRUPPA on parent update no action */

  /* ERWIN_RELATION:CHECKSUM="00010cf3", PARENT_OWNER="", PARENT_TABLE="FAKULTET"

    CHILD_OWNER="", CHILD_TABLE="GRUPPA"

    P2C_VERB_PHRASE="Relationship_264", C2P_VERB_PHRASE="",

    FK_CONSTRAINT="", FK_COLUMNS="FAKULTET_id" */

  IF

    /* %JoinPKPK(:%Old,:%New," <> "," OR ") */

    FAKULTET.FAKULTET_id <> FAKULTET.FAKULTET_id

  THEN

    SELECT count(*) INTO NUMROWS

      FROM GRUPPA

      WHERE

        /*  %JoinFKPK(GRUPPA,:%Old," = "," AND") */

        GRUPPA.FAKULTET_id = :old.FAKULTET_id;

    IF (NUMROWS > 0)

    THEN

      raise_application_error(

        -20005,

        'Cannot update FAKULTET because GRUPPA exists.'

      );

    END IF;

  END IF;

 

 

-- ERwin Builtin 15 мая 2012 г. 15:53:49

END;

 

/

ALTER TRIGGER  "TU_FAKULTET" ENABLE

/

 

Далее заполняем таблицу GRUPPA:

 

Рис.2.17. Таблица GRUPPA в Oracle

 

Далее представлен программный  код таблицы GRUPPA: