
- •1. Введение в курс
- •1.1. Введение в базы данных, содержание и цели курса, основные понятия
- •1.1.1. О чём этот курс
- •1.1.2. Основные определения
- •1.1.3. Способы организации знаний в базах знаний
- •1.1.4. Применение баз знаний
- •1.1.5. Виды моделей баз данных
- •2. Теория баз данных
- •2.1. История развития представлений о базах данных
- •2.1.1. Области применения вычислительной техники
- •2.1.2. Базы данных и информационные системы
- •2.1.3. История развития баз данных
- •2.1.4. Этапы развития баз данных
- •2.2. Основные термины и определения теории бд, виды бд и их отличия
- •2.2.1. Классификация бд
- •2.3. Реляционные бд, понятие сущности и связи
- •2.3.1. Общие определения
- •2.3.2. Факты о реляционной модели данных
- •2.3.3. Достоинства реляционной модели данных
- •2.3.4. Недостатки реляционной модели данных
- •2.3.5. Целостность бд
- •2.3.6. Отношения
- •2.3.7. Кортежи и отношения
- •2.3.8. Связи
- •2.3.9. Ключи отношений
- •2.3.10. Ссылочная целостность
- •2.3.11. Консистентность данных
- •2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных
- •2.4.1. Определения
- •2.4.2. Многоуровневая структура баз данных
- •2.4.3. Постоянная и переменная длина записи
- •2.4.4. Способы представления данных
- •2.4.5. Простейший вариант – плоский файл
- •2.4.6. Факторизация по значениям поля
- •2.4.7. Индексирование по полям
- •2.4.8. Комбинация простых представлений
- •2.4.9. Использование цепочек указателей
- •2.4.10. Многосписочные структуры
- •2.4.11. Инвертированная организация
- •2.4.12. Иерархическая организация
- •2.4.14. Промежуточный итог
- •2.4.15. Методы индексирования
- •2.4.16. Индексирование по комбинации полей
- •2.4.17. Селективный индекс
- •2.4.18. Индексация по методу сжатия
- •2.4.19. Фронтальное сжатие
- •2.4.20. Сжатие окончания
- •2.4.21. Символьные указатели
- •2.4.23. Индексно-последовательная организация
- •2.4.24. Сбалансированные деревья
- •2.4.25. Ведение файла
- •2.4.26. Хэширование
- •2.4.28. Итог
- •2.5. Алгоритмы хэширования
- •2.5.1. Введение
- •2.5.2. Хэширование
- •2.5.2. Факторы эффективности хэширования
- •2.5.3. Размер участка памяти
- •2.5.4. Плотность заполнения
- •2.5.5. Алгоритмы хэширования
- •2.5.6. Размещение записей в области переполнения
- •2.5.7. Итог
- •2.6. Механизмы обработки и хранения данных в бд
- •2.6.1. Введение
- •2.6.2. Механизмы обработки и хранения данных в ms-sql 6.0-6.5
- •2.6.3. Механизмы обработки и хранения данных в ms-sql 7.0 и более поздних версиях
- •2.6.4. Метод доступа isam
- •2.6.5. Метод доспута MyIsam
- •2.6.6. Метод доступа vsam
- •2.6.7. Включение записей в *sam-файлы
- •2.6.8. Размещение индексов для *sam-файлов
- •2.6.9. Метод доступа InnoDb
- •2.6.10. Итог
- •2.7. Физическое представление древовидных и сетевых структур
- •2.7.1. Введение
- •2.7.2. Древовидные структуры
- •2.7.3. Сетевые структуры
- •2.7.4. Итог
- •3.1.4. Стандарты разработки бд/субд
- •3.1.5. Sql и его стандарты
- •Часть 1 – sql/Структура (sql/Framework) – определяет общие требования соответствия и фундаментальные понятия sql.
- •3.1.6. Использование методологии idef1x
- •3.1.7. Пример логической и физической схемы в ErWin
- •3.1.8. Минимальный набор стандартных таблиц
- •3.1.8. Итог
- •3.2. Средства автоматизированного проектирования бд
- •3.2.1. Введение
- •3.2.2. Case-технологии
- •3.2.3. Достоинства case-технологий
- •3.2.4. Промежуточные выводы и определения
- •3.2.5. Методологии структурного моделирования
- •3.2.6. Методология sadt (idef0)
- •3.2.7. Методологии информационного моделирования
- •3.2.8. Нотация Чена
- •3.2.9. Нотация Мартина
- •3.2.10. Нотация ide1x
- •3.2.11. Нотация Баркера
- •3.2.12. Язык информационного моделирования
- •3.2.13. Case-средства
- •3.2.14. Процесс создания модели бд в ErWin
- •3.2.15. Процесс создания модели бд в Sparx ea
- •3.2.16. Итог
- •3.3. Особенности проектирования бд на логическом и физическом уровнях
- •3.3.1. Введение
- •3.3.2. Модель бд
- •3.3.4. Банки данных
- •3.3.5. Модели данных
- •3.3.6. Этапы проектирования бд
- •3.3.7. Проектирование бд: внешний уровень
- •3.3.8. Проектирование бд: инфологический уровень
- •3.3.9. Проектирование бд: даталогический уровень
- •3.3.10. Уровни sql
- •3.3.11. Проектирование бд: физический уровень
- •3.3.12. Итог
- •3.4. Прямое и обратное проектирование бд
- •3.4.1. Введение
- •3.4.2. Понятие нормализации
- •3.4.3. Требования нормализации
- •3.4.4. Примеры аномалий
- •3.4.5. Нормальные формы
- •3.4.6. Зависимости
- •3.4.6. Первая нормальная форма
- •3.4.7. Вторая нормальная форма
- •3.4.8. Третья нормальная форма
- •3.4.9. Нормальная форма Бойса-Кодда
- •3.4.10. Четвёртая нормальная форма
- •3.4.11. Пятая нормальная форма
- •3.4.12. Доменно-ключевая нормальная форма
- •3.4.13. Ещё раз, кратко, все нормальные формы
- •3.4.14. Ещё раз, кратко, в ErWin
- •3.5.2. Показатели качества бд
- •3.5.3. Итог
2.4.2. Многоуровневая структура баз данных
В наших дальнейших рассуждениях о БД и её уровнях мы будем отталкиваться от следующей схемы.
Рисунок 2.4.2.1 – Схема уровней БД
Начнём с упрощающего предположения: СУБД использует некоторый метод доступа для детального управления физическим доступом к БД.
Метод доступа реализуется набором подпрограмм, назначение которых состоит в том, чтобы скрыть все детали управления устройствами от СУБД и обеспечить СУБД интерфейс хранимых записей.
Т.о. «метод доступа» можно рассматривать как некий аналог «драйвера».
Существование более сложных методов доступа (например, добавляющих собственные вторичные индексы) никак не противоречит последующему обсуждению.
Интерфейс хранимых записей позволяет СУБД представлять структуры хранения в виде совокупности хранимых файлов, каждый из которых состоит из экземпляров одного типа хранимых записей.
СУБД известно, какие существуют хранимые файлы и для каждого из них:
структура соответствующих хранимых записей;
хранимые поля упорядочения (если таковые есть);
хранимые поля, которые могут использоваться как аргументы выборки при прямом доступе (если таковые есть).
Объектом, передаваемым через интерфейс хранимых записей, является один экземпляр хранимой записи.
СУБД неизвестно:
ничего о физических записях (блоках);
как хранимые поля связаны в хранимые записи (хотя это во многих случаях очевидно вследствие их физически последовательного размещения);
как именно осуществляется упорядочение (например, это может выполняться при помощи физического следования, по индексу или с помощью цепочки указателей);
как выполняется прямой доступ (т.е. посредством индекса, последовательного просмотра или хэш-адресации).
Вся эта информация используется методом доступа, а не непосредственно СУБД.
Предположим, что структура хранения включает хранимый файл PART, где каждый экземпляр хранимой записи состоит из номера детали (Р#), наименования детали (PNAME), цвета (COLOR) и веса (WEIGHT).
Часть определения структуры хранения в этом случае может иметь следующий вид:
STORED FILE PART {Р#, PNAME, COLOR, WEIGHT)
SEQUENCED ASCENDING P#
INDEXED Р#
Это определение говорит о следующем:
существует хранимый файл PART;
хранимая запись имеет конкретную структуру;
экземпляры хранимой записи упорядочены в возрастающем порядке значений Р# (механизм упорядочения здесь НЕ задаётся);
поле Р# индексировано, так что прямой доступ может выполняться по некоторому значению, соответствующему этому полю.
Сделаем ещё одно допущение: когда экземпляр новой хранимой записи впервые создаётся – метод доступа должен присвоить ему уникальный адрес хранимой записи.
Адрес позволяет различить экземпляры хранимых записей в базе данных.
Адрес может являться физическим адресом экземпляра в пределах «тома памяти» (совместно с идентификатором тома) или, наоборот, идентификатором соответствующего хранимого файла совместно со смещением в пределах этого файла.
Концепция адреса хранимой записи позволяет СУБД строить собственные механизмы доступа (индексы, цепочки указателей и т. д.) на основе тех, которые обеспечиваются методом доступа.