Система управления экономической информацией в МУ «ЦБМУ»

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

«Нуль» не означает пустое поле или обычный математический нуль. Он отображает тот факт, что значение неизвестно, недоступно или неприменимо. Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет) на трехзначную (да/нет/может быть). С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее, они являются составной частью большинства официальных стандартов различных реляционных СУБД.

Целостность – очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы – проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логической ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями.

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

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

• Определяться на языке высокого уровня, используемом системой для всех других целей;
• Храниться в словаре данных, а не в программных приложениях.

Эти возможности в  том или ином виде реализованы  в большинстве систем.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

Процедуры, выполняемые  на этапах жизненного цикла БД

Проектирова-ние

Создание

Эксплуатация

Анализ предметной области  и запросов к БД

Генерация схемы БД

Реорганизация БД

Организация доступа  к  базам данных

Контроль состояния  БД

Интеграция пользовательских представлений

Подготовка среды хранения

Реструктуризация БД

Поиск и обновление данных

Сбор и анализ статистики использования БД

Выбор средства реализации

Ввод и контроль данных

Рефор-матизация БД

Вывод отчетов

Контроль целостности  БД

Логическое проектирова-ние

Загрузка и корректировка  БД

Разграничение доступа

Копирование и восстанов-ление БД

Физическое проектирова-ние

Инициирование и завершение работы с СУБД

 

Рис. 1

Анализ предметной области  и запросов к  БД.

На данном этапе необходимо проанализировать запросы пользователей, выбрать информационные объекты и их характеристики и на основе анализа структурировать предметную область (рис. 2).

Анализ предметной области  целесообразно разбить на три  фазы:

- Анализ концептуальных требований и информационных потребностей;

- Выявление информационных объектов и связей между ними;

- Построение концептуальной модели предметной области и проектирование концептуальной схемы БД.

Объекты реального мира		Ограничения эксплуатации (технология)				Входные / выходные/ документы
		Уровень  реальности
Описания объектов предметной области				Внешние пользовательские представления (описание функций приложений –  задач)
		Уровень концептуального проектирования
Описание предметной области на языке описания данных выбранной СУБД			Описание входных и выходных форм документов и функций обработки  данных на языках описания входных  и выходных форм запросов выбранной  СУБД
		Уровень формальных текстов (логическое проектирование)

               Описание         Уровень физической

Библиотека     Библиотека

      базы           реализации  входных и      запросов

      данных      вых. форм

 

Рис. 2

 

Анализ концептуальных требований.

На этапе анализа  концептуальных требований и информационных потребностей необходимо решить следующие задачи:

- Анализ требований пользователей к БД (концептуальных требований);

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

- Выявление перспективных задач (перспективных приложений);

- Документирование результатов анализа.

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

Например, в случае разработки БД для ведения электронной документации экономистов муниципального учреждения «ЦБМУ» необходимо получить ответы на вопросы:

1. Сколько сотрудников трудится в каждом учреждении?
2. Сколько смен и классов в каждом учебном учреждении?
3. Как распределяются выделенные денежные средства на каждое учреждение?
4. Сколько денежных средств необходимо для расчета фонда оплаты труда по каждому учреждению?
5. Сколько имеется подконтрольных муниципальных учреждений?
6. Сколько сотрудников в каждом муниципальном дошкольном учреждении, их специализация и классность?
7. Как часто обновляется информация в БД?

Необходимо решить задачи:

1. Ведения финансовых документов по каждому муниципальному учреждению.
2. Ведения отчетности по каждому муниципальному учреждению.
3. Ведения расчетов фонда оплаты труда сотрудников каждого муниципального учреждения?

 

На основе информации хранящейся в БД необходимо выдавать следующие отчеты:

- Роспись бюджета по каждому муниципальному учреждению.

- Сводная роспись бюджета по МУ «ЦБМУ».

- Штатная структура каждого муниципального учреждения.

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

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

При выборе информационных объектов необходимо ответить на ряд  вопросов:

На какие таблицы  можно разбить данные, подлежащие хранению в БД?

Какое имя можно присвоить каждой таблице?

Какие наиболее интересные характеристики (с точки зрения пользователя) можно выделить?

Какие имена можно  присвоить выбранным характеристикам?

В нашем случае предполагается завести следующие таблицы (рис. 3):

 

Учреждения	Тарифика-ция	Штатное расписание	Бюджет	Расчет ФОТ
МСДОУДСКВ № 40 «Калинка»	Ф.И.О.	Должность	Статья бюджета	Тариф по штату
МДОУДСКВ № 44 «Солнышко»	Должность	Кол-во шт.единиц	КБК	Фонд надбавок
МДОУДС № 53 «Серебряное  копытце»	Образование	Ставка	Выделено на год	Надбавка за категорию
МДОУДСКВ «Радуга»	Стаж пед.работы	Компенсация за вредность	Необходимо на год	Ночные и праздничные
МОУ СОШ № 5	Ставка	Персон.над-бавка	Дефицит	Уральский коэффициент
МОУ СОШ № 7	Категория	Категория		Компенсация отпуска
МОУ СОШ № 10	Уральский коэффициент	Уральский коэффициент
МОУГ
МОУ СОШ с.Акинфиево
МОУ ДОД ДШИ
МОУ ДОД ДДТ
МОУ ДОД ДЮСШ
МОУ ДОД клуб «Эврика»
МУК «ЦГБ»
МУ «ГДК»
МУ «СОК»

 

Рис. 3.

Выделим связи между информационными объектами (рис.4)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 4.

В ходе этого процесса необходимо ответить на следующие  вопросы:

Какие типы связей между  информационными объектами?

Какое имя можно присвоить  каждому типу связей?

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

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

Какова область значений для числовых характеристик?

Каковы функциональные зависимости между характеристиками одного информационного объекта?

Какой тип отображения  соответствует каждому типу связей?

При проектировании БД существуют взаимосвязи между информационными  объектами трех типов: «один к  одному», «один ко многим», «многие  ко многим» (рис.5).

Например:

сотрудник	Один к одному	категория
учреждение	Один ко многим	сотрудник
Сотрудники учреждения	Многие к многим	тариф

 

Рис. 5.

 

 

Построение концептуальной модели

В простых случаях  для построения концептуальной схемы  используют традиционные методы агрегации  и обобщения. При агрегации объединяются информационные объекты (элементы данных) в один в соответствии с семантическими связями между объектами. Например, преподаватель МОУ СОШ № 10 , стаж педагогической деятельности 5 лет, занимает 1 ставку, имеет надбавку за категорию. Методом агрегации создаем информационный объект (сущность) СПИСОК со следующими атрибутами: «преподаватель», «стаж», «ставка». При обобщении информационные объекты (элементы данных) объединяются в родовой объект (рис.6):

преподаватель
Стаж пед.деятельности		Расчет ФОТ на одного преподавателя
ставка