- •1 Основные понятия и определения
- •1.1Информационные системы и банки данных
- •1.2Назначение и основные компоненты банка данных
- •1.3Трех уровневая архитектура абстракций базы данных.
- •1.4Физическая и логическая независимость данных
- •1.5Администратор базы данных
- •1.6Системы управления базами данных
- •1.7Схема обмена данными при работе с базой данных
- •1.8Локальные информационные системы
- •1.9Информационные системы в сетях
- •2Модели данных концептуального уровня
- •2.1Иерархическая модель данных
- •2.2Сетевая модель
- •2.3Реляционная модель
- •2.4Постреляционная модель
- •2.5Многомерная модель
- •2.6Объектно-ориентированная модель
- •3Физические модели баз данных
- •3.1Файловые структуры, используемые в базах данных
- •3.2 Хешированные файлы
- •3.2.1Стратегия разрешения коллизий с областью переполнения
- •3.2.2Организация стратегии свободного замещения
- •3.3Индексные файлы
- •3.3.1Файлы с плотным индексом, или индексно-прямые файлы
- •3.3.2Файлы с неплотным индексом, или индексно-последовательные файлы
- •3.3.3Организация индексов в виде b-tree (в-деревьев)
- •3.4Моделирование отношений «один-ко-многим» на файловых структурах
- •3.5Инвертированные списки
- •3.6Модели бесфайловой организации данных
- •4Реляционная модель данных
- •4.1Основные определения
- •4.2Соглашения об отношениях в реляционных системах
- •4.3Классы отношений
- •4.3.1Классы отношений с точки зрения способов создания и хранения
- •4.3.2Классификация отношений с точки зрения их содержания
- •4.4Операции реляционной алгебры
- •4.4.1Основные понятия
- •4.4.2Базовые теоретико-множественные операции
- •4.4.3Специальные операции реляционной алгебры
- •4.4.4Связи между отношениями (таблицами)
- •4.5Реляционное исчисление
- •4.6Язык запросов по образцу qbe
- •4.7Структурированный язык запросов sql
- •4.7.1История развития sql
- •4.7.2Общая характеристика языка
- •4.7.3Структура sql
- •4.7.4Оператор выбора select
- •4.7.5Применение агрегатных функций и группировки
- •4.7.6Раздел order by и ключевое слово top
- •4.7.7Вложенные запросы
- •4.7.8Внутренние и внешние объединения
- •4.7.9Перекрестные запросы
- •4.7.10Операторы манипулирования данными
- •4.7.11Запросы на создание таблиц
- •4.7.12Использование языка определения данных
- •4.8Правила Кодда (требования к реляционным бд)
- •5Проектирование баз данных
- •5.1Этапы проектирования бд
- •5.2Проблемы проектирования реляционных баз данных
- •5.3Нормализация отношений
- •5.4Метод сущность-связь
- •5.5Средства автоматизации проектирования
- •5.5.1Основные определения
- •5.5.2Модели жизненного цикла
- •5.5.3Модели структурного проектирования
- •5.5.4Объектно-ориентированные модели
- •5.5.5 Классификация case-средств
- •6Защита информации в базах данных
- •6.1Общие подходы к обеспечению безопасности данных
- •6.2Назначение и проверка полномочий, проверка подлинности
- •6.3Средства защиты базы данных
- •7Базы данных в сетях
- •7.1Организация базы данных в локальной сети
- •7.2Модели архитектуры клиент-сервер
- •7.3Управление распределенными данными
- •8История развития баз данных
4.8Правила Кодда (требования к реляционным бд)
Явное представление данных. Все данные должны быть представлены явно и их значения не должны рассчитываться косвенными алгоритмами (исключение – однозначные отображения). Пример: если в отношении явно не указан пол студента, то его нельзя получать из фамилии, т.к. различные алгоритмы интерпретации фамилии в различных приложениях могут вызвать противоречия (нарушить целостность) в БД.
Гарантированный доступ к данным. Вся информация в БД должна быть доступной для приложения. Получение доступа к любому значению в РБД выполняется при указании:
имени отношения;
указателя на кортеж;
имени атрибута.
То есть, кортеж ( имя_отношения, ключ, атрибут), полностью определяет доступ к значению атрибута в отношении.
Полная обработка неопределенных значений. Неопределенные значения атрибутов, отличные от любого определенного значения, должны поддерживаться для всех типов данных при выполнении всех операций.
Доступ к базе данных в терминах реляционной модели. Описание БД (перечень отношений, определения схем отношений и ключей, статистическая информация и т.д.) должно быть выполнено на реляционном языке. Пользователь должен иметь доступ к этой информации с помощью реляционного языка. Т.е. должна быть реализована возможность администрирования баз данных независимо от приложений.
Полнота подмножества реляционного языка. Реляционная схема может поддерживать несколько языков, по крайней мере, язык DDL и DML. Однако хотя бы один из языков должен иметь синтаксис предложений, поддерживающий следующие понятия:
определение данных (отношения, атрибуты, домены, ключи, ограничения целостности);
определение виртуальных (мнимых) отношений образованных с помощью реляционных выражений на основе одного или нескольких отношений. Виртуальные отношения называются представлениями. Следует различать термин «представление» (пользователя), как модель предметной области с точки зрения отдельного пользователя, и «представление», как конструкцию реляционного языка. При этом «представление» пользователя часто реализуется с помощью реляционных конструкций «представление»;
манипулирование данными (интерактивное или программное);
контроль при всех операциях описанных ограничений целостности;
поддержка только санкционированного доступа к БД;
управление транзакциями (начало транзакции, фиксация выполнения, отказ от выполнения).
Обновляемость представлений. Все представления (виртуальные отношения) должны автоматически обновляться при модификации данных в базовых отношениях.
Наличие высокоуровнего языка манипулирования данными. Операции вставки, обновления и удаления должны применяться к отношению в целом: обеспечивая контроль над целостностью базы данных при модификации отношений при выполнении вставки над отношением в целом легко проверить уникальность первичного ключа, ограничения на значения и пр.
Физическая независимость данных. Прикладные программы не должны зависеть от используемых способов хранения данных на носителях информации и методов доступа к ним. Физически независимые обеспечивает работоспособность приложений при изменении расположения данных в сети.
Логическая независимость данных. Прикладные программы не должны зависеть от реализации любого из используемых представлений (виртуальных отношений). Определив виртуальные отношение в рамках БД, можно разрабатывать приложения, использующие это отношение, не беспокоясь о том, что структура БД изменится, и виртуальные отношение будет строиться на основе других реляционных выражений.
Независимость контроля целостности. Все ограничения целостности и внешнее представления (виртуальные отношения, отчеты) должны определяться не в приложениях, а должны быть определены с помощью языка определения данных и сохранения в каталоге (словаре) базы данных.
Дистрибутивная независимость. Реляционная система должна быть распространяема и переносима. Создание разнородных компьютерных систем требует обеспечения доступа к базам данных в различных OS и на различных платформах. Дистрибутивная независимость предполагает полную реализацию СУБД для различных платформ или реализацию коммуникационных блоков в составе СУБД, позволяющих обмениваться данными различным СУБД.
Согласования языковых уровней. Если реляционная система имеет низкоуровневый язык доступа (элемент доступа – запись) и высокоуровневый язык доступ (элемент доступа – отношения). То выполнение низкоуровневых команд должно производиться с контролем целостности, так же как и при высокоуровневых командах.