Основные понятия теории баз данных.

 

Вуз (Н_ВУЗ, …)

Служащий ( НОМ_СЛ,…, Н_ВУЗ)

Студент ( НОМ_СТ, …,Н_ВУЗ)

Вид_сп ( ВИД_СП,…, НОМ_ТРЕН )

Культивирует ( Н_ВУЗ, ВИД_СП,…)

Судья (НОМ_СУД,…)

Вуз_гость (Н_Г,…)

Вуз_хозяин (Н_Х,…)

Участвует (ВИД_СП , НОМ_СТ,…)

Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, …)

Тренер (НОМ_ТР,…, ВИД_СП)

 

7.  Затем дописываем в отношения  атрибуты которые оговаривались  в условии:

 

Вуз (Н_ВУЗ, Н_СТАД, ВМЕСТ, ЧИСЛО_СТ)

Служащий ( НОМ_СЛ, Н_ВУЗ, ФАМ, АДР, ДОМ_Т, РАБ_Т, ДОЛЖНОСТЬ)

Студент ( НОМ_СТ, Н_ВУЗ, ПОЛ, ДАТА_РОЖД, ФАМ, АДР_СТ, ДАТА_ПОСТ)

Вид_сп ( ВИД_СП, НОМ_ТРЕН )

Культивирует ( Н_ВУЗ, ВИД_СП)

Судья (НОМ_СУД,ФАМ_СУД, АДР_СУД, ДТЕЛ_СУД, ВИД_СП_СУД)

Вуз_гость (Н_Г)

Вуз_хозяин (Н_Х)

Участвует (ВИД_СП , НОМ_СТ)

Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, ДАТА_ВСТР, ВРЕМЯ_НАЧАЛА)

Тренер (НОМ_ТР, ВИД_СП)

 

Две таблицы ВУЗ Гость и ВУЗ  Хозяин, не содержат ни какой полезной информации. Это является следствием того, что в модели отсутствуют атрибуты, характерные только для команды хозяев, или только для команды гостей. Поэтому эти две таблицы можно исключить. Например если бы мы хотели бы считать расходы команд за матч они были бы различными. Команда гостей должна оплачивать свое проживание, а команда хозяев оплатить банкет после матча например. Тогда в этих двух таблицах хранилась бы дополнительная информация.

 

Все восемь оставшихся отношений находятся  в НФБК.

Рассмотрим вариант когда одну встречу могут судить несколько  судей одновременно, тогда верхняя часть рисунка 7.55 выглядела бы следующим образом:

 

Рис. 7.56 Диаграмма ER-типа для связи расписание, в случае если одну встречу судят несколько судей.

 

Встреча (ID_встреча, н_гость, н_хозяин, вид_сп, дата, время),

Судит (ID_встреча, ном_с).

 

8. Постреляционные базы данных

 

1. Ограничения реляционных баз данных.

 

Появление реляционных СУБД стало  важным шагом вперед по сравнению  с иерархическими и сетевыми СУБД, в этих системах стали использоваться непроцедурные языки манипулирования  данными и была достигнута значительная степень независимости данных от обрабатывающих программ. В то же время, выяснился ряд недостатков реляционных систем. Реляционная модель ограничена в представлении данных:

Они идеально походят для таких  традиционных приложений, как системы резервирования билетов или мест в гостиницах, а также банковских систем, но их применение в системах автоматизации проектирования, интеллектуальных системах обучения и других системах, основанных на знаниях, часто является затруднительным.

Это прежде всего связано с примитивностью структур данных, лежащих в основе реляционной модели данных. Плоские  нормализованные отношения универсальны и теоретически достаточны для представления  данных любой предметной области. Однако в нетрадиционных приложениях в базе данных появляются сотни, если не тысячи таблиц, над которыми постоянно выполняются дорогостоящие операции соединения, необходимые для воссоздания сложных структур данных, присущих предметной области.

Другим серьезным ограничением реляционных систем являются их относительно слабые возможности по части представления семантики приложения. Самое большее, что обеспечивают реляционные СУБД,- это возможность формулирования и поддержки ограничений целостности данных.

Недостатки реляционных баз данных

 

• Реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц).
• По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения. Однако, в таких приложениях как САПР (системы автоматизированного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно-структурированными объектами.
• В том случае, когда сложный объект удается “уложить” в реляционную базу данных, его данные распределяются, как правило, по многим таблицам. Соответственно, извлечение каждого такого объекта требует выполнения многих операций соединения, что значительно замедляет работу СУБД.

 

Обойти эти ограничения можно  было бы в том случае, если бы реляционная  модель допускала:

 

• возможность определения новых типов данных
• определение наборов операций, связанных с данными определенного типа

 

Первые  работы, в которых отмечались эти  и ряд других недостатков, появились уже в начале 80-х годов. В следующих разделах мы рассмотрим некоторые способы преодоления указанных недостатков.

 

2. Системы управления базами данных следующего поколения

 

Кратко  рассмотрим основные направления исследований и разработок в области так называемых постреляционных систем, т.е. систем, относящихся к следующему поколению.

Хотя  отнесение СУБД к тому или иному  классу в настоящее время может  быть выполнено только условно, можно  отметить три направления в области  СУБД следующего поколения. Обозначим их именами наиболее характерных СУБД.

 

• Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД (если не считать коренной переделки системы управления внешней памятью).
• Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисных слоев системы.
• Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.

 

В целом можно сказать, что СУБД следующего поколения - это прямые наследники реляционных систем. Тем не менее, различные направления систем третьего поколения стоит рассмотреть отдельно, поскольку они обладают некоторыми разными характеристиками.

Абстрактные типы данных

 

Одной из наиболее известных СУБД третьего поколения является система 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, которая является простым расширением Си++, поддерживающим стабильное хранение данных во внешней памяти. Вместо готовой СУБД предоставляется набор “полуфабрикатов” с согласованными интерфейсами, из которых можно сгенерировать систему, максимально отвечающую потребностям приложения.

3. Ориентация на расширенную реляционную модель

 

Одним из основных положений реляционной  модели данных является требование нормализации отношений: поля кортежей могут содержать  лишь атомарные значения. Для традиционных приложений реляционных СУБД - банковских систем, систем резервирования и т.д. - это вовсе не ограничение, а даже преимущество, позволяющее проектировать экономные по памяти БД с предельно понятной структурой. Запросы с соединениями в таких системах сравнительно редки, для динамической поддержки целостности используются соответствующие средства SQL.

 

Однако с появлением эффективных  реляционных СУБД их стали пытаться использовать и в менее традиционных прикладных системах - САПР, системах искусственного интеллекта и т.д. Такие системы  обычно оперируют сложно структурированными объектами, для реконструкции которых из плоских таблиц реляционной БД приходится выполнять запросы, почти всегда требующие соединения отношений. Осознавая эти ограничения и недостатки реляционных систем, исследователи в области баз данных выполняют многочисленные проекты, основанные на идеях, выходящих за пределы реляционной модели данных.

Расширенная реляционная модель

 

Постреляционная модель данных представляет собой расширенную реляционную  модель, в которой отменено требование атомарности атрибутов. Поэтому постреляционную модель называют “не первой нормальной формой” (NF2) или “многомерной базой данных”. Она использует трехмерные структуры, позволяя хранить в полях таблицы другие таблицы. Тем самым расширяются возможности по описанию сложных объектов реального мира. В качестве языка запросов используется несколько расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения.  

9. Объектно-ориентированные СУБД.

 

 

Направление объектно-ориентированных  баз данных (ООБД) возникло сравнительно давно. Термин “объект” в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается “нечто, имеющее четко определенные границы”. Одна из причин появления объектно-ориентированных СУБД потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделенного сервера базы данных крайне редки.

Пример объектно-ориентированной СУБД - ObjectStore которая обеспечивает долговременное хранение в базе данных объектов, созданных программами на языках C++ и Java.

 

Первой формализованной и общепризнанной моделью данных была реляционная  модель Кодда. В этой модели, как и во всех следующих, выделялись три аспекта - структурный, целостный и манипуляционный. Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются с помощью средств логики первого порядка и, наконец, манипулирование данными осуществляется на основе реляционной алгебры или равносильного ей реляционного исчисления. Как отмечают многие исследователи, своим успехом реляционная модель данных во многом обязана тому, что опиралась на строгий математический аппарат теории множеств, отношений и логики первого порядка.

 

1. Объектно-ориентированная парадигма.

 

Любая модель данных должна включать три аспекта: структурный, целостный  и манипуляционный. Посмотрим, как  они реализуются на основе объектно-ориентированная парадигмы программирования:

Структура: