Предыдущая страница реферата | 11  12  13  14  15  16  17  18  19  20  21 | Следующая страница реферата

. URL-интерфейс (UniversalResourceLocator). Этот интерфейс дает разработчикам Web-приложений единую точку доступа к логике приложения и информации, содержащейся в базе данных. Такая информация может включать динамически конструируемые или статические HTML-страницы и соответствующие мультимедийные данные. Для быстрой и персонализированной доставки пользователям этой информации WebConnect передает URL серверу баз данных.

. Страницы приложений (AppPages). AppPage - это HTML-страница со встроенными операторами SQL, на основании которой конструируется документ, отображаемый браузером. AppPage может включать скрипты

JavaScript и апплеты Java.

. Программный интерфейс. Набор соответствующих средств позволяет просто переносить приложения "клиент-сервер" в среду Web или разрабатывать новые такие приложения. С помощью этого интерфейса обеспечивается стыковка с объектными брокерами (в частности, основанными на CORBA).

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

. Безопасность. Обеспечивается возможность авторизации и аутентификации на уровне сервера баз данных. Это дает возможность распространить систему безопасности баз данных на Web-сервер.
8.1.5.3. Решения компании Sybase
Компания Sybase и ее дочерняя компания Powersoft поставляют несколько продуктов, предназначенных для производства Web-приложений, которые имеют доступ к базам данных. Кратко охарактеризуем некоторые из них. (Заметим, что в силу общей ориентации Sybase на компонентную архитектуру, в большинстве случаев эти продукты представляют собой компоненты, которые могут встраиваться в разные продукты.)
NetImpactDynamo - компонент, содержащий средства для построения сложных, динамических, связанных с базами данных Web-узлов. В настоящее время этот компонент поставляется в составе продукта SybaseSQLAnywhereProfessional. jConnect - полная реализация на языке Java стандарта JDBC. Продукт дает возможность непосредственного доступа к базам данных (без использования промежуточного Web-сервера) из Java-приложений.
PowerSite - полная среда разработки в среде Web. Продукт обеспечивает разнообразные средства разработки, управления и тестирования динамических управляемых данными Web-приложений. PowerSite состоит из редактора и браузера HTML, персонального Web-сервера и средств поддержки активных языков сценариев.
Продукт Sybaseweb.sql дает возможность встраивать операторы SQL и скрипты, написанные на языке Perl, в HTML-страницы, что позволяет создавать персонализированные и кастомизированные страницы.
8.1.5.4. Решения компании IBM
Для интеграции технологии баз данных и Web-технологии компания IBM предлагает продукт DB2 WorldWideWebConnection. Этот продукт представляет собой шлюз с Internet и предназначен для работы с семейством серверов реляционных баз данных DB2 и семейством Web-серверов и защитных экранов
(firewall). Кроме того, DB2 WWWConnection работает с продуктами IBM категории промежуточного программного обеспечения, что дает возможность Web- доступа к другим источникам данных.
Web-приложения для DB2, построенные с помощью DB2 WWWConnection, позволяют пользователю использовать для доступа к базам данных из стандартного браузера без потребности в каких бы то ни было изменениях в существующих структурах данных. На основе стандартных языков HTML и SQL строятся приложения, которые взаимодействуют с DB2 с помощью обычных операторов SQL.

Возможно построение двух- или трехзвенных архитектур "клиент-сервер". При двухзвенной организации используются клиентские рабочие места с Web- браузерами и Web-сервер, на котором и производится доступ к DB2. В трехзвенной среде Web-сервер обращается к другим серверам баз данных.
Связующие возможности обеспечиваются средствами
DistributedDatabaseConnectionServices (DDCS), ClientApplicationEnabler
(CAE) и DistributedRelationalDatabaseArchitectureApplicationRequester
(DRDAAR).
В трехзвенной организации допускается использование продукта DataJoiner, при применении которого обеспечивается возможность Web-доступа к базам данных Oracle, Sybase, MicrosoftSQLServer и другим реляционным и нереляционным источникам данных. Для повышения уровня безопасности приложений используется криптография.
В настоящее время продукт DB2 WWWConnection доступен на платформах OS/2,
AIX, OS/400, MVS/ESA, WindowsNT, Solaris, HP/UX.
8.1.5.5. Решения компании ComputerAssociates
Компания ComputerAssociatesInternational включила средства интеграции с Web- технологией в новый выпуск OpenIngres 2.0. В дополнение к существовавшей в предыдущих версиях системы возможности устанавливать связь между Web- сервером и сервером баз данных на основе CGI, в выпуске 2.0 реализованы встроенные интерфейсные средства для связи с Web-серверами компаний
Microsoft, Netscape и Spyglass. Новый макропроцессор позволяет встраивать операторы SQL прямо в HTML-страницы. Во время работы Web-сервер обращается с такими операторами к OpenIngres.
8.1.5.6. Решения компании Microsoft
Компания Microsoft поставляет целый ряд продуктов, предназначенных для разработки Web-приложений, работающих с базами данных. Большая часть этих продуктов входит в состав крупных серверных средств.
В состав MicrosoftSQLServer входит средство SQLServerWebAssistant. Основное назначение этого средства - формировать динамическую HTML-страницу на основе результата SQL-оператора выборки из базы данных.
Внутренним компонентом MicrosoftInternetInformationServer является
InternetDatabaseConnector (IDC). Фактически, этот компонент является встроенным шлюзом с SQL-сервером. Получая от браузера HTML-страницу
(например, заполненную форму), IDC обращается к SQL-серверу с соответствующим запросом. После получения результатов IDC формирует возвращаемую пользователю HTML-страницу. Другим ключевым компонентом
InformationServer является ActiveServerPages (ASP). Это средство позволяет встраивать в HTML-страницы скрипты, написанные на языках
VisualBasicScriptingLanguage и Jscript, которые могут производить доступ к ресурсам (приложениям, базам данных и т.д.), расположенным на локальном
InformationServer или на других серверах.

8.2. Склады данных и системы оперативной аналитической обработки

В этом разделе мы рассмотрим вопросы организации специального класса информационных приложений, ориентированных не на оперативную обработку транзакций (onLineTransactionProcessing - OLTP), а на оперативную аналитическую обработку (OnLineAnalyticalProcessing - OLAP). Значимость аналитических систем непрерывно возрастает. Любая серьезная компания независимо от вида ее бизнеса нуждается не только в непрерывной оперативной транзакционной поддержке, но и в средствах анализа и прогнозирования как своей собственной деятельности, так и деятельности своих поставщиков, потребителей, партнеров и конкурентов.
8.2.1. Чем отличаются системы оперативной обработки транзакций и системы оперативной аналитической обработки?
У этих двух разновидностей систем принципиально разные задачи.
Корпоративные информационные OLTP-системы создаются для того, чтобы способствовать повседневной деятельности корпорации, и опираются на актуальные для текущего момента данные. OLAP-системы служат для анализа деятельности корпорации или ее компонентов и прогнозирования будущего состояния. Для этого требуется использовать многочисленные накопленные данные о деятельности корпорации в прошлом, а также внешние источники данных, формирующие контекст, в котором работала корпорация.
Система оперативной аналитической обработки данных отличается от статической системы поддержки принятия решений (DecisionSupportSystem -
DSS) тем, что OLAP-система позволяет аналитику динамически формировать класс вопросов, который требуется для решаемой им текущей аналитической задачи. DSS обеспечивает выдачу отчетов в соответствии с заранее сформулированными правилами. Для удовлетворения нового запроса нужно формально его описать, запрограммировать и только потом выполнить.
Тематика OLAP-систем очень широка и специальна. Мы не будем обсуждать соответствующие вопросы на глубоком уровне, а в основном (и тоже не очень глубоко) сосредоточимся на проблемах обеспечения OLAP-системы данными. Мы будем говорить о складах данных (Datawarehouse).
8.2.2. Что вызвало появление понятия склада данных?
Любая крупная и давно существующая корпорация обладает несколькими базами данных, относящимися к разным видам деятельности. Данные могут иметь разные представления, а иногда могут быть даже несогласованными (например, из-за ошибки ввода в одну из баз данных). Это нехорошо даже для OLTP-систем (в частности, с этой проблемой связаны потребности в интеграции корпоративных информационных OLTP-систем) и в принципе непригодно для OLAP-систем, которые должны обрабатывать общие исторические согласованные корпоративные данные. Более того, для оперативной аналитической обработки требуется привлечение внешних источников данных, которые тем более могут обладать разными форматами и требовать согласования. Видимо, на подобных рассуждениях и возникла концепция склада данных как предметно- ориентированного, интегрированного, неизменчивого, поддерживающего хронологию набора данных, организованного для целей поддержки управления.
Заметим, что подход построения склада данных для интеграции неоднородных источников данных принципиально отличается от подхода динамической интеграции разнородных баз данных. В случае склада данных реально строится новое крупномасштабное хранилище, управление данными в котором происходит, вообще говоря, по другим правилам, нежели в исходных оперативных базах данных.
Итак, в основе концепции склада данных лежат две основные идеи:

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

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

. неоднородность программной среды;

. распределенный характер организации;

. повышенные требования к безопасности данных;

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

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

. Описания структур данных, их взаимосвязей.

. Информация о хранимых на складе данных и поддерживаемых им агрегатах данных.

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

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

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

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

. Статистические оценки времени выполнения запросов. До выполнения запроса полезно иметь хотя бы приблизительную оценку времени, которое потребуется для получения ответа, и объема этого ответа.
Уже сейчас известны примеры складов данных, содержащих терабайты информации. По данным консалтинговой компании MetaGroup, около половины корпораций, использующих или планирующих использовать склады данных предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается.
Последнее, на чем мы остановимся в этом разделе, - это рынки данных
(DataMart; кстати ведущий специалист Московского отделения компании
Informix Ховард Залкин предпочитает называть их "лавками данных"). Рынок данных по своему исходному определению - это набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, рынок данных - это облегченный вариант склада данных, содержащий только тематически объединенные данные.
Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Рынок данных, естественно, существенно меньше по объему, чем корпоративный склад данных, и для его реализации не требуется особо мощная вычислительная техника.
8.2.4. Насколько склады данных могут поддерживаться существующими серверами реляционных баз данных?
В последнее время все более популярной становится идея совместить концепции склада и рынка данных в одной реализации и использовать склад данных в качестве единственного источника интегрированных данных для всех рынков данных. Тогда естественной становится такая трехуровневая организация OLAP- системы:

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

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

Рекомендуем скачать другие рефераты по теме: реферат религия, оценка дипломной работы.



Предыдущая страница реферата | 11  12  13  14  15  16  17  18  19  20  21 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки