
- •Содержание
- •Глава 1. Основные понятия 6
- •Глава 2. Модели данных 19
- •Глава 3. Функциональные зависимости 46
- •Глава 4. Нормализация 54
- •Глава 5. Методология концептуального проектирования 69
- •Глава 6. Методология логического проектирования баз данных реляционного типа 75
- •Глава 7. Методология физического проектирования реляционных бд 93
- •Глава 8. Язык структурированных запросов sql. 107
- •Предисловие
- •Глава 1. Основные понятия
- •1.1. Информационные системы с базами данных.
- •1.2. Функции и возможности субд
- •1.3. Программные компоненты субд
- •1.4. Архитектура среды базы данных
- •1.5. Реляционные объекты данных: терминология
- •1.6. Формальные определения
- •1.6.1. Домены
- •1.6.2. Отношения
- •1.7. Целостность реляционных данных
- •1.7.1. Потенциальные ключи
- •1. Свойством уникальности.
- •2. Свойством не избыточности.
- •1.7.2. Первичные и альтернативные ключи
- •1.7.3. Внешние ключи
- •1.7.4. Ссылочная целостность
- •1.7.5. Правила внешних ключей
- •Глава 2. Модели данных
- •2.1. Элементы er-модели
- •2.1.1. Множество сущностей
- •2.1.2. Атрибуты
- •2.1.3. Связи
- •2.1.4. Рекурсивная связь
- •2.1.5. Атрибуты связей
- •2.2. Структурные ограничения
- •2.2.1. Связь "один-к-одному"
- •2.2.2. Связь "один-ко-многим"
- •2.2.3. Связь "многие-ко-многим"
- •2.2.4. Степень участия
- •2.2.5. Многосторонние связи
- •2.2.6. Слабые множества сущностей
- •2.3. Проблемы er-моделирования (Материал данного параграфа не обязателен для изучения)
- •2.3.1. Ловушки разветвления
- •2.3.2. Ловушка разрыва
- •2.4. Ееr-модель
- •2.4.1. Суперклассы и подклассы типов сущностей
- •2.4.2. Наследование атрибутов
- •2.4.3. Специализация
- •2.4.4. Генерализация
- •2.4.5. Ограничения, накладываемые на процедуры специализации и генерализации
- •2.4.6. Категоризация
- •2.5. Реляционные модели
- •2.5.1. От er-диаграмм к реляционным схемам
- •2.5.2. От er-связей к к отношениям
- •2.5.3. Объединение отношения
- •2.5.4. Преобразование слабых множеств сущностей
- •Глава 3. Функциональные зависимости
- •3.1.Основные определения
- •3.2. Тривиальные и нетривиальные зависимости
- •3.3. Замыкание множества зависимостей
- •3.4. Правила вывода Армстронга
- •3.5. Неприводимое множество зависимостей
- •Примеры
- •Глава 4. Нормализация
- •4.1. Декомпозиция без потерь
- •4.2. Первая, вторая и третья нормальные формы.
- •Вторая нормальная форма (2нф).
- •Третья нормальная форма ( 3нф ).
- •Нормальная форма Бойса-Кодда
- •4.3. Многозначные зависимости
- •4.4. Четвертая нормальная форма (4нф)
- •4.5. Пятая нормальная форма (5нф)
- •4.6. Итоговая схема процедуры нормализации
- •4.7. Альтернативный набор определений нфбк, 4нф и 5нф
- •4.8. Выделим цели процесса нормализации
- •4.9. Другие нормальные формы
- •Глава 5. Методология концептуального проектирования
- •5.1. Источники представления пользователей о предметной области
- •5.2. Определение типов сущностей
- •5.3. Определение типов связей
- •5.4. Определение атрибутов
- •5.5. Определение доменов атрибутов
- •5.6. Определение потенциальных и первичных ключей
- •5.7. Генерализация и специализация типов сущностей
- •5.8. Создание диаграммы "сущность-связь"
- •5.9. Обсуждение локальных концептуальных моделей данных с конечными пользователями
- •Глава 6. Методология логического проектирования баз данных реляционного типа
- •6.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
- •6.1.1. Удаление связей типа m:n
- •6.1.2. Удаление сложных связей
- •6.1.3. Удаление рекурсивных связей
- •6.1.4. Удаление связей с атрибутами
- •6.1.5. Удаление множественных атрибутов
- •6.1.6. Перепроверка связей типа 1:1
- •6.1.7. Удаление избыточных связей
- •6.2. Наборы отношений локальных логических моделей данных
- •6.2.1. Сильные типы сущностей
- •6.2.2. Слабые типы сущностей
- •6.2.3. Бинарные связи типа "один-к-одному" (1:1)
- •6.2.4. Бинарные связи типа "один-ко-многим" (1:м)
- •6.2.5. Связи типа "суперкласс/подкласс"
- •6.2.6. Документирование созданных отношений и атрибутов внешних ключей
- •6.3. Проверка модели с помощью правил нормализации
- •6.4. Проверка модели в отношении транзакций
- •6.5. Создание диаграмм "сущность-связь"
- •6.7.1. Слияние локальных логических моделей данных в единую глобальную модель данных
- •6.7.1.1. Анализ имен сущностей и их первичных ключей
- •6.7.1.2. Анализ имен связей
- •2. Слияние эквивалентных сущностей с различными первичными ключами
- •3. Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи
- •7.1.1. Oписание на языке sql стандарта iso 1992 (sql2)
- •Листинг 1. Операторы языка sql, предназначенные для создания таблицы
- •7.1.2. Реализация с использованием триггеров
- •Пример 1
- •7.1.3. Реализация с использованием уникальных индексов
- •Пример 2
- •7.2. Реализация бизнес-правил предприятия в среде целевой субд
- •7.3. Организация эффективного хранения данных
- •7.3.1. Анализ транзакций.
- •7.3.2. Выбор файловой структуры.
- •Последовательные файлы
- •Хешированные файлы
- •Индексно-последовательные файлы
- •Двоичные деревья
- •7.3.3. Определение вторичных индексов.
- •7.3.4. Анализ необходимости введения контролируемой избыточности.
- •7.3.5. Определение требований к дисковой памяти.
- •Последовательные файлы
- •Хешированные файлы
- •7.4. Разработка механизмов защиты
- •7.4.1. Разработка пользовательских представлений (видов).
- •7.4.2. Определение прав доступа.
- •7.5. Организация мониторинга и настройка функционирования системы
- •Глава 8. Язык структурированных запросов sql.
- •Операторы ddl
- •Типы данных
- •Создание файла бд
- •Создание (определение) таблиц
- •Определение столбцов
- •Примеры создания таблиц
- •Удаление таблиц
- •Модификация структуры таблиц
- •Операторы, изменяющие информацию в бд
- •Добавление новых данных.
- •Удаление существующих данных.
- •Обновление существующих данных.
- •Запрос информации из бд
- •Инструкция select
- •Предложение select.
- •Предложение from.
- •Запросы
- •Порядок выполнения многотабличных запросов
- •Виды объединений
- •Предложение where.
- •Условия отбора
- •Составные или сложные условия отбора
- •Предложение group by.
- •Предложение having.
- •Предложение order by.
- •Применение оператора select в инструкции insert
Пример 2
CREATE UNIQUE INDEX property no index ON property for rent (pno)
7.2. Реализация бизнес-правил предприятия в среде целевой субд
Поскольку одни системы для реализации требований организации предлагают больше возможностей, а другие - меньше, то способ реализации бизнес-правил будет зависеть от типа выбранной целевой СУБД. Так, например, в компании Домострой существует правило, согласно которому каждый работник может одновременно заниматься не более чем десятью сдаваемыми в аренду объектами. Это ограничение можно включить в оператор SQL при создании таблицы Property_for_Rent (Недвижимость_в_аренду):
CONSTRAINT staff_not_handling_too_much
CHECK (NOT EXIST (SELECT sno FROM property_for_rent
GROUP BY sno HAVING COUNT( ) >10))
Альтернативным методом реализации бизнес-правил является использование триггеров:
CREATE TRIGGER staff_not_handling_too_much
ОN property_for_rent
FOR INSERT, UPDATE
AS IF ((SELECT COUNT(*) FROM property_for_rent p, WHERE p.sno=INSERTED.sho}>10)
BEGIN
PRINT "Данный работник уже отвечает за 10 объектов"
ROLLBACK TRANSACTION
END
В результате создается триггер, который будет запускаться при каждой попытке вставки новой записи в таблицу Property_for_Rent (Недвижимость_в_аренду).
7.3. Организация эффективного хранения данных
Одной из важнейших целей физического проектирования базы данных является организация эффективного хранения данных. Существует несколько показателей, которые могут быть использованы для оценки достигнутой эффективности.
Пропускная способность транзакций. Этот показатель представляет собой количество транзакций, которые могут быть обработаны за заданный интервал времени.
Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции.
Дисковая память. Этот показатель представляет собой объем дискового пространства, необходимого для размещения файлов базы данных
Однако ни один из этих факторов не является самодостаточным. Как правило, разработчик вынужден жертвовать одним из показателей ради другого, чтобы достичь оптимального баланса.
Вначале имеет смысл выбрать такие структуры хранилищ, которые будут весьма эффективны при массовой загрузке данных в процессе создания базы, после чего их можно будет заменить другими структурами, позволяющими ее эффективно эксплуатировать.
Некоторые СУБД предоставляют пользователям средства ознакомления с выбранной оптимизатором стратегией выполнения отдельного запроса или операции обновления. Эта функция носит название Query Execution Plan (QPE) • (получение плана выполнения запроса). Например, СУБД DB2 имеет утилиту EXPLAIN, СУБД Oracle – диагностическую утилиту EXPLAIN PLAN, а СУБД INGRES поддерживает интерактивную QPE-функцию. Если выполнение запроса происходит медленнее, чем это предполагалось, имеет смысл воспользоваться подобным инструментом, чтобы определить причины замедления работы. Полученные данные помогут найти альтернативную стратегию, которая позволит увеличить скорость обработки запроса. Чтобы достичь высокой производительности системы, разработчик физического проекта базы данных должен решить, каким образом четыре основных компонента оборудования будут взаимодействовать.
Поскольку одни системы для реализации требований организации предлагают больше возможностей, а другие – меньше, то разработчик физического проекта базы данных должен решить каким образом четыре основных компонента оборудования будут взаимодействовать между собой и как это повлияет на достигнутый уровень производительности.
Оперативная память. Чем больше объем доступной СУБД оперативной памяти, тем быстрее будут работать приложения. Опыт показывает, что полезно постоянно поддерживать в системе такой режим, при котором около 5% ее оперативной памяти остается свободной. Эти страницы будут считаны с диска, как только вновь потребуется доступ к данным.
Процессор. Устанавливает задачи для других системных ресурсов и выполняет пользовательские процессы. Важнейшим условием эффективной работы этого компонента является предотвращение конкуренции за право использования, что обычно сопровождается переводом процессов в состояние ожидания.
Дисковый ввод/вывод. В любой достаточно мощной СУБД процессы сохранения и выборки данных связаны с выполнением множества дисковых операций ввода/вывода.
На общую производительность дисковой памяти очень большое влияние оказывает способ организации хранения данных.
Основные принципы распределения данных на дисковых устройствах заключаются в следующем:
Файлы операционной системы должны быть отделены от файлов базы данных.
Основные файлы базы данных должны быть отделены от индексных файлов.
Журнал восстановления должен быть отделен от остальной части базы данных.
С учетом сказанного приступим к обсуждению действий, которые должны быть выполнены на этапе разработки базы данных:
1. Анализ транзакций.
2. Выбор файловой структуры.
3. Определение вторичных индексов.
4. Анализ необходимости введения контролируемой избыточности данных.
5. Определение требований к дисковой памяти.