2. Таблицы измерений

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

     Каждая  таблица измерений должна находиться в отношении «один ко многим»  с таблицей фактов.

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

     Пример  таблицы измерений приведен в приложении Г.

     Одно  измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Пример схемы приведен в Приложении Б.

     Если  же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). Пример схемы «снежинка» приведен в приложении Д.

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

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

     Еще один пример отступления от правил - наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий - иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней пример такой таблицы приведен на рисунке в приложении В. [7, с.24].

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

     Следует отметить, что для создания реляционных  хранилищ данных нередко применяются  специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Примером такого продукта является Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах (не по строкам, а по столбцам). Однако создавать хранилища можно и в обычных реляционных СУБД.

2. Аналитические системы

2.1 Создание информационно-аналитических систем

     Основой современной индустрии программных  средств и решающим фактором успеха при создании информационно-аналитических  систем является технология их создания. Информационно-аналитические системы – это особый класс информационных систем, предназначенных для аналитической обработки данных, а не для автоматизации повседневной деятельности организации. Информационно-аналитические системы объединяют, анализируют и хранят как единое целое информацию, извлекаемую как из учетных баз данных организации, так и из внешних источников. Входящие в состав информационно-аналитических систем хранилища данных обеспечивают преобразование больших объемов сильно детализированных данных в обобщенную выверенную информацию, которая пригодна для принятия обоснованных решений. В отличие от обычных баз данных хранилища содержат обработанное, упорядоченное и понятное руководителям представление данных. Хранилище данных является сборочным конвейером по подготовке информации в интегрированном, непротиворечивом, наглядном виде для поддержки принятия управленческих решений [3, с.24].

     Создание  информационно-аналитических систем, реально отвечающих целям и задачам  организаций, представляет собой достаточно сложный процесс, включающий этапы формирования концепции, проектирования, разработки, внедрения и сопровождения. Сам характер этого процесса требует предварительной разработки достаточно жесткой фиксированной технологической схемы. Технологическая схема представляет собой в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99, описывающим процессы жизненного цикла программных средств, последовательность работ и задач, выполняемых определенными исполнителями.

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

     Технология  и методика создания информационно-аналитических  систем охватывает следующие виды деятельности:

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

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

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

• При определении адресных сведений следует придерживаться следующей структуры адреса: почтовый индекс, код населенного пункта по общестатистическому классификатору ОКАТО (урезанный до шести знаков, существенных для отдельной области), код улицы, номер дома, номер корпуса/строения, номер квартиры/помещения. Классификаторы улиц в настоящее время разрабатываются администрациями городов и должны интегрироваться на сервере областной администрации в едином адресаторе. В настоящее время разработан и поддерживается классификатор улиц города Иваново. Возможно использовать в качестве основы такого адресатора базу областной налоговой инспекции. Вместе с тем, правомерно областной адресатор курировать управлению архитектуры в рамках ведения градостроительного кадастра совместно с информационно-аналитическом центром областной администрации и распространять всем заинтересованным ведомствам для ведения своих реестров.
• Необходимо стремиться к соблюдению однозначной идентификации юридических и физических лиц в системе. В частности, информация по юридическому лицу или частному предпринимателю должна сопровождаться кодом ИНН. По физическому лицу предпочтительно иметь уникальный социальный номер, который может быть присвоен либо управлением внутренних дел на основе базы данных областного адресного бюро, либо налоговой инспекцией, учитывая опыт Башкортастана. В связи с отсутствием в области однозначной идентификации физических лиц по ним в базе необходимо иметь номер и серию документа удостоверяющего личность, дату и наименование органа, выдавшего документ.
• Желательно иметь на уровне области интегрированные хранилища сведений по юридическим и физическим лицам, определенная информация из которых может быть использована различными ведомствами в качестве соответствующих общесистемных справочников. Так на уровне информационно-аналитического центра администрации области должна вестись интегрированная база по юридическим лицам, которая объединяет сведения, собираемые регистрирующими органами администраций городов и районов, а также ряд вышеупомянутых ведомственных реестров. В настоящее время в администрациях крупных городов уже ведутся соответствующие базы данных, которые могут быть использованы в интересах ведения общего хранилища. Недостающую информацию можно получить из реестра областного комитета статистики. Уточнять информацию можно на основе открытых для публикации сведений реестра налогоплательщиков областной налоговой инспекции. Хранилище сведений по физическим лицам должно вестись на основе данных адресного бюро управления внутренних дел, а также областного отдела ЗАГС и, возможно, областной налоговой инспекции.
• Все сведения, которые могут быть сведены к перечислимому типу следует кодировать в системе на основе внутренних справочников. Так например, при описании конструктивных элементов зданий (материал и форма фундаментов, материал стен и перегородок, материал перекрытий, материал и тип крыши, материал проемов, внутренние санитарно-технические работы и электротехнические устройства) следует пользоваться внутрисистемными справочниками.
• Каждое зарегистрированное строение и помещение должно иметь уникальный в рамках области кадастровый номер, который будет однозначно идентифицировать его в региональной информационной системе, аналогично коду ИНН юридического лица или социальному номеру физического лица. Это может быть инвентарный номер БТИ или при его отсутствии реестровый номер КУГИ. По соответствующему инвентарному номеру в хранилище будет накапливаться динамика состояния объекта собственности. Аналогичным образом должны быть идентифицированы все ресурсы области [10, с.24].
• Каждая запись ведомственной базы данных в системе оперативной обработки информации должна сопровождаться служебной датой ее актуализации и признаком первичного ввода, корректировки сведений или прекращения существования. Эти сведения необходимы для обеспечения возможности последующего использования информации на уровне областных хранилищ.

     2.2 Области применения 

     Аналитические системы СППР позволяют решать три  основных задачи: ведение отчётности, анализ информации в реальном времени (OLAP) и интеллектуальный анализ данных.

     Отчётность.

     Сервис  отчётности СППР помогает организации  справиться с созданием всевозможных информационных отчетов, справок, документов, сводных ведомостей и пр., особенно когда число выпускаемых отчетов велико и формы отчётов часто меняются. Средства СППР, автоматизируя выпуск отчётов, позволяют перевести их хранение в электронный вид и распространять по корпоративной сети между служащими компании [8, с.24].

     OLAP

     Технология  комплексного многомерного анализа  данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент  организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром  Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

• предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
• возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
• многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
• многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);
• возможность обращаться к любой нужной информации независимо от ее объема и места хранения [4, с.24].

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

     OLAP (On-Line Analitycal Processing) - сервис представляет собой инструмент для анализа больших объемов данных в режиме реального времени. Взаимодействуя с OLAP-системой, пользователь сможет осуществлять гибкий просмотр информации, получать произвольные срезы данных, и выполнять аналитические операции детализации, свертки, сквозного распределения, сравнения во времени. Вся работа с OLAP-системой происходит в терминах предметной области [7, с.24].