Приложение, выполняющееся на любом компьютере кластера, может работать с базой так, как если бы она полностью размещалась на этом компьютере. Распределенность базы по узлам кластера делает DB2/400 прозрачной как для приложений, так и для конечного пользователя. Для задания имен системам в группе узлов в CL были введены новые команды, к некоторым командам были добавлены новые параметры для поддержки распределения файлов базы по узлам. После рассредоточения по узлам, файл при выполнении операций вставки, обновления и удаления выглядит как локальный.
Главное преимущество слабо связанных параллельных систем — отсутствие верхнего предела количества узлов, что означает практически неограниченный рост производительности и емкости. Возможности расширения концепции кластеров AS/400 в будущем мы рассмотрим в главе 12.
Многомерные базы данных (MDD)
Реляционные базы данных организованы в виде двумерных таблиц. В MDD имеется одно или несколько дополнительных измерений. Например, Вам надо оценить свои доходы от продаж, рассмотрев в отдельности сводки по товарам, по регионам и по времени. В этом случае лучшую наглядность Вам обеспечит трехмерная структура данных со шкалой измерения по товарам на одной оси; временем в днях, неделях или месяцах — на второй; и географическими данными — на третьей. В результате получится куб, очень похожий на трехмерную электронную таблицу, в каждой ячейке которой — величина доходов от продажи. Далее можно использовать различные средства анализа продаж товаров в регионах в течение некоторого периода времени.
AS/400 поддерживает многомерные структуры данных непосредственно в самой базе данных DB2/400 или с помощью продуктов, разработанных бизнес-партнерами. Преимущество многомерных структур данных состоит в возможности быстро получить ответ на поставленный вопрос в виде среза данных по любому измерению или прохода сквозь структуру для получения данных новых уровней. Поскольку время ответа на запросы обычно очень мало, такой многомерный анализ часто называют оперативной аналитической обработкой OLAP (on-line analytical processing).
Иногда различным подразделениям одной организации требуются информационные данные в разных формах. Внутри MDD можно создавать специализированные хранилища данных (data mart), которые содержат информационные данные, соответствующие потребностям конкретного отдела или рабочей группы. В этом случае хранилище данных всей организации состоит из набора таких специализированных хранилищ для отдельных структурных единиц[ 49 ].
Анализ данных и инструментарий конечных пользователей
Термином «интеллектуальный бизнес» (business intelligence) обозначают методы обработки информации, применяемые для принятия решений в бизнесе. Средства интеллектуального ведения бизнеса — это программные пакеты, используемые для анализа данных в хранилище данных на AS/400. Обычно, эти программы работают на ПК и способны обращаться к хранилищу данных на AS/400 напрямую. Есть три основных категории бизнес-информационных средств:
программы поддержки принятия решений DSS (decision support system);
управленческие информационные системы EIS (executive information system);
средства разработки данных.
Программы DSS позволяют конечному пользователю строить гипотезу и затем генерировать запросы для ее проверки. При этом предполагается, что у пользователя есть некое общее представление о том, что нужно найти в хранилище данных, и это позволяет ему выдавать произвольные запросы и генерировать отчеты. Это средства простейшего типа, так как они просто возвращают информацию по запросу пользователя.
EIS объединяют средства поддержки принятия решений с некоторыми расширенными возможностями анализа. Обычно, они имеют доступ к средствам за пределами хранилища данных, например, могут использовать оперативные новости из Интернета для получения информации с мировых рынков. Как и DSS, EIS предполагает наличие у спрашивающего некоторого представления о том, что именно следует искать.
И EIS, и DSS обеспечивают поиск нужной пользователю информации путем проверок. Но как быть, если Вы не можете четко сформулировать вопрос? Вы знаете, что в базе данных скрыта важная информация, но не можете придумать, как до нее добраться. Тогда Вам нужна разработка данных — средство принятия решений на основе открытий.
Разработка данных позволяет отыскивать информацию при незначительном объеме указаний от пользователя или вовсе без таковых. Система выполняет поиск шаблонов и связей. На практике существует бесконечное множество вариантов такого способа поиска. Например, розничный торговец может использовать разработку данных для того, чтобы определить, какие товары покупаются вместе. Анализ и оценка привычек покупателей очень полезны при оценке спроса на товар, или выявлении групп покупателей с наивысшим потенциалом. Разработка данных используется также в банковском деле для выявления подделок кредитных карт: путем «просеивания» больших объемов информации можно выявлять отклонения от нормы.
Технология разработки данных пришла из мира искусственного интеллекта. Средства IBM для поиска шаблонов и взаимосвязей данных комбинируют нейронные сети и статистические алгоритмы. Нейронная сеть поддерживает основной шаг разработки данных в процессе открытия знаний. Соответствующая технология была разработана в Рочестере в период проекта Fort Knox (подробнее об этом — в Приложении) и впервые появилась на рынке в начале 90-х годов в виде утилиты для AS/400. Теперь же она — основа всей разработки данных в IBM.
Управление хранилищем данных
Метаданные — это данные о данных. Они используются для управления хранилищем данных. Существуют две формы метаданных — технические и бизнес-данные. Первые содержат описания оперативной базы данных и хранилища данных, что позволяет перемещать данные из оперативной базы в хранилище.
Бизнес-данные необходимы конечному пользователю для поиска информации в хранилище данных. Легче всего представить их себе как каталог информации о хранилище, в том числе об актуальности и источниках поступления этой информации. Бизнес-данные пользователь видит в терминах, принятых в его отрасли деятельности, и может позволить себе забыть о сложности нижележащей базы данных.
Теперь, после рассмотрения способов использования новых технологий баз данных AS/400, мы можем перейти к фундаментальным концепциям DB2/400. Сначала рассмотрим историю этой замечательной базы данных.
Эволюция реляционной базы данных
Первая коммерческая база данных с реляционными возможностями появилась в System/38. Эта уникальная технология опережала другие реляционные базы примерно на три года, что позволило System/38 выйти на передовые позиции на рынке.
Разработчики System/38 искали более эффективный способ обработки записей, по сравнению с System/3. Первая System/3 была разработана как машина единичных записей. Она поддерживала только пакетную обработку, то есть приложение должно было обработать все записи в файле одну за другой. Первые записи размещались на перфокартах, колода перфокарт составляла файл. Позднее, появилась возможность хранения файлов на диске, хотя обрабатывались они по-прежнему с помощью перфокарт.
Типичное приложение единичных записей сначала сортировало записи в файле. Записи могли иметь несколько полей, содержащих такую информацию, как имя клиента, номер счета, номер детали и так далее. Выбиралось одно из этих полей, называемое ключом, и все записи сортировались по значению ключевого поля в определенном порядке. Механический сортировщик перфокарт в большинстве машин единичных записей использовался очень интенсивно. После сортировки файл обрабатывался последовательно, запись за записью, до конца.
Позднее в System/3 была добавлена интерактивная обработка. Применение дисков позволило обращаться к записям в произвольном порядке. Поиск нужной записи осуществлялся с помощью индекса — небольшого файла, в котором каждой записи основного файла соответствуют лишь два поля. Первое содержит значение ключа, а второе — дисковый адрес записи с совпадающим значением. Для сортировки записей индекса по значениям ключа использовалась особая программа. Затем индекс сохранялся на диске вместе с основным файлом.
Для поиска записи с заданным значением ключа система вначале просматривала индекс. После этого для выборки полной записи использовался дисковый адрес, хранящийся вместе с этим значением. Так как размер памяти System/3 был очень небольшим, хранить в памяти объемные индексы целиком было невозможно. Это снижало эффективность поиска из-за необходимости нескольких обращений к диску.
System/34 была первой моделью семейства System/3, предназначенной для работы в интерактивном, а не в пакетном режиме. Размеры памяти в System/34 были также невелики, так что IBM решила ускорить поиск нужной записи в индексе, а для этого — устранить необходимость считывать индекс с диска.
