- •Базы данных: основные понятия. Введение в базы данных. Определения.
- •Развитие технологий обработки данных. Современное состояние технологий баз данных.
- •Базы данных и их свойства.
- •Системы управления базами данных. Компоненты среды субд.
- •Архитектура субд. Трехуровневая архитектура базы данных. Внешний уровень. Концептуальный уровень. Внутренний уровень.
- •Функции субд. Управление данными во внешней памяти. Управление транзакциями. Восстановление базы данных.
- •Управление данными во внешней памяти
- •Управление транзакциями
- •Восстановление базы данных
- •Функции субд. Поддержка языков бд. Словарь данных. Управление параллельным доступом. Управление буферами оперативной памяти. Поддержка языков бд
- •Словарь данных
- •Управление буферами оперативной памяти
- •Функции субд. Контроль доступа к данным. Поддержка обмена данными. Поддержка целостности данных. Поддержка независимости от данных. Вспомогательные функции. Контроль доступа к данным
- •Поддержка обмена данными
- •Поддержка целостности данных
- •Поддержка независимости от данных
- •Вспомогательные функции
- •Типовая организация современной субд.
- •Языки баз данных. Язык определения данных. Языки манипулирования данными.
- •Манипулирование данными
- •Архитектура многопользовательских субд. Тенденции развития многопользовательских систем.
- •Модели двухуровневой технологии «клиент-сервер». Файловый сервер. Модель удаленного доступа к данным.
- •Модель сервера баз данных. Сервер приложений. Трехуровневая модель.
- •Проектирование баз данных. Концепции проектирования. Жизненный цикл бд.
- •Планирование разработки базы данных. Определение требований к системе. Сбор и анализ требований пользователей.
- •Проектирование базы данных. Концептуальное проектирование базы данных. Логическое проектирование базы данных. Физическое проектирование базы данных.
- •Разработка приложений. Загрузка данных. Тестирование. Эксплуатация и сопровождение.
- •Концептуальное проектирование. Фундаментальные понятия. Объекты. Атрибуты. Ключи.
- •Связи между объектами. Показатель кардинальности. Степень участия. Рекурсивная связь.
- •Пример моделирования локальной ПрО.
- •Специализация и генерализация. Категоризация. Составные объекты.
- •Модели данных. Классификация моделей данных. Объектные модели данных. Модели данных на основе записей. Физическая модель данных.
- •Сетевая модель. Структуры данных сетевой модели. Сетевой граф бд.
- •Преобразование концептуальной модели в сетевую. Реализация наборов. Управляющая часть сетевой модели.
- •Иерархическая модель данных. Структурная часть иерархической модели.
- •Преобразование концептуальной модели в иерархическую модель данных.
- •Управляющая часть иерархической модели. Описание данных. Манипулирование данными. Ограничения целостности.
- •Достоинства и недостатки ранних субд.
- •Реляционная модель данных. История вопроса. Структурная часть реляционной модели. Реляционное отношение. Свойства и виды отношений. Реляционные ключи.
- •Обновление отношений. Целостность базы данных. Проектирование базы данных. Последовательная нормализация. Избыточность данных в бд.
- •Аномалии обновления в базе данных. Аномалии включения. Аномалии удаления. Аномалии модификации.
- •Процесс нормализации. Функциональные зависимости и ключи. Первая нормальная форма.
- •Вторая нормальная форма. Третья нормальная форма.
- •Нормализация на основе декомпозиции. Недостатки данной нормализации.
- •Четвертая нормальная форма. Пятая нормальная форма.
- •Проектирование реляционной базы данных. Логическое проектирование реляционной бд. Упрощение концептуальной модели данных.
- •Методика преобразования концептуальных структур данных в реляционные структуры.
- •Преобразование объектов и атрибутов. Преобразование бинарных связей. Преобразование связи типа «суперкласс/подкласс».
- •Предварительные отношения для бинарных связей типа m:n. Преобразование составных объектов. Преобразование тернарных связей. Преобразование рекурсивных связей.
- •Проверка модели с помощью концепций последовательной нормализации. Проверка модели в отношении транзакций пользователей. Проверка поддержки целостности данных.
- •Управление реляционной базой данных.
- •Реляционная алгебра. Основные операции реляционной алгебры. Дополнительные операции реляционной алгебры.
- •Реляционное исчисление. Целевой список и определяющее выражение. Формулы исчисления кортежей. Квантор существования. Квантор всеобщности.
- •Язык sql. Исторические аспекты развития sql. Структура и типы данных языка sql. Операторы языка sql.
- •Оператор выбора select. Формирование запросов к базе данных. Агрегатные функции языка. Группирование результатов. Вложенные запросы.
- •Оператор выбора select. Многотабличные запросы. Множественные операции реляционной алгебры. Открытые соединения.
- •Встроенный sql. Однострочные и многострочные запросы.
- •Управление транзакциями. Модель транзакции. Свойства транзакции. Журнализация. Проблемы многопользовательских систем. Блокировки.
- •Триггеры. Основные сведения. Создание триггера. Триггер удаления.
- •Хранимые процедуры. Назначение хранимых процедур. Создание и использование хранимых процедур.
- •Администрирование баз данных. Управление учетными записями и правами доступа в ms sql Server. Резервное копирование и восстановление баз данных.
Предварительные отношения для бинарных связей типа m:n. Преобразование составных объектов. Преобразование тернарных связей. Преобразование рекурсивных связей.
Предварительные отношения для бинарных связей типа M:N
При такой степени связи требуется три отношения вне зависимости от класса принадлежности обоих объектов: по одному для каждого объекта, причем ключ каждого объекта используется в качестве первичного ключа соответствующего отношения, и одного отношения для связи. Последнее должно иметь в числе своих атрибутов ключ каждого объекта. Единственно допустимый вариант в сложившейся ситуации - представить БД тремя отношениями:
Проверка модели с помощью концепций последовательной нормализации. Проверка модели в отношении транзакций пользователей. Проверка поддержки целостности данных.
Целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в НФБК.
Если в процессе анализа отношений модели будут найдены отношения, не отвечающие требованиям НФБК, то это будет означать, что где-то на предыдущих этапах были допущены ошибки. Возможно, ошибки появились при построении концептуальной модели, а возможно — в процессе ее преобразования в логическую модель. Для обеспечения корректности логической модели в такой ситуации придется вернуться на ранние этапы проектирования и перестроить ошибочно созданные фрагменты модели.
Правильно выполненные действия по проектированию модели предметной области должны обязательно привести к созданию набора отношений в НФБК. Функциональные зависимости, определенные для реляционной модели, являются атрибутами связей с показателями кардинальности «один к одному» или «один ко многим». Описанный процесс преобразования каждой из этих конструкций в атрибуты реляционных отношений гарантирует, что они будут зависеть только от ключевых атрибутов. Таким образом, каждая полученная реляционная таблица будет иметь НФБК.
Проверка модели в отношении транзакций пользователей
Помимо выполнения вышеописанной проверки созданная реляционная модель предметной области должна быть проанализирована в плане возможности выполнения всех транзакций, предусмотренных представлениями пользователей. Перечень транзакций определяется в соответствии со спецификациями, описывающими действия, выполняемые пользователями.
Наиболее действенный метод осуществления указанной проверки заключается в нанесении непосредственно на ER-диаграммы всех путей, которые потребуются для выполнения каждой из транзакций. Такой подход позволяет выделить в модели ценные с точки зрения транзакций ее области, и наоборот, выявить области, бесполезные для транзакций. По отношению к бесполезным для транзакций областям концептуальной модели можно вполне справедливо поставить вопрос о целесообразности их присутствия в модели. В то же время, если в модели присутствует область, не позволяющая выполнить некоторую необходимую пользователю транзакцию, то это может свидетельствовать о том, что в данной области не достает какого-то объекта или связи, а, следовательно, модель нуждается в доработке.
Проверка поддержки целостности данных
О необходимости поддерживать в базе данных согласованные непротиворечивые данные в книге уже декларировалось неоднократно. Построив логическую модель данных предметной области, проектировщик как раз подошел к такому моменту, когда от деклараций требуется перейти к делу и необходимо заняться этим вопросом вплотную. При этом следует обратить внимание на следующие вопросы:
возможность для атрибутов иметь пустые значения;
ограничения для доменов атрибутов;
категорная целостность;
ссылочная целостность;
бизнес-правила в данной предметной области.
