Мультимодельные СУБД

Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 39 страниц
В избранное:

МИНИСТЕРСТВО ОБРАЗОВАНИЯ
И НАУКИ РЕСПУБЛИКИ КАЗАХСТАН

КАЗАХСКИЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ
им. Т. Рысулова

Кафедра “Прикладная информатика”

Курсовая работа

по дисциплине “Системы баз данных”
на тему: Мультимодельные СУБД

Выполнила: студентка 3 курса,

группа ИС-306, Муратова Д.М.

Проверила: ст.преп. Неверова Е.Г.

Алматы 2008

Содержание
Введение ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ..3
1.Теоретическая часть: ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ..4
1.1 Классификация БД ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...10
1.2 Объектно-ориентированные СУБД ... ... ... ... ... ... ... ... ... ... ...13
2.Практическая часть: ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ..15
2.1 Иерархическая модель базы данных ... ... ... ... ... ... ... ... ... ... ..15
2.1.1 Недостатки иерархической модели ... ... ... ... ... ... ... ... ... ..18
2.2 Реляционная модель базы данных ... ... ... ... ... ... ... ... ... ... ... .20
2.2.1Реляционные датологические модели СУБД ... ... ... ... ... ... ...23
2.3 Сетевые модели данных ... ... ... ... ... ... ... ... ... ... ... ... ... ... .27
2.4 Иерархические модели в реляционных БД ... ... ... ... ... ... ... ... ..31
3.Аналитическая часть: ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .33
3.1 Научные исследования в области системах ... ... ... ... ... ... ... ... .33
3.2Основные возможности и организация СУБД иерархического,
сетевого, реляционного типов ... ... ... ... ... ... ... ... ... ... ... ... ... ..37
Заключение ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ..39
Список литературы ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .40

Введение

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

1 Теоретическая часть
База данных - это именованная совокупность данных, адекватно
отображающих состояние объектов и их взаимосвязей в некоторой предметной
области и организованных таким образом, что данные могут использоваться для
решения многих задач многими пользователями. Предметная область, в общем
случае, складывается из множества реальных объектов, обладающих некоторым
набором свойств, - атрибутов. Отображению в базе данных подлежать лишь
существенные атрибуты, несущественными можно пренебречь.
База данных (БД) - совокупность взаимосвязанных данных хранящихся в памяти
ЭВМ, вводятся, хранятся, просматриваются, обрабатываются, а также выводятся
на экран.
Существует два способа создания базы данных:
а) Позадачный- каждая задача работает со своей совокупностью данных;
б) с использованием систем управления БД (СУБД).
Имеем БД, СУБД, задачи (прикладная программа 1,2, ..., п) работает сразу со
всеми задачами.
СУБД выполняет двоякую функцию:
а) является инструментальным средством (средой), создания, разработки,
программирование БД;
б) обеспечивает эксплуатацию БД.
Современные СУБД можно классифицировать на следующие классы:
а) электронные таблицы (Super Calc MSDOS, Excel Windows)
Первый класс СУБД используется для решения небольших по объему (V) и
несложных по выполнению задач.
Функциональные возможности электронных таблиц:
написание, корректировка и другая работа с текстом (т.е. имеют свой
встроенный редактор);
проведение расчетов и вычислений с помощью общепринятых арифметических,
логических операций и встроенных функций (sin, cos, tg, ctg).
работа в режиме псевдографики, т.е. создание столбовых, прямоугольных,
круговых, линейчатых, зонных и других диаграмм.
работа со встроенной БД реалиционного типа.
Электронные таблицы содержат һеір(помощь); встроенный пакет-справочник с
примерами.
При работе с базой данных в электронных таблицах, исходную таблицу смещают
вниз от левого верхнего угла, а вверху записывают условия нахождения
данных, они же результирующие таблицы, которые отражают поиска.
б) Второй класс СУБД средство программирования баз данных оперативного
типа (Clipper, dbase, FoxBase). Эти СУБД с точки зрения технологии создания
БД аналогичны стандартному языку программирования (Турбо-паскаль).
в) СУБД комбинированного типа (на основе файловой структуры Clarion).
г) СУБД со встроенными программами (генераторами) автоматизированного
программирования объектов БД (таблицу, форм входных документации,
меню с подключением механизма реорганизации данных в БД, запросов с
отчетами форм входных документов). Paradox - язык Pal (Pal не уступает
Турбо-Паскалю 7.0). Он позволяет подключение подпрограмм, написанных
на любом языке программирования
Объекты базы данных:
1. а) Таблицы (взаимосвязанные или невзаимосвязанные);
б) логические (виртуальные) таблицы - связанные между собой с помощью
ключевых атрибутов (нужна, чтоб не дублировать данные).
Формы входных документов с которыми работает пользователь.
Система управляющего меню.
Запросы.
Формы входных документов (отчеты).
Для полноценной работы БД создают или подключают механизм реорганизации
данных в БД.
Жизненный цикл автоматизированной информационной системы:
"бумажное" программирование;
реализация;
эксплуатация (введение БД). Различают 3 основных модели БД:
иерархическая;
сетевая (реализует технологию "Клиент-Сервер");
реляционную модель для IBM PC (локальная). Существует два подхода к
созданию базы данных:
сначала создаются таблицы и формы, а потом меню и запросы с отчетом;
создается меню, потом таблицы и формы, запросы с отчетами.
Элементы построения баз данных.
Номер. Буква алфавита. Ф.И.О. Место работы. Телефон. Адрес. printf("\n");
printf ("\п Номер Буква алфавита ФИО Место работы Телефон Адрес \п");
printf(" \п");
В современных средствах программирования баз данных используется программа
автоматизации программирования следующих объектов: таблиц, форм документов,
систем управления меню и запросов с отчетами. Эти средства делятся на
классы:
средства операторного типа;
средства, включающие комплекс программ автоматизированного построения
указанных объектов электронной таблицы.
Для небольшого по V и несложных по вычислению баз данных используются
электронные таблицы.
Структура базы данных.
Это взаимосвязь основных объектов БД (таблицы, формы, меню) с файловой
структурой. В настоящее время для создания баз данных и других программных
продуктов используются технологии "Клиент-Сервер". Рассмотрим применение
этой технологии на примере разработки фирмы Staffware (Англия). На
протяжении последнего года эта фирма разрабатывает продукты вместе с
ІВМ(США) и Microsoft (США). Структура разработки фирмы Staffware:

Данная система предназначена для автоматизации управления документами
в электронном офисе. Объем электронной текстовой информации (документа)
станет в 3 раза больше. Например, в США ежедневно создается 900 млн.
страниц информации, 76 млн. писем и 21 млн. других документов, храница
І.Зтрл. документов на бумаге. Однако, получить доступ можно лишь к 10% этой
информации.
Требования к СУБД:
Эффективность выполнения различных функций предметной области;
Минимизация избыточности;
Предоставление для процесса принятия решений непротиворечивой информации;
Обеспечение безопасности;
Отсутствие повышенных требований к персоналу, связанное с разработкой
прикладных программ;
Реорганизация БД;
Централизованное управление;
Упрощение эксплуатации ЭВМ.
БД должна:
Удовлетворять актуальным требованиям внешних юзеров, обеспечивать хранение
и модификацию больших объемов информации;
Обеспечивать заданный уровень достоверности хранимой информации и ее
непротиворечивость;
Обеспечивать доступ к секретным данным только спец. юзерам;
Возможность поиска информации по ключу;
Удовлетворение требованиям по производительности обработки запросов;
Возможность реорганизации и расширения при замене границ ПО;
Различные виды выдачи информации;
Простота и удобство обращения к информации.;
Обеспечивать возможность одновременного обслуживания большого числа юзеров.
Администратор БД (АБД). АБД — лицо, ответственное за выполнение функции
администрирования БД. АБД не обладатель БД, а ее хранитель. С усложнением
предметной области усложняются процессы формирования информации, и принятия
решения (расширение спектра функций администрирования БД. Главный принцип —
непротиворечивость данных.
АБД должен: координировать все действия по сбору информации. Ее
проектирование и ведение в целом. А также ЗИ. Независимость данных.
Прикладному программисту для организации доступа к данным надо знать:
1)каков формат;
где располагаются;
как обратиться к ним.
Используя ту или иную БД и не зная ее внутреннего представления, этим
достигается независимость данных. Возникают модернизации, связанные с
ЭКСПОРТОМ и импортом файлов в БД (добавление и усечение БД). Причины,
порождающие необходимость независимости данных:
АБД должен проводить изменения содержания, расположения БД;
поставщик Hard & Soft обработки данных должен вводить новые технологии, не
требуя
перепрограммирования программ клиента. Необходимо обеспечить разделение
данных, представляя их по-разному ограниченно прикладным программистам.
Защита АБД.
Два уровня независимости данных. Процесс проектирования БД начинается с
установления концептуальных требований ряда юзеров. Эти требования
интегрируются как единое обобщенное представление, из которого образуется
концептуальная модель предметной области.
Транслирование концептуальной модели (адаптация) в совместимую область с
выбранной СУБД.

База Данных (БД) — структурированный организованный набор данных,
описывающих характеристики каких-либо физических или виртуальных систем.

Базой данных часто упрощённо или ошибочно называют Системы Управления
Базами Данных (СУБД). Нужно различать набор данных (собственно БД) и
программное обеспечение, предназначенное для организации и ведения базы
данных (СУБД).

Структура БД
Организация структуры БД формируется исходя из следующих соображений:

1. Адекватность описываемому объектусистеме — на уровне концептуальной
и логической модели.
2. Удобство использования для ведения учёта и анализа данных — на уровне
так называемой физической модели.

Виды концептуальных (инфологических) моделей БД: сущность-связь,
семантические, графовые

Виды логических (даталогических) моделей БД:
1. Документальные (архивы) — ориентированные на формат документа,
дескрипторные, тезаурусные.
2. Фактографические (картотеки)

теоретико-графовые: иерархическая модель, сетевая модель.
теоретико-множественные: реляционная модель (ER-модель), многомерная
модель.
объектно-ориентированные: объектная модель.
основанные на инвертированных файлах.

Таким образом, по модели представления данных БД классифицируются:
* Картотеки
* Сетевые
* Иерархические
* Реляционные
* Многомерные
* Объектно-ориентированные
* Дедуктивные

На уровне физической модели электронная БД представляет собой файл или
их набор в формате TXT, CSV, Excel, DBF, XML либо в специализированном
формате конкретной СУБД. Также в СУБД в понятие физической модели включают
специализированные виртуальные понятия, существующие в её рамках — таблица,
табличное пространство, сегмент, куб, кластер и т. д.

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

Этапы проектирования базы данных
1. Концептуальное проектирование — сбор, анализ и редактирование требований
к данным. Для этого осуществляются следующие мероприятия:

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

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

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

3. Физическое проектирование — определение особенностей хранения данных,
методов доступа и т. д.

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

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ — Представление аналитика (используется
инфологическая модель сущность-связь)
* сущности
* атрибуты
* связи

ЛОГИЧЕСКИЙ УРОВЕНЬ — Представление программиста
* записи
* элементы данных
* связи между записями

ФИЗИЧЕСКИЙ УРОВЕНЬ — Представление администратора
* группирование данных
* индексы
* методы доступа

1.1 Классификация БД.
БД являются сложными системами, объединяющими разнотипные компоненты
и выполняющие различные функции. Классификация БД производится как с точки
зрения системы в целом, так и по отдельным характеристикам подсистем в
отдельности. По используемому языку общения с БД различают системы с
базовым языком (открытые системы) и с собственным языком (замкнутые
системы).
В открытых системах для обращения к БД используется язык
программирования, расширенный операторами ЯМД, что требует
непосредственного знания языка при общении с БД. Основной целью на этом
этапе ( автоматизация процесса написания программ для общения с БД
(автоматический синтез программ для общения с БД). Связи с применением
открытых систем при большом разнообразии типов запросов эффективным
является реализация не регламентированных по содержанию запросов. Системы с
базовыми языками требуют от программиста знание логической структуры той
части БД, к которой он имеет непосредственный доступ.
Замкнутые СУБД имеют собственные самостоятельные языки общения юзеров с
БД. Они позволяют обходиться без прикладных программистов и обеспечивать
непосредственное общение с БД в режиме вопрос - ответ или в диалоговом
режиме. Жесткой границы между открытыми и замкнутыми системами не. В
настоящее время в связи с широким развитием работ по автоматизации
проектирования информационных систем с реализацией тенденции
программирования без программистов все разработанные системы все больше
наделяются свойствами замкнутых систем.
В зависимости от особенностей моделей поддерживаемых БД различают
следующие системы: системы со структурированными, неструктурированными и
частично структурированными БД. Системы со структурированной БД
ориентированы на предварительную классификацию объектов реального мира на
установление свойств и связей, которые будут фиксироваться в БД, а также на
предварительное определение форматов для хранения данных. Структурированные
БД называются также форматированными или БД с детерминированной схемой. БД
с детерминированной схемой удается представить как массовые предсказуемые
события в предметной области. В системах с неструктурированной БД
совокупность видов свойств и видов взаимосвязей объекта с другими объектами
определяется только в момент появления каждого реального объекта в поле
знания СУБД. СУБД делятся:
универсальные (такие СУБД настраиваются на ту или иную предметную область
путем создания соответствующей БД и прикладных программ);
проблемно-ориентированные системы.
Проблемная ориентация СУБД может быть обусловлена различными причинами:
особенностями использования языковых средств;
включение в СУБД процедур обработки данных, учитывающих предметную область.
Большинство СУБД являются универсальными с широким спектром применения.
По допустимым режимам работы различают системы с пакетной, местной и
телеобработкой. Изначально многие СУБД обладали возможностью обеспечивать
только пакетного режима работы.
По характеру хранимой информации выделяют БД для экономической, научно
технической, социально-политической, технологической и др. информации.
По способу организации обработки данных различают:
локализованные (достаточно 1 ЭВМ);
2) распределенные БД (БД реализуется на нескольких ЭВМ).
Распределенные БД (РБД). Первоначально РБД отождествлялась с
распределенной БД по узлам сети, однако распределяться могут и другие
компоненты БД, поэтому здесь используется понятие РБД, которое в процессе
использования (ее компоненты) должны быть разделены только физически, но не
логическом уровне. Логическая интеграция РБД означает,-что вся РБД -
потенциально доступна из узла. В системах с РБД кроме понятия "схема"
вводится понятие "супер-схема" — описание РБД как логически целой
информационной совокупности. В РБД функции АБД распределены между
администратором интегрированной БД и администраторами локальных БД. ПО
каждого узла сети кроме компонентов, используемых в локальных БД, содержат
2 дополнительных компонента: средства управления связью, сетевую систему
управления БД. С помощью сетевого компонента выявляются сведения о
нахождении данных в системе, определяется, куда послать запрос на
обработку.
Преимущества и недостатки РБД.
Преимущества:
РБД позволяет совместить децентрализованные и централизованные системы,
т.е. есть возможность распределения нагрузки между различными компонентами
системы. РБД обладает лучшими адаптивными свойствами и меньшей
чувствительностью к выходу из строя отдельных компонентов. Недостатки:
Сложность. В РСУБД больше функций, чем в обычной СУБД. Проблемы
синхронизации при обработке поисковых и корректирующих запросов. Сложная
задача проектирования БД, как на логическом, так и на физическом уровнях. В
РБД часто появляются дополнительные уровни модели данных (увеличивается
время обработки). Сложнее стоит вопрос с ЗИ.
Классификация РБД. В зависимости от однородности компонентов РБД
различают однородные (гомогенные) и разнородные (гетерогенные) чаще всего
эта классификация производится относительно используемых ЭВМ и СУБД.
Гомогенные системы являются более простыми как с точки зрения
проектирования и эксплуатации, гетерогенные более сложные и гибкие. По
распределяемым ресурсам различают: системы с распределенными БД и
распределенными СУБД. Системы РБД могут быть как с распределенными, так и с
едиными СУБД. Системы с распределенными СУБД обязательно являются системами
с РБД. Наряду, с очевидными достоинствами распределенные системы с
централизованной БД имеют и недостатки. Высокая стоимость передачи данных,
низкая надежность, большое время реакции системы. В многомашинном комплексе
технических средств могут эффективно распределятся отдельные функции
системы обработки данных. Такая функция по управлению данными могут быть
переданы отдельной ЭВМ, такие системы называются внутрикомплексные
распределенные системы со специализированными ЭВМ . Машины выполняющие
функции управления БД называют процессорами БД или файловыми процессорами.
Их роль обычно несут универсальные ЭВМ. ЭВМ которые используются для
выполнения всех остальных функций по обработке данных за исключением
управления БД называются главными машинами . Кроме того аналогичное
распределение функций может быть выполнено в рамках 1 -й ЭВМ такие машины
называются би— функциональными. Применение таких машин отличает их от
стандартного применения БД по способу организации процесса внутримашинной
обработки данных. БД в системах с РБД могут: равноправными и
неравноправными. Существует много способов распределения данных по узлам
сети, крайним вариантом является полностью избыточные сети, в которых инфра
дублируется в каждом узле сети. Распределенные системы - это системы, в
которых ни какая информация хранится не более чем в 1-м узле. По способу
адресации запроса системы с распределенными БД делятся на безадресные и с
явной адресацией. В без адресных системах используются разные способы
определения место нахождения нужных данных, а именно хранение справочников
в каждом узле, а также последовательный опрос узлов. В соответствии с
топологией выделяют: сетевые, иерархические, звездообразные. Различают
физическая и логическая топология. Физическая топология определяет
действующий путь прохождения запроса в сети. Логическая топология
определяет связи БД с пользователем без деталей их физической реализации.

1.2 Объектно-ориентированные СУБД (ООСУБД)

В настоящем параграфе рассматриваются основные концепции, понятия, черты
и характеристики объектно-ориентированных систем управления БД (ООСУБД)
в контексте рассмотренных объектно-ориентированных программирования
и технологии. В последние годы в результате проникновения идеологии ООП в
СУБД интенсивные разработки теоретического и прикладного характера ведутся
по созданию различного назначения.ООСУБД. Ввиду не совсем устоявшейся в
этом направлении терминологии отметим основные черты и характеристики,
определяющие СУБД как объектно-ориентированную. При этом по мере
необходимости проводятся сопоставления с рассмотренной выше концепцией ООП.
Характеристики ООСУБД подразделяются на три определяющие группы:
— базовые, определяющие принадлежность СУБД к объектно-ориентированному
классу;
по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовыми;
открытости, позволяющие пользователю делать осознанный выбор из ряда
одинаково приемлемых реализаций ООСУБД.
В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД
в ее классическом понимании и быть объектно-ориентированной системой (ООС),
т.е. в определенной степени она должна быть совместимой с современными
объектно-ориентированными ЯВУ. Первый критерий включает следующие пять
характеристик, присущих классической СУБД: сохранность данных, развитое
управление внешней памятью, возможность совмещения обработки и поиска
данных, поддержка средств восстановления и возможность быстрого доступа к
БД по запросу пользователя. Отмеченные характеристики в той или иной мере
обсуждались выше. Второй критерий предполагает наличие следующих
характеристик, присущих собственно объектно-ориентированной технологии:
понятие сложных объектов, идентичность объектов, инкапсуляция, типы или
классы, наследование, настройка (сочетающаяся с отложенным присвоением),
расширяемость и вычислительная полнота. Характеристики первого критерия
хорошо известны пользователям традиционных СУБД (dBase, R- Base, др.)
Сложные объекты строятся из более простых путем применения к ним
конструкторов. В качестве простых используются такие объекты, как: целые и
действительные числа, символы, символьные строки любой длины, булевы
величины и, возможно, другие первичные типы. В качестве конструкторов
сложных объектов (объектных конструкторов) могут выступать: кортежи,
множества, списки, массивы, таблицы и др. В качестве минимального набора
объектных конструкторов от ООСУБД определяются: множество, кортеж, список
или массив. Множество дает естественную возможность представления
определенного набора объектов из имеющейся обширной совокупности; тогда как
кортеж позволяет представлять определенные свойства объекта. При этом
кортежи и множества имеют особое значение, получив широкое применение в
качестве объектных конструкторов в реляционных БД (РБД) Список или массив
играют важную роль при установлении порядка среди элементов множества.
Более того, указанные типы объектных конструкторов играют важную роль во
многих приложениях (векторно-матричные задачи, задачи анализа временных
рядов и др.).
Объектные конструкторы должны удовлетворять принципу ортогональности:
любой конструктор может применяться к любому объекту. Например,
конструкторы РБД не обладают данным свойством (так конструктор множества
может применяться только к кортежам, а конструктор кортежей — только к
первичным типам).

2 Практическая часть:
2.1 Иерархическая модель базы данных
Иерархическая модель базы данных состоит из объектов с указателями от
родительских объектов к потомкам, соединяя вместе связанную информацию.

Иерархические базы данных могут быть представлены как дерево,
состоящее из объектов различных уровней. Верхний уровень занимает один
объект, второй — объекты второго уровня и т. д.

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

Примеры

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

В этой модели запрос, направленный вниз по иерархии, прост (например:
какие заказы принадлежат этому покупателю); однако запрос, направленный
вверх по иерархии, более сложен (например, какой покупатель поместил этот
заказ). Также, трудно представить не-иерархические данные при использовании
этой модели.

Иерархической базой данных является файловая система, состоящая из
корневой директории, в которой имеется иерархия поддиректорий и файлов.

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

Структурная часть иерархической модели
Основными информационными единицами в иерархической модели данных
являются сегмент и поле. Поле данных определяется как наименьшая неделимая
единица данных, доступная пользователю. Для сегмента определяются тип
сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных
значений полей данных. Тип сегмента — это поименованная совокупность
входящих в него типов полей данных. Как и сетевая, иерархическая модель
данных базируется на графовой форме построения данных, и на концептуальном
уровне она является просто частным случаем сетевой модели данных. В
иерархической модели данных вершине графа соответствует тип сегмента или
просто сегмент, а дугам — типы связей предок — потомок. В иерархических
структуpax сегмент — потомок должен иметь в точности одного предка.
Иерархическая модель представляет собой связный неориентированный гpaф
древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из
упорядоченного набора деревьев.

Преобразование концептуальной модели в иерархическую модель данных
Преобразование концептуальной модели в иерархическую структуру данных
во многом схоже с преобразованием ее в сетевую модель, но и имеет некоторые
отличия в связи с тем, что иерархическая модель требует организации всех
данных в виде дерева. Преобразование связи типа "один ко многим" между
предком и потомком осуществляется практически автоматически в том случае,
если потомок имеет одного предка, и происходит это следующим образом.
Каждый объект с его атрибутами, участвующий в такой связи, становится
логическим сегментом. Между двумя логическими сегментами устанавливается
связь типа "один ко многим". Сегмент со стороны "много" становится
потомком, а сегмент со стороны "один" становится предком. Ситуация
значительно усложняется, если потомок в связи имеет не одного, а двух и
более предков. Так как подобное положение является невозможным для
иерархической модели, то отражаемая структура данных нуждается в
преобразованиях, которые сводятся к замене одного дерева, например, двумя
(если имеется два предка). В результате такого преобразования в базе данных
появляется избыточность, так как единственно возможный выход из этой
ситуации — дублирование данных.

Управляющая часть иерархической модели
В рамках иерархической модели выделяют языковые средства описания
данных (ЯОД) и средства манипулирования данными (ЯМД). Каждая физическая
база описывается набором операторов, обусловливающих как ее логическую
структуру, так и структуру хранения БД. При этом способ доступа
устанавливает способ организации взаимосвязи физических записей.

Определены следующие способы доступа: Ұ иерархически последовательный;
Ұ иерархически индексно-последовательный; Ұ иерархически прямой; Ұ
иерархически индексно-прямой; Ұ индексный.

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

Примеры типичных операторов поиска данных
Ұ найти указанное дерево БД; Ұ перейти от одного дерева к другому; Ұ
найти экземпляр сегмента, удовлетворяющий условию поиска; Ұ перейти от
одного сегмента к другому внутри дерева; Ұ перейти от одного сегмента к
другому в порядке обхода иерархии. Примеры типичных операторов поиска
данных с возможностью модификации: Ұ найти и удержать для дальнейшей
модификации единственный экземпляр сегмента, удовлетворяющий условию
поиска; Ұ найти и удержать для дальнейшей модификации следующий экземпляр
сегмента с теми же условиями поиска; Ұ найти и удержать для дальнейшей
модификации следующий экземпляр для того же родителя. Примеры типичных
операторов модификации иерархически организованных данных, которые
выполняются после выполнения одного из операторов второй группы (поиска
данных с возможностью модификации): Ұ вставить новый экземпляр сегмента в
указанную позицию; Ұ обновить текущий экземпляр сегмента; Ұ удалить текущий
экземпляр сегмента.

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

Известные иерархические СУБД

* Типичным представителем (наиболее известным и распространенным)
является Information Management System (IMS) фирмы IBM. Первая версия
появилась в 1968 г.
* Time-Shared Date Management System (TDMS) компании Development
Corporation;
* Mark IV Multi - Access Retrieval System компании Control Data
Corporation;
* System - 2000 разработки SAS-Institute;
* Серверы каталогов, такие, как LDAP и Active Directory (допускают
чёткое представление в виде дерева)
* По принципу иерархической БД построен и Реестр Windows.

2.1.1 Недостатки иерархической модели.

Для нереляционных СУБД следует разделять СУБД иерархической, сетевой (не
путать с LAN и WAN :)) и объектно-ориентированной модели.

Классическая иерархическая несколько устарела (лет так на 30 :)) На сетевую
модель есть стандарт - CODASYL, они тоже не первой свежести, пример
реализации на х86 - Titanium. Cashe, как я понимаю, объектная, были потуги
их стандартизации, насколько помню - кончились ничем. Смело можно считать
объектную модель надстройкой над сетевой - механизм тот же.

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

Недостатки:

Отсутствует декларативный язык запросов (SQL). Логику работы с данными
приходится реализовывать в программах = она неизменна и почти не
масштабируется.

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

Еще следствие - процедурный запрос почти не параллелится = никакая
масштабируемость.

В тех СУБД, где внешний SQL есть (Cache, Titanium) - он скуден, требуется
ручное сложное проектирование отображения родной сетевой структуры в
реляционную. Плохие оптимизаторы SQL.

Еще одним (современным) вариантом иерархических (но не сетевых) СУБД можно
смело считать XML СУБД. У них как раз есть декларативный язык запросов
XQueryXPath, но весьма специфическая модель данных. Как XML DBMS могут
выступать и некоторые РСУБД, например DB2 и Oracle.

По факту развития СУБД иерархических БД относят к первому поколению, а
РСУБД ко второму.

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

Я бы все-таки ко 2-му поколению отнес сетевые (CODASYL) СУБД, а РСУБД - к 3-
му.

XML ДБ является полуструктурированной только для не типизированных
документов. Если СУБД знает схему XML документов и использует ее при
парсинге и хранении, БД вполне типизирована и является иерархической по
организации данных и методу навигации по ним. Но, согласен, эта модель
весьма отличается от иерархической "классики" и заслуживет отдельного
рассмотрения.

2.2 Реляционная модель базы данных
Реляционные СУБД — далеко не идеал, написано об этом достаточно.
Хорошо, что пишут и про то, что чисто объектные СУБД тоже не панацея, хотя
у них есть свои преимущества. Но ведь и у сетевых, и у иерархических систем
были и остаются достоинства, про которые нельзя забывать. Вот бы соединить
плюсы таких систем и моделей данных в одной СУБД!
Есть и другая сторона медали. Надо отчетливо представлять, ради чего
применять СУБД, и какие механизмы в них использовать. Мы имеем в виду
случаи длительного хранения данных, отражающих структурно сложные
предметные области. Наша цель — показать, какие классические, но часто
забываемые возможности должны использоваться, какие средства и инструменты
позволяют их практически сочетать с новыми средствами информационных
технологий.
Статус-кво
Появление промышленных СУБД устранило несколько основных недостатков
файловых хранилищ данных, дав средства устранения избыточности за счет
поддержания связанной совокупности агрегатов данных, а также обеспечило
сохранение и восстановление всей совокупности данных вне зависимости от
способов их хранения и обработки. Вопрос проектирования корректных и
эффективных структур данных рассматривался как ключевой.
Что произошло дальше?
Число распространенных промышленных СУБД увеличилось, SQL стал
стандартом, а технические возможности хранения данных возросли. В силу
этого при выборе СУБД все еще оценивают платформу для ее применения,
технологию проектирования, сопровождающую применение СУБД, рассматривают
языки программирования приложений. Пожалуй, и все. А вопрос структур
логической организации и хранения данных, которые может поддерживать СУБД,
вроде бы отошел на второй план.
Вместе с тем в АИС, проектируемых для использования в течение
длительного времени, поддержка различных структур данных очень важна. И это
оказывается напрямую связано с тем, насколько правильно вложены деньги в
СУБД как в базовое ПО для хранения данных, рассчитанное на длительный
период, например, на десятки лет. Плохой выбор чреват либо заменой СУБД в
обозримом будущем, либо постоянными дополнительными инвестициями — закупкой
мощностей, перепрограммированием приложений.
Корни проблем и практические мотивы.
В качестве пробного камня для проверки плюсов и минусов разных систем и
моделей мы выбрали возможности отражения в БД сложных структур данных и, в
первую очередь, структурных связей между данными. Это вызвано тем, что при
ограниченных возможностях отражения в структуре БД особенностей предметной
области будут возникать значительные потери непротиворечивости
накапливаемых данных. Как следствие, будут возникать серьезные претензии
пользователей к хранилищу данных (то есть к БД), что приведет к
необходимости дорогостоящего перепроектирования и перевода накопленных
данных на новую СУБД. (Является ли хранилище — DataWareHouse —
принципиально новой идеей или просто другим названием старых добрых БД?
Авторы склонны ко второй точке зрения, поскольку VLDB (Very Large Data
Bases) разных типов создаются десятки лет, да и другие особенности,
приписываемые DWH, просто выделяют некоторые классы БД из всего
разнообразия.)

Конечно, проблемы вызваны не только ограничениями СУБД. На наш взгляд,
распространенной бедой является и пробел в самом понимании разработчиками
того, что же такое база данных (как их хранилище), хотя определения этого
понятия даны еще в шестидесятых-семидесятых годах. К сожалению, этот пробел
образуется в вузах, где основное внимание уделяется программированию, в
лучшем случае — основам проектирования приложений, но не основам построения
хранилищ данных как средству отображения предметной области.
И еще одно: не хотелось бы говорить об упускаемых возможностях, если
нет средств их практической реализации. Однако существует промышленная
система, которая позволяет разработчикам использовать такие возможности,
интегрируя плюсы классических СУБД различных типов, развивая их и дополняя
новыми методами обработки данных.
О связях
Рассмотрим некоторые детали отображения предметной области структурами
данных. Более конкретно — остановимся на представлении связей между
агрегатами данных в БД, как бы они ни назывались в разных СУБД: записями,
сегментами, группами, строками таблиц или объектами.
Наиболее известны такие структурные связи (особенности в правилах
существования связей мы не рассматриваем): один-к-одному (один экземпляр
агрегата данных может быть связан с одним экземпляром агрегата другого
типа); один-ко-многим (один экземпляр связан со многими экземплярами
другого типа); многие-ко-многим (один экземпляр связан со многими
экземплярами другого типа, а каждый из последних — со многими другими
экземплярами исходного типа); разветвленная (один экземпляр может быть
связан с экземплярами нескольких других типов); рекурсивная (один экземпляр
данного типа может быть связан с другими экземплярами этого же типа или сам
с собой).

Есть и варианты этих связей, сочетающие разные их свойства. О моделях
данных. Часто, говоря о моделях данных различных СУБД, различают их именно
по поддержанию тех или иных связей между агрегатами БД в ее физическом или
логическом представлении (мы не претендуем здесь на исчерпание термина
модель данных).
Иерархическая модель

Эта ... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.