- •Первая нормальная форма.
- •Основной пример. Отношение (Сотрудники-Отделы-Проекты)
- •Функциональные зависимости отношений.
- •Вторая нормальная форма.
- •Анализ декомпозированных отношений
- •Третья нормальная форма.
- •Алгоритм приведения к 3нф.
- •Сравнение нормализованной и ненормализованной модели.
- •Корректность процедуры нормализации - декомпозиция без потерь.
- •Теорема Хеза.
- •Четвертая нормальная форма.
- •Многозначные зависимости.
- •Теорема Фейджина.
- •Пятая нормальная форма.
- •Зависимости соединения.
- •Приведение от 3нф к 5нф.
- •Информационная система. Состав и свойства.
- •Функциональные части ис. Обеспечивающие части ис.
- •Средства структурного анализа и их взаимоотношения.
- •Диаграммы потоков данных.
- •Основные компоненты диаграммы потоков данных.
- •Контекстная диаграмма dfd и детализация процессов.
- •Процесс построения модели dfd
- •Триггеры и ограничения. События, условия и действия.
- •Объявление и открытие курсора.
- •Оператор fetch.
- •Предметная область и ее модель.
- •Физическое проектирование бд.
- •Процедурные и декларативные языки манипулирования данными.
- •Потребительские свойства ис.
- •Характерные особенности современных крупных проектов ис.
- •Частные принципы создания ис.
- •Организационно-технологические принципы создания ис.
- •Аспекты описания ис.
- •Стадии проектирования ис.
- •Предпроектная стадия проектирования ис.
- •Этап проектирования ис.
- •Этап внедрения ис.
- •Анализ информационных потребностей ис.
- •Жизненный цикл программного обеспечения ис.
- •Модели жизненного цикла по ис.
- •Каскадная модель жизненного цикла по ис.
- •Спиральная модель жизненного цикла по ис.
- •Итерационная модель жизненного цикла по ис.
- •Этап определения стратегии.
- •Принципы структурного анализа.
- •Словарь данных dfd.
- •Спецификации управления.Диаграммы переходов состояний (std).
- •Из каких объектов состоит std.
- •Основные понятия er-диаграмм: сущности, экземпляры, атрибуты, связи.
- •Типы и модальности связей.
- •Более сложные элементы er-модели.
- •Подтипы и супертипы.
- •Получение реляционной схемы из er-диаграммы.
- •Пример разработки простой er-модели.
- •Проектирование баз данных.
- •Концептуальное и логическое проектирование бд.
- •Денормализация для оптимизации
- •Физическое проектирование бд. Типы данных.
- •Физическое проектирование бд. Индексы, кластеры.
- •Физическое проектирование бд. Временные данные.
- •Физическое проектирование бд. Хранение объектов данных.
- •Оптимизация запросов, основные понятия.
- •Синтаксическая оптимизация
- •Оптимизация, основанная на правилах
- •Оптимизация, основанная на вычислении стоимости
- •Последовательность шагов оптимизации запросов
- •Физические операции манипулирования данными.
- •Анализ запросов с целью повышения скорости их выполнения
- •Использование базовых переменных, понятие курсора
- •Базовая переменная sqlstate.
- •Операции встроенного sql, не использующие курсоров.
- •Операции, использующие курсоры.
- •Операторы позиционного удаления и модификации данных.
- •1.Оператор позиционного удаления
- •2.Оператор позиционной модификации
- •Понятие, назначение и структура хранимых процедур.
- •Использование хранимых процедур.
- •Операторы окончания транзакции.
- •Встроенный sql в vba.
- •Уровни моделирования выделяемые при разработке базы данных.
- •Принципы проектирование реляционных баз данных
- •Критерии оценки качества логической модели данных. Адекватность базы данных предметной области
- •Назначение нормализации отношений.
- •Приведение к 5нф.
- •Этапы разработки проекта: стратегия и анализ.
- •Этапы проектирования.Стратегия.
- •Этап анализа.
- •Основные методологии структурного анализа.
- •Сильные и слабые сущности.
- •Некоторые принципы проверки качества и полноты информационной модели.
- •Методология idef1х.
- •Идентифицирующие и неидентифицирующие связи.
- •Мощность связи.
Уровни моделирования выделяемые при разработке базы данных.
При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД. Можно выделить следующие уровни:
1)Сама предметная область это часть реального мира, данные о которой мы хотим отразить в базе данных.
2)Модель предметной области Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п.
3)Логическая модель данных Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.
4)Физическая модель данных Физическая модель данных описывает данные средствами конкретной СУБД. решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных
5)Собственно база данных и приложения База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Например, можно выбирать различные типы компьютеров, менять количество процессоров, объем оперативной памяти, дисковые подсистемы и т.п.
Принципы проектирование реляционных баз данных
Проблема проектирования заключается в том, как в некоторой базе данных для заданного набора данных выбрать подходящую логическую структуру. Говоря другими словами, какие базовые отношения и с какими атрибутами следует задать.
Прежде всего заметим, что речь идет о логическом проектировании
Для нереляционных макетов редполагается сначала создать реляционный макет
Ключевым условием является также целостность данных.
При проектировании базы данных макет следует рассматривать независимо от приложения
при проектировании учитывать(Этапы разработки БД, Нормализация, Функциональная зависимость,1НФ,2НФ,3НФ, Алгоритм нормализации,)
Для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Например, можно спроектировать несколько отношений с большим количеством атрибутов, или наоборот, разнести все атрибуты по большому числу мелких отношений
При проектировании базы данных прежде всего следует создать логический макет, а затем отобразить этот макет на некоторые физические структуры, поддерживаемые СУБД. Физический макет по определению является специфическим для данной СУБД. Логический макет, напротив, совершенно независим от СУБД и для его реализации могут быть использованы некоторые строгие теоретические принципы.
При проектировании базы данных макет следует рассматривать независимо от приложения. Иначе говоря, интерес представляют сами данные, а не то как они используются. Независимость от приложения желательна потому, что обычно в момент проектирования базы данных не известны все способы использования данных. Таким образом, необходимо, чтобы макет был стабильным, т.е. оставался работоспособным даже при возникновении в приложении новых требований к данным. Таким образом, нужно создать концептуальную схему, т.е. абстрактный логический макет, не зависящий от аппаратного обеспечения, операционной системы, СУБД, языка программирования, пользователя и т.д.