
- •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. Итог
3.1.5. Sql и его стандарты
Одним из основных преимуществ реляционного подхода к организации баз данных (БД) является то, что пользователи реляционных БД получают возможность эффективной работы в терминах простых и наглядных понятий таблиц, их строк и столбцов без потребности знания реальной организации данных во внешней памяти.
Реляционная модель данных, содержащая набор чётких предписаний к базовой организации любой реляционной системы управления базами данных (СУБД), позволяет пользователям работать в ненавигационной манере, т.е. для выборки информации из БД человек должен всего лишь указать список интересующих его таблиц и те условия, которым должны удовлетворять выбираемые данные.
СУБД скрывает от пользователя выполняемые ей просмотры таблиц, выполняя их наиболее эффективным образом.
Очень важная особенность реляционных систем состоит в том, что результатом выполнения любого запроса к таблицам БД является также таблица, которую можно сохранить в БД и/или по отношению к которой можно выполнять новые запросы.
Базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции.
В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL – Structured Query Language (теперь всё чаще название языка понимается как Standard Query Language).
До появления SQL в СУБД (независимо от того, на какой модели они основывались) приходилось поддерживать по крайней мере три языка, которые обычно имели мало общего:
язык определения данных (ЯОД), служащий для спецификации структур БД (обычно общую структуру БД называют схемой БД);
язык манипулирования данными (ЯМД), позволяющий создавать прикладные программы, взаимодействующие с БД;
язык администрирования БД (ЯАДБ), с помощью которого можно было выполнять служебные действия (например, изменять структуру БД или производить её настройку с целью повышения эффективности).
Кроме того, если требовалось предоставить пользователям СУБД интерактивный доступ к БД, приходилось вводить ещё один язык, операторы которого выполняются в диалоговом режиме. Язык SQL позволяет решать все эти задачи.
Следует отметить, что к достоинствам языка SQL относится наличие международных стандартов. Первый международный стандарт был принят в 1989 г., и соответствующая версия языка называется SQL-89.
Этот стандарт полностью поддерживается практически во всех современных коммерческих реляционных СУБД. Стандарт SQL-89 во многих частях имеет чрезвычайно общий характер и допускает очень широкое толкование. В этом стандарте полностью отсутствуют такие важные разделы, как манипулирование схемой БД и динамический SQL.
Наиболее важными достижениями стандарта SQL-89 являются:
чёткая стандартизация синтаксиса и семантики операторов выборки и манипулирования данными;
фиксация средств ограничения целостности БД, включающих возможности определения первичного и внешних ключей отношений и так называемых проверочных ограничений целостности, позволяющих сформулировать условие для каждой отдельной строки таблицы.
Средства определения внешних ключей позволяют легко формулировать требования так называемой целостности БД по ссылкам. Формулировка ограничений целостности на основе понятия внешнего ключа проста и понятна.
Осознавая неполноту стандарта SQL-89, на фоне завершения разработки этого стандарта специалисты различных фирм начали работу над стандартом SQL2. Эта работа также длилась несколько лет, было выпущено несколько проектов стандарта, пока, наконец, в марте 1992 г. был выработан окончательный проект стандарта (после чего стандарт и соответствующий язык стали называть SQL-92).
Этот стандарт существенно более полный и охватывает практически все необходимые для реализации аспекты:
манипулирование схемой БД;
управление транзакциями и сессиями (сессия – это последовательность транзакций, в пределах которой сохраняются временные отношения);
подключение к БД;
динамический SQL.
В стандарте представлены три уровня языка:
базовый;
промежуточный;
полный.
В течение нескольких лет после принятия стандарта производители СУБД, утверждавшие совместимость своих продуктов со стандартом, на самом деле в лучшем случае поддерживали промежуточный уровень языка SQL-92 (естественно, с собственными расширениями).
Только в последних выпусках СУБД ведущих производителей обеспечивается совместимость с полным вариантом языка.
Наконец, одновременно с завершением работ по определению стандарта SQL-92 была начата разработка стандарта SQL3.
Общей точкой зрения ведущих производителей СУБД является то, что будущие продукты, обладая более развитыми возможностями, должны быть совместимы с предыдущими выпусками.
Хотя многие разработчики и пользователи реляционных СУБД осознают наличие многих неустранимых недостатков языка SQL, от него теперь уже невозможно отказаться.
SQL3 (также известный как SQL99) состоит из пяти взаимосвязанных документов и предполагается, что в ближайшем будущем к ним могут быть добавлено еще несколько: