- •Шехтман в. Е.
- •1. Базы данных и модели данных
- •1.1. Введение.
- •1.2. Файлы операционной системы
- •1.3. Пример базы данных.
- •1.4. Иерархическая модель данных
- •1.5. Сетевая модель данных
- •1.6. Инвертированные списки.
- •2. Введение в реляционную модель данных.
- •1.7. Реляционная модель данных
- •3. Реляционная алгебра
- •3.1. Теоретико-множественные операции.
- •3.2. Специальные операции ra
- •4. Нормализация данных
- •4.1. Полная декомпозиция.
- •Магазин товар ндс
- •Товар ндс
- •Магазин ндс
- •Товар ндс
- •Магазин товар ндс
- •4.2. Проблема дублирования данных.
- •1 Глобус 33-33-33
- •2 Глобус 33-33-33
- •4 Океан 77-77-77
- •4.3. Висячие записи.
- •Поставщик Тел
- •4.4. Проблемы, возникающие из-за неудачной структуры данных.
- •4.5. Пятая нормальная форма (5нф).
- •4.6. Функциональная зависимость.
- •4.7. Связь между фз и полной декомпозицией отношения.
- •4.8. Первая нормальная форма (1нф).
- •4.9. Вторая нормальная форма (2нф).
- •4.10. Третья нормальная форма (3нф).
- •4.11. Нормальная форма Бойса-Кодда (нфбк).
- •4.12. Многозначная зависимость.
- •4.13. Четвертая нормальная форма (4нф).
- •4.14. Пример нормализации.
- •4.15. Резюме. Нормальные формы.
- •5. Инфологическое моделирование.
- •5.1. Сущность и набор сущностей
- •5.2. Связи между сущностями.
- •5.3. Рекурсивная связь. Роли.
- •5.4. Множественные связи.
- •5.5. Суперсущности и производные сущности
- •5.6. Слабые наборы сущностей
- •5.7. Борьба с избыточнотью
- •5.8. Преобразование инфологической модели в физическую модель.
- •5.9. Пример инфологического моделирования.
- •6. Язык sql
- •6.1. История sql.
- •6.2. Структура sql.
- •6.3. Язык запросов
- •6.4. Простые запросы на выборку данных.
- •6.5. Агрегатные (групповые) функции.
- •6.6. Вложенные запросы
- •6.7. Внешние объединения
- •6.8. Изменение данных
- •Insert into r1 (o, fio, d) values (5, ‘Иванов’, ’бд’)
- •7. Представления.
- •8. Определение схемы базы данных и ограничений целостности
- •9. Транзакции
- •9.1. Свойства транзакций
- •9.2. Надежное хранение данных
- •9.3. Параллельное выполнение транзакций
- •9.3.1. Коллизия “пропавшие изменения” - lost update problem
- •9.3.2. Коллизия “промежуточные данные” - dirty read
- •9.3.3. Коллизия “Несогласованные данные” - unrepeatable read, inconsistent analysis
- •9.3.4. Коллизия “фантом” - phantom
- •9.4. Уровни изолированности
- •9.5. Тупики
- •10. Ограничение прав доступа в целях обеспечения безопасности
- •11. Физическая организация баз данных
- •11.1. Организация размещения данных.
- •11.2. Организация индексов
- •11.2.1. Поиск в бд.
- •11.2.2. Плотный индекс (индексно-прямые файлы).
- •11.2.3. Неплотный индекс (индексно-последовательные файлы).
- •11.2.4. Сбалансированные деревья.
- •11.2.5. Инвертированные списки.
- •12. Архитектура субд. Методы оптимизации запросов.
- •Логические преобразования запросов.
- •Преобразования запросов с изменением порядка реляционных операций.
- •13. Аналитические системы.
- •Анализ данных.
- •Хранилища данных
- •Типы ошибок
- •Способы реализации olap.
- •Требования к средствам реализации систем оперативной и аналитической обработки данных
- •Многомерная модель данных.
- •Разработка данных
- •14. Загружаемые процедуры.
- •In pr double precision)
- •If eof then leave Cl end if;
- •Insert into providers(code, name)
- •Values (nr.Codec, ‘*** новый поставщик ***’);
- •15.4. Модель сервера приложений (трёхзвенная архитектура, “тонкий клиент”)
- •Список литературы
- •15. Модели совместного доступа к бд
- •15.1. Файл-серверная модель.
- •15.2. Модель клиент-сервер с бизнес-логикой на клиенте.
- •15.3. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
4. Нормализация данных
Прикладные и предметные базы данных.
Сбор требований о данных, которые следует хранить.
Цель проектирования оптимальной структуры БД:
устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте
уменьшение затрат на операции обновления избыточных копий
устранение избыточности (экономия памяти).
4.1. Полная декомпозиция.
Пусть S = (МАГАЗИН, ТОВАР, НДС):
Магазин товар ндс
ПРИВЕТ БАНАН 20
ПРИВЕТ КАПУСТА 10
РЯБИНКА АРБУЗ 20
РЯБИНКА КАПУСТА 10
S[МАГАЗИН, ТОВАР]:
МАГАЗИН ТОВАР
-
ПРИВЕТ
БАНАН
ПРИВЕТ
КАПУСТА
РЯБИНКА
АРБУЗ
РЯБИНКА
КАПУСТА
S[ТОВАР, НДС]:
Товар ндс
БАНАН 20
КАПУСТА 10
АРБУЗ 20
Можно убедиться, выполнив соответсвующие вычисления, что
S[МАГАЗИН, ТОВАР] join S[ТОВАР, НДС] = S
Введем определение:
Полная декомпозиция отношения – это совокупность произвольного числа его проекций, соединение которых идентично исходному отношению.
Поэтому совокупность проекций S[МАГАЗИН, ТОВАР] и S[ТОВАР, НДС] можно назвать полной декомпозицией.
Рассмотрим другие проекции того же отношения S:
S[МАГАЗИН, НДС]:
Магазин ндс
ПРИВЕТ 20
ПРИВЕТ 10
РЯБИНКА 20
РЯБИНКА 10
S[ТОВАР, НДС]:
Товар ндс
БАНАН 20
КАПУСТА 10
АРБУЗ 20
Выполнив необходимые вычисления, получим:
S[МАГАЗИН, НДС] join S[ТОВАР, НДС]:
Магазин товар ндс
ПРИВЕТ БАНАН 20
ПРИВЕТ АРБУЗ 20 Лишняя строка
ПРИВЕТ КАПУСТА 10
РЯБИНКА БАНАН 20
РЯБИНКА АРБУЗ 20
РЯБИНКА КАПУСТА 10
Следовательно
S[МАГАЗИН, НДС] join S[ТОВАР, НДС] <> S
т. е. данная совокупность проекций не образует полную декомпозицию!
4.2. Проблема дублирования данных.
Пусть P = (КодТовара, Поставщик, Тел)
При этом рассмотрим ситуацию, когда каждый вид товара поставляется только одной фирмой, все фирмы имеют разные названия:
КодТовара Поставщик Тел
1 Глобус 33-33-33
2 Глобус 33-33-33
3 МИР 99-99-99
4 Океан 77-77-77
5 МИР 99-99-99
В данном отношении поставщики и телефоны многократно дублируются.
Если взять проекцию P[Поставщик, Тел], то можно убедиться что в ней дублей нет:
Поставщик Тел
ГЛОБУС 33-33-33
МИР 99-99-99
ОКЕАН 77-77-77
Рассмотрим и проекцию P[КодТовара, Поставщик]:
КодТовара Поставщик
1 ГЛОБУС
2 ГЛОБУС
3 МИР
4 ОКЕАН
5 МИР
Попробуйте убедиться, что P[КодТовара, Поставщик] join P[Поставщик, Тел] = P – т. е. что эти две проекции образуют полную декомпозицию.
С другой стороны, если использовать проекцию P[КодТовара, Тел], то дублирования избежать не удастся:
КодТовара Тел
1 33-33-33
2 33-33-33
3 99-99-99
4 77-77-77
5 99-99-99
Иногда, заменив отношение его полной декомпозицией, можно избежать дублирования данных. Но в других случаях такая замена не удается. Очевидно, необходим критерий, позволяющий судить о целесообразности полной декомпозиции отношения. Заметим, что проекции P[Поставщик, Тел] и P[КодТовара, Поставщик] (образующие полную декомпозицию) не содержит общего ключа исходного отношения, в то время как проекции P[КодТовара, Тел] и P[КодТовара, Поставщик] (не образующие полную декомпозицию) обе содержат ключ исходного отношения – КодТовара.