Создание схемы.

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

Оператор CREATE SCHEMA

Схемы создаются с помощью оператора CREATE SCHEMA. Синтаксис этого оператора следующий.

CREATE SCHEMA [ ИМЯ_СХЕМЫ ] ( ИМЯ_ПОЛЬЗОВАТЕЛЯ ]

[ DEFAULT CHARACTER SET НАБОР_СИМВОЛОВ ]

[ PATH ИМЯ_СХЕМЫ [ , ИМЯ_СХЕМЫ ] ]

[ СПИСОК_ЭЛЕМЕНТОВ_СХЕМЫ ]

Вот пример:

CREATE SCHEMA USER1 CREATE TABLE TBL1

(Столбец1 ТИП_ДАННЫХ [NOT NULL], 

Столбец2 ТИП_ДАННЫХ [NOT NULL]...) 

CREATE TABLE TBL2

(Столбец1 ТИП_ДАННЫХ [NOT NULL],

Столбец2 ТИП_ДАННЫХ [NOT NULL]...) 

GRANT SELECT ON TBLl TO USER2 

GRANT SELECT ON TBL2 TO USER2 

[ Другие команды DDL ... ]

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

Удаление схем. Схема может быть удалена из базы данных с помощью оператора

DROP SCHEMA ИМЯ__СХЕМЫ { RESTRICT | CASCADE }

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

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

Привилегии

Привилегии — это уровни полномочий, предоставленных пользователю при доступе к самой базе данных и ее объектам, при манипуляции данными и при выполнении в рамках базы данных различных административных функций. Привилегии предоставляются посредством команды GRANT и отменяются посредством команды REVOKE.

• Привилегии доступа к системе.

• Привилегии доступа к данным.

 

  Привилегии доступа к системе

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

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

Некоторых из привилегий доступа к системе, которые предлагаются в рамках Sybase.

CREATE DATABASE 

CREATE DEFAULT 

CREATE PROCEDURE 

CREATE RULE 

DUMP DATABASE 

DUMP TRANSACTION 

EXECUTE

Привилегии доступа к объектам

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

Стандарт ANSI определяет следующие привилегии доступа к объектам.

USAGE. Разрешает использование заданной области.

SELECT. Разрешает доступ к заданной таблице.

INSERT (имя_столбца). Позволяет разместить данные в указанном столбце заданной таблицы.

INSERT. Позволяет поместить данные во все столбцы заданной таблицы.

UPDATE {имя_столбца). Позволяет изменить данные в указанном столбце заданной таблицы.

UPDATE. Позволяет изменить данные во всех столбцах заданной таблицы.

REFERENCES (имя_столбца). Позволяет сослаться в условиях целостности на указанный столбецзаданной таблицы; требуется для всех условий целостности.

REFERENCES, позволяет сослаться в условиях целостности на любой столбец заданной таблицы.

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

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

Обычно право использовать команды GRANT и REVOKE имеет администратор базы данных, но если есть администратор по безопасности, то он тоже может иметь право использовать эти команды. Конкретные инструкции по поводу того, кому и какие именно привилегии следует назначить или отменить, должны исходить от руководства и желательно в письменном виде.

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

Команда GRANT

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

Синтаксис оператора следующий.

GRANT Привилегия1 [, Привилегия2 ] [ ON Объект ]

ТО Имя_Пользователя [ WITH GRANT OPTION | ADMIN OPTION ]

Одну привилегию пользователю можно предоставить следующим образом.

GRANT SELECT ON EMPLOYEE_TBL TO USERI;

Право предоставлено. 

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

GRANT SELECT, INSERT ON EMPLOYEE_TBL TO USER1;

Право предоставлено.

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

Нескольким пользователям привилегии предоставляются следующим образом.

GRANT SELECT, INSERT ON EMPLOYEE_TBL TO USER1, USER2;

Grant succeeded.

  Опция GRANT OPTION команды GRANT является достаточно мощной. Если владелец объекта предоставляет привилегии относительно объекта другому пользователю и использует при этом опцию GRANT OPTION, это значит, что последний получает право предоставлять другим привилегии использования объекта, не являясь при этом владельцем объекта. Вот пример использования опции:

GRANT SELECT ON EMPLOYEE_TBL TO USER1 WITH GRANT OPTION;

Право предоставлено.

  ADMIN OPTION

Опция ADMIN OPTION команды GRANT подобна опции GRANT OPTION в том, что получающий привилегии пользователь наследует также и право предоставлять эти привилегии другим пользователям. Но GRANT OPTION используется для привилегий на уровне объектов, a ADMIN OPTION — на уровне системы.

Команда REVOKE отменяет привилегии, ранее предоставленные пользователю базы данных. Команда REVOKE имеет две опции — RESTRICT и CASCADE. При использовании опции RESTRICT команда REVOKE будет успешно завершена только в том случае, когда отсутствуют другие пользователи с оставшимися привилегиями, явно указанными оператором REVOKE. С помощью опции CASCADE отменяются и все оставшиеся привилегии других пользователей. Другими словами, если владелец объекта наделил пользователя USERI привилегиями с опцией GRANT OPTION, а пользователь USER1 наделил привилегиями пользователя USER2, то при отмене владельцем привилегий пользователя USER1 с опцией CASCADE будут автоматически отменены и соответствующие привилегии пользователя USER2

Синтаксис оператора для отмены привилегий следующий.

REVOKE Привилегия! [, Привилегия2 ] [ GRANT OPTION FOR ] ON Объект 

    FROM Имя_Пользователя { RESTRICT | CASCADE }

Вот пример использования подобного оператора.

REVOKE INSERT ON EMPLOYEE_TBL FROM USERI;

Право отменено.

  Контроль за привилегиями с помощью распределения ролей

Роль — это создаваемый объект базы данных, содержащий нечто подобное группе привилегий Использование ролей направлено на сокращение усилий по обеспечению надежности хранения данных путем отказа от явного предоставления привилегий пользователям Управлять группами привилегий с помощью ролей оказывается проще Привилегии в рамках роли можно изменить, и такие изменения будут прозрачны для пользователя

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

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

Создать роль можно с помощью оператора CREATE ROLE. 

CREATE ROLE Имя_роли;

Предоставление привилегий ролям аналогично предоставлению привилегий пользователям.

CREATE ROLE RECORDS_CLERK;

Роль создана.

GRANT SELECT, INSERT, UPDATE, DELETE ON EMPLOYEE_PAY TO

       RECORDS_CLERK;

Право предоставлено.

GRANT RECORDS_CLERK TO USER1;

Право предоставлено.

Роль удаляется с помощью оператора DROP ROLE. 

DROP ROLE Имя_роли;

Вот пример:

DROP ROLE RECORDS_CLERK;

Роль удалена.

Роль может быть назначена пользователю в рамках его сеанса доступа к базе данных с помощью оператора SET ROLE.

  Системный каталог

Системный каталог — это набор таблиц и представлений, содержащих важную информацию о базе данных. Системный каталог имеется в любой базе данных. Информация в системном каталоге определяет структуру всей базы данных. Например, в системном каталоге хранятся операторы DDL (Data Definition Language — Язык определения данных) для всех таблиц базы данных

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

Администрирование баз данных

12.1. Определение функций администрирования баз данных и их проведение

Управление данными, причем не только в рамках СУБД, отдельная сложная задача, для обеспечения ее выполнения разрабатываются функции администрирования баз данных (database administration function).

Лицо, ответственное за управление централизованной и распределенной базой данных, называется администратором баз данных (DBA, database administrator).

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

либо штатной,

либо консультирующей.

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

Штатный администратор DBA отвечает за

планирование, определяет, реализует и проводит в жизнь

политику,

стандарты

и процедуры,

необходимые администратору.

Политики (policies) — основные руководящие инструкции или действия, соответствующие целям DBA.

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

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

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

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

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

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

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

DBA и

DA (data administrator) - администратор данных.

DA, которого еще называют менеджером информационных ресурсов (information resource manager, IRM), обычно напрямую подотчетен высшему руководству и имеет более высокие полномочия и степень ответственности, чем DBA, хотя их роли частично перекрываются.

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

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

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

Администратор данных (DA)	Администратор базы данных (DBA)
Стратегическое планирование Определение долгосрочных целей Выработка политики стандартов	Управление и контроль Исполнение планов для достижения целей Проведение в жизнь политик и процедур Проведение в жизнь стандартов программирования
Широкие масштабы деятельности Долгосрочные перспективы	Узкие рамки деятельности Краткосрочные перспективы (основное внимание ежедневным операциям)
Организационная направленность	Техническая направленность
Независимость от СУБД	Привязка к СУБД

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

"разделяемость" (возможность совместного использования) данных и готовность их к использованию;

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

безопасность и конфиденциальность данных;

рамки и характер использования информации.

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

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

Посредничество во взаимодействии между двумя наиболее важными ценностями предприятия (люди и информация) определяет место DBA в динамической среде.

12.2. Требования к профессиональной подготовке DBA

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

организационные и

технические.

Подобная классификация представлена в табл.12.1.

табл.12.1.

Организационные

Технические

Широкие познания в области бизнеса Умение координировать деятельность Умение разрешать конфликты Умение общаться (устно и письменно) Умение вести переговоры Опыт работы: 2—5 лет по обработке информации на большом предприятии

Широкие познания в области обработки данных Знания в области жизненного цикла разработки систем Аналитические навыки Знание структурированных методик: Схемы информационных потоков Структурные диаграммы Языки программирования Навыки моделирования и проектирования баз данных: Концептуального Логического Физического Оперативные навыки: реализация баз данных, управление словарем базы данных, безопасность и т. д.

Функции администратора.

Стало общепринятой практикой определять функции DBA, разделяя деятельность DBA в соответствии с фазами жизненного цикла БД (database life cycle, DBLC) Стало общепринятой практикой определять функции DBA, разделяя деятельность DBA в соответствии с фазами жизненного цикла БД (database life cycle, DBLC)

Функции администратора на стадии разработки БД

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

Проектирование и моделирование базы данных. Какую методологию нужно использовать при проектировании БД (нормализация, объектно-ориентированные технологии и т. д.)? Какие инструментальные средства необходимо использовать (CASE-средства, словари данных, ER-диаграммы и т. д.)?

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

Разработка, кодирование и тестирование прикладных программ БД. DBA должен определить стандарты кодирования прикладных программ, документации и тестирования. Стандарты и процедуры, утвержденные DBA, передаются прикладным программистам, a DBA должен следить за использованием этих стандартов.

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

Функции администратора на стадии эксплуатации БД.

Обеспечение безопасности и целостности данных.

Резервное копирование и восстановление баз данных.

Обслуживание базы данных

Обучение пользователей.

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

12.3. ФУНКЦИИ ОБЕСПЕЧЕНЯ  БЕЗОПАСНОСТИ И ЦЕЛОСТНОСТИ ДАННЫХ.

 DBA должен определить политики, управляющие безопасностью и целостностью. Под безопасностью подразумевается, как сохранность данных, так и их конфиденциальность. Обеспечение сохранность и конфиденциальности данных в БД — функция руководства, обладающего соответствующими полномочиями. Полномочное руководство определяет политику, стандарты безопасности процедуры защиты, гарантирующие безопасность и конфиденциальность информации в БД. BDA участвует в их определении и реализует. Использование интернет-интерфейсов к БД требует чтобы DBA должны совместно с экспертами по безопасности Интернета

Процедуры обеспечения безопасности  включают в себя (но не ограничиваются только этим)

управление доступом пользователей,

 определение представлений,

 управление доступом к утилитам СУБД

 наблюдение за использованием СУБД.

Управление доступом пользователей.

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

определение каждого пользователя в базе данных;

назначение пароля каждому пользователю;

определение групп пользователей;

назначение привилегий доступа;

контроль физического доступа.

Определение каждого пользователя в базе данных  достигается  на двух уровнях: на уровне операционной системы  и на уровне СУБД.  На уровне операционной системы DBA может потребовать создания регистрационного имени пользователя (logon user ID), которое разрешает пользователю регистрироваться в системе. На уровне СУБД DBA может либо создать другое регистрационное имя пользователя, либо использовать для доступа к СУБД то же самое имя.

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

Определение групп пользователей обеспечивает сортировку пользователей  по различным группам (ролям) в соответствии с общими требованиями по доступу к БД облегчает работу DBA по контролю и управлению привилегиями доступа отдельных пользователей.

При назначение привилегий доступа DBA определяет права доступа,  для каждой группы пользователей. Например, могут быть ограничены только чтением, авторизованный доступ может включать привилегии READ (чтение), WRITE (запись) и DELETE (удаление). Привилегии доступа в реляционных базах данных назначаются с помощью команд SQL GRANT и REVOKE.

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

 

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

 

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

Наблюдение за использованием СУБД подразумевает ведение документации доступа пользователей к БД. Большинство пакетов  СУБД имеют средства, позволяющие создавать контрольный журнал (audit log), в который автоматически записывается краткое описание операций с БД, выполняемых всеми пользователями. Такие сведения позволяют DBA определять нарушения прав доступа. Контрольный журнал можно настроить на запись всех попыток доступа к базе данных или только неудачных попыток

12.4. ФУНКЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ  ДАННЫХ И ВОССТАНОВЛЕНИЯ

 

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

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

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

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

 

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

Процедуры восстановления и копирования баз данных позволяют восстанавливать разрушенную базу данных на основании ранее созданной копии.

Обычно для обеспечения восстановления БД создается специальный план Управление чрезвычайными ситуациями (disaster management) включает в себя все действия DBA, направленные на обеспечение готовности данных при физических катастрофах или нарушениях целостности базы данных. включает в себя разработку и тестирование процедур, выполняемых  в случае непредвиденных обстоятельств.  Кроме процедур копирования и восстановления план по управлению чрезвычайными мероприятиями должен включать дополнительные мероприятия по физической защите данных и ограничению доступа пользователей. План восстановления данных в случае непредвиденных обстоятельств должен быть тщательно протестирован и оценен, его также необходимо периодически проверять на практике. Так называемые "пожарные учения" не стоит рассматривать как некое унижение, и высшее руководство должно оказывать всяческую поддержку таким мероприятиям.

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

Периодическое Копирование данных

Восстановление.

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

полное,

инкрементальное и

параллельное.

При полном резервном копировании (full backup), которое также называется дампом базы данных, создается полная копия всей БД.

Инкрементальное копирование (incremental backup) создает резервную копию всех данных, начиная с даты последнего резервного копирования.

Параллельное резервное копирование (concurrent backup) выполняется в процессе работы пользователей с базой данных.)

Созданные резервные копии  должны однозначно маркироваться с помощью детального описания и указания даты их создания, что позволяет DBA обеспечить использование нужной копии при восстановлении БД. Должны быть подобранны средства физического храниения резервной копии. В качестве носителя резервной копии может использоваться оптический диск,  магнитная лента; место хранения и маркировка физических носителей резервных копий должны тщательно продумываться оператором, a DBA должен контролировать использование и местоположение носителей резервных копий. . Необходимо иметь несколько резервных копий с одинаковой датой создания, и каждая такая копия должна храниться в отдельном месте. Места хранения должны находиться как внутри предприятия, так и за его пределами (размещение различных резервных копий в одном месте, прежде всего, не соответствует требованию наличия нескольких резервных копий). Место хранения должно быть тщательно подготовлено и может представлять собой, например, огнеупорный, защищенный от землетрясений сейф, снабженный датчиками влажности и температуры. DBA должен разработать политику, позволяющую ответить на два вопроса:

1) Где хранится резервная копия?

1) Сколько времени должна храниться резервная копия?

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

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

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

Аналогично копированию может быть использовано

Полное восстановление БД из дампа;

Восстановление данных, с заданного периода времени с использованием инкркментной копии.

 

12.5. ФУНКЦИИ ОБСЛУЖИВАНИЯ БД

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

Одной из важных функций обслуживания является

Распределение и использование данных

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

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

Такая идеология распределения данных в настоящее время считается общепринятой и, вероятно, будет получать дальнейшее распространение по мере развития технологии баз данных. Такая структура устраивает конечных пользователей. Очевидно, что получение пользователями относительной самостоятельности при использовании данных может привести к более эффективному использованию информации в процессе принятия решений. И все же такая "демократия данных" имеет побочные эффекты. Разрешая конечным пользователям управлять своими наборами данных на микроуровне, мы можем нарушить связь между пользователями и администрацией. Работа DBA в этих условиях может стать достаточно сложной, и может возникнуть угроза эффективности работы DBA. Может вновь буйно расцвести дублирование данных без какого-либо контроля на уровне предприятия по обеспечению уникальности элементов данных. При этом конечные пользователи, не до конца понимающие природу и источник информации, могут неправильно использовать элементы данных.

Обучение пользователей. На предприятии должна быть принята полноценная программа обучения, а процедуры управления обучением должны быть точно определены. Цель — четко определить, кто должен выполнять, что и как. Каждый пользователь должен ознакомиться с видом и формой доступного обучения.