Концепции построения и реализации информационных систем

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

Роль метаданных в системах Хранилищ Данных

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

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

Таблица 4. Уровни метаданных в Хранилище  Данных

Вопросы защиты данных

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

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

В таких системах, часто оказывается недостаточно защиты обеспечиваемой в стандартных  конфигурациях коммерческих СУБД (обычно уровень защиты по классу “C2 Orange Book”.) Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но, для повышения эффективности доступа к данным, в целевой БД Хранилища Данных, все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого, является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс “B1 Orange Book”).

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

Большие объемы хранимых данных.

Когда мы говорим  о целевой БД Хранилища Данных, мы подразумеваем, что это нечто  очень большое (таблица 5). Но насколько  большое? Согласно данным Meta Group, уже  сегодня, около половины организаций  планируют Хранилища в 100 гигабайт и более. И уже известны реализации систем, с терабайтами данных.

Таблица 5. Классификация  Хранилищ Данных в соответствии с  объёмом целевой БД

Причём, когда  говорится, о 100 гигабайтах исходных данных, следует понимать, что реальное дисковое пространство, требуемое для реализации целевой БД, будет несколько больше. Для ответа на вопрос “Насколько больше?”, лучше всего посмотреть, что об этом думают сами фирмы производители СУБД.

Одним из показателей  недавно принятого теста TPC-D (новый  специализированный тест для систем DSS), является именно соотношение между  реальным объёмом исходных данных (длина  строки таблицы умножается на число  строк и так по всем исходным таблицам) и реальным объёмом используемого тесте дискового массива (таблица 6).

Таблица 6 Соотношение между реальным объемом  исходных данных и размером дискового  массива

Таким образом, средний коэффициент, на который  должен умножаться объём исходных данных для оценки реального необходимого для реализации системы объёма дискового пространства, равен 4.87 (для 100 гигабайтных тестов) и имеет тенденцию к возрастанию при увеличении объема исходных данных. Более того, как показывает тест DB2 для Windows NT, для того чтобы получить БД в несколько терабайт, может потребоваться всего несколько сот мегабайт исходных данных.

Естественно, цифры  из таблицы 6 не являются догмой. Более  того, здесь учитывается не только объём собственно БД, но, и пространство под операционную систему, различные  временные области, буфера и т.д. С другой стороны, здесь заранее известны структуры данных, объёмы и режимы загрузки, фиксировано количество записей в каждой таблице и известно, сколько и откуда записей будет добавляться, и удаляться, сколько и каких типов записей будет выбрано для формирования ответа на запрос. Тестируемые фирмы могут заранее и очень точно оценить размеры всех областей. Основным показателем теста, является соотношение Цена/Производительность и сложно предположить, что в конфигурации тестируемых систем, было что-то избыточное и лишнее. Поэтому, в реальной жизни, эти коэффициенты могут оказаться, не только не меньше, а даже несколько больше.

СУБД для  аналитических систем

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

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

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

Во  вторых, для обеспечения приемлемого времени ответа, при использовании РСУБД, необходимо уже на этапе проектирования знать обо всех возможных типах запросов, необходимых срезах и уровнях агрегации данных.

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

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

И всё же, по мнению Э.Кодда /3/, реляционные базы данных уже стали и будут оставаться и в будущем, наиболее подходящей технологией для реализации информационных систем уровня предприятия. И главной причиной их неэффективности в аналитических приложениях, являются не столько собственно недостатки реляционного подхода, сколько то, что производители РСУБД, еще до недавнего времени просто не обращали внимания на рынок аналитических систем.

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

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