Управление sql. Управление безопасностью SQL сервера средствами Microsoft Access (документация). Управление на основе политик

04.04.2019

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

Клиент-серверная архитектура

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

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

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

Принцип работы клиент-серверной архитектуры

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

Клиент-серверная архитектура: применение технологии

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

БД В АРХИТЕКТУРЕ «КЛИЕНТ-СЕРВЕР»

План лекции

1. Клиенты и серверы локальных сетей

2. Системная архитектура клиент-сервер

3. Модели рабочих нагрузок в архитектуре клиент/сервер

4. Уровни и модели архитектуры «клиент-сервер»

Т. Конноли. Базы данных. Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ. – М.: Изд. дом «Вильямс», 2006. – 1440 с.

1 Клиенты и серверы локальных сетей

В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Развитие этой идеи приводит к функциональному выделению компонентов сети: рабочих станций и серверов локальной сети. Сервер локальной сети (server) предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам. Рабочая станция (клиeнты (client)) - кoмпьютepы, ocyщecтвляющиe дocтyп к ceтeвым pecypcaм, пpeдocтaвляeмым cepвepoм.

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

· файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций и в случае запроса фaйл или дaнныe цeликoм кoпиpyютcя нa зaпpaшивaющий кoмпьютep;

· сервер приложений выпoлняет пpиклaдныe чacти клиeнт-cepвepныx пpилoжeний, a тaкжe содержит дaнныe, дocтyпныe клиeнтaм;

2 Системная архитектура «клиент-сервер»

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

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

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

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

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

1) функции диалога (Presentation Logic, PL) или компонент визуализации . Компонент визуализации прикладной задачи осуществляет ввод информации пользователем с помощью тех или иных средств, а также вывод информации на экран и печать. Компонент визуализации для архитектуры клиент-сервер всегда исполняется на рабочем месте пользователя (поскольку должен же он наблюдать какие-либо результаты работы программы). Для организации презентационной логики преимущественно используется модель графического интерфейса пользователя GUI (User Interface Graphical) или Web-интерфейс;

2) прикладные функции или это часть кода приложения с алгоритмами обработки данных (Business Logic, BL). Компонент прикладной логики решает собственно ту или иную задачу, связанную с обработкой данных в той или иной предметной области и представляет собой алгоритмы реакции приложения на действия пользователя или на внутренние события, правила обработки данных. Этот компонент может быть распределен между клиентской и серверной частью различным образом в зависимости от применяемой модели. Обычно этот код программируется на языках программирования высокого уровня: C, C++, Visual Basic, Object Pascal и т. п.;

3) функции обработки данных внутри приложения (Database Logic, DL) - это часть кода приложения, связанная с выборкой и манипулированием данными (данными управляет собственно СУБД). Подъязыком является язык SQL.

Типовая структура приложения «клиент-сервер»

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

5) служебные функции, играющие роль связок между предыдущими группами функций.

3 Модели рабочих нагрузок в архитектуре клиент/сервер

«Клиент-серверные» системы могут опираться на несколько типов распределения обязанностей между клиентом и сервером:

· «интеллектуальные» клиенты (толстый клиент - тонкий сервер);

· «интеллектуальный» сервер (тонкий клиент - толстый сервер);

· смешанные системы;

· многоуровневые системы.

DIV_ADBLOCK80">

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

На компьютере-клиенте реализуется только логика представления данных.

Достоинства:

· увеличение производительности работы ИС: бизнес-логика выполняется в том же адресном пространстве, что и код доступа к базе данных, и, кроме того, тесно интегрирован с механизмом поиска данных. Это означает, что данные не нужно перемещать или копировать перед обработкой, а значит, сетевой трафик минимизируется;

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

· при необходимости бизнес-логика модифицируется централизованно, без изменения клиентов.

Недостатки:

· повышение требований к ресурсам сервера, где выполняются все запросы и манипуляции с данными.

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

Достоинства смешанных систем:

· серверный код одновременно доступен многим клиентам, что снижает накладные расходы при выполнении однотипных запросов;

· эффективность работы клиентов меньше зависит от сетевого трафика.

Недостатки:

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

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

Достоинства многоуровневых систем:

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

· централизованная модификация бизнес-правил;

Недостатки:

· увеличивается сетевой трафик.

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

4 Уровни и модели архитектуры «клиент-сервер»

С точки зрения количества составных частей клиент-серверные системы делятся на двухуровневые и трехуровневые.

Двухуровневые системы состоят только из клиента и сервера К двухуровневым моделям архитектуры «клиент-сервер» относятся:

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

2) модель удаленного доступа (RDA-модель);

3) модель активного сервера (DBS-модель).

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

Архитектура «файл-сервер»

В архитектуре «файл-сервер» (File Server, FS-модель) все основные функции приложения информационной системы (презентационная логика, бизнес-логика и функции обработки и управления данными) располагаются на клиенте (рис. 2).

На сервере находятся файлы с данными и поддерживается доступ к файлам.

В этой модели клиент обращается к серверу с запросом к данным. Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд, Система управления файлами (СУФ) считывает запрашиваемые данные из БД и поблочно передает эти данные клиентскому приложению, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации и т. д. Фактически, FS-модель предполагает автономную работу программного обеспечения ИС на разных машинах в сети. Компоненты ИС взаимодействуют только за счет наличия общего хранилища данных. Безусловно, таким хранилищем должна быть хорошо спроектированная БД под управлением СУБД, поддерживающей FS-модель, например, СУБД Informix SE. Такого рода СУБД нельзя считать «истинным сервером».

Модель архитектуры файлового сервера

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

В целом в архитектуре ИС «файл-сервер» мы имеем «толстого» клиента и очень «тонкий» сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти.

К недостаткам архитектуры «файл-сервер» можно отнести:

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

· ограниченное множество команд манипулирования данными, фактически это только файловые команды;

· низкая производительность (зависит от производительности сети, сервера, клиента);

· плохая возможность подключения новых клиентов;

· отсутствие развитых средств защиты данных (только на уровне файловой системы).

К несомненным достоинствам следует отнести

· высокую эффективность работы с небольшими объемами данных в однопользовательском режиме.

· удобство централизованного управления доступом;

· низкая стоимость разработки;

· высокая скорость разработки;

· невысокая стоимость обновления и изменения ПО.

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

Модель удаленного доступа к данным, RDA ( Remote Data Access , RDA )

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

Клиент заметно «похудел» по сравнению с FS-моделью, зато значительно расширились функции сервера, сократился сетевой трафик, а самое главное достоинство модели RDA: появился язык SQL с расширенным множеством команд определения данных и манипулирования данными, который унифицировал интерфейс клиент-сервер.

Модель архитектуры удаленного доступа к данным

Достоинства RDA-модели:

· перенос Business Logic на клиента существенно разгружает сервер БД, сводя к минимуму общее число процессов в операционной системе;

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

· резко уменьшается загрузка сети так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на SQL, и их объем существенно меньше. В ответ на запросы клиент получает только данные, релевантные запросу, а не блоки файлов, как в FS-модели.

Недостатки RDA-модели:

· по-прежнему высокий сетевой трафик, особенно при большом количестве клиентов и их интенсивной работе в интерактивном режиме;

· излишнее дублирование кода приложения, например повторение бизнес-логики для каждого клиента;

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

Модель сервера БД (иногда называют активный сервер)

Модель сервера (Data Base Server, DBS) - концепция, в соответствии с которой прикладной компонент (бизнес-логика) частично или полностью располагается на сервере базы данных (рис.4). Бизнес-логика реализована в виде хранимых программных единиц (ПрЕ), триггеров, пользовательских типов данных, которые хранятся в БД, а управляются сервером. В базе данных также накапливаются данные и формируется база метаданных (БМД). Клиентское приложение обращается к серверу с командой запуска ПрЕ, а сервер при необходимости выполняет её и фиксирует изменения в БД. Сервер возвращает результат запроса клиенту либо для вывода на периферийное устройство, либо для выполнения части бизнес-логики, которая расположена на клиенте. При таком способе распределения обработки данных сетевой трафик резко уменьшается.

Триггер - механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер => триггер - это программа, которая выполняется над БД и вызывает хранимые процедуры.

Данная модель сервера является активной, потому что не только клиент, но и сам сервер используют механизм триггеров.
Достоинства:

DBS-модель поддерживает большинство современных СУБД: Oracle, Sybase, Ingres, Informix, MS SQL Server, хотя функциональные возможности у них разные.

Достоинства DBS-модели:

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

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

· возможность разделения процедур несколькими приложениями и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения SQL-запроса. (так как хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях).

Недостатки:

Функции сервера:

1. Осуществляет мониторинг событий, связанных с описанными триггерами;

2. Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;

3. Обеспечивает исполнение внутренней программы каждого триггера;

4. Запускает хранимые процедуры по запросам пользователей;

5. Запускает хранимые процедуры из триггеров;

6. Возвращает требуемые данные клиенту;

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

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

Сервер приложений

Сервер приложений (Application server , AS ) - разновидность многоуровневой архитектуры «клиент-сервер», основанный на схеме «клиент - сервер приложений».

В данной модели вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений. Отсюда и идентичное название - «модель сервера приложений» AS (Application Server).

В этой модели все компоненты ИС делятся между тремя исполнителями.

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

Модель сервера приложений

Серверы приложений исполняют наиболее общие правила бизнеса, поддерживают доменную среду, обеспечивают обмен сообщениями между компонентами приложений. Прикладные функции сервера приложений оформлены как отдельные службы или сервисы (Service). Служба предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. В архитектуре ИС серверов приложений может быть несколько, и каждый из них предоставляет определенный набор сервисов. Любая программа, которая пользуется ими, рассматривается как клиент сервера приложений AC (Application Client). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. АС обращается с запросом к конкретному сервису, а не к AS. Запросы выстраиваются в очередь к AS-процессу, который передает их для обработки конкретной службе согласно установленным приоритетам.

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

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

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

Достоинства AS-модели:

· повышение производительности за счет разгрузки сервера;

· удешевление эксплуатации ИС;

· возможность усложнения бизнес-логики без потери производительности;

· улучшение свойств переносимости и масштабируемости ИС за счет использования стандартных языков программирования, например С, С++, Borland Pascal, Small Talk, Java, для реализации большей части бизнес-логики.

· клиентское ПО не нуждается в администрировании;

· конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

· высокая безопасность;

· высокая надежность;

· низкие требования к скорости канала (сети) между клиентами и сервером приложений;

· низкие требования к производительности и техническим характеристикам клиентов, как следствие снижение их стоимости.

Недостатки:

· растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание;

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

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

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

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

Главная > Документ

Многоуровневый "клиент-сервер"

Многоуровневая архитектура клиент-сервер (Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов . Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры. Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных. В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов. В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы. Плюсами данной архитектуры являются:

клиентское ПО не нуждается в администрировании; масштабируемость; конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней; высокая безопасность; высокая надежность; низкие требования к скорости канала (сети) между терминалами и сервером приложений; низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Минусы:

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

26. Оптимізація роботи з базою даних в режимі мережі.

Особенности управления одновременным доступом Управление одновременным доступом - это то, чем отличаются различные СУБД. Именно это отличает СУБД от файловой системы и одну СУБД от другой. Для программиста важно, чтобы его приложение базы данных корректно работало в условиях одновременного доступа, и именно это постоянно забывают проверять. Приемы, прекрасно работающие в условиях последовательного доступа, работают гораздо хуже при одновременном их применении несколькими сеансами. Если не знать досконально, как в конкретной СУБД реализованы механизмы управления одновременным доступом, то: будет нарушена целостность данных; приложение будет работать медленнее, чем предусмотрено, даже при небольшом количестве пользователей; будет потеряна возможность масштабирования до большого числа пользователей. Проблемы одновременного доступа выявлять сложнее всего - трудности сопоставимы с отладкой многопотоковой программы. Программа может отлично работать в уп- равляемой, искусственной среде отладчика, но постоянно "слетать" в "реальном мире". Например, в условиях интенсивных обращений может оказаться, что два потока одно- временно изменяют одну и ту же структуру данных. Такого рода ошибки очень сложно выявлять и исправлять. Реализация блокирования СУБД использует блокировки, чтобы в каждый момент времени те или иные дан- ные могли изменяться только одной транзакцией. Говоря проще, блокировки - это механизм обеспечения одновременного доступа. При отсутствии определенной модели бло- кирования, предотвращающей одновременное изменени. Принципы блокирования в СУБД Oracle. Oracle блокирует данные на уровне строк и только при изменении. Эскалация блокировок до уровня блока или таблицы никогда не выполняется. Oracle никогда не блокирует данные с целью считывания. При обычном чтении блокировки на строки не устанавливаются. Сеанс, записывающий данные, не блокирует сеансы, читающие данные. Повторю: операции чтения не блокируются операциями записи. Это принципиально отличается от практически всех остальных СУБД, в которых операции чтения бло кируются операциями записи. Сеанс записи данных блокируется, только если другой сеанс записи уже забло- кировал строку, которую предполагается изменять. Сеанс считывания данных ни- когда не блокирует сеанс записи. Блокируя ресурс, который мы пытаемся зарезервировать, мы гарантируем, что никакой другой сеанс в это же время не изменяет план использования ресурса. Ему придется ждать, пока наша транзакция не будет зафиксирована - после этого он сможет увидеть сделанное в ней резервирование. Возможность перекрытия планов, таким образом, устранена. Разработчик должен понимать, что в многопользовательской среде иногда необходимо использовать те же приемы, что и при многопотоковом программировании. В данном случае конструкция FOR UPDATE работает как семафор. Она обеспечивает последовательный доступ к конкретной строке в таблице ресурсов, гарантируя, что два сеанса одновременно не резервируют ресурс. Этот подход обеспечивает высокую степень параллелизма, поскольку резервируемых ресурсов могут быть тысячи, а мы всего лишь гарантируем, что сеансы изменяют конкретный ресурс поочередно. Это один из немногих случаев, когда необходимо блокирование вручную данных, которые не должны изменяться. Требуется уметь распознавать ситуации, когда это необходимо, и, что не менее важно, когда этого делать не нужно (пример, когда не нужно, приведен далее). Кроме того, такой прием не блокирует чтение ресурса другими сеансами, как это могло бы произойти в других СУБД, благодаря чему обеспечивается высокая масштабируемость. Многовариантность - это механизм, с помощью которого СУБД Oracle обеспечивает: согласованность по чтению для запросов: запросы выдают согласованные резуль таты на момент начала их выполнения; неблокируемые запросы: запросы не блокируются сеансами, в которых изменя ются данные, как это бывает в других СУБД. Это две очень важные концепции СУБД Oracle. Термин многовариантность произошел от того, что фактически СУБД Oracle может одновременно поддерживать множе ство версий данных в базе данных. Понимая сущность многовариантности, всегда можно понять результаты, получаемые из базы данных. Например мы создали тестовую таблицу Т и заполнили ее данными. Мы открыли курсор для этой таблицы. Мы не выбирали данные с помощью этого курсора, просто открыли его. Помните, что при открытии курсора сервер Oracle не "отвечает " на запрос; он никуда не копирует данные при открытии курсора (представьте, сколько времени потре бовало бы открытие курсора для таблицы с миллиардом строк в противном случае). Курсор просто открывается и дает результаты запроса по ходу обращения к данным. Другими словами, он будет читать данные из таблицы при извлечении их через курсор. В том же (или в другом) сеансе мы затем удаляем все данные из таблицы. Более того, мы даже фиксируем (COMMIT) это удаление. Строк больше нет - не так ли? На самом деле их можно извлечь с помощью курсора Фактически, результирующее множе- ство, возвращаемое командой OPEN, было предопределено в момент открытия курсора. Мы не прочитали при открытии курсора ни одного блока данных таблицы, но результат оказался жестко зафиксированным. Мы не сможем узнать этот результат, пока не извлечем данные, но с точки зрения нашего курсора результат этотнеизменен. Дело не в том, что СУБД Oracle скопировала все эти данные в другое место при открытии курсора; данные сохранил оператор delete, поместив их в область данных под названием сегмент отката. Именно в этом и состоит согласованность по чтению, и если не понимать, как работает схема многовариантности в Oracle и каковы ее последствия, вы не только не сможете воспользоваться всеми преимуществами СУБД Oracle, но и не создадите корректных приложений для Oracle, гарантирующих целостность данных. Поэтому если вы привыкли к реализации согласованности и одновременности запросов в других СУБД или просто никогда не сталкивались с такими понятиями (не имеете реального опыта работы с СУБД), то теперь понимаете, насколько важно для вашей работы их понимание. Чтобы максимально использовать потенциальные возможности СУБД Oracle, необходимо понимать эти проблемы и способы их решения именно в Oracle, а не в других СУБД.

30. Сервер додатка. Структура сервера додатка. Реєстрація сервера додатка

Сервер приложений инкапсулирует большую часть бизнес-логики распределенного приложения и обеспеч. доступ клиентов к базе данных. Основной частью сервера приложений является удаленный модуль данных. Во-первых, подобно обычному модулю данных он является платформой для размещения невизуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress. Во вторых, удаленный модуль данных реализует основные ф-и сервера приложений на основе предоставления клиентам интерфейса AppServer или его потомка. Для этого удаленный модуль данных должен содержать необход. число компонентов-провайдеров TDataSetProvider. Эти компоненты передают пакеты данных клиентскому приложению, а точнее компонентам TdientDataSet, а также обеспечивают доступ к методам интерфейса.
В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi .
Remote Data Module - удаленный модуль данных, инкапсулирующий сервер Автоматизации. Используется для организации соединений через DCOM, HTTP, сокеты (см. гл. 21).
Transactioiial Data Module - удаленный модуль данных, инкапсулирующий сервер MTS (Microsoft Transaction Server).
SOAP Server Data Module - удаленный модуль данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol).
WebSnap Data Module - удаленный модуль данных, использующий Web-службы и Web-браузер в качестве сервера.
С каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи клиенту, в модуле данных должен быть связан компонент-провайдер.

34. Відмінності SQL від мов високого рівня. Категорії операторів SQL.

SQL, не является процедурным языком, да и, по большому счету, он вообще не относится к языкам программирования.PL/SQL - это процедурный язык пошагового программирования, инкапсулирующий язык SQL. В результате получается хорошо развитый язык программирования третьего поколения (3GL), подобный языку C++, Pascal и т. д. В своей сути PL/SQL блочно ориентирован.PL/SQL имеет строгие правила области видимости переменных, поддерживает параметризованные вызовы процедур и функций и так же унаследовал от языка ADA такое средство, как пакеты (package).PL/SQL предусматривает строгий контроль типов, все ошибки несовместимости типов выявляются на этапе компиляции и выполнения. Так же поддерживается явное и неявное преобразование типов.PL/SQL - поддерживает сложные структуры данных, так же предусмотрена перегрузка подпрограмм, для создания гибкой среды прикладного программирования.Язык PL/SQL - имеет элемент Exception Handler (обработчик исключительных ситуаций) для синхронной обработки ошибок на этапе выполнения кода PL/SQL.Так же строго говоря, язык PL/SQL не является объектно-ориент., хотя имеет некоторые средства для создания и работы с объектами БД на уровне объектно-ориентированных языков программирования.PL/SQL - является машинно независимым языком программирования. Оператор - это символ, указывающий на действие, которое выполняется над одним или несколькими выражениями. Категории операторов, используемые SQL Server: Арифметические операторы,Логические операторы,Оператор присваивания,Оператор разрешения области, Битовые операторы, Операторы наборов, Операторы сравнения, Оператор объединения строк, Составные операторы, Унарные операторы

36) Логические операторы SQL. Эффективное построение запросов

Логические операторы AND, OR и NOT. Операторы AND и OR используются для объединения условий поиска в предложениях WHERE. Оператор NOT обращает значение условия поиска. Оператор AND соединяет два условия и возвращает TRUE, только если оба условия выполняются. Например, этот запрос возвратит только одну строку, в которой идентификатор клиента (BusinessEntityID) начинается с числа 1, а название магазина начинается с «Bicycle»:SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "1%" AND Name LIKE N"Bicycle%";Оператор OR также соединяет два условия, но возвращает TRUE, если выполняется хотя бы одно из условий. Следующий запрос возвращает 349 строк, в которых либо идентификатор заказчика начинается с 1, либо название магазина начинается с «Bicycle»: SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "1%" OR Name LIKE N"Bicycle%"; Оптимизация: Оптимизация SQL-запросовВсе больше приложений используют базы данных. Все больше данных приходится хранить и обрабатывать. Если приложение медлительное, программисты, пользователи и администраторы в первую очередь ссылаются на низкую производительность сети, плохие аппаратные средства сервера и друг на друга:). И забывают про оптимизацию.И такое будет продолжаться до тех пор, пока приложение не будет подвергнуто жестокому анализу на предмет повышения производительности. Один из способов повысить скорость работы приложения - оптимизация SQL-запросов. Этот способ хорош тем, что не надо лезть в дебри оптимизации SQL-сервера. Проще не допускать появления неэффективных SQL-запросов. Но если такое уже случилось, ищи выходы из сложившихся неприятных ситуаций. Общая оптимизацияКаждая SQL-операция имеет так называемый "коэффициент полезности" – уровень эффективности данной операции. Чем больше балл, тем "полезней" операция, а значит, SQL-запрос выполняется быстрее.Практически любое условие состоит из двух операндов и знака операции между ними. ПримерыЧтобы лучше понять таблицы, рассмотрим пример расчета рейтинга запроса.… WHERE smallint_column = 123455 баллов за поле слева (smallint_column), 2 балла за точный цифровой операнд(smallint_column), 10 баллов за операцию сравнения (=) и 10 баллов за значение справа (12345). Итого получили 27 баллов. Теперь рассмотрим более сложный пример:... WHERE char_column >= varchar_column || "x"5 баллов за поле слева (char_column), 0 баллов за символьный операнд (char_column), 5 баллов за операцию больше или равно (>=), 3 балла за логическое выражение (varchar_column || "x"), 0 баллов за символьный операнд (varchar_column). В итоге получим 13 баллов.Естественно, такие расчеты не обязательно проводить для каждого запроса. Но когда встанет вопрос о скорости условий того или иного запроса, его можно будет выяснить с помощью этих двух таблиц. На скорость запроса также влияет количество выбираемых данных и дополнительные директивы, которые рассмотрим ниже. Также имей в виду, что расчет "коэффициента полезности" не является неким универсальным способом оптимизации. Все зависит от конкретной ситуации.Основной закон при оптимизации запросов - закон преобразования. Неважно, как мы представляем условие, главное чтобы результат остался прежним. И снова рассмотрим пример. Есть запрос: ... WHERE column1 < column2 AND column2 = column3 AND column1 = 5. Используя перестановку, получаешь запрос: …WHERE 5 < column2 AND column2 = column3 AND column1 = 5. Результат запроса будет один и тот же, а продуктивность разной, потому что использование точного значения (5) влияет на производительность.Если ты изучал С или С++, то знаешь, что выражение x=1+1-1-1 во время компиляции станет x=0. Удивительно, что лишь некоторые БД способны выполнять такие операции. При выполнении запроса БД будет выполнять операции сложения и вычитания и тратить твое драгоценное время. Поэтому всегда лучше сразу рассчитывать такие выражения там, где это возможно. Не … WHERE a - 3 = 5, а … WHERE a = 8.Еще одна возможность оптимизировать запрос - придерживаться общей идеи составления условий в SQL. Другими словами, условие должно иметь вид: <колонка> <операция> <выражение>. Например, запрос "... WHERE column1 - 3 = -column2" лучше привести к виду: ... WHERE column1 = -column2 + 3.И эти приемы оптимизации работают практически всегда и везде. Оптимизируем условияТеперь настало время произвести оптимизацию самих условных операторов SQL. Большинство запросов используют директиву SQL WHERE, поэтому, оптимизируя условия, можно добиться значительной производительности запросов. При этом почему-то лишь небольшая часть приложений для БД используют оптимизацию условий. ANDОчевидно, что в серии из нескольких операторов AND условия должны располагаться в порядке возрастания вероятности истинности данного условия. Это делается для того, чтобы при проверке условий БД не проверяла остальную часть условия. Эти рекомендации не относится к БД Oracle, где условия начинают проверяться с конца. Соответственно, их порядок должен быть обратным – по убыванию вероятности истинности. ORСитуация с данным оператором прямо противоположна ситуации с AND. Условия должны располагаться в порядке убывания вероятности истинности. Фирма Microsoft настойчиво рекомендует использовать данный метод при построении запросов, хотя многие даже не знают об этом или, по крайней мере, не обращают на него внимание. Но опять-таки это не относится к БД Oracle, где условия должны располагаться по возрастанию вероятности истинности.Еще одним условием для оптимизации можно считать тот факт, что если одинаковые колонки располагаются рядом, запрос выполняется быстрее. Например, запрос ".. WHERE column1 = 1 OR column2 = 3 OR column1 = 2" будет выполняться медленней, чем запрос "WHERE column1 = 1 OR column1 = 2 OR column2 = 3". Даже если вероятность истинности условия column2 = 3 выше, чем column1 = 2. AND + ORЕще в школе мне рассказывали про распределительный закон. Он гласит, что A AND (B OR C) - то же самое, что и (A AND B) OR (A AND C). Опытным путем было установлено, что запрос вида "...WHERE column1 = 1 AND (column2 = "A" OR column2 = "B")" выполняется несколько быстрее, чем "...WHERE (column1 = 1 AND column2 = "A") OR (column1 = 1 AND column2 = "B")". Некоторые БД сами умеют оптимизировать запросы такого типа, но лучше перестраховаться. NOTЭту операцию всегда следует приводить к более "читабельному" виду (в разумных пределах, конечно). Так, запрос "...WHERE NOT (column1 > 5)" преобразуется в "...WHERE column1 <= 5". Более сложные условия можно преобразовать используя правило де Моргана, которое ты тоже должен был изучить в школе. Согласно этому правилу NOT(A AND B) = (NOT A) OR (NOT B) и NOT(A OR B) = (NOT A) AND (NOT B). Например, условие "...WHERE NOT (column1 > 5 OR column2 = 7)" преобразуется в более простую форму: ...WHERE column1 <= 5 AND column2 <> 7. INМногие наивно полагают, что запрос "... WHERE column1 = 5 OR column1 = 6" равносилен запросу "...WHERE column1 IN (5, 6)". На самом деле это не так. Операция IN работает гораздо быстрее, чем серия OR. Поэтому всегда следует заменять OR на IN, где это возможно, несмотря на то, что некоторые БД сами производят эту оптимизацию. Там, где используется серия последовательных чисел, IN следует поменять на BETWEEN. Например, "...WHERE column1 IN (1, 3, 4, 5)" оптимизируется к виду: …WHERE column1 BETWEEN 1 AND 5 AND column1 <> 2. И этот запрос действительно быстрее. LIKEЭту операцию следует использовать только при крайней необходимости, потому что лучше и быстрее использовать поиск, основанный на full-text индексах. К сожалению, я вынужден направить тебя за информацией о поиске на просторы всемирной паутины. CASEСама эта функция может использоваться для повышения скорости работы запроса, когда в нем есть более одного вызова медленной функции в условии. Например, чтобы избежать повторного вызова slow_function() в запросе "...WHERE slow_function(column1) = 3 OR slow_function(column1) = 5", нужно использовать CASE:... WHERE 1 = CASE slow_function(column1)WHEN 3 THEN 1WHEN 5 THEN 1END СортировкаORDER BY используется для сортировки, которая, как известно, занимает время. Чем больше объем данных, тем больше времени займет сортировка, поэтому нужно обязательно ее оптимизировать. На скорость сортировки в запросах влияет три фактора:

количество выбранных записей; количество колонок после оператора ORDER BY; длина и тип колонок, указанных после оператора ORDER BY. Самой ресурсоемкой сортировкой является сортировка строк. Несмотря на то, что текстовые поля имеют фиксированную длину, длина содержимого этих полей может быть различной (в пределах размера поля). Поэтому неудивительно, что сортировка колонки VARCHAR(100) будет медленней, чем сортировка колонки VARCHAR(10) (даже если данные будут одинаковые). А происходит это из-за того, что при сортировке сама база данных выделяет память для своих операций в соответствии с максимальным размером поля независимо от содержимого. Поэтому при объявлении полей всегда следует использовать размер, который нужен, и не выделять лишние байты про запас.На компьютерах с ОС Windows поля типа INTEGER занимают 32 бита, а поля типа SMALLINT – 16 бит. Логично предположить, что сортировка полей типа SMALLINT должна происходить быстрее. На самом деле сортировка INTEGER происходит быстрее, чем SMALLINT. Также сортировка INTEGER происходит быстрее, чем CHAR.Сортировка символов также имеет свои нюансы, описание которых займет не одну статью. Она может быть быстрой и неправильной или медленной, но с меньшим количеством ошибок. Оптимизации сортировки производится для конкретной ситуации, так что универсальных рекомендаций никто дать не может. ГруппированиеОперация GROUP BY используется для определения подмножества в результате запроса, а также для применения к этому подмножеству агрегатных функций. Рассмотрим несколько наиболее эффективных методов оптимизации операции группирования.Первое, что следует помнить, - нужно использовать как можно меньше колонок для группировки. Также следует избегать лишних условий. Например, в запросе SELECT secondary_key_column, primary_key_column, COUNT(*) FROM Table1 GROUP BY secondary_key_column, primary_key_column колонка secondary_key_column совершенно не нужна. Причина простая: secondary_key_column является уникальным полем, оно может не иметь значений NULL, а значит, некоторые данные могут просто потеряться. Но если убрать secondary_key_column из секции GROUP BY, некоторые БД могут выдать ошибку о том, что невозможно указывать это поле, если оно не объявлено в секции GROUP BY. Для решения этой проблемы можно написать запрос в таком виде: SELECT MIN(secondary_key_column), primary_key_column, COUNT(*) FROM Table1 GROUP BY primary_key_column. Этот запрос быстрее и "правильнее" с точки зрения конструирования запросов.В большинстве БД операции WHERE и HAVING не равноценны и выполняются не одинаково. Это значит, что следующие два запроса логически одинаковы, но выполняются с разной скоростью:SELECT column1 FROM Table1 WHERE column2 = 5 GROUP BY column1 HAVING column1 > 6SELECT column1 FROM Table1 WHERE column2 = 5 AND column1 > 6 GROUP BY column1Второй запрос работает быстрее, чем первый. HAVING следует использовать в тех редких случаях, когда условие (в примере column1 > 6) сложно выразить без ущерба производительности.Если требуется группирование, но без использования агрегатных функций (COUNT(), MIN(), MAX и т.д.), разумно использовать DISTINCT. Так, вместо SELECT column1 FROM Table1 GROUP BY column1 лучше использовать SELECT DISTINCT column1 FROM Table1.При использовании MIN() и MAX() учитываем, что эти функции лучше работают по отдельности. Это значит, что их лучше использовать в раздельных запросах или в запросах с использованием UNION.При использовании функции SUM() большей производительности можно добиться используя SUM(x + y), а не SUM(x) + SUM(y). Для вычитания лучше противоположное: SUM(x) – SUM(y) быстрее, чем SUM(x – y). Соединения таблиц (JOINS)Вот где сложно что-то сказать про оптимизацию, так это при использовании JOIN . Дело в том, что скорость выполнения таких операций во многом зависит от организации самой таблицы: использование foreign-key, primary-key, количество вложенных соединений и т.д. Иногда лучшей производительности можно добиться используя вложенные циклы непосредственно в программе. Иногда быстрее работают JOINs. Однозначного совета по тому, как использовать разные способы соединения таблиц, не существует. Все зависит от конкретного случая и архитектуры БД. Подзапросы (SUBQUERIES)Раньше далеко не все БД могли похвастаться поддержкой подзапросов, а сейчас практически любая современная БД это умеет. Даже MySQL, которая несколько лет воплощала подзапросы в жизнь, наконец разжилась их поддержкой. Основная проблема при оптимизации подзапросов - не оптимизация непосредственно самого кода запроса, а выбор правильного способа для реализации запроса. Задачи, для которых используются подзапросы, также могут решаться с помощью вложенных циклов или JOIN’ов. Когда используешь JOIN, даешь возможность БД выбрать механизм, которым будет производиться соединение таблиц. Если же используешь подзапросы, то явно указываешь на использование вложенных циклов. Что выбрать?Ниже аргументы в пользу того или иного способа. Выбирай сам в зависимости от ситуации. Достоинства JOIN:

Если запрос содержит условие WHERE, встроенный оптимизатор БД будет оптимизировать запрос в целом, в то время как в случае использования подзапросов запросы будут оптимизироваться отдельно. Некоторые БД более эффективно работают с JOINs, нежели с подзапросами (например, Oracle). После JOIN’а информация окажется в общем "списке", что нельзя сказать про подзапросы. Достоинства SUBQUERIES:

последнее время

Основное преимущество JOIN’ов в том, что не надо указывать БД то, каким именно способом производить операцию. А основное преимущество подзапросов в том, что цикл подзапроса может иметь несколько итераций (повторений), что, в свою очередь, может существенно увеличить производительность. ЗаключениеВ этой статье показаны самые распространенные способы увеличения производительности SQL-запросов. Тем не менее, чтобы оптимизировать запросы, есть еще очень много разных уловок и трюков. Оптимизация запросов больше похожа на искусство, чем на науку. У каждой базы данных свои встроенные оптимизаторы, которые могут помочь в этом нелегком деле, но всю работу за тебя никто не сделает. Как говорил старенький преподаватель по физике: "Чтобы решать задачи, их нужно решать".Не рекомендуется использовать ORDER BY в связке с такими операциями, как DISTINCT или GROUP BY, потому что данные операторы могут создавать побочные эффекты для сортировки. Как следствие, ты можешь получить неправильно отсортированный набор данных, который может оказаться критическим в некоторых ситуациях. Такое следствие не относится к оптимизации, но забывать о нем не стоит.Прежде чем повышать производительность сети и наращивать аппаратные средства сервера, попробуй сделать оптимизацию. У любой SQL-операции есть "коэффициент полезности". Чем выше коэффициент, тем "полезней" операция: запрос выполняется быстрее. В отличие от компиляторов, не все БД умеют упрощать выражения типа x=1+1-1-1 до x=0. Следовательно, они тратят драгоценное время на выполнение пустых операций. Оптимизируй их заранее. При использовании функции SUM() можно добиться большей производительности с помощью SUM(x + y), а не SUM(x) + SUM(y). Но если функции SUM() требуются для вычитания, используй противоположное: SUM(x) – SUM(y). SUM(x – y) работает медленнее. У каждой БД есть свои встроенные оптимизаторы, но они далеки от совершенства. Поэтому оптимизируй заранее.

38. Фізична організація бази даних в InterBase.

База данных InterBase состоит из последовательно, начиная с 0, пронумерован-ных страниц. Нулевая страница является служебной и содержит информацию, не¬обходимую для соединения с БД. Размер страницы - 1 (по умолчанию), 2, 4 или8 Кбайт. Размер страницы задается при создании БД, но может быть изменен при сохранении и восстановлении базы. Одна страница читается сервером за один логический доступ к БД.Объем буфера ввода-вывода для операций чтения-записи определяется в коли¬честве страниц (по умолчанию - 75). Если БД будет чаще читаться, объем бу¬фера следует увеличить. Если в нее будет чаще осуществляться запись, размер буфера можно уменьшить.В InterBase для записей поддерживается режим множества версий. При измене¬нии записи какой-либо транзакцией создается новая версия записи, куда помимо данных записывается номер транзакции и указатель на предыдущую версию за¬писи. Старая версия помечается как измененная; ее указатель на следующую вер¬сию записи содержит ссылку на вновь созданную версию. Каждая стартующая транзакция работает с последней версией записи, изменения для которой подтвер¬ждены. Таким образом, параллельно работающие с БД транзакции всегда исполь¬зуют разные версии записей, что позволяет снимать блокировки для клиентских приложений, одновременно работающих с одними и теми же данными в БД. При удалении записи она также физически не удаляется с диска, а помечается как уда¬ленная до тех пор, пока не завершатся все активные транзакции, использующие эту запись.InterBase размещает на одной своей странице все версии одной записи ТБД. Пос¬ле удаления записей на странице образуются «дырки». При добавлении новой записи анализируется размер максимальной «дырки», и, если он меньше длины добавляемой записи, происходит сжатие страницы, в процессе которой «дырки» объединяются. Если освободившегося пространства не хватает для размещения новой записи, та записывается с новой страницы. Загрузка страницы считается нормальной в случае, если «дырки» занимают не более 20 % объема страницы.Выделение страниц никак не оптимизировано. На отдельной служебной страни¬це БД хранятся номера всех свободных страниц. При выделении страниц не пред¬принимается никаких действий по выделению последовательно расположенных страниц для хранения записей одной таблицы БД, а выделяется первая страница в списке свободных. Если свободной страницы нет, добавляется новая в конец БД. Только в этом случае размер БД возрастает.Структура записей, поддерживающая режим множества версий, и неоптимальное выделение страниц ведут к высокой фрагментации БД и как следствие - к замед¬лению работы с ней. Поэтому необходимо периодически производить дефрагмен-тацию БД. Дефрагментированная БД характеризуется расположением записей таблиц БД на последовательно расположенных страницах и отсутствием «мусо¬ра». Под мусором понимаются версии записей, с которыми не работает никакая активная транзакция.Для удаления мусора БД сохраняется на дисковом носителе и затем восстанавли¬вается из сделанной резервной копии с помощью утилиты IBConsole (для преды¬дущих версий InterBase - с помощью утилиты InterBase Server Manager). Этот процесс гарантирует удаление всего мусора, так как в момент сохранения истановления БД не должно быть активных подключений к БД со стороны дру¬гих пользователей и потому не может быть активных транзакций. Кроме того, в InterBase предусмотрено автоматическое удаление мусора на фоне активных транзакций. Интервал, через который происходит автоматическое удаление му¬сора, по умолчанию составляет 20 000 транзакций. Это значение может быть из¬менено с помощью утилиты IBConsole (InterBase Server Manager). При автома¬тической очистке удаляются только те версии записей, для которых нет активных транзакций. В результате могут быть удалены не все старые версии.

Основи SQL

1. Створення бази даних (Create Database).

В различных СУБД процедура создания баз данных обычно закрепляется только за администратором баз данных. В однопользовательских системах принимаемая по умолчанию база данных может быть сформирована непосредственно в процессе установки и настройки самой СУБД. Стандарт SQL не определяет, как должны создаваться базы данных, поэтому в каждом из диалектов языка SQL обычно используется свой подход. Процесс создания базы данных в системе SQL-сервера состоит из двух этапов: сначала организуется сама база данных , а затем принадлежащий ей журнал транзакций . Информация размещается в соотв. файлах, имеющих расширения *.mdf (для базы данных ) и *.ldf. (для журнала транзакций ). В файле базы данных записываются сведения об основных объектах (таблицах , индексах , просмотрах и т.д.), а в файле журнала транзакций – о процессе работы с транзакциями (контроль целостности данных, состояния базы данных до и после выполнения транзакций). Создание базы данных в системе SQL-сервер осуществляется командой CREATE DATABASE. (процедура создания базы данных в SQL-сервере требует наличия прав администратора сервера.)<определение_базы_данных> ::= CREATE DATABASE имя_базы_данных [ <определение_файла> [,...n] ] [,<определение_группы> [,...n] ] ] [ LOG ON {<определение_файла>[,...n] } ] [ FOR LOAD | FOR ATTACH ] Параметр ON определяет список файлов на диске для размещения информации, хранящейся в базе данных . Параметр PRIMARY определяет первичный файл . Если он опущен, то первичным является первый файл в списке. Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций . Имя файла для журнала транзакций генерируется на основе имени базы данных , и в конце к нему добавляются символы _log.

Основи SQL.

3. Створення доменів (Create Domain). Створення таблиць (Create Table)

CREATE TABLE table ( [, | ...]);где table - имя создаваемой таблицы, - описание поля, - описание ограничений и/или ключей (квадратные скобки означают необязательность, вертикальная черта | означает "или").Описание поля состоит из наименования поля и типа поля = col {datatype | COMPUTED BY () | domain} [] Здесь col - имя поля;datatype - любой правильный тип SQL-сервера, символьные типы могут иметь CHARACTER SET - набор символов, определяющий язык страны. Для русского языка следует задать набор символов WIN1251;COMPUTED BY () - определение вычисляемого на уровне сервера поля, где - правильное SQL-выражение, возвращающее единственное значение;domain - имя домена (обобщенного типа), определенного в базе данных;DEFAULT - конструкция, определяющая значение поля по умолчанию;NOT NULL - конструкция, указывающая на то, что поле не может быть пустым;COLLATE - предложение, определяющее порядок сортировки для выбранного набора символов.ПримерCREATE TABLE lsn_team (id lsn_dintkey, name lsn_dname UNIQUE, founded lsn_dfounded, PRIMARY KEY(id))Создание доменаИзучая предметную область разработчик базы данных часто сталкивается с тем, что встроенный тип слишком "широк" для хранения атрибута рассматриваемой сущности. Например, нужно вводить возраст, а типы данных INTEGER и SMALLINT предоставляют слишком широкие диапазоныю Сервер предоставляет нам возможность создать свой тип данных, наложив на него необходимые ограничения. Тип данных в SQL называется доменом и для его создания служит команда CREATE DOMAIN : CREATE DOMAIN dage AS INTEGER DEFAULT 0 CHECK(VALUE >= 0 AND VALUE <= 120) Рассмотрим приведенную выше команду. Мы попросили сервер создать домен CREATE DOMAIN с именем dage на основе целочисленного типа AS INTEGER, причем, если пользователь не укажет возраст, то будет использовано значение по умолчанию 0 -- DEFAULT 0, и значение поля должно находиться в пределах от 0 до 120 -- CHECK(VALUE >= 0 AND VALUE <= 120). Мы могли бы указать, что поле будет обязательно для заполнения -- NOT NULL, но в этом нет необходимости, так как NULL значение в любом случае не пройдет проверку CHECK.

Основи SQL

5. Батьківська і підлегла БД. Забезпечення посилальної цілісності

Декларативные ограничения целостности задаются на уровне операторов создания таблиц. При описании таблицы задается имя таблицы, которое является идентификатором в базовом языке СУБД и должно соответствовать требованиям именования объектов в данном языке. Кроме имени таблицы в операторе указывается список элементов таблицы, каждый из которых служит либо для определения столбца, либо для определения ограничения целостности определяемой таблицы. Требуется наличие хотя бы одного определения столбца. То есть таблицу, которая не имеет ни одного столбца, определить нельзя. Количество столбцов в одной таблице не ограничено, но в конкретных СУБД обычно бывают ограничения на количество атрибутов. Так, например, в MS SQL Server 6.5 максимальное количество столбцов в таблице было 250, но уже в MS SQL Server 7.0 оно увеличено до 1024.При задании ограничений уникальности данный столбец определяется как возможный ключ, что предполагает уникальность каждого вводимого значения в данный столбец. И если это ограничение задано, то СУБД будет автоматически осуществлять проверку на отсутствие дубликатов значений данного столбца во всей таблице. Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца, то порождается соответствующее определение ограничения по ссылкам для таблицы: FOREIGN KEY(<имя столбца>) < спецификация ссылки>, что означает, что значения данного столбца должны быть взяты из соответствующего столбца родительской таблицы. Родительской таблицей в данном случае называется таблица, которая связана с данной таблицей связью "один-ко-многим" (1:М). При этом каждая строка родительской таблицы может быть связана с несколькими строками определяемой таблицы. Трансляция операторов SQL проводится в режиме интерпретации, поэтому важно, чтобы сначала была бы описана родительская таблица, а потом уже все подчиненные таблицы, связанные с ней. Иначе транслятор определит ссылку на неопределенный объект. Сначала должны быть описаны все основные таблицы, а потом подчиненные таблицы.

Основи SQL

8. Підзапити. Вкладені підзапити

Подзапрос - очень мощное средство языка SQL. Он позволяет строить сложные иерархии запросов, многократно выполняемые в процессе построения результирующего набора или выполнения одного из операторов изменения данных (DELETE, INSERT, UPDATE). Условно подзапросы иногда подразделяют на три типа, каждый из которых является сужением предыдущего:

табличный подзапрос, возвращающий набор строк и столбцов; подзапрос строки, возвращающий только одну строку, но, возможно, несколько столбцов (такие подзапросы часто используются во встроенном SQL); скалярный подзапрос, возвращающий значение одного столбца в одной строке. Вложенный подзапрос - это подзапрос, заключенный в круглые скобки и вложенный в WHERE (HAVING) фразу предложения SELECT или других предложений, использующих WHERE фразу. Вложенный подзапрос может содержать в своей WHERE (HAVING) фразе другой вложенный подзапрос и т.д. Нетрудно догадаться, что вложенный подзапрос создан для того, чтобы при отборе строк таблицы, сформированной основным запросом, можно было использовать данные из других таблиц (например, при отборе блюд для меню использовать данные о наличии продуктов в кладовой пансионата).SELECT * from tbl1 WHERE f2=(SELECT f2 FROM tbl2 WHERE f1=1);Коррелированные подзапросы В операторе SELECT из внутреннего подзапроса можно ссылаться на столбцы внешнего запроса, указанного во фразе SELECT. Такой подзапрос выполняется для каждой строки таблицы, определяя условие ее вхождения в формируемый результирующий набор. Например:SELECT * from tbl1 t1 WHERE f2 IN (SELECT f2 FROM tbl2 t2 WHERE t1.f3=t2.f3); В данном случае для каждой строки таблицы tbl1 будет проверяться условие, что значение поля f2 совпадает со значением строки таблицы tbl2, где значение поля f3 равно значению поля f3 внешней таблицы (tbl1). Это простейший пример коррелированного подзапроса.

Предисловие Системы управления базами данных (субд) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются
Документ
Системы управления базами данных (СУБД) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются базами данных.
Http://www citforum ru/database/osbd/contents shtml Основы современных баз данных
Реферат
Управления базой данных (субд). Неформально можно определить базу данных как некоторый набор данных, необходимый для работы и организованный тем или иным способом
Лекция
На первой лекции мы рассмотрим общий смысл понятий база данных (БД) и система управления базой данных (СУБД). Неформально можно определить базу данных как некоторый набор данных, необходимый для работы и организованный тем или иным способом.

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

Преимущества

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

Все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов. На сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.

Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т.п.

[править]

Недостатки

Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.

Поддержка работы данной системы, требует отдельного специалиста - системного администратора.

Высокая стоимость оборудования.

[править]

Многоуровневая архитектура клиент-сервер

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

Частные случаи многоуровневой архитектуры:

Трёхуровневая архитектура

[править]

Сеть с выделенным сервером

Сеть с выделенным сервером (англ. Client/Server network) - это локальная вычислительная сеть (LAN), в которой сетевые устройства централизованы и управляются одним или несколькими серверами. Индивидуальные рабочие станции или клиенты (такие, как ПК) должны обращаться к ресурсам сети через сервер(ы).

Введение

О технологии клиент-сервер написано уже очень много. Можно заметить, что некий ажиотаж вокруг этой темы, имевший место еще два года назад, теперь определенно спал. Статьи в прессе и разговоры в кулуарах приобрели спокойный, деловой тон и обсуждают теперь, как правило, конкретные аспекты применения этой технологии. Вопроса "Быть или не быть архитектуре клиент-сервер?" теперь уже никто не поднимает - все знают, что "Быть!".

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

Что такое архитектура клиент-сервер?

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

В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..

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

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

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

Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).

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

Когда вам нужна архитектура клиент-сервер?

Даже очень детальный анализ особенностей архитектуры клиент-сервер может не ответить на вопрос "А что мне это даст?" Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему:

Надежность

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

Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:

атомарность - при любых обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;

независимость - транзакции, инициированные разными пользователями, не вмешиваются в дела друг друга;

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

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

Масштабируемость

Масштабируемость - способность системы адаптироваться к росту количества пользователей и объема базы данных при адекватном повышении производительности аппаратной платформы, без замены программного обеспечения.

Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, разумеется, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что наиболее существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры.

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

Безопасность

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

Гибкость

В приложении, работающем с данными, можно выделить три логических слоя:

пользовательского интерфейса;

правил логической обработки (бизнес-правил);

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

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

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

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

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

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

2) В двухуровневой клиент-серверной системе, если алгоритм расчета зарплаты реализован на сервере в виде правила расчета зарплаты, его выполняет сервер бизнес-правил, выполненный, например, в виде OLE-сервера, и мы обновим один из его объектов, ничего не меняя ни в клиентском приложении, ни на сервере баз данных.

Этапы построения клиент-серверной системы.

Предположим, Вы сегодня используете приложение, реализованное в файл-серверной архитектуре, средствами, Microsoft Access, и думаете о его развитии. Можно рассмотреть следующие шаги.

1.Перенести базу данных на Microsoft SQL Server, сохранив интерфейс и логику работы неизменной. Вы при этом не будете использовать все преимущества архитектуры клиент-сервер, но можете быть спокойны за надежность хранения ваших данных.

2.Разработать полноценное двухуровневое клиент-серверное приложение, используя все ту же связку Access - SQL Server, которая работает очень хорошо. Делать это можно, например, постепенно меняя отдельные компоненты приложения, полученного на шаге 1. Альтернативой может быть разработка полностью нового приложения с использованием в качестве клиента Visual Basic, Delphi или любого другого из десятков имеющихся инструментов.

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

Надеемся, что эта статья дала Вам общее представление об архитектуре клиент-сервер и ее преимуществах. В следующих номерах мы планируем подробнее рассказать о Microsoft SQL Server и построении систем на его основе.