Фактографические модели данных.

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

Среди фактографических информационных систем выделяют два класса:

- системы операционной обработки данных;

- системы, ориентированные на анализ данных и поддержку принятия решения.

1) Системы операционной обработки данных.

Для обозначения таких систем используется термин OLTP (On-Line Transaction Processing – оперативная обработка транзакций или выполнение транзакций в режиме реального времени). Такие системы рассчитаны на обслуживание относительно простых запросов большого числа пользователей.

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

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

Информационная система строится как система OLTP, если при ее функционировании неизбежны следующие аспекты работы:

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

Пример: продажа билетов.

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

Пример: перевод денежных средств.

Пример 2: В БД библиотеки хранятся библиографические сведения о каждой книге: год издания, автор, название и пр. Разумеется, текст книги в ней содержаться не будет. В БД учащихся школы хранятся анкетные данные об учениках: фамилия, имя, отчество, год и место рождения и т. д.

Одним из основных требований к современной OLAP-системе является надежность хранения данных, т.е. способность восстанавливать согласованное состояние базы данных после любых аппаратных или программных сбоев.

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

2) Системы, ориентированные на анализ данных.

Для обозначения таких систем используется термин – OLAP (On-Line Analytical Processing – системы оперативной аналитической обработки). Они ориентированы на анализ данных и обеспечивают получение информации, необходимой для разработки решений в сфере управления. К системам OLAP можно отнести:

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

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

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

Основателем данной концепции является Билл Инмон (1992 г. в книге «Создание хранилища данных» определил хранилище данных так – «предметно-ориентированный, интегрированный, неизменный и поддерживающий хронологию набор данных, предназначенный для поддержки принятия решений»).

Всем хранилищам данных присущи следующие свойства:

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

2. Интегрированность. Исходные данные извлекаются из систем оперативной обработки, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (т.е. вычисляются суммарные показатели) и загружаются в хранилище.

3. Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные накапливаются в хранилище в виде «исторических слоев», каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции развития.

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

Системы управления базами данных фактографических АИС.

История СУБД как особого вида программного обеспечения неразрывно связана с историей начала использования электронно-вычислительных машин для организации хранения и обработки информации. Именно в то время (конец 60-х, начало 70-х годов) были разработаны основы программного обеспечения для создания и эксплуатации фактографических информационных систем. В конце 70-х, начале 80-х годов направление программного обеспечения под общим названием «СУБД» превратилось в одну из наиболее бурно развивающихся отраслей программной индустрии. При этом основные программно-математические и технологические решения по СУБД были разработаны в 70-х годах в ряде крупных исследовательских проектов. Наиболее известными из них являются проект «Рабочей группы по базам данных» КОДАСИЛ (DBTG CODASYL) с участием уже упоминавшегося Ч. Бахмана, пионерские работы основателя теории реляционных баз данных Е. Кодда, проект разработки системы управления реляционными базами данных «System R» фирмы IBM (1975-1979 гг.) и проект разработки СУБД «Ingres» (Interactive Graphics and Retrieval System) в университете Беркли (1975-1980 гг.) под руководством известного специалиста в области баз данных М. Стоунбрейкера.

1.2. Внутренняя схема баз данных фактографических систем.

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

Рис. 1. Cocтав внутренней схемы базы данных.

Центральным компонентом внутренней схемы являются информационные массивы, включающие собственно данные (информационных объектов логической схемы БД, т.е. в реляционных СУБД таблиц), и массивы индексов, являющихся специальными дополнительными конструкциями для ускорения доступа к данным основных информационных объектов.

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

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

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

1.3. Проектирование банков данных фактографических АИС.

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

Рис. 2. Соотношение понятий БнД, СУ БД и БД.

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