Вопросы к госэкзамену

1. Жизненный цикл КИС. Этапы жизненного цикла КИС

2. Модели жизненного цикла КИС (бизнес-приложений)

3. Технологические процессы создания КИС

4. CASE-средства поддержки жизненного цикла КИС

5. Методы и средства структурного системного анализа и проектирования

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

7. Корпоративные информационные системы. Их структура. Примеры КИС

8. Информационная архитектура КИС. Назначение и состав. Методы и средства описания архитектуры данных

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

10. Архитектурные шаблоны (oltp, olap – системы) в информационной архитектуре предприятия

OLAP-системы

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence[1].

Основоположник термина OLAP — Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени».

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

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

Данная проблема эффективно решается с помощью информационно-аналитических систем, построенных на базе OLAP-техологий (другие названия: OLAP-система, Система бизнес-аналитики, Business Intelligence). OLAP-системы интегрируют уже существующие системы учёта, предоставляя пользователю инструменты для анализа больших объёмов данных в реальном времени, динамического конструирования отчётов, мониторинга и прогнозирования ключевых бизнес-показателей.

Преимущества OLAP-систем

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

Разработка каждого отчёта требует работы программиста.

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

Данные, получаемые от различных структурных элементов компании не унифицированы и часто противоречивы.

OLAP-системы, самой идеологией своего построения предназначены для анализа больших объёмов информации, позволяют преодолеть ограничения традиционных информационных систем.

Создание OLAP-системы на предприятии позволит:

• Интегрировать данные различных информационных систем, создав единую версию правды

• Проектировать новые отчеты несколькими щелчками мыши без участия программистов.

• В реальном времени анализировать данные по любым категориям и показателям бизнеса на любом уровне детализации.

Производить мониторинг и прогнозирование ключевых показателей бизнеса

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

Итоги внедрения OLAP-системы

Руководство получает полное ясное видение ситуации и единый механизм учёта, контроля и анализа.

За счёт автоматизации внутренних бизнес-процессов и повышения производительности сотрудников, уменьшается потребность в человеческих ресурсах.

Действие OLAP

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

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».

Вместе с базовой концепцией существуют три типа OLAP:

OLAP со многими измерениями (Multidimensional OLAP — MOLAP);

реляционный OLAP (Relational OLAP — ROLAP);

гибридный OLAP (Hybrid OLAP — HOLAP).

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

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

HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми

Реализации OLAP

Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией считается система Express, разработанная в 1970 году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database)[2]. Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году[3], в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor[4].

Другие известные OLAP-продукты: Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Аналитический комплекс ПРОГНОЗ[5].

C точки зрения реализации делятся на «физический OLAP» и «виртуальный» (реляционный, англ. Relational OLAP, ROLAP). «Физический», в свою очередь, в зависимости от реализации подразделяется на многомерный (англ. Multidimensional OLAP, MOLAP) и гибридный — (англ. Hybrid OLAP, HOLAP).

В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение. Примеры таких продуктов — Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.

Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной базе данных, а агрегаты — в многомерной.

В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов — SAP BW, Microstrategy Intelligence Server, Mondrian.

С точки зрения пользователя все варианты выглядят похожими по возможностям. Наибольшее применение OLAP находит в продуктах для финансового планирования, хранилищах данных, решениях класса Business Intelligence.

OLTP-системы (Системы оперативной обработки транзакций)

OLTP (Online Transaction Processing), транзакционная система — обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

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

Проблема целостности – в обеспечении правильности данных БД в любой момент времени. Она может быть нарушена в след случаях: 1. при вводе и обновлении, когда подаются неверные сведения. 2. когда данным пользуются одновременно несколько userов. 3. при сбоях АПС.

Решение проблем целостности надо рассматривать с программной и организационной точки зрения. Для ПОбл 1. надо ряд организац мероприятий (чтобы следили за вводом), user должен знать правила ввода и ограничения. Для проблем 2-3 – стандартные средства СУБД или спец программные модули. СУБД – 2 основных ограничения целостности: 1. структурные ограничения (задаются функциональными связями и проверяются путем проверки равенства значений БД) 2. ограничения реальных значений. Требуют, чтобы значения поля принадлежали некоторому диапазону , либо это зависимость между значениями некоторых полей. (типы данных и маски ввода). Ограничения могут задаваться АБД в любой момент, но СУБД может не принять ограничение (если много записей ему уже не удовлетворяют), если соответствие есть – записывается в словарь и используется. Ограничения различаются по уровню сложности:

1. ограничения на значение поля: (запрет ввода 0, запрет на диапазон, запрет список).

2. ограничения на совокупность атрибутов строки. ( должность – разрядные ставки, края – города).

3. ограничения одновременно на множество строк.

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

Должна обладать 4 свойствами: 1. Атомарность (неделимость): выполняется как одинарная операция доступа к БД, должна выполняться полностью или не выполняться совсем. 2. Согласованность – гарантирует взаимную целостность данных после окончания обработки транзакций. 3. Изолированность (каждая транзакция может изменять данное, которое временно находится в несогласованном состоянии). При этом доступ других транзакций к этим данным запрещен, пока транзакция не завершится. 4. долговечности – если транзакция выполнена успешно, то изменения не будут потеряны. Результатом выполнения транзакции может быть её фиксация (действие по фиксации изменений в БД) или откат (отмена транзакции и возврат БД в состояние до начала её). Механизм фиксации и откат основан на использовании журнала транзакций, где сохраняется состояние ДО (в нескольких итерациях) и ПОСЛЕ. Некоторые диалекты SQL включают операторы промежуточной фиксации (откат от точки к точке).

Мониторы обработки транзакций (Transaction Processing Monitor — TPM)— это программные системы (относят к посредническому или промежуточному программному обеспечению), решающие задачу эффективного управления информационно-вычислительными ресурсами в распределенной системе. Они представляют собой гибкую, открытую среду для разработки и управления мобильными приложениями, ориентированными на оперативную обработку распределенных транзакций. В числе важнейших характеристик TPM — масштабируемость, поддержка функциональной полноты и целостности приложений, достижение максимальной производительности при обработке данных при невысоких стоимостных показателях, поддержка целостности данных в гетерогенной среде. TPM опираются на трехзвенную модель "клиент-сервер"

На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), TUXEDO Sytem (Novell).

Совместное использование данных

При реализации транзакций возникает проблема: потеря обновлений (в БД фиксируется только изменения одного userа, остальные теряются). И 2 проблема – чтение незафиксированных данных. Для решения - спец механизмы обработки транзакций. Принципы: 1. транзакция не имеет доступа к незафиксированным данным. 2. результат совместного выполнения транзакций эквивалентен их последнему выполнению. Реализуется этот механизм через систему блокировок: СУБД блокирует часть БД, к которой обращается транзакция до момента её фиксации, т.е. 2-ю транзакцию надо поставить в очередь ожидания. Чем больше блокируемый элемент, тем медленнее обрабатывается транзакция. В системах OLTP обычно блокируется строка, при этом транзакции могут попадать в ситуацию взаимной блокировки. Для предотвращения СУБД периодически опрашивает блокировки и если такое есть, одна из транзакций прерывается. Для более удобной работы допускаются блокировки совместного использования данных: параллельно работающим userам запрещается изменять данные, но разрешается выборка их. Этот подход не единственный, можно, например использовать тиражирование данных в системах с распред доступом. Эта технология предполагает отказ от распределенности данных, и в каждом узле – своя копия БД. Средства, обеспечивающие это должны поддерживать согласованное состояние БД копированием изменений. Процесс переноса изменений исходной БД в БД отдельных узлов называется тиражированием данных. Эти функции выполняет определенный модуль (сервер тираж-я/ репликатор). Схема его работы – полное обновление содержимого БД на удаленных серверах (схема с полн обновлением) или обновление только изменяющихся данных (схема с быстрым обновлением) Если нет необходимости постоянно обновлять данные, то репликатор накапливает изменения и копир-т их в нужный момент.

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

Современные технологии БД предъявляют определенные требования в области архитектуры. До недавнего времени выделялось три класса задач:

• задачи оперативной обработки транзакций;

• задачи пакетной обработки;

• задачи принятия решений.

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

Системы OLTP характеризуются:

• поддержкой большого числа users;

• малым временем отклика на запрос;

• относительно короткими запросами;

• короткими транзакциями;

• участие в запросах небольшого числа таблиц.

Практически все запросы к базе данных в OLTP-системах состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.

Сервер оперативной обработки транзакций строится в предположении:

• OLTP- операции поддерживают большое число user;

• наиболее часто используются короткие простые транзакции;

• обычно транзакции не использую одинаковые данные;

• операторы обычно затрагивают небольшое число строк;

• время отклика - доли секунды;

• только несколько таблиц имеют большие размеры или могут быть изменены.

Реализация такого сервера опирается на:

• физические методики сокращений операций с дисками;

• обработку небольших объемов данных в памяти;

• примитивный оптимизатор запросов;

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