- •1. Понятие и принципы построения баз данных.
- •2. Реляционная модель. Три аспекта модели. Основные понятия, лежащие в основе реляционной модели
- •4) Виды моделей данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •3) Основные понятия реляционных баз данных
- •3.2.1. Тип данных
- •3.2.2. Домен
- •3.2.3. Заголовок отношения, кортеж, тело отношения, значение отношения, переменная отношения
- •3.2.4. Первичный ключ и интуитивная интерпретация реляционных понятий
- •3) Отношения. Переменные-отношения. Смысл отношений, свойства отношений. Домены.
- •4) Ключи переменных-отношений. Виды ключей.
- •5) Трехуровневая архитектура базы данных. Внешний, концептуальный и внутренний уровни.
- •6) Независимость данных.
- •7) Назначение и функции субд.
- •8) Реляционная алгебра – реляционный язык обработки данных.
- •9) Традиционные и специальные операции реляционной алгебры: объединение, пересечение, вычитание, декартово произведение, проекция, выборка. О соединение, естественное соединение, деление.
- •1.3.2 Пересечение
- •1.3.3 Вычитание
- •1.3.4 Произведение
- •10) Понятие функциональной зависимости для отношения. Основные определения. Способ определения ф.З. Тривиальные и нетривиальные зависимости.
- •11) Замыкание множества зависимостей. Аксиомы Армстронга.
- •12) Нормализация. Первая, вторая и третья нормальные формы отношения
- •1Нф (Первая Нормальная Форма)
- •Аномалии обновления
- •Аномалии вставки (insert)
- •Аномалии обновления (update)
- •Аномалии удаления (delete)
- •Функциональные зависимости
- •Вторая нормальная форма
- •Анализ декомпозированных отношений
- •Оставшиеся аномалии вставки (insert)
- •Оставшиеся аномалии обновления (update)
- •Оставшиеся аномалии удаления (delete)
- •Третья нормальная форма
- •12) Концептуальные модели данных. Модель «сущность-связь». Сущности, атрибуты, связи. Сущности-связи и мощности связей. Примеры.
- •Основные понятия er-модели
- •Инструкция select
- •Синтаксис
- •Замечания
- •Предложение from
- •Синтаксис
- •Замечания
- •Предложение where
- •Синтаксис
- •Замечания
- •Предикат like
- •2.3.4.2.1 Предикат сравнения
- •2.3.4.2.2 Предикат between
- •2.3.4.2.3 Предикат in
- •Предикат exists
- •Предложение having
- •Синтаксис
- •Замечания
- •Предикаты all, distinct, distinctrow, top
- •Синтаксис
- •14) Определение базы данных на sql (операторы определения и манипулирования данными).
- •15) Понятие целостности. Классификация ограниченной целостности базы данных.
- •16) Представления. Создание и использование представлений. Создание запросов к представлению.
- •17. Хранимые процедуры
- •18. Триггеры
- •19. Транзакция. Acid – свойства транзакций. Уровни изоляции транзакций.
- •Serializable (упорядочиваемость)
- •Repeatable read (повторяемость чтения)
- •Read committed (чтение фиксированных данных)
- •Read uncommitted (чтение незафиксированных данных)
- •Проблемы параллельного доступа с использованием транзакций
- •20. Защита данных. Средства защиты данных языка sql.
- •21. Понятие предметной области. Определение сущностей, связей и их свойств.
- •22. Проектирование реляционной базы данных. Определение состава таблиц
Аномалии обновления
Даже одного взгляда на таблицу отношения СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ достаточно, чтобы увидеть, что данные хранятся в ней с большой избыточностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования проектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга данные - и данные о сотрудниках, и об отделах, и о проектах, и о работах по проектам. Пока никаких действий с отношением не производится, это не страшно. Но как только состояние предметной области изменяется, то, при попытках соответствующим образом изменить состояние базы данных, возникает большое количество проблем.
Исторически эти проблемы получили название аномалии обновления. Попытки дать строгое понятие аномалии в базе данных не являются вполне удовлетворительными [51, 7]. В данных работах аномалии определены как противоречие между моделью предметной области и физической моделью данных, поддерживаемых средствами конкретной СУБД. "Аномалии возникают в том случае, когда наши знания о предметной области оказываются, по каким-то причинам, невыразимыми в схеме БД или входящими в противоречие с ней" [7]. Мы придерживаемся другой точки зрения, заключающейся в том, что аномалий в смысле определений упомянутых авторов нет, а есть либо неадекватность модели данных предметной области, либо некоторые дополнительные трудности в реализации ограничений предметной области средствами СУБД. Более глубокое обсуждение проблемы строгого определения понятия аномалий выходит за пределы данной работы.
Таким образом, мы будем придерживаться интуитивного понятия аномалии как неадекватности модели данных предметной области, (что говорит на самом деле о том, что логическая модель данных попросту неверна!) или как необходимости дополнительных усилий для реализации всех ограничений определенных в предметной области (дополнительный программный код в виде триггеров или хранимых процедур).
Т.к. аномалии проявляют себя при выполнении операций, изменяющих состояние базы данных, то различают следующие виды аномалий:
Аномалии вставки (INSERT)
Аномалии обновления (UPDATE)
Аномалии удаления (DELETE)
В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести примеры следующих аномалий:
Аномалии вставки (insert)
В отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о сотруднике, который пока не участвует ни в одном проекте. Действительно, если, например, во втором отделе появляется новый сотрудник, скажем, Пушников, и он пока не участвует ни в одном проекте, то мы должны вставить в отношение кортеж (4, Пушников, 2, 33-22-11, null, null, null). Это сделать невозможно, т.к. атрибут Н_ПРО(номер проекта) входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.
Точно также нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.
Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).
Вывод - логическая модель данных неадекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.