- •Шехтман в. Е.
- •1. Базы данных и модели данных
- •1.1. Введение.
- •1.2. Файлы операционной системы
- •1.3. Пример базы данных.
- •1.4. Иерархическая модель данных
- •1.5. Сетевая модель данных
- •1.6. Инвертированные списки.
- •2. Введение в реляционную модель данных.
- •1.7. Реляционная модель данных
- •3. Реляционная алгебра
- •3.1. Теоретико-множественные операции.
- •3.2. Специальные операции ra
- •4. Нормализация данных
- •4.1. Полная декомпозиция.
- •Магазин товар ндс
- •Товар ндс
- •Магазин ндс
- •Товар ндс
- •Магазин товар ндс
- •4.2. Проблема дублирования данных.
- •1 Глобус 33-33-33
- •2 Глобус 33-33-33
- •4 Океан 77-77-77
- •4.3. Висячие записи.
- •Поставщик Тел
- •4.4. Проблемы, возникающие из-за неудачной структуры данных.
- •4.5. Пятая нормальная форма (5нф).
- •4.6. Функциональная зависимость.
- •4.7. Связь между фз и полной декомпозицией отношения.
- •4.8. Первая нормальная форма (1нф).
- •4.9. Вторая нормальная форма (2нф).
- •4.10. Третья нормальная форма (3нф).
- •4.11. Нормальная форма Бойса-Кодда (нфбк).
- •4.12. Многозначная зависимость.
- •4.13. Четвертая нормальная форма (4нф).
- •4.14. Пример нормализации.
- •4.15. Резюме. Нормальные формы.
- •5. Инфологическое моделирование.
- •5.1. Сущность и набор сущностей
- •5.2. Связи между сущностями.
- •5.3. Рекурсивная связь. Роли.
- •5.4. Множественные связи.
- •5.5. Суперсущности и производные сущности
- •5.6. Слабые наборы сущностей
- •5.7. Борьба с избыточнотью
- •5.8. Преобразование инфологической модели в физическую модель.
- •5.9. Пример инфологического моделирования.
- •6. Язык sql
- •6.1. История sql.
- •6.2. Структура sql.
- •6.3. Язык запросов
- •6.4. Простые запросы на выборку данных.
- •6.5. Агрегатные (групповые) функции.
- •6.6. Вложенные запросы
- •6.7. Внешние объединения
- •6.8. Изменение данных
- •Insert into r1 (o, fio, d) values (5, ‘Иванов’, ’бд’)
- •7. Представления.
- •8. Определение схемы базы данных и ограничений целостности
- •9. Транзакции
- •9.1. Свойства транзакций
- •9.2. Надежное хранение данных
- •9.3. Параллельное выполнение транзакций
- •9.3.1. Коллизия “пропавшие изменения” - lost update problem
- •9.3.2. Коллизия “промежуточные данные” - dirty read
- •9.3.3. Коллизия “Несогласованные данные” - unrepeatable read, inconsistent analysis
- •9.3.4. Коллизия “фантом” - phantom
- •9.4. Уровни изолированности
- •9.5. Тупики
- •10. Ограничение прав доступа в целях обеспечения безопасности
- •11. Физическая организация баз данных
- •11.1. Организация размещения данных.
- •11.2. Организация индексов
- •11.2.1. Поиск в бд.
- •11.2.2. Плотный индекс (индексно-прямые файлы).
- •11.2.3. Неплотный индекс (индексно-последовательные файлы).
- •11.2.4. Сбалансированные деревья.
- •11.2.5. Инвертированные списки.
- •12. Архитектура субд. Методы оптимизации запросов.
- •Логические преобразования запросов.
- •Преобразования запросов с изменением порядка реляционных операций.
- •13. Аналитические системы.
- •Анализ данных.
- •Хранилища данных
- •Типы ошибок
- •Способы реализации olap.
- •Требования к средствам реализации систем оперативной и аналитической обработки данных
- •Многомерная модель данных.
- •Разработка данных
- •14. Загружаемые процедуры.
- •In pr double precision)
- •If eof then leave Cl end if;
- •Insert into providers(code, name)
- •Values (nr.Codec, ‘*** новый поставщик ***’);
- •15.4. Модель сервера приложений (трёхзвенная архитектура, “тонкий клиент”)
- •Список литературы
- •15. Модели совместного доступа к бд
- •15.1. Файл-серверная модель.
- •15.2. Модель клиент-сервер с бизнес-логикой на клиенте.
- •15.3. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
11.2.5. Инвертированные списки.
Для вторичных индексов. (См. Главу 1, раздел 1.5.).
12. Архитектура субд. Методы оптимизации запросов.
На рис. изображена структура СУБД. Здесь условно показано, что СУБД должна управлять внешней памятью, в которой расположены файлы с данными, файлы журналов и файлы системного каталога.
СУБД управляет и оперативной памятью, в которой расположены буферы с данными, буферы журналов, данные системного каталога, которые необходимы для поддержки целостности и проверки привилегий пользователей. Кроме того, в оперативной памяти во время работы СУБД располагается информация, которая соответствует текущему состоянию обработки запросов, гам хранятся планы выполнения скомпилированных запросов и т. д.
Рис. Структура СУБД.
Рис. Оперативная память, управляемая СУБД.
Задачей управления внешней памятью является обеспечение создания необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например для ускорения доступа к данным в некоторых случаях (например, индексы). Как мы видели ранее, в некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа осуществляется на уровне устройств внешней памяти. Но в любом случае пользователь не обязан знать способы организации. СУБД поддерживает собственную систему именования объектов БД. Модуль управления буферами оперативной памяти предназначен для решения задачи эффективной буферизации, которая используется для выполнения всех остальных функций СУБД.
Условно оперативную память, которой управляет СУБД, можно представить как совокупность буферов, хранящих страницы данных, буферов, хранящих страницы журналов транзакций и область совместно используемого пула (см. рис. ). Последняя область содержит фрагменты системного каталога, которые необходимо постоянно держать в оперативной памяти, чтобы ускорить обработку запросов пользователей, и область операторов SQL с курсорами. В стандарте SQL2 определены требования к системному каталогу (иначе его называют словарем данных):
Системный каталог в реляционных СУБД представляет собой совокупность таблиц, которыми владеет сама СУБД. Эти таблицы создаются автоматически при установке программного обеспечения сервера. Все системные таблицы обычно принадлежат некоторому пользователю, изначально создаваемому при создании базы данных.
При обработке SQL-запросов СУБД постоянно обращается к этим таблицам. В некоторых СУБД разрешен ограниченный доступ к этим таблицам, обычно в режиме чтения. Только системный администратор имеет права на их модификацию.
Каждая таблица системного каталога содержит информацию об отдельных структурных элементах СУБД. В SQL2 определены:
Системная таблица |
Содержание |
USERS |
Одна строка для каждого идентификатора пользователя с зашифрованным паролем |
SCHEMA |
Одна строка для каждой информационной схемы |
DATA_TYPE_DESCRIPTION |
Одна строка для каждого домена или столица, имеющего определенный тип данных |
DOMAINS |
Одна строка для каждого домена |
DOMAIN_CONSTRAINTS |
Одна строка для каждого ограничивающего условия, наложенного на домен |
TABLES |
Одна строка для каждой таблицы с указанием имени, владельца, количества столбцов, размеров данных столбцов, и т. д. |
VIEWS |
Одна строка для каждого представления с указанием имени, имени владельца, запроса, который определяет представление и т. д. |
COLUMNS |
Одна строка для каждого столбца с указанием имени столбца, имени таблицы или представления, к которому он относится, типа данных столбца, его размера, допустимости или недопустимости неопределенных значений (NULL ) и т. д. |
VIEW_TABLE_USAGE |
Одна строка для каждой таблицы, на которую имеется ссылка в каком-либо представлении (если представление многотабличное, то для каждой таблицы заносится одна строка) |
VIEW_COLUMN_USAGE |
Одна строка для каждого столбца, на который имеется ссылка в некотором представлении |
TABLE_CONSTRAINTS |
Одна строка для каждого условия ограничения. заданного в каком-либо определении таблицы |
KEY_COLUMN_USAGE |
Одна строка для каждого столбца, на который наложено условие уникальности и который присутствует в определении первичного или внешнего ключа (если первичный или внешний ключ заданы несколькими столбцами, то для каждою из них задастся отдельная строка) |
rential_constraints |
Одна строка для каждого внешнего ключа, присутствующего в определении таблицы |
CHECK_CONSTRAINTS |
Одна строка для каждого условия проверки, заданного в определении таблицы |
CHECK_TABLE_USAGE |
Одна строка для каждой таблицы, на которую имеем ссылка в условиях проверки, ограничительном условии для домена или таблицы |
CHECK_COLUMN_USAGE |
Столбец, на который ссылается условие проверки, ограничительном условии для домена или ином. |
ASSERTIONS
|
Декларативное ограничение целостности |
TABLE_PRIVILEGES
|
Привилегия пользователя по отношению к таблице |
COLUMN_PRIVILEGES |
Привилегия пользователя по отношению к столбцу |
USAGE_PRIVILEGES |
Привилегия пользователя по отношению к домену, набору символов, … |
CHARACTER_SETS |
Набор символов |
COLLATIONS |
Последовательность |
TRANSLATIONS |
Преобразование |
SQL_LANGUAGES |
Язык, поддерживаемый СУБД. |
Стандарт SQL2 не требует, чтобы СУБД в точности поддерживала указанный набор системных таблиц. Стандарт ограничивается требованием, чтобы для рядовых пользователей были доступны некоторые специальные представления системного каталога. Поэтому системные таблицы организуются по-разному в разных СУБД и имеют различные имена, но большинство СУЬД обеспечивает стандартный набор представлений таблиц каталога.
Кроме того, системный каталог может отражать некоторые дополнительные возможности конкретных СУБД.
Область SQL содержит данные связывания, временные буферы, дерево разбора и план выполнения для каждого оператора SQL, переданного серверу. Область разделяемого пула ограничена в размере, поэтому, возможно, в ней не могут поместиться все операторы SQL, которые были выполнены с момента запуска сервера. Ядро СУБД удаляет старые, давно не используемые операторы, освобождая память под новые операторы SQL. Если пользователь выполняет запрос, план выполнения которого уже хранится в разделяемом пуле, то сервер не производит его разбор н построение нового плана, она сразу запускает его на выполнение, возможно, с новыми параметрами.
Модуль управления транзакциями поддерживает механизмы фиксации и отката транзакций, который связан с буферами оперативной памяти и обеспечивает информацию, требуемую для восстановления после мягких или жестких сбоев. Кроме того, он содержит механизмы поиска тупиков и реализует стратегию выхода из них. Модуль поддержки SQL – это транслятор с языка SQL и оптимизатор запросов.
Методы синтаксической оптимизации запросов
Методы синтаксической оптимизации запросов связаны с построением некоторой эквивалентной формы, называемой иногда канонической формой, которая требует меньших затрат на выполнение запроса, но дает результат, полностью эквивалентный исходному запросу.
К методам, используемым при синтаксической оптимизации запросов, относятся следующие:
