Информационные системы

На рисунке 5 приводится ER-диаграмма, моделирующая структуры данных и их связи в системе документооборота кафедры. Отношение между ними относится к типу «один ко многим». Эта связь обусловлена тем обстоятельством, что каждое дело в номенклатуре дел кафедры включает множество документов, которые относятся ко многим сотрудникам и группам кафедры.

 

Рис. 5. ER-модель предметной области

 

Сущность «Подразделения института» обладает следующими атрибутами:

1. «НазПодр» (Название подразделения – PK);
2. «Заведующий»;
3. «Телефон»;
4. «НомКаб» (Номер кабинета).

Ключевым  полем данной сущности является «НазПодр». Первичный ключ (PK) – это атрибут который можно использовать для уникальной идентификации таблицы.

Сущность  «Сотрудники кафедры» обладает следующими атрибутами:

1. «ТабНом» (Табельный номер – PK) – данное поле является ключевым;
2. «ФИО» (Фамилия Имя Отчество);
3. «НазДолж» (Название должности – FK1);
4. «Ученая степень»;
5. «Ученое звание»;
6. «Условия привлечения».

Внешний ключ (FK) – это атрибут, который  существует в нескольких таблицах и  является первичным ключом одной из этих таблиц.

Сущность  «Документы» обладает следующими атрибутами:

1. «ID» (PK) – данное поле является ключевым;
2. «КодКл» (Код класса);
3. «Название»;
4. «НазПодр» (FK1);
5. «Учебный год»;
6. «Дата создания»;
7. «ID группы» (FK2);
8. «ТабНом» (FK3).

Сущность  «Штат кафедры» обладает следующими атрибутами:

1. «НазДолж» (Название должности);
2. «Объем нагрузки»;
3. «ДолжИнст» (Должностные инструкции).

Ключевым  полем данной сущности является «НазДолж» (PK).

Сущность  «Номенклатура дел» обладает следующими атрибутами:

1. «КодКл» (Код класса, PK) – данное поле является ключевым;
2. «Название»;
3. «Срок хранения, статья по перечню»;
4. «Примечание».

Сущность «Группы студентов» обладает следующими атрибутами:

1. «ID» (Номер группы, PK) – данное поле является ключевым;
2. «Курс»;
3. «Специальность»;
4. «ФИО куратора»;
5. «Форма обучения».

 

2.2 Разработка базы данных на  основе даталогического моделирования в среде MS Access

 

Даталогическая  модель предметной области ориентирована  на среду хранения и манипулирования  данными. Существует огромное количество различных средств проектирования систем управления базами данных. Можно выбрать низкоуровневые программные системы разработки СУБД, высокоуровневые и автоматизированные системы разработки на основе CASE-технологий [8, с. 389].

Ранее на этапе выбора программного обеспечения  нами была выбрана среда разработки СУБД MS Access. Особенность этой системы в том, что она входит в комплект MS Office, широко распространена, практична и легка в применении. Применение этой системы позволяет без особого труда проектировать реляционные СУБД. Поэтому, даталогическое моделирование выполним применительно к среде разработки СУБД MS Access.

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

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

Классическая  технология проектирования реляционных  баз данных связана с теорией  нормализации, основанной на анализе (функциональных зависимостей между атрибутами отношений). Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей [45, с. 297]. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

• первая нормальная форма;
• вторая нормальная форма;
• третья нормальная форма;
• нормальная форма Бойса – Кодда;
• четвертая нормальная форма;
• пятая нормальная форма, или форма проекции-соединения.

Сформулируем  требования при нормализации базы данных.

Первая  нормальная форма требует, чтобы  все значения полей были атомарными и все записи уникальными.

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

Модель  находится в третьей нормальной форме, если она находится во второй нормальной форме и не имеет транзитивных зависимостей. Транзитивная зависимость  – это зависимость между не ключевыми атрибутами.

В большинстве  случаев достаточно довести нормализацию базы данных до третьей нормальной формы. Более высокий уровень нормализации приводит к усложнению работы с базой данных. При проектировании базы данных для автоматизированной системы документооборота кафедры достижение третьей нормальной формы будет достаточно [44, с. 17].

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

Реляционное отношение в среде MS Access представляется в виде двумерной таблицы. Структура таблиц в MS Access разрабатывается в режиме конструктора. На этом этапе даются имена полям таблицы, устанавливается тип данных каждого поля, а также задаются ключевые поля (первичный ключ и внешние ключи). Результаты проектирования структуры таблиц приводятся в таблицах 2 – 7.

Всего в  данной БД существует 6 таблиц:

1. Номенклатура дел;
2. Документы;
3. Сотрудники кафедры;
4. Подразделения института;
5. Штат кафедры;
6. Группы студентов.

Далее определим  типы и размеры полей таблиц.

 

Таблица 2

Структура таблицы «Номенклатура  дел»

Имя поля	Тип поля	Примечание
КодКл	Текстовый	Длина 15 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.
Название	Текстовый	Длина 85 символов
Срок хранения, статья по перечню	Текстовый	Длина 105 символов
Примечание	Текстовый	Длина 255 символов

 

В данной таблице использовались следующие  типы полей:

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

 

Таблица 3

Структура таблицы «Документы»

Имя поля	Тип поля	Примечание
ID	Счетчик	Длинное целое. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.
КодКл	Текстовый	Длина 25 символов
Название документа	Гиперссылка
Название подразделения	Текстовый	Длина 55 символов
Учебный год	Текстовый	Длина 25 символов
Дата создания	Дата/время	Краткий формат даты
Группа	Текстовый	Длина 10 символов
ФИО сотрудника	Текстовый	Длина 255 сиволов символов

 

В данной таблице использовались следующие  типы полей:

Поле  «ID» (номер по порядку) тип данных которого – счетчик. Поле, в которое при добавлении записи автоматически вводится уникальное число. Созданный для записи номер уже не может быть удален или изменен.

Текстовый – для ввода текста или комбинации текста и чисел, не требующих вычисления. Данный тип выбран для следующих полей: «КодКл», «Название подразделения», «Учебный год», «Группа», «ФИО сотрудника». Длина поля выбирается исходя из возможной длины самого длинного значения атрибута.

Дата/время  – для вывода даты или времени. Данный тип удобен для поля «Дата» с кратким форматом даты.

Гиперссылка – цветной подчеркнутый текст  или графический объект, по щелчку которого выполняется переход к  файлу, фрагменту документа. Данный тип данных выбран для поля «Название  документа».

 

Таблица 4

Структура таблицы «Сотрудники  кафедры»

Имя поля	Тип поля	Примечание
ТабНом	Текстовый	Длина 25 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.
ФИО	Текстовый	Длина 255 символов
Название должности	Текстовый	Длина 30 символов
Ученая степень	Текстовый	Длина 20 символов
Ученое звание	Дата/время	Длина 25 символов
Условия привлечения	Тестовый	Длина 75 символов

 

В таблице 4 использовались следующие типы полей:

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

 

Таблица 5

Структура таблицы «Подразделения института»

Имя поля	Тип поля	Примечание
НазПодр	Текстовый	Длина 255 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.
Заведующий	Текстовый	Длина 25 символов
НомКаб	Числовой	Длинное целое
Телефон	Текстовый	Длина 20 символов.

 

В таблице 5 использовались следующие типы полей:

Текстовый – для ввода текста или комбинации текста и чисел, не требующих вычисления. Данный тип выбран для следующих полей: «НазПодр», «Заведующий», «Телефон». Длина поля выбирается исходя из возможной длины самого длинного значения атрибута.

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