Организация связи сущностей

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

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

Более сложные связи (не бинарные) следует сводить к бинарным. Для описания взаимосвязей N объектов требуется N-1 таблиц связей. Транзитивных связей не должно быть. Избыток связей приводит к противоречиям.

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

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

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

Хранилище данных

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

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

В основе концепции хранилища данных лежат две основные идеи:

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

2. Разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа

В отличие от БД в традиционных ИС, где данные подобраны в соответствии с конкретными приложениями, информация в Хранилище ориентирована на задачи поддержки принятия решений.

Для системы поддержки принятия решений требуются "исторические" данные - факты продаж за определенные интервалы времени.

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

Свойства информационных хранилищ:

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

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

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

Минимизация избыточности информации. Поскольку информация в Хранилище загружается из БД, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? На самом деле избыточность минимальна (около 1%), что объясняется следующими причинами:

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

Основные компоненты информационного хранилища:

• ПО промежуточного слоя. Обеспечивает сетевой доступ и доступ к базам данных. Сюда относятся сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и пр.
• Транзакционные БД и внешние источники информации. Базы данных исторически предназначались для эффективной обработки структур данных в относительно небольшом числе четко определенных транзакций.
• Уровень доступа к данным. Относящееся сюда ПО обеспечивает общение конечных пользователей с информационным хранилищем и загрузку требуемых данных из транзакционных систем.
• Загрузка и предварительная обработка. Этот уровень включает в себя набор средств для загрузки данных из БД и внешних источников. Выполняется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
• Информационное хранилище. Представляет собой ядро всей системы - один или несколько серверов БД.
• Метаданные (репозиторий, "данные о данных"). Играют роль справочника, содержащего сведения об источниках первичных данных, алгоритмах обработки, которым данные были подвергнуты, и т. д.
• Уровень информационного доступа. Обеспечивает непосредственное общение пользователя с данным Хранилища посредством стандартных систем манипулирования, анализа и предоставления данных типа MS Excel, FoxPro и др.
• Уровень управления (администрирования). Отслеживает выполнение процедур, необходимых для обновления информационного хранилища или поддержания его состояния.

Проблемы интеграции данных в Хранилище:

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

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

Повышение требований к безопасности данных. Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если хранилище данных одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на хранилищах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США).

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

Потребность в эффективном хранении и обработке очень больших объемов информации. Уже сейчас известны примеры хранилищ данных, содержащих терабайты информации. По данным консалтинговой компании Meta Group, около половины корпораций, использующих или планирующих использовать хранилища данных, предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается

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

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

По сведениям IDC, за последние десять лет из 40% американских компаний, полностью лишившихся своих данных в результате пренебрежительного отношения к технологиям их хранения, только 10% смогли вернуться к бизнесу и только 4% (!) из них выжили в течение последующих трех лет.

Хранилища данных отличаются от баз данных или систем оперативной обработки транзакций (OLTP-систем) своим назначением и устройством:

• хранилище содержит данные, позволяющие проводить анализ деловых операций;

• хранилища обычно представляют собой системы, доступные только для чтения;

• в хранилищах же накапливаются данные, не меняющиеся со временем и избавленные от ошибок.

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

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

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