- •Введение
- •1. Информационная система (ис):
- •2.Типы и структуры данных
- •2.1.Основные типы данных
- •2.1.Методы доступа к данным
- •2.1.1.Методы поиска по дереву
- •2.2.2.Хеширование
- •3. Представление данных с помощью модели "сущность-связь".
- •3.1.Элементы модели
- •3.2.Диаграмма "сущность-связь".
- •4. Даталогические модели
- •4.1.Иерархическая модель данных
- •4.1.1.Структура данных
- •4.1.2.Операции над данными, определенные в иерархической модели:
- •4.1.3. Ограничения целостности
- •4.2. Сетевая модель данных
- •4.2.1. Структура данных
- •4.2.2.Операции над данными
- •4.3. Реляционная модель данных
- •1. Основные понятия
- •4.3.1. Структура данных
- •4.3.2. Фундаментальные свойства отношений
- •4.3.2.1. Отсутствие кортежей-дубликатов
- •4.3.2.2. Отсутствие упорядоченности кортежей
- •4.3.2.3. Отсутствие упорядоченности атрибутов
- •4.3.2.4. Атомарность значений атрибутов
- •4.3.3.Свойства отношений.
- •4.3.4. Реляционная модель и модель сущность - связь
- •4.3.4.1. Преобразование er-модели в реляционную модель
- •5. Языки запросов к реляционным базам данных
- •5.1. Реляционная алгебра
- •Общая интерпретация реляционных операций
- •Замкнутость реляционной алгебры и операция переименования
- •Правила записи выражений реляционной алгебры
- •5.2. Реляционное исчисление кортежей
- •5.3. Реляционное исчисление доменов
- •5.3. Ограничения реляционных баз данных
- •5.4. Постреляционные субд
- •6. Проектирование информационных систем и баз данных
- •Информационное моделирование процессов предметной области и применение потоковых диаграмм
- •7. Проектирование реляционных баз данных с использованием нормализации
- •7.1. Основные свойства нормальных форм
- •7.2. Функциональная зависимость
- •2. Ни для какого зависимость
- •7.2.1. Аксиомы функциональных зависимостей
- •7.2.2. Вычисление замыканий
- •7.2.3. Полная функциональная зависимость
- •7.2.4. Транзитивная функциональная зависимость
- •7.2.5.2. Вторая нормальная форма
- •7.2.5.3. Третья нормальная форма
- •7.2.5.4. Нормальная форма Бойса-Кодда
- •7.2.5.5. Четвертая нормальная форма
- •7.2.5.6. Пятая нормальная форма
- •7.2.6. Функциональные зависимости и проектирование базы данных.
- •Дополнительная литература
5.3. Реляционное исчисление доменов
В исчислении доменов областью определения переменных являются не отношения, а домены. Применительно к базе данных СОТРУДНИКИ-ОТДЕЛЫ можно говорить, например, о доменных переменных ИМЯ (значения - допустимые имена) или СОТР_НОМ (значения - допустимые номера сотрудников).
Основным формальным отличием исчисления доменов от исчисления кортежей является наличие дополнительного набора предикатов, позволяющих выражать так называемые условия членства. Если R - это n-арное отношение с атрибутами a1, a2, ..., an, то условие членства имеет вид
R (ai1:vi1, ai2:vi2, ..., aim:vim) (m <= n),
где vij - это либо литерально задаваемая константа, либо имя кортежной переменной. Условие членства принимает значение true в том и только в том случае, если в отношении R существует кортеж, содержащий указанные значения указанных атрибутов. Если vij - константа, то на атрибут aij задается жесткое условие, не зависящее от текущих значений доменных переменных; если же vij - имя доменной переменной, то условие членства может принимать разные значения при разных значениях этой переменной.
Во всех остальных отношениях формулы и выражения исчисления доменов выглядят похожими на формулы и выражения исчисления кортежей.
Для примера сформулируем с использованием исчисления доменов запрос "Выдать номера и имена сотрудников, не получающих минимальную заработную плату" (будем считать для простоты, что мы определили доменные переменные, имена которых совпадают с именами атрибутов отношения СОТРУДНИКИ, а в случае, когда требуется несколько доменных переменных, определенных на одном домене, мы будем добавлять в конце имени цифры):
Найти СОТР_НОМ, СОТР_ИМЯ WHERE EXISTS СОТР_ЗАРП1
(СОТРУДНИКИ (СОТР_ЗАРП1) AND
СОТРУДНИКИ (СОТР_НОМ, СОТР_ИМЯ, СОТР_ЗАРП) AND
СОТР_ЗАРП > СОТР_ЗАРП1)
Реляционное исчисление доменов является основой большинства языков запросов, основанных на использовании форм. В частности, на этом исчислении базировался известный язык Query-by-Example, который был первым (и наиболее интересным) языком в семействе языков, основанных на табличных формах.
5.3. Ограничения реляционных баз данных
Появление реляционных СУБД стало важным шагом вперед по сравнению с иерархическими и сетевыми СУБД, в этих системах стали использоваться непроцедурные языки манипулирования данными и была достигнута значительная степень независимости данных от обрабатывающих программ. В то же время, выяснился ряд недостатков реляционных систем. Во-первых, сама реляционная модель ограничена в представлении данных:
Как мы уже видели, реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц). Все отношения принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их поддержку приходится осуществлять в рамках конкретной прикладной программы.
По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения. Однако, в таких приложениях как САПР (системы автоматизированного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно - структурированными объектами.
Пример: Пусть нам необходимо создать базу данных земельных участков. Каждый участок задается координатами узлов ломаной линии, ограничивающей его по периметру. В этом случае спроектировать реляционную таблицу невозможно, т.к. заранее не известно количество узлов для всех участков. Также невозможно написать общие процедуры (вычисление площади, нахождение пересечения и т.д.) для всех случаев.
Кроме того, даже в том случае, когда сложный объект удается "уложить" в реляционную базу данных, его данные распределяются, как правило, по многим таблицам. Соответственно, извлечение каждого такого объекта требует выполнения многих операций соединения (join), что значительно замедляет работу СУБД. Обойти это и предыдущее ограничения можно было бы в том случае, если бы реляционная модель допускала
возможность определения новых типов данных
определение наборов операций, связанных с данными определенного типа
Во-вторых, имеются определенные недостатки и в реализации тех возможностей, которые прямо не предусматриваются реляционной моделью, но стали непременным атрибутом всех современных СУБД:
Цикл существования реляционной базы данных состоит в переходе от одного целостного состояния к другому. Однако, нельзя избежать такой ситуации, когда пользователь вводит данные, формально удовлетворяющие ограничениям целостности, но не соответствующие реальному состоянию предметной области. В этом случае предыдущее "истинное" значение данных будет утеряно.
Реляционная СУБД выполняет над данными не только те действия, которые задает пользователь, но и дополнительные операции в соответствии с правилами, заложенными в базу данных. Этот механизм реализуется с помощью триггеров, однако аппарат триггеров весьма сложен в отладке и полностью не реализован ни в одной системе.