Управление данными в информационных системах

Принципы организации  хранилища

1. Проблемно-предметная ориентация. Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.
2. Интегрированность. Данные объединены так, чтобы они удовлетворяли всем требованиям предприятия в целом, а не единственной функции бизнеса.
3. Некорректируемость. Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются.
4. Зависимость от времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.

 

Управление  данными  в DataWarehouse .

Процессы работы с данными

Источниками данных могут быть:

1. Традиционные системы регистрации операций
2. Отдельные документы
3. Наборы данных

Операции с данными:

1. Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.
2. Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.
3. Загрузка – помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих.
4. Анализ – OLAP, Data Mining, сводные отчёты.
5. Представление результатов анализа.

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

Задача словаря метаданных состоит  в том, чтобы освободить разработчика от необходимости стандартизировать  источники данных.

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

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

Логическая структура данных хранилища  данных отличается от структуры данных источников данных.

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

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

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

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные → информация → знания → полученные решения.

 

 

Общий  подход  в  проектировании  баз  данных.

При проектировании БД возможны 2 подхода:

• синтаксический – ориентирован на уже известную организационную структуру предметной области, то есть подход от запросов пользователя. Как правило, используется в организациях, фирмах с устоявшейся организационной структурой;
• семантический – ориентирован на смысловые характеристики информации – так называемый подход "от  реального мира". Наиболее распространен. Предполагает изменение границ предметной области, непрерывное развитие АЭИС.

Деление на синтаксис и семантику  условно и актуально на I этапе проектирования БД.

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

 

Существует много разновидностей методологии рассмотрения баз данных в классическом подходе, однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис

Этапы формулировки  и  анализа  требований.

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

 

Концептуальное  проектирование.

Этап концептуального  проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут  быть совокупность документов пользователя (рис. 3.3) при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.

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

 

/******************/

Проектирование БД осуществляется в 3 этапа, которые обусловливают жизненную стадию любого цикла автоматизированной экономической информационной системы (АЭИС).

1. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

• обследование предметной области, изучение ее информационной структуры

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

По окончании данного этапа  получаем концептуальную модель, инвариантную к структуре базы данных. Часто  она представляется в виде модели "сущность-связь".

 

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

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

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

/***********/

Логическое проектирование - преобразование требований к данным в структуры  данных. На этом этапе часто моделируют базы данных применительно к различным  СУБД и проводят сравнительный анализ моделей. Выбор конкретной СУБД.

 

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

Физическое проектирование - определение  особенностей хранения данных, методов  доступа и т.д.

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

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

 

2.1.4  Этапы  создания  информационных  систем  и  информационных приложений.

• I этап — предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);
• II этап — проектный (составление технического и рабочего проектов);
• III этап — внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);
• IV этап — анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

Предпроектная стадия

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

К методам изучения и анализа состояния экономического объекта и его системы управления относятся:

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

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

Проектный этап

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

Проектирование технологических процессов включает проектирование паролей, программ, сценариев диалога пользователя с ПВМ, включая проектирование иерархических организованных меню и "окон”. Меню содержит перечень блоков, модулей и программы. Каждый модуль выполняет определенную функцию. Разрабатывается структура меню и сцена диалога человека с машиной. Если привлекаются готовые пакеты прикладных программ, то в них обязательно должно быть руководство пользователю к эксплуатации и комплект машинных программ на дисках.

Требования  к  управлению  данными  со  стороны  информационных систем.

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

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

Доступ и передача данных

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