5. Требования к ис повышающие удобство использования

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

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

• Наличие дружественно графического интерфейса;

• Время ответа по любой из наиболее часто встречающихся операций не превышает 2 секунды;

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

2 Специальная часть

2.1 Потоки данных

- Хранилище данных (Структура для хранения информационных объектов)

- Функция (Действие, выполняемое моделируемой системой)

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

- Внешняя сущность (Внешний по отношению к системе объект, обменивающийся с нею потоками данных)

Такой тип обозначений элементов DFD-диаграммы получил название "нотация Йордона - Де Марко", по именам разработавших его специалистов.

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

• Функции преобразуют входящие потоки данных в выходящие

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

• Преобразования потоков данных во внешних сущностях игнорируется

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

В моем случае, преподаватели создают документацию, преподаватели это объект, документация – это хранилище. Методист проверяет документацию и создает замечания о выполнении, методист это объект.

Рис. 2.1.1 Потоки данных

2.2 Инфологическое проектирование

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

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

Сущность – объект природы, который имеет уникальное имя.

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

Средства, примененные при проектировании инфологической модели.

Для проектирования инфологической модели будем применять диаграммы “сущность - связь” (Entity - Relationship Diagrams). Диаграммы “сущность-связь” (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущность системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами.

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

Отношение – в самом общем виде представляет собой связь между двумя и более сущностями.

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

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

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

• Связи будем идентифицировать по их назначению;

• Допускается использование атрибутов в нескольких сущностях одновременно;

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

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

В данном случае у нас будут сущности:

Основные сущности:

1. «Преподаватели»

• Код преподавателя;

• ФИО преподавателя;

• ЦК;

2. «Дисциплины»

• Код;

• Дисциплина;

• Семестр;

• Группа;

• Преподаватели;

• Литература;

3. «Литература»

• Код;

• Наименование дисциплин;

• Количество обучающихся;

• Автор, название;

• Количество (экз);

• Методическое пособие;

• Год издания;

4. «Нагрузка»

• Код предмета;

• Группа/предмет;

• Кол_час_неделю (1 сем);

• Часы_лаб/пр (1 сем);

• Деление_лаб/пр (1 сем);

• Экз/зач (1 сем);

• Экз-часы (1 сем);

• Кол_час_всего (1 сем);

• Кол_часов_неделю (2 сем);

• Деление_лаб/пр (2 сем);

• Часы_лаб/пр (2 сем);

• Экз/зач (2 сем);

• Экз_часы (2 сем);

• Кол_час_всего (2 сем);

• Дата_начала_занятий;

• Дата_оконч_занятий;

5. «КТП»

• Урок;

• Календарные сроки изучения темы;

• Наименование тем;

• Количество часов;

• Вид занятий;

• Учебно-наглядные пособия;

• Задания для студентов;

6. «Распис. Нов.»

• Код;

• Неделя нечет/чет;

• День недели;

• Пара;

• Предмет;

7. «Расписание_неделя»

• Пара;

• Четная/нечетная;

• Понедельник

• Вторник

• Среда

• Четверг

• Пятница

• Суббота

• Воскресенье

8. «Календарь»

• День

• Месяц

• Выходные да/нет

• День недели

• Номер уч. Недели

• Нечетная/четная

Вспомогательные сущности:

1. «чет/нечет неделя»

   • Неделя ключевой атрибут

   • Нечет/чет

2. «Группа»

• Название специальности

• Группа

3. «ЦК»

• Номер

• Название

Ключевые атрибуты однозначно определяют экземпляр сущности. Например, ключевое поле «Неделя» будет описанием конкретного кода, нечет/четн.,

На ЕR - диаграмме сущность обозначают:

Название сущности

П редметы во Вкладыш

Д ень Выходныеда/нет Деньнедели

Ключевой атрибут

Между сущностями устанавливается связь. Она может быть между разными сущностями или между сущностями и ей самой, т.е. рекурсивная связь. Рекурсивная связь показывает, как связаны экземпляры сущности между собой.

Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь может быть обязательной, если в ней должен участвовать каждый элемент сущности; иначе эта связь будет необязательной. Связь также может быть обязательной с одной стороны и необязательной с другой.

Условные обозначения, примененные при описании отношений.

Отношение один к одному обязательное с обеих сторон Отношение один к одному необязательное с обеих сторон Отношение один к одному необязательное с одной из сторон и обязательное с другой Отношение один ко многим обязательное с одной из сторон и необязательное с другой Отношение многие к одному, необязательное с одной из сторон и обязательное с другой Отношение многие ко многим необязательное с обеих сторон Отношение многие ко многим обязательное с обеих сторон

У меня получается 3 инфологические модели, т.к. у меня 3 блока.

Д исциплины К од Д исциплина Семестр Г руппа П реподаватели Литература Ц К Н омер Н азвание

Литература К од Н аименование дисциплин Количество обучающихся Автор, название Количество (экз) Методическое пособие Год издания Группа Н азвание специальности г руппа Преподаватели К од преподавателя ФИО преподавателя Ц К

Р ис.2.2.1 Инфологическая модель(ER-диаграмма). Справочная информация

Нагрузка К од предмета Г руппа/предмет Кол-час_неделю (1сем) Часы_лаб/пр (1 сем)

К ТП Урок Календарные сроки Наименование тем Количество часов Вид Занятий Учебно-наглядное пособие Задание для студента п римечание Д исциплина Распис нов Неделя нечет/чет День недели Пара П редмет

Рис.2.2.1 Инфологическая модель(ER-диаграмма). Календарно-тематический план, расписание

Ч ет/нечет неделя Н еделя н ечет/чет

Расписание_неделя П ара Ч етная/нечетная Понедельник Вторник Среда Четверг Пятница Суббота Воскресенье Календарь День Месяц Выходные да/нет ДеньНед Н омер уч нед Нечетная/четная

Рис. 2.2.1 Инфологическая модель(ER-диаграмма). Календарь, ежедневник

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

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

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