Операторы ddl (Data Definition Language) - операторы определения объектов базы данных

• CREATE SCHEMA - создать схему базы данных

• DROP SHEMA - удалить схему базы данных

• CREATE TABLE - создать таблицу

• ALTER TABLE - изменить таблицу

• DROP TABLE - удалить таблицу

• CREATE DOMAIN - создать домен

• ALTER DOMAIN - изменить домен

• DROP DOMAIN - удалить домен

• CREATE COLLATION - создать последовательность

• DROP COLLATION - удалить последовательность

• CREATE VIEW - создать представление

• DROP VIEW - удалить представление

42. Операторы манипулирования данными. Операторы DML (Data Manipulation Language) - операторы манипулирования данными

• SELECT - отобрать строки из таблиц

• INSERT - добавить строки в таблицу

• UPDATE - изменить строки в таблице

• DELETE - удалить строки в таблице

• COMMIT - зафиксировать внесенные изменения

• ROLLBACK - откатить внесенные изменения

42. Операторы защиты и управления данными.Операторы защиты и управления данными

• CREATE ASSERTION - создать ограничение

• DROP ASSERTION - удалить ограничение

• GRANT - предоставить привилегии пользователю или приложению на манипулирование объектами

• REVOKE - отменить привилегии пользователя или приложения

45.Транзакции

Транзакция – понимается неделимое с точки зрения воздействие на БД последовательность операторов манипулирования данных, а конкретно чтение удаления модификация вставка. Приводящие к одному из двух возможных … либо последовательно выполняется, если все операторы правильные, либо вся транзакция откатывается, если один оператор не может быть успешно выполнен Транзакции составляют основу изолированности многопользовательских систем, где с одной БД могут параллельно работать несколько пользователей. Одна из основных задач СУБД это обеспечение изолированности, то есть создание такого режима функционирования при котором каждому пользователю казалось что БД доступно только ему. Такую задачу СУБД принято называть парралелизмом транзакции. При выполнении транзакции СУБД должна придерживаться определенных правил обработки набора команд входящих в транзакцию, в частности разработано 4 правила известные как требования acid, они гарантируют правильность работы системы:

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

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

3. Транзакция всегда изолированная, поскольку ее результаты самодостаточные. Они не зависят от предыдущих или последующих транзакций, это свойство называется сериализуемостью и означает, что транзакции последовательности не зависимы.

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

Блокировки

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

Различают два вида блокировки:

1. блокировка записи – транзакция блокирует все строки в таблицы таким образом, что запрос других транзакций к этим строкам будет отменен.

2. Блокировка чтения – транзакция блокирует строки так, что запрос со стороны другой транзакции на блокировки записи будет ответным, а на блокировку чтения принят.

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

1. Транзакция, результатом действия которой на строку данных является ее извлечение, обязана наложить блокировку чтения на эту строку.

2. Транзакция, предназначенная для модификации строки данных, накладывает на нее блокировку записи.

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

4. Блокировка записи сохраняется вплоть до конца выполнения транзакции.

Если СУБД не реализованы механизм блокирования, то при одновременном чтении и изменении одних и тех же данных несколькими пользователями могут возникнуть проблемы одновременного доступа.

Модели (клиент – сервер).

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

1. функции ввода и отображения данных (presentation logic)

2. прикладные функции, определяющие основные алгоритмы решения задач приложения (bisnes logic)

3. функции обработки данных внутри приложения (database logic)

4. функции управления информационными ресурсами (database manager system)

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

Модель удаленного управления данными или модель файлового сервера.

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

В ЭТОЙ модели файла… клиент обращается к серверу с файловой команды, а механизм управления всеми информационными ресурсами находится на клиенте. Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом серверный процесс может обслуживать множество клиентов, которые обращаются к нему с запросами. СУБД должна находится в этой модели на клиенте.

Алгоритм выполнения запроса клиента:

-запрос клиента формируются в команды

-СУБД переводит этот запрос в последовательность файловых команд

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

- на клиенте СУБД анализирует полученную информацию и если в полученном блоке не содержится ответа на запрос то принимается решение о перекачке следующего блока информации и так далее пока не будет получен запрос на ответ клиента.

Недостатки:

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

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

-отсутствие средств безопасности доступа к данным

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

В модели RDA база данных хранится на сервере. На сервере также находится ядро СУБД. На клиенте располагается презентационная логика и бизнес логика. Клиент обращается к серверу с запросом на языке sql.

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

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

-сервер БД освобождается от не свойственных ему функций. В процессоре и процессов сервера целиком загружается операциями обработки данными операциями

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

Недостатки:

-запросы на языке SQL при интенсивной работе клиентского приложения могут все-таки существенно загрузить сеть.

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

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

Модель сервера БД

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

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

Недостатки:

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

• осуществляет мониторинг событий связанных с описанными триггерами

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

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

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

Если мы переложили на сервер большую часть бизнес логики приложения, то требования к клиентам резко уменьшаются. Иногда такую модель называют моделью с тонким клиентом.

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

Эта модель является расширением двухуровневой модели и в ней вводятся дополнительный промежуточный уровень между клиентом и сервером.

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

Второй компонент это сервер приложений. Сервер приложений составляет новый промежуточный уровень архитектуры. Они с проектированы как исполнения общих не нагружаемых функций приложения.

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

Серверы БД. СБД в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и введения БД, обеспечивают целостность БД, обеспечивают функции хранилищ данных. Кроме того на них возлагаются функции создания резервных копий БД, восстановление БД после сбоев, управление выполнением транзакций и поддержку устаревших приложений. Отметим что эта модель обладает большей гибкостью чем двухуровневая модель, наиболее заметны модели сервера приложения в том случаях когда клиенты выполняют сложные аналитические расчеты над БД которые относятся к области OLAP приложений. В этой модели большая часть бизнес логики клиента изолирована от возможности встроенного SQL и может быть выполнена на стандартных языках программирования. Это повышает переносимость системы и ее масштабируемость.

Модели серверов БД.

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

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

18