ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В СТРОИТЕЛЬСТВЕ

БАЗА ДАННЫХ, ЕЕ СОСТАВ, МОДЕЛИ БАЗ ДАННЫХ

Активная деятельность по отысканию приемлемых способов обобществле­ния непрерывно растущего объема информации привела к созданию в начале 60-х гг. прошлого века специальных программных комплексов, называемых «Системы управления базами данных» (СУБД).

Основная особенность СУБД — это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, называются «Базы данных» (БД).

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

Традиционных возможностей файловых систем оказывается недостаточно для построения даже простых информационных систем. Существует несколь­ко потребностей, которые не покрываются возможностями систем управления файлами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разно­го рода сбоев; параллельная работа нескольких пользователей. Можно считать, что если прикладная информационная система опирается на некоторую систе­му управления данными, обладающую этими свойствами, то эта система управ­ления данными является системой управления базами данных (СУБД).

Более точно, к числу функций СУБД принято относить следующие:

• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.

Организация типичной СУБД и состав ее компонентов соответствует рас­смотренному набору функций.

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

Логически в современной реляционной СУБД можно выделить внутреннюю часть — ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других — нет, но логически такое разделение можно провести во всех СУБД.

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

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

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

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

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

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

Преимущества системы баз данных по сравнению с традиционным «бумаж­ным» методом ведения учета очевидны:

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

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

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

Можно выделить следующие преимущества этого подхода:

• Возможность совместного доступа к данным. Совместный доступ к данным означает не только возможность доступа к ним нескольких существующих при­ложений базы данных, но и возможность разработки новых приложений для работы с этими же данными Другими словами, требования новых приложений по доступу к данным могут быть удовлетворены без необходимости добавления новых данных в базу.
• Сокращение избыточности данных. В системах, не использующих базы данных, каждое приложение имеет свои файлы. Это часто приводит к избыточ­ности хранимых данных и, следовательно, к расточительству пространства вторичной памяти. Например, как приложение, связанное с учетом персонала, так и приложение, связанное с учетом обучения служащих, могут иметь соб­ственные файлы с ведомственной информацией о служащих. Эти два файла можно объединить с устранением избыточности (одинаковой информации) при условии, что администратор данных знает о том, какие данные нужны для каждого приложения, т.е. что на предприятии осуществляется необходимое общее управление.
• Устранение противоречивости данных. В действительности это следствие предыдущего пункта. Например: пусть служащий с номером «ЕЗ», работающий в отделе с номером «D8» представлен двумя различными записями в базе дан­ных. Пусть в СУБД не учтено это раздвоение (т.е. избыточность данных не контролируется). Тогда рано или поздно обязательно возникнет ситуация, при которой эти две записи перестанут быть согласованными, когда одна из них будет изменена, а другая — нет. В этом случае база данных станет противоре­чивой. Ясно, что противоречивая база данных способна предоставлять поль­зователю неправильную, противоречивую информацию.

Также очевидно, что если какой-либо факт представлен одной записью (т.е. при отсутствии избыточности), то противоречий возникнуть не может. Проти­воречий можно также избежать, если не удалять избыточность, а контролиро­вать ее (соответствующим образом известив об этом СУБД). Тогда СУБД смо­жет гарантировать, что, с точки зрения пользователя, база данных никогда не будет противоречивой. Данная гарантия обеспечивается тем, что если обнов­ление вносится в одну запись, то оно автоматически будет распространено на все остальные. Этот процесс называется распространением обновлений (propagating updates).

• Возможность поддержки транзакций. Транзакция (transaction) — это ло­гическая единица работы, обычно включающая несколько операций базы дан­ных (в частности, несколько операций изменения). Стандартный пример — передача суммы денег со счета А на счет В. Очевидно, что в данном случае необходимы два изменения: изъятие денег со счета А и их внесение на счет В. Если пользователь укажет, что оба изменения входят в одну и ту же транзакцию, то система сможет реально гарантировать, что либо оба эти изменения будут выполнены, либо не будет выполнено ни одно из них, даже если до завершения процесса изменений в системе произойдет сбой (скажем, из-за перерыва в по­даче электроэнергии).

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

• Обеспечение целостности данных. Задача обеспечения целостности заклю­чается в гарантированной поддержке корректности данных в базе. Противо­речивость между двумя записями, представляющими один «факт», является примером утраты целостности данных. Конечно, эта конкретная проблема может возникнуть лишь при наличии избыточности в хранимых данных. Но даже если избыточность отсутствует, база данных может содержать некоррект­ную информацию. Например, в базе данных может быть указано, что сотрудник отработал 400 рабочих часов в неделю вместо 40, или зафиксирована его при­надлежность к отделу, которого не существует. Централизованное управление базой данных позволяет избежать подобных проблем (насколько их вообще возможно избежать). Для этого администратор данных определяет (а АБД ре­ализует) ограничения целостности (integrity constraints), иначе называемые бизнес-правилами, которые будут применяться при любой попытке внести какие-либо изменения в соответствующие данные.

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

• Организация защиты данных. Благодаря полному контролю над базой дан­ных администратор базы данных (АБД) может обеспечить доступ к ней только через определенные каналы. Для этой цели могут устанавливаться ограничения защиты (security constraints) или правила, которые будут проверяться при любой попытке доступа к уязвимым данным. Можно установить различные правила для разных типов доступа (выборка, вставка, удаление и т.д.) к каждому из эле­ментов информации в базе данных. Однако следует заметить, что при отсутствии таких правил безопасность данных подвергается большему риску, чем в обыч­ной (разобщенной) файловой системе. Следовательно, централизованная при­рода системы баз данных в определенном смысле требует наличия надежной системы защиты.
• Возможность балансировки противоречивых требований. Зная общие тре­бования всего предприятия (а не требования каждого отдельного пользователя), АБД (опять же в соответствии с указаниями администратора данных) может структурировать базу данных таким образом, чтобы обслуживание было наи­лучшим для всего предприятия. Например, администратор базы может выбрать такое физическое представление данных во вторичной памяти, которое обе­спечит быстрый доступ к информации для наиболее важных приложений (воз­можно, с потерей производительности для некоторых других приложений).
• Возможность введения стандартизации. Благодаря централизованному управлению базой данных АБД (по указаниям администратора данных) может обеспечить соблюдение всех подходящих стандартов, регламентирующих пред­ставление данных в системе. Стандарты бывают частными, корпоративными, ведомственными, промышленными, национальными и интернациональными. Стандартизация представления данных очень важна с точки зрения обмена и пересылки данных между системами. Стандарты именования и документиро­вания данных важны для их совместного использования и углубленного по­нимания.
• Независимость данных. Независимость данных может быть реализована на двух уровнях: физическом и логическом. Здесь будет рассмотрена только физическая независимость данных.

Проще всего разобраться в понятии независимости данных на примере их противоположности. Приложения, реализованные в старых системах («доре- ляционные» или созданные даже до появления систем баз данных), в той или иной мере зависимы отданных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями при­ложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программный код приложения.

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

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

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

Для обработки данных используется аппарат теории множеств (объединение, пересечение, разность, декартово произведение), в котором любое представ­ление данных сводится к совокупности двумерных таблиц особого вида, из­вестного в математике как отношение — relation (англ.).

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

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

• Тип данных. Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в со­временных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), а также специальных «темпоральных» данных (дата, время, времен-

ной интервал). Достаточно активно развивается подход к расширению возмож­ностей реляционных систем абстрактными типами данных.

• Домен. Доменом называется множество атомарных значений одного и того же типа. Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся его элементы, и произвольного логического вы­ражения, применяемого к элементу типа данных. Если вычисление этого ло­гического выражения дает результат «истина», то элемент данных является элементом домена.
• Атрибут. Под атрибутом понимается поименованная характеристика сущ­ности. Его наименование должно быть уникальным для конкретного типа сущ­ности, но может быть одинаковым для различного типа сущностей (например, «цвет» может быть определен для многих сущностей как «цветок», «автомобиль», «краска» и т.д.). Атрибуты используются для определения того, какая инфор­мация должна быть собрана о сущности. Примерами атрибутов для сущности «автомобиль» являются «тип», «марка», «номерной знак», «цвет» и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута «цвет» имеет много экземпляров или значений — «красный», «синий», «желтый», «бе­лый» и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

• Кортеж, отношение. Кортеж, соответствующий данной схеме отноше­ния, — это множество пар — {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Зна­чение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень, или «арность» кортежа, т.е. число элементов в нем, совпадает с «арностью» соот­ветствующей схемы отношения. Попросту говоря, кортеж — это набор имено­ванных значений заданного типа. Отношение — это множество кортежей, со­ответствующих одной схеме отношения.
• Первичный ключ. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первич­ного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов.

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

• Схема отношения, схема базы данных. Схема отношения — это поимено­ванное множество пар — {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Схема базы данных (в структурном смысле) — это набор именованных схем отношений.
• Степень отношения. Под степенью отношения понимается число его атри­бутов.
• ХРАНИЛИЩА ДАННЫХ И БАЗЫ ДАННЫХ

Хранилище данных (data warehouse) — это автоматизированная информа­ционно-технологическая система, которая собирает данные из существующих баз и внешних источников, формирует, хранит и использует информацию как единую. Хранилище обеспечивает инструментарий для преобразования боль­ших объемов детализированных данных в форму, которая удобна для стратеги­ческого планирования и реорганизации бизнеса и необходима специалисту, ответственному за принятие решений. При этом происходит слияние из разных источников различных сведений в требуемую предметно-ориентированную форму с использованием различных методов анализа.

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

Хранилище информации предназначено для хранения, оперативного полу­чения и анализа интегрированной информации по всем видам деятельности организации.

Данные в таком хранилище характеризуются следующими свойствами:

• предметная ориентация — данные организованы согласно предмету, а не приложению (в соответствии со способом данных);
• интегрированность—данные согласуются с определенной системой наи­менований, хотя могут принадлежать различным источникам и их формы пред­ставления могут не совпадать;
• упорядоченность во времени — данные согласуются во времени для ис­пользования в сравнениях, трендах и прогнозах;
• неизменяемость и целостность — данные не обновляются и не изменя­ются, а только перезагружаются и считываются, поддерживая концепцию «од­ного правдивого источника»;
• большой объем и сложные взаимосвязи данных.

К основным типам данных, которые располагаются в хранилище, относятся:

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

В информационных хранилищах используются статистические технологии,

генерирующие информацию об информации; процедуры суммирования; ме­тоды обработки электронных документов, аудио- и видеоинформации, графов и географических карт.

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

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

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

• Скорость загрузки. В хранилищах необходимо обеспечить периодическую загрузку новых порций данных, укладывающихся в достаточно узкий времен­ной интервал. Требуемая производительность процесса загрузки не должна накладывать ограничения на размер хранилища.
• Технология загрузки. Загрузка новых данных в хранилище включает пре­образование данных, фильтрацию, переформатирование, проверку целост­ности, организацию физического хранения, индексирование и обновление метаданных. Это дает возможность объединить разнородную информацию из пакетов, применяемых в структурных подразделениях организации.
• Управление качеством данных. В хранилище должна быть обеспечена ло­кальная и глобальная согласованность данных. Мера качества построенного хранилища — объективность исходных данных и степень разнообразия воз­можных запросов.
• Поддержка различных видов данных. В хранилище могут накапливаться данные не только стандартных типов, но и более сложных, таких, как текст, изображения, а также уникальных типов, определяемых разработчиками.
• Скорость обработки запросов. Сложные запросы, важные для принятия ответственных решений, должны обрабатываться за секунды или минуты. Ско­рость обработки запроса должна зависеть от его сложности, а не от объема БД.
• Масштабируемость. Хранилище организации может достигнуть несколь­ких сотен гигабайт. СУБД не должна иметь никаких архитектурных ограниче­ний и должна поддерживать модульную и параллельную обработку, сохранять работоспособность в случае локальных аварий и иметь средства восстановления.
• Обслуживание большого числа пользователей. Доступ к хранилищу данных не ограничивается узким кругом специалистов организации. Сервер БД должен поддерживать сотни пользователей без снижения скорости обработки запросов.
• Сети хранилищ данных. Сервер должен содержать инструменты, коорди­нирующие перемещение данных между хранилищем организации, информа­ционными системами банков и т.п. Пользователи должны иметь возможность обращаться к нескольким хранилищам с одной клиентской рабочей станции.
• Администрирование. СУБД должна обеспечить контроль за ресурсными ограничениями, сообщать о затратах ресурсов и позволять устанавливать при­оритеты для различных категорий пользователей или операций, а кроме того, уметь осуществлять трассировку и настройку системы на максимальную про­изводительность. Качество построенного хранилища определяется удобством доступа к нему для конечного пользователя.
• Интегрированные средства многомерного анализа. Для обеспечения высо­копроизводительной аналитической обработки необходимы средства много­мерных представлений, инструменты, поддерживающие удобные функции создания предварительно вычисленных суммарных показателей и автомати­зирующих генерацию таких предварительно вычисленных агрегированных величин.
• Средства формирования запросов. Пользователь должен иметь возможность проведения аналитических расчетов, последовательного и сравнительного ана­лиза, а также доступ к детальной и агрегированной информации.

Примером информационного хранилища может служить Oracle VLM, раз­работанная фирмами Oracle и Digital.

В информационном хранилище Oracle VLM увеличился объем кэш-памяти (быстродействующей памяти) для обмена с сервером базы данных, что сокра­тило время обращения кдиску с миллисекунд до микросекунд. Например, «ма­ленькая» база данных объемом 5 Гб целиком загружается в кэш-память. По­скольку кэш-память базы данных является частью системной области памяти SGA, Oracle VLM фактически снимает ограничения на ее размер и оперирует с большой, системной областью памяти LSGA.

Увеличился максимальный размер обрабатываемого блока базы данных до 32 кб. Обычно он равнялся 2 кб, а максимальный — 8 кб. Обрабатываемый блок базы данных содержит управляющую часть (заголовок) и собственно данные. Если данные (графика, аудио-, видеоданные, изображения) не помещаются в блок целиком, строится цепочка блоков.

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

На вопрос, зачем строить хранилища данных, ведь они содержат заведомо избыточную информацию, которая и так находится в базах или файлах опера­тивных систем, ответить можно кратко: анализировать данные оперативных систем напрямую невозможно или очень затруднительно. Это объясняется раз­личными причинами, в том числе разрозненностью данных, хранением их в форматах различных СУБД и на разных серверах корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД (что бывает крайне редко), аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах. Таким образом, задача хранилища — предоста­вить данные для анализа в одном месте и в простой, понятной структуре.

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