- •Шехтман в. Е.
- •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. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
1.4. Иерархическая модель данных
Представляет собой совокупность связанных элементов, образующих иерархическую структуру — перевернутый граф (дерево). К основным понятиям иерархической модели данных относятся уровень, элемент (или узел) и связь. Узлом называют совокупность атрибутов данных, описывающих некоторый объект. Каждый узел связан с одним узлом более высокого уровня и с любым количеством (в том числе и с нулем) узлов нижнего уровня. Исключением является узел самого высокого уровня, который не связан ни с одним узлом более высокого уровня. Этот узел называется корнем дерева. Подчинённые узлы располагаются на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется количеством корней деревьев. К каждой записи базы данных существует единственный путь от корневой записи. Примером иерархической модели данных может служить адрес. Действительно, на первом уровне (в корне дерева) лежит страна, на втором — регион, на третьем - город, на четвертом - улица, дом и квартира. Один и тот же город не может принадлежать двум странам или регионам. Другим примером иерархической модели является пространство доменных имен интернета – система DNS.
Рис. 1. Иерархическая модель данных. Структура организации.
1.5. Сетевая модель данных
Сетевая модель обобщает иерархическую, в ее основе лежат те же понятия, что и в основе иерархической модели данных - узел, уровень и связь. Однако существенным отличием сетевой модели данных является то, что узел может быть связан с любым другим узлом, в том числе лежащим на уровне, не связанном непосредственно с уровнем текущего узла. Простейшим примером сетевой модели данных может служить база данных, в которой хранится информация об участии специалистов некоторого учреждения в проектах, которыми занимается это учреждение. Каждый из специалистов может участвовать в нескольких проектах. В свою очередь, в одну проектную группу могут входить несколько специалистов.
Рис. 2. Сетевая модель данных. Принадлежность сотрудников проектам.
1.6. Инвертированные списки.
Организация доступа к данным на основе инвертированных списков используется и сейчас практически во всех современных реляционных СУБД, но в этих системах пользователи не имеют непосредственного доступа к внутренней структуре инвертированных списков, (см. Главу 11. Физическая организация баз данных) как это было на заре становления технологии баз данных. Более того, пользователь может и не догадываться о наличии такой структуры.
Инвертированные списки предназначены для быстрой адресации записей, обладающих теми или иными свойствами. Например, в базе данных о лечениях в поликлинике с помощью механизма инвертированных списков можно выбрать все амбулаторные карты, в которых есть записи об искомом лечении, дате лечения или специализации врача. Таким способом можно найти не одну запись, а сразу некоторое множество записей. Будем называть характеристику записи, одно значение которой присуще сразу нескольким записям, вторичным ключом.
Для быстрого выполнения поиска записей, удовлетворяющих некоторым критериям (без необходимости последовательного просмотра всех записей) и используют так называемые инвертированные списки. Каждый такой список состоит из пар
(значение поля;
значение адреса записи или уникального идентификатора записи)
Список таких пар упорядочен по значению поля.
Пусть, например, файл данных состоит из записей с тремя атрибутами: № амбулаторной карты пациента, дата лечения в поликлинике, специализация врача. Предполагаем, что атрибут № амбулаторной карты позволяет вычислить местонахождение всей совокупности данных, входящих в амбулаторную карту, во внешней памяти. Возьмем для простоты лишь 12 записей.
№ амбулаторной карты |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
Дата лечения |
11.10 |
01.10 |
10.10 |
11.10 |
08.10 |
30.09 |
11.10 |
10.10 |
11.10 |
07.10 |
05.10 |
07.10 |
Специализ. врача |
Терапевт |
Невролог |
Кардиолог |
Терапевт |
Терапевт |
Терапевт |
Кардиолог |
Невролог |
Терапевт |
Терапевт |
Кардиолог |
Терапевт |
Таблица 1. Данные о лечениях.
Список, инвертированный по дате лечения:
Дата лечения |
30.09 |
01.10 |
05.10 |
07.10 |
08.10 |
10.10 |
11.10 |
№ амбулаторной карты |
6 |
2 |
11 |
10,12 |
5 |
3,8 |
1,4,7,9 |
Таблица 2. Список, инвертированный по дате лечения.
Список, инвертированный по специализации врача:
Специализация врача |
Кардиолог |
Невролог |
Терапевт |
№ амбулаторной карты |
3, 7, 11 |
2, 8 |
1, 4, 5, 6, 9, 10, 12 |
Таблица 3. Список, инвертированный по специализации врача.
Объединение инвертированных списков по всем вторичным ключам составляет так называемый (полностью) инвертированный файл. Имея такой файл, легко найти записи с данными значениями атрибутов. Например, в нашем случае специализации врача Кардиолог и одновременно дату лечения 11.10 имеет лишь амбулаторная карта №8. Если инвертированные списки не перекрывают все множество ключей, то говорят о частично инвертированном файле.
Как станет ясно из дальнейшего, база данных, организованная с помощью инвертированных списков, похожа на реляционную БД, но с тем отличием, что инвертированные файлы видны пользователям. При этом для каждого файла данных можно определить произвольное число ключей поиска, для которых строятся инвертированные списки. Эти списки автоматически поддерживаются системой, но явно видны пользователям.
Иерархическая и сетевая модели данных обладают определенными недостатками, затрудняющими обработку и доступ к данным, основными из которых являются:
Высокая логическая сложность работы с данными
Зависимость приложений от физической реализации базы данных
Наличие только навигационного метода доступа к данным. Это означает, что для осуществления запроса на выборку данных приходится организовывать в программе перебор запись за записью – нельзя выразить запрос в виде высокоуровнего выражения, осуществляющего обработку сразу множества записей.
По этим причинам такие модели данных в настоящее время применяются мало. Что касается инвертированных списков, то это скорее не модель данных, а механизм поиска. И этот механизм не утратил значения в наши дни – на нем основаны так называемые вторичные индексы (см. главу 11).
С течением времени упомянутые способы организации данных уступили своё место новой модели данных, получившей название реляционной.
