- •С.В. Никитина. Базы и Банки Данных. – Москва, 2009. – 80 стр.
- •Содержание
- •Глава 1. Назначение и основные компоненты системы баз данных 6
- •Глава 2. Типовая организация современной субд 10
- •Глава 3. Инфологическая модель данных «сущность-связь» 21
- •Глава 4. Ранние подходы к организации бд. Иерархические и сетевые субд. 31
- •Глава 5. Реляционная модель 35
- •Глава 6. Базисные средства манипулирования реляционными данными 40
- •Глава 7. Особенности теоретико-множественных операций реляционной алгебры 45
- •Глава 1. Назначение и основные компоненты системы баз данных Данные и эвм
- •Концепция баз данных
- •Основные функции субд
- •Непосредственное управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация
- •Поддержка языков бд
- •Глава 2. Типовая организация современной субд
- •Классификация пользователей субд
- •Распределение обязанностей в системах с базами данных.
- •Администраторы данных и администраторы баз данных.
- •Администрирование данных и администрирование баз данных.
- •Администрирование данных.
- •Задачи администрирования данных.
- •Администрирование Базы Данных.
- •Задачи администрирования базы данных.
- •Администрирование данных и администрирование базы данных
- •Преимущества централизованного подхода к управлению данными
- •Возможность совместного доступа к данным
- •Сокращение избыточности данных
- •Устранение противоречивости данных (до некоторой степени)
- •Возможность поддержки транзакций
- •Обеспечение целостности данных
- •Организация защиты данных
- •Возможность балансировки противоречивых требований
- •Возможность введения стандартизации
- •Независимость данных
- •Глава 3. Инфологическая модель данных «сущность-связь»
- •Основные понятия
- •Характеристика связей и язык моделирования
- •О первичных и внешних ключах
- •Ограничения целостности
- •Глава 4. Ранние подходы к организации бд. Иерархические и сетевые субд.
- •Иерархические системы
- •Иерархические структуры данных
- •Манипулирование данными
- •Ограничения целостности
- •Сетевые системы
- •Сетевые структуры данных
- •Манипулирование данными
- •Ограничения целостности
- •Достоинства и недостатки ранних субд
- •Глава 5. Реляционная модель Основные понятия реляционных баз данных
- •Тип данных
- •Кортеж, отношение
- •Фундаментальные свойства отношений
- •Отсутствие кортежей-дубликатов
- •Отсутствие упорядоченности кортежей
- •Отсутствие упорядоченности атрибутов
- •Атомарность значений атрибутов
- •Общая характеристика реляционной модели данных
- •Глава 6. Базисные средства манипулирования реляционными данными Реляционная структура данных. Общие понятия реляционного подхода к организации бд. Основные концепции и термины
- •Реляционная алгебра
- •Общая интерпретация реляционных операций
- •Замкнутость реляционной алгебры и операция переименования
- •Глава 7. Особенности теоретико-множественных операций реляционной алгебры Объединение
- •Пересечение
- •Вычитание
- •Произведение
- •Специальные реляционные операции* Выборка
- •Проекция
- •Соединение
- •Деление
- •Ассоциативность и коммутативность
- •Зачем нужна реляционная алгебра
- •Операция расширения
- •Операция обобщения
- •Группирование и разгруппирование
- •Реляционные сравнения
- •Реляционное исчисление.
- •Глава 8. Нормализация данных. 1-я, 2-я, 3-я нормальные формы
- •Функциональная зависимость
- •Вторая нормальная форма
- •Третья нормальная форма
- •Глава 9. Нормализация данных. Нормальные формы более высоких порядков
- •Нормальная форма бойса-кодда
- •Многозначные зависимости. Четвертая нормальная форма
- •Зависимость соединения. Пятая нормальная форма
- •Глава 10. Внутренняя организация реляционных субд Структуры внешней памяти
- •Хранение отношений
- •Индексы
- •Журнальная информация
- •Служебная информация
- •Глава 11. Методы организации индексов
- •Методы поиска по дереву
- •Автоматическое поддержание свойства сбалансированности b-деревьев при выполнении операций занесения и удаления записей *
- •Хэширование
- •Глава 12. Защита бд Обеспечение защиты данных в базе
- •Идентификация пользователя
- •Управление доступом
- •Защита данных при статистической обработке
- •Физическая защита
- •Глава 13. Целостность бд
- •Целостность сущности и ссылок
- •Обеспечение целостности данных
- •Транзакции и целостность баз данных
- •Изолированность пользователей
- •Сериализация транзакций
- •Глава 14. Степень соответствия субд реляционной модели
- •Список литературы по теме курса
- •Кори Майкл Дж., Эбби Майкл, Абрамсон Ян
-
Организация защиты данных
Благодаря полному контролю над базой данных АБД (безусловно, в соответствии с указаниями администратора данных) может обеспечить доступ к ней только через определенные каналы. Для этой цели могут устанавливаться ограничения защиты (security constraints) или правила, которые будут проверяться при любой попытке доступа к уязвимым данным. Можно установить различные правила для разных типов доступа (выборка, вставка, удаление и т.д.) к каждому из элементов информации в базе данных. Однако следует заметить, что при отсутствии таких правил безопасность данных подвергается большему риску, чем в обычной (разобщенной) файловой системе. Следовательно, централизованная природа системы баз данных в определенном смысле требует наличия надежной системы защиты.
-
Возможность балансировки противоречивых требований
Зная общие требования всего предприятия (а не требования каждого отдельного пользователя), АБД (опять же, в соответствии с указаниями администратора данных) может структурировать базу данных таким образом, чтобы обслуживание было наилучшим для всего предприятия. Например, он может выбрать такое физическое представление данных во вторичной памяти, которое обеспечит быстрый доступ к информации для наиболее важных приложений (возможно, с потерей производительности для некоторых других приложений).
-
Возможность введения стандартизации
Благодаря централизованному управлению базой данных АБД (по указаниям администратора данных) может обеспечить соблюдение всех подходящих стандартов, регламентирующих представление данных в системе. Стандарты бывают частными, корпоративными, ведомственными, промышленными, национальными и интернациональными. Стандартизация представления данных очень важна с точки зрения обмена и пересылки данных между системами. Стандарты именования и документирования данных важны в отношении их совместного использования и в отношении их углубленного понимания.
Большинство перечисленных преимуществ достаточно очевидно. Однако есть дно преимущество, которое необходимо добавить к этому списку и которое не очевидно (хотя косвенно и охватывает несколько преимуществ). Речь идет об обеспечении независимости данных. (Строго говоря, это, скорее, цель создания систем баз данных, а не обязательное их преимущество).
-
Независимость данных
Независимость данных может быть реализована на двух уровнях: физическом и логическом. Однако сейчас нас интересует только физическая независимость. Поэтому неуточненный термин "независимость данных" мы пока будем понимать лишь как физическую независимость данных.
Замечание. Необходимо отметить, что термин "независимость данных" несовсем подходящий (он не отражает достаточно точно сущность происходящего). Но поскольку именно этот термин традиционно используется, мы последуем общему правилу.
Проще всего разобраться в понятии независимости данных на примере его противоположности. Приложения, реализованные в старых системах ("дореляционные" или созданные даже до появления систем баз данных), в той или иной мере зависимы от данных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программный код приложения.
Пример. Предположим, у нас есть приложение, обрабатывающее файл EMPLOYEE. Исходя из соображений эффективности примем, что этот файл проиндексирован по полю имени работника (NAME). В старых системах в этом приложении учитывалось бы, что такой индекс существует, и что последовательность записей в файле определена данным индексом. На основе этих сведений была бы построена вся внутренняя структура приложения. В частности, избранный способ реализации процедур доступа и обработки исключительных ситуаций в значительной степени зависел бы от особенностей интерфейса, предоставляемого программами управления данными.
Приложения, подобные описанному в этом примере, мы называем зависимыми от данных, так как невозможно изменить физическое представление (т.е. способ физического размещения данных во вторичной памяти) или метод доступа (т.е. конкретный способ доступа к данным), не изменив самого приложения (возможно, радикально). Например, невозможно заменить индексированный файл в нашем примере хешированным файлом, не внеся в приложение значительных изменений. Более того, изменению в подобных случаях подлежат те части приложения, которые взаимодействуют с программами управления данными. Трудности, возникающие при этом, не имеют никакого отношения к проблеме, для решения которой было написано данное приложение; это трудности, внесенные используемой структурой интерфейса управления данными.
Однако для системы баз данных крайне нежелательно, чтобы приложение зависело от данных, и на то есть, по меньшей мере, две причины.
1. Для разных приложений требуются разные представления одних и тех же данных. Например, предположим, что до перехода к интегрированной базе данных предприятие имело два приложения, А и В. Каждое из них работало с собственным файлом, содержащим поле "баланс заказчика". Предположим также, что приложение А записывает значение этого поля в десятичном формате, а приложение В — в двоичном. Эти два файла все еще можно интегрировать, а существующую избыточность устранить, если в СУБД есть возможность выполнить все необходимые преобразования между форматом представления данных, (формат представления может быть десятичным, двоичным или любым другим) и форматом, необходимым для приложения. Например, если принято решение сохранять значения поля в десятичном формате, каждое обращение к приложению В потребует преобразования значений в двоичный формат или из двоичного формата.
Это довольно простой пример различий, которые могут существовать в системе баз данных между формой представления данных в приложении и формой их физического хранения.
2. Администратор базы данных должен иметь неограниченные возможности изменять физическое представление или метод доступа к данным в случае изменения требований, причем без необходимости модифицировать существующие приложения. Например, к базе данных могут быть добавлены новые виды данных, на предприятии могут быть приняты новые стандарты, могут быть изменены приоритеты приложений (а, следовательно, и связанные с ними требования к производительности), могут появиться новые типы запоминающих устройств и т.д. Если приложения зависят от данных, то перечисленные изменения потребуют внесения изменений в программы, а значит, дополнительных усилий программистов, которые можно было бы направить на создание новых приложений. До сих пор подобные проблемы не являются исключением.
Таким образом, обеспечение независимости данных — важнейшая цель создания систем баз данных. Независимость данных можно определить как иммунитет приложений к изменениям в физическом представлении данных и в методах доступа к ним, а это означает, что рассматриваемые приложения не зависят от любых конкретных способов физического представления информации или выбранных методов доступа к ним.