
- •Вопрос 4. Состав стадий и этапов канонического проектирования.
- •2 Этап: Описание бизнес архитектуры организации.
- •3 Этап: Анализ моделей (описаний)
- •4 Этап: Собственно реинжиниринг
- •4 Обзор систем автоматизированного проектирования кис
- •12. Файл-серверная архитектура.
- •Case-технологии и case-средства. Модели as-is и to be
- •Основные понятия и классификация case-технологий. Функционально-ориентированное и объектно-ориентированное проектирование ис.
- •Вопрос 19. Моделирование потоков работ в нотации idef3
- •22. Создание логической и физической модели ис с помощью Data eRwin Modeler.
12. Файл-серверная архитектура.
Самой простой архитектурой для реализации является архитектура "файл-сервер", но она же обладает и самым большим количеством недостатков, ограничивающих спектр решаемых ею задач. Простейшим случаем является случай, когда данные располагаются физически на том же компьютере, что и само приложение.
К существенным неудобствам, возникающим при работе с системой, построенной по такой архитектуре, можно отнести следующее:
- трудности при обеспечении непротиворечивости и целостности данных;
- существенная загрузка локальной сети передаваемыми данными;
- в целом, невысокая скорость обработки и представления информации;
- высокие требования к ресурсам компьютеров. При этом возникают следующие ограничения.
- невозможность организации равноправного одновременного доступа; пользователей к одному и тому же участку базы данных;
- количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС, построенной в соответствии со спецификацией 10BaseT (скорость обмена данными до 10Мб/с);
При всем этом система обладает одним очень важным преимуществом - низкой стоимостью.
Архитектура "файл-сервер" предусматривает концентрацию обработки на рабочих станциях. Основным преимуществом этого варианта является простота и относительная дешевизна. Подобное решение приемлемо, пока число пользователей, одновременно работающих с базой данных, не превышает 5-10 человек. При увеличении количества пользователей система может "захлебнуться" из-за перегруженности ЛВС большими потоками необработанной информации.
Сервер, как правило, — самый мощный и самый надежный компьютер. Он обязательно подключается через источник бесперебойного питания, в нем предусматриваются системы двойного или даже тройного дублирования. В особо ответственных случаях можно подключить вместе несколько серверов так, что при выходе из строя одного из них в работу автоматически включится "дублер". Таким образом, при концентрации обработки данных на сервере надежность системы в целом ограничивается только материальными средствами, которые заказчики готовы вложить в техническое оснащение.
Решение по автоматизации учета и управления в корпоративных структурах предполагает распределенную обработку данных, организацию параллельных вычислений, глубокое разграничение уровней доступа, возможность выбора различных операционных систем и серверных платформ. Если бизнес не велик, подобное решение оптимально.
В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями.
Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения. Эта возможность облегчается тем обстоятельством, что у локальных СУБД база данных — понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности - как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые - нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики - это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос, должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для "ремонта" испорченных файлов настольных СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер базы данных (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных - как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа - сервер БД (SQL-сервер), поставляемый разработчиком СУБД.
13. Понятие информационного хранилища. Подсистема хранения данных. Подсистема метаинформации (репозиторий).
Информационное хранилище (Data Warehousing) — это место хранения данных предприятия, предназначенное для упрощения принятия управленческих решений. Информационное хранилище включает в себя не только данные, но также инструменты, процедуры, обучение, персонал и другие ресурсы, облегчающие доступ к данным и делающие его более осмысленным для лиц, принимающих решения. Назначение информационного хранилища состоит в увеличении ценности информационных активов предприятия . Роль информационного хранилища заключается в том, чтобы хранить выдержки из рабочих данных и выдавать их пользователям в удобном формате. Это могут быть как выдержки из базы данных и файлов, так и отсканированные образы документов, записи, фотографии и другие данные. Информационные хранилища служат для хранения, комбинирования, агрегирования, преобразования и доставки данных пользователям с помощью средств анализа и принятия решений, таких как OLAP. Информационное хранилище считается новым этапом представления данных в рамках современных бизнес-процессов. Концепция информационных хранилищ предложена в 1990 году Уильямом Инмоном. По Инмону информационное хранилище – есть предметно-ориентированный, интегрированный, неизменный, поддерживающий хронологию набор данных, предназначенный для поддержки принятия решений. В этом определении соединены две различные функции:
–сбор, организация, подготовка данных для анализа в виде постоянно наращиваемой базы данных;
–анализ, как элемент принятия решений. Назначение информационного хранилища заключается в следующем:
–интеграция данных в масштабе бизнес-процессов;
–функционально-стоимостной анализ эффективности бизнес-процессов;
–сложные аналитические запросы в разрезах: виды услуг, клиенты, регионы, технологии;
–анализ данных в динамике и в сравнении с показателями отрасли.
Основная цель информационного хранилища – сделать все значимые для управления бизнесом данные доступными в стандартизованной форме, пригодными для анализа и получения необходимых отчетов.
Подсистема хранения данных
Подсистема хранения данных отвечает за хранение, изменение и ввод данных о параметрах технологического процесса в форме, удобной для дальнейшего использования при расчете.
Многомерное хранилище данных может быть организовано в виде одной из следующих структур:
∙ физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружаются данные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным инструментальным средством, поддерживающим MOLAP, являются Oracle Express (Oracle), Power Play (Cognos Corp), DataDirect (INTERSOLV);
∙ виртуальной структуры, называемой ROLAP (Relational OLAP), которая динамически используется при запросах, вызывающих физическое манипулирование с файлами-источниками из реляционных баз оперативных данных (формирование ответа на запрос к ИХ "на лету"). ROLAP - система рассматривается просто как надстройка над реляционными базами данных, обеспечивающая удобный интерфейс пользователя. Типичными инструментальными средствами, поддерживающими ROLAP, являются MetaCube (Informix), Business-Objects (BusinessObjects) и др.;
∙ гибридной структуры, называемой HOLAP (Hybrid OLAP), которая используется при построении многоуровневых информационных хранилищ, применяемых на разных уровнях управления больших корпораций. Типичным инструментальным средством, поддерживающим HOLAP, является SAS System (SAS Institute).
Сравнительный анализ применения MOLAP и ROLAP хранилищ представлен в табл. 12.4.
Анализ параметров использования MOLAP и ROLAP информационных хранилищ показывает, что внедрение и эксплуатация ROLAP - систем являются более простыми и дешевыми по сравнению с MOLAP - системами, но уступают последним в эффективности оперативного анализа данных.
Т а б л и ц а 12.4 Сравнительный анализ применения MOLAP и POLAR ИХ
Параметры |
MOLAP |
ROLAP |
Объем хранилища
|
10-50 Гбайт |
Неограничен |
Требования к серверу |
Специализированный OLAP ─ сервер с высоким быстродействием |
SQL - сервер |
Скорость доступа к хранилищу |
Не зависит от транзакции оперативной обработки данных |
Зависит от транзакции оперативной обработки данных |
Скорость ответа на запрос |
Не зависит от структуры данных |
Зависит от числа обрабатываемых таблиц |
Кроссмерные функции над показателями (формулярные показатели) |
Встроены |
Ограничены |
Обновления данных |
С определенной периодичностью |
По мере возникновения |
Реорганизация (модификация состава показателей и измерений) |
Пересоздания и перезагрузка хранилища |
Реструктуризалия отдельных таблиц |
Специализация измерений для показателей |
Разреженный для всех измерений гиперкуб или специализированные поликубы |
Динамическое представление размерности |
Подсистема метаинформации (репозиторий)
Репозиторий представляет собой описание структуры информационного хранилища: состава показателей, иерархий агрегации измерений, форматов данных, используемых функций, физического размещения на сервере, прав доступа пользователей частоты обновления.
Важнейшей функцией репозитория является представление схем отображения структуры данных файлов-источников на структуре данных ИХ, в соответствии с которой осуществляется периодическая загрузка MOLAP-хранилища или непосредственная реализация запросов "на лету" в ROLAP-хранилищах.
В репозиторий задается также схема отображения структуры ИХ на схемах представлений данных пользователей или витринах данных. Через репозиторий осуществляется интерпретация запросов к ИХ на проведение оперативного анализа данных.
Отображение данных между источниками данных и ИХ, ИХ и представлением данных осуществляется либо через механизм межуровневого взаимодействия, либо через процедуры преобразования данных.