
- •Первая нормальная форма.
- •Основной пример. Отношение (Сотрудники-Отделы-Проекты)
- •Функциональные зависимости отношений.
- •Вторая нормальная форма.
- •Анализ декомпозированных отношений
- •Третья нормальная форма.
- •Алгоритм приведения к 3нф.
- •Сравнение нормализованной и ненормализованной модели.
- •Корректность процедуры нормализации - декомпозиция без потерь.
- •Теорема Хеза.
- •Четвертая нормальная форма.
- •Многозначные зависимости.
- •Теорема Фейджина.
- •Пятая нормальная форма.
- •Зависимости соединения.
- •Приведение от 3нф к 5нф.
- •Информационная система. Состав и свойства.
- •Функциональные части ис. Обеспечивающие части ис.
- •Средства структурного анализа и их взаимоотношения.
- •Диаграммы потоков данных.
- •Основные компоненты диаграммы потоков данных.
- •Контекстная диаграмма dfd и детализация процессов.
- •Процесс построения модели dfd
- •Триггеры и ограничения. События, условия и действия.
- •Объявление и открытие курсора.
- •Оператор fetch.
- •Предметная область и ее модель.
- •Физическое проектирование бд.
- •Процедурные и декларативные языки манипулирования данными.
- •Потребительские свойства ис.
- •Характерные особенности современных крупных проектов ис.
- •Частные принципы создания ис.
- •Организационно-технологические принципы создания ис.
- •Аспекты описания ис.
- •Стадии проектирования ис.
- •Предпроектная стадия проектирования ис.
- •Этап проектирования ис.
- •Этап внедрения ис.
- •Анализ информационных потребностей ис.
- •Жизненный цикл программного обеспечения ис.
- •Модели жизненного цикла по ис.
- •Каскадная модель жизненного цикла по ис.
- •Спиральная модель жизненного цикла по ис.
- •Итерационная модель жизненного цикла по ис.
- •Этап определения стратегии.
- •Принципы структурного анализа.
- •Словарь данных dfd.
- •Спецификации управления.Диаграммы переходов состояний (std).
- •Из каких объектов состоит std.
- •Основные понятия er-диаграмм: сущности, экземпляры, атрибуты, связи.
- •Типы и модальности связей.
- •Более сложные элементы er-модели.
- •Подтипы и супертипы.
- •Получение реляционной схемы из er-диаграммы.
- •Пример разработки простой er-модели.
- •Проектирование баз данных.
- •Концептуальное и логическое проектирование бд.
- •Денормализация для оптимизации
- •Физическое проектирование бд. Типы данных.
- •Физическое проектирование бд. Индексы, кластеры.
- •Физическое проектирование бд. Временные данные.
- •Физическое проектирование бд. Хранение объектов данных.
- •Оптимизация запросов, основные понятия.
- •Синтаксическая оптимизация
- •Оптимизация, основанная на правилах
- •Оптимизация, основанная на вычислении стоимости
- •Последовательность шагов оптимизации запросов
- •Физические операции манипулирования данными.
- •Анализ запросов с целью повышения скорости их выполнения
- •Использование базовых переменных, понятие курсора
- •Базовая переменная sqlstate.
- •Операции встроенного sql, не использующие курсоров.
- •Операции, использующие курсоры.
- •Операторы позиционного удаления и модификации данных.
- •1.Оператор позиционного удаления
- •2.Оператор позиционной модификации
- •Понятие, назначение и структура хранимых процедур.
- •Использование хранимых процедур.
- •Операторы окончания транзакции.
- •Встроенный sql в vba.
- •Уровни моделирования выделяемые при разработке базы данных.
- •Принципы проектирование реляционных баз данных
- •Критерии оценки качества логической модели данных. Адекватность базы данных предметной области
- •Назначение нормализации отношений.
- •Приведение к 5нф.
- •Этапы разработки проекта: стратегия и анализ.
- •Этапы проектирования.Стратегия.
- •Этап анализа.
- •Основные методологии структурного анализа.
- •Сильные и слабые сущности.
- •Некоторые принципы проверки качества и полноты информационной модели.
- •Методология idef1х.
- •Идентифицирующие и неидентифицирующие связи.
- •Мощность связи.
Денормализация для оптимизации
Иногда приходится жертвовать идеями и работать с недостаточно нормализованной схемой БД. Конечно, при работе с такой схемой могут возникать аномалии изменений, но с ними можно бороться другими способами, например, с помощью триггеров.
Приведем несколько примеров ограничений реализации СУБД:
В информационной модели описаны три сущности — A, B, C. Сущности B и C содержат внешние ключи, ссылающиеся на сущность A. В СУБД поддерживается возможность определения внешнего ключа только для первичного ключа, а для возможного ключа определить декларативную ссылочную целостность нельзя. В этом случае отображение ER-модели на физическую модель данных невозможно без изменения информационной модели.
В информационной модели описан внешний ключ с каскадным удалением и модификацией. В СУБД поддерживаются внешние ключи только для варианта действия no action (то есть каскадные изменения в явном виде не поддерживаются). Реализация ссылочной целостности посредством триггеров ограничена уровнем каскадирования триггеров (например, 32 вызовами триггера). В этом случае потребуется также изменение информационной модели.
В информационной модели определен атрибут, представляющий собой строку длиной в 500 символов. По этому атрибуту часто осуществляется поиск в информационной системе; объем данных велик. В СУБД можно индексировать строки символов не длиннее чем 128 или 256 символов. Если осуществлять поиск без индекса, то время ответа информационной системы существенно превышает допустимое, вследствие чего придется изменить описание сущности.
Физическое проектирование бд. Типы данных.
Как правило, СУБД поддерживают небольшой набор базовых типов данных: числовые типы (целые, вещественные с плавающей и фиксированной точкой), строки (символов и байт), дата и время (или комбинированный тип datetime), BLOB (и его разновидности, например BLOB-поля для хранения только текста). В информационной модели каждому атрибуту соответствует домен. Поскольку не все реализации СУБД поддерживают домены, то в этом случае при определении модели данных ограничения домена описывают как ограничения столбца таблицы (если такое возможно); в частности используют check constraints, триггеры.
Следует отметить, что при определении типов столбцов таблиц нужно учитывать, какие типы данных поддерживаются в словаре данных СУБД. Например, в Oracle ключевые слова integer, smallint, real поддерживаются транслятором SQL, но в словаре данных им соответствуют number(38), number(38), float(63), так как Oracle хранит данные в двоично-десятичном формате с плавающей точкой, а не в двоичном формате с плавающей точкой, и 38-значное число никак нельзя назвать словом smallint.
СУБД поддерживают два вида строковых типов: с фиксированной длиной (например, char), когда хранится ровно столько символов, сколько указано в описании атрибута, и с переменной длиной (например, varchar), когда хранится реальная длина значения атрибута, а концевые пробелы строки усекаются. Семантика сравнения строк в СУБД также различная, и если ваше мнение о сравнении строк расходится с тем, как это реализовано в СУБД, то придется смириться с этим как с особенностью СУБД. Например (описано поведение Oracle 7.x), если сравниваются значения A равное ‘ab’ и B равное ‘ab’ двух атрибутов типа varchar разной длины, то sql сообщит, что они не совпадают.