Системы управления базами данных (I часть) Распределенные БД. Хранилища данных. Обзор современных СУБД и средств автоматизированного проектирования БД.
Лекции доступны на сайте www. ucit. ru В разделе сайта: Профессиональная переподготовка Рабочие программы
Разделение ресурсов В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах. Развитие этой идеи приводит к функциональному выделению компонентов сети: разумно иметь не только доступ к ресурсами удаленного компьютера, но также получать от этого компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства для обеспечения которого нецелесообразно дублировать в нескольких узлах. Так мы приходим к различению рабочих станций и серверов локальной сети.
Рабочие станции Рабочая станция предназначена для непосредственной работы пользователя или категории пользователей и обладает ресурсами, соответствующими локальным потребностям данного пользователя. Специфическими особенностями рабочей станции могут быть: 1. объем оперативной памяти (далеко не все категории пользователей нуждаются в наличии большой оперативной памяти), 2. наличие и объем дисковой памяти (достаточно популярны бездисковые рабочие станции, использующие внешнюю память дискового сервера), 3. характеристики процессора и монитора (некоторым пользователям нужен мощный процессор, других в большей степени интересует разрешающая способность монитора, для третьих обязательно требуются средства убыстрения графики и т. д. ). При необходимости можно использовать ресурсы и/или услуги, предоставляемые сервером.
Сервер локальной сети Сервер локальной соответствующими сети его должен обладать функциональному ресурсами, назначению и потребностям сети. Заметим, что в связи с ориентацией на подход открытых систем, правильнее говорить о логических серверах (имея в виду набор ресурсов и программных средств, обеспечивающих услуги над этими ресурсами), которые располагаются не обязательно на разных компьютерах. Особенностью логического сервера в открытой системе является то, что если по соображениям эффективности сервер целесообразно переместить на отдельный компьютер, то это можно проделать без потребности в какой-либо переделке как его самого, так и использующих его прикладных программ.
Примеры серверов 1. сервер телекоммуникаций, обеспечивающий услуги по связи данной локальной сети с внешним миром; 2. вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях; 3. дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциями и, возможно, другим серверам; 4. файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций; 5. сервер баз данных - фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты. Сервер локальной сети предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам. Принято называть клиентом локальной сети компонент, запрашивающий услуги у некоторого сервера и сервером - компонент локальной сети, оказывающий услуги некоторым клиентам.
СУБД по способу доступа к БД: Файл-серверные Клиент-серверные Архитектура «файл-сервер» не имеет сетевого разделения компонентов диалога и использует компьютер для функции отображения, что облегчает построение графического интерфейса. «Файл-сервер» только извлекает данные из файлов, так что дополнительные пользователи добавляют лишь незначительную нагрузку на ЦП и каждый новый клиент добавляет вычислительную мощность сети. Минус: высокая загрузка сети состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файлсерверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Минус: сам факт существования сервера и больших вычислительных ресурсов, потребляемых сервером.
Файл-серверные СУБД. БД может располагаться на файл-сервере или нескольких файлсерверах, в качестве которого может использоваться либо специально выделенный компьютер, либо одна из объединенных в сеть мощных ПЭВМ. Функции файл-сервера заключаются в основном в хранении БД и обеспечении доступа к ним пользователей, работающих на различных компьютерах. Эти функции обеспечиваются, как правило, той же СУБД, которая работает и на компьютерах пользователей. При небольших объемах данных эта схема вполне удовлетворяет всем современным требованиям, но с увеличением числа компьютеров в сети или ростом БД начинают возникать проблемы, связанные с резким падением производительности. Это связано с увеличением объема данных, передаваемых по сети, так как вся обработка производится на компьютере пользователя. Если пользователю требуется пара строк из таблицы объемом в сотни тысяч записей, то сначала вся таблица с файл-сервера передается на его компьютер, а затем СУБД отбирает нужные записи. В этом случае длительные перерывы в работе можно сильно сократить, перейдя на технологию клиент-сервер.
Технология «клиент-сервер» "Клиент-сервер" - это модель взаимодействия компьютеров в сети. Редко бывает так, чтобы они были совершенно равноправными. Как правило, один компьютер в сети располагает информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие же компьютеры пользуются ими. Компьютер, управляющий тем или иным ресурсом, принято называть СЕРВЕРОМ этого ресурса, а компьютер, желающий им воспользоваться - КЛИЕНТОМ. Конкретный сервер характеризуется видом ресурса, которым он владеет. Если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого - обслуживать запросы клиентов, связанные с обработкой баз данных.
Функции стандартного приложения Один из основных принципов технологии "клиент-сервер" заключается в разделении функций стандартного приложения на три группы, имеющие различную природу. 1. Первая группа - это функция ввода и отображения данных. 2. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области. 3. К третьей группе относятся фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т. д. )
Логические компоненты приложения В соответствии с этим в любом приложении выделяются следующие логические компоненты: oкомпонент представления, реализующий функции первой группы; oприкладной компонент, поддерживающий функции второй группы; oкомпонент доступа к информационным ресурсам или менеджер ресурсов, поддерживающий функции третьей группы.
Существует по меньшей мере три модели «клиент-сервер» 1. Модель доступа к удаленным данным 2. Модель сервера базы данных 3. Модель сервера приложений
В модели доступа к удаленным данным коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки. Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных. Говоря об архитектуре "клиент-сервер", в большинстве случаев имеют в виду именно эту модель.
Модель сервера базы данных строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах, которые также называют компилируемыми резидентными процедурами, или процедурами базы данных. Они хранятся непосредственно в базе данных и выполняются на компьютере - сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД). Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика модели сервера баз данных - имеется пока только в СУБД, да и то не во всех.
В модели сервера приложений процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (то есть реализует функции первой группы). Прикладные функции выполняются группой процессов (серверов приложений), функционирующих на удаленном компьютере (или нескольких компьютерах). Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается ровно тем же способом, что и в первой модели. Из прикладных компонентов доступны ресурсы различных типов - базы данных, индексированные файлы, очереди и др. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, однако могут выполняться и на других компьютерах.
Архитектура "клиент-сервер" Распределенные системы - это системы "клиент-сервер". Технология клиент-сервер разделяет приложение на две части, используя лучшие качества обеих сторон. Front-end (клиентская часть) обеспечивает интерактивный, легкий в использовании, обычно графический интерфейс - находится на компьютере пользователя. Back-end (сервер) обеспечивает управление данными, разделение информации, изощренное администрирование и безопасность - находится на специально выделенных компьютерах или даже мейн-фреймах. При технологии клиент-сервер клиентское приложение формирует запрос к серверу БД, на котором выполняются все команды. Результаты команд посылаются затем клиенту для просмотра и использования. Обычно клиент посылает запросы базе данных в виде предложений на языке структурированных запросов (SQL), используя понятный серверу базы данных диалект.
Системная архитектура "клиентсервер" Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Интерфейс серверной части определен и фиксирован. Основной проблемой систем, основанных на архитектуре "клиентсервер", является то, что в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. В разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т. д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования. Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду
Серверы баз данных Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В идеале, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел. Очевидный недостаток: при таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы. В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL. o Включение в состав клиентской части системы некоторых функции для работы с "локальным кэшем" базы данных, т. е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов. o Перенос большей части прикладной системы на сторону сервера, если разница в мощности клиентских рабочих станций и сервера чересчур велика. При использовании RPC это сделать нетрудно. Но требуется, чтобы базовое программное обеспечение сервера действительно позволяло это. При использовании ОС UNIX проблемы практически не возникают. 2 НФ
Основные принципы функционирования модели сервера баз данных Эта модель реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования ядра СУБД. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Попытки стандартизации языка SQL, касающиеся хранимых процедур, пока не привели к ощутимому успеху. Кроме того, во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, нежели выполнение программ, написанных на языках третьего поколения. Механизм хранимых процедур - один из составных компонентов активного сервера базы данных.
Преимущества модели сервера баз данных 1. возможность централизованного администрирования бизнес-функций, 2. снижение трафика сети, 3. возможность разделения процедуры между несколькими приложениями, 4. экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.
Недостатки модели сервера баз данных 1. Средства, используемые для написания хранимых процедур, строго говоря, не являются языками программирования в полном смысле слова. Это - разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения (C или Pascal). Они встроены в конкретные СУБД, и рамки их использования ограничены. Система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. 2. В большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что превращает последние в весьма опасный механизм.
Недостатки модели сервера баз данных 3. Модель сервера баз данных не обеспечивает требуемой эффективности использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т. д. ) пока не позволяют добиться желаемого эффекта. 4. Децентрализация приложений (один из ключевых факторов современных информационных технологий) требует существенного разнообразия вариантов взаимодействия клиента и сервера. При реализации прикладной системы могут понадобиться такие механизмы взаимодействия, как хранимые очереди, асинхронные вызовы и т. д. , которые в этой модели не поддерживаются.
Модель сервера приложений (трехуровневая модель) Основным элементом в такой модели является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения. Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. Клиент приложения обращается с запросом к конкретной службе, но не к серверу приложений, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от клиентов приложений, выстраиваются в очередь к процессу сервера приложений, который извлекает и передает их для обработки службе в соответствии с приоритетами.
Классическая трехуровневая архитектура «клиент-сервер» Сервер приложений
WEB-ориентированная трехуровневая архитектура «клиент-сервер» Сервер приложений Промежуточное программное обеспечение
Промежуточное звено Промежуточное ПО (ППО) – это слой ПО, находящийся между клиентом и сервером. Одно из главных обоснований ППО – обеспечение независимости внешнего приложения от БД. В этом случае клиент может использовать собственный язык высокого уровня или протокол взаимодействия с ППО. Это позволяет обеспечить простую замену одной СУБД на другую и оградить клиентское ПО от изменений вносимых в структуру БД на сервере.
Интерфейсы доступа к данным Важнейшим этапом в построении приложений клиент-сервер является установка связи клиентского приложения с источником данных, находящимся на сервере. Клиентское приложение, даже самое хорошее с точки зрения дружественности и простоты, ничто без связывающего слоя интерфейса прикладных программ (API - Application Programming Interface) обеспечивающего доступ к данным в таблицах БД и скрывающего от клиента особенности операционной системы и сети. Во многих случаях от разработчика скрыт даже и API, а доступны только функции средства разработки. Наличие такого API позволяет использовать стандартные инструментальные средства и существенно упрощает процесс разработки приложения.
Интерфейсы доступа к данным Среди разработчиков, использующих язык Java, в качестве общего интерфейса доступа к БД принят JDBC. Классы JDBC скрывают от разработчика сложности целевой БД и позволяют использовать любую БД без потребности понимания ее специфических особенностей. К наиболее популярным интерфейсам относятся ODBC, OLE DB и Active. X Data Object (ADO) компании Microsoft. ODBC и OLE DB – это API Window для доступа к данным. Более старая спецификация ODBC обеспечивает доступ прежде всего к реляционным БД, основанным на использовании языка SQL. OLE DB – это спецификация следующего поколения Microsoft, которая позволяет осуществлять доступ к данным через провайдеров, которые могут включать нереляционные БД.
Серверы баз данных обеспечивают надежный доступ к разделяемым данным для программ-клиентов, которые обращаются к функциям СУБД. Обычно клиенты по вычислительной сети посылают запросы серверу в форме предложений на языке SQL. Сервер интерпретирует их и пересылает соответствующие данные обратно клиенту. Серверы реляционных и нереляционных баз данных могут быть различного вида и масштабов. Большинство программ-серверов баз данных – такие, как Oracle - выполняются на выделенных машинах. При этом серверы баз данных работают на разнообразных процессорах и в различных операционных средах. Следовательно, у создателей систем клиент-сервер имеется выбор для удовлетворения потребностей прикладных программ. Пример. Oracle работает на большинстве RISC- и CISC-ориентированных Unix -системах, включая HP/UX фирмы Hewlett-Packard и Solaris компании Sun. Кроме того, Oracle выполняется на серверах, использующих процессоры Intel под управлением SCO Unix и Netware компании Novell.
Функции сервера 1. Серверы баз данных занимаются обслуживанием данных. 2. В них предусмотрены также механизмы блокировок и элементы управления многопользовательским доступом, которые обеспечивают защиту данных от опасности параллельного доступа. 3. Серверу баз данных приходится ограждать данные от несанкционированного доступа, оптимизировать запросы к базе данных, обеспечивать кэширование и предоставлять место для размещения словаря данных. 4. Способность сервера обеспечивать целостность ссылочных данных. Ссылочная целостность данных - это механизм, обеспечивающий каждому внешнему ключу соответствующий первичный ключ. 5. Обеспечение обоюдного контроля завершения транзакции. Обоюдный контроль завершения транзакций - гарантия того, что ваши данные не будут повреждены даже при аппаратном сбое.
Программа непосредственно самого сервера баз данных С помощью хранимых процедур, триггеров и правил, разработчики могут составить программу непосредственно самого сервера баз данных и, таким образом, появляется еще одно место для размещения логики программы. Хранимые процедуры - это группа предложений на языке SQL и процедурная логика, которые разработчики могут компилировать и хранить на сервере баз данных в качестве объектов. Программы-клиенты способны выполнять хранимые процедуры, также как и другой вид хранимых процедур или триггеров, путем посылки сообщений серверу баз данных. Триггеры - это хранимые процедуры, которые активизируются автоматически, как только серверу баз данных встречается связанное с данными событие. Правило - это специальный тип триггера, который проверяет данные до внесения их в базу данных. Большая часть имеющихся на данный момент хранимых процедур, триггеров и правил обладает весьма узкой специализацией и отличающимися возможностями. Более того, расширения процедур SQL у разных изготовителей разные.
Средства разработки прикладных программ Назначение всякого инструмента для разработки систем клиент-сервер - ускорить и упростить процесс их создания. С помощью средств быстрой разработки приложений (Rapid application development - RAD) можно создавать программы со встроенными средствами связи с любым числом серверов баз данных. На этом быстрорастущем рынке конкурируют сотни инструментальных комплектов для архитектуры «клиент-сервер» . Ряд лучших средств для разработки клиентов Microsoft Windows представлены пакетами Delphi Client/Server Suite компании Borland, Enterprise Developer фирмы Symantec, Power. Builder компании Power. Soft, SQLWindows 5 фирмы Gupta и Visual Basic корпорации Microsoft. В каждом инструментальном комплекте используется собственный подход, но большинство из них обладает одинаковым набором основных функций: промежуточное обеспечение для баз данных, возможность конструирования баз данных, репозиторий (хранилище), возможности объектно-ориентированной разработки, конструкторы ГИП, язык программирования высокого уровня и механизмы распределения прикладных программ.
Репозитории (хранилища) Репозитории - это места хранения многими средствами разработки важной для прикладной программы информации об элементах базы данных. Кроме основной информации, в репозитории могут находиться правила предметной области (бизнес-правила), связанные с каким-либо элементом данных. Как только разработчик вводит в репозиторий информацию, с помощью имеющегося у средства разработки механизма наследования повсюду в программе этот элемент данных автоматически приобретет указанные свойства. В основном, инструментальные комплекты создают репозитории автоматически по умолчанию, используя расположенную на сервере физическую схему базы данных. Основой для построения средств быстрой разработки приложений служит концепция репозитория, согласно которой элементы данных приобретают свои свойства с помощью механизма наследования. При формировании сред разработки все эти средства исходят из своего собственного представления объектно-ориентированной модели. В большинстве из них предусмотрены механизмы наследования, полиморфизма и инкапсуляции, но каждый делает это по-своему (простое наследование, при котором изменения в родительском объекте автоматически распространяются на его потомка; множественное наследование , при котором методы и данные двух объектов передаются одному объекту).
Возможности конструирования прикладных программ Почти во всех средствах предусмотрено простое в использовании графическое изображение физической структуры базы данных, используемое разработчиком при создании или изменении структуры базы данных. С его помощью разработчики выполняют такие операции, как добавление элементов в базу данных, связывание таблиц и пересылка изменений серверу баз данных в форме SQL-предложений. 1. Концепция репозитория; 2. Конструкторы интерфейсов, с помощью которых разработчики создают окна данных, формы ввода данных, меню и другие компоненты ГИП прикладных программ. В конструкторах интерфейсов представлена палитра стандартных элементов, которые разработчики могут с помощью мыши переносить в создаваемые окна. В большинстве средств число управляющих элементов можно увеличить, используя полученные от независимых поставщиков элементы 3. Языки программирования. Во всех комплектах имеется какой-либо гибкий язык программирования высокого уровня (4 GL). В некоторых комплектах применяются языки более низкого уровня 3 GL. 4. Распределение прикладных программ по конечным пользователям
Распределенные базы данных Под распределенной (Distributed Data. Base - DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику. ("распределенность" базы данных невидима извне).
Определение Дэйта. 12 свойств или качеств идеальной распределенной БД 1. Локальная автономия 2. Независимость узлов 3. Непрерывные операции 4. Прозрачность расположения 5. Прозрачная фрагментация 6. Прозрачное тиражирование 7. Обработка распределенных запросов 8. Обработка распределенных транзакций 9. Независимость от оборудования 10. Независимость от операционных систем 11. Прозрачность сети 12. Независимость от баз данных
Локальная автономия Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы.
Независимость от центрального узла В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа.
Непрерывные операции Это качество можно трактовать как возможность непрерывного доступа к данным (известное "24 часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно".
Прозрачность расположения Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.
Прозрачная фрагментация Это свойство трактуется как возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: Горизонтальная - хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вертикальная - распределение столбцов логической таблицы по нескольким узлам.
Пример Пусть фирма имеет базы данных в разных местах. Допустим, имеется таблица Сотрудники (Код_сотр, ФИО_сотр, Телефон), определенная в базе данных на узле в Новосибирске. Имеется точно такая же таблица, определенная в базе данных на узле в Академгородке. Кроме того, в базе данных на узле в Бердске определена таблица Зарплата_сотрудников (Код_сотр, сумм_зарпл). Тогда запрос "получить информацию о сотрудниках фирмы" может быть сформулирован так: SELECT * FROM Сотрудники@Новосибирск, Сотрудники@Академгородок ORDER BY Код_сотр В то же время запрос "получить информацию о заработной плате сотрудников компании" будет выглядеть следующим образом: SELECT Сотрудники. Код_сотр, ФИО_сотр, сумм_зарпл FROM Сотрудники@Новосибирск, Сотрудники@Академгородок, Зарплата_сотрудников @Бердск ORDER BY Код_сотр
Прозрачность тиражирования Тиражирование данных - это асинхронный (в общем случае) процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном контексте прозрачность тиражирования означает возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.
Обработка распределенных запросов o. Это свойство DDB трактуется как возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных. Например, SELECT Имя_пост, Адрес_пост, Номер_заказа, Дата_заказа FROM Поставщики@Москва, Заказы@Новосибирск WHERE Поставщики. Номер_пост = Заказы. Номер_заказа
Обработка распределенных транзакций Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазового или двухфазного протокола фиксации транзакций, ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.
Независимость от оборудования Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".
Независимость от операционных систем Это качество вытекает из предыдущего и означает многообразие операционных систем, управляющих узлами распределенной системы.
Прозрачность сети Доступ к любым базам данных может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы.
Независимость от баз данных Это качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.
Исходя из определения Дэйта, можно рассматривать DDB как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами - это потоки тиражируемых данных. Топология DDB варьируется в широком диапазоне - возможны варианты иерархии, структур типа "звезда" и т. д. В целом топология DDB определяется географией информационной системы и направленностью потоков тиражирования данных
OLTP и OLAP системы Выделяют два класса систем, для которых в большей степени подходят сильно и слабо нормализованные отношения. 1. Сильно нормализованные модели данных хорошо подходят для OLTPприложений – On-Line Transaction Processing (OLTP) – приложений оперативной обработки транзакций. Типичными примерами OLTPприложений являются системы складского учета, заказов билетов, операционные банковские системы
OLTP системы Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно, и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Таким образом, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений.
OLTP и OLAP системы 2. Другим типом приложений являются OLAP-приложения – On-Line Analitical Processing (OLAP) – приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений – Decision Support System (DSS), хранилищ данных – Data Warehouse, систем интеллектуального анализа данных – Data Mining.
OLAP системы Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу «что если…» и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками: • добавление в систему новых данных происходит относительно редко крупными блоками, например, один раз в месяц или квартал; • данные, добавленные в систему, как правило, никогда не удаляются; • перед загрузкой данные проходят различные подготовительные процедуры, связанные с приведением их к определенным форматам и тому подобное; • запросы к системе являются нерегламентированными и достаточно сложными; • скорость выполнения запросов важна, но не критична.
Хранилища данных – это особый вид программных решений, предназначенный для сбора, интеграции и анализа данных. Они строятся по принципам, отличным от принятых при разработке учетных и OLАP-систем. Как следствие, решать задачи, связанные с анализом информации, с помощью ХД гораздо более эффективно, чем при использовании других программ. Одно только разделение учетной и аналитической информации дает огромное преимущество. Пример: формирование отчетов. Раз в месяц, ежеквартально и ежегодно все банки подготавливают довольно большой объем отчетных форм для предоставления в Банк России – в общей сложности за весьма короткий промежуток времени создается почти сотня разнообразной отчетности. Как банки с этим справляются? Большинство старается готовить нужную отчетность либо в ночное время, либо на отдельной копии автоматизированной банковской системы (АБС). Поэтому при формировании отчетов нагрузка на банковскую учетную систему столь высока, что выполнять в ней текущие операции весьма проблематично. Задача решается использованием ХД.
Именно менеджеры компании – главные пользователи систем, построенных по технологии ХД и OLAP-приложений. Ведь конечная цель применения аналитических систем – повышение эффективности управления предприятием. Поэтому интерфейс таких систем (средства работы конечного пользователя) делается максимально простым и интуитивно понятным. ХД - «предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки управления» (90 -е годы, У. Инмон). Возникает вопрос, как выглядит типичная инфраструктура компании, готовой применить ХД на практике, сколько людей потребуется для обработки данных, как оптимально организовать их хранение? Здесь общие оценки дать трудно. Объем ресурсов, которые могут потребоваться, зависит от задач, стоящих перед предприятием, и от конкретного инструментального решения.
Необходимость использования ХД 1. Автоматизация сбора и интеграции данных; 2. Приведение их к единой системе понятий; 3. Сверка и согласование данных; 4. Территориальная распределенность системы; 5. Признак разнообразия программных средств, эксплуатирующихся на предприятии. ; 6. Диверсификация компании, то есть разнообразие видов ее деятельности. Чем их больше, тем сложнее оценить вклад каждого в общий доход компании; 7. Разнообразие типовых клиентов компании или сегментов постоянной клиентской базы. Оценить вклад того или иного сегмента клиентской базы, конкретного продукта или подразделения в прибыль зачастую довольно сложно; 8. Необходимость в обработке больших объемов информации с целью выявить и понять закономерности происходящих событий, их взаимное влияние и составление прогнозов.
Каждое подразделение ежедневно высылает в центральный офис отчет заранее утвержденной формы. Данные преобразуются к единому виду и переносятся в хранилище данных. Для решения проблемы различного представления данных в различных системах нужен перекодировщик. • различные программы по-разному хранят информацию. • разные единицы измерения информации • люди, допускающие ошибки
Плюсы внедрения ХД Как только были получены описанные результаты, стало возможным и применение различного аналитического аппарата – OLAP, регулярные отчеты, прогнозирование. Кроме того, попутно было достигнуто еще несколько целей: 1. Все пользователи информации о товародвижении стали получать ее из единого места в одинаковом виде. Была, наконец, решена проблема несоответствия терминологий, когда под отгрузкой они понимали отпуск товара третьим лицам, вторые – все, что ушло со склада, а третьи – все, что проведено бухгалтерией. 2. Информация поступает оперативно. Отчеты поступают ежедневно. 3. Всегда можно поднять данные за любой промежуток времени. 4. Наконец, с данными очень удобно работать.
Введение в CASE-технологии Современные крупные проекты ИС характеризуются, как правило, следующими особенностями: 1. сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов; 2. наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема); 3. отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем; 4. необходимость интеграции существующих и вновь разрабатываемых приложений;
5. функционирование в неоднородной среде на нескольких аппаратных платформах; 6. разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; 7. существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Ручная разработка обычно порождала следующие проблемы: 1. неадекватная спецификация требований; 2. неспособность обнаруживать ошибки в проектных решениях; 3. низкое качество документации, снижающее эксплуатационные качества; 4. затяжной цикл и неудовлетворительные результаты тестирования
Перечисленные факторы способствовали появлению программнотехнологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Факторы, предшествующие появлению CASE-технологий 1. подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования; 2. широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования; 3. внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Предупреждение 1. CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время; 2. реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение; 3. CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.
Факторы, усложняющие определение возможного эффекта от использования CASE -средств 1. широкое разнообразие качества и возможностей CASE-средств; 2. относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения; 3. широкое разнообразие в практике внедрения различных организаций; 4. отсутствие детальных метрик и данных для уже выполненных и текущих проектов; 5. широкий диапазон предметных областей проектов; 6. различная степень интеграции CASE-средств в различных проектах.
Для успешного внедрения CASEсредств организация должна обладать следующими качествами: 1. Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию; 2. Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями; 3. Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.
Проблемы перехода к CASEтехнологиям 1. достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО; 2. внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения; 3. отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям; 4. CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;
5. некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение; 6. негативное отношение персонала к внедрению новой CASEтехнологии может быть главной причиной провала проекта; 7. необходимость долгосрочных затрат на эксплуатацию; 8. частое появление новых версий и возможное быстрое моральное старение средств; 9. постоянные затраты на обучение и повышение квалификации персонала
Успешное внедрение CASE-средств должно обеспечить такие выгоды как: 1. высокий уровень технологической поддержки процессов разработки и сопровождения ПО; 2. положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование; 3. приемлемый уровень отдачи от инвестиций в CASE-средства.
Некоторые примеры SADT - методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители. Возникла в конце 60 -х годов. Базовой книгой по этому вопросу является: Дэвид А. Марка, Клемент Мак. Гоуэн "Методология структурного анализа и проектирования"(размер файла 3, 7 мб). Очень хорошая книга, с подробными примерами. IDEF 0 - методология функционального моделирования. Применяется для описания рабочих процессов (Work Flow). Разработана на основе SADT. По сути одно и тоже. Для изучения могу рекомендовать книгу: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF 0. Руководящий документ. РД IDEF 0 - 2000". Это стандарт. Неплохо изложен и, главное, по-русски. Хотя, как всякий стандарт, он сильно формализован. По сути, он является точной копией американского стандарта "INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF 0) 1993 December 21 ".
DFD - методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами. IDEF 3 - методология моделирования потоков работ. Является более детальной по отношению к IDEF 0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. IDEF 1 X - методология описания данных. Применяется для построения баз данных. IDEF 4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектноориентированных языках (например С++). Пока, на мой взгляд, широкого распространения не нашла. Более широко сейчас используется UML. ARIS - описывает бизнес-процесс в виде потока последовательно выполняемых работ. Ее использует программное средство ARIS Toolset. UML - (Unified Modeling Language) язык визуального моделирования, основанный на объектно-ориентированном подходе. UML включает в себя двенадцать типов диаграмм, которые позволяют описать статическую структуру системы и ее динамическое поведение.
Средства построения схем Platinum BPwin или, как он теперь называется, All Fusion Process Modeller. Поддерживает нотации IDEF 0, DFD, IDEF 3. Описание BPWin имеется на страничке http: //www. interface. ru/ca/bpwin. htm. Средство удобное, с интуитивно понятным интерфейсом. Позволяет строить иерархию диаграмм. Большой недостаток в том, что созданные объекты нельзя перемещать мышью в другие диаграммы на другой уровень. Нельзя также копировать, т. к. они должны быть уникальными. В результате нельзя создавать стандартные операции. Rational Rose - средство моделирования компании Rational Software. Использует объектно-ориентированный подход и, в частности, UML. Является частью мощного пакета Rational, включающего целый ряд компонентов, которые позволяют провести разработку, начиная от концептуальной модели, до программного кода. Имеет удобный современный интерфейс.
Скачать презентацию Системы управления базами данных I часть Распределенные БД
управление базами данных.ppt