SQL-СЕРВЕРЫ
Лекции
Содержание
Лекция 1. Распределенная обработка данных 3
Лекция 2. Обзор SQL-серверов 17
Лекция 3. Основы теории множеств 23
Лекция 4. MS SQL Server 44
Лекция 5. Язык SQL 46
ВСТАВКА ОДНОГО ЗАПРОСА ВНУТРЬ ДРУГОГО 68
КАК РАБОТАЕТ ПОДЗАПРОС? 68
Лекция 1. Распределенная обработка данных
-
Архитектура распределенной обработки данных
-
Архитектура «файл – сервер»
-
Архитектура «выделенный сервер БД»
-
Архитектура «активный сервер БД»
-
Архитектура «сервер приложений»
-
Распределенные БД
-
Преимущества СУРБД
-
Недостатки СУРБД
-
12 правил Дейта для СУРБД
Основные идеи современных информационных технологий базируются на концепции, согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов, называемых системами управления базами данных (СУБД).
Появление вычислительных систем с БД привело к изменению прежнего способа обработки данных, когда для каждого приложения определялись и поддерживались собственные наборы данных, на новый способ, при котором все данные определялись и поддерживались централизованно. Обработка данных с использованием централизованной БД, доступ к которой может осуществляться с различных компьютеров сети, называется распределенной обработкой данных.
Архитектура "клиент-сервер"
Почти все модели организации взаимодействия пользователя с БД построены на основе модели «клиент – сервер». Но различные приложения отличаются способом распределения функций между клиентской и серверной частями.
Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети.
Разделение процесса выполнения запроса на клиентскую и серверную компоненту позволяет:
различным прикладным (клиентским) программам одновременно использовать общую БД;
централизовать функции управления: защиту информации, обеспечение целостности данных, управление совместным использованием ресурсов;
обеспечивать параллельную обработку запроса в случае распределенных БД;
высвобождать ресурсы рабочих станций и сети;
повышать эффективность управления данными за счет использования ЭВМ, специально разработанных для работы СУБД.
Открытые системы
Реальное распространение архитектуры "клиент-сервер" стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем.
Основным смыслом подхода открытых систем является упрощение комплексирования вычислительных систем за счет международной и национальной стандартизации аппаратных и программных интерфейсов. Главной побудительной причиной развития концепции открытых систем явились повсеместный переход к использованию локальных компьютерных сетей.
Ключевой фразой открытых систем, направленной в сторону пользователей, является независимость от конкретного поставщика. Ориентируясь на продукцию компаний, придерживающихся стандартов открытых систем, потребитель, который приобретает любой продукт такой компании, не попадает к ней в рабство. Он может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств.
Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось придти к соглашению об основных стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным (а в большинстве случаев и системным) программистам. Как кажется, несмотря на появление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в ближайшие годы.
Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам. Интероперабельность означает упрощения комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.
Использование подхода открытых систем выгодно и производителям, и пользователям. Прежде всего открытые системы обеспечивают естественное решение проблемы поколений аппаратных и программных средств. Производители таких средств не вынуждаются решать все проблемы заново; они могут по крайней мере временно продолжать комплексировать системы, используя существующие компоненты.
Преимуществом для пользователей является то, что они могут постепенно заменять компоненты системы на более совершенные, не утрачивая работоспособности системы. В частности, в этом кроется решение проблемы постепенного наращивания вычислительных, информационных и других мощностей компьютерной системы.
Клиенты и серверы локальных сетей
В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах.
Развитие этой идеи приводит к функциональному выделению компонентов сети: разумно иметь не только доступ к ресурсами удаленного компьютера, но также получать от этого компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства для обеспечения которого нецелесообразно дублировать в нескольких узлах. Так мы приходим к различению рабочих станций и серверов локальной сети.
Рабочая станция предназначена для непосредственной работы пользователя или категории пользователей и обладает ресурсами, соответствующими локальным потребностям данного пользователя. Специфическими особенностями рабочей станции могут быть объем оперативной памяти (далеко не все категории пользователей нуждаются в наличии большой оперативной памяти), наличие и объем дисковой памяти (достаточно популярны бездисковые рабочие станции, использующие внешнюю память дискового сервера), характеристики процессора и монитора (некоторым пользователям нужен мощный процессор, других в большей степени интересует разрешающая способность монитора, для третьих обязательно требуются средства убыстрения графики и т.д.). При необходимости можно использовать ресурсы и/или услуги, предоставляемые сервером.
Сервер локальной сети должен обладать ресурсами, соответствующими его функциональному назначению и потребностям сети. Заметим, что в связи с ориентацией на подход открытых систем, правильнее говорить о логических серверах (имея в виду набор ресурсов и программных средств, обеспечивающих услуги над этими ресурсами), которые располагаются не обязательно на разных компьютерах. Особенностью логического сервера в открытой системе является то, что если по соображениям эффективности сервер целесообразно переместить на отдельный компьютер, то это можно проделать без потребности в какой-либо переделке как его самого, так и использующих его прикладных программ.
Примерами сервером могут служить:
сервер телекоммуникаций, обеспечивающий услуги по связи данной локальной сети с внешним миром;
вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях;
дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциями и, возможно, другим серверам;
файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;
сервер баз данных фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты.
Сервер локальной сети предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам.
Принято называть клиентом локальной сети, запрашивающий услуги у некоторого сервера и сервером - компонент локальной сети, оказывающий услуги некоторым клиентам.
Системная архитектура "клиент-сервер"
Понятно, что в общем случае, чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется некоторый интерфейсный программный слой, поддерживающий такого рода взаимодействие (было бы по меньшей мере неестественно требовать, чтобы прикладная программа напрямую пользовалась примитивами транспортного уровня локальной сети). Из этого, собственно, и вытекают основные принципы системной архитектуры "клиент-сервер".
Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Заметим, что в развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос.
Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).
Основной проблемой систем, основанных на архитектуре "клиент-сервер", является то, что в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.
Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.
Серверы баз данных
Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных.
Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Принципы взаимодействия между клиентскими и серверными частями
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL.
Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, некоторые из которых были рассмотрены на предыдущих лекциях, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов.
Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.
Недостаток тоже довольно очевиден. При таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.
Преимущества протоколов удаленного вызова процедур
Упоминавшиеся выше протоколы удаленного вызова процедур особенно важны в системах управления базами данных, основанных на архитектуре "клиент-сервер".
Во-первых, использование механизма удаленных процедур позволяет действительно перераспределять функции между клиентской и серверной частями системы, поскольку в тексте программы удаленный вызов процедуры ничем не отличается от удаленного вызова, и следовательно, теоретически любой компонент системы может располагаться и на стороне сервера, и на стороне клиента.
Во-вторых, механизм удаленного вызова скрывает различия между взаимодействующими компьютерами. Физически неоднородная локальная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате пользователи не обязаны серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.
Типичное разделение функций между клиентами и серверами
В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL.
В некоторых случаях хотелось бы включить в состав клиентской части системы некоторые функции для работы с "локальным кэшем" базы данных, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.
С другой стороны, иногда хотелось бы перенести большую часть прикладной системы на сторону сервера, если разница в мощности клиентских рабочих станций и сервера чересчур велика. В общем-то при использовании RPC это сделать нетрудно. Но требуется, чтобы базовое программное обеспечение сервера действительно позволяло это. В частности, при использовании ОС UNIX проблемы практически не возникают.
Требования к аппаратным возможностям и
базовому программному обеспечению клиентов и серверов
Из предыдущих рассуждений видно, что требования к аппаратуре и программному обеспечению клиентских и серверных компьютеров различаются в зависимости от вида использования системы.
Если разделение между клиентом и сервером достаточно жесткое (как в большинстве современных СУБД), то пользователям, работающим на рабочих станциях или персональных компьютерах, абсолютно все равно, какая аппаратура и операционная система работают на сервере, лишь бы он справлялся с возникающим потоком запросов.
Но если могут возникнуть потребности перераспределения функций между клиентом и сервером, то уже совсем не все равно, какие операционные системы используются.
Базовые архитектуры распределенной обработки
Архитектура «файл – сервер»
Рис. 1.
В архитектуре «файл – сервер» средства организации и управления БД (в том числе и СУБД) целиком располагаются на машине клиента, а БД, представляющая собой набор специализированных структурированных файлов, - на машине - сервере. В этом случае серверная компонента представлена не средствами СУБД, а сетевыми составляющими ОС, обеспечивающими удаленный доступ к файлам.
Взаимодействие между клиентом и сервером происходит на уровне команд ввода – вывода файловой системы: запрос к БД, сформулированный на языке манипулирования данными, преобразуется самой СУБД в последовательность команд ввода – вывода, которые обрабатываются ОС машины – сервера.
В среде файлового сервера программа управления данными, которая выполняется на машине – клиенте, должна осуществлять запрос каждой записи БД, после чего она может определить, удовлетворяет ли запись поисковым условиям, и лишь после этого передать запись для функциональной обработки.
Достоинство: возможность обслуживания запросов нескольких клиентов.
Недостатки:
высокая загрузка сети и машин – клиентов;
низкий уровень защиты данных;
низкий уровень управления целостностью и непротиворечивостью информации.
Архитектура «выделенный сервер БД»
Рис. 2.
В архитектуре сервера БД средства управления БД и БД размещены на машине – сервере. Взаимодействие между клиентом и сервером происходит на уровне команд языка манипулирования данными СУБД (SQL), которые обрабатываются СУБД на машине – сервере. Сервер БД осуществляет поиск записей и анализирует их. Записи, удовлетворяющие условиям, могут накапливаться на сервере и после того, как запрос будет целиком обработан, пользователю на клиентскую машину передаются все записи, удовлетворяющие поисковым условиям.
Достоинства:
возможность обслуживания запросов нескольких клиентов;
снижение нагрузки на сеть и машины сервера и клиентов;
защита данных осуществляется средствами СУБД;
сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей.
Недостатки:
бизнес - логика функциональной обработки (правила, по которым проводится ввод, вывод и изменение данных в БД) и представление данных могут быть одинаковыми для нескольких клиентских приложений, что увеличит совокупные потребности в ресурсах при исполнении вследствие повторения части кода программ и запросов;
низкий уровень управления непротиворечивостью информации, так как правила функциональной обработки сосредоточены на клиентской части.
Архитектуры «файл – сервер» и «выделенный сервер БД» называют моделями с «толстым клиентом», так как на стороне клиента выполняется большинство функций. Следующие две архитектуры «активный сервер БД» и «сервер приложений» называют моделями с «тонким клиентом».
Архитектура «активный сервер БД»
Для того, чтобы устранить недостатки, свойственные архитектуре сервера БД, необходимо, чтобы непротиворечивость бизнес - логики и изменения БД контролировались на стороне сервера. Для этого функции бизнес - логики разделяются между клиентской и серверной частями. Общие функции оформляются в виде хранимых процедур, включаемых в состав БД. Вводится механизм отслеживания событий БД – триггеров, также включаемых в состав БД. При возникновении соответствующего события, СУБД вызывает для выполнения хранимую процедуру, связанную с триггером, что позволяет эффективно контролировать изменение БД.
Рис. 3.
Недостатком такой архитектуры является существенно возрастающая загрузка сервера за счет необходимости отслеживания событий и выполнения части бизнес - правил.
Достоинства:
Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с БД. Этот снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса.
Все рассмотренные выше архитектуры являются двухзвенными: все функции доступа и обработки распределены между программой клиента и сервером БД.
Архитектура «сервер приложений»
В архитектуре «сервер приложений» для снижения уровня требований к ресурсам клиента вводится промежуточное звено – сервер приложений, на который переносится значительная часть программных компонентов управления данными и большая часть бизнес - логики. При этом серверы БД обеспечивают функции СУБД по ведению и обслуживанию БД.
Рис. 4.
Достоинства:
Централизованное ведение бизнес – логики. Отсутствие необходимости тиражирования изменений в клиентских приложениях.
Отсутствие необходимости устанавливать на клиентских машинах компоненту программного обеспечения управления доступом к данным.
Возможность отложенного обновления БД в случае изменения данных, запрошенных с сервера, в автономном режиме.
Распределенные БД
В отличие от технологии распределенной обработки данных технология распределенных БД, получившая в последнее время широкое распространение, способствует обратному переходу от централизованной обработки данных к децентрализованной. Создание технологии систем управления распределенными БД является одним из самых больших достижений в области БД.
Системы распределенных БД представляют собой системы с БД, размещенными в сети разнотипных компьютеров. Распределенная БД – набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети. Такие системы обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы БД, размещенные на различных ЭВМ сети.
Распределенная СУБД – программный комплекс, предназначенный для управления распределенными БД и позволяющий сделать распределенность информации прозрачной (невидимой) для конечного пользователя. От пользователей должен быть полностью скрыт тот факт, что распределенная БД состоит из нескольких фрагментов, размещенных на различных компьютерах. В распределенной БД сами данные хранятся на нескольких компьютерах. Т. е. распределенная система внешне должна вести себя так, как централизованная. Это требование называют основным принципом построения распределенных СУБД.
Система управления распределенными БД (СУРБД) состоит из единой логической БД, разделенной на некоторое количество фрагментов. Каждый фрагмент БД сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи, и каждый из которых работает под управлением отдельной СУБД и независимо администрируется.
Пользователи взаимодействуют с распределенной БД через приложения. Приложения могут быть локальными, использующими данные одного фрагмента распределенной БД, и глобальными, использующими данные нескольких фрагментов распределенной БД.
Распределенные СУБД можно классифицировать как гомогенные и гетерогенные. В гомогенных системах все узлы используют один и тот же тип СУБД. В гетерогенных системах на узлах могут функционировать различные типы СУБД, использующие разные модели данных. В гетерогенных системах необходимо обеспечить прозрачность в отношении типа используемой СУБД, т. е. пользователи каждого из узлов должны иметь возможность создавать интересующие их запросы на языке той СУБД, которая используется на данном узле. Система должна взять на себя локализацию требуемых данных и выполнение трансляции передаваемых сообщений.
Помимо распределенных СУБД существуют параллельные СУБД. Параллельная СУБД – система управления БД, функционирующая с использованием нескольких процессоров и устройств жестких дисков, что позволяет ей распараллеливать выполнение некоторых операций с целью повышения общей производительности обработки данных. таким образом, в параллельных системах размещение данных диктуется исключительно соображениями производительности.
Параллельные технологии обычно используются в случае исключительно больших БД, размеры которых могут достигать нескольких терабайт (1012 байт), или в системах, которые должны поддерживать выполнение тысяч транзакций в секунду. Подобные системы нуждаются в доступе к большому объему данных и должны обеспечивать приемлемое время реакции на запрос.
Преимущества СУРБД
Отражение структуры предметной области. Например, крупные организации, как правило, имеют множество отделений, которые могут находиться в разных концах страны и даже за ее пределами. Вполне логично будет предположить, что используемая этой организацией БД должна быть распределена между ее отделениями. В каждом отделении поддерживается БД, содержащая сведения о его персонале, клиентах и т. д. Через сеть осуществляется доступ не только к своим данным, но и данным, хранящимся в других отделениях.
Разделяемость и локальная автономность. Пользователи одного узла распределенной БД могут получать доступ к данным, сохраняемым на других узлах. Данные могут быть помещены на тот узел, на котором зарегистрированы пользователи, которые их чаще всего используют. В результате заинтересованные пользователи получают локальный контроль над требуемыми им данными и могут устанавливать или регулировать локальные ограничения на их использование.
Повышение доступности данных. В централизованных СУБД отказ центрального компьютера вызывает прекращение функционирования всей СУБД. Однако отказ одного из узлов СУРБД или линии связи между узлами сделает недоступным лишь некоторые узлы, тогда как вся система в целом сохранит свою работоспособность.
Повышение надежности. Если организована репликация данных, в результате чего данные и их копии размещены на более чем одном узле, отказ отдельного узла или соединительной связи между узлами не приведет к недоступности данных в системе.
Повышение производительности. СУРБД способствуют повышению скорости доступа к БД по сравнению с доступом к удаленной централизованной БД.
Экономические выгоды.
Закон Гроша: Мощность вычислительной установки возрастает пропорционально квадрату стоимости ее оборудования. Однако, в настоящее время считается общепринятым положение, согласно которому намного дешевле собрать из небольших компьютеров систему, мощность которой будет эквивалентна мощности одного большого компьютера.
В случае, когда пользователи сильно удалены от централизованной БД из-за относительно высокой стоимости передачи данных по сети (по сравнению со стоимостью их локальной обработки) оказывается экономически выгодным разделить приложение на соответствующие части и выполнять необходимую обработку на каждом из узлов отдельно.
Модульность системы. В распределенной среде расширение существующей системы осуществляется намного проще. Добавление в сеть нового узла не оказывает влияния на функционирование уже существующих. В централизованных же СУБД рост размера БД может потребовать замены и оборудования, и используемого программного обеспечения.
Недостатки СУРБД
Повышение сложности. Распределенные СУБД, способные скрыть от конечных пользователей распределенную природу используемых ими данных и обеспечить необходимый уровень производительности, надежности и доступности, являются более сложными программными комплексами, чем централизованные СУБД.
Увеличение стоимости. Увеличение сложности означает и увеличение затрат на приобретение и сопровождение СУРБД.
Проблемы защиты. В распределенных системах требуется организовать контроль доступа не только к данным, реплицируемым на несколько различных узлов, но и защиту сетевых соединений самих по себе.
Усложнение контроля за целостностью данных.
Отсутствие стандартов.
Отсутствуют стандарты на каналы связи и протоколы доступа к данным.
Не существует инструментальных средств и методологий, способных помочь пользователям в преобразовании централизованных систем в распределенные.
Недостаток опыта. Распределенные системы общего назначения еще не получили широкого распространения. Еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем.
Усложнение процедуры разработки БД. Разработка распределенных БД требует принятия решения о фрагментации данных, распределения фрагментов по отдельным узлам и организации процедур репликации данных.
12 правил Дейта для СУРБД
Правило 0. Основной принцип. С точки зрения пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная система.
Правило 1. Локальная автономность. Узлы в распределенной системе должны быть автономными, т. е. локальные данные принадлежат локальным владельцам и сопровождаются локально.
Правило 2. Отсутствие опоры на центральный узел. В системе не должно быть ни одного узла, без которого система не сможет функционировать, т. е. в системе не должно существовать центральных серверов таких служб, как управление транзакциями, оптимизация запросов и управление глобальным системным каталогом.
Правило 3. Непрерывное функционирование. В системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения операций таких, как добавление или удаление узла из системы, динамическое создание или удаление фрагментов с одного или нескольких узлов.
Правило 4. Независимость от расположения. Пользователь должен получать доступ к БД с любого из узлов. Пользователь должен получать доступ к любым данным так, как если бы они хранились на его узле, независимо от того, где они физически сохраняются.
Правило 5. Независимость от фрагментации. Пользователь должен получать доступ к данным независимо от способа их фрагментации.
Правило 6. Независимость от репликации. Пользователь не должен нуждаться в сведениях о наличии репликации данных.
Правило 7. Обработка распределенных запросов. Пользователь должен иметь возможность объединять данные, расположенные более сем на одном узле.
Правило 8. Обработка распределенных транзакций. СУРБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов, как в отдельных системах, так и в сети.
Правило 9. Независимость от типа оборудования. СУРБД должна быть способна функционировать на оборудовании с различными вычислительными платформами.
Правило 10. Независимость от операционной системы. СУРБД должна быть способна функционировать под управлением различных операционных систем.
Правило 11. Независимость от сетевой архитектуры. СУРБД должна быть способна функционировать в сетях с различной архитектурой и типами носителей.
Правило 12. Независимость от типа СУБД. СУРБД должна поддерживать гетерогенность.
|
