Базы данных, знаний и экспертные системы Калабухов ЕВ, БГУИР 2007 (Мет пособие)
.pdfПример применения декомпозиции. Пусть дано отношение
F{S#,City,Status,P#,Qty}
иизвестны его функциональные зависимости:
•S#→City ,
•S#→ Status ,
•City → Status ,
•S#,P#→Qty .
Первичный ключ отношения – 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 наблюдается транзитивная зависимость S#→ 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НФ.
91
Суть процесса нормализации:
1)В нормализованных отношениях не разрешаются никакие
функциональные зависимости, кроме функциональных зависимостей вида
K→ A , где K – потенциальный ключ отношения R, а A – неключевой атрибут.
2)Если же отношение R имеет функциональные зависимости B → A , где B не является потенциальным ключом, то в отношении R будет наблюдаться избыточность данных.
Выполнение нормализации важно не только при первичном проектировании реляционной БД, но также и при корректировке модели данных в процессе эксплуатации БД для учета новых функциональных зависимостей и устранения внесенных аномалий.
4.3.3.6.Недостатки и пути развития реляционной модели
4.3.3.6.1.Недостатки традиционных реляционных систем
Недостатки реляционных систем можно увидеть, проанализировав программные приложения, связанные с базами данных.
Традиционными для уверенного использования реляционных СУБД являются такие бизнес-приложения, как:
•обработка заказов;
•учет складских запасов;
•банковское дело;
•заказ билетов на транспорт (например, поезда и самолеты).
Однако существует ряд современных приложений, в которых
реляционные системы продемонстрировали свою неадекватность:
1) Автоматизированное проектирование (CAD) – компьютерные системы проектирования сложных проектов – зданий, самолетов, микросхем и т.п. Такие
92
проекты имеют следующие особенности:
•большое количество разных типов при небольшом количестве экземпляров объектов, что формирует большое количество отношений и сложно для обработки в РСУБД;
•сложные проекты насчитывают миллионы элементов и связаны с другими проектами;
•проект не является статичным, любые изменения должны своевременно отражаться во всех представлениях проекта – перепроектирование БД на лету часто неприемлемо для РСУБД;
•обновление проекта в небольшой части затрагивает практически весь проект;
•для одного проекта возможно множество альтернативных решений, требуется вести их учет, сравнение и внесение изменений.
•в проекте могут участвовать одновременно сотни сотрудников, работающих над разными частями и версиями – проблема непротиворечивости и скоординированности действий.
2)Автоматизированное производство (CAM) – например, производство автомобилей, химический синтез – проблемы обработки данных в реальном времени, большой объем статистики, много операторов.
3)Автоматизированная разработка программного обеспечения (CASE) – подобно CAD-проектам – коллективная разработка, много версий и т.п.
4)Офисные информационные системы, мультимедиа системы, цифровое издательское дело – большой набор разнообразных данных произвольных форматов (например, текстовых, видео, аудио, …) и необходимость осмысленной навигации по данным, нестандартные операции с данными.
Несмотря на многие сильные стороны реляционной модели, такие как:
•теоретическая обоснованность и опора на математику,
•простота,
•пригодность для систем интерактивной обработки транзакций,
•обеспечение независимости от данных,
93
•стандарт по обработке данных SQL, РСУБД имеют и определенные недостатки:
•слабое представление сущностей реального мира – процесс нормализации приводит к созданию фрагментов объектов реального мира в БД, в процессе обработки данных требуется большое число соединений;
•семантическая перегрузка – все виды семантических данных представляются в РСУБД только одной структурой – отношением, такое представление в операциях частично теряет смысл данных;
•слабая поддержка ограничений целостности и корпоративных ограничений – современные РСУБД не поддерживают все возможности реляционной модели данных (например, домены), из-за чего многие правила целостности приходится встраивать в приложения, что небезопасно; в реляционной модели вообще не предусмотрены корпоративные правила целостности – только SQL или приложения;
•однородная структура данных – с одной стороны таблица представлена очень просто, что удобно для обработки (набор атомарных значений ячеек), с другой стороны – нет возможности обрабатывать более сложные структуры данных – их надо хранить неестественным образом; для сложных BLOB-объектов есть только общие операции - нет доступа к элементам объекта;
•ограниченный набор операций – нет определения новых операций с данными, например, в GIS-системах требуется обрабатывать векторные и растровые понятия;
•трудности организации рекурсивных запросов – большая вложенность запросов на SQL2 не может быть реализована без дополнительных операторов или языка программирования высокого уровня;
•проблема рассогласования – преобразования данных между разными языками (например, SQL->C->SQL) приводит к большим затратам производительности (до 30%) и ресурсов;
•жесткость структуры БД и трудности ее преобразования во время
94
эксплуатации;
•слабый навигационный доступ – противоречит принципам реляционных операций.
4.3.3.6.2. Объектно-реляционные СУБД
Разработка СУБД с использованием расширенной реляционной модели данных или объектно-реляционной СУБД (ОРСУБД) относится к разработке СУБД третьего поколения.
Разработка ОРСУБД (старое название - расширенная реляционная СУБД) является ответом на развитие нереляционных СУБД третьего поколения, которые захватывают новые области применения (например, WWW). Другая сторона разработки ОРСУБД – множество кампаний уже инвестировали средства в РСУБД, полная замена которых на нереляционные СУБД практически невозможна без значительных затрат – здесь ОРСУБД планируется как перспективная замена РСУБД, поэтому в этом направлении активно работают такие разработчики РСУБД, как Oracle и IBM.
Наиболее очевидный способ преодоления недостатков РСУБД - это внесение в нее дополнительных функций:
•расширяемая пользователем система типов,
•инкапсуляция,
•наследование,
•полиморфизм,
•динамическое связывание методов,
•использование составных объектов (в том числе и не в 1НФ),
•поддержка идентичности объектов.
Не существует единого стандарта расширенной реляционной модели, в
каждой ОРСУБД формируется свой набор функциональных возможностей. Общие принципы построения ОРСУБД базируются на совмещении подходов РСУБД (использование базовых реляционных таблиц и расширенного
95
реляционного языка запросов (SQL3)) и объектно-ориентированных систем (определение понятия объекта и методов работы с ним). Развитие исследовательских проектов ОРСУБД ведется примерно с середины 1980 гг., а коммерческие ОРСУБД декларированы серединой 1990 гг. Примерами ОРСУБД можно назвать Postgres, IUS (Informix Universal Server), Oracle 8 и Oracle 9i, DB2 Universal Database.
Основные преимущества ОРСУБД:
•устранение недостатков широко распространенных РСУБД – большой рынок приложений;
•повторное и совместное использование компонентов – расширение сервера СУБД специальными функциями, которые выполняются централизованно и не входят в состав кода приложений (например, векторные вычисления);
•сохранение ранее наработанных знаний и опыта, связанных с разработкой реляционных приложений – эволюционный (а не революционный) путь развития требует меньших финансовых затрат; Недостатки ОРСУБД:
•повышенные расходы на эксплуатацию сложных систем;
•утрата простоты и ясности реляционной модели;
•ожидание низкой производительности от расширений (особенно в традиционных реляционных приложениях);
•неполное соответствие объектно-ориентированному подходу – подмена терминов, т.к. есть большой семантический разрыв между реляционными
иобъектно-ориентированными системами (понятие объектов гораздо шире понятия данных);
•значительное усложнение языка обработки данных, для поддержки SQL2.
Отделом CADF (Committee for Advanced DBMS Function) сформирован
манифест баз данных третьего поколения, которому должна следовать любая СУБД третьего поколения (основные положения):
• богатая система типов;
96
•желательна поддержка механизма наследования;
•поддержка функций, процедур и методов, а также механизм инкапсуляции;
•использование системных уникальных идентификаторов только при отсутствии первичных ключей, определенных пользователем;
•наличие триггеров и ограничений;
•все программные способы доступа к базе данных осуществляются с помощью непроцедурного языка высокого уровня
•должны быть как минимум два способа задания коллекций: на основе перечисления членов коллекции и с использованием языка запросов для определения членства в коллекции;
•наличие обновляемых представлений;
•СУБД третьего поколения должны быть доступны из многих языков высокого уровня;
•язык SQL остается стандартом для работы с данными;
•запросы и ответы на них должны составлять самый нижний уровень взаимодействия сервера и клиента.
Сдругой стороны, существует ряд сторонников традиционной реляционной модели данных (Дейт), и по их мнению объектноориентированные и реляционные системы ортогональны друг другу и «реляционная модель не нуждается ни в каких расширениях, исправлениях, категоризациях и, более всего, в извращениях». Развитие реляционных систем этой группой видится в полной и правильной реализации реляционной модели
вРСУБД и переработка (замена) языка SQL (вместо него предложен язык D).
4.3.3.6.3. Нереляционные СУБД третьего поколения
Основной конкурент РСУБД среди нереляционных СУБД представлен объектно-ориентированными СУБД (ООСУБД). ООСУБД применяются с
97
конца 1980-х для обеспечения управления базами данных приложениями, построенными в соответствии с концепцией объектно-ориентированного программирования.
В манифесте ООСУБД (1989 г.) предлагаются правила определения ООСУБД:
•поддержка составных объектов;
•поддержка идентичности объектов – наличие у объекта уникального идентификатора, независящего от значений атрибутов;
•поддержка инкапсуляции – программисты имеют права доступа только к методам объектов;
•поддержка типов или классов;
•поддержка наследования типов или классов от их предков;
•поддержка динамического связывания – перегрузка и переопределение методов во время выполнения программы;
•язык DML должен обладать вычислительной полнотой – фактически это должен быть язык программирования общего назначения;
•набор типов данных должен быть расширяемым – должны быть средства создания новых типов данных пользователя;
•поддержка перманентности данных – данные должны сохраниться после завершения работы приложения без явных указаний пользователя;
•поддержка очень больших баз данных – должны быть средства, как и у РСУБД, для управления буферизацией, индексированием и т.п.
•поддержка параллельной работы многих пользователей;
•обеспечение восстановления после сбоев аппаратного и программного обеспечения;
•предоставление простых способов создания запросов к данным – высокоуровневое, эффективное и независимое от приложений средство создания запросов, но не обязательно декларативный язык.
Кпреимуществам ООСУБД можно отнести:
98
•улучшенные возможности моделирования – объектно-ориентированная модель более точно представляет реальный мир (понятие объектов, который инкапсулирует состояние и поведение, связи с другими объектами хранятся в самом объекте (в том числе и связи «многие-ко многим»));
•расширяемость – создание новых абстрактных типов данных, работает наследование и переопределение методов, легко выполняется повторное использование классов;
•устранение проблемы несоответствия – нет проблемы преобразования типов как в РСУБД (SQL->C->SQL), DML обладает вычислительной полнотой;
•более выразительный язык запросов – использование навигационного способа обработки данных (хорошо подходит для выполнения рекурсивных запросов, ветвлений и т.п.), есть версии декларативных языков построенных на объектно-ориентированной форме SQL – OQL (для конечных пользователей);
•поддержка эволюции схемы – использования наследования и генерализации для более понятной и семантической точной схемы данных;
•поддержка долговременных транзакций – обычно это является проблемой больших РСУБД;
•применимость для сложных специализированных приложений баз данных – проблемные области для применения традиционных РСУБД;
•повышенная производительность – не для традиционных приложений РСУБД, преимущество может достигаться в том, что для ООСУБД отсутствует уровень преобразований между языком СУБД и языком приложения, а также отображение объектов в память с вторичного выполняется более эффективно (нет лишних преобразований и контроля типов).
Недостатками ООСУБД являются:
99
•отсутствие универсальной модели данных – нет стандарта на объектноориентированную модель данных и теоретического обоснования этой модели;
•недостаточность опыта эксплуатации – использование ООСУБД пока ограничено, более подходит для программистов, чем для конечных пользователей;
•отсутствие стандартов – нет фактических стандартов на язык запросов (OQL), предложен фактический, но не международный стандарт на объектно-ориентированную БД – ODMG 2.0(1995 г.);
•влияние оптимизации запросов на инкапсуляцию – доступ к объектам напрямую без защиты;
•влияние блокировки на уровне объекта на производительность – может вызывать проблемы в отношении иерархии наследования;
•сложность – ООСУБД сложнее РСУБД, сложная система – сложные продукты, поддержка одноуровневой модели (диск-память) хранения данных тоже сложнее, чем двухуровневая модель (диск-преобразование- память) в РСУБД;
•отсутствие поддержки представлений – существенное отличие от реляционной модели в плане администрирования;
•недостаточность средств обеспечения безопасности – не реализованы адекватные механизмы обеспечения безопасности (только высокий
уровень блокировок, плохое управление правами доступа).
Примерами ООСУБД можно назвать Objectivity/DB 2.1, GemStone 5.0, ONTOS, OpenODB, ObjectStore, Versant и UniSQL.
Направление ООСУБД - динамически развивающееся направление на рынке СУБД.
4.4. Физические модели данных
100