Задание и проведение транзакций

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

• механизма блокировок;

• создания регистрационной информации (log-информации);

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

39. Управление доступом к данным в SQL

Одного предоставления доступа к экземпляру SQL Server будет недостаточно для приложения, которому необходим доступ к данным. Предоставив доступ к экземпляру SQL Server, необходимо предоставить доступ к определенным базам данных. Доступ к базам данных предоставляется посредством добавления пользователей базы данных и сопоставления пользователям базы данных имен входа. Каждое имя входа сопоставляется пользователю базы данных для каждой базы данных, к которой этому имени входа нужен доступ. Каждый пользователь базы данных сопоставляется только одному имени входа, за исключением пользователя базы данных dbo.

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

Пользователи базы данных - это участники уровня базы данных. Все имена входа, за исключением серверной роли sysadmin, должны быть сопоставлены пользователям, которые, в свою очередь, сопоставлены базе данных, к которой им нужен доступ. Члены ролиsysadmin сопоставлены пользователю dbo во всех базах данных сервера.

Добавляем пользователя базы данных

Добавить пользователя базы данных можно при помощи инструкции CREATE USER. Следующий пример кода Transact-SQL создает имя входа Peter и сопоставленного с ним пользователя в базе данных Adventure Works:

• Создаем имя входа Peter

CREATE LOGIN Peter WITH PASSWORD='Tyu87IOR0';

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Добавляем пользователя базы данных Peter, который сопоставлен имени входа Peter в БД AdventureWorks.

CREATE USER Peter FOR LOGIN Peter;

Управляем пользователями базы данных Проверить, имеет ли текущее имя входа доступ к базе данных, можно при помощи следующей инструкции:

SELECT HAS_DBACCESS('AdventureWorks');

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

Если нужно временно отключить доступ пользователя к базе данных, можно отозвать разрешение CONNECT для этого пользователя. Следующий пример отзывает разрешение CONNECT для пользователя Peter:

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Отзываем разрешение connect для Peter в AdventureWorks.

REVOKE CONNECT TO Peter;

39. Встраивание SQL к прикладным программам

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

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

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

39. Диалекты SQL в СУБД

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

Выделяют три уровня соответствия стандарту ANSI— начальный, промежуточный и полный. В

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

больше и больше отличаются друг от друга. Это имеет свои достоинства и недостатки. Конкретная

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

стандартом SQL, например, больше типов данных, большее количество команд, больше дополнительных возможностей у имеющихся команд. Такие возможности делают работу с конкретной СУБД более эффективной. Кроме того, такие нестандартные возможности языка проходят практическую апробацию и со временем могут быть включены в стандарт. Недостаток в том, что различия в синтаксисе реализаций SQL затрудняют перенос приложений из одной системы в другую. Например, если приложение было написано для базы данных MS SQL Server с использованием своего диалекта SQL – языка Transact-SQL, то при переносе системы в базу данных ORACLE, не все конструкции языка будут понятнысоответствующему диалекту SQL – языку PL/SQL.В

широко распространенных в настоящее время СУБД используются следующие диалекты языка

SQL:

- PL/SQL

- Transact-SQL

- Informix-SQL

- Jet SQL

39. Эволюция концепций в обработке данных

Обработка данных – это совокупность методов и средств, осуществляющих преобразование данных. В общем случае обработка данных включает в себя ввод данных в компьютер, преобразование и отбор данных по каким-либо критериям, вывод данных в удобном для пользователя виде. Концепции обработки данных прошли эволюционный путь развития, тесно связанный с развитием вычислительной техники. Исторически можно выделить следующие концепции обработки данных:

· обработка на мэйнфреймах в пакетном режиме;

· обработка в многотерминальных системах;

· обработка на автономных персональных компьютерах;

· обработка данных с использованием компьютерных сетей.

39. Архитектура файл/сервер. Обработка запросов в ней. Причины неэффективности файл/сервер. Настольные СУБД. Их достоинства и недостатки

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

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

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

Настольные СУБД отличаются тем, что используют в модель вычислений с сетью и файловым сервером (архитектура «файл-сервер»). Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явилось предпосылками появления новой архитектуры «файл-сервер». Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных. В соответствие с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных.

39. Клиент/серверные системы. Выполнение запросов в клиент/сервер. Преимущества. Характеристики серверов БД

Клиент-серверная система – это система с пользовательским интерфейсом, расположенным на клиенте, и данными, хранящимися на сервере.

Известны две вариации таких систем: “тонкий” клиент и “толстый” клиент. В первом случае у клиентов может не быть своих собственных компонентов для обработки данных и вычислительные ресурсы ограничены. Во втором – вычислительные ресурсы клиента больше, он может заниматься не только визуализацией данных, но и их обработкой.

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

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

Внимание уделяется:

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

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

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

39. Механизмы доступа к внешним БД

Существует два класса механизма доступа к БД:

• на стороне сервера (используются интерфейсы CGI, API и др.);

• на стороне клиента (используются языки Java, JavaScript и др.).

Для обеспечения доступа к базам данных на стороне Web-клиента используются языки Java, JavaScript, VBScript и др. Одно из важных свойств этих языков – это мобильность, которая заключается в том, что написанный код может использоваться на любой платформе.

Написанные программы (апплеты), на основе этих языков, компилируются в мобильные коды и соответствующие ссылки на определённые коды этих программ ставятся в HTML-документе. Браузер, работающий с таким документом, запрашивает у Web-сервера все мобильные коды. Коды могут начать выполняться сразу после размещения в компьютере клиента или быть активизированы с помощью специальных команд. Такие апплеты могут быть специализированы для работы с БД.

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

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

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

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

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

39. Понятие и архитектура распределённых БД. Гомогенные и гетерогенные РаБД. Стратегия распределения данных в РаБД

Распределенная БД (РаБД) – набор логически связанных между собой разделяемых данных и их

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

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

Репликаты – множество различных физических копий некоторого объекта БД, для которых в соответствии с определенными в БД правилами поддерживается синхронизация с некоторой «главной копией».

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

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

РаСУБД – комплекс программ для управления РаБД, позволяющие сделать распределяемость данных «позрачной» для конечных пользователей. Основная задача РаСУБД – обеспечить интеграцию локальн БД, чтобы польз-ль имел доступ ко всем БД как к единой БД.

39. Распределённые СУБД. Двенадцать правил К. Дейта. Преимущества и недостатки РаСУБД

Распределенная СУБД (РаСУБД) – комплекс программ, предназначенный для управления распределенной БД и позволяющий сделать распределённость информации «прозрачной» для конечного пользователя.