- •Предметная область. Интеграция данных. Достоинства. Проблемы.
- •Интеграция данных Достоинства интеграции данных
- •Проблемы, связанные с интеграцией данных
- •2. Функции администратора базы данных.
- •Защита данных от разрушения при сбоях оборудования.
- •Защита от некорректных обновлений.
- •Защита данных от несанкционированного доступа.
- •Обеспечение коллективного доступа к данным.
- •Пользователи информационной системы
- •Уровни представления информационной системы.
- •Начальный уровень
- •Инфологический уровень
- •Концептуальный уровень
- •Внутренний уровень
- •Структура данных сетевой модели
- •Способы упорядочения подчиненных записей
- •Режим включения подчиненных записей
- •Режим исключения подчиненных записей.
- •Операции над данными в сетевой модели.
- •Ограничения целостности в сетевой модели.
- •4.. Иерархические базы данных.
- •Структура данных иерархической модели
- •Операции над данными в иерархической модели
- •Ограничения целостности в иерархической модели.
- •5 Реляционные базы данных.
- •6… Цели проектирования баз данных
- •Универсальные отношения
- •7..Проблемы, связанные с использованием единственного отношения
- •Проблема вставки.
- •Проблема обновления.
- •Проблема удаления.
- •Функциональные зависимости
- •8..Нормальные формы отношений Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Третья усиленная форма или нормальная форма Бойса–Кодда (нфбк)
- •Декомпозиция отношений
- •9..Избыточные функциональные зависимости. Правила вывода
- •Правило 1. Транзитивные зависимости
- •Правило 2. Корректные, но избыточные зависимости
- •Правило 3. Объединение функциональных зависимостей
- •Правило 4. Декомпозиция функциональных зависимостей
- •Правило 5. Псевдотранзитивность
- •Пример удаления избыточных зависимостей с помощью правил вывода
- •Общая схема проектирования баз данных методом декомпозиции
- •10.Семантическое моделирование или проектирования баз данных методом “Сущность-связь”
- •Сущности и связи
- •Диаграмма еr–экземпляров:
- •Диаграмма er–типа:
- •Терминология метода “Сущность-связь”
- •11.. Степень связи
- •Класс принадлежности сущности
- •Примеры диаграмм er-типа связей степени 1:1.
- •Примеры диаграмм er-типа связей степени 1:n и n:1
- •Примеры диаграмм er-типа связей степени m:n
- •Порядок или мерность связи
- •12.. Бинарные связи со степенью связи 1: 1
- •Правило 1.
- •Правило 2.
- •Правило 3.
- •Бинарные связи со степенью связи 1: n
- •Правило 4.
- •Правило 5.
- •13.. Бинарные связи степени m:n.
- •Правило 6.
- •Пример проектирования с использованием связей степенью м:n
- •Связи более высокого порядка
- •Правило 7
- •Пример проектирования с использованием связей более высокого порядка
- •Использование ролей
- •Правило 8
- •Пример проектирования с использованием ролей
- •14..Ограничения реляционных баз данных.
- •Недостатки реляционных баз данных
- •Системы управления базами данных следующего поколения
- •Абстрактные типы данных
- •Генерация систем баз данных, ориентированных на приложения
- •Ориентация на расширенную реляционную модель
- •Расширенная реляционная модель
- •15.. Объектно-ориентированные субд.
- •Объектно-ориентированная парадигма.
- •Недостатки объектно-ориентированных баз данных:
- •Стандарт odmg.
- •Объектная модель
- •Язык описания объектов
- •Язык объектных запросов
- •Связывание с оо-языками
- •Объектные расширения реляционных субд. Язык sql-3.
Абстрактные типы данных
Одной из наиболее известных СУБД третьего поколения является система Postgres, а создатель этой системы М.Стоунбрекер. В Postgres реализованы многие интересные средства: поддерживается темпоральная модель хранения и доступа к данным (см. ниже) и в связи с этим абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивается мощный механизм ограничений целостности; поддерживаются ненормализованные отношения (работа в этом направлении началась еще в среде Ingres).
Одно свойство системы Postgres сближает ее со свойствами объектно-ориентированных СУБД. В Postgres допускается хранение в полях отношений данных абстрактных, определяемых пользователями типов. Это обеспечивает возможность внедрения поведенческого аспекта в БД, т.е. решает ту же задачу, что и ООБД, хотя, конечно, семантические возможности модели данных Postgres существенно слабее, чем у объектно-ориентированных моделей данных. Основная разница состоит в том, что системы класса Postgres не предполагают наличия языка программирования, одинаково понимаемого как внешней системой программирования, так и системой управления базами данных. Если с использованием такой системы программирования определяются типы данных, хранящихся в базе данных, то СУБД оказывается не в состоянии контролировать безопасность этих определений, т.е. то отсутствует гарантия, что при выполнении процедур абстрактных типов данных не будет разрушена сама база данных.
Заметим, что в середине 1995 г. компания Sun Microsystems объявила о выпуске нового продукта - языка и семейства интерпретаторов под названием Java. Язык Java является расширенным подмножеством языка Си++. Основные изменения касаются того, что язык является пооператорно интерпретируемым (в стиле языка Бейсик), а программы, написанные на языке Java, гарантированно безопасны (в частности, при выполнении любой программы не может быть поврежден интерпретатор). Для этого, в частности, из языка удалена арифметика над указателями. В то же время Java остается мощным объектно-ориентированным языком, включающим развитые средства определения абстрактных типов данных. Компания Sun продвигает язык Java с целью расширения возможностей службы Всемирной Паутины (World Wide Web) Internet (основная идея состоит в том, что из сервера WWW в клиенты передаются не данные, а объекты, методы которых запрограммированы на языке Java и интерпретируются на стороне клиента; этот подход, в частности, решает проблему нестандартизованного представления мультимедийной информации). Однако, интерпретируемый и безопасный язык типа Java может быть успешно применен и в системах баз данных, допускающих хранение данных с типами, определенными пользователями.
Генерация систем баз данных, ориентированных на приложения
Идея очень проста: никогда не станет возможно создать универсальную систему управления базами данных, которая будет достаточна и не избыточна для применения в любом приложении. Например, если посмотреть на использование универсальных коммерческих СУБД (например, Oracle или Informix) в российской действительности, то можно легко увидеть, что по крайней мере в 90% случаев применяется не более чем 30% возможностей системы. Тем не менее, приложение несет всю тяжесть поддерживающей его СУБД, рассчитанной на использование в наиболее общих случаях.
Поэтому очень заманчиво производить не законченные универсальные СУБД, а нечто вроде компиляторов компиляторов (сompiler compiler), позволяющих собрать систему баз данных, ориентированную на конкретное приложение (или класс приложений). Желательно уметь генерировать систему баз данных, возможности (и соответствующие накладные расходы) которой в достаточной степени соответствуют потребностям приложения. На сегодняшний день на коммерческом рынке такие “генерационные” системы отсутствуют (например, при выборе сервера системы Oracle вы не можете отказаться от каких-либо ненужных для вашего приложения его свойств или потребовать наличия некоторых дополнительных свойств). Однако существуют как минимум два экспериментальных прототипа - Genesis и Exodus.
Обе эти генерационные системы основаны прежде всего на принципах модульности и точного соблюдения установленных интерфейсов. По сути дела, системы состоят из минимального ядра (развитой файловой системы в случае Exodus) и технологического механизма программирования дополнительных модулей. В проекте Exodus этот механизм основывается на системе программирования E, которая является простым расширением Си++, поддерживающим стабильное хранение данных во внешней памяти. Вместо готовой СУБД предоставляется набор “полуфабрикатов” с согласованными интерфейсами, из которых можно сгенерировать систему, максимально отвечающую потребностям приложения.