Области применения баз данных
КУРСОВАЯ РАБОТА
На тему: Области применения баз данных
Алматы 2008
Содержание
Введение 3
I. Системы управления базами данных (СУБД) и их структуры 4
1.1 Основные положения 4
1.2 Иерархическая и сетевая даталогические модели СУБД 7
1.3 Сетевые структуры 8
1.3.1 Файловая модель 9
1.4 Реляционные структуры 11
1.4.1 Реляционные даталогические модели СУБД 13
1.4.2 Объектно-ориентированные СУБД (ООСУБД) 15
1.5 Иерархические структуры 17
1.5.1 Иерархические структуры в реляционных базах данных 18
1.5.2 Вложенные рекурсивные иерархические данные 18
1.5.3 Отображение данных 19
II. РАЗЛИЧНЫЕ КЛАССЫ БАЗ ДАННЫХ ПО ПРЕДМЕТНЫМ ОБЛАСТЯМ ИСПОЛЬЗОВАНИЯ 21
2.1 Документальные и документографические БД 21
2.2 Система баз данных о продукции 24
2.3 Экономическая и конъюнктурная информация 27
2.4 Фактографические базы социальных данных 29
2.5 Базы данных транспортных систем страны 30
2.6 Справочные базы для населения и организаций. 30
2.7 Система ресурсных баз данных 31
2.8 Фактографические базы и банки научных данных 32
2.9 БД в области культуры и искусства 34
2.10 Лингвистические БД 34
Заключение 36
Список литературы 38
Введение
Основные идеи современной информационной технологии базируются на
концепции баз данных (БД). Согласно данной концепции основой информационной
технологии являются данные, организованные в БД, адекватно отражающие
реалии действительности в той или иной предметной области и обеспечивающие
пользователя актуальной информацией в соответствующей предметной области.
В первых четырех параграфах первой главы рассматриваются основные
системы управления базами данных, такие как иерархическая и сетевая
даталогическая модели, реляционные даталогические модели, объектно-
ориентированные СУБД. Обычно различают три класса СУБД, обеспечивающих
работу иерархических, сетевых и реляционных моделей. Однако различия между
этими классами постепенно стираются, причем, видимо, будут появляться
другие классы, что вызывается прежде всего интенсивными работами в области
баз знаний (БЗ) и объектно-ориентированной инфотехнологией. Поэтому
традиционной классификацией пользуются все реже, но мы пока будем
придерживаться именно ее, как наиболее устоявшейся. Каждая из указанных
моделей обладает характеристиками, делающими ее наиболее удобной для
конкретных приложений.
В пятом параграфе первой главы “Иерархические структуры” подробнее
описываются положительные и отрицательные черты иерархической модели.
Окружающий мир переполнен иерархическими данными. Любая группа объектов, в
которой один объект может быть “родителем” для произвольного числа других
объектов, организована в виде иерархического дерева. При работе с
иерархиями используется “семейная” терминология (родители, внуки, предки,
потомки), поскольку семья является самым распространённым примером объектов
(в данном случае – людей), объединённых иерархическими отношениями. В то же
время место объекта в иерархическом дереве - не более чем условное
обозначение связи с другими объектами. Иерархическая структура всего лишь
помогает сохранить и найти объект.
В данной работе я постаралась классифицировать существующие базы
данных, а так же оценить перспективы их развития в нашей стране.
Классификационным признаком является предметная область использования.
Целью данной работы является так же анализ наиболее распространенных
классов БД, получивших распространение и применение как в нашей стране, так
и за рубежом. Этому посвящена вся вторая глава.
В данной работе не акцентируется проблема передачи данных между БД, а
лишь исследуется архитектура и общая организация самих БД.
I. Системы управления базами данных (СУБД) и их структуры
Основные идеи современной информационной технологии базируются на
концепции баз данных (БД). Согласно данной концепции основой информационной
технологии являются данные, организованные в БД, адекватно отражающие
реалии действительности в той или иной предметной области и обеспечивающие
пользователя актуальной информацией в соответствующей предметной области.
Первые БД появились уже на заре 1-го поколения ЭВМ представляя собой
отдельные файлы данных или их простые coвокупности. По мере увеличения
объемов и структурной сложности хранимой информации, а также расширения
круга потребителей; информации определилась необходимость создания удобных
эффективных систем интеграции хранимых данных и управления ими. В конце 60-
х годов это привело к созданию первых коммерческих систем управления базами
данных (СУБД), поддерживающих opганизацию и ведение БД.
1 Основные положения
База данных (БД) в строгом смысле слова представляет собой совокупность
взаимосвязанных файлов данных определенной организации. БД, как правило,
включает целый ряд файлов, но может состоять и из единственного файла.
Данные, составляющие БД, отражают характеристики объектов и их отношений в
соответствующей прикладной области. Каждый файл, входящий в БД, содержит
определенное число записей (изменяемое в процессе функционирования БД),
отражающих ту или иную сторону предметной области, на которую ориентирована
БД. Как правило, файлы БД содержат большое число однотипных записей.
Записи, в свою очередь, состоят из полей, представляющих определенные типы
информации об объектах. Поле является наименьшей информационной единицей,
непосредственно доступной в записи. Если файл_1 БД (рис. 1) содержит п
однотипных записей (имеющих одинаковую структуру полей и их смысловую
нагрузку),то j-запись (1jn) файла состоит из фиксированного набора
(кортежа полей А1—Ак), каждое из которых содержит в общем случае различного
типа информацию. При наличии БД прикладные программы могут использовать ее
информацию (записи и их поля) для решения конкретных задач в прикладной
области, на которую ориентирована данная БД.
1 Поле А1 Поле А2 ... Поле Ак ... Поле S1 Поле S2 ... Поле Sd 1 2
Поле А1 Поле А2 ... Поле Ак ... Поле S1 Поле S2 ... Поле Sd 2 ... ...
... ... ... ... ... ... ... ... ... N Поле А1 Поле А2 ... Поле Ак ... Поле S1
Поле S2 ... Поле Sd P Файл_1 Файл_М Рис. 1
Файловая организация баз данных (файлы, записи, поля)
Пользователями БД являются четыре основные категории потребителей ее
информации иили поставщиков информации для нее: (1) конечные пользователи,
(2) программисты и системные аналитики, (3) персонал поддержки БД в
актуальном состоянии и (4) администратор БД. Хорошо спроектированные
системы управления БД (СУБД), используют развитые графические интерфейсы и
поддерживают системы отчетов, отвечающие специфике пользователей указанных
четырех категорий. В этом случае персонал поддержки БД и конечные
пользователи могут легко осваивать и использовать СУБД для обеспечения
своих потребностей без какой-либо специальной подготовки, т.е. специфика
функционирования данных систем скрыта от пользователя. Более того, хорошо
спроектированные СУБД предоставляют опытному пользователю средства для
создания собственных БД-приложений, не требуя от него специальной
программистской подготовки. Конечным пользователям для обеспечения доступа
к информации БД предоставляется графический интерфейс, как правило, в виде
системы окон с функциональными меню, позволяющими легко получать
необходимую информацию на экран иили принтер в виде удобно оформленных
отчетов.
Программисты и системные аналитики используют СУБД совершенно в ином
качестве, обеспечивая разработку новых БД-приложений, поддерживая и
модифицируя (при необходимости) уже существующие. Для данной группы
пользователей СУБД требуются средства, обеспечивающие указанные функции
(создание, откладка, редактирование и т.д.). Пользователи третьей категории
нуждаются в интерфейсе, как правило, графическом для обеспечения задач
поддержания БД в актуальном состоянии. Эти пользователи состоят в штатах
подразделений функциональных иили обработки информации, обеспечивающих
прикладную область, и отвечают за актуальное состояние соответствующей ей
БД (контроль текущего состояния, удаление устаревшей информации, добавление
новой и т.д.). Программисты выполняют своего рода посреднические функции
между БД и конечными пользователями. И если на первых этапах развития БД-
технологии они составляли весьма многочисленную группу пользователей, то в
процессе развития СУБД и, прежде всего, массового использования ПК эта
категория сходит на нет. Особую и ответственную роль выполняет
администратор, отвечающий как за актуальность находящейся в БД информации,
так и за корректность функционирования и использования БД и СУБД.
В случае больших БД может быть достаточно много конечных пользователей,
ряд программистов и несколько администраторов БД; в случае небольших БД
(что особенно характерно для ПК) все эти функции могут обеспечиваться одним
человеком. Важные функции выполняет администратор БД, отвечающий за
выработку требований к БД, ее проектирование, реализацию, эффективное
использование и сопровождение. Необходимость в таком специалисте вытекает
из принципа независимости данных, а также диктуется важностью БД в
деятельности организаций и более крупных объединений — поставщиков и
потребителей информации БД. Администратор БД взаимодействует с
пользователями в определении требований к базе в процессе выработки
требований к системе в целом, пользуется языком описания данных для
определения БД в процессе проектирования системы, взаимодействует с
программистами, которые создают ПС использующее доступ к БД, отвечает за
загрузку БД информацией в процессе реализации системы, контролирует
работоспособность БД, используя соответствующие программные и аппаратные
средства, и определяет, когда следует реорганизовывать данные в базе или
начать работы по созданию новой, более совершенной БД. В целом функции
администратора БД сводятся к поддержанию целостности БД, необходимого
уровня защиты ее данных и эффективности. Среди его наиболее важных
обязанностей — согласование конфликтующих требований, которое требуется
достаточно часто, ибо БД обслуживает, как правило, целый ряд различных
прикладных процессов.
Как уже отмечалось, БД представляет собой совокупность логически
взаимосвязанных файлов данных определенной организации; для определения и
обращения к такой файловой совокупности используют средства системы
управления БД (СУБД). СУБД представляет собой совокупность лингвистических
и программных средств, предназначенных для создания, ведения и совместного
использования БД многими пользователями. Тогда как под системой БД
понимается СУБД с наполненной соответствующей информацией БД, управляемой
ее средствами. Это означает, во-первых, что совокупность файлов БД
определяется посредством схемы, не зависящей от программ, которые к ней
обращаются, и, во-вторых, что она реализована на основе ВП прямого доступа.
Использование СУБД обеспечивает лучшее управление данными, более
совершенную организацию файлов и более простое обращение к ним по сравнению
с обычными способами хранения информации. Вследствие более совершенных
механизмов доступа БД, как правило, имеют более сложную организацию, чем
обычные файлы, объединяя данные, ранее хранящиеся во многих отдельных
файлах. Размер и сложность не являются определяющими характеристиками БД —
наличие СУБД для ПК и даже в среде ряда пакетов (например, табличных
процессоров, интегрированных и др.) приводит к созданию большого числа
относительно простых и небольших БД, достоинством которых (при наличии
соответствующих СУБД) являются простота определения и доступа к данным. Под
банком данных (БнД) понимается система лингвистических, программных,
аппаратных и организационных средств, основанная на БД-технологии и
предназначенная для централизованного накопления и коллективного
использования данных в той или иной прикладной области. Тогда как система
обработки информации (СОИ) реализует автоматизированный сбор, обработку и
хранение информации, включая соответствующие лингвистические, программные,
аппаратные, организационные средства и обслуживающий их персонал.
Под целостностью БД понимается актуальное состояние ее данных,
отражающих состояние некоторой реальной прикладной области и подчиняющихся
правилам непротиворечивости. Под языком БД понимается один или совокупность
языков, обеспечивающих описание данных, манипулирование с данными.
Конкретный язык БД всегда ассоциируется с конкретной СУБД. СУБД
представляет собой средства обработки на языке базы данных, позволяющие
обрабатывать обращения к БД, поступающие от прикладных программ иили
конечных пользователей, и поддерживать целостность БД. Таким образом, СУБД
имеет свойства, характерные как для компиляторов, так и для ОС, однако по
сравнению с первыми обеспечивается более высокий уровень абстрагирования,
что оказывается очень полезным как для программистов, так и для конечных
пользователей.
1.2 Иерархическая и сетевая даталогические модели СУБД
Каждая БД содержит и обрабатывает информацию из конкретной прикладной
области, представляющей интерес для определенных приложений. Описание
предметной области без акцента на ее последующие БД-реализации определяет
инфологическую модель предметной области. Инфологическая модель является
исходной для построения даталогической модели БД и служит промежуточной
моделью для специалистов предметной области (для которой создается БнД) и
администратора БД в процессе проектирования и разработки конкретной БД.
Под даталогической понимается модель, отражающая логические взаимосвязи
между элементами данных безотносительно их содержания и физической
организации. При этом даталогическая модель разрабатывается с учетом
конкретной реализации СУБД, также с учетом специфики конкретной предметной
области на основе ее инфологической модели. Для конкретной реализации
даталогической модели проектируется физическая модель, oтображающая первую
на конкретные программные и аппаратные средства (ОС, внешняя память, работа
с данными на физическом уровне и т.д.). Наполненная конкретной информацией
физическая модель и составляет собственно БД. Система, обеспечивающая
cоответствующее совместное функционирование указанных компонентов и
составляет суть конкретной СУБД.
Современные СУБД допускают целый ряд классификаций в зависимости от
уровня их рассмотрения (в целом либо по совокупности их функциональных
характеристик): по интерфейсу с пользователем в зависимости от
поддерживаемых моделей, по назначению и режиму функционирования, по способу
обработки информации и т.д. Мы кратко остановимся на моделях
даталогического уровня, который берется за основу большинства современных
классификаций СУБД.
Обычно различают три класса СУБД, обеспечивающих работу иерархических,
сетевых и реляционных моделей. Однако различия между этими классами
постепенно стираются, причем, видимо, будут появляться другие классы, что
вызывается прежде всего интенсивными работами в области баз знаний (БЗ) и
объектно-ориентированной инфотехнологией, о которой будет идти речь ниже.
Поэтому традиционной классификацией пользуются все реже, но мы пока будем
придерживаться именно ее, как наиболее устоявшуюся. Каждая из указанных
моделей обладает характеристиками, делающими ее наиболее удобной для
конкретных приложений. Одно из основных различий этих моделей состоит в
том, что для иерархических и сетевых СУБД их структура часто не может быть
изменена после ввода данных, тогда как для реляционных СУБД структура может
изменяться в любое время. С другой стороны, для больших БД, структура
которых остается длительное время неизменной, и постоянно работающих с ними
приложений с интенсивными потоками запросов на БД-обслуживание именно
иерархические и сетевые СУБД могут оказаться наиболее эффективными
решениями, ибо они могут обеспечивать более быстрый доступ к информации БД,
чем реляционные СУБД.
1.3 Сетевые структуры
Если в отношении между данными порожденный элемент имеет более одного
исходного элемента, то это отношение уже нельзя описать как древовидную или
иерархическую структуру. Его описывают в виде сетевой структуры. Любая
сетевая структура может быть приведена к более простому виду введением
избыточности. “БД постоянно грозит опасность стать громоздкими, застывшими
и слишком сложными системами. Новые приложения порождают новые виды
запросов пользователей к базе, что увеличивает набор логических связей
между ее элементами. В итоге многие системы БД оказываются очень сложными в
построении и эксплуатации. Если разработчики не придумают ясные и простые
схемы организации, эти системы будут подобны паутине” [К.Дейт.].
Сетевая модель более симметрична, чем иерархическая модель. Однако
процедуры (обновления) значительно сложнее. Проблема состоит в следующем:
всегда имеются две стратегии для определения места одного экземпляра
записи, первая начинается с "владельца" и просмотра его цепочки для выбора
звена, а другая начинается с "подчиненного звена" и просмотра его цепочки
для выбора "владельца". Как пользователь может решить, какую стратегию
принять? Выбор и здесь имеет большое значение. Как в иерархических, так и
сетевых СУБД при описании данных обычно указываются характеристики записей
каждого типа, способствующие более эффективному размещению данных во
внешней памяти и более быстрому доступу к ним. К таким характеристикам
относятся: размеры полей записи (минимальные, средние, максимальные),
состав ключа, допустимый набор символов, интервалы значений и т.д.
Иерархические и сетевые базы данных часто называют базами данных с
навигацией. Это название отражает технологию доступа к данным, используемую
при написании обрабатывающих программ на языке манипулирования данными. При
этом, очевидно, что доступ к данным по путям, не предусмотренным при
создании базы данных, может потребовать неразумно большого времени. Повышая
эффективность доступа к данным и сокращая таким образом время ответа на
запрос, принцип навигации вместе с этим повышает и степень зависимости
программ и данных. Обрабатывающие программы оказываются жестко привязанными
к текущему состоянию структуры базы данных и должны быть переписаны при ее
изменениях. Операции модификации и удаления данных требует переустановки
указателей, а манипулирование данными остается записеориентированным. Кроме
того, принцип навигации не позволяет существенно повышать уровень языка
манипулирования данными, чтобы сделать его доступным пользователю-
непрограммисту, или даже программисту-непрофессионалу. Для поиска записи-
цели в иерархической или сетевой структуре программист должен вначале
опеределить путь доступа, а затем просмотреть все записи, лежащие на этом
пути, - шаг за шагом.
Насколько запутанной являются схемы представления иерархических и
сетевых баз данных, настолько и трудоемким является проектирование
конкретных прикладных систем на их основе. Как показывает, опыт длительные
сроки разработки прикладных систем нередко приводят к тому, что они
постоянно находятся в стадии разработки и доработки.
Указанные и некоторые другие проблемы, с которыми столкнулись
разработчики и пользователи иерархических и сетевых систем послужили
стимулом к созданию реляционной модели данных и реляционных СУБД.
1.3.1 Файловая модель
Кратко рассмотрим файловую модель, неправомерно относимую довольно
часто к СУБД. Файловая модель представляет собой набор файлов данных
определенной структуры, но связь между данными этих файлов отсутствует.
Естественно, программные средства работы с таким образом организованной
инфобазой могут устанавливать связь между данными ее файлов, но на
концептуальном уровне файлы модели являются независимыми. Системы,
обеспечивающие работу с файловыми инфобазами, называют системами управления
файлами (СУФ) и они оказываются весьма эффективными во многих приложениях.
СУФ используются на всех классах ЭВМ, но особенно они распространены для
обработки информации на ПК. При этом во многих источниках они фигурируют в
качестве СУБД. Файловые системы легко осваиваются, достаточно просты и
эффективны в использовании и, как правило, для работы с ними используются
простые языки запросов либо и вовсе ограничиваются набором программ-утилит.
Такие системы обычно поддерживают работу с небольшим числом файлов,
содержащих ограниченное число записей с небольшим количеством полей.
Иерархические модели СУБД имеют древовидную структуру, когда каждому
узлу структуры соответствует один сегмент, представляющий собой
поименованный линейный кортеж полей данных. Каждому сегменту (кроме S1-
корневого) соответствует один входной и несколько выходных сегментов.
Каждый сегмент структуры лежит на единственном иерархическом пути,
начинающемся от корневого сегмента.
Для описания такой логической организации данных ЯОД достаточно
предусматривать для каждого сегмента данных только идентификацию входного
для него сегмента. Так как в иерархической модели каждому входному сегменту
данных соответствует N выходных, то такие модели весьма удобны для
представления отношений типа 1:N в предметной области. Следует отметить,
что в настоящее время не разрабатываются СУБД, поддерживающие на
концептуальном уровне только иерархические модели. Как правило,
использующие иерархический подход системы допускают связывание древовидных
структур между собой иили установление связей внутри них. Это приводит к
сетевым даталогическим моделям СУБД. К основным недостаткам иерархических
моделей следует отнести: неэффективность реализации отношений типа N:N,
медленный доступ к сегментам данных нижних уровней иерархии, четкая
ориентация на определенные типы запросов и др. В связи с этими недостатками
ранее созданные иерархические СУБД подвергаются существенным модификациям,
позволяющим поддерживать более сложные типы структур и, в первую очередь,
сетевые и их модификации. Сетевая даталогическая модель СУБД во многом
подобна иерархической: если в иерархической модели для каждого сегмента
записи допускается только один входной сегмент при N выходных, то в сетевой
модели для сегментов допускается несколько входных сегментов наряду с
возможностью наличия сегментов без входов с точки зрения иерархической
структуры. Графическое изображение структуры связей сегментов такого типа
моделей представляет собой сеть. Сегменты данных в сетевых БД могут иметь
множественные связи с сегментами старшего уровня. При этом направление и
характер связи в сетевых БД не являются столь очевидными, как в случае
иерархических БД. Поэтому имена и направление связей должны
идентифицироваться при описании БД средствами ЯОД.
Таким образом, под сетевой СУБД понимается система, поддерживающая
сетевую организацию: любая запись, называемая записью старшего уровня,
может содержать данные, которые относятся к набору других записей,
называемых записями подчиненного уровня. Возможно обращение ко всем записям
в наборе, начиная с записи старшего уровня. Обращение к набору записей
реализуется по указателям. В рамках сетевых СУБД легко реализуются и
иерархические даталогические модели. Сетевые СУБД поддерживают сложные
соотношения между типами данных, что делает их пригодными во многих
различных приложениях. Однако пользователи таких СУБД ограничены связями,
определенными для них разработчиками БД-приложений. Более того, подобно
иерархическим сетевые СУБД предполагают разработку БД приложений опытными
программистами и системными аналитиками.
Среди недостатков сетевых СУБД следует особо выделить проблему
обеспечения сохранности информации в БД, решению которой уделяется
повышенное внимание при проектировании сетевых БД.
1.4 Реляционные структуры
Реляционный подход стал широко известен благодаря первым работам
Е.Кодда, которые появились около 1970г. В течение долгого времени
реляционный подход рассматривался как удобный формальный аппарат анализа
баз данных, не имеющий практических перспектив, так как его реализация
требовала слишком больших машинных ресурсов. Только с появлением
персональных ЭВМ реляционные и близкие к ним системы неожиданно стали
распространяться, практически не оставив места другим моделям. Один из
самых естественных способов представления данных для пользователей - это
двумерная таблица. Она привычна для пользователя, понятна и обозрима, ее
легко запомнить. Поскольку любая сетевая структура может быть разложена в
совокупность древовидных структур, то и любое представление данных может
быть сведено к двумерным плоским файлам. Связи между данными могут быть
представлены в форме двумерных таблиц.
Таблица обладает следующими свойствами:
Каждый элемент таблицы представляет собой один элемент данных.
Повторяющиеся группы отсутствуют.
Все столбцы в таблице однородные. Это означает, что элементы столбца
имеют одинаковую природу.
Столбцам присвоены уникальные имена.
В таблице нет двух одинаковых строк.
Порядок расположения строк и столбцов в таблице безразличен. Таблица
такого рода называется отношением. База данных, построенная с помощью
отношений, называется реляционной базой данных.
Чем же принципиально отличаются реляционные модели от сетевых и
иерархических? Вкратце на это можно ответить следующим образом:
иерархические и сетевые модели данных - имеют связь по структуре, а
реляционные - имеют связь по значению. Проектирование баз данных
традиционно считалось очень трудной задачей. Реляционная технология
значительно упрощает эту задачу в трех различных направлениях:
Разделением логического и физического уровней системы она упрощает
процесс отображения "уровня реального мира", в структуру, которую система
может прямо поддерживать. Поскольку реляционная структура сама по себе
концептуально проста, она позволяет реализовывать небольшие иили простые
(и поэтому легкие для создания) базы данных, такие как персональные, сама
возможность реализации которых никогда даже бы не рассматривалась в старых
более сложных системах.
Теория и дисциплина нормализации может помочь, показывая, что
случается, если отношения не структурированы естественным образом.
Реляционная модель данных особенно удобна для использования в базах
данных распределенной архитектуры - она позволяет получать доступ к любым
информационным элементам, хранящимся в узлах сети ЭВМ. Необходимо обратить
особое внимание на высокоуровневый аспект реляционного подхода, который
состоит в множественной обработке записей. Благодаря этому значительно
возрастает потенциал реляционного подхода, который не может быть достигнут
при обработке по одной записи, и прежде всего это касается оптимизации. У
системы управления базами данных появляется возможность влиять на
эффективность реализации. В настоящее время на рынке программно-
математического обеспечения для ПЭВМ представлено более сотни различных
СУБД. Они сильно различаются по стоимости, по эффективности работы, по
функциональной мощности, по сложности изучения и использования.
Наиболее широкое распространение получили СУБД, использующие
реляционную модель данных, теоретической основой которой является логика
предикатов первого порядка и теория отношений. Одной из важнейших
характеристик как с точки зрения разработчика информационно-управляющих
систем, так и их пользователей является быстродействие СУБД, в силу чего
практически все фирмы мира-производители СУБД работают над проблемой
увеличения реактивности. Большинство известных коммерческих СУБД страдают
существенным недостатком: при работе с большими и сверхбольшими базами
данных резко снижается время реакции системы при выполнении процедур поиска
информации. Кроме того, появляющиеся в периодической печати результаты
тестирования коммерческих СУБД не всегда позволяют сделать вывод об
эффективности того или иного программного продукта, поскольку почти всегда
оцениваемым по времени результатом поиска является первая найденная запись,
а время ответа на сложные многоключевые запросы не оценивается, в то время
как время поиска всех записей, удовлетворяющих некоторому критерию, линейно
зависит от числа записей в базе, от числа записей-целей, от размеров
записи, и, следовательно, для больших баз измеряется значительным
интервалом времени.
Таким образом проведенный анализ систем управления базами данных,
ориентированных на различные модели данных, позволяет сделать вывод: в
распределенной интегрированной информационной системе возможно
использование СУБД реляционного типа.
1.4.1 Реляционные даталогические модели СУБД
СУБД реляционного типа являются наиболее распространенным на всех
классах ЭВМ, а на ПК занимают доминирующее положение. Данная модель
позволяет определять: (1) операции по запоминанию и поиску данных; (2)
ограничения, связанные с обеспечением целостности данных. Для увеличения
эффективности работы во многих СУБД реляционного типа приняты ограничения,
соответствующие строгой реляционной модели.
Многие реляционные СУБД представляют файлы БД для пользователя в
табличном формате — с записями в качестве строк и их полями в качестве
столбцов. В табличном виде информация воспринимается значительно легче.
Однако в БД на физическом уровне данные хранятся, как правило, в файлах,
содержащих последовательности записей. Основным преимуществом реляционных
СУБД является возможность связывания на основе определенных соотношений
файлов БД. Со структурной точки зрения реляционные модели являются более
простыми и однородными, чем иерархические и сетевые. В реляционной модели
каждому объекту предметной области соответствует одно или более отношений.
При необходимости определить связь между объектами явно, она выражается в
виде отношения, в котором в качестве атрибутов присутствуют идентификаторы
взаимосвязанных объектов. В реляционной модели объекты предметной области и
связи между ними представляются одинаковыми информационными конструкциями,
существенно упрощая саму модель.
СУБД считается реляционной при выполнении следующих двух условий,
предложенных еще Э. Коддом : (1) поддерживает реляционную структуру данных
и (2) реализует по крайней мере операции селекции, проекции и соединения
отношений. В последующем был создан целый ряд реляционных СУБД, в той или
иной мере отвечающих данному определению. Многие СУБД представляют собой
существенные расширения реляционной модели, другие являются смешанными,
поддерживая несколько даталогических моделей.
Реляционная СУБД должна четко отслеживать взаимосвязи записей в БД во
избежание потери или искажения информации. С этой целью СУБД постоянно
пересчитывает число связей для каждой записи БД в прямом и обратном
направлениях, что требует существенных временных затрат для больших БД.
Простота и стройность реляционной алгебры делают ее весьма привлекательной
для организации реляционных БД. Однако в действительности реальные данные
предметной области не укладываются в указанную модель (например, отношения
могут содержать повторяющиеся записи и т.д.). Поэтому наряду с сугубо
реляционными существуют и другие даталогические модели СУБД и их различные
модификации и сочетания, обеспечивая широкий круг решаемых на их основе
информационных, коммерческих, управленческих, финансовых, вычислительных и
других типов задач. Из наиболее известных примеров реляционных СУБД можно
отметить такие, как: dBase, DB2, ORACLE, Paradox и ряд других.
Массовое развитие класса ПК оказало весьма существенное влияние на
развитие инфотехнологии и БД-технологии в частности, привнося элементы
последней в массовую инфотехнологию. Прежде всего, этому способствовало
развитие мощной индустрии по созданию разнообразных СУБД для ПК. Если
создание СУБД для ЭВМ общего назначения и (в значительной мере) мини-ЭВМ
занимало длительный промежуток времени и число таких коммерческих СУБД было
невелико — практически весь их перечень был на слуху у специалистов по
компьютерной инфотехнологии, то с появлением класса ПК наряду с мощным
развитием для них ПС различного назначения начали быстро появляться СУБД.
При этом БД-технология начала активно проникать и в ПС другого назначения
(электронные таблицы, интегрированные и статистические пакеты и т.д.). К БД-
технологии были приобщены широкие круги пользователей ПК. Во многих
разработках для ПК начали применяться собственные СУБД различных
организации и назначения. На наш взгляд, ряд причин способствовал такому
массовому использованию БД-технологии:
— массовое использование ПК в приложениях, предопределяющих работу с
БД;
— резкое уменьшение цикла разработки ПС из-за персонального характера
работы;
— наличие достаточно развитых системных и инструментальных средств;
наличие внешней памяти большой емкости на "винчестерах".
Эти и другие причины обеспечили как широкий спрос на СУБД для ПК, так и
хорошие предпосылки для его быстрого удовлетворения. Наряду с мощными
фирмами, специализирующимися на разработке коммерческих СУБД к разработкам
иили адаптации уже готовых СУБД для ПК приступили и крупные фирмы, ранее
ориентированные в этой области на приложения к ЭВМ других классов (Oracle,
IBM, Relational Technology и др.). Все это способствовало интенсивному
проникновению БД-технологии в массовую инфообработку. С другой стороны,
широкое использование ПК в весьма обширном спектре прикладных областей
способствовало выдвижению к СУБД целого ряда актуальных требований и, в
первую очередь, по повышению уровня интерфейсов с пользователем и другими
приложениями.
Разработанное в настоящее время большое число различного назначения
СУБД позволяет создавать и эксплуатировать системы БД на всех классах и
типах ЭВМ, поддерживая различные даталогические модели и обеспечивая нужды
широкого круга приложений
Средства современных СУБД настолько разнообразны, что способны
удовлетворить потребности самого широкого круга пользователей — от
профессионала в области разработки систем БД различных типа и назначения до
пользователя, не обладающего достаточным уровнем компьютерной грамотности.
В первую очередь, это относится к СУБД, созданным для класса ПК. Эти СУБД
характеризуются не только своим количеством, но и функциональным
разнообразием: от простых файловых систем до функционально полных СУБД, в
основном реляционного типа. Многие из коммерческих СУБД поддерживают
многопользовательскую работу и работу в сетях ЭВМ, как локальных, так и
глобальных. К средствам, непосредственно относящимся к СУБД, можно отнести
и многочисленные средства их окружения: генераторы и конверторы данных и
программ, компиляторы языков программирования БД-приложений, генераторы
создания различного назначения и уровня интерфейсов с БД в рамках
традиционных ЯВУ и т.д.
Такое многообразие инструментальных и прикладных средств по СУБД
позволяет выбирать наиболее адекватные нуждам пользователя, обеспечивая
эффективное использование вычислительных ресурсов и существенное сокращение
сроков разработки конкретных БД-технологий. В подавляющем большинстве СУБД
для ПК ориентированы на интерактивный режим работы с пользователем, широко
используя удобные и дружелюбные системы интерфейсов на основе простых и
понятных меню. В СУБД, поддерживающих языки программирования БД-приложений,
средства такого интерфейса избавляют пользователя от необходимости знания
синтаксиса языка для обеспечения требуемых функций. Ряд популярных СУБД
предусматривают несколько уровней интерфейса, обеспечивающих работу с ними
различной квалификации пользователей (dBase IV, Paradox, др.). Большое
внимание уделено эффективной системе Help-информации по СУБД, включающей
электронные краткие обучающие курсы с демонстрацией наиболее часто
используемых приемов работы с конкретным пакетом.
Интенсивное расширение компьютерной инфотехнологии ставит перед
дальнейшим развитием СУБД целый ряд новых требований, во многом связанных с
вопросами стандартизации. Это относится не только к СУБД, но и к ПС других
типов. В отношении же СУБД это прежде всего относится к стандартизации
эталонной модели управления данными, предусматривающей четкую классификацию
основных вопросов стандартизации СУБД в зависимости от функциональных
особенностей и уровня описания данных на разных стадиях проектирования.
Можно предполагать, что последующее развитие СУБД будет ориентироваться на
рекомендации международных стандартов относительно языков БД и средств
доступа к удаленным БД, а также интерфейсов с системами программирования.
Новые интересные аспекты БД-технологии появляются на основе объектно-
ориентированной технологии программирования и обработки информации.
1.4.2 Объектно-ориентированные СУБД (ООСУБД)
В данном параграфе рассматриваются основные концепции, понятия, черты и
характеристики объектно-ориентированных систем управления БД (ООСУБД) в
контексте рассмотренных объектно-ориентированных программирования и
технологии. В последние годы в результате проникновения идеологии ООП в
СУБД интенсивные разработки теоретического и прикладного характера ведутся
по созданию различного назначения ООСУБД. Ввиду не совсем устоявшейся в
этом направлении терминологии отметим основные черты и характеристики,
определяющие СУБД как объектно-ориентированную. При этом по мере
необходимости проводятся сопоставления с рассмотренной выше концепцией ООП.
Характеристики ООСУБД подразделяются на три определяющие группы:
— базовые, определяющие принадлежность СУБД к объектно-ориентированному
классу;
— по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовыми;
— открытости, позволяющие пользователю делать осознанный выбор из ряда
одинаково приемлемых реализаций ООСУБД.
В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД
в ее классическом понимании и быть объектно-ориентированной системой (ООС),
т.е. в определенной степени она должна быть совместимой с современными
объектно-ориентированными ЯВУ. Первый критерий включает следующие пять
характеристик, присущих классической СУБД: сохранность данных, развитое
управление внешней памятью, возможность совмещения обработки и поиска
данных, поддержка средств восстановления и возможность быстрого доступа к
БД по запросу пользователя. Отмеченные характеристики в той или иной мере
обсуждались выше. Второй критерий предполагает наличие следующих
характеристик, присущих собственно объектно - ориентированной технологии:
понятие сложных объектов, идентичность объектов, инкапсуляция, типы или
классы, наследование, настройка (сочетающаяся с отложенным присвоением),
расширяемость и вычислительная полнота. Характеристики первого критерия
хорошо известны пользователям традиционных СУБД (dBase, R-Base, др.)
Сложные объекты строятся из более простых путем применения к ним
конструкторов. В качестве простых используются такие объекты. как: целые и
действительные числа, символы, символьные строки любой длины, булевы
величины и, возможно, другие первичные типы. В качестве конструкторов
сложных объектов (объектных конструкторов) могут выступать: кортежи,
множества, списки, массивы, таблицы и др. В качестве минимального набора
объектных конструкторов от ОООСУБД определяются: множество, кортеж, список
или массив. Множество дает естественную возможность представления
определенного набора объектов из имеющейся обширной совокупности; тогда как
кортеж позволяет представлять определенные свойства объекта. При этом
кортежи и множества имеют особое значение, получив широкое применение в
качестве объектных конструкторов в реляционных БД (РБД) Список или массив
играют важную роль при установлении порядка среди элементов множества.
Более того, указанные типы объектных конструкторов играют важную роль во
многих приложениях (векторно-матричные задачи, задачи анализа временных
рядов и др.).
Объектные конструкторы должны удовлетворять принципу ортогональности:
любой конструктор может применяться к любому объекту. Например,
конструкторы РБД не обладают данным свойством (так конструктор множества
может применяться только к кортежам, а конструктор кортежей — только к
первичным типам).
1.5 Иерархические структуры
Дерево представляет собой иерархию элементов, называемую узлами. На
самом верхнем уровне иерархии имеется только один узел - корень. Каждый
узел, кроме корня, связан с одним узлом на более высоком уровне, называемым
исходным узлом для данного узла. Ни один элемент не имеет более одного
исходного. Каждый элемент может быть связан с одним или нескольким
элементами на более низком уровне. Они называются порожденными.
Иерархические структуры относительно просто создаются и поддерживаются. Это
важно для ряда приложений, однако множество данных по своей природе не
связаны в древовидные структуры. Во многих структурах данных одна запись
требует более одного представления (поэтому приходится разрабатывать
способы объединения данных, которые по разному представляются различным
пользователям, в одну общую схему БД. В результате получаются обычно более
сложные структуры по сравнению с древовидными. Поэтому программное
обеспечение, сконструированное только для работы с древовидными
структурами, имеет ограниченное применение и не редко сильно влияет на
возможности увеличения объема и развития БД.
Принципиальным для иерархического представления данных является то, что
каждый экземпляр записи приобретает свой смысл только тогда, когда он
рассматривается в своем контексте; подчиненный экземпляр записи не может
существовать без своего предшественника по иерархии (несимметричность или
асимметрия). Асимметрия - основной недостаток иерархического подхода,
поскольку она затрудняет работу пользователя. В частности, пользователь
вынужден тратить время и усилия на решение проблем, связанных со спецификой
модели и никак не следующих из характера задаваемых вопросов. Очевидно, что
такие проблемы усугубляются по мере увеличения числа типов записей,
представленных в структуре, и по мере роста сложности иерархии. Кроме того,
иерархическая модель обладает еще некоторыми нежелательными свойствами
аномалии, которые ярко проявляются в связи с выполнением каждой из основных
операций запоминания (добавление, удаление, модификация).
Длительный опыт использования иерархических систем показал, что они
весьма эффективны лишь для достаточно простых задач, но они практически не
пригодны для использования в сложных системах с оперативной обработкой
транзакций и распределенной архитектурой. Иерархическая организация не
может обеспечить быстродействие, необходимое для работы в условиях
одновременного модифицирования файлов несколькими прикладными подсистемами.
1.5.1 Иерархические структуры в реляционных базах данных
Окружающий мир переполнен иерархическими данными. В это широкое понятие
входят компании, состоящие из дочерних компаний, филиалов, отделов и
рабочих групп; детали из которых собираются узлы, входящие затем в
механизмы; специальности, специализации и рабочие навыки; начальники и
подчинённые и т. д. Любая ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
На тему: Области применения баз данных
Алматы 2008
Содержание
Введение 3
I. Системы управления базами данных (СУБД) и их структуры 4
1.1 Основные положения 4
1.2 Иерархическая и сетевая даталогические модели СУБД 7
1.3 Сетевые структуры 8
1.3.1 Файловая модель 9
1.4 Реляционные структуры 11
1.4.1 Реляционные даталогические модели СУБД 13
1.4.2 Объектно-ориентированные СУБД (ООСУБД) 15
1.5 Иерархические структуры 17
1.5.1 Иерархические структуры в реляционных базах данных 18
1.5.2 Вложенные рекурсивные иерархические данные 18
1.5.3 Отображение данных 19
II. РАЗЛИЧНЫЕ КЛАССЫ БАЗ ДАННЫХ ПО ПРЕДМЕТНЫМ ОБЛАСТЯМ ИСПОЛЬЗОВАНИЯ 21
2.1 Документальные и документографические БД 21
2.2 Система баз данных о продукции 24
2.3 Экономическая и конъюнктурная информация 27
2.4 Фактографические базы социальных данных 29
2.5 Базы данных транспортных систем страны 30
2.6 Справочные базы для населения и организаций. 30
2.7 Система ресурсных баз данных 31
2.8 Фактографические базы и банки научных данных 32
2.9 БД в области культуры и искусства 34
2.10 Лингвистические БД 34
Заключение 36
Список литературы 38
Введение
Основные идеи современной информационной технологии базируются на
концепции баз данных (БД). Согласно данной концепции основой информационной
технологии являются данные, организованные в БД, адекватно отражающие
реалии действительности в той или иной предметной области и обеспечивающие
пользователя актуальной информацией в соответствующей предметной области.
В первых четырех параграфах первой главы рассматриваются основные
системы управления базами данных, такие как иерархическая и сетевая
даталогическая модели, реляционные даталогические модели, объектно-
ориентированные СУБД. Обычно различают три класса СУБД, обеспечивающих
работу иерархических, сетевых и реляционных моделей. Однако различия между
этими классами постепенно стираются, причем, видимо, будут появляться
другие классы, что вызывается прежде всего интенсивными работами в области
баз знаний (БЗ) и объектно-ориентированной инфотехнологией. Поэтому
традиционной классификацией пользуются все реже, но мы пока будем
придерживаться именно ее, как наиболее устоявшейся. Каждая из указанных
моделей обладает характеристиками, делающими ее наиболее удобной для
конкретных приложений.
В пятом параграфе первой главы “Иерархические структуры” подробнее
описываются положительные и отрицательные черты иерархической модели.
Окружающий мир переполнен иерархическими данными. Любая группа объектов, в
которой один объект может быть “родителем” для произвольного числа других
объектов, организована в виде иерархического дерева. При работе с
иерархиями используется “семейная” терминология (родители, внуки, предки,
потомки), поскольку семья является самым распространённым примером объектов
(в данном случае – людей), объединённых иерархическими отношениями. В то же
время место объекта в иерархическом дереве - не более чем условное
обозначение связи с другими объектами. Иерархическая структура всего лишь
помогает сохранить и найти объект.
В данной работе я постаралась классифицировать существующие базы
данных, а так же оценить перспективы их развития в нашей стране.
Классификационным признаком является предметная область использования.
Целью данной работы является так же анализ наиболее распространенных
классов БД, получивших распространение и применение как в нашей стране, так
и за рубежом. Этому посвящена вся вторая глава.
В данной работе не акцентируется проблема передачи данных между БД, а
лишь исследуется архитектура и общая организация самих БД.
I. Системы управления базами данных (СУБД) и их структуры
Основные идеи современной информационной технологии базируются на
концепции баз данных (БД). Согласно данной концепции основой информационной
технологии являются данные, организованные в БД, адекватно отражающие
реалии действительности в той или иной предметной области и обеспечивающие
пользователя актуальной информацией в соответствующей предметной области.
Первые БД появились уже на заре 1-го поколения ЭВМ представляя собой
отдельные файлы данных или их простые coвокупности. По мере увеличения
объемов и структурной сложности хранимой информации, а также расширения
круга потребителей; информации определилась необходимость создания удобных
эффективных систем интеграции хранимых данных и управления ими. В конце 60-
х годов это привело к созданию первых коммерческих систем управления базами
данных (СУБД), поддерживающих opганизацию и ведение БД.
1 Основные положения
База данных (БД) в строгом смысле слова представляет собой совокупность
взаимосвязанных файлов данных определенной организации. БД, как правило,
включает целый ряд файлов, но может состоять и из единственного файла.
Данные, составляющие БД, отражают характеристики объектов и их отношений в
соответствующей прикладной области. Каждый файл, входящий в БД, содержит
определенное число записей (изменяемое в процессе функционирования БД),
отражающих ту или иную сторону предметной области, на которую ориентирована
БД. Как правило, файлы БД содержат большое число однотипных записей.
Записи, в свою очередь, состоят из полей, представляющих определенные типы
информации об объектах. Поле является наименьшей информационной единицей,
непосредственно доступной в записи. Если файл_1 БД (рис. 1) содержит п
однотипных записей (имеющих одинаковую структуру полей и их смысловую
нагрузку),то j-запись (1jn) файла состоит из фиксированного набора
(кортежа полей А1—Ак), каждое из которых содержит в общем случае различного
типа информацию. При наличии БД прикладные программы могут использовать ее
информацию (записи и их поля) для решения конкретных задач в прикладной
области, на которую ориентирована данная БД.
1 Поле А1 Поле А2 ... Поле Ак ... Поле S1 Поле S2 ... Поле Sd 1 2
Поле А1 Поле А2 ... Поле Ак ... Поле S1 Поле S2 ... Поле Sd 2 ... ...
... ... ... ... ... ... ... ... ... N Поле А1 Поле А2 ... Поле Ак ... Поле S1
Поле S2 ... Поле Sd P Файл_1 Файл_М Рис. 1
Файловая организация баз данных (файлы, записи, поля)
Пользователями БД являются четыре основные категории потребителей ее
информации иили поставщиков информации для нее: (1) конечные пользователи,
(2) программисты и системные аналитики, (3) персонал поддержки БД в
актуальном состоянии и (4) администратор БД. Хорошо спроектированные
системы управления БД (СУБД), используют развитые графические интерфейсы и
поддерживают системы отчетов, отвечающие специфике пользователей указанных
четырех категорий. В этом случае персонал поддержки БД и конечные
пользователи могут легко осваивать и использовать СУБД для обеспечения
своих потребностей без какой-либо специальной подготовки, т.е. специфика
функционирования данных систем скрыта от пользователя. Более того, хорошо
спроектированные СУБД предоставляют опытному пользователю средства для
создания собственных БД-приложений, не требуя от него специальной
программистской подготовки. Конечным пользователям для обеспечения доступа
к информации БД предоставляется графический интерфейс, как правило, в виде
системы окон с функциональными меню, позволяющими легко получать
необходимую информацию на экран иили принтер в виде удобно оформленных
отчетов.
Программисты и системные аналитики используют СУБД совершенно в ином
качестве, обеспечивая разработку новых БД-приложений, поддерживая и
модифицируя (при необходимости) уже существующие. Для данной группы
пользователей СУБД требуются средства, обеспечивающие указанные функции
(создание, откладка, редактирование и т.д.). Пользователи третьей категории
нуждаются в интерфейсе, как правило, графическом для обеспечения задач
поддержания БД в актуальном состоянии. Эти пользователи состоят в штатах
подразделений функциональных иили обработки информации, обеспечивающих
прикладную область, и отвечают за актуальное состояние соответствующей ей
БД (контроль текущего состояния, удаление устаревшей информации, добавление
новой и т.д.). Программисты выполняют своего рода посреднические функции
между БД и конечными пользователями. И если на первых этапах развития БД-
технологии они составляли весьма многочисленную группу пользователей, то в
процессе развития СУБД и, прежде всего, массового использования ПК эта
категория сходит на нет. Особую и ответственную роль выполняет
администратор, отвечающий как за актуальность находящейся в БД информации,
так и за корректность функционирования и использования БД и СУБД.
В случае больших БД может быть достаточно много конечных пользователей,
ряд программистов и несколько администраторов БД; в случае небольших БД
(что особенно характерно для ПК) все эти функции могут обеспечиваться одним
человеком. Важные функции выполняет администратор БД, отвечающий за
выработку требований к БД, ее проектирование, реализацию, эффективное
использование и сопровождение. Необходимость в таком специалисте вытекает
из принципа независимости данных, а также диктуется важностью БД в
деятельности организаций и более крупных объединений — поставщиков и
потребителей информации БД. Администратор БД взаимодействует с
пользователями в определении требований к базе в процессе выработки
требований к системе в целом, пользуется языком описания данных для
определения БД в процессе проектирования системы, взаимодействует с
программистами, которые создают ПС использующее доступ к БД, отвечает за
загрузку БД информацией в процессе реализации системы, контролирует
работоспособность БД, используя соответствующие программные и аппаратные
средства, и определяет, когда следует реорганизовывать данные в базе или
начать работы по созданию новой, более совершенной БД. В целом функции
администратора БД сводятся к поддержанию целостности БД, необходимого
уровня защиты ее данных и эффективности. Среди его наиболее важных
обязанностей — согласование конфликтующих требований, которое требуется
достаточно часто, ибо БД обслуживает, как правило, целый ряд различных
прикладных процессов.
Как уже отмечалось, БД представляет собой совокупность логически
взаимосвязанных файлов данных определенной организации; для определения и
обращения к такой файловой совокупности используют средства системы
управления БД (СУБД). СУБД представляет собой совокупность лингвистических
и программных средств, предназначенных для создания, ведения и совместного
использования БД многими пользователями. Тогда как под системой БД
понимается СУБД с наполненной соответствующей информацией БД, управляемой
ее средствами. Это означает, во-первых, что совокупность файлов БД
определяется посредством схемы, не зависящей от программ, которые к ней
обращаются, и, во-вторых, что она реализована на основе ВП прямого доступа.
Использование СУБД обеспечивает лучшее управление данными, более
совершенную организацию файлов и более простое обращение к ним по сравнению
с обычными способами хранения информации. Вследствие более совершенных
механизмов доступа БД, как правило, имеют более сложную организацию, чем
обычные файлы, объединяя данные, ранее хранящиеся во многих отдельных
файлах. Размер и сложность не являются определяющими характеристиками БД —
наличие СУБД для ПК и даже в среде ряда пакетов (например, табличных
процессоров, интегрированных и др.) приводит к созданию большого числа
относительно простых и небольших БД, достоинством которых (при наличии
соответствующих СУБД) являются простота определения и доступа к данным. Под
банком данных (БнД) понимается система лингвистических, программных,
аппаратных и организационных средств, основанная на БД-технологии и
предназначенная для централизованного накопления и коллективного
использования данных в той или иной прикладной области. Тогда как система
обработки информации (СОИ) реализует автоматизированный сбор, обработку и
хранение информации, включая соответствующие лингвистические, программные,
аппаратные, организационные средства и обслуживающий их персонал.
Под целостностью БД понимается актуальное состояние ее данных,
отражающих состояние некоторой реальной прикладной области и подчиняющихся
правилам непротиворечивости. Под языком БД понимается один или совокупность
языков, обеспечивающих описание данных, манипулирование с данными.
Конкретный язык БД всегда ассоциируется с конкретной СУБД. СУБД
представляет собой средства обработки на языке базы данных, позволяющие
обрабатывать обращения к БД, поступающие от прикладных программ иили
конечных пользователей, и поддерживать целостность БД. Таким образом, СУБД
имеет свойства, характерные как для компиляторов, так и для ОС, однако по
сравнению с первыми обеспечивается более высокий уровень абстрагирования,
что оказывается очень полезным как для программистов, так и для конечных
пользователей.
1.2 Иерархическая и сетевая даталогические модели СУБД
Каждая БД содержит и обрабатывает информацию из конкретной прикладной
области, представляющей интерес для определенных приложений. Описание
предметной области без акцента на ее последующие БД-реализации определяет
инфологическую модель предметной области. Инфологическая модель является
исходной для построения даталогической модели БД и служит промежуточной
моделью для специалистов предметной области (для которой создается БнД) и
администратора БД в процессе проектирования и разработки конкретной БД.
Под даталогической понимается модель, отражающая логические взаимосвязи
между элементами данных безотносительно их содержания и физической
организации. При этом даталогическая модель разрабатывается с учетом
конкретной реализации СУБД, также с учетом специфики конкретной предметной
области на основе ее инфологической модели. Для конкретной реализации
даталогической модели проектируется физическая модель, oтображающая первую
на конкретные программные и аппаратные средства (ОС, внешняя память, работа
с данными на физическом уровне и т.д.). Наполненная конкретной информацией
физическая модель и составляет собственно БД. Система, обеспечивающая
cоответствующее совместное функционирование указанных компонентов и
составляет суть конкретной СУБД.
Современные СУБД допускают целый ряд классификаций в зависимости от
уровня их рассмотрения (в целом либо по совокупности их функциональных
характеристик): по интерфейсу с пользователем в зависимости от
поддерживаемых моделей, по назначению и режиму функционирования, по способу
обработки информации и т.д. Мы кратко остановимся на моделях
даталогического уровня, который берется за основу большинства современных
классификаций СУБД.
Обычно различают три класса СУБД, обеспечивающих работу иерархических,
сетевых и реляционных моделей. Однако различия между этими классами
постепенно стираются, причем, видимо, будут появляться другие классы, что
вызывается прежде всего интенсивными работами в области баз знаний (БЗ) и
объектно-ориентированной инфотехнологией, о которой будет идти речь ниже.
Поэтому традиционной классификацией пользуются все реже, но мы пока будем
придерживаться именно ее, как наиболее устоявшуюся. Каждая из указанных
моделей обладает характеристиками, делающими ее наиболее удобной для
конкретных приложений. Одно из основных различий этих моделей состоит в
том, что для иерархических и сетевых СУБД их структура часто не может быть
изменена после ввода данных, тогда как для реляционных СУБД структура может
изменяться в любое время. С другой стороны, для больших БД, структура
которых остается длительное время неизменной, и постоянно работающих с ними
приложений с интенсивными потоками запросов на БД-обслуживание именно
иерархические и сетевые СУБД могут оказаться наиболее эффективными
решениями, ибо они могут обеспечивать более быстрый доступ к информации БД,
чем реляционные СУБД.
1.3 Сетевые структуры
Если в отношении между данными порожденный элемент имеет более одного
исходного элемента, то это отношение уже нельзя описать как древовидную или
иерархическую структуру. Его описывают в виде сетевой структуры. Любая
сетевая структура может быть приведена к более простому виду введением
избыточности. “БД постоянно грозит опасность стать громоздкими, застывшими
и слишком сложными системами. Новые приложения порождают новые виды
запросов пользователей к базе, что увеличивает набор логических связей
между ее элементами. В итоге многие системы БД оказываются очень сложными в
построении и эксплуатации. Если разработчики не придумают ясные и простые
схемы организации, эти системы будут подобны паутине” [К.Дейт.].
Сетевая модель более симметрична, чем иерархическая модель. Однако
процедуры (обновления) значительно сложнее. Проблема состоит в следующем:
всегда имеются две стратегии для определения места одного экземпляра
записи, первая начинается с "владельца" и просмотра его цепочки для выбора
звена, а другая начинается с "подчиненного звена" и просмотра его цепочки
для выбора "владельца". Как пользователь может решить, какую стратегию
принять? Выбор и здесь имеет большое значение. Как в иерархических, так и
сетевых СУБД при описании данных обычно указываются характеристики записей
каждого типа, способствующие более эффективному размещению данных во
внешней памяти и более быстрому доступу к ним. К таким характеристикам
относятся: размеры полей записи (минимальные, средние, максимальные),
состав ключа, допустимый набор символов, интервалы значений и т.д.
Иерархические и сетевые базы данных часто называют базами данных с
навигацией. Это название отражает технологию доступа к данным, используемую
при написании обрабатывающих программ на языке манипулирования данными. При
этом, очевидно, что доступ к данным по путям, не предусмотренным при
создании базы данных, может потребовать неразумно большого времени. Повышая
эффективность доступа к данным и сокращая таким образом время ответа на
запрос, принцип навигации вместе с этим повышает и степень зависимости
программ и данных. Обрабатывающие программы оказываются жестко привязанными
к текущему состоянию структуры базы данных и должны быть переписаны при ее
изменениях. Операции модификации и удаления данных требует переустановки
указателей, а манипулирование данными остается записеориентированным. Кроме
того, принцип навигации не позволяет существенно повышать уровень языка
манипулирования данными, чтобы сделать его доступным пользователю-
непрограммисту, или даже программисту-непрофессионалу. Для поиска записи-
цели в иерархической или сетевой структуре программист должен вначале
опеределить путь доступа, а затем просмотреть все записи, лежащие на этом
пути, - шаг за шагом.
Насколько запутанной являются схемы представления иерархических и
сетевых баз данных, настолько и трудоемким является проектирование
конкретных прикладных систем на их основе. Как показывает, опыт длительные
сроки разработки прикладных систем нередко приводят к тому, что они
постоянно находятся в стадии разработки и доработки.
Указанные и некоторые другие проблемы, с которыми столкнулись
разработчики и пользователи иерархических и сетевых систем послужили
стимулом к созданию реляционной модели данных и реляционных СУБД.
1.3.1 Файловая модель
Кратко рассмотрим файловую модель, неправомерно относимую довольно
часто к СУБД. Файловая модель представляет собой набор файлов данных
определенной структуры, но связь между данными этих файлов отсутствует.
Естественно, программные средства работы с таким образом организованной
инфобазой могут устанавливать связь между данными ее файлов, но на
концептуальном уровне файлы модели являются независимыми. Системы,
обеспечивающие работу с файловыми инфобазами, называют системами управления
файлами (СУФ) и они оказываются весьма эффективными во многих приложениях.
СУФ используются на всех классах ЭВМ, но особенно они распространены для
обработки информации на ПК. При этом во многих источниках они фигурируют в
качестве СУБД. Файловые системы легко осваиваются, достаточно просты и
эффективны в использовании и, как правило, для работы с ними используются
простые языки запросов либо и вовсе ограничиваются набором программ-утилит.
Такие системы обычно поддерживают работу с небольшим числом файлов,
содержащих ограниченное число записей с небольшим количеством полей.
Иерархические модели СУБД имеют древовидную структуру, когда каждому
узлу структуры соответствует один сегмент, представляющий собой
поименованный линейный кортеж полей данных. Каждому сегменту (кроме S1-
корневого) соответствует один входной и несколько выходных сегментов.
Каждый сегмент структуры лежит на единственном иерархическом пути,
начинающемся от корневого сегмента.
Для описания такой логической организации данных ЯОД достаточно
предусматривать для каждого сегмента данных только идентификацию входного
для него сегмента. Так как в иерархической модели каждому входному сегменту
данных соответствует N выходных, то такие модели весьма удобны для
представления отношений типа 1:N в предметной области. Следует отметить,
что в настоящее время не разрабатываются СУБД, поддерживающие на
концептуальном уровне только иерархические модели. Как правило,
использующие иерархический подход системы допускают связывание древовидных
структур между собой иили установление связей внутри них. Это приводит к
сетевым даталогическим моделям СУБД. К основным недостаткам иерархических
моделей следует отнести: неэффективность реализации отношений типа N:N,
медленный доступ к сегментам данных нижних уровней иерархии, четкая
ориентация на определенные типы запросов и др. В связи с этими недостатками
ранее созданные иерархические СУБД подвергаются существенным модификациям,
позволяющим поддерживать более сложные типы структур и, в первую очередь,
сетевые и их модификации. Сетевая даталогическая модель СУБД во многом
подобна иерархической: если в иерархической модели для каждого сегмента
записи допускается только один входной сегмент при N выходных, то в сетевой
модели для сегментов допускается несколько входных сегментов наряду с
возможностью наличия сегментов без входов с точки зрения иерархической
структуры. Графическое изображение структуры связей сегментов такого типа
моделей представляет собой сеть. Сегменты данных в сетевых БД могут иметь
множественные связи с сегментами старшего уровня. При этом направление и
характер связи в сетевых БД не являются столь очевидными, как в случае
иерархических БД. Поэтому имена и направление связей должны
идентифицироваться при описании БД средствами ЯОД.
Таким образом, под сетевой СУБД понимается система, поддерживающая
сетевую организацию: любая запись, называемая записью старшего уровня,
может содержать данные, которые относятся к набору других записей,
называемых записями подчиненного уровня. Возможно обращение ко всем записям
в наборе, начиная с записи старшего уровня. Обращение к набору записей
реализуется по указателям. В рамках сетевых СУБД легко реализуются и
иерархические даталогические модели. Сетевые СУБД поддерживают сложные
соотношения между типами данных, что делает их пригодными во многих
различных приложениях. Однако пользователи таких СУБД ограничены связями,
определенными для них разработчиками БД-приложений. Более того, подобно
иерархическим сетевые СУБД предполагают разработку БД приложений опытными
программистами и системными аналитиками.
Среди недостатков сетевых СУБД следует особо выделить проблему
обеспечения сохранности информации в БД, решению которой уделяется
повышенное внимание при проектировании сетевых БД.
1.4 Реляционные структуры
Реляционный подход стал широко известен благодаря первым работам
Е.Кодда, которые появились около 1970г. В течение долгого времени
реляционный подход рассматривался как удобный формальный аппарат анализа
баз данных, не имеющий практических перспектив, так как его реализация
требовала слишком больших машинных ресурсов. Только с появлением
персональных ЭВМ реляционные и близкие к ним системы неожиданно стали
распространяться, практически не оставив места другим моделям. Один из
самых естественных способов представления данных для пользователей - это
двумерная таблица. Она привычна для пользователя, понятна и обозрима, ее
легко запомнить. Поскольку любая сетевая структура может быть разложена в
совокупность древовидных структур, то и любое представление данных может
быть сведено к двумерным плоским файлам. Связи между данными могут быть
представлены в форме двумерных таблиц.
Таблица обладает следующими свойствами:
Каждый элемент таблицы представляет собой один элемент данных.
Повторяющиеся группы отсутствуют.
Все столбцы в таблице однородные. Это означает, что элементы столбца
имеют одинаковую природу.
Столбцам присвоены уникальные имена.
В таблице нет двух одинаковых строк.
Порядок расположения строк и столбцов в таблице безразличен. Таблица
такого рода называется отношением. База данных, построенная с помощью
отношений, называется реляционной базой данных.
Чем же принципиально отличаются реляционные модели от сетевых и
иерархических? Вкратце на это можно ответить следующим образом:
иерархические и сетевые модели данных - имеют связь по структуре, а
реляционные - имеют связь по значению. Проектирование баз данных
традиционно считалось очень трудной задачей. Реляционная технология
значительно упрощает эту задачу в трех различных направлениях:
Разделением логического и физического уровней системы она упрощает
процесс отображения "уровня реального мира", в структуру, которую система
может прямо поддерживать. Поскольку реляционная структура сама по себе
концептуально проста, она позволяет реализовывать небольшие иили простые
(и поэтому легкие для создания) базы данных, такие как персональные, сама
возможность реализации которых никогда даже бы не рассматривалась в старых
более сложных системах.
Теория и дисциплина нормализации может помочь, показывая, что
случается, если отношения не структурированы естественным образом.
Реляционная модель данных особенно удобна для использования в базах
данных распределенной архитектуры - она позволяет получать доступ к любым
информационным элементам, хранящимся в узлах сети ЭВМ. Необходимо обратить
особое внимание на высокоуровневый аспект реляционного подхода, который
состоит в множественной обработке записей. Благодаря этому значительно
возрастает потенциал реляционного подхода, который не может быть достигнут
при обработке по одной записи, и прежде всего это касается оптимизации. У
системы управления базами данных появляется возможность влиять на
эффективность реализации. В настоящее время на рынке программно-
математического обеспечения для ПЭВМ представлено более сотни различных
СУБД. Они сильно различаются по стоимости, по эффективности работы, по
функциональной мощности, по сложности изучения и использования.
Наиболее широкое распространение получили СУБД, использующие
реляционную модель данных, теоретической основой которой является логика
предикатов первого порядка и теория отношений. Одной из важнейших
характеристик как с точки зрения разработчика информационно-управляющих
систем, так и их пользователей является быстродействие СУБД, в силу чего
практически все фирмы мира-производители СУБД работают над проблемой
увеличения реактивности. Большинство известных коммерческих СУБД страдают
существенным недостатком: при работе с большими и сверхбольшими базами
данных резко снижается время реакции системы при выполнении процедур поиска
информации. Кроме того, появляющиеся в периодической печати результаты
тестирования коммерческих СУБД не всегда позволяют сделать вывод об
эффективности того или иного программного продукта, поскольку почти всегда
оцениваемым по времени результатом поиска является первая найденная запись,
а время ответа на сложные многоключевые запросы не оценивается, в то время
как время поиска всех записей, удовлетворяющих некоторому критерию, линейно
зависит от числа записей в базе, от числа записей-целей, от размеров
записи, и, следовательно, для больших баз измеряется значительным
интервалом времени.
Таким образом проведенный анализ систем управления базами данных,
ориентированных на различные модели данных, позволяет сделать вывод: в
распределенной интегрированной информационной системе возможно
использование СУБД реляционного типа.
1.4.1 Реляционные даталогические модели СУБД
СУБД реляционного типа являются наиболее распространенным на всех
классах ЭВМ, а на ПК занимают доминирующее положение. Данная модель
позволяет определять: (1) операции по запоминанию и поиску данных; (2)
ограничения, связанные с обеспечением целостности данных. Для увеличения
эффективности работы во многих СУБД реляционного типа приняты ограничения,
соответствующие строгой реляционной модели.
Многие реляционные СУБД представляют файлы БД для пользователя в
табличном формате — с записями в качестве строк и их полями в качестве
столбцов. В табличном виде информация воспринимается значительно легче.
Однако в БД на физическом уровне данные хранятся, как правило, в файлах,
содержащих последовательности записей. Основным преимуществом реляционных
СУБД является возможность связывания на основе определенных соотношений
файлов БД. Со структурной точки зрения реляционные модели являются более
простыми и однородными, чем иерархические и сетевые. В реляционной модели
каждому объекту предметной области соответствует одно или более отношений.
При необходимости определить связь между объектами явно, она выражается в
виде отношения, в котором в качестве атрибутов присутствуют идентификаторы
взаимосвязанных объектов. В реляционной модели объекты предметной области и
связи между ними представляются одинаковыми информационными конструкциями,
существенно упрощая саму модель.
СУБД считается реляционной при выполнении следующих двух условий,
предложенных еще Э. Коддом : (1) поддерживает реляционную структуру данных
и (2) реализует по крайней мере операции селекции, проекции и соединения
отношений. В последующем был создан целый ряд реляционных СУБД, в той или
иной мере отвечающих данному определению. Многие СУБД представляют собой
существенные расширения реляционной модели, другие являются смешанными,
поддерживая несколько даталогических моделей.
Реляционная СУБД должна четко отслеживать взаимосвязи записей в БД во
избежание потери или искажения информации. С этой целью СУБД постоянно
пересчитывает число связей для каждой записи БД в прямом и обратном
направлениях, что требует существенных временных затрат для больших БД.
Простота и стройность реляционной алгебры делают ее весьма привлекательной
для организации реляционных БД. Однако в действительности реальные данные
предметной области не укладываются в указанную модель (например, отношения
могут содержать повторяющиеся записи и т.д.). Поэтому наряду с сугубо
реляционными существуют и другие даталогические модели СУБД и их различные
модификации и сочетания, обеспечивая широкий круг решаемых на их основе
информационных, коммерческих, управленческих, финансовых, вычислительных и
других типов задач. Из наиболее известных примеров реляционных СУБД можно
отметить такие, как: dBase, DB2, ORACLE, Paradox и ряд других.
Массовое развитие класса ПК оказало весьма существенное влияние на
развитие инфотехнологии и БД-технологии в частности, привнося элементы
последней в массовую инфотехнологию. Прежде всего, этому способствовало
развитие мощной индустрии по созданию разнообразных СУБД для ПК. Если
создание СУБД для ЭВМ общего назначения и (в значительной мере) мини-ЭВМ
занимало длительный промежуток времени и число таких коммерческих СУБД было
невелико — практически весь их перечень был на слуху у специалистов по
компьютерной инфотехнологии, то с появлением класса ПК наряду с мощным
развитием для них ПС различного назначения начали быстро появляться СУБД.
При этом БД-технология начала активно проникать и в ПС другого назначения
(электронные таблицы, интегрированные и статистические пакеты и т.д.). К БД-
технологии были приобщены широкие круги пользователей ПК. Во многих
разработках для ПК начали применяться собственные СУБД различных
организации и назначения. На наш взгляд, ряд причин способствовал такому
массовому использованию БД-технологии:
— массовое использование ПК в приложениях, предопределяющих работу с
БД;
— резкое уменьшение цикла разработки ПС из-за персонального характера
работы;
— наличие достаточно развитых системных и инструментальных средств;
наличие внешней памяти большой емкости на "винчестерах".
Эти и другие причины обеспечили как широкий спрос на СУБД для ПК, так и
хорошие предпосылки для его быстрого удовлетворения. Наряду с мощными
фирмами, специализирующимися на разработке коммерческих СУБД к разработкам
иили адаптации уже готовых СУБД для ПК приступили и крупные фирмы, ранее
ориентированные в этой области на приложения к ЭВМ других классов (Oracle,
IBM, Relational Technology и др.). Все это способствовало интенсивному
проникновению БД-технологии в массовую инфообработку. С другой стороны,
широкое использование ПК в весьма обширном спектре прикладных областей
способствовало выдвижению к СУБД целого ряда актуальных требований и, в
первую очередь, по повышению уровня интерфейсов с пользователем и другими
приложениями.
Разработанное в настоящее время большое число различного назначения
СУБД позволяет создавать и эксплуатировать системы БД на всех классах и
типах ЭВМ, поддерживая различные даталогические модели и обеспечивая нужды
широкого круга приложений
Средства современных СУБД настолько разнообразны, что способны
удовлетворить потребности самого широкого круга пользователей — от
профессионала в области разработки систем БД различных типа и назначения до
пользователя, не обладающего достаточным уровнем компьютерной грамотности.
В первую очередь, это относится к СУБД, созданным для класса ПК. Эти СУБД
характеризуются не только своим количеством, но и функциональным
разнообразием: от простых файловых систем до функционально полных СУБД, в
основном реляционного типа. Многие из коммерческих СУБД поддерживают
многопользовательскую работу и работу в сетях ЭВМ, как локальных, так и
глобальных. К средствам, непосредственно относящимся к СУБД, можно отнести
и многочисленные средства их окружения: генераторы и конверторы данных и
программ, компиляторы языков программирования БД-приложений, генераторы
создания различного назначения и уровня интерфейсов с БД в рамках
традиционных ЯВУ и т.д.
Такое многообразие инструментальных и прикладных средств по СУБД
позволяет выбирать наиболее адекватные нуждам пользователя, обеспечивая
эффективное использование вычислительных ресурсов и существенное сокращение
сроков разработки конкретных БД-технологий. В подавляющем большинстве СУБД
для ПК ориентированы на интерактивный режим работы с пользователем, широко
используя удобные и дружелюбные системы интерфейсов на основе простых и
понятных меню. В СУБД, поддерживающих языки программирования БД-приложений,
средства такого интерфейса избавляют пользователя от необходимости знания
синтаксиса языка для обеспечения требуемых функций. Ряд популярных СУБД
предусматривают несколько уровней интерфейса, обеспечивающих работу с ними
различной квалификации пользователей (dBase IV, Paradox, др.). Большое
внимание уделено эффективной системе Help-информации по СУБД, включающей
электронные краткие обучающие курсы с демонстрацией наиболее часто
используемых приемов работы с конкретным пакетом.
Интенсивное расширение компьютерной инфотехнологии ставит перед
дальнейшим развитием СУБД целый ряд новых требований, во многом связанных с
вопросами стандартизации. Это относится не только к СУБД, но и к ПС других
типов. В отношении же СУБД это прежде всего относится к стандартизации
эталонной модели управления данными, предусматривающей четкую классификацию
основных вопросов стандартизации СУБД в зависимости от функциональных
особенностей и уровня описания данных на разных стадиях проектирования.
Можно предполагать, что последующее развитие СУБД будет ориентироваться на
рекомендации международных стандартов относительно языков БД и средств
доступа к удаленным БД, а также интерфейсов с системами программирования.
Новые интересные аспекты БД-технологии появляются на основе объектно-
ориентированной технологии программирования и обработки информации.
1.4.2 Объектно-ориентированные СУБД (ООСУБД)
В данном параграфе рассматриваются основные концепции, понятия, черты и
характеристики объектно-ориентированных систем управления БД (ООСУБД) в
контексте рассмотренных объектно-ориентированных программирования и
технологии. В последние годы в результате проникновения идеологии ООП в
СУБД интенсивные разработки теоретического и прикладного характера ведутся
по созданию различного назначения ООСУБД. Ввиду не совсем устоявшейся в
этом направлении терминологии отметим основные черты и характеристики,
определяющие СУБД как объектно-ориентированную. При этом по мере
необходимости проводятся сопоставления с рассмотренной выше концепцией ООП.
Характеристики ООСУБД подразделяются на три определяющие группы:
— базовые, определяющие принадлежность СУБД к объектно-ориентированному
классу;
— по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовыми;
— открытости, позволяющие пользователю делать осознанный выбор из ряда
одинаково приемлемых реализаций ООСУБД.
В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД
в ее классическом понимании и быть объектно-ориентированной системой (ООС),
т.е. в определенной степени она должна быть совместимой с современными
объектно-ориентированными ЯВУ. Первый критерий включает следующие пять
характеристик, присущих классической СУБД: сохранность данных, развитое
управление внешней памятью, возможность совмещения обработки и поиска
данных, поддержка средств восстановления и возможность быстрого доступа к
БД по запросу пользователя. Отмеченные характеристики в той или иной мере
обсуждались выше. Второй критерий предполагает наличие следующих
характеристик, присущих собственно объектно - ориентированной технологии:
понятие сложных объектов, идентичность объектов, инкапсуляция, типы или
классы, наследование, настройка (сочетающаяся с отложенным присвоением),
расширяемость и вычислительная полнота. Характеристики первого критерия
хорошо известны пользователям традиционных СУБД (dBase, R-Base, др.)
Сложные объекты строятся из более простых путем применения к ним
конструкторов. В качестве простых используются такие объекты. как: целые и
действительные числа, символы, символьные строки любой длины, булевы
величины и, возможно, другие первичные типы. В качестве конструкторов
сложных объектов (объектных конструкторов) могут выступать: кортежи,
множества, списки, массивы, таблицы и др. В качестве минимального набора
объектных конструкторов от ОООСУБД определяются: множество, кортеж, список
или массив. Множество дает естественную возможность представления
определенного набора объектов из имеющейся обширной совокупности; тогда как
кортеж позволяет представлять определенные свойства объекта. При этом
кортежи и множества имеют особое значение, получив широкое применение в
качестве объектных конструкторов в реляционных БД (РБД) Список или массив
играют важную роль при установлении порядка среди элементов множества.
Более того, указанные типы объектных конструкторов играют важную роль во
многих приложениях (векторно-матричные задачи, задачи анализа временных
рядов и др.).
Объектные конструкторы должны удовлетворять принципу ортогональности:
любой конструктор может применяться к любому объекту. Например,
конструкторы РБД не обладают данным свойством (так конструктор множества
может применяться только к кортежам, а конструктор кортежей — только к
первичным типам).
1.5 Иерархические структуры
Дерево представляет собой иерархию элементов, называемую узлами. На
самом верхнем уровне иерархии имеется только один узел - корень. Каждый
узел, кроме корня, связан с одним узлом на более высоком уровне, называемым
исходным узлом для данного узла. Ни один элемент не имеет более одного
исходного. Каждый элемент может быть связан с одним или нескольким
элементами на более низком уровне. Они называются порожденными.
Иерархические структуры относительно просто создаются и поддерживаются. Это
важно для ряда приложений, однако множество данных по своей природе не
связаны в древовидные структуры. Во многих структурах данных одна запись
требует более одного представления (поэтому приходится разрабатывать
способы объединения данных, которые по разному представляются различным
пользователям, в одну общую схему БД. В результате получаются обычно более
сложные структуры по сравнению с древовидными. Поэтому программное
обеспечение, сконструированное только для работы с древовидными
структурами, имеет ограниченное применение и не редко сильно влияет на
возможности увеличения объема и развития БД.
Принципиальным для иерархического представления данных является то, что
каждый экземпляр записи приобретает свой смысл только тогда, когда он
рассматривается в своем контексте; подчиненный экземпляр записи не может
существовать без своего предшественника по иерархии (несимметричность или
асимметрия). Асимметрия - основной недостаток иерархического подхода,
поскольку она затрудняет работу пользователя. В частности, пользователь
вынужден тратить время и усилия на решение проблем, связанных со спецификой
модели и никак не следующих из характера задаваемых вопросов. Очевидно, что
такие проблемы усугубляются по мере увеличения числа типов записей,
представленных в структуре, и по мере роста сложности иерархии. Кроме того,
иерархическая модель обладает еще некоторыми нежелательными свойствами
аномалии, которые ярко проявляются в связи с выполнением каждой из основных
операций запоминания (добавление, удаление, модификация).
Длительный опыт использования иерархических систем показал, что они
весьма эффективны лишь для достаточно простых задач, но они практически не
пригодны для использования в сложных системах с оперативной обработкой
транзакций и распределенной архитектурой. Иерархическая организация не
может обеспечить быстродействие, необходимое для работы в условиях
одновременного модифицирования файлов несколькими прикладными подсистемами.
1.5.1 Иерархические структуры в реляционных базах данных
Окружающий мир переполнен иерархическими данными. В это широкое понятие
входят компании, состоящие из дочерних компаний, филиалов, отделов и
рабочих групп; детали из которых собираются узлы, входящие затем в
механизмы; специальности, специализации и рабочие навыки; начальники и
подчинённые и т. д. Любая ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
Похожие работы
Дисциплины
- Информатика
- Банковское дело
- Оценка бизнеса
- Бухгалтерское дело
- Валеология
- География
- Геология, Геофизика, Геодезия
- Религия
- Общая история
- Журналистика
- Таможенное дело
- История Казахстана
- Финансы
- Законодательство и Право, Криминалистика
- Маркетинг
- Культурология
- Медицина
- Менеджмент
- Нефть, Газ
- Искуство, музыка
- Педагогика
- Психология
- Страхование
- Налоги
- Политология
- Сертификация, стандартизация
- Социология, Демография
- Статистика
- Туризм
- Физика
- Философия
- Химия
- Делопроизводсто
- Экология, Охрана природы, Природопользование
- Экономика
- Литература
- Биология
- Мясо, молочно, вино-водочные продукты
- Земельный кадастр, Недвижимость
- Математика, Геометрия
- Государственное управление
- Архивное дело
- Полиграфия
- Горное дело
- Языковедение, Филология
- Исторические личности
- Автоматизация, Техника
- Экономическая география
- Международные отношения
- ОБЖ (Основы безопасности жизнедеятельности), Защита труда
