Правила принадлежности систем к реляционным
В 1985 г. Коддом были сформулированы 13 правил, которым обязаны соответствовать реляционные системы.
Фундаментальное. Любая система, которая рекламируется или представляется как реляционная СУБД, должна быть способна управлять базами данных исключительно с помощью реляционных функций.
Это означает, что в СУБД не должны применяться какие-либо нереляционные операции для определения данных и манипулирования ими.
Представление информации. Вся информация в РБД представляется в явном виде на логическом уровне и только одним способом – в виде значений в таблицах.
Согласно этому правилу, вся информация, даже метаданные в системном каталоге, должна храниться в виде отношений и управляться с помощью тех же функций, которые используются для работы с данными. Упоминание в этом правиле "логического уровня" означает, что такие физические конструкции, как индексы, не должны быть представлены в модели, и пользователь не обязан явно их упоминать в операциях выборки данных, даже если они существуют.
Гарантированный доступ. Для всех и каждого элемента данных (элементарного значения) реляционной базы данных должен быть гарантирован логический доступ на основе использования комбинации имени таблицы, значения первичного ключа и значения имени столбца.
Систематическая обработка NULL-значений. Неопределенные значения (задаваемые с помощью определителя NULL, т.е. значения, отличные от пустой символьной строки или строки пробельных символов, а также от нуля или любого другого числа) поддерживаются как способ систематического представления отсутствующей или неприемлемой информации, причем независимо от типа данных.
Динамический оперативный каталог, построенный по правилам реляционной модели. Описание базы данных должно быть представлено на логическом уровне таким же образом, как и обычные данные, что позволяет санкционированным пользователям применять для обращений к этому описанию тот же реляционный язык, что и при обращении к обычным данным.
Это правило указывает на то, что должен существовать только один язык, предназначенный для манипулирования как метаданными, так и обычными данными, причем в СУБД для организации хранения системной информации должна использоваться только одна логическая структура — переменная отношения.
Исчерпывающий подъязык данных. Реляционная система баз данных может поддерживать несколько языков и различные режимы работы. Однако должен существовать по крайней мере один язык, операторы которого позволяли бы выражать все следующие конструкции:
1) определение данных;
2) определение представлений;
3) операторы манипулирования данными (доступные как в интерактивном режиме, так и с помощью программ);
4) ограничения целостности;
5) авторизация пользователей;
6) поэтапная организация транзакций (запуск, фиксация и откат).
Обновление представления. Все представления, которые являются теоретически обновляемыми, должны быть обновляемыми и в данной системе.
В действительности ни одна существующая система не поддерживает это требование, поскольку все еще не сформулированы условия определения всех теоретически обновляемых представлений.
Высокоуровневые операции вставки, обновления и удаления. Способность обрабатывать базовые или производные переменные отношения (т.е. представления) как единый операнд должна относиться не только к процедурам выборки данных, но и к операциям вставки, обновления и удаления данных.
Физическая независимость от данных. Прикладные программы должны оставаться логически неизменными при внесении любых изменений в способы хранения данных или методы доступа к ним.
Логическая независимость от данных. Прикладные программы должны оставаться логически неизменными при внесении в базовые таблицы любых не меняющих информацию изменений, которые теоретически не должны затрагивать прикладное программное обеспечение.
Независимость ограничений целостности. Специфические для данной реляционной СУБД ограничения целостности должны определяться на подъязыке реляционных данных и храниться в системном каталоге, а не в прикладных программах.
Независимость от распределения данных. Подъязык манипулирования данными в реляционной СУБД должен позволять прикладным программам и запросам оставаться логически неизменными, независимо от того, как хранятся данные — физически централизованно или в распределенном виде.
Правило запрета обходных путей. Если реляционная система имеет низкоуровневый язык (обрабатывающий данные по одной записи), он не может быть использован для отмены или обхода правил и ограничений, составленных на реляционном языке более высокого уровня (с одновременной обработкой сразу нескольких записей).
Иногда эти правила подразделяют на группы.
Фундаментальные (0 и 12)
0. Фундаментальное.
12. Правило запрета обходных путей.
Структурные (1 и 6)
1. Представление информации.
6. Обновление представления.
Правила целостности (3 и 10)
3. Систематическая обработка NULL-значений.
10. Независимость ограничений целостности.
Правила манипулирования данными (2, 4, 5 и 7)
2. Гарантированный доступ
4. Динамический оперативный каталог, построенный по правилам реляционной модели
5. Исчерпывающий подъязык данных.
7. Высокоуровневые операции вставки, обновления и удаления
Правила независимости от данных (8, 9 и 11)
8. Физическая независимость от данных
9. Логическая независимость от данных
11. Независимость от распределения данных
Администрирование БД
Предыдущие лекции затрагивали, в основном, вопросы проектирования. Грамотное проектирование – это залог стабильной работы информационной системы. Основная работа по проектированию БД лежит на разработчиках ИС. Однако есть еще одна категория задач, связанная не с разработкой систем, а с поддержкой уже внедренных систем на предприятии.
В целом можно сказать, что любое администрирование, применительно к IT, обозначает некоторую деятельность по поддержанию ресурсов предприятия в рабочем состоянии.
Основные задачи, которые стоят перед администратором БД (АБД).
Установка и конфигурирование аппаратного обеспечения, используемого для работы СУБД и размещения БД.
Установка и конфигурирование СУБД (установка новых продуктов и обновлений, настройка имеющихся, разворачивание новых БД и настройка имеющихся, разворачивание тестовых конфигураций БД и систем).
Настройка прикладного ПО, которое использует СУБД и БД предприятия. Проведение работ по внедрению новых систем в части, затрагивающей БД (в том числе, консультации с разработчиками внедряемой системы).
Управление безопасностью БД и приложений БД (настройка прав доступа и разрешений, интеграция системы безопасности СУБД с системой безопасности, используемой на предприятии).
Выполнение резервного копирования и восстановления данных.
Мониторинг производительности и устранение связанных проблем (контроль роста БД, поиск и устранение «бутылочных горлышек»).
Создание корпоративных стандартов (регламентов), определяющих порядок организации процессов администрирования и использования СУБД и БД.
Классификация АБД по выполняемым функциям
Оперативные (operational) АБД:
манипулируют дисковым пространством
наблюдают за текущей производительностью системы
реагируют на возникающие неисправности БД
обновляют системное ПО и ПО базы данных
контролируют структурные изменения БД
запускают процедуры резервного копирования данных
выполняют восстановление данных
создают и управляют тестовыми конфигурациями БД
Тактические (tactical) АБД:
реализуют схемы размещения информации
утверждают процедуры резервного копирования и восстановления данных
разрабатывают и внедряют структурные элементы БД: таблицы, столбцы, размеры объектов, индексацию и т.п.; сценарии(scripts) изменения схемы БД; конфигурационные параметры БД
утверждают план действий в случае аварийной ситуации
Стратегические (strategic) АБД:
выбирают поставщика СУБД
устанавливают корпоративные стандарты данных
внедряют методы обмена данных в рамках предприятия
определяют корпоративную стратегию резервирования и восстановления данных
устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных
Прикладные (application) АБД:
в курсе информационных нужд компании
помогают в разработке прикладных задач
отвечают за разработку схемы и ее изменения
вместе с системным АБД обеспечивают должный уровень резервирования/ восстановления данных
занимаются построением тестовых БД
Системные (system) АБД:
отвечают за все необходимое для резервирования и восстановления данных
контролируют производительность системы в целом
осуществляют поиск и устранение неисправностей
в курсе нынешних и будущих потребностей БД в плане емкости
в курсе текущего состояния и нужд БД
Наемные (contract) АБД:
приглашаются под конкретную задачу или в качестве консультантов
передают персоналу необходимые знания
фиксируют свои действия!
должны прекрасно разбираться в соответствующей области
хороши в качестве временного персонала, для оценки проекта или системы
Администраторы-руководители:
проводят еженедельные совещания
определяют перечень первоочередных задач
устанавливают и оглашают официальный курс и стратегию
утверждают и корректируют должностные инструкции и список обязанностей
следят за наличием соответствующей документации
Требования к квалификации АБД
В зависимости от класса АБД и его должностных обязанностей, уровень его квалификации (и зарплаты) может быть различным. В общем можно отметить следующие требования.
Знание основ реляционной теории (особенно в части поддержки ограничений целостности).
Знание процесса проектирования информационных систем и БД.
Детальное знание администрируемой СУБД в части:
используемого языка (как правило, это диалект SQL с множеством индивидуальных функций);
системы безопасности (как организован доступ пользователей к серверам БД и самим БД);
окружения СУБД (операционная система, контроллер домена, ОС пользователей, каналы связи, Web-сервер, используемые технологии подключения к серверам БД)
используемых методов физического размещения данных (управление дисками и файловыми группами);
использования и настройки методов доступа (настройка индексов и статистик, умение читать и понимать планы исполнения запросов, всё, что касается оптимизации запросов);
языковых и программных средств мониторинга и диагностики;
средств резервного копирования;
средств репликации.
|
