5)Пользователи.
Админы данных (АД) отвечают за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, бизнес-правил и деловых процедур, также за концептуальное и логическое проектирование базы данных, контролирует соответствие общего направления развития БД корпоративным целям. Админ баз данных (АБД) отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение сохранности и целостности данных, за сопровождение операционной системы, за обеспечение наибольшей производительности приложений. Создатели баз данных: Можно выделить два типа разработчиков: создатели логической базы данных и создатели физической базы данных. Разработчик логической БД занимается идентификацией данных (другими словами сущностей и их атрибутов), связей меж данными. Разработчик физической базы данных выполняет физическую реализацию: занимается преобразованием логической модели данных в набор таблиц и ограничений целостности, выбором структур хранения и способов доступа к данным, проектированием всех требуемых мер защиты данных (во многом все это определяется избранной СУБД). Прикладные программеры занимаются разработкой приложений, предоставляющих юзерам нужные многофункциональные способности. Пользователи являются потребителями БД. Можно условно их поделить на две подгруппы: «опытные пользователи» - знакомы со структурой БД, могут применять языки, создавать собственные приложения; «наивные пользователи» обращаются к базе данных при помощи особых приложений, используя меню и простые команды.
Функции СУБД.
1)Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы).
2)Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти.
3)Управление транзакциями. Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций.
4)Журнализация. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД.
5)Поддержка языков БД. Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка -язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
Серверы баз данных.
Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Сервер баз данных (database server) обслуживает базы данных и обеспечивает целостность и сохранность данных при их хранении, а также операциях ввода-вывода при доступе клиента к информации. Сервер базы данных - один из ключевых компонентов в архитектуре вычислительной сети типа "клиент-сервер", в которой пользовательский интерфейс располагаются на менее мощной машине-клиенте, а функции Систему Управления Базами Данных (СУБД) размещены на мощном сервере. Сервер баз данных работает под управлением серверной операционной системы и получает клиентские запросы на языке SQL. Серверам баз данных требуется большая мощность, так как на них ложится задача не только по хранению информации, но и работа с базами данных организации, обработка запросов пользователей, резервное копирование и прочие задачи. Поэтому они оснащены новейшими высокопроизводительными четырехядерными процессорами Intel® Xeon® Processor, которые позволяют поднять работу с базами данных на новый уровень. Серверы баз данных Talisman Absolute имеют системы защиты данных: RAID-массивы различных уровней, «горячая» замена жестких дисков, а старшие модели и блоки питания с «горячей» заменой, а также зеркалированием плат памяти и дополнительными батареями защиты данных на раид-контроллерах. Опционально данные серверы могут монтироваться в 19 дюймовую стойку.
Метаданные. Ссылочная целостность. Механизм транзакций.
Метаданные (от греч. Meta и лат. Data), буквально переводится как «данные о данных», информация о другом наборе данных. Метаданные — это структурированные, кодированные данные, которые описывают характеристики объектов-носителей информации, способствующие идентификации, обнаружению, оценке и управлению этими объектами. Обычно невозможно провести однозначное разделение на данные и метаданные в документе, поскольку: 1)что-то может являться как данными, так и метаданными. Так, заголовок статьи можно одновременно отнести как к метаданным (как элемент метаданных — заголовок), так и к собственно данным (поскольку заголовок является частью самого текста); 2)данные и метаданные могут меняться ролями. На стихотворение, рассматриваемое как данные, может быть написана музыка, в этом случае всё стихотворение может быть «прикреплено» к музыкальному файлу и в этом случае рассматриваться как метаданные. Таким образом, отнесение к одной или другой категории зависит от точки зрения (или пространства имён, системы отсчёта).
Классификация метаданных:
1)Метаданные описания контента. Контентные метаданные охватывают описание всех аспектов данного информационного объекта, как отдельной сущности. Иногда их дополнительно подразделяют на структурные и описательные.
2)Административные метаданные. Административные метаданные объединяют различные группы и отличаются большим разнообразием.
Ссылочная целостность – это ограничение базы данных, гарантирующее, что ссылки между данными являются действительно правомерными и неповрежденными. Ссылочная целостность является фундаментальным принципом теории баз данных и проистекает из той идеи, что база данных должна не только сохранять данные, но и активно содействовать обеспечению их качества. Ссылочной целостностью называют особый механизм, осуществляемый средствами СУБД или программистом, ответственный за поддержание непротиворечивых данных в связанных релятивными отношениями таблицах. Ссылочная целостность подразумевает, что в таблицах, имеющих релятивные связи, нет ссылок на несуществующие записи.
Транзакция – группа операций, которые необходимо выполнить последовательно как единое целое. Механизм транзакций используется для поддержания целостности БД: транзакция переводит БД из одного целостного состояния в другое. Транзакция может быть явной и неявной. Неявная транзакция запускается и завершается автоматически, явной транзакцией управляет программист.
Свойства транзакций:
1.атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.
2.согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных.
3.изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.
4.долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).
Защита данных. Управление транзакциями.
Защита данных - это широкое понятие, включающее в себя комплекс мер, которые препятствуют несанкционированному доступу к чтению и копированию программ, данных и ресурсов. Шифрование (или криптография) - это один из методов защиты, преобразовывающий открытые данные в зашифрованные или наоборот с использованием специальных ключей. Помимо этого, при помощи криптографии можно реализовать электронную подпись для доступа. К шифровальным программам предъявляются некоторые требования. Это высокий уровень защиты против дешифровки и модификации, знание ключа не должно зависеть от знания алгоритма, изменение текста или ключа должно приводить к изменению всего текста ("обвалу"), невозможность подбора ключа путем перебора значений. Программа должна быть устойчива ко всем ресурсам, которые готовы расшифровать текст или ключ. Если вы хотите укрыть только собственные данные, то секретный ключ будет построен под паролем, сложным для подбора.
Под транзакцией понимается выполняемая от имени определённого ID последовательность операций манипулирования данными, переводящая БД из целостного начального состояния в целостное конечное состояние. При этом промежуточные состояния БД не обязательно целостные.
Под управлением транзакциями будем понимать действия системы, направленные на поддержание свойств АСИД. Атомарность обеспечивается специальной подсистемой СУБД, которая называется диспетчером (администратором) транзакций. Для того чтобы транзакция воспринималась системой как логическая единица работы, входной язык должен иметь средства для указания начала и окончания транзакции. Поскольку транзакция может завершиться одним из двух способов - фиксацией или откатом, требуется два различных оператора завершения.
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
Классификация СУБД.
БД - совокупность структурированных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области. СУБД - программный продукт, поддерживающий процессы создания, ведения и использования БД многими пользователями.
По языкам общения: открытые, замкнутые и смешанные. Открытые системы – это системы, в которых для обращения к базам данных используются универсальные языки программирования. Замкнутые системы имеют собственные языки общения с пользователями БнД. Открытые системы в настоящее время используются редко.
По числу уровней в архитектуре: одноуровневые, двухуровневые, трехуровневые системы. В принципе возможно выделение и большего числа уровней. Под архитектурным уровнем СУБД понимают функциональный компонент, механизмы которого служат для поддержки некоторого уровня абстракции данных (логический и физический уровень, а также «взгляд» пользователя – внешний уровень).
По выполняемым функциям: информационные и операционные. Информационные СУБД позволяют организовать хранение информации и доступ к ней. Для выполнения более сложной обработки необходимо писать специальные программы. Операционные СУБД выполняют достаточно сложную обработку, например, автоматически позволяют получать показатели, не хранящиеся непосредственно в базе данных, могут изменять алгоритмы обработки и т.д.
По сфере возможного применения: универсальные и специализированные, обычно проблемно-ориентированные СУБД.
Системы управления базами данных поддерживают разные типы данных. Набор типов данных, допустимых в разных СУБД, различен. В настоящее время наблюдается тенденция к расширению числа используемых типов данных. Кроме того, ряд СУБД позволяет разработчику добавлять новые типы данных и новые операции над этими данными. Такие системы называются расширяемыми системами баз данных. Дальнейшим развитием концепции расширяемых систем баз данных являются объектно-ориентированные системы баз данных, обладающие достаточно мощными выразительными возможностями, чтобы непосредственно моделировать сложные объекты.
По характеру использования: персональные и многопользовательские. Персональные СУБД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Access и др. Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.
Выбор СУБД.
Выбор СУБД представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений БД. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды. Наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. Вообще говоря, перечень требований к СУБД, используемых при анализе той или иной информационной системы, может изменяться в зависимости от поставленных целей. Тем не менее можно выделить несколько групп критериев:
1)Моделирование данных (Используемая модель данных. Распространенные - иерархическая, сетевая, реляционная, объектно-реляционная и объектная. Триггеры и хранимые процедуры. Триггер - программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Хранимая процедура - программа, которая хранится на сервере и может вызываться клиентом. Средства поиска. Предусмотренные типы данных. Здесь следует учесть два фактически независимых критерия: базовые или основные типы данных, заложенные в систему, и наличие возможности расширения типов. Реализация языка запросов.).
2)Особенности архитектуры и функциональные возможности (Мобильность-это независимость системы от среды, в которой она работает. Средой в данном случае является как аппаратура, так и программное обеспечение (операционная система). Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту информационной системы. Распределенность. Сетевые возможности. Многие системы позволяют использовать широкий диапазон сетевых протоколов и служб для работы и администрирования.)
3)Контроль работы системы (Контроль использования памяти компьютера. Система может иметь возможность управления использованием как оперативной памяти, так и дискового пространства. Автонастройка. Многие современные системы включают в себя возможности самоконфигурирования, которые, как правило, опираются на результаты работы сервисов с амодиагностики производительности. Данная возможность позволяет выявить слабые места конфигурации системы и автоматически настроить ее на максимальную производительность.)
4)Особенности разработки приложений (Средства разработки приложений. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также и возможности средств разработки приложений. Средства проектирования. Некоторые системы имеют средства автоматического проектирования, как баз данных, так и прикладных программ. Многоязыковая поддержка. Поддержка большого количества национальных языков расширяет область применения системы и приложений, построенных на ее основе. Возможности разработки Web-приложений. Поддерживаемые языки программирования. Широкий спектр используемых языков программирования повышает доступность системы для разработчиков, а также может существенно повлиять на быстродействие и функциональность создаваемых приложений.)
5)Производительность (Рейтинг TPC (Transactions per Cent). Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является TPC-анализ производительности систем. Фактически TPC анализ рассматривает композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель TPC - это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы. Возможности параллельной архитектуры. Для обеспечения параллельной обработки данных существует, как минимум, два подхода: распараллеливание обработки последовательности запросов на несколько процессоров, либо использование нескольких компьютеров-клиентов, работающих с одной БД, которые объединяют в так называемый параллельный сервер. Возможности оптимизирования запросов. При использовании непроцедурных языков запросов их выполнение может быть неоптимальным. Поэтому необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ выполнения, когда по начальному представлению запроса путем его синтаксических и семантических преобразований вырабатывается процедурный план выполнения запроса, наиболее оптимальный при существующих в базе данных управляющих структурах.)
6)Надежность (Восстановление после сбоев. Резервное копирование. Откат изменений. При выполнении транзакции применяется простое правило - либо транзакция выполняется полностью, либо не выполняется вообще. Это означает, что в случае сбоев, все результаты недоведенных до конца транзакций должны быть аннулированы. Механизм отката может иметь различное быстродействие и эффективность. Многоуровневая система защиты.)
7)Требования к рабочей среде (Поддерживаемые аппаратные платформы. Минимальные требования к оборудованию. Максимальный размер адресуемой памяти. Поскольку почти все современные системы используют свою файловую систему, немаловажным фактором является то, какой максимальный объем физической памяти они могут использовать. Операционные системы, под управлением которых способна работать СУБД.)
8)Смешанные критерии (Качество и полнота документации. Локализованность. Возможность использования национальных языков не во всех системах реализована полностью. Модель формирования стоимости. Стабильность производителя. Распространенность СУБД.)
Централизованная архитектура.
Исторически первыми появились компьютерные системы с ЦА приложений. При использовании этой архитектуры все программное обеспечение (ПО) автоматизированной системы выполняется централизованно на одном компьютере, выполняющем одновременно много задач и поддерживающем большое количество пользователей. На этом компьютере полностью осуществляется процесс ввода/вывода информации, а также ее прикладная обработка. В качестве центрального компьютера для такой системы может применяться либо большая ЭВМ (называемая также майнфреймом) либо так называемая мини-ЭВМ. К подобному комплексу подключаются периферийные устройства для ввода/вывода информации от каждого пользователя. Чаще всего у нас в подобных системах на предприятиях (на Западе это встречается заметно реже) взаимодействие между сотрудниками предприятия и ЭВМ осуществлялось не напрямую, а через операторов ЭВМ, которые получали исходную информацию в бумажном виде, заносили ее в компьютер, а затем передавали пользователям результаты работы программы в виде распечаток. Естественно, что подобный цикл обработки информации требовал многочисленного обслуживающего персонала, занимал длительное время, порождал большое число ошибок и был очень негибким и весьма дорогостоящим. Кроме того, работа в централизованной архитектуре требовала специализированных знаний. А это создавало дополнительный барьер между управленцем и системой автоматизации и усложняло процесс ее адаптации к нуждам пользователей. Поэтому с помощью подобных систем было целесообразно автоматизировать только отдельные процессы в управлении предприятием с очень высокой трудоемкостью ручной обработки информации. К ним относились, как правило, задачи бухгалтерии с очень большим объемом рутинных вычислений. Пользователи могли также осуществлять ввод информации и получение результатов обработки самостоятельно, с использованием алфавитно-цифровых терминалов. В таком варианте централизованные системы существуют и успешно функционируют до сих пор. Есть две главные причины того что системы на больших ЭВМ эксплуатируются до сих пор, несмотря на большие затраты на специализированную аппаратуру и информационные каналы для поддержания надежной связи между каждым терминалом и компьютером.
Во-первых, ЦА при необходимом качестве аппаратуры и ПО очень надежна (особенно в плане целостности данных). Абсолютная производительность майнфреймов не уступает самым большим комплексам в архитектуре клиент-сервер. Большая ЭВМ достаточной мощности может обеспечивать устойчивую работу огромного количества пользователей одновременно.
Во-вторых, затраты на замену подобной системы, включая прямые затраты - на замену аппаратуры и ПО и непрямые затраты - на переподготовку пользователей, перестройку инфраструктуры и изменение технологии обработки информации составляют сумму, огромную даже для крупной западной компании. С другой стороны, по мере распространения архитектуры клиент-сервер появились возможности для ее интеграции с ЦА. Сейчас большинство фирм, выпускающих большие ЭВМ, стали предлагать решения, позволяющие использовать их в качестве серверов в архитектуре клиент-сервер. Подобные гетерогенные (разнородные) комплексы позволяют, во-первых, совместно эксплуатировать централизованные приложения и системы клиент-сервер, а во-вторых, соединяют преимущества распределенной архитектуры с надежностью майнфреймов.
Архитектура "файл-сервер".
Развитие информационных систем потребовало создания аппаратных и программных технологий для одновременного доступа к ресурсам большого числа пользователей. Для решения этой проблемы была предложена и успешно реализована, архитектура файл-сервер. На определенном этапе компьютеризации предприятия эта архитектура соответствует потребностям управления и позволяет создавать приложения, выполняющие задачи масштаба отдела. Архитектура файл-сервер предполагает наличие трех основных компонент: файлового сервера, файлового клиента и набора локальной сети для общения между ними. Файловый сервер - это комплекс аппаратных и программных средств, обеспечивающий совместный доступ к файловым ресурсам (а также к принтерам) через локальную сеть многим пользователям одновременно. Как правило, при построении файлового сервера используется специализированная аппаратура (с большим объемом оперативной памяти, быстродействующими и более надежными внешними устройствами). Файловый сервер функционирует под управлением специализированного ПО - сетевой ОС. В качестве стандарта де-факто на промышленных предприятиях применяется серверная ОС Netware фирмы Novell. Файловый клиент - это набор программного обеспечения, обеспечивающий доступ к файловым ресурсам сервера (или серверов) с ПК. Клиент устанавливается на каждом рабочем месте, с которого должен осуществляться доступ к серверу. Как правило, доступ к ресурсам осуществляется прозрачно для прикладных программ, то есть для пользователя они представляются аналогичными локальным ресурсам его ПК. И наконец, для нормального функционирования файл-серверных приложений, естественно, необходима собственно локальная сеть, соединяющая между собой клиент и сервер. Работоспособность файл-серверного приложения напрямую зависит от надежности и производительности локальной сети. Как следует из самого термина файл-сервер, весь обмен между клиентскими рабочими местами и сервером осуществляется на уровне файлов. Типовые команды, которые передаются серверу в этой архитектуре - это открыть файл, прочитать определенное число байт их файла, записать в файл определенное число байт, закрыть файл. При этом сервер не обладает никакой информацией о содержимом файлов, поэтому всю обработку данных производит клиент. Это негативно на производительность системы.
Как правило, файл-сервер обладает специальными средствами, повышающими надежность хранения данных на сервере и уменьшающими вероятность потери информации после программного или аппаратного сбоя. И наконец, в архитектуре файл-сервер повышается безопасность системы, поскольку, как правило, сервер позволяет предоставлять различный уровень доступа к системе для разных пользователей.
Архитектура "клиент-сервер".
Как и для файл-серверной архитектуры, составными компонентами клиент-серверной архитектуры являются сервер, клиентские места и сетевая инфраструктура. Однако, в отличие от предыдущего случая, сервер здесь яв-ся уже не сервером файлов, а сервером БД или даже сервером приложений, т.о. на сервер ложится не просто хранение файлов, а поддержание БД в целостном состоянии или, в случае сервера приложений, даже выполнение той или иной части прикладной задачи. Естественно, что требования к серверу при этом могут возрастать в разы. С другой стороны, то, что сервер обладает информацией о характере хранимой БД, позволяет намного увеличить эффективность обработки. Поэтому для многих задач автоматизации нагрузка на сервер за счет более оптимального выполнения операций над данными по сравнению с аналогичными файл-серверными приложениями может даже уменьшиться. Соответственно, общение между клиентом и сервером происходит не на уровне файлов, а на уровне обмена запросами. Клиент передает серверу высокоуровневые запросы на получение той или иной информации либо на ее изменение, а сервер возвращает клиенту результаты выполнения запросов. При этом, в отличие от файл-серверной архитектуры, доступ к данным не является прозрачным для пользовательской программы. Поэтому, технология разработки таких приложений принципиально отлична от локальных и файл-серверных систем. На современном этапе сетевое обеспечение для архитектуры клиент-сервер аналогично файл-серверной. Клиент-серверные системы могут строиться с использованием тех же сетевых технологий и на той же сетевой инфраструктуре. Более того, как правило, на предприятии мирно сосуществуют обе эти архитектуры. Это вызвано двумя основными причинами. Во-первых, что на любом предприятии много задач, связанных с хранением и обменом документами, которые представляют собой отдельные файлы, а для них архитектура файл-сервер оптимальна. Во-вторых, файл-серверные задачи в том или ином объеме почти всегда сохраняются в том или ином объеме и эксплуатируются наряду с создаваемыми клиент-серверными приложениями. С точки зрения сетевого взаимодействия принципиально новым в приложениях клиент-сервер является возможность перехода к использованию глобальной сети. Скорость обмена в такой сети может быть на порядок ниже, а расстояния между рабочими местами могут достигать километров и даже десятков километров. Это осуществимо, поскольку в приложениях клиент-сервер объем передаваемой информации может быть радикально сокращен за счет использования высокоуровневых запросов к данным. Но главным изменение, которое может быть осуществлено промышленным предприятием при переходе к клиент-серверной архитектуре - это качественный скачок в масштабах задач, решаемых при компьютеризации, в том, насколько комплексно автоматизируется управление производством, в уровне целостности и достоверности данных, хранимых в информационной системе.
Следует отметить, что появление клиент-серверных приложений на предприятии - процесс трудный и часто болезненный. Причем, помимо решения технических и финансовых проблем, при этом переходе очень важно осуществить изменение самого уровня управления, что влечет за собой огромную организационную работу.
Трехзвенная архитектура "клиент – сервер".
Подходы, реализованные в моделях технологии "клиент – сервер" (FS, RDA, DBS, AS модели).
Выделяются четыре подхода, реализованные в следующих технологиях:
• файловый сервер (File Server — FS);
• доступ к удаленным данным (Remote Data Access — RDA);
• сервер баз данных (Data Base Server — DBS)
• сервер приложений (Application Server — AS).
Файловый сервер (FS) Этот подход является базовым для локальных сетей ПК. Один из компьютеров в сети назначается файловым сервером и предоставляет другим компьютерам услуги по обработке файлов.
Файловый сервер работает под управлением сетевой операционной системы и играет роль компонента доступа к информационным ресурсам (т. е. к файлам). На других ПК в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент (рис).
Протокол обмена при такой схеме представляет собой набор вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.
К недостаткам данной технологии относится низкий сетевой трафик (передача множества файлов, необходимых приложению), – небольшое количество операций манипуляции с данными (файлами), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т. д.
Доступ к удаленным данным
Доступ к удаленным данным (RDA) существенно отличается от FS методом доступа к информационным ресурсам. В данной технологии программы компонента представления и прикладного компонента совмещены и выполняются на компьютере – клиенте. Доступ к информационным ресурсам обеспечивается операторами специального языка (например, языка запросов SQL, если речь идет о базах данных) или вызовами функций специальной библиотеки (если имеется специальный интерфейс прикладного программирования —API).
Запросы к информационным ресурсам направляются по сети удаленному компьютеру, который обрабатывает и выполняет их, возвращая клиенту блоки данных.
Достоинство RDA заключается в унификации интерфейса «клиент — сервер» в виде языка запросов и широком выборе средств разработки приложений. К недостаткам можно отнести существенную загрузку сети при взаимодействии клиента и сервера посредством запросов; невозможность администрирования приложений в RDA, так как в одной программе совмещаются различные по своей природе функции (представления и прикладные).
Технологии RDA и DBS опираются на двухзвенную схему разделения функций:
• в RDA прикладные функции отданы программе-клиенту (прикладной компонент комбинируется с компонентом представления);
• в DBS ответственность за их выполнение берет на себя ядро СУБД (прикладной компонент интегрируется в компонент, доступа к информационным ресурсам).
В AS реализована трехзвенная схема разделения функций. Здесь прикладной компонент выделен как важнейший изолированный элемент приложения. Сравнивая модели, можно заключить, что AS обладает наибольшей гибкостью и имеет универсальный характер.
Объектно-ориентированные СУБД: история развития, связь с общими понятиями объектно-ориентированного подхода.
Рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
1) FS-модель
Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.
Основные свойства:
- выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;
- играет роль компонент доступа к информационным ресурсам;
- в остальных узлах функционирует приложение, в кодах которого совмещены компоненты представления и прикладной;
- протокол обмена — набор низкоуровневых вызовов.
Технология: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на компьютере-клиенте.
Недостатки: высокий сетевой трафик; небольшое число операций манипулирования; недостаточные требования к безопасности.
2) RDA-модель
Основные свойства:
-коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте;
-доступ к информационным ресурсам обеспечивается операторами непроцедурного языка SQL.
Технология:
клиентский запрос направляется на сервер, где функционирующее ядро СУБД обрабатывает запрос и возвращает результат (блок данных) клиенту. Ядро СУБД выполняет пассивную роль;
инициатор манипуляций с данными — программы на компьютере-клиенте.
Достоинства:
-процессор сервера загружается операциями обработки данных;
-уменьшается загрузка сети, т.к. по сети передаются запросы на языке SQL;
-унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.
Недостатки:
удовлетворительное администрирование приложений в RDA-модели невозможно из-за совмещения в одной программе различных по своей природе функций (представления и прикладных).
3) DBS-модель
Реализована в реляционных СУБД Informix, Ingres, Oracle.
Основные свойства:
-основа модель-механизм хранимых процедур — средство программирования SQL-сервера;
-процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на компьютере, где функционирует SQL-сервер;
-компонент представления выполняется на компьютере-клиенте;
-прикладной компонент и ядро СУБД на компьютере-сервере базы данных.
Достоинства:
-возможность централизованного администрирования;
-вместо SQL-запросов по сети передаются вызовы хранимых процедур, что ведет к снижению сетевого трафика.
Недостатки:
-в большинстве СУБД недостаточно возможностей для отладки и типизирования хранимых процедур;
ограниченность средств для написания хранимых процедур.
На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.
4) AS-модель
Основные свойства:
-на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;
-этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);
-прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (AS);
-все операции над БД выполняются соответствующим компонентом, для которого AS — клиент.
RDA- и DBS-модели имеют в основе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.
В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, имеющий стандартизированные интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки транзакций.
Язык запросов — это искусственный язык, на котором делаются запросы к базам данных и другим информационным системам, особенно к информационно-поисковым системам.
SQL — де-факто стандартный язык запросов к реляционным базам данных.
Language Integrated Query — расширение для некоторых языков программирования в .NET Framework, добавляющее к ним SQL-подобный язык запросов.
XQuery — язык запросов, разработанный для обработки данных в формате XML.
XPath — язык запросов к элементам XML-документа.
Объектно-ориентированные СУБД: основные характеристики, стандарты объектных баз данных (ODL, OQL, C++, Smalltalk).
Начиная с 70-80-ых годов ХХ-го века развитие аппаратных средств существенно опережало развитие систем и средств программирования. Чтобы выправить положение, были предложены различные подходы к увеличению производительности труда программиста. Среди этих попыток выделяется такое популярное направление, как объектно-ориентированный подход (ООП) к конструированию и кодированию программ. Особую роль в популярности этого подхода сыграло как его тесная связь с интерфейсами пользователя (особенно графическими), так и включение элементов этого подхода в популярные реализации языков программирования C++ и Pascal with Objects фирмы Borland.
ООП также получил признание в сфере автоматизированного проектирования, как альтернатива структурного подхода в проектировании сложных ( в том числе и информационных систем) и реляционной модели данных как основного средства отображения информации о сложных объектах.
Среди типовых задач, для которых ООП является перспективным, можно выделить такие:
Проектирование сложных инженерных объектов и систем (таких как ракетные комплексы, АСУП и САПР, управление технологиями, автоматизация эксперимента, робототехника) ;
Диспетчеризация, планирование современного производства;
Сети коммуникации и связи;
Системы искусственного интеллекта, системы поддержки принятия решений, экспертные системы;
Операционные системы, системы реального времени;
Системы имитации и моделирования, тренажеры и т.д.
Новая методология ориентирована, прежде всего, на создание больших сложных систем, коллективную их разработку, последующее активное сопровождение при эксплуатации и регулярные модификации.
До сих пор большинство сложных систем были построены на принципах структурного подхода, суть которого состоит в декомпозиции системы на ряд модулей, процедур, функций и структур данных, связанных общим алгоритмом функционирования. Но распространение мощных персональных компьютеров создало в 90-х годах основу для широкого применения объектно-ориентированного подхода в практике проектирования и программирования. В последнее время более широко начинают использоваться как языки программирования, созданные в рамках объектно-ориентированной методологии, так и объектно-ориентированные СУБД.
В основе объектно-ориентированной методологии (ООМ) лежит объектный подход, когда прикладная предметная область представляется в виде совокупности объектов, которые взаимодействуют между собой посредством передачи сообщений. Под объектом понимается некоторая сущность (реальна или абстрактная), обладающая состоянием, поведением и индивидуальностью. Состояние объекта характеризуется перечнем всех его возможных (обычно статических) свойств - структурой и значениями каждого из этих свойств. Поведение объекта (или его функциональность) характеризует то, как объект взаимодействует с другими объектами или подвергается взаимодействию других объектов, проявляя свою индивидуальность. Индивидуальность - это такие свойства объекта, которые отличают его ото всех других объектов. Поведение объекта реализуется в виде функций, которые называют методами. При этом структура объекта доступна только через его методы, которые в совокупности формируют интерфейс объекта.
Такой подход позволяет локализовать принимаемые решения рамками объекта, объединяя в нем и структуру и поведение, а следовательно, снижая сложность описания и реализации объекта. Эта способ объединения структуры и поведения в одном месте и сокрытия всех данных внутри объекта, что делает их невидимыми для всех, за исключением методов самого объекта называется инкапсуляцией. Это позволяет объектам функционировать совершенно независимо друг от друга, скрывая за интерфейсом детали реализации. Инкапсуляция позволяет рассматривать объекты, как изолированные "черные ящики", которые знают и умеют выполнять определенные действия. С этой точки зрения, внутреннее устройство "черных ящиков" для нас значения не имеет, нам все равно, что происходит внутри. Важно только знать, что надо положить в ящик при обращении к нему и что мы при этом из него получим. Таким образом, объекты - это минимальные единицы инкапсуляции.
Но к объекту может обращаться не только программист, разработчик или администратор, но и любой объект, функционирующий в системе. Для этого нужно только послать интересующему объекту сообщение, которое представляет требование выполнить некоторые действия. И если такое требование может быть выполнено принявшим сообщение объектом, то оно выполняется, а если не может быть выполнено, то пославший требование объект информируется о реакции на полученное сообщение.
Для упрощения описания и управления миолм объектов была введена одна из ключевых концепций объектно-ориентированного программирования - идея группировки объектов в классы, в соответствии с тем как они устроены и действуют. Под классом понимается множество объектов, связанных общностью структуры и поведения. Именно класс вначале описывает переменные и методы объекта, то есть структуру и поведение объекта. Любой конкретный объект представляет собой экземпляр класса.
Структура и поведение схожих объектов определяют общий для них класс, т.о. объект это экземпляр класса. Классы, как и объекты, не существуют изолированно.
Примеры объектно-ориентированных СУБД (проекты ORION и O2).
В настоящее время ведется очень много экспериментальных и производственных работ в области объектно-ориентированных СУБД. Больше всего университетских работ, которые в основном носят исследовательский характер. Но уже несколько лет назад отмечалось существование по меньшей мере тринадцати коммерчески доступных систем ООБД. Среди них уже упоминавшиеся в нашем обзоре системы O2, ORION, GemStone и Iris.
Проект ORION осуществлялся с 1985 по 1989 г. фирмой MCC под руководством известного еще по работам в проекте System R Вона Кима. Под названием ORION на самом деле скрывается семейство трех СУБД: ORION-1 - однопользовательская система; ORION-1SX, предназначенная для использования в качестве сервера в локальной сети рабочих станций; ORION-2 - полностью распределенная объектно-ориентированная СУБД. Реализация всех систем производилась с использованием языка Common Lisp на рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС Genera 7.0 и SUN-3 в среде ОС UNIX.
Основными функциональными компонентами системы являются подсистемы управления памятью, объектами и транзакциями. В ORION-1 все компоненты, естественно, располагаются на одной рабочей станции; в ORION-1SX - разнесены между разными рабочими станциями (в частности, управление объектами производится на рабочей станции-клиенте). Применение в ORION-1SX для взаимодействия клиент-сервер механизма удаленного вызова процедур позволило использовать в этой системе практически без переделки многие модули ORION-1. Сетевые взаимодействия основывались на стандартных средствах операционных систем.
В число функций подсистемы управления памятью входит распределение внешней памяти, перемещение страниц из буферов оперативной памяти во внешнюю память и наоборот, поиск и размещение объектов в буферах оперативной памяти (как принято в объектно-ориентированных системах, поддерживаются два представления объектов - дисковое и в оперативной памяти; при перемещении объекта из буфера страниц в буфер объектов и обратно представление объекта изменяется). Кроме того, эта подсистема ответственна за поддержание вспомогательных индексных структур, предназначенных для ускорения выполнения запросов.
Подсистема управления объектами включает подкомпоненты обработки запросов, управления схемой и версиями объектов. Версии поддерживаются только для объектов, при создании которых такая необходимость была явно указана. Для схемы БД версии не поддерживаются; при изменении схемы отслеживается влияние этого изменения на другие компоненты схемы и на существующие объекты. При обработке запросов используется техника оптимизации, аналогичная применяемой в реляционных системах (т.е. формируется набор возможных планов выполнения запроса, оценивается стоимость каждого из них и выбирается для выполнения наиболее дешевый).
Подсистема управления транзакциями обеспечивает традиционную сериализуемость транзакций, а также поддерживает средства журнализации изменений и восстановления БД после сбоев. Для сериализации транзакций применяется разновидность двухфазного протокола синхронизационных захватов с различной степенью гранулированности. Конечно, при синхронизации учитывается специфика ООБД, в частности, наличие иерархии классов. Журнал изменений обеспечивает откаты индивидуальных транзакций и восстановление БД после мягких сбоев (архивные копии БД для восстановления после поломки дисков не поддерживаются).
Проект O2 выполнялся французской компанией Altair, образованной специально для целей проектирования и реализации объектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был рассчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. После успешного завершения проекта для сопровождения системы и ее дальнейшего развития была организована новая чисто коммерческая компания O2.
Прототип системы функционировал в режиме клиент/сервер в локальной сети рабочих станций SUN c соответствующим разделением функций между сервером и клиентами.
Основными компонентами системы (не считая развитого набора интерфейсных средств) являются интерпретатор запросов и подсистемы управления схемой, объектами и дисками. Управление дисками, т.е. поддержание базовой среды постоянного хранения обеспечивает система WiSS, которую разработчики O2 перенесли в окружение ОС UNIX.
Наибольшую функциональную нагрузку несет компонент управления объектами. В число функций этой подсистемы входят: управление сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем; управление передачей сообщений между объектами; управление транзакциями; управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet); отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней памяти до тех пор, пока достижим из какого-либо долговременно хранимого объекта); управление буферами оперативной памяти (аналогично ORION, представление объекта в оперативной памяти отличается от его представления на диске); управление кластеризацией объектов во внешней памяти; управление индексами.
Несколько слов про управление транзакциями. Различаются режимы, когда допускается параллельное выполнение транзакций, изменяющих схему БД, и когда параллельно выполняются только транзакции, изменяющие внутренность БД. Первый режим обычно используется на стадии разработки БД, второй - на стадии выполнения приложений. Средства восстановления БД после сбоев и откатов транзакций также могут включаться и выключаться. Наконец, поддерживается режим, при котором все постоянно хранимые объекты загружаются в оперативную память при начале транзакции для увеличения скорости работы прикладной системы.
Компонент управления схемой БД реализован над подсистемой управления объектами: в системе поддерживаются несколько невидимых для программистов классов и в том числе классы "Class" и "Method", экземплярами которых являются, соответственно, объекты, определяющие классы, и объекты, определяющие методы. (Как видно, ситуация напоминает реляционные системы, в которых тоже обычно поддерживаются служебные отношения-каталоги, описывающие схему БД.) Удаление класса, который не является листом иерархии классов или используется в другом классе или сигнатуре какого-либо метода, запрещено.
Даже приведенное краткое описание особенностей двух объектно-ориентированных СУБД показывает прагматичность современного подхода к организации таких систем. Их разработчики не стремятся к полному соблюдению чистоты объектно-ориентированного подхода и применяют наиболее простые решения проблем.
Многоплатформные СУБД.
Многоплатформенная
СУБД ЛИНТЕР работает более чем на 15-ти программно-аппаратных платформах. Среди них как достаточно популярные платформы, так и очень специфические, рассчитанные на работу в реальном масштабе времени или на портативных компьютерах (КПК).
Масштабируемая
СУБД ЛИНТЕР давно и успешно развивается в этом направлении. При переходе на новую, более совершенную технику, вы получите соответствующий выигрыш. СУБД ЛИНТЕР сможет эффективно использовать дополнительную память вашего сервера или его дополнительную многопроцессорность.
Развивающаяся
СУБД ЛИНТЕР непрерывно развивается и совершенствуется.
Основные направления развития системы:
-увеличение эффективности;
-повышение надёжности;
-улучшение многопользовательской работы;
-новые типы данных;
-новые типы индексов.
Однако ещё раз следует обратить внимание, что аппарат КСЗ СУБД ЛИНТЕР не покинет систему ни при каких её изменениях.
Разнообразные средства разработки приложений
СУБД ЛИНТЕР можно использовать как при интерактивной работе, так и в системах оперативного управления интенсивно изменяющимися объектами.
Есть множество примеров успешного использования СУБД ЛИНТЕР в системах управления, работающих в режиме реального времени.
Концепции и разработка распределенных БД.
Базой систем нового поколения являются профессиональные(многопользовательские, многоплатформенные) СУБД и архитектура «клиент —сервер», реализуемая на их основе.
Профессиональные СУБД обеспечивают выполнение более сложных операций. Они позволяют разработчику расширять сервисные возможности -процедуры базы данных, которые вызываются клиентом и выполняются сервером более производительно, чем компьютеры на рабочих местах пользователей. К профессиональным СУБД относятся Oracle, SyBase, Informix, Ingres, Progress.Перечисленные системы имеют средства обработки информации, распределенной по нескольким узлам сети. Распределенная обработка данных позволяет разместить базу в различных узлах таким образом, чтобы отслеживать изменения на всех узлах и чтобы каждый компонент данных располагался на том узле, где он будет обрабатываться.
Новейшей технологией управления распределенными базами данных является тиражирование. Профессиональные СУБД поддерживают те или иные механизмы тиражирования.
Тиражирование представляет собой асинхронный перенос изменений объектов исходной базы данных в базы данных, принадлежащие различным узлам распределенной системы. При внесении изменений одновременный доступ ко всем узлам, затрагиваемым этими изменениями, не требуется. Данные изменяются на одном узле, а затем переносятся на остальные. Тиражирование может производиться после завершения определенного числа транзакций, в том числе и после каждой транзакции, через равные промежутки или к определенному моменту времени,контролироваться администратором системы или пользовательским приложением.
Распределенная обработка позволяет в широких пределах варьировать вычислительными ресурсами, избегая узких мест, сдерживающих производительность, и добиваясь максимальной эффективности информационных систем.
Особенностью современных информационных систем, например,биржевых или банковских, является требование оперативного оповещения пользователей о происходящих событиях. Например, все участники фондовой биржи должны немедленно получать информацию о совершенных сделках, изменениях котировок и т.д. Другими словами, предполагается наличие некоторого количества процессов, которые должны исполняться параллельно и синхронизироваться во время исполнения. Это приводит к необходимости обмена информации между ними.Профессиональные СУБД типа Oracle позволяют организовать эти процессы в виде отдельных приложений на одной базе данных. Например, при совершении сделки процесс, занимающийся их регистрацией, возбуждает событие «совершена сделка».Результаты ее включаются в общий поток информации о сделках. Если же этот процесс не исполняется, то событие «совершена сделка» не приводит ни к каким дополнительным действиям. Механизмы событий, реализованные в современных профессиональных СУБД, являются готовым технологическим средством, которое позволяет разработчикам информационных систем экономить значительное количество времени и усилий.
По мере развития любой хозяйственной деятельности появляется потребность в наращивании информационной системы. Возникает вопрос, как встроить имеющееся локальное приложение в новую систему. Профессиональные СУБД предоставляют достаточно широкие возможности. Развитые системы шлюзов позволяют строить информационные системы, распределенные по узлам с различными аппаратными и программными платформами. Большой интерес представляет также использование локальными приложениями так называемого ODBC — стандарта (Open DataBase Connectivity, стандарт, предложенный фирмой Microsoft), который дает возможность прозрачного доступа к данным СУБД различных типов. Таким образом,приложение, разработанное с учетом стандарта ODBC, имеет большую гибкость при интеграции в существующую информационную систему.
Потребность в гибких решениях для современных информационных систем диктуется жизнью. На практике чаще всего встречается потребность в объединении возможностей отдельных подсистем или программных модулей; Причем все это нужно иметь на одной базе данных. Через некоторое время соотношение потребностей может измениться. Поэтому для построения информационной системы важно иметь инструмент, который наиболее приспособлен для построения открытых и гибких систем. Таким инструментом в настоящий момент являются профессиональные СУБД SQL, обеспечивающие работу в модели «клиент — сервер» и обладающие развитыми средствами разработки и сопровождения баз данных. Использование профессиональной СУБД позволяет иметь программное обеспечение, в большей степени отвечающее конкретным потребностям организации.
Объектные, объектно-ориентированные и объектно-реляционные СУБД.
Системы с базами данных → для интеграции инф. Рессурса организации в единое целое и обеспечение контролируемого доступа. На практике создание компьютерных сетей приводит к децентрализации обработки данных.
Децентрализованной подход отражает организационную структуру организации, где каждая единица имеет дело с собственным набором обрабатываемых данных.
Разработка РБД, отражающих организационные структуры предприятий, позволяет сделать данные, поддерживаемые каждым из под разделением, общедоступными, обеспечив при этом их хранение в тех местах, где они чаще всего используются Это наиболее распространенный.
Распределение баз данных - Набор логических связанных между собой разделяемых данных (и их описаний), которые физически расположены в некоторой компьютерной сети.
Распределение СУБД - Программный комплекс, предназначенный для УПРАВЛЕНИЯ распределенными базами данных и позволяющий сделать распределенность информации прозрачной для конечного пользователя.
Система управления распределенными базами данных (СУРБД) состоит из ЕДИНОЙ ЛОГИЧЕСКОЙ БАЗЫ ДАННЫХ, разделенной на некоторое количество фрагментов.
Каждый фрагмент базы данных сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи и каждый из которых работает под управлением отдельной СУБД. Любой из сайтов способен независимо обрабатывать ЗАПРОСЫ пользователей, требующие доступа локально сохраненным данным, а также способен обрабатывать данные, сохраненные на других компьютерах в сети.
Пользователи взаимодействуют с РБД через приложения. Приложения бывают локальные (не требует доступа к данным на других сайтах) и Глобальные (требуют подобного доступа).
В распределении СУБД должно существовать хотя бы одно глобальное приложение, поэтому любая СУРБД должна иметь следующие особенности:
Набор логически связанных разделяемых данных
Сохраняемые данные разбиты на некоторое количество фрагментов
Между фрагментами может быть организована репликация данных
Фрагменты и их реплики распределены по различным сайтам
Сайты связаны между собой сетевыми соединениями
Работа с данными на каждом сайте упрвляется СУБД
СУБД на каждом сайте способна поддерживать автономную работу локальных приложений
СУБД каждого сайта поддерживает хотя бы одно Глобальное приложение
Нет необходимости в том, чтобы на каждом из сайтов системы существовала собственная система базы данных.
Для каждого пользователя распределенность системы д.б. совершенно ПРОЗРАЧНА (невидима): прозрачность что имеется набор фрагментов, размещенных на различных компьютерах, прозрачность, что имеется репликация. Основа СУРБД обеспечение прозрачности.