«Разработка и эксплуатация удалённых баз данных» Учебное пособие преподавателя Французовой Г.Н.

Французова Г.Н.2 1. Разработка и эксплуатация удаленных баз данных –1.1 Введение в дисциплину 1.1 Введение в дисциплину –1.2. Терминология УБД1.2. Терминология УБД –1.3. Модель "клиент-сервер"1.3. Модель "клиент-сервер" –1.4. Двухуровневые модели 1.4. Двухуровневые модели –1.5. Модели серверов баз данных 1.5. Модели серверов баз данных –1.6. Типы параллелизма 1.6. Типы параллелизма –1.7. Модели транзакций 1.7. Модели транзакций –1.8. Свойства транзакций. Способы их завершения.1.8. Свойства транзакций. Способы их завершения. –1.9. Журнал транзакций.1.9. Журнал транзакций. –1.10. Структура журнала Структура журнала 2. Многопользовательская работа с БД в СУБД MS Access _2.1. Существующие в Access типы прав доступа –2.2. Манипуляции с файлами РГ –2.3. Шифрование БД –2.4. Репликация баз данных

Французова Г.Н Введение в дисциплину. При размещении БД на ПК, который не находится в сети, БД всегда используется в монопольном режиме. Даже если БД используют несколько пользователей, они могут работать с БД только последовательно. Однако работа на изолированном ПК с небольшой БД в настоящий момент становится уже не характерной для большинства приложений. БД отражает информационную модель реальной ПО, она растет по объему => резко увеличивается количество задач, решаемых с помощью этой БД и в соответствии с этим увеличивается количество приложений, работающих с единой БД. ПК объединяются в локальные сети и необходимость распределения приложений, работающих с единой БД по сети, является несомненной. В начало

Французова Г.Н.4 Системы распределенных ( удаленных ) баз данных Если БД расположена на нескольких ПК, распределенных в сети, и к ней возможен параллельный доступ нескольких пользователей, то мы имеем дело с параллельным доступом к распределенным БД. Такие системы называются системами распределенной обработки данных. В начало

Французова Г.Н.5 Режимы работы с базой данных. В начало

Французова Г.Н Терминология УБД. Пользователь БД - это программа или человек, обращающиеся к БД на языке манипулирования данными. Запрос - это процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД. Транзакция - это последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние. Логическая структура БД - это определение БД на физически независимом уровне, ближе всего соответствующем концептуальной модели БД. Топология БД (структура РБД) - это схема распределения физических БД по сети. Локальная автономность означает принадлежность локальному владельцу информации локальной БД и связанных с ней определенных данных. Удаленный запрос - это запрос, который выполняется с использованием модемной связи. В начало

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

Французова Г.Н Модель "клиент-сервер" Модель "клиент-сервер" связана с принципом открытых систем. Термин "клиент-сервер" исходно применялся в архитектуре ПО, которое ориентировало распределение процесса выполнения по принципу взаимодействия 2-х программ, процессов, один из которых в этой модели назывался клиентом, а другой - сервером. При этом предполагалось, что один серверный процесс может обслуживать множество клиентских процессов. В начало

Французова Г.Н.9 Ранее приложение (пользовательская программа) не разделялось на части, а выполнялось монолитным блоком, но при рациональном использовании ресурсов сети данный принцип не актуален. Теперь все ПК в сети обладают собственными ресурсами и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы. В начало

Французова Г.Н.10 Основной принцип технологии "клиент-сервер" в БД заключается в разделении функций стандартного интерактивного приложения на 5 групп: Функция ввода и отображения данных (PL); Прикладные функции, определяющие основные алгоритмы решения задач приложения (BL); Функции обработки данных внутри приложения (DL); Функции управления информационными ресурсами (DML); Служебные функции, играющие роль связок между функциями 1-х и 4-х групп. В начало

Французова Г.Н.11 Структура типичного приложения, работающего с БД. В начало

Французова Г.Н.12 PL - это часть приложения, которая определяется тем, что пользователь видит на экране, когда работает приложение (интерактивные экранные формы, а также все то, что выводится пользователю на экран, результаты решения некоторых промежуточных задач, справочная информация). BL - это часть кода приложения, которая определяет алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования. DL - это часть кода приложения, которая связана с обработкой данных внутри приложения (данными управляет собственно СУБД), где используется язык запросов и средства манипулирования данными стандартного языка SQL.

Французова Г.Н.13 Основные задачи PL: формирование экранных изображений; чтение и запись в экранные формы информации; управление экраном; обработка движений мыши и нажатий клавиш клавиатуры. В начало

Французова Г.Н.14 Процессор управления данными (Data Base Manager System Processing) - это собственно СУБД, которая обеспечивает управление и хранение данных. В идеале СУБД должна быть скрыта от BL-приложения. Однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения. В начало

Французова Г.Н Двухуровневые модели. Эти модели фактически являются распределением пяти указанных функций между двумя процессами, которые выполняются на двух платформах - клиенте и сервере. Модель удаленного управления данными (модель файлового сервера). В этой модели BL и PL располагаются на клиенте. На сервере располагаются файлы с данными и доступ к ним. Функции управления информационными ресурсами в этой модели находятся на клиенте. В начало

Французова Г.Н.16 Модель файл-сервера. В этой модели файлы БД хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами ( база метаданных ( БМД )) находится на клиенте. В начало

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

Французова Г.Н.18 Алгоритм выполнения запроса клиента. Запрос клиента формируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента. Далее на клиенте СУБД анализирует полученную информацию. Если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации до тех пор, пока не будет найдено ответа на запрос.

Французова Г.Н.19 Модель удаленного доступа к данным. В модели удаленного доступа (RDA) база данных хранится на сервере. На нем же находится и ядро СУБД. На клиенте располагаются PL и BL приложения. Клиент обращается к серверу с запросами на языке SQL. В начало

Французова Г.Н.20 Достоинства модели удалённого доступа : перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС. процессор сервера целиком загружается операциями обработки данных, запросов и транзакций. резко уменьшается загрузка сети, запросы на ввод- вывод и на SQL уменьшаются в объеме, т.е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу. унификация интерфейса клиент-сервер. стандартным при обращении приложения клиента и сервера становится язык SQL. В начало

Французова Г.Н.21 Недостатки: запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть. на клиенте располагаются PL и BL, и если при повторении аналогичных функций в различных приложениях (других клиентов) их код должен быть повторен для каждого клиентского приложения, следовательно, дублирование кода приложения. сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте => это усложняет клиентское приложение. В начало

Французова Г.Н.22 Модель сервера баз данных. Для того, чтобы избавиться от недостатков модели удаленного доступа должны быть соблюдены следующие условия: Данные, которые хранятся в БД в каждый момент времени должны быть непротиворечивы. БД должна отображать некоторые правила ПО, законы ПО. Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них. Возникновение некоторой ситуации в БД четко и оперативно должно влиять на ход выполнения прикладной задачи. Одной из важных проблем СУБД является контроль типов данных через язык описания данных (ЯОД). В начало

Французова Г.Н.23 Модель активного сервера. В начало Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур (как средства программирования SQL-сервера), механизм триггеров (как механизм отслеживания текущего состояния информационного хранилища) и механизм ограничений на пользовательские типы данных (который иногда называется механизмом поддержки доменной структуры).

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

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

Французова Г.Н.26 Достоинства: Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях. Недостатки: Очень большая загрузка сервера. В начало Данная модель сервера является активной, потому что не только клиент, но и сам сервер используют механизм триггеров.

Французова Г.Н.27 Функции активного сервера: Осуществляет мониторинг событий, связанных с описанными триггерами; Осуществляет мониторинг событий, связанных с описанными триггерами; Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий; Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий; Обеспечивает исполнение внутренней программы каждого триггера; Обеспечивает исполнение внутренней программы каждого триггера; Запускает хранимые процедуры по запросам пользователей; Запускает хранимые процедуры по запросам пользователей; Запускает хранимые процедуры из триггеров; Запускает хранимые процедуры из триггеров; Возвращает требуемые данные клиенту; Возвращает требуемые данные клиенту; Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД. Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД. В начало

Французова Г.Н.28 Для разгрузки сервера была предложена 3-уровневая модель сервера: В начало Эта модель является расширением двухуровневой модели, т.е. вводится дополнительный промежуточный уровень между клиентом и сервером. В этой модели компоненты приложения делятся между тремя исполнителями: клиентом, сервером приложений и сервером БД.

Французова Г.Н.29 3-уровневая модель сервера Клиент - обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы. Серверы приложений - составляют новый, промежуточный уровень архитектуры. (Они спроектированы как исполнение общих не загружаемых функций для клиентов, поддерживают функции клиентов, поддерживают сетевую доменную операционную среду, хранят и исполняют общие правила бизнес логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов) Серверы БД этой модели занимаются исключительно функциями СУБД, функции создания резервных копий БД и восстановления БД после сбоев, управление выполнением транзакций и поддержки устаревших (унаследованных) приложений. В начало

Французова Г.Н.30 Достоинства 3 –уровневого сервера: Обладает большей гибкостью, чем двухуровневая модель. В начало

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

Французова Г.Н.32 Многопотоковая односерверная архитектура. Вышеперечисленные недостатки устраняются в модели (архитектуре) "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (tread), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной. В начало

Французова Г.Н.33 Многопотоковая односерверная архитектура. В начало Достоинства: уменьшается нагрузка на ОС, возникающая при работе большого числа пользователей. Недостатки: сервер может выполняться только на одном процессоре, возникает ограничение на применение СУБД для мультипроцессорных платформ. Например, если компьютер имеет 4 процессора, то СУБД с одним сервером использует только один из них, не загружая оставшиеся 3. В некоторых системах эта проблема решается вводом промежуточного диспетчера - архитектура виртуального сервера.

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

Французова Г.Н.35 Архитектура виртуального сервера. В начало Недостатки: невозможно направить запрос от конкретного клиента к конкретному серверу. серверы становятся равноправными, т.е. нет возможности устанавливать приоритеты для обслуживания запросов.

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

Французова Г.Н.37 Многопотоковая мультисерверная архитектура. В начало

Французова Г.Н Типы параллелизма. В начало Горизонтальный параллелизм Вертикальный параллелизм Гибридный параллелизм Хранимая в БД информация распределяется по нескольким физическим устройствам хранения - нескольким дискам

Французова Г.Н.39 Горизонтальный параллелизм Возникает, когда хранимая в БД информация распределяется по нескольким физическим устройствам хранения - нескольким дискам. При этом информация из одного отношения разбивается на части по горизонтали. Этот вид параллелизма иногда называют распараллеливанием или сегментацией данных. Параллельность здесь достигается путем выполнения одинаковых операций (например, фильтрации). Результат выполнения целого запроса складывается из результатов выполнения отдельных операций. Достоинства: Сокращается время выполнения запроса. В начало

Французова Г.Н.40 Вертикальный параллелизм Достигается конвейерным выполнением операций, составляющих запрос пользователя. Этот подход требует серьезного усложнения в модели выполнения реляционных операций ядром СУБД. Достоинства: Сокращается время выполнения запроса. В начало

Французова Г.Н.41 Выполнение запроса при вертикальном параллелизме. В начало

Французова Г.Н.42 Гибридный параллелизм. Эти методы позволяют существенно сократить время выполнения сложных запросов над очень большими объемами данных. В начало Выполнение запроса при гибридном параллелизме.

Французова Г.Н Модели транзакций. В начало Транзакцией называется последовательность операций, производимых над БД и переводящих БД из одного непротиворечивого (согласованного) состояния в другое непротиворечивое состояние. Транзакция рассматривается как некоторое неделимое действие над БД, осмысленное с точки зрения пользователя. В то же время это логическая единица работы системы. Разработчик БД определяет семантику совокупности операций на БД, которая моделирует с точки зрения разработчика некоторую одну неразрывную работу (это и составляет транзакцию).

Французова Г.Н.44 Например: Принимается заказ в фирме на изготовление компьютера. Компьютер состоит из комплектующих, которые сразу резервируются за данным заказом в момент его оформления. Транзакцией будет вся последовательность операций, включающая следующие: 1. ввод нового заказа со всеми реквизитами заказчика; 2. изменения состояния для всех выбранных комплектующих на складе на "занято" с привязкой к определенному заказу; 3. подсчет стоимости заказа с формированием платежного документа (например, выставляемого счета к оплате); 4. включение нового заказа в производство. С точки зрения работника - это единая последовательность операций. Если она будет прервана, то БД потеряет свое целостное состояние. В начало

Французова Г.Н Свойства транзакций. Способы их завершения. Свойства транзакций: структура транзакции параллельность внутри транзакции продолжительность Типы транзакций: Плоские (классические) Цепочечные. Вложенные. В начало

Французова Г.Н.46 В начало Иногда данные транзакции называются ACID транзакциями. ACID – Atomicity, Consistency, Isolation, Durability.

Французова Г.Н.47 Плоские транзакции характеризуются 4 классическими свойствами: Атомарность - выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе Согласованность - гарантирует, что по мере выполнения транзакций, данные переходят из одного согласованного состояния в другое, т.е. транзакция не разрушает взаимной согласованности данных. Изолированность - означает, что конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. Долговечность - если транзакция завершена успешно, то те изменения, в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах. В начало

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

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

Французова Г.Н.50 В стандарте ANSI/ISO SQL транзакция завершается одним из 4-х возможных путей: Оператор COMMIT означает успешное завершение транзакции, его использование делает постоянными изменения, внесенные в БД в рамках текущей транзакции. Оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в БД в рамках этой транзакции. Новая транзакция начинается непосредственно после использования ROLLBACK. Успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT). Ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

Французова Г.Н.51 В начало В стандарте ANSI/ISO SQL транзакция завершается одним из 4-х возможных путей:

Французова Г.Н Журнал транзакций. Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая журналом транзакций. Он предназначен для обеспечения надежного хранения данных в БД, а также для возможности восстановления согласованного состояния БД после любого рода аппаратных и программных сбоев. Для выполнения восстановления необходима некоторая дополнительная информация, которая поддерживается в виде журнала изменений в БД. Журнализация и восстановление тесно связаны с понятием транзакции. В начало

Французова Г.Н.53 Общие принципы восстановления: Результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД. Результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии БД. Это означает, что восстанавливается последнее по времени согласованное состояние БД. В начало

Французова Г.Н.54 Индивидуальный откат транзакции –оператор ROLLBACK; –аварийное завершение программы; –принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. Для выхода из тупика данная транзакция может быть выбрана в качестве "жертвы" и принудительно прекращено ее выполнение ядром СУБД.

Французова Г.Н.55 Восстановление после внезапной потери содержимого ОП (мягкий сбой) –при аварийном выключении электропитания; –при возникновении неустранимого сбоя процессора. Такая ситуация характеризуется потерей той части БД, которая к моменту сбоя содержалась в буферах ОП.

Французова Г.Н.56 Восстановление после поломки основного внешнего носителя БД (жесткий сбой). Происходит очень редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже в этом случае. Основой восстановления является архивная копия и журнал изменений БД.

Французова Г.Н.57 Два варианта ведения журнальной информации: Для каждой транзакции поддерживается отдельный локальный журнал изменений БД этой транзакцией (локальные журналы). Они используются для индивидуальных откатов транзакций и могут поддерживаться в виртуальной памяти. Общий журнал изменений БД, используемый для восстановления состояния БД после мягких и жестких сбоев. В начало

Французова Г.Н.58 Достоинства: Позволяет выполнять индивидуальные откаты транзакций. Недостатки: Приводит к дублированию информации в локальном и общем журналах, => лучше использовать второй вариант. В начало

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

Французова Г.Н.60 Имеются два альтернативных варианта журнала транзакций: Протокол с отложенными обновлениями. Протокол с немедленными обновлениями. В начало

Французова Г.Н.61 Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций: Когда транзакция (T1) начинается, в протокол заносится запись 1. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи заносится новое значение: 2, где ID_RECORD - уникальный номер записи. Если все действия, из которых состоит транзакция T1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится: 3. После того как транзакция фиксирована, записи протокола, относящиеся к T1, используются для внесения соответствующих изменений в БД. В начало

Французова Г.Н.62 Если происходит сбой, то СУБД просматривает протокол и выясняет какие транзакции необходимо переделать. Транзакцию T1 необходимо переделать, если протокол содержит обе записи (1, 3). БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется системная процедура REDO(), которая заменяет все значения элементов данных на новые, просматривая протокол. Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

Французова Г.Н.63 Журнал транзакций: В начало

Французова Г.Н.64 Существует альтернативный механизм с немедленным выполнением предусмотренных изменений сразу в БД, а в протокол заносятся не только новые, но все и все старые значения изменяемых атрибутов. Строка в журнале транзакций выглядит так:. Если транзакция успешно завершена, то все изменения уже внесены в БД, а при откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции. В начало

Французова Г.Н.65 Для восстановления при сбое используется следующий механизм: Если транзакция содержит команду начала транзакции, но не содержит команды фиксации (COMMIT), то выполняется последовательность действий, как при откате транзакции (т.е. восстанавливаются старые значения). Если сбой произошел после выполнения последней команды изменения БД, но до команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит, т.е. работа происходит только на уровне протокола. Изменения заносятся как в журнал транзакций, так и в БД не сразу, а сначала буферируются. В начало

Французова Г.Н.66 Защита на уровне пользователя Применяется в тех случаях, когда с одной БД работают несколько пользователей или групп пользователей, имеющих разные права доступа к объектам БД. Использовать защиту на уровне пользователя можно на отдельном компьютере и при коллективной работе - в составе локальной сети. Этот способ защиты подобен способам разграничения доступа в локальных сетях. Для организации защиты на уровне пользователя в системе Access создаются рабочие группы (РГ). Каждая РГ определяет единую технологию работы совокупности пользователей. Информация о каждой рабочей группе хранится в соответствующем файле РГ (system.mdw), который автоматически создается при установке системы. Информация о размещении этого файла хранится в системном реестре. Для управления РГ в Access 2002 имеется программа "Администратор рабочих групп" (АРГ), запустить которую можно из подменю Сервис->Защита. В начало

Французова Г.Н.67 Кроме сведений о системе защиты на уровне пользователя в файле РГ хранятся параметры системы Access: параметры отображения информации системой Access (строки состояния, окна запуска, панели инструментов, скрытых и системных объектов). параметры средств разработки запросов, экранных форм, отчетов, модулей, комбинации клавиш, параметры режима правки и поиска информации, параметры открытия БД (общий или монопольный). В начало

Французова Г.Н.68 Файл РГ описывает группы пользователей и отдельных пользователей, входящих в эту РГ. Он содержит учетные записи групп пользователей и отдельных пользователей. По каждой учетной записи система Access хранит права доступа к объектам БД. По умолчанию, в каждую рабочую группу входит 2 группы пользователей: администраторы (имя группы Admins) обычные пользователи (имя группы Users) В начало

Французова Г.Н.69 Причем в группу Admins первоначально включен один администратор под именем Admin. При создании групп указывается имя (идентификатор) группы и код, представляющий собой последовательность от 4 до 20 символов. При регистрации (создании) пользователей в системе защиты им присваивается имя, код и необязательный пароль. Каждому из пользователей, независимо от принадлежности к группе, можно присвоить пароль. Этот пароль, в отличие от пароля БД, называется паролем учетной записи и хранится в учетной записи в файле РГ. Каждой из групп присваиваются определенные права на объекты базы данных. Члены группы Admins имеют максимальные права. В начало

Французова Г.Н.70 Наличия двух функциональных групп пользователей в рабочей группе, как правило, достаточно для организации нормальной работы коллектива пользователей. При необходимости можно создать дополнительные группы пользователей. Один пользователь может входить в состав нескольких групп. При подключении пользователя, зарегистрированного в нескольких группах, действуют минимальные из установленных в разных группах ограничения на объекты БД. В начало

Французова Г.Н.71 При создании рабочих групп и регистрации пользователей действуют следующие ограничения: Группы Admins и Users удалить невозможно; В группе Admins должен быть хотя бы один пользователь. Первоначально таким пользователем является пользователь Admin (администратор). Удалить пользователя Admin из этой группы можно после включения в нее еще одного пользователя. Все регистрируемые пользователи автоматически становятся членами группы Users. Удалить их из этой группы нельзя. Удалить пользователя Admin из РГ нельзя (из группы Admins его можно удалить, а из группы Users - нет). Создаваемые группы не могут быть вложены в другие группы, другими словами, нельзя создавать иерархию групп пользователей. В системе защиты могут быть пустые группы, но не может быть пользователей, не входящих ни в одну из групп (они обязательно входят в группу Users). В начало

Французова Г.Н.72 Структура рабочей группы. В начало

Французова Г.Н.73 Основное назначение системы защиты на уровне пользователя состоит в контроле прав доступа к объектам БД. Для этого нужно установить защиту БД с помощью мастера защиты. В начало

Французова Г.Н Существующие в Access типы прав доступа. Права подключающегося пользователя делятся на явные и неявные. Явные права имеются в случае, если они определены для учетной записи пользователя. Неявные права - это права той группы, в которую входит пользователь. Как уже было сказано: пользователь, имеющий явные и неявные права в одной или нескольких группах, пользуется правами с минимальными ограничениями из всей совокупности прав. В начало

Французова Г.Н.75 Типы прав доступа: Права доступа Разрешенные действия ОбъектыОткрытие/запуск Открытие БД, формы или отчета, запуск макросаБД, формы, отчеты, макросы Монопольный доступ Открытие БД для монопольного доступа БДЧтение макета Просмотр объектов в режиме конструктора Таблицы, запросы, формы, отчеты, макросы, модули Изменение макета Просмотр и изменение макета объектов или удаление объектов Таблицы, запросы, формы, отчеты, макросы, модули АдминистратораДля баз данных: установка пароля, репликация и изменение параметров запуска. Для объектов БД: полные права на объекты и данные, в том числе предоставление прав доступаБД, таблицы, запросы, формы, отчеты, макросы, модули Чтение данных Просмотр данных Таблицы, запросы Обновление данных Просмотр и изменение данных без их вставки и удаления Таблицы, запросы Вставка данных Просмотр и вставка данных без их изменения Таблицы, запросы Удаление данных Просмотр и удаление данных без их изменения и вставки Таблицы, запросы В начало

Французова Г.Н.76 Изменить права других пользователей на объекты некоторой БД могут следующие пользователи: Члены группы Admins; Владелец объекта; Пользователь, получивший на объект права администратора. В начало

Французова Г.Н.77 Изменить свои собственные права в сторону их расширения могут пользователи, которые являются членами группы Admins и владельцы объекта. Владелец объекта - это пользователь, создавший объект. Владельца объекта можно изменить путем передачи права владельца другому пользователю. Правами изменения владельца обладают пользователи, имеющие право изменить права доступа к объекту или создать объект (Сервис->Защита- >Разрешения). Создать объект в новой БД, можно с помощью операции импорта/экспорта или копирования его в БД. Для создания и защиты на уровне пользователя копии всей БД можно воспользоваться мастером защиты (Сервис->Защита- >Мастер). Владельцем защищенной БД может стать другой пользователь => здесь происходит изменение владельца БД, но у исходной БД остается свой владелец. В начало

Французова Г.Н.78 Установка защиты на уровне пользователя - это процесс, сложнее парольной защиты. Она состоит из следующих операций: Создание файлов РГ; Создание учетных записей пользователей и групп; Включение пользователей в группы; Активизация процедуры подключения к Access; Защита каждой из БД с помощью "мастера защиты". В начало

Французова Г.Н Манипуляции с файлами РГ. Выполняются с помощью программы "Администратор рабочих групп" (АРГ). Назначение - привязка Access к нужному файлу РГ. (Сервис->Защита). Функции АРГ: создание файла РГ; связь с произвольным файлом РГ; выход из программы. В начало

Французова Г.Н.80 Система защиты на уровне пользователя действует в двух основных режимах: С требованием подключения пользователя к системе; Без требования подключения пользователя к системе; Для активизации окна входа в систему необходимо: Запустить Access; Сервис->Защита->Пользователи и группы. Откроется окно "Пользователи и группы". На вкладке "Пользователи" проверить, что в поле имя выбрана учетная запись Admin. В начало

Французова Г.Н.81 В начало

Французова Г.Н.82 На вкладке изменение пароля оставить пустым поле "текущий пароль", а в поле "новый пароль" ввести его (от 1 до 14 символов, без пробелов). Подтверждение пароля. В начало

Французова Г.Н.83 В начало

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

Французова Г.Н.85 Определение прав пользователей и групп. Вызов окна управления правами доступа: Сервис- >Защита->Разрешение. При управлении правами доступа учитывается следующее: возможности манипуляций зависят от полномочий текущего пользователя, указанного в нижней части окна. Для выбора нескольких объектов в области "имя объекта" используется клавиша Ctrl. Для смены владельца некоторого объекта БД - вкладка "Смена владельца". В начало

Французова Г.Н Шифрование БД. Средства шифрования в Access позволяют копировать файл БД таким образом, что он становится недоступным для чтения из других программ, в которых известен формат БД Access. В начало

Французова Г.Н.87 Шифровать не защищенную паролем БД смысла нет, т.е. шифрация в Access применяется, чтобы изменить до неузнаваемости стандартный формат файла БД (Запустить Access->Сервис->Защита- >Шифровать/дешифровать->указать имя БД, которую требуется зашифровать->указать имя, диск и папку для целевой БД->ОК). Замечания: при низком качестве гибких дисков надо быть осторожным во время шифрования БД, т.к. если зашифрованной БД вы дали то же самое имя, она "затирает" исходную, и если возникла какая-либо ошибка при шифровании, то можно потерять БД. Вывод: при шифровании необходимо дать другое имя БД, проверить ее, а исходную удалить. В начало

Французова Г.Н.88 Скрытие объектов БД. Механизм скрытия применяется в случаях, когда пользователь работает с БД через стандартный интерфейс (окно БД) и желательно предохранить БД от случайного доступа к ее объектам. Для этого необходимо: Выделить объект->правая кнопка мыши- >скрытый; Переименовать объект таким образом, чтобы его имя начиналось с Usys. В начало

Французова Г.Н.89 Скрытые объекты БД пользователь видит в окне БД если в текущих установках параметров Access задано отображение скрытых объектов в окне БД. Чтобы скрытые объекты сделать не скрытыми, необходимо их сначала сделать видимыми (Сервис->Параметры->Вид- >Отображение на экране->Скрытые объекты). Поле этого работать со свойствами этого объекта. Кроме пользовательских объектов в каждой БД есть системные (служебные) объекты. Их имена начинаются с символов Msys. Атрибут этих объектов - системный. Чтобы их увидеть: Сервис- >Параметры->Вид->Отображение на экране->Системные объекты. Под обслуживанием БД понимают: копирование, восстановление, сжатие. В начало

Французова Г.Н Репликация баз данных. Репликацией называются создания специальных копий (реплик) БД Access, с которыми пользователи могут одновременно работать на разных рабочих станциях. Отличие репликации от обычного копирования файлов ОС в том, что для каждой реплики возможна синхронизация с остальными репликами. По одной БД можно создать набор реплик, где различают основную реплику и дополнительные реплики. Основная реплика отличается от обычной (дополнительной) тем, что в ней можно изменять структуру БД. В начало

Французова Г.Н.91 Вывод: в любой момент времени в наборе реплик одна из них является основной, остальные - дополнительными. Дополнительные реплики можно создавать из основной и дополнительных реплик. Создание новой реплики - это преобразование файла исходной БД в новый файл. Исходную БД будем называть реплицируемой. Для безопасности, перед проведением преобразования целесообразно создать резервную копию исходной БД В начало

Французова Г.Н.92 После репликации файл исходной БД пропадает. В ходе репликации в файл исходной БД добавляются специальные таблицы, поля, свойства, исходная БД становится основной репликой в наборе реплик. Добавленные системные таблицы в результате репликации изменять пользователю не рекомендуется. Они могут быть видимыми или нет (Вид->Системные объекты->…). Реплицироваться могут все объекты БД (таблицы, формы, запросы, отчеты и т.д.). В каждой дополнительной реплике, кроме реплицируемых объектов, могут содержаться свои локальные объекты, структура и содержание которых не передаются в другие реплики. Признак реплицируемости объекта БД устанавливается Access путем изменения свойств объектов. Изменение структуры реплицируемых объектов, а также содержимого БД основной реплики по специальным командам синхронизации передается во все дополнительные реплики. В начало

Французова Г.Н.93 Образование основной реплики. В начало

Французова Г.Н.94 Репликация БД преследует следующие цели: Распространение приложений, т.е. все изменения существующих объектов и добавление новых объектов БД выполняются в основной реплике. В сеансе синхронизации между репликами последние изменения распространяются на объекты дополнительных реплик набора. Доступ к данным. Пользователи, работающие не переносных компьютерах и имеющие реплики основной БД, после подключения к сети, могут провести синхронизацию внесенных ими на переносных компьютерах исправлений с изменениями общей реплики. Резервное копирование. Поместив реплику на другом компьютере, можно организовать резервное копирование данных основной базы, т.е. репликация разрешает вносить изменения даже во время синхронизации и создания резервной копии. Перераспределение нагрузки и распараллеливание работы пользователей. Одновременная работа группы пользователей с репликами одной БД позволяет распараллелить работу и ускорить решение некоторых задач при работе с ней (например, ввод большого числа исходных данных). В начало

Французова Г.Н.95 Синхронизацией называют процесс обновления двух компонентов в наборе реплик, при котором производится обмен обновленными записями и объектами из каждого компонента. В начало

Французова Г.Н.96 Синхронизацию предпочтительно выполнять через основную реплику. Архивирование БД лучше свести к архивированию БД основной реплики. Вывод: управлять набором реплицируемых объектов и их структурой нужно из основной реплики. Создание реплики: Сервис->Репликация. Создание дополнительной реплики: Сервис- >Репликация->Создать дополнительную реплику. Синхронизация реплик: Сервис->Репликация- >Синхронизация. Устранение конфликтов при синхронизации: Сервис->Репликация->Устранение конфликтов. В начало

Французова Г.Н.97 В начало