Программная реализация базы данных

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

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

Рис. 2. Таблица «Лекарственные препараты»

Для освоения навыков использования различных функций MS Access при построении таблицы «Группы товаров» воспользуемся конструктором таблиц. С помощью конструктора можно формировать сколь угодно сложные таблицы с полями любого типа.

Заполним поля «имя поля», «тип данных», «описание» в соответствии с разработкой в разделе «структура таблиц».

Рис. 3. Группы товаров

Установим связь между таблицей «Группы товаров» и таблицей «Лекарственные препараты». Выберем команду Сервис > Схема данных. Установим связь между полем «ключ группы» таблицы «Группы товаров» и полем «группы товаров» таблицы «Лекарственные препараты».

Такая связь позволяет установить правила взаимодействия между таблицами.

Для создания запроса наличия лекарственных препаратов по группам товаров воспользуемся режимом конструктора. Установим min и max по срокам выпуска лекарств и групповой операцией Count для обработки всех записей из таблицы «Лекарственные препараты» соответствующих данной группе товаров из таблицы «Группы товаров». Установим сортировку согласно алфавиту (т.е. по возрастанию).

Благодаря этому запросу мы видим наличие количества наименований препаратов данной группы товаров, а так же по min и max дате выпуска мы косвенно можем предположить насколько давно поступила данная продукция и насколько она востребована.

В то время как таблицы и запросы позволяют отобразить на экране длинные списки записей, формы дает возможность сосредоточиться на конкретной записи. Форма облегчает ввод, редактирование и восприятие информации, может содержать вспомогательные подписи и элементы оформления. Для облегченного и быстрого создания формы воспользуемся функцией «Создание формы с помощью мастера». Мастер форм позволяет сберечь время и быстро сконструировать привлекательную форму для записей таблицы «Лекарственные препараты».

Рис. 4. Форма «Лекарственные препараты»

Рис. 5. Создание отчета в режиме конструктора

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

Воспользуемся функцией «Создание отчета с помощью мастера». Для удобного восприятия информации о лекарственных препаратах выберем поля: группы товаров (из таблицы «Группы товаров»), а также наименование товара, фирма производитель, год выпуска, формы выпуска, примерная цена (из таблицы «Лекарственные препараты»). Получим удобную форму «Отчеты» для вывода информации о лекарственных препаратах на принтер и визуального восприятия без излишней (бесполезной) информации.

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

Заключение

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

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

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

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

В окне базы данных можно работать со всеми её объектами. Для просмотра объектов определённого типа следует выбрать соответствующую вкладку. С помощью кнопок можно открывать и изменять существующие объекты и создавать новые.

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

ИНФОРМАЦИОННО-АНАЛИТИЧЕСКАЯ СИСТЕМА ВУЗА. АНАЛИТИЧЕСКАЯ ОБРАБОТКА ДАННЫХ, ЕЕ КОНЦЕПЦИИ И ТЕХНОЛОГИИ

Титова Г.С. ¹

1. Юго-западный государственный университет

Резюме | Abstract | PDF (146 K)

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

К основным задачам ИАС можно отнести: эффективное хранение, обработка и анализ данных. В ходе исследований и разработок накоплен богатый опыт в этой области.

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

Архитектура типичной ИАС в общем виде представлена на рисунке 1.

Рисунок 1. Архитектура информационно-аналитической системы

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

1. Хранилища данных, или Склады данных (Data Warehouse) [6, 2];
2. Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP) [5, 3, 4, 10];
3. Интеллектуальный анализ данных (ИАД) (Data Mining)) [7, 8, 9,1].

Технологии OLAP плотно взаимодействуют с другими технологиями, такими как: хранилища данных (Data Warehouse) и методы интеллектуальной обработки (Data Mining). Исходя из этого, оптимальный вариант - комплексный подход в процессе их внедрению.

Изучением указанной проблемы занимается ряд ведущих университетов и научно-исследовательских институтов России: СФУ г. Красноярск, СибГТУ, СибГАУ, КНЦ СО РАН, СибНИИ охотничьего хозяйства, Институт вычислительного моделирования СО РАН.

В статье предложена ИАС для управления учебным процессом ВУЗа.

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

Созданный по технологии OLAP программный продукт «Информационно-аналитическая программа "Выбор"» (сокращенно «Выбор») состоит из следующих компонентов (рисунок 2).

Рисунок 2. Структура программного продукта «Информационно-аналитическая программа "Выбор"»

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

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

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

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

Рисунок 3. Интерфейс пользователя

Информация отображается в форме таблиц. Предусмотрена возможность выбора таблиц при помощи кнопок управления (рисунок 4).

Рисунок 4. Просмотр информации в программе

Анализ информации может проводиться даже неквалифицированным в вопросах эксплуатации компьютера пользователем.

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

Механизм выполнения запроса осуществляется программным продуктом без вмешательства пользователя, т.е. по средствам программирования на языке SQL.

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

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

В отчетах предусмотрены функции «Экспорт» и «Печать».

Функция «Экспорт». Данная функция позволяет сохранять сформированные отчеты либо в текстовом формате, либо в формате HTML-страницы. Сохранение отчета в формате HTML-страницы позволяет хранить отчеты на сайте вуза для быстрого доступа к ним лиц, принимающих решение.

Функция «Печать». Эта функция позволяет выводить сформированный отчет на бумажный носитель. Имеется возможность настройки печати.

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

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

Хранилища данных и задачи прогнозирования

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

Давайте рассуждать на уровне обычной логики. В августе, сентябре, октябре вы продали 10000 единиц какого-либо товара. Что нам говорят эти данные? Это хороший или плохой результат? Однозначно на этот вопрос ответить невозможно. Во-первых, нужно учитывать сезонность, во-вторых, состояние рынка, в-третьих, действия конкурентов и так можно продолжать еще долго: цена, реклама, изменение законодательства... Если человек не может дать ответ на, казалось бы, достаточно простой вопрос, что стоит ждать от машины. Можно возразить, что эксперты дают прогнозы, основываясь на этих данных, но эти возражения не выдерживают критики. Эксперт всегда имеет много, пусть и не формализованной, дополнительной информации. Это называется опытом работы. В случае применения какого-либо математического метода у нас этих данных нет. Не нужно забывать еще и о различного рода аномальных выбросах и провалах. Эксперт, зная, что происходило в это время, будет или не будет принимать эти сведения в расчет при прогнозировании объемов продаж.

Фундаментальная проблема заключается в том, что информации об истории продаж – то, на основе чего чаще всего предлагается прогнозировать, совершенно недостаточно для сколько-нибудь качественного прогноза. Конечно, можно прогнозировать и имея только эти данные, но это больше напоминает гадание на кофейной гуще. Сведения об объемах продаж, конечно, нужны, но они дают максимум 30% от необходимой информации. Фактически они описывают только то, что произошло внутри организации, и то не в полном объеме. А то, что произошло в это время на рынке, практически игнорируется. В то время, как влияние внешних факторов очень велико, в некоторых случаях и решающее.

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

1. Историю продаж;

2. Состояние склада на каждый день. Может быть, не было продаж из-за отсутствия товара на складе, а вовсе не из-за отсутствия спроса;

3. Сведения о ценах конкурентов;

4. Изменения в законодательстве;

5. Общее состояние рынка;

6. Курс доллара, инфляция;

7. Сведения о рекламе;

8. Сведения об отношении к вашей продукции клиентов;

9. Различного рода специфическую информацию. Например, для продавцов мороженого – температуру, а для аптечных складов – санитарно-эпидемиологическую обстановку;

и многое другое.

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

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

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

Создание хранилища – данных довольно утомительное и дорогое занятие, но вариантов не очень много. Как говорится, "если вы считаете, что образование это – слишком дорого, попробуйте, почем невежество".

Главная страница > О компании > Публикации РДТЕХ в прессе Описание решения: Выбираем решение по созданию единого хранилища данных в банке Анатолий Волков, директор Центра финансовых решений РДТЕХ, Евгений Пустозёров, консультант Центра финансовых решений РДТЕХ. (Обзор CNews "ИТ в банках и страховых компаниях 2011", октябрь, 2011 год) Сегодня банки понимают необходимость и ценность консолидированного решения для сбора, обработки и анализа данных на основе корпоративного информационного хранилища. Компания РДТЕХ предлагает комплексное решение, в рамках которого необходимые банку функциональные модули (системы обязательной и управленческой отчётности, финансового планирования и бюджетирования, оценки рисков) создаются на основе единого, корпоративного хранилища данных на базе технологий Oracle и Informatica. На современном этапе развития бизнеса средние и крупные банки вышли на новый уровень, при котором одним из важнейших конкурентных преимуществ является скорость и качество обработки накопленных данных, а также возможность их разностороннего анализа. С одной стороны, финансовой организации необходимо соответствовать требованиям национального законодательства по обязательной отчётности, с другой стороны, международный характер современного банковского бизнеса все более подвигает российские банки к международным стандартам работы и технологического развития. Вместе с тем, для руководства финансовой организации важна возможность в любой момент времени составить единую информационную картину работы всех подразделений банка, которая позволит корректно отслеживать показатели доходности в различных разрезах: клиент, продукт, канал продаж, центр финансовой ответственности и т.д. Тенденция решать все эти задачи точечно, на уровне отдельных департаментов и подразделений, при помощи различных систем осталась в прошлом: сегодня банки понимают необходимость и ценность консолидированного решения для сбора, обработки и анализа данных на основе корпоративного информационного хранилища (далее КИХ). При выборе поставщика единого корпоративного хранилища данных необходимо принимать во внимание, что решения, предлагаемые крупными западными вендорами, помимо очевидных плюсов - использования проверенных лучших практик для финансовой отрасли, упрощения процессов интеграции банка в мировую систему финансовой коммуникации - обладают и существенным недостатком, а именно, не учитывают специфику национального законодательства, которое в России и странах СНГ значительно отличается от западного. Понимая все эти трудности, компания РДТЕХ использует комплексный подход, в рамках которого необходимые банку функциональные модули (системы обязательной и управленческой отчётности, финансового планирования и бюджетирования, оценки рисков) создаются на основе единого, консолидированного корпоративного хранилища данных. При этом хранилище строится при помощи передовых технологий крупнейших вендоров: Oracle и Informatica, на основе типовой логической модели, разработанной специалистами РДТЕХ под специфику национальных банков России и стран СНГ. Особое внимание при построении хранилища уделяется процессу сбора, очистки, верификации данных. Грамотное построение процесса загрузки информации в хранилище гарантирует использование полных, непротиворечивых, актуальных данных при построении любых видов отчётности (как обязательной, так и управленческой), анализе рисков, планировании и бюджетировании. Системная архитектура корпоративного хранилища данных Решение "Система корпоративной и обязательной отчетности финансового института на основе единого хранилища данных" РДТЕХ представляет собой не просто хранилище данных, консолидирующее информацию из банковских систем-источников, это комплексное решение, состоящее из набора модулей, каждый из которых обладает определенной функциональностью (см. Рис. 1). Системные модули: модуль "Загрузка данных" (ETL): предназначен для извлечения, трансформации, консолидации, проверки и приведения к единому формату информации, находящейся в автоматизированных системах банка; модуль "Безопасность": предназначен для управления правами доступа пользователей к КИХ; модуль "Рабочее хранилище данных" (далее РХД): содержит типовую банковскую модель, предназначенную для накопления и постоянного хранения сделочной информации, а также данных бухучета, клиентских данных и нормативно-справочной информации (НСИ). Функциональные модули - "Обязательная отчётность ЦБ", "Налоговая отчётность", "Отчётность МСФО","Управленческая отчётность", "Анализ рисков" и др. - являются витринами данных и используют в своей работе очищенные и консолидированные данные из РХД. Функциональные модули, в отличие от системных, предназначены для решения конкретных задач анализа данных и построения отчётности, которые ежедневно возникают у бизнес-подразделений банка. Концептуальная схема корпоративного хранилища данных РДТЕХ Модуль "Загрузка данных (ETL)" Системный модуль "Загрузка данных (ETL)" решает первоочередную задачу - создание единого источника унифицированной, консолидированной информации, объединяющего все разнородные, нередко дублирующиеся или неполные данные, хранящиеся в различных системах-источниках банка. Таким образом, хранилище данных становится единственным источником для заведомо правильной чистой информации, структурированной в единую типовую банковскую модель, позволяющую использовать данные для всестороннего анализа и формирования аналитической, обязательной и специализированной отчётности банка. Основными функциональными блоками данного модуля являются: ETL-средство Средство получения и преобразования данных из различных систем-источников, единая платформа интеграции данных, которая позволяет получать доступ и проводить интеграцию данных любого формата, из любых источников и доставлять их в хранилище с высокой скоростью. Обычно в качестве ETL-средств в решении РДТЕХ используются продукты Informatica PowerCenter или Oracle Data Integrator. Оперативный склад данных КИХ (Stage-область) Промежуточная область хранения загруженных данных. В этой области выполняется очистка, верификация данных и приведение их к единому формату хранения в РХД. Блок верификации данных Совокупность средств, выполняющих проверку корректности загружаемых данных. Рабочее хранилище данных (РХД) Область хранения очищенных и консолидированных данных, загруженных из оперативного склада данных КИХ. Интерфейсы управления Интерфейсы управления - набор автоматизированных рабочих мест (АРМ), позволяющих осуществлять управление модулем "Загрузка данных". Информация из систем-источников банка с помощью промышленного ETL-средства попадает в Stage-область, где происходит консолидация данных, очистка, верификация, приведение к формату типовой банковской логической модели, на базе которой строится рабочее хранилище данных. Загрузка данных из систем-источников банка в РХД может происходить в следующих режимах: Инициализирующая загрузка данных. Выполняет первичное наполнение хранилища данными, при этом происходит создание начальной сальдовой точки. Регламентная загрузка данных. Производится в ночное время, выполняет загрузку изменений данных справочников и данных-фактов за предыдущий операционный день. Исправительная загрузка (перезагрузка) данных. Даёт возможность перезагрузки данных за определённый период времени в прошлом. Например, перезагрузка справочных данных приводит к частичной замене истории изменений справочника за период, пересекающийся с периодом перезагрузки по тем данным, которые подвергаются перезагрузке. Порядок обработки данных в ходе работы модуля "Загрузка данных" Порядок обработки данных состоит из пяти последовательных фаз, каждая из которых выполняет соответствующие преобразования данных (см. Рис. 2). Порядок обработки данных 1. Загрузка данных из системы-источника (PHASE_01). На данной фазе происходит копирование определенного набора данных из системы-источника банка в Stage-область и его подготовка для дальнейшего преобразования. 2. Формирование глобальных ключей (PHASE_02). На данной фазе происходит формирование глобальных идентификаторов записей справочников. Для каждой сущности значение глобального ключа однозначно определяет элемент сущности. Алгоритм формирования глобального ключа зависит от нескольких факторов: типа загружаемой сущности, типа первичного ключа в источнике, системы-источника, из которого производится загрузка и т.д. 3. Поиск изменений относительно текущего состояния РХД (PHASE_03). o Определение новых и измененных записей в источнике; o Определение удаленных строк в источнике. 4. Преобразование и подготовка данных для загрузки в РХД (PHASE_04). На данной фазе происходит формирование строк загружаемой сущности в том виде, в котором они будут храниться в РХД. Для этого на основе исходной постановки задачи по загрузке выполняется привязка атрибутов таблицы системы-источника и атрибутов таблицы РХД (возможно, с использованием необходимых преобразований); определение и простановка условий соединения с зависимыми таблицами РХД; вычисление хеш-значения загружаемых атрибутов. 5. Загрузка данных в РХД (PHASE_05). o Загрузка в РХД структур, содержащие актуальные данные.Вставка новых записей и обновление уже существующих данных в актуальном срезе загружаемой структуры. o Загрузка данных в исторические таблицы. Загрузка данных в таблицу с поддержкой истории изменений по всем значимым (т.е. не служебным) полям загружаемой структуры. Типы загрузки При загрузке можно выделить следующие типы загрузки данных: загрузка таблиц-справочников, при которой используются все фазы, описанные выше; загрузка таблиц-фактов, при которой могут быть пропущены следующие фазы из описанных выше: PHASE_02; PHASE_03; PHASE_05H. Проверка качества данных Основными задачами ETL-процесса являются изъятие информации из источников банка, их фильтрация, выявление изменений, очистка, верификация, преобразование в единый формат, загрузка в рабочее хранилище с поддержкой истории, агрегация. Одним из важнейших этапов, влияющих на работу всех функциональных модулей КИХ, является процесс верификации данных, их проверки. Работа с данными, прошедшими процесс проверки, гарантирует достоверность построения любых видов отчётности. В корпоративном информационном хранилище РДТЕХ механизм отслеживания качества данных, загружаемых в хранилище, автоматизирован, проверки данных проходят на различных этапах их загрузки и использования (см. рис 3). Модуль верификации данных, являющийся универсальным, реализуется процедурами, зарегистрированными в специальном справочнике правил верификации. Проверка данных может осуществляться как на уровне одной строки, так и на уровне таблицы. Набор правил верификации является гибким, расширяемым и может изменяться в процессе эксплуатации модуля. Концептуальная модель потока данных с зонами покрытия проверками данных Проверки данных выполняются автоматически при движении информации по всем потокам, передающим данные от системы-источника до витрины. Потоки данных характеризуются следующими параметрами: период, за который происходит загрузка; источник данных - совокупность первичных данных в одном формате с единой кодификацией данных (первичных ключей и связей) и НСИ; режим загрузки - разновидности загрузки: инициализирующая, регламентная или исправительная. Проверки выполняются автоматически при движении данных по всем потокам в следующих ключевых местах: 1. Точка выполнения технических проверок над данными (фаза PHASE_01B_DIRTY процесса загрузки данных). Проверки запускаются после того как осуществлён захват данных из источника и данные размещены в оперативном складе (Stage-область) без трансформации. На данном этапе выполняется первичная верификация загружаемых данных: проверка форматов полей, типов данных, обязательности их заполнения и т.д. 2. Точка выполнения технических проверок над данными (фаза PHASE_04B_DIRTY процесса загрузки данных). Проверки запускаются после преобразования (трансформации) данных к единому виду РХД. На этот этап поступает только часть данных (новые и изменённые) за период загрузки. Выполняется верификация данных на предмет уникальности записей, ссылочной целостности и соответствия данных формату РХД. 3. Точка выполнения бизнес-проверок. Проверки выполняются над данными, размещенными в РХД. На данном этапе обрабатываются все данные за период. Основные проверки данного этапа - бухгалтерские и функциональные. Например, проверка остатков и оборотов активных счетов в рублях и валюте, контроль баланса, сверка графика погашения кредитов и остатков на ссудных счетах и т.д. Точка выполнения бизнес-проверок. Проверки выполняются над данными, размещёнными в витрине данных. На этом этапе обрабатываются все расчетные данные за период. Выполняется итоговая верификация данных перед их дальнейшим анализом и построением отчётов. Проверяется соответствие загруженных и рассчитанных данных требованиям функциональных модулей. Функционал модуля верификации данных позволяет на регулярной основе автоматически проводить проверки качества данных и в оперативном режиме предоставлять результаты проверок в виде отчётов для пользователей, ответственных за исправление ошибок. Модуль "Рабочее хранилище данных (РХД)". Типовая модель данных РДТЕХ для банков. На основании большого опыта работы в области построения хранилищ данных для отечественных и зарубежных финансовых организаций, специалисты РДТЕХ разработали типовую банковскую модель данных, описывающую все бизнес-процессы банка в их взаимосвязи. Данная модель лежит в основе РХД и обеспечивает единую основу для подготовки всех видов банковской отчётности, бюджетирования, планирования, расчёта рисков и других бизнес-задач. Типовая модель данных корпоративного хранилища состоит из следующих компонентов: Логическая модель. Представляет собой наборы взаимосвязанных сущностей, соответствующих по уровню детализации понятиям первичного учёта банковской предметной области. Сущности логической модели группируются в такие бизнес-области, как Субъекты, Бухгалтерия, Кредитные сделки, Депозитные сделки, Банковские карты и другие; Физическая модель. Отображает логическую модель на уровне таблиц (и других объектов) базы данных Oracle; Глоссарий модели. Описывает в бизнес-терминах определения всех атрибутов/сущностей логической модели. Одними из главных преимуществ использования типовой модели данных являются учёт специфических требований национальных законодательств в области отчётности, наличие полного описания всех типовых бизнес-процессов банка на русском языке, увеличение скорости внедрения решения за счёт его унификации, возможность масштабирования и развития решения в соответствии с новыми бизнес-задачами. Кроме того, детально проработанный глоссарий модели позволяет обеспечить единую терминологическую базу для всех участников проекта: бизнес-пользователей, технологов банка, разработчиков системы. В терминах глоссария формируются требования к системе, составляется техническое задание, описывается каждая сущность бизнес-процесса и осуществляется её привязка к соответствующей сущности источника данных, что обеспечивает однозначность интерпретации всех проектных документов. Описание взаимосвязей между различными сущностями логической модели реализовано при помощи технологии визуализации - продукта Oracle Designer - что позволяет значительно облегчить процесс описания модели, внесения изменений и поддержку их версионности. При помощи данной технологии всегда возможно отследить, как та или иная сущность логической модели связана с физической моделью или системой-источником, т.е. перейти от конкретной сущности логической модели к соответсвующей ей таблице в рабочем хранилище данных или определённому набору данных источника, содержащего первичную информацию. В репозитории Oracle Designer легко проанализировать источники данных в различных разрезах при помощи отчётов, например, наборы загруженных в КИХ данных и их качество. Отчёты по логической модели строятся на базе продукта Oracle Business Intelligence Publisher и экспортируются в различные форматы - XML, RTF, PDF, XLS и HTML - что делает типовую модель данных ещё более удобной в использовании. Типовая банковская модель РДТЕХ успешно используется в реальной практике внедрения хранилищ данных в коммерческих банках России и стран СНГ. Функциональные модули хранилища данных На основании собранной в системах-источниках проверенной информации, трансформированной согласно логической модели, производится наполнение функциональных модулей - витрин данных, которые завершают работу комплексного решения по хранению и анализу данных в банке. Благодаря тому, что все прикладные модули используют единую модель данных хранилища, вобравшую в себя международный опыт в области банковских хранилищ данных и аналитических систем, приложения наследуют гибкость и масштабируемость, заложенные в модель. В комплексном решении РДТЕХ реализованы основные функциональные модули, необходимые для эффективной деятельности банка: Модуль "Обязательная отчётность для ЦБ"; Модуль "Налоговая отчётность"; Модуль "Отчётность МСФО"; Модуль "Управленческая отчётность"; Модуль "Анализ рисков"; Модуль "Финансовое планирование и бюджетирование". Внедрение прикладных модулей позволяет автоматизировать большинство банковских процессов, увеличить скорость и качество подготовки обязательной и управленческой отчётности, расширить возможности по построению систем бюджетирования и планирования, анализа доходности различных направлений бизнеса. О компании: Компания РДТЕХ успешно работает на рынке информационных технологий с 1992 года. РДТЕХ предлагает комплекс услуг для финансовых институтов - разработку заказных систем на базе программных продуктов ведущих мировых производителей, лидеров рынка корпоративного обеспечения - Oracle, i2, внедрение бизнес-приложений Oracle, в том числе специализированных решений на платформе отраслевого бизнес-приложения Oracle Financial Services Analytical Applications (OFSAA), консалтинг, продажу лицензий и технической документации, авторизованное обучение и техническую поддержку ПО Oracle

В самом начале определение Хранилища данных было простым. Согласно нему (а оно актуально до сих пор), Хранилище данных - это набор данных, которые являются:

· предметно-ориентированными,

· интегрированными,

· не изменяющимися во времени,

· долговременными,

и предназначены для принятия решений руководством.

Кроме того, стало очевидным, что Хранилища данных являются структурированными. Они содержат базовые данные, которые образуют единый источник для обработки данных во всех системах поддержки принятия решений (decision support system, DSS). Если возникают разногласия во мнениях, с помощью Хранилища данных можно выполнить согласование информации. А элементарные данные, присутствующие в Хранилище, могут быть представлены в различной форме, отвечая не только известным требованиям, но еще и неизвестным.

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