- •Оглавление
- •1. Введение. Представление данных в памяти компьютера 3
- •2. Модели представления данных 43
- •3. Проектирование реляционных бд 83
- •4 Реляционная алгебра 114
- •5. Case – технологии 127
- •6. Организация доступа прикладной программы 178
- •1. Введение. Представление данных в памяти компьютера
- •1.1 Предмет дисциплины и ее задачи
- •1.2 Основные понятия
- •1.3 Файловые системы, как первый шаг к субд
- •1.4 Структурная схема субд и основные функции
- •1.5 Преимущества и недостатки субд по сравнению с файловыми системами
- •1.6 Организация внешней памяти реляционной субд
- •1.7 Типы и структуры данных
- •1.8 Типы и структуры данных, применяемые в реляционных бд
- •1.9 Типы и структуры данных, применяемые в объектно-реляционных бд
- •1.10 Понятие модели данных
- •2. Модели представления данных
- •2.1 Иерархическая модель данных
- •2.2 Сетевая модель данных
- •2.3 Реляционная модель данных
- •2.4 Свойства отношений. Отличие отношений от таблиц.
- •2.5 Понятие целостности данных
- •2.6 Ограничения реляционных баз данных
- •2.7 Суть постреляционного объектно-ориентированного подхода
- •2.8 Объектно-ориентированные субд и стандарт odmg
- •2.9 Объектно-реляционные субд
- •2.10 No sql бд и субд
- •1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.
- •6. Распределенные системы
- •3. Проектирование реляционных бд
- •3.1 Этапы разработки базы данных
- •3.2 Критерии оценки качества логической модели данных
- •3.3 Проектирование баз данных на основе нормализации отношений
- •3.4 Первая нормальная форма
- •3.5 Аномалии обновления
- •3.6 Функциональные зависимости
- •3.7 Вторая нормальная форма
- •3.8 Третья нормальная форма
- •3.9 Алгоритм нормализации (приведение к 3nf)
- •3.10 Oltp и olap-системы
- •3.11 Корректность процедуры нормализации. Теорема Хеза
- •3.12 Нормальная Форма Бойса-Кодда (nfbk)
- •3.13 Четвертая Нормальная Форма
- •3.14 Пятая Нормальная Форма
- •3.15 Продолжение алгоритма нормализации (приведение к 5 nf)
- •4 Реляционная алгебра
- •4.1 Операции над отношениями: общие сведения
- •4.2 Синтаксис операторов реляционной алгебры
- •4.3 Оптимизация алгоритмов реализации запросов
- •5. Case – технологии
- •5.1 Общие вопросы проектирования ис, понятие case-технологии
- •5.2 Жизненный цикл по ис
- •5.3 Модели жизненного цикла по
- •5.4 Методология rad
- •5.5 Структурный подход к проектированию ис
- •5.6 Методология функционального моделирования sadt (idef0)
- •5.7 Моделирование потоков данных (методология Гейна-Сарсона)
- •5.8 Методы построения диаграмм «сущность-связь» (erd)
- •5.9 Моделирование данных case-методом Баркера
- •5.10 Методология idef1
- •6. Организация доступа прикладной программы к серверу базы данных
- •6.1 Общие сведения
- •6.2 Использование специализированных библиотек и встраиваемого sql
- •6.4 Odbc – открытый интерфейс к бд на платформе ms Windows
- •6.5 Jdbc - интерфейс к базам данных на платформе Java
- •6.6 Прикладные интерфейсы ole db и ado
- •Литература
2. Модели представления данных
2.1 Иерархическая модель данных
Первые иерархические и сетевые СУБД появились в начале 60-х годов. Причиной создания послужила необходимость управления миллионами записей, связанных друг с другом иерархическим образом, например, при информационной поддержке лунного проекта Аполлон. Cамая распространенная иерархическая СУБД - IMS (Information Management System) компании IBM. Первая версия системы появилась в 1968 году. Известны и другие иерархические системы: TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi - Access Retrieval System компании Control Data Corporation; System - 2000 разработки SAS-Institute [6].
Организация данных в СУБД иерархического типа определяется в терминах: атрибут, запись (группа), групповое отношение.
Атрибут (элемент данных) – наименьшая единица структуры иерархических данных. Обычно каждому элементу при описании БД присваивается уникальное имя. По этому имени к нему обращаются при обработке. Такой элемент данных также часто называют полем.
Запись – именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи – это конкретная запись с конкретными значениями атрибутов.
Групповое отношение – это иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения, предок) называется исходной записью, а дочерние записи (члены группового отношения, потомки) – подчиненными. Таким образом, иерархическая БД состоит из упорядоченного набора деревьев.
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей, начиная от корневой.
При графическом изображении (диаграмма Бахмана) групповые отношения изображают дугами ориентированного графа, а типы записей – вершинами.
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись. При удалении родительской записи автоматически удаляются все подчиненные.
Пример 1. Рассмотрим модель данных предприятия (рис. 5): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.
Поэтому, для ИС управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение для двух дочерних записей показано на рис. 5 а.
Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ (НОМЕР, ДАТА, СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. 5 б).
Рис. 5 – Иерархическая модель данных
На рис. 5 хорошо видны недостатки иерархических БД:
1) Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между ними.
2) Иерархическая модель реализует отношение “один ко многим” между исходной и дочерней записью, то есть одной родительской записи может соответствовать любое число дочерних. Допустим, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь “многие ко многим”). В этом случае в БД необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ – дочерней (рис. 5 в), что снова приведет к дублированию информации.
Операции над данными, определенные в иерархической модели:
ДОБАВИТЬ в БД новую запись. При этом для корневой записи обязательно формирование значения ключа.
ИЗМЕНИТЬ значение данных предварительно извлеченной записи. При этом ключевые данные не должны подвергаться изменениям.
УДАЛИТЬ некоторую запись и все подчиненные ей записи.
ИЗВЛЕЧЬ: корневую запись по ключевому значению, следующую запись (извлекается в порядке левостороннего обхода дерева), допускается также последовательный просмотр корневых записей и задание условий выборки.
Все операции изменения применяются только к одной "текущей" записи, которая предварительно извлечена из БД. Такой подход к манипулированию данными получил название "навигационного".
Для обеспечения целостности данных поддерживается только одно ограничение: целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка).
В остальном аппарат обеспечения целостности иерархической модели данных имеет существенные недостатки, так как не обеспечивает автоматическое поддержание соответствия парных записей, входящих в разные иерархии; не реализует явное разделение логических и физических характеристик модели; а непредвиденные запросы могут требовать реорганизации БД.