диплом Анализ архитектур сетевых баз данных (id=idd_1909_0000535)

Содержание

Введение…………………………………………………………………………….3
1 Основы архитектур баз данных……………………………….………………...7
1.1 Основные понятия архитектуры сетевой базы данных………..………….....7
1.2 Сетевые структуры………………………………………………..……………8
1.3 Реляционные структуры………………………………….…………….…….12
1.4 Объектно-ориентированные СУБД…………………………..……………...18
1.5 Типы сетевых баз данных………………………………………..………..….20
1.6 Выводы по первой главе……………………………..……………………….21
2 Представление и обработка знаний в сетевых архитектурах баз данных…..23
2.1 Представление знаний в сетевых архитектурах БД ……………..…………23
2.2 Обработка распределенных данных……………………………..…………..31
2.3 Средства защиты данных в БД……………………………..…. …………….42
2.4 Выводы по второй главе………………………………………..…………….47
3 Практическое применение……………………………..…………………….…49
3.1 Системы автоматизированного проектирования (САПР) и базы данных...49
3.2 Базы данных общего назначения……………………………..……..........….55
3.3 Выводы по третьей главе………………………………………..……………57
Заключение………………………………………………………………..….……59
Глоссарий………………………………………………………………………….64
Список использованных источников………………………….…………...……66
Список сокращений……………………………………………………………….69
Приложение А Элементы реляционной модели...............………………………71
Приложение Б Схема сетевой модели данных.................………………………72
Приложение В Характеристика видов связей таблиц ………………………….74
Приложение Г Объединение и разделение хранимых записей ……..…………75
Приложение Д Распределенная обработка данных ………….…………………76
Приложение Е Структура информационной базы САПР………………………77
Приложение Ж Фонды данных…………………………………………………..78
Введение

Базы данных (БД) составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности.
Для взаимодействия пользователя с БД используются системы управления базами данных (СУБД), которые обеспечивают:
– набор средств для поддержки таблиц и соотношений между ними;
– развитый пользовательский интерфейс, позволяющий вводить и модифицировать информацию, производить поиск и представлять результаты;
– средства программирования высокого уровня, позволяющие создавать собственные приложения.
Подход к построению СУБД видоизменялся. На смену вычислительного центра (ВЦ) предприятия и автоматизированным системам управления предприятия (АСУП) на их основе пришли персональные компьютеры и настольные (персональные) системы управления базами данных, затем с развитием коммуникаций появились распределенные системы и концепции управления крупными предприятиями – корпорациями на основе бизнес-процессов.
При этом в условиях динамичного изменения бизнес-процессов за последние годы сформулировался ряд определенных требований к функциональным возможностям тех СУБД, производители которых стремятся поддерживать свои продукты на высоком, конкурентоспособном уровне. Современные СУБД должны отвечать определенным требованиям:
1. Создаваемые средствами СУБД приложения должны обладать высокой степенью мобильности и легко переноситься на разные компьютерные и сетевые платформы.
2. Коммуникационный обмен данными становится асинхронным, а информационные процессы длительными, и поэтому возникает необходимость журнализации состояния баз данных и проведения возможного отката/восстановления для расширенных временных рамок (дни, недели).
3. Средства СУБД должны допускать возможность гибкого варьирования архитектуры различных ИС для соблюдения разумного компромисса при разделении функциональных возможностей системы между рабочими станциями клиентов и серверами.
4. Создание «менеджеров процессов» может быть эффективным только в таких условиях, когда средства программирования СУБД объектно-ориентированы и возможно создание стабильных приложений при динамичном изменении маршрутизации сквозь эти задачи.
5. Производителям СУБД следует обеспечить соответствие поставляемых ими продуктов открытым стандартам взаимодействия.
6. Расширение бизнес-процессов за пределы одной компании и необходимость создания глобальных информационных связей выдвигает серьезную задачу поддержки высокой степени готовности систем, работающих 24 часа в сутки все 365 дней в году.
Перечисленные требования к СУБД как к интегрирующим звеньям информационных систем новой архитектуры позволяют взглянуть на существующие ныне на рынке продукты разных производителей под соответствующим углом зрения. Соответствие современных СУБД новым требованиям определит преимущества создаваемых ИС, их гибкость, мобильность, возможность легкой перестройки и, в конечном счете, способность к выживанию.
Тема выпускной квалификационной работы актуальна, т.к. БД является важнейшей составной частью информационных систем, которые предназначены для хранения и обработки информации. Изначально такие системы существовали в письменном виде. Для этого использовались различные картотеки, папки, журналы, библиотечные каталоги. Развитие средств вычислительной техники обеспечило возможность для создания и широкого использования автоматизированных информационных систем. Разрабатываются информационные системы для обслуживания различных систем деятельности, системы управления хозяйственными и техническими объектами, модельные комплексы для научных исследований, системы автоматизации проектирования и производства, всевозможные тренажеры и обучающие системы. Современные информационные системы основаны на концепции интеграции данных, характеризующих большими объектами хранимых данных, сложной организацией, необходимостью удовлетворять разнообразные требования многочисленных пользователей. Для управления этими данными и обеспечения эффективности доступа к ним были созданы системы управления данными. Итак, БД облегчает работу с огромной информацией, помогает справиться с тем огромным потоком информации, с которым раньше приходилось справляться вручную. Причем этот поток информации постоянно обновляется.
Действительно, процессы обработки информации имеют общую природу и опираются на описание фрагментов реальности, выраженное в виде совокупности взаимосвязанных данных. БД являются эффективным средством представления структур данных и манипулирования ими. Концепция БД предполагает использование интегрированных средств хранения информации, позволяющих обеспечить централизованное управление данными и обслуживание ими многих пользователей. При этом БД должна поддерживаться в среде ЭВМ единым программным обеспечением – СУБД. СУБД вместе с прикладными программами называют банком данных.
Одно из основных назначений СУБД – поддержка программными средствами представления, соответствующего реальности.
Предметной областью называется фрагмент реальности, который описывается или моделируется с помощью БД и ее приложений. В предметной области выделяются информационные объекты – идентифицируемые объекты реального мира, процессы, системы, понятия и т.д., сведения о которых хранятся в БД.
Цель данной работы – анализ архитектур сетевых БД. Для этого были поставлены и решены следующие задачи:
1. Рассмотреть представление знаний в сетевых архитектурах БД.
2. Сформулировать основные понятия архитектуры сетевой базы данных.
3. Дать понятие сетевых, реляционных, объектно – ориентированных СУБД.
4. Выявить области применения СУБД.
Работа выполнена и оформлена в соответствии с требованиями, предъявляемыми к выполнению выпускных квалификационных работ в Современной Гуманитарной Академии.
1 Основы архитектур баз данных

1.1 Основные понятия архитектуры сетевой базы данных

Хранимые в базе данные имеют определенную логическую структуру – иными словами, описываются некоторой моделью представления данных (моделью данных), поддерживаемой СУБД. К числу классических относятся следующие модели данных:
– иерархическая;
– сетевая;
– реляционная.
Разрабатываются также всевозможные системы, основанные на других моделях данных, расширяющих известные модели. В их числе можно назвать объектно-реляционные, дедуктивно – объектно – ориентированные, семантические, концептуальные и ориентированные модели. Некоторые из этих моделей служат для интеграции баз данных, баз знаний и языков программирования.
В некоторых СУБД поддерживается одновременно несколько моделей данных. Например, в системе ИНТЕРБАЗА для приложений применяется сетевой язык манипулирования данными, а в пользовательском интерфейсе реализованы языки SQL и QBE.
В сетевой модели данные представлены в виде коллекций записей, а связи – в виде наборов. В отличие от реляционной модели, связи здесь явным образом моделируются наборами, которые реализуются с помощью указателей. Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в виде его ребер.
К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь. Узел – это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. В сетевой структуре каждый элемент может быть связан с любым другим элементом.
Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию. Несмотря на то, что эта модель решает некоторые проблемы, связанные с иерархической моделью, выполнение простых запросов остается достаточно сложным процессом. Поскольку логика процедуры выборки данных зависит от физической организации этих данных, то эта модель не является полностью независимой от приложения. Другими словами, если необходимо изменить структуру данных, то нужно изменить и приложение.
Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. и изначально ориентированная на использования на мейнфреймах компании IBM. Архитектура системы основана на предложениях Data Base Task Group (DBTG) организации CODASYL (COnference on DAta SYstems Languages), которая отвечала за определение языка программирования COBOL. Отчет DBTG был опубликован в 1971 г., и вскоре после этого появилось несколько систем, поддерживающих архитектуру CODASYL, среди которых присутствовала и СУБД IDMS. В настоящее время IDMS принадлежит компании Computer Associates.

1.2 Сетевые структуры

Сетевой подход к организации данных является расширением иерархического подхода. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных у потомка может иметься любое число предков. Элементы реляционной модели (РМД) и формы их представления приведены в таблице 1 в приложении А. Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:
– каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;
– каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:
– тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии);
– данный тип записи P может быть типом записи предка в любом числе типов связи;
– данный тип записи P может быть типом записи потомка в любом числе типов связи;
– может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 – два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться;
– типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком – в другой;
– предок и потомок могут быть одного типа записи.
На рисунке 1 показан простой пример схемы сетевой БД. На этом рисунке показаны три типа записи: Отдел, Служащие и Руководитель и три типа связи: Состоит из служащих, Имеет руководителя и Является служащим. В типе связи Состоит из служащих типом записи-предком является Отдел, а типом записи-потомком – Служащие (экземпляр этого типа связи связывает экземпляр типа записи Отдел со многими экземплярами типа записи Служащие, соответствующими всем служащим данного отдела). В типе связи Имеет руководителя типом записи-предком является Отдел, а типом записи-потомком – Руководитель (экземпляр этого типа связи связывает экземпляр типа записи Отдел с одним экземпляром типа записи Руководитель, соответствующим руководителю данного отдела). Наконец, в типе связи Является служащим типом записи-предком является Руководитель, а типом записи-потомком – Служащие (экземпляр этого типа связи связывает экземпляр типа записи Руководитель с одним экземпляром типа записи Служащие, соответствующим тому служащему, которым является данный руководитель).

Состоит из служащих Является служащим




Имеет руководителя

Рис. 1. Пример схемы сетевой базы данных
Рассмотрим манипулирование данными. Вот примерный набор операций манипулирования данными:
– найти конкретную запись в наборе однотипных записей (например, служащего с именем Иванов);
– перейти от предка к первому потомку по некоторой связи (например, к первому служащему отдела 625);
– перейти к следующему потомку в некоторой связи (например, от Иванова к Сидорову);
– перейти от потомка к предку по некоторой связи (например, найти отдел, в котором работает Сидоров);
– создать новую запись;
– уничтожить запись;
– модифицировать запись;
– включить в связь;
– исключить из связи;
– переставить в другую связь и т.д.
Имеется возможность потребовать для конкретного типа связи отсутствие потомков, не участвующих ни в одном экземпляре этого типа связи (как в иерархической модели).
В целом ранние системы можно охарактеризовать следующим образом:
Эти системы активно использовались в течение многих лет, задолго до появления работоспособных реляционных СУБД. На самом деле некоторые из ранних систем используются даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем информационных систем является использование этих систем совместно с современными.
Все ранние системы не основывались на каких-либо абстрактных моделях. Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
Можно считать, что уровень средств ранних СУБД соотносится с уровнем файловых систем примерно так же, как уровень языка Cobol соотносится с уровнем языков ассемблера. Заметим, что при таком взгляде уровень реляционных систем соответствует уровню языков Ада или APL.
Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователей самих производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
Заметим, что перечисляемые выше характеристики в полной мере относятся и к другим не реляционным подходам к организации баз данных, которые возникли до появления реляционного подхода или почти одновременно с ним. В частности, подобными свойствами обладают системы, основанные на подходах MUMPS (наиболее известной в России является реализация этого подхода в СУБД Cache компании Intersystems) и Pick (этот подход реализован во многих СУБД, в частности, в СУБД UniVerse и UniData семейства U2 компании IBM).

1.3 Реляционные структуры

Основой современной технологии БД, без сомнения является реляционная модель данных. Для реляционной модели характерны три основных момента:
данные воспринимаются пользователем как таблицы и никак иначе. Таблицы в реляционной системе являются логическими, а не физическими структурами (внешний и концептуальный уровень представления данных);
в распоряжении пользователя имеются операторы, которые генерируют новые таблицы из старых и среди которых есть по крайней мере такие операторы как: выборка строк, столбцов и объединение;
все информационное содержимое БД представлено одним и только одним способом, а именно: явным заданием значений данных. В частности, нет никаких указателей, связывающих одну таблицу с другой.
Если реляционная БД – это БД, в которой данные представлены в виде таблиц, то почему не «табличная» база данных? Потому что термин relation (отношение) – это математическое название определенного вида таблицы. Принципы реляционной модели были изначально заложены в 1969 –70-х годах доктором Эдгаром Фрэнком Коддом, в то время работавшим в корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые осознал, что математику можно использовать для внесения в область управления базами данных строгих принципов и точности, то есть формализовать этот процесс. Трудность заключалась в том, что многие распространенные термины были очень нечеткими. Пример – понятие «запись». Это и экземпляр записи, и тип переменных, физические записи, логические записи и возможно что-то еще. Поэтому в формальной реляционной модели не используется термин «запись», вместо него используется термин «кортеж».
В реляционной модели рассматриваются три аспекта данных:
структура данных;
целостность данных;
и обработка данных.
Структурный аспект описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения. Целостный аспект описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Манипуляционный аспект описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.
В данной главе рассматривается структурная часть реляционной модели.
Поскольку реляционная модель является теорией, а большинство теорий сопровождается специальной терминологией, то мы будет использовать ту терминологию, которая поначалу может показаться неудобной, но к этому необходимо привыкнуть. В каждом из перечисленных аспектов есть своя терминология.
Для начала, дадим неформальное определение основным терминам, используя, для примера, рисунок 2.
Атрибуты


S#
SNAME
STATUS
CITY




























Рис. 2. Схема отношения в БД.
Схема отношения базы данных – это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или «арность» схемы отношения – мощность этого множества.
Отношение – это множество кортежей данной базы данных, соответствующих одной схеме отношения.
В реляционной модели данных отношение это подмножество декартова произведения доменов.
Домен – некоторое множество элементов (например, множество целых чисел или множество допустимых значений, которые может принимать объект по некоторому свойству и т.п.). Каждому атрибуту в реляционной модели ставится в соответствие множество его значений – домен атрибута. Т.е. можно сказать, что отношение это структура данных, построенная на доменах атрибутов. Над отношениями выполняются реляционные операции. Отношение состоит из заголовка и тела. Заголовок включает фиксированное множество атрибутов. Тело отношения состоит из конечного множества кортежей – множества пар вида (атрибут-значение атрибута). Число кортежей в отношении и их содержимое может меняться.
Степенью отношения называется число атрибутов в отношении. Мощностью отношения называется количество кортежей в отношении. Для отношения определяется первичный (и, если есть, возможный) ключ отношения.
Кортеж, соответствующий данной схеме отношения в базе данных, – это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или «арность» кортежа, т.е. число элементов в нем, совпадает с «арностью» соответствующей схемы отношения. Попросту говоря, кортеж – это набор именованных значений заданного типа..
Атрибут – соответствует имени столбца таблицы.
Кардинальное число – определяется количеством кортежей в таблице. Кардинальное число (от лат. cardinalis – главный), иначе количественное число, или мощность
Первичный ключ – это набор атрибутов, однозначно определяющих каждую строку реляционной таблицы. Ключ состоящий более чем из одного атрибута называется составным ключем. Первичный ключ должен удовлетворять требованиям уникальности и минимальности. Уникальность – для любой пары кортежей рассматриваемого отношения найдется хотя бы один атрибут, значение которого в этой паре кортежей различны. Минимальность – ни один из атрибутов не может быть удален из ключа без нарушения требования уникальности. В реляционной таблице может оказаться более одного набора атрибутов, который можно выбрать в качестве первичного ключа. Такой набор называется потенциальным или возможным ключом. Один из возможных ключей объявляется первичным, остальные альтернативными. Первичный ключ это потенциальный ключ, выбранный для преимущественного использования в целях однозначного определения строк таблицы. Внешний ключ это набор атрибутов одной таблицы, являющийся первичным ключом другой таблицы. Внешний ключ используется для организации логических связей между таблицами. Они используются для того, чтобы связать данные одной таблицы с данными в другой таблице. В некоторых СУБД допускается, что атрибуты внешнего ключа не обязательно должны иметь те же имена, что атрибуты первичного ключа, которым они соответствуют, но они должны базироваться на одних и тех же доменах.
В области связанной с обеспечением целостности данных несколько раз менялись некоторые основные определения. Поэтому остановимся на самых важных правилах, относящихся к любой базе данных.
Хотя основная идея потенциальных и внешних ключей довольно проста, имеется, к сожалению, один осложняющий дело фактор это null-значения (неопределенные значения). Возможность того, что внешний ключ может допускать null – значения портит всю картину. Поэтому, прежде чем переходить к определению потенциальных и внешних ключей, поговорим о null-значениях.
Основное назначение баз данных состоит в том, чтобы хранить и предоставлять информацию о реальном мире. Для представления этой информации в базе данных используются привычные для программистов типы данных – строковые, численные, логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы вводить пустую строку, то, что вводить вместо неизве

Заказать эту работу прямо сейчас

Посмотреть другие готовые работы по предмету ИНФОРМАТИКА

© 2002-2024 Москва 'Мастерская дипломов'. Все права защищены.