Системы удаленной обработки данных

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

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

Централизованная база Ошибка! Закладка не определена. данных хранится в памяти одной вычислительной системы (на центральном компьютере), к которой пользователи (клиенты) обращаются за информацией с помощью своих компьютеров. Управление базой данных (ее корректировка и прочие процедуры, поддерживающие ее целостность, безопасность и др.) осуществляется централизованно. Один компьютер, располагающий ресурсами, называется сервером. Компьютер, который обращается к серверу за данными или требованием решения задачи, называется клиентом. Такой доступ к базе данных называют удаленным. Такой способ использования баз данных часто применяют в локальных сетях ПК.

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

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

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

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

Любой пользователь или любая прикладная программа оперирует с одной или несколькими базами данных. Когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла- необходимо указать имя удаленного узла и имя базы данных. Если использовать фиксированное имя узла, то прикладная программа становится зависимой от расположения БД. Например, обращение к БД "teacher.Prim", где первое слово указывает имя узла, будет зависимым от расположения.

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

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

· Прозрачность сети;

· Автоматическое преобразование форматов данных;

· Автоматическая трансляция кодов;

· Межоперабельность;

Прозрачность сети - клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk, и др.).

Автоматическое преобразование форматов данных – при  соединении нескольких компьютеров различных моделей под управлением различных операционных систем в сеть, возникает вопрос о согласовании форматов представления данных. В сети могут быть компьютеры, отличающиеся разрядностью (16-ти, 32-х и 64-х разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т.д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле.

Автоматическая трансляция кодов - в неоднородной компьютерной среде при взаимодействии клиента и сервера возникает задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (например, ASCII), при этом происходит рассогласование трактовки кодов символов. Поэтому, если на локальном узле используется одна кодовая таблица, а на удаленном — другая, то при передаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.

По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

К базам данных с локальным доступом возможен доступ только с того компьютера, на котором установлена база данных.

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

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

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

Выделяются четыре подхода, реализованные в следующих моделях:

1. модель файлового сервера (File Server - FS);

2. модель доступа к удаленным данным (Remote Data Access - RDA);

3. модель сервера баз данных (Data Base Server - DBS);

4. модель сервера приложений (Application Server - AS).

Удаленный доступ к централизованной базе данных предполагают использование в основном двух архитектур подобных систем:

• файл-сервер - один из компьютеров сети выделен в качестве центрального (сервер файлов), на котором хранится совместно используемая централизованная БД. Все другие компьютеры сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользователей к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно. До недавнего времени была популярна среди разработчиков, использовавших такие системы, как FoxPro, Clipper, Clarion, Paradox и т.д.;

• клиент-сервер - помимо хранения централизованной базы данных сервер должен обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), инициирует поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SOL.

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

Одним из важных преимуществ архитектуры клиент-сервер в сетевой обработке данных является возможность сокращения времени реализации запроса.

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

Службы баз данных NetWare Btrieve и NetWare SQL фирмы Novell позволяют разработчикам создавать надежные прикладные программы баз данных без необходимости написания собственных программ управления записями, что обеспечивает удобный перенос прикладных программ в среду клиент-сервера.

В настоящее время разработаны десятки тысяч прикладных автономных и многозадачных программ, ориентированных на клиента версий NetWare Btrieve, NetWare SQL, которые могут быть использованы организациями, создающими или имеющими сеть ЭВМ. Более того, версии NetWare Btrieve и NetWare SQL фирмы Novell для клиентов имеют согласованные API, что упрощает перенос программ из среды одного клиента в среду другого.

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

Достоинствами распределенной обработки информации является:

- большое число взаимодействующих между собой пользователей;

- устранение пиковых нагрузок с централизованной базы данных за счет распределения обработки и хранения локальных баз данных на разных ЭВМ;

- возможность доступа пользователя к вычислительным ресурсам сети ЭВМ;

- обеспечение обмена данными между удаленными пользователями.

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

Создание распределенных баз данных (РБД) было вызвано двумя тенденциями обработки данных, с одной стороны - интеграцией, а с другой - децентрализацией.

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

Распределенная база данных - база данных, части которой размещены на отдельных ЭВМ, входящих в сеть. При этом некоторые данные могут дублироваться.

При проектировании РБД осуществляется разбиение объекта на несколько частей (фрагментов) и размещение каждого фрагмента на одном или нескольких компьютерах. Размещение фрагментов может быть избыточным или безызбыточным.

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

К организации баз данных предъявляются такие общие требования, как обеспечение высокой скорости обработки запросов, секретности, независимости (физической и логической) данных, безопасности и т.д. Кроме перечисленных требований, к РБД выдвигаются требования "прозрачности" распределенной структуры БД; совместного доступа к данным; распределенной обработки.

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

Совместный доступ к данным подразумевает модификацию одних и тех же данных несколькими пользователями, не нарушая целостности РБД.

"Прозрачность" распределенной обработки означает независимость пользователей и программ от типа локальной вычислительной сети и применяемого сетевого программного обеспечения. Обработка запроса пользователя может производиться на нескольких ЭВМ.

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

- автоматическое определение ЭВМ, хранящей требуемые в запросе данные;

- декомпозицию распределенных запросов на частные подзапросы к БД отдельных ЭВМ;

- планирование обработки запросов;

- передачу частных подзапросов и их исполнение на удаленных ЭВМ;

- прием результатов выполнения частных подзапросов;

- поддержание в согласованном состоянии копий дублированных данных на различных ЭВМ сети;

- управление параллельным доступом пользователей к РБД;

- обеспечение целостности РБД.

 

Системы обработки распределенных баз данных (РаБД)

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

Распределение данных осуществляется двумя способами: реплицирование  и тиражирование данных.

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

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

Глобальный словарь данных — это механизм отслеживания расположения объектов в распределенной БД. Данные могут храниться на локальном узле, на удаленном узле, или на обоих узлах — их расположение должно оставаться прозрачным как для конечного пользователя, так и для программ. Не нужно явным образом указывать место расположения данных — программа должна быть полностью независима от того, на каких узлах размещаются данные, с которыми она оперирует;

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

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

Вскоре после появления идея (и теория) реляционных баз данных стала популярна среди разработчиков СУБД. Однако сделать реляционную СУБД оказалось непросто. Сложилась неоднозначная ситуация, когда после некоторых усовершенствований одни фирмы стали называть свои разработки реляционными, а другие - отказываться от создания реляционных СУБД в силу сложности задачи. Для того, чтобы внести ясность в оценку разработок одних фирм и более определенно сформулировать цель, к которой разработчикам нужно стремиться, для других фирм, Е. Кодд, автор реляционного подхода, в конце 70-х гг. опубликовал свои 12 правил соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики:

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

1. Информационное правило. Вся информация, хранимая в реляционной базе данных, должна быть явно, на логическом уровне, представлена единственным образом: в виде значений в R-таблицах.

2. Правило гарантированного логического доступа. К каждому имеющемуся в реляционной базе атомарному значению должен быть гарантирован доступ с помощью указания имени R-таблицы, значения первичного ключа и имени столбца.

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

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

5. Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:

· определение данных,

· определение правил целостности,

· манипулирование данными (в диалоге и из программы),

· определение выводимых таблиц (в том числе возможности их модификации),

· определение правил авторизации,

· границы транзакций.

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

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

8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или в методах доступа СУБД Ошибка! Закладка не определена..

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

10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

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

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

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

Эти правила были переработаны Крисом Дейтом, который начал свою карьеру в компании IBM, где специализировался в области технологии баз данных. Основным трудом К. Дейта является учебная монография “Введение в системы баз данных”. В 2003 г. вышло в свет уже восьмое издание этой книги. Каждое издание книги существенно отличается предыдущих изданий, но не снижает их собственную значимость. На русском языке опубликованы три издания “Введения в системы баз данных”.

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

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

 

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

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

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

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

Моделью данных в ХД служат гиперкубы, т.е. многомерные базы данных, в ячейках которых находятся анализируемые данные. По осям многомерного куба указываются измерители объекта с различных точек зрения.

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

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

Оси измерения позволяют создавать многомерную модель данных (гиперкуб), над которым можно выполнять следующие операции:

• срез;

• вращение;

• консолидация или детализация.

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

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

 

 

 

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

Концепция ХД относится к одному из перспективных направлений развития систем формирования решений. Хранилище данных может создаваться в следующих целях:

· интеграция текущих и исторических значений данных;

· объединение данных из разрозненных источников;

· создание надежной платформы данных для аналитических целей;

· обеспечение однородности данных в организации;

· облегчение внедрения корпоративных стандартов данных без изменения существующих операционных систем;

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

В настоящий момент внедрение Хранилищ данных и связанных с ними технологий находится в процессе невиданного за последние несколько лет ускоренного развития и изменения. Недавние результаты, представленные аналитиками компании IDC, показывают, что рынок ХД составляет сегодня около 10 млрд. долларов, а в ближайшие годы может возрасти до 13,5 млрд. Казалось бы, идея ХД, «с нуля» выросшая во всемирный многомиллиардный рынок, уже изживает себя. Однако осуществленные за последние годы новые разработки говорят о том, что в этой области грядет возрождение. Крупные корпорации по всему миру получают существенные преимущества за счет технологии Хранилищ, которая потенциально может принести еще больше пользы.

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

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

Устройства для Хранилищ данных можно определить как:

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

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

Большинство подобных устройств поддерживают так называемые "крупные витрины данных", где витрина является частью аналитического приложения, обычно предназначенного для анализа какой-то отдельной области: деталей заказов, потребителей, корзин заказов и т.д. Это одна из наиболее распространенных на сегодня областей использования устройств для Хранилищ данных.

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

Объем данных, находящихся под управлением одной крупной витрины, обычно составляет от 1 до 10 терабайт, причем это данные, доступные для запросов. Их объем будет увеличиваться по мере того, как пользователи станут работать с большим количеством данных, а поставщики начнут создавать более емкие модели. Обычно пользователи устройств для Хранилищ данных начинают с объема 1-3 терабайта и доводят его до 10 терабайт за несколько лет.

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

 

Контрольные вопросы

1. Исторический аспект методов обработки данных.

2. Принципы передачи данных в сети.

3. Сущность удаленной обработки данных.

4. Для чего используются виртуальные имена узлов сети.

5. Обработка запросов в архитектуре "файл/сервер".

6. Обработка запросов в архитектуре "клиент/сервер".

7. Достоинства и недостатки архитектур файл/сервер и клиент/сервер.

8. Понятие «распределенная база данных».

9. Способы распределения базы данных.

10. Достоинства и недостатки распределенной обработки данных.

11. Различия гомогенных и гетерогенных РаБД.

12. Наиболее известные распределенные СУБД Ошибка! Закладка не определена..

13. Двенадцать правил К. Дейта.

14. Понятие «хранилище данных».

15. Причины появления хранилищ данных.

16. Суть технологии OLAP.

Литература

1. Экономическая информатика / Под.ред. П.В.Конюховского, Д.Н.Колесова. – Мн.: Новое знание. 2001. - с. 302-306.

2. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. пособие. – 2-е изд., испр. и доп. – М.: ФОРУМ:ИНФРА-М, 2007. – С. 272-280, 337-340.

3. Кузин А.В., Демин В.М. Разработка баз данных в системе Microsoft Access: учебник. – 2-е изд. – М.: ФОРУМ-ИНФРА-М, 2007.- С. 182-186.

4. Романов А.Н., Одинцов Е.Е. Информационные системы в экономике (лекции, упражнения и задачи): Учеб. пособие. – М.: Вузовский учебник, 2007. – С. 99-100., 107-111.

Основные понятия

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

Распределенная база данных - база данных, части которой размещены на отдельных ЭВМ, входящих в сеть.

Локальный доступ - к базам данных с локальным доступом возможен доступ только с того компьютера, на котором установлена база данных.

Удаленный доступ - к базам данных с удаленным доступом возможен доступ с компьютеров в сети.

Принципы сетевого доступа к базе данных: прозрачность расположения; прозрачность сети; автоматическое преобразование форматов данных; автоматическая трансляция кодов; межоперабельность.