Калабухов Е.В. Курс лекций по дисциплине Базы данных, знаний и экспертные системы

Подождите немного. Документ загружается.

Пример применения декомпозиции. Пусть дано отношение

F{S#,City,Status,P#,Qty}

и известны его функциональные зависимости:

•

Cit

→#,

•

Status

→#,

• StatusCit

→ ,

•

→#,#.

Первичный ключ отношения – S#, P#. Необходимо получить отношения в

3НФ.

Выполнение процесса по шагам:

1) 1НФ. Отношение F находится в 1НФ.

2) 2НФ. Атрибуты City и Status в отношении F частично зависят от

первичного ключа, поэтому выносятся из отношения F в новое отношение SF.

В SF для сохранения функциональных зависимостей копируется детерминант

S#, который становится первичным ключом отношения SF. В результате

преобразования в 2НФ получаем:

F{S#,P#,Qty}, первичный ключ – S#, P#;

SF{S#,City,Status}, первичный ключ – S#.

3) 3НФ. В отношении F нет транзитивных зависимостей, и значит, оно

находится в 3НФ. В отношении SF наблюдается транзитивная зависимость

Status

→# через атрибут City. Транзитивный атрибут Status выносится из

отношения SF в новое отношение SSF. В SSF для сохранения функциональных

зависимостей копируется детерминант City, который становится первичным

ключом отношения SSF. В результате преобразования в 3НФ получаем:

F{S#,P#,Qty}, первичный ключ – S#, P#;

SF{S#,City}, первичный ключ – S#;

SSF{City,Status}, первичный ключ – City.

Полученные отношения F, SF и SSF – результат выполнения

декомпозиции исходного отношения в 3НФ.

Суть процесса нормализации:

1) В нормализованных отношениях не разрешаются никакие

функциональные зависимости, кроме функциональных зависимостей вида

→ , где K – потенциальный ключ отношения R, а A – неключевой атрибут.

2) Если же отношение R имеет функциональные зависимости

→ , где

B не является потенциальным ключом, то в отношении R будет наблюдаться

избыточность данных.

Выполнение нормализации важно не только при первичном

проектировании реляционной БД, но также и при корректировке модели

данных в процессе эксплуатации БД для учета новых функциональных

зависимостей и устранения внесенных аномалий.

4.3.3.6. Недостатки и пути развития реляционной модели

4.3.3.6.1. Недостатки традиционных реляционных систем

Недостатки реляционных систем можно увидеть, проанализировав

программные приложения, связанные с базами данных.

Традиционными для уверенного использования реляционных СУБД

являются такие бизнес-приложения, как:

•

обработка заказов;

•

учет складских запасов;

•

банковское дело;

•

заказ билетов на транспорт (например, поезда и самолеты).

Однако существует ряд современных приложений, в которых

реляционные системы продемонстрировали свою неадекватность:

1) Автоматизированное проектирование (CAD) – компьютерные системы

проектирования сложных проектов – зданий, самолетов, микросхем и т.п. Такие

проекты имеют следующие особенности:

•

большое количество разных типов при небольшом количестве

экземпляров объектов, что формирует большое количество отношений и

сложно для обработки в РСУБД;

•

сложные проекты насчитывают миллионы элементов и связаны с

другими проектами;

• проект не является статичным, любые изменения должны своевременно

отражаться во всех представлениях проекта – перепроектирование БД на

лету часто неприемлемо для РСУБД;

•

обновление проекта в небольшой части затрагивает практически весь

проект;

•

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

требуется вести их учет, сравнение и внесение изменений.

•

в проекте могут участвовать одновременно сотни сотрудников,

работающих над разными частями и версиями – проблема

непротиворечивости и скоординированности действий.

2) Автоматизированное производство (CAM) – например, производство

автомобилей, химический синтез – проблемы обработки данных в реальном

времени, большой объем статистики, много операторов.

3) Автоматизированная разработка программного обеспечения (CASE) –

подобно CAD-проектам – коллективная разработка, много версий и т.п.

4) Офисные информационные системы, мультимедиа системы, цифровое

издательское дело – большой набор разнообразных данных произвольных

форматов (например, текстовых, видео, аудио, …) и необходимость

осмысленной навигации по данным, нестандартные операции с данными.

Несмотря на многие сильные стороны реляционной модели, такие как:

•

теоретическая обоснованность и опора на математику,

•

простота,

•

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

•

обеспечение независимости от данных,

• стандарт по обработке данных SQL,

РСУБД имеют и определенные недостатки:

•

слабое представление сущностей реального мира – процесс нормализации

приводит к созданию фрагментов объектов реального мира в БД, в

процессе обработки данных требуется большое число соединений;

•

семантическая перегрузка – все виды семантических данных

представляются в РСУБД только одной структурой – отношением, такое

представление в операциях частично теряет смысл данных;

•

слабая поддержка ограничений целостности и корпоративных

ограничений – современные РСУБД не поддерживают все возможности

реляционной модели данных (например, домены), из-за чего многие

правила целостности приходится встраивать в приложения, что

небезопасно; в реляционной модели вообще не предусмотрены

корпоративные правила целостности – только SQL или приложения;

•

однородная структура данных – с одной стороны таблица представлена

очень просто, что удобно для обработки (набор атомарных значений

ячеек), с другой стороны – нет возможности обрабатывать более сложные

структуры данных – их надо хранить неестественным образом; для

сложных BLOB-объектов есть только общие операции - нет доступа к

элементам объекта;

•

ограниченный набор операций – нет определения новых операций с

данными, например, в GIS-системах требуется обрабатывать векторные и

растровые понятия;

•

трудности организации рекурсивных запросов – большая вложенность

запросов на SQL2 не может быть реализована без дополнительных

операторов или языка программирования высокого уровня;

•

проблема рассогласования – преобразования данных между разными

языками (например, SQL->C->SQL) приводит к большим затратам

производительности (до 30%) и ресурсов;

•

жесткость структуры БД и трудности ее преобразования во время

эксплуатации;

•

слабый навигационный доступ – противоречит принципам реляционных

операций.

4.3.3.6.2. Объектно-реляционные СУБД

Разработка СУБД с использованием расширенной реляционной модели

данных или объектно-реляционной СУБД (ОРСУБД) относится к разработке

СУБД третьего поколения.

Разработка ОРСУБД (старое название - расширенная реляционная СУБД)

является ответом на развитие нереляционных СУБД третьего поколения,

которые захватывают новые области применения (например, WWW). Другая

сторона разработки ОРСУБД – множество кампаний уже инвестировали

средства в РСУБД, полная замена которых на нереляционные СУБД

практически невозможна без значительных затрат – здесь ОРСУБД

планируется как перспективная замена РСУБД, поэтому в этом направлении

активно работают такие разработчики РСУБД, как Oracle и IBM.

Наиболее очевидный способ преодоления недостатков РСУБД - это

внесение в нее дополнительных функций:

•

расширяемая пользователем система типов,

•

инкапсуляция,

•

наследование,

•

полиморфизм,

•

динамическое связывание методов,

•

использование составных объектов (в том числе и не в 1НФ),

•

поддержка идентичности объектов.

Не существует единого стандарта расширенной реляционной модели, в

каждой ОРСУБД формируется свой набор функциональных возможностей.

Общие принципы построения ОРСУБД базируются на совмещении подходов

РСУБД (использование базовых реляционных таблиц и расширенного

реляционного языка запросов (SQL3)) и объектно-ориентированных систем

(определение понятия объекта и методов работы с ним). Развитие

исследовательских проектов ОРСУБД ведется примерно с середины 1980 гг., а

коммерческие ОРСУБД декларированы серединой 1990 гг. Примерами

ОРСУБД можно назвать Postgres, IUS (Informix Universal Server), Oracle 8 и

Oracle 9i, DB2 Universal Database.

Основные преимущества ОРСУБД:

•

устранение недостатков широко распространенных РСУБД – большой

рынок приложений;

•

повторное и совместное использование компонентов – расширение

сервера СУБД специальными функциями, которые выполняются

централизованно и не входят в состав кода приложений (например,

векторные вычисления);

•

сохранение ранее наработанных знаний и опыта, связанных с разработкой

реляционных приложений – эволюционный (а не революционный) путь

развития требует меньших финансовых затрат;

Недостатки ОРСУБД:

•

повышенные расходы на эксплуатацию сложных систем;

•

утрата простоты и ясности реляционной модели;

•

ожидание низкой производительности от расширений (особенно в

традиционных реляционных приложениях);

• неполное соответствие объектно-ориентированному подходу – подмена

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

и объектно-ориентированными системами (понятие объектов гораздо

шире понятия данных);

•

значительное усложнение языка обработки данных, для поддержки SQL2.

Отделом CADF (Committee for Advanced DBMS Function) сформирован

манифест баз данных третьего поколения, которому должна следовать любая

СУБД третьего поколения (основные положения):

•

богатая система типов;

• желательна поддержка механизма наследования;

•

поддержка функций, процедур и методов, а также механизм

инкапсуляции;

•

использование системных уникальных идентификаторов только при

отсутствии первичных ключей, определенных пользователем;

•

наличие триггеров и ограничений;

•

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

помощью непроцедурного языка высокого уровня

• должны быть как минимум два способа задания коллекций: на основе

перечисления членов коллекции и с использованием языка запросов для

определения членства в коллекции;

•

наличие обновляемых представлений;

•

СУБД третьего поколения должны быть доступны из многих языков

высокого уровня;

•

язык SQL остается стандартом для работы с данными;

•

запросы и ответы на них должны составлять самый нижний уровень

взаимодействия сервера и клиента.

С другой стороны, существует ряд сторонников традиционной

реляционной модели данных (Дейт), и по их мнению объектно-

ориентированные и реляционные системы ортогональны друг другу и

«реляционная модель не нуждается ни в каких расширениях, исправлениях,

категоризациях и, более всего, в извращениях». Развитие реляционных систем

этой группой видится в полной и правильной реализации реляционной модели

в РСУБД и переработка (замена) языка SQL (вместо него предложен язык D).

4.3.3.6.3. Нереляционные СУБД третьего поколения

Основной конкурент РСУБД среди нереляционных СУБД представлен

объектно-ориентированными СУБД (ООСУБД). ООСУБД применяются с

конца 1980-х для обеспечения управления базами данных приложениями,

построенными в соответствии с концепцией объектно-ориентированного

программирования.

В манифесте ООСУБД (1989 г.) предлагаются правила определения

ООСУБД:

•

поддержка составных объектов;

•

поддержка идентичности объектов – наличие у объекта уникального

идентификатора, независящего от значений атрибутов;

• поддержка инкапсуляции – программисты имеют права доступа только к

методам объектов;

•

поддержка типов или классов;

•

поддержка наследования типов или классов от их предков;

•

поддержка динамического связывания – перегрузка и переопределение

методов во время выполнения программы;

•

язык DML должен обладать вычислительной полнотой – фактически это

должен быть язык программирования общего назначения;

•

набор типов данных должен быть расширяемым – должны быть средства

создания новых типов данных пользователя;

• поддержка перманентности данных – данные должны сохраниться после

завершения работы приложения без явных указаний пользователя;

•

поддержка очень больших баз данных – должны быть средства, как и у

РСУБД, для управления буферизацией, индексированием и т.п.

•

поддержка параллельной работы многих пользователей;

•

обеспечение восстановления после сбоев аппаратного и программного

обеспечения;

•

предоставление простых способов создания запросов к данным –

высокоуровневое, эффективное и независимое от приложений средство

создания запросов, но не обязательно декларативный язык.

К преимуществам ООСУБД можно отнести:

• улучшенные возможности моделирования – объектно-ориентированная

модель более точно представляет реальный мир (понятие объектов,

который инкапсулирует состояние и поведение, связи с другими

объектами хранятся в самом объекте (в том числе и связи «многие-ко

многим»));

•

расширяемость – создание новых абстрактных типов данных, работает

наследование и переопределение методов, легко выполняется повторное

использование классов;

•

устранение проблемы несоответствия – нет проблемы преобразования

типов как в РСУБД (SQL->C->SQL), DML обладает вычислительной

полнотой;

•

более выразительный язык запросов – использование навигационного

способа обработки данных (хорошо подходит для выполнения

рекурсивных запросов, ветвлений и т.п.), есть версии декларативных

языков построенных на объектно-ориентированной форме SQL – OQL

(для конечных пользователей);

•

поддержка эволюции схемы – использования наследования и

генерализации для более понятной и семантической точной схемы

данных;

•

поддержка долговременных транзакций – обычно это является проблемой

больших РСУБД;

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

данных – проблемные области для применения традиционных РСУБД;

•

повышенная производительность – не для традиционных приложений

РСУБД, преимущество может достигаться в том, что для ООСУБД

отсутствует уровень преобразований между языком СУБД и языком

приложения, а также отображение объектов в память с вторичного

выполняется более эффективно (нет лишних преобразований и контроля

типов).

Недостатками ООСУБД являются:

• отсутствие универсальной модели данных – нет стандарта на объектно-

ориентированную модель данных и теоретического обоснования этой

модели;

•

недостаточность опыта эксплуатации – использование ООСУБД пока

ограничено, более подходит для программистов, чем для конечных

пользователей;

•

отсутствие стандартов – нет фактических стандартов на язык запросов

(OQL), предложен фактический, но не международный стандарт на

объектно-ориентированную БД – ODMG 2.0(1995 г.);

•

влияние оптимизации запросов на инкапсуляцию – доступ к объектам

напрямую без защиты;

•

влияние блокировки на уровне объекта на производительность – может

вызывать проблемы в отношении иерархии наследования;

•

сложность – ООСУБД сложнее РСУБД, сложная система – сложные

продукты, поддержка одноуровневой модели (диск-память) хранения

данных тоже сложнее, чем двухуровневая модель (диск-преобразование-

память) в РСУБД;

•

отсутствие поддержки представлений – существенное отличие от

реляционной модели в плане администрирования;

•

недостаточность средств обеспечения безопасности – не реализованы

адекватные механизмы обеспечения безопасности (только высокий

уровень блокировок, плохое управление правами доступа).

Примерами ООСУБД можно назвать Objectivity/DB 2.1, GemStone 5.0,

ONTOS, OpenODB, ObjectStore, Versant и UniSQL.

Направление ООСУБД - динамически развивающееся направление на

рынке СУБД.

4.4. Физические модели данных

100