Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Модели представления данных в СУБД - файл 1.doc


Модели представления данных в СУБД
скачать (630.5 kb.)

Доступные файлы (1):

1.doc631kb.13.12.2011 07:11скачать

содержание

1.doc

АННОТАЦИЯ
Формы

представления данных в СУБД

Реферат. – Челябинск,

2010, 37с., 5 источников.


В реферате осуществлено описание форм (моделей) представления данных в СУБД.

Освещены вопросы сущности системы управления базами данных.

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ…………………………………………………………………….…4

^ ГЛАВА 1. БАЗЫ ДАННЫХ

1.1. Понятие базы данных…………………………………………….…..5

1.2. Понятие системы управления базами данных……………………….7

1.3. Классификация баз данных…………....………………………….....10

^ ГЛАВА 2. ФОРМЫ ПРЕДСТАВЛЕНИЯ ДАННЫХ В СУБД

2.1. Файловая модель представления данных …….……………………12

2.2. Иерархическая и сетевая модели представления данных……..…..17

2.3. Реляционная модель данных………………………………….……..24

ЗАКЛЮЧЕНИЕ…………………………………………...……………………..35

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ………………………………...37
ВВЕДЕНИЕ
В соответствии с основными этапами проектирования базы данных после построения концептуальной модели выбирается система управления базой данных, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Вторая стадия проектирования базы данных состоит в представлении построенной на предыдущей стадии концептуальной модели средствами модели данных СУБД или в отображении концептуальной модели в модель данных СУБД. Именно это обуславливает актуальность исследования моделей представления данных.

Объектом исследования являются системы управления базами данных.

Цель реферата заключается в исследовании моделей представления данных.

Для достижения поставленной цели в работе решаются следующие задачи:

- дается общее представление о базах данных и системах управления базами данных, а также приводится классификация баз данных.

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

В курсовой работе были использованы труды авторов, таких как Малышенко Ю.В., Балдин К.В., Уткин В.Б. и др.
ГЛАВА 1.1 БАЗЫ ДАННЫХ
^

1.1 Понятие базы данных (БД)



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

База данных – средство организации хранения и управления большим количеством упорядоченной разнородной информации. Обычно её характеризует жёсткая внутренняя структура и взаимосвязь между отдельными элементами хранящихся данных. Работая с базой данных, пользователь абстрагируется от конкретного способа их физического хранения на компьютере.

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

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

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

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

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

1. Адекватность описываемому объекту/системе — на уровне концептуальной и логической модели.

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

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

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

1.2 Понятие системы управления базами данных (СУБД)
Базы данных используются под управлением систем управления базами данных (СУБД).

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

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

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

К числу функций СУБД принято относить следующие:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

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

3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД.

4. Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.

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

5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).

Обычно современная СУБД содержит следующие компоненты:

  • ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

  • процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода,

  • подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

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

  • поддержка широкого спектра типов представляемых данных и операций над ними (включая фактографические, документальные, картинно-графические данные);

  • естественные и эффективные представления в БД разнообразных отношений между объектами предметных областей (например, пространственно-временных с обеспечением визуализации данных);

  • поддержка непротиворечивости данных и реализация дедуктивных БД;
    обеспечение целостности БД в широком диапазоне разнообразных предметных областей и операционных обстановок;

  • управление распределенными БД, интеграция неоднородных баз данных;

  • существенное повышение надежности функционирования БД.


1.3 Классификация баз данных

Многообразие характеристик и видов баз данных порождает многообразие классификации. Рассмотрим основные виды классификации.

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

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

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

По способу доступа к данным базы данных подразделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

Файл – сервер. Согласно этой архитектуре в компьютерной сети выделяется машина – сервер для хранения файлов централизованной базы данных. Файлы базы данных могут быть переданы на рабочие станции для обработки: ввода, корректировки, поиска записей. При большой интенсивности доступа к одним и тем же файлам производительность системы падает. В этой системе сервер и рабочие станции должны быть реализованы на достаточно мощных компьютерах.

На данный момент файл – серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Borland Paradox.

Клиент – сервер – архитектура, используемая не только для хранения файлов централизованной базы данных на сервере, но и выполняющая на том же сервере основной объем работы по обработке данных. Таким образом, при необходимости поиска информации в базе данных рабочим станциям – клиентам передаются не файлы данных, а уже записи, отобранные в результате обработки файлов данных. Такая архитектура позволяет использовать маломощные компьютеры в качестве рабочих станций, но обязательно в качестве сервера используется очень мощный компьютер.

Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, MySQL,

PostgreSQL.

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

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

С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. Модели данных, которые поддерживают СУБД, а, следовательно, и сами СУБД делят на:

иерархические;

сетевые;

реляционные;

файловые.

^ ГЛАВА 2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ В СУБД
2.1 Файловая модель представления данных
Основные компоненты модели

Исторически первыми системами хранения и обработки данных на ЭВМ была файловая организация данных. При такой модели внутримашинная система размещения данных представляет собой совокупность не связанных между собой обычных компьютерных файлов из однотипных записей с линей­ной (одноуровневой) структурой.

Основные компоненты структуры данных файловой модели - поле, запись, файл (рис. 2.1).
ФАЙЛ



Поле Запись


Рис. 2.1 Логическая структура данных в файловых БД

Поле - элементарная единица логической организации данных, которая соответствует отдельной, неделимой единице информации - реквизиту.

Запись - совокупность полей, соответствующих логически связанным рек­визитам. Структура записи определяется составом и последовательностью вхо­дящих в нее полей, каждое из которых содержит элементарные данные.

Файл - множество одинаковых по структуре экземпляров записей.

Агрегат - несколько фун­кционально связанных нолей данных.

Так, поли со значениями года, месяца и дня можно рассматри­вать как некоторый агрегат.

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

Допустим, надо создать БД файлового типа, содержащую сведения о сотрудниках некоторой организации (табл. 2.1). Тогда в качестве отдельной записи будет рассматриваться информация каждой из строк табл. 2.1, в качестве k-го поля - данные k-го столбца в соответствующей строке (т.е. первое поле каждой записи будет содержать помер отдела, второе - фамилию, третье - год рождения и т.д.). Таким образом, БД будет содержать 7 записей одного типа, каждая из 6 полей.

Табл. 2.1


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

Ключи для выбора записей

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

В общем случае ключи записи бывают двух видов: первичный и вторичный.

Первичный ключ - это одно или несколько полей, однозначно идентифици­рующих запись.

Первичный ключ позволяет для его любого значения всегда находить в БД не более одной записи. Например, для данных, представленных в табл. 2.1, пер­вичным ключом будет поле <Паспорт>. Если задать любое допустимое значение этого поля, то всегда будет выбрана только одна запись. Так, при задании значе­ния <12 34 034 123> будет выбрана запись № 4.

Вторичный ключ - это одно или несколько полей, значение которых может повторяться в нескольких записях файла.

Такой ключ используется, когда указанному в запросе требованию в БД могут соответствовать несколько записей. Допустим, нам надо выбрать сотруд­ников, родившихся в некотором году. Для рассматриваемого выше примера поле <Год рождения> будет вторичным ключом, так как для значения ключа «1953» в БД будет найдено две записи: № 4 и № 7.

Заметим, что может быть несколько разных первичных и (или) вторичных ключей. Так, в табл. 2.1, кроме поля <Паспорт>, первичным ключом является и поле <Номер записи>.

Если ключ состоит из одного поля, то называется простым, если из несколь­ких полей - составным.

Организация поиска записей

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

Возможности БД файлового типа в значительной мере определяются воз­можностями файловой системы ЭВМ.

Первоначально, когда жесткие диски и оперативная память имели небольшую емкость, файлы БД располагались на магнитных лентах. Особенность работы с магнитными лентами состоит в том, что файлы располагаются на ленте после­довательно друг за другом и для доступа к нужной записи необходимо прокру­тить ленту до места ее расположения. Иными словами, в файловых системах ЭВМ первых поколений реализовывался последовательный метод доступа к данным, когда для извлечете нужной записи надо было прочитать все предыдущие. Поэтому первые файловые БД требовали длительного времени поиска данных.

В последующем ЭВМ стали использовать файловые системы с произволь­ным или индексно-последовательным доступом, а для хранения БД - жесткие диски и оперативную память. В них стало возможным реализовать способ пря­мого доступа к памяти и практически сразу находить нужный файл и запись. Именно тогда окончательно сформировалось понятие ключа, по значению кото­рого определяется запись, необходимая пользователю.

В базах данных, основанных на файловой модели, используются простей­шие по современным понятиям СУБД, в которых реализовывается простейший механизм поиска необходимых пользователю записей. Фактически в них для реализации запроса нового типа требуется писать дополнительный програм­мный модуль.

Заметим, что система хранения и поиска данных на жестком диске ПЭВМ и есть некоторый вариант БД файлового типа

Рассмотрим, например, как физически располагаются записи на жестком диске и организуется выборка нужной записи при использовании файловой сис­темы с индексно-последовательным доступом .

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

Записи при их большом числе требуют для размещения несколько сег­ментов, дорожек и (или) цилиндров; в одном сегменте может быть несколько (записей. Для простоты понимания предположим, что каждая запись на диске представлена одним сегментом, а дорожки в цилиндре пронумерованы чис­лами 1,2,....

Очевидно, что для поиска записи следует указать номера цилиндра и дорож­ки, а также сегмента. Для ускорения поиска создаются индексные таблицы цилиндров и дорожек (рис.2.2)



Рис. 2.2. Схема поиска записи при индексно-последовательном доступе

Допустим, что записи пронумерованы и значение номера сегмента есть первичный ключ для выборки нужной записи. При запросе «Выбрать запись со значением ключа 64» будут выполнены определенные действия. Сначала ЭВМ найдет на диске индексную таблицу (далее индекс) цилиндров.

В ней для каждого цилиндра указывается максимальный ключ - максималь­ный номер записи (сегмента) на данном цилиндре (рис. 2.2). Далее определя­ется, что нужная запись находится на втором цилиндре, производится обраще­ние к индексу дорожек цилиндра 2 и определяется, что запись 64 находится па дорожке 3. После этого производится чтение с дорожки 3 второго цилиндра сег­мента (записи) с нужным номером. Эта запись будет четвертой на дорожке 3 второго цилиндра.

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

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

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

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

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

Между записями в иерархии могут быть определены связи: один ко многим или один к одному, где запись, соответствующая элементу один, определяется как исходная, а соответствующая элементу иного — как порожденная. Для иерар­хической структуры характерно, что запись-потомок имеет только одного пред­ка, у которого может быть множество потомков. В общем случае данные в иерар­хической БД могут представляться несколькими деревьями.

В иерархических БД автоматически поддерживается целостность ссылок между предыдущим (родителями) и последующим (потомками). Основное пра­вило — последующее не может существовать без своего предыдущего. Анало­гичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается.

В различных СУБД описание объекта для БД иерархического типа может называться по-разному: тип записи, файл, сегмент (далее используем термин «запись»). В свою очередь, запись состоит из одного или нескольких элемен­тов данных (это аналог поля в файловой модели). Элементы упорядочиваются в некотором порядке.

Записи одной структуры образуют тип записи. Отдельные записи некоторого типа называют экземплярами записи. Модель данных может включать несколько типов записей. При этом запись конкретного типа называют объектом модели.

Между объектами модели данных устанавливаются связи. Они также харак­теризуются типом. Связи между разными объектами (между парой экземпляров записей разного типа) могут иметь разный тип.

В качестве пояснения ниже приводится концептуальная и логическая моде­ли иерархической БД для «Классификатора таможенных органов и их структур­ных подразделений». Этот классификатор применяется при подготовке и конт­роле таможенных документов.

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

Конкретная таможня подчиняется только одному РТУ, а ТП - только одной таможне, поэтому для каждого РТУ мож­но построить дерево подчиненности, в котором у каждого потомка будет толь­ко один предок, а корнем дерева будет объект типа РТУ. Следовательно, взаимо­связь данных в создаваемой БД описыва­ется иерархическим деревом, что является особенностью БД иерархического типа.

Поскольку в состав каждого РТУ входят несколько таможен, а в тамож­ню - несколько ТП, можно выделить два типа связей: первый - [РТУ-» Т] и второй - [Т -> ТП] . Поскольку в ФТС России семь РТУ, логи­ческая модель создаваемой БД будет иметь семь однотипных деревьев (рис. 2.3). Количество потомков записей РТУ или Т будет зависеть от структуры соответ­ствующих РТУ. Для описания элементов объектов в логической модели будет три типа записей по числу типов объектов: РТУ, Т и ТП.



Рис.2.3. Логическая модель БД классификатора

Например, запись типа РТУ, описывающая Центральное таможенное управ­ление (ЦТУ), будет иметь вид:

Имя

Код

ЦТУ

10100000

В Подольской таможне несколько ТП. Поэтому запись типа Т с именем - <Подольская> будет иметь соответствующее число потомков типа ТП.

Имя

Код

Подольская

10127070

Дальневосточное таможенное управление состоит из 18 таможен, соот­ветственно в дереве, описывающем это управление, у записи типа РТУ будет 18 записей-потомков. Конкретная таможня, например Владивостокская, будет представлена записью:

Имя

Код

ДВТУ

10702000

В СУБД на основе иерархической модели типичными являются операции типа:

- найти указанное дерево БД;

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

- просмотреть записи некоторого типа в заданном порядке;

- добавить запись в заданную позицию иерархии и др.

Для хранения в памяти ЭВМ иерархической структуры данных используется система указателей. Поэтому, например, при размещении в память ЭВМ записи типа РТУ после нее будет к ячеек-указате-лей с адресами расположения записей типа Т (к - число таможен, подчиненных определенному РТУ). В конце каждой записи типа Т будет столько указателей, сколько таможенных постов у соответствующей таможни.

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

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

В технической литературе в качестве примеров иерархических БД часто называют системы IMS (Information Management System), TDMS (Time-Shared Data Management System), Mark IV (Multi-Access Retrieval System), System-2000 и др.

Сетевая модель данных

Иерархическая модель является частным случаем сетевой. В строго иерархических моделях любой объект может подчиняться только одному объ­екту вышестоящего уровня. В иерархических моделях первоначальный доступ возможен по ключу, как правило, только к объекту самого высокого уровня (сопоставленного корню дерева), который не подчинен другим объектам. Доступ к другим объектам осуществляется по связям от корня дерева с использованием соответствующих дополнительных ключей.

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

На рис. 2.4. представлена концептуальная модель сетевой БД, содержащая информацию о предпринимателях, брокерах, офрмляющих грузовые таможенные декларации (с номерами 1,2….,5) на некоторые товары (сахар, окорочка, телевизоры).



Рис.2.4. Пример структуры данных сетевой БД

Достаточно очевидно, что в этой БД будет четыре типа записей: <Владелец товара>, <Брокер>, <Грузовая таможенная декларация><Вид товара>.

Логическую структуру сетевой БД можно представить в виде графа (рис. 2.5). Нетрудно заметить, что в нем несколько корневых вершин, причем некоторые из них имеют нескольких предков, что является характерным свойством сетевой модели.

В сетевых моделях доступ по ключу может обеспечиваться к любому экзем­пляру записи независимо от уровня, на котором она находится в модели. Возможен также доступ по нескольким путям.

Таким образом, при использовании сетевой модели пользователю доста­точно (в общем случае) задать один ключ, чтобы получить искомую запись. Например, декларацию 2 можно най­ти в БД через владельцев товара либо брокеров. При иерархической модели может потребоваться последователь­ное задание нескольких ключей, чтобы получить требуемую запись.



Рис. 2.5. Граф, соответствующий примеру на рис. 2.3.

Таким образом, при использовании сетевой модели пользователю проще получить искомую запись.

В принципе сетевую структуру (см. рис 2.3) можно представить в виде нескольких отдельных деревьев ( в виде иерархической модели), но тогда воз­никнет дублирование части информации, что приведет к росту объема БД.

В СУБД на основе сетевой модели типичными являются операции:

- поиск указанной записи;

- переход от предка к потомку;

- переход от потомка к предку;

- просмотр предков или потомков в заданном порядке;

- добавление записи в заданную позицию иерархии и др.

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

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

Внутримашинное представление данных в сетевой БД, как и в иерархичес­кой, предполагает снабжение записей указателями.

В технической литературе в качестве примеров сетевых БД часто называют системы IDS (Integrated Data Store), IDMS (Integrated Database Management System), db. VISTA и др.
2.3 Реляционная модель данных
Основные понятия

Длительное время до появления реляционных БД на практике пре­обладали иерархические и сетевые модели.

Считается, что впервые наиболее полное изложение реляционной модели сформулировал Е.Ф. Кодд в начале 70-х гг. К этому времени ста­ло ясно, что при сложных структурах данных реализация новых запросов или введение новых логических связей в сетевых или иерархических БД требует довольно существенных доработок программного обеспечения. Указанный недо­статок обусловлен тем, что в этих БД выбор необходимых записей производится е использованием указателей, через которые связаны записи. Предположим, что исходная иерархическая или сетевая БД содержит сведения о товарах, их ценах в разных поставках и информацию о производителях товаров, причем в графе исходной структуры данных нет пути между вершинами, сопоставленными про­изводителям и их ценам товаров. Тогда при необходимости выбора из БД сведе­ний о ценах товаров указанного производителя придется выполнить несколько запросов и провести специальную обработку выбранных данных (скорей всего для этого потребуется разработать дополнительный программный модуль). Если же было несколько производителей одного товара, то задача может оказаться невыполнимой.

Е.Ф. Кодд предложил представлять логическую модель данных в виде набора таблиц, которые получили название реляций, а сама модель - реляционной. При использовании этой модели по запросу пользователя из таблиц должна выбирать­ся одна или несколько строк (столбцов), удовлетворяющих заданным требовани­ям. Кроме того он предложил для обработки таблиц (в целях реализации запро­сов) применять механизм реляционной алгебры или реляционного исчисления.

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

Базы данных, объектами которых являются связанные определенным образом таблицы, называют реляционными (от relation - связь, отношение). В реляционной БД таблицы (реляции) должны удовлетворять определенным требованиям.

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

2. Столбцы должны размешаться в произвольном порядке, а данные каждого столбца должны быть однотипными.

3. Каждый столбец должен быть уникальным (недопустимо дублирование столбцов) и иметь уникальное наименование.

4. Строки размешаются в таблице в произвольном порядке.

Связанные отношениями таблицы взаимодействуют по принципу главная (master) - подчиненная (detail). Например, если имеются две таблицы, в одной из которых указаны наименования фирм таможенных брокеров и сведения об оформленных через них ГТД за некоторый период времени, а о другой - све­дения о каждом таможенном брокере (адрес, номер и дата выдачи лицензии), то первая будет главной, а вторая - подчиненной. Часто главную таблицу называ­ют родительской, а подчиненную – дочерней. Одна и та же таблица может быть главной по отношению к одной таблице БД и дочерней по отношению к другой.

В теории реляционных БД используется специфическая терминология.

В таблице 2.2 приведены основные термины, используемые при работе с реляционными БД.

Таблица 2.2

Элемент модели

Определение

Отношение или реляция

Таблица

Атрибут

Столбец таблицы

Имя атрибута

Заголовок столбца таблицы

Кортеж

Совокупность значений строки таблицы

Домен

Совокупность значений в столбце

Область атрибута

Множество, из которого берутся значения атрибута

Пусть таблица-отношение К (рис. 2.6) содержит столбцы (атрибуты) с име­нами А,, А2,..., Ап.



Рис. 2.6 Структура реляционной таблицы-отношения R


Множество значений атрибутов в j-м столбце образуют домен, а множество значений атрибутов в i-й строке образуют кортеж Кi.

Значение атрибута Aj в клетке на пересечении i-й строки и j-го столбца обозначим через аij. Тогда отношение R образуется множеством упорядоченных кор­тежей: R={Ki}, где Кi={аi1, аi2..., аmn}; i=1,..., m - номер кортежа; j =1,2,..., n - номер домена.

В таблице 2.3 приведен пример реляции (таблицы), названной «Таможен­ный брокер», которая включает три домена и четыре кортежа. Домен 1 содержит наименование организации, домен 2 - номер лицензии, домой 3 - регион деятельности таможенного брокера. Каждый домен имеет по 4 значения, а каждый кортеж состоит из трех элементов.

Таблица 2.3

Отношение «Таможенный брокер»

Атрибут «Номер лицензии»

Наименование организации

Номер лицензии

Регион деятельности

РОСТЭК-ДВ

10700/0009

Дальневосточное таможенное упр.

ГРОДЕКОВОВНЕШЬРАНС

107000/0020

Гродековская таможня

ВЛАДВНЕШТРАНС

197000/0003

Владивостокская таможня

ВЛАДВНЕШТРАНС

107000/0003

Гродековская таможня

Значение атрибута

Ключи

В реляционных БД. как и в других типах БД, для поиска нужных дан­ных используются ключи.

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

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

Если, например, отношение задано в виде табл. 2.1, то очевидно, что атри­бут «Паспорт» будет первичным ключом: если задать любое из возможных значений этого атрибута, в таблице найдется только одна строка с заданным значением.

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

Таблица 2.3 «Таможенный брокер» является примером отношения, для которого первичный ключ состоит из двух атрибутов, т.е. является составным. При этом возможны два варианта первичного ключа: атрибуты «Наименова­ние организации» и «Регион деятельности» либо «Номер лицензии» и «Реги­он деятельности». Если задать какой-нибудь из возможных номеров лицензии и название организации, то в таблице найдется не более одной строки с заданны­ми значениями.

Вторичный ключ - это такой ключ, значения которого могут повторяться в нескольких строках-кортежах.

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

Таким образом, ключ будет вторичным, если хотя бы одному из его значений соответствуют две или более строки. Заметим, что некоторым значениям вторичного ключа может соответствовать всего одна строка.

Так, для табл. 2.3 любой отдельный атрибут будет вторичным ключом. Напри­мер, если задать значение атрибута «Номер лицензии» равным 107000/0003, в таблице будут найдены две строки с этим значением.

Нормализация таблиц-отношений.

В реляционных БД существует также понятие внешнего ключа, с помощью которого устанавливаются связи между таблицами, т.е. такой ключ позволяет извлечь данные сразу из нескольких таблиц. Пусть имеется БД из трех таблиц, содержащая информацию о предприятиях-брокерах (на рис. 2.7 показаны только атрибуты этих таблиц). Составной ключ из атрибутов «Лицен­зия» и «ИНН» является внешним ключом для этой БД. Информация о пред­приятиях распределена по трем таблицам. Однако если задать значения лицен­зии и ИНН некоторого предприятия (т.е. задать значение внешнего ключа), то из других таблиц БД будет извлечена вся имеющаяся информация по соот­ветствующему предприятию.

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

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

Рис. 2.7 Применение внешних ключей для связи отношений



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

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

Выделяют следующие формы нормализованных таблиц:

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная форма (ЗНФ);

- усиленная третья нормальная форма или нормальная форма Бойса-Кодда (БКНФ);

- четвертая нормальная форма (4НФ);

- пятая нормальная форма (5НФ).

Обычно при создании реляционной БД ее таблицы достаточно привести к третьей нормальной форме (ЗНФ или БКНФ).

При первой нормальной форме все атрибуты отношения должны быть про­стыми» т.е. иметь единственное значение в каждой строке.

Так, например, если фирма продает ЭВМ в двух вариантах исполнения и в прайс-листе, представленном в виде таблицы, столбец в строке с информацией о ЭВМ содержит обозначения сразу обоих вариантов, то таблица является ненор­мализованной, поскольку приводит к неоднозначности выполнения запросов. Преобразование к первой нормальной форме обычно приводит к представлению такой строки в виде нескольких строк или даже требует введения дополнитель­ных таблиц. При нормализации стараются обеспечить неделимость значений атрибутов, которая означает, что содержащиеся в клетках таблицы значения не должны делиться на более мелкие. Например» если в строке некоторой таблицы атрибут содержит одновременно фамилию, имя и отчество сотрудника, следует разделить его на три атрибута - отдельно для фамилии, имени и отчества.

При второй нормальной форме все атрибуты отношения удовлетворяют требованиям 1НФ и каждый неключевой атрибут функционально полно зави­сит от ключа. Атрибут А функционально зависит от атрибута В, если каждому значению А соответствует только одно значение В, т.е. во всех кортежах с одним и тем же значением атрибута А атрибут В также имеет одно и то же значение (записывается: А - > В). Если атрибут находится в функциональной зависи­мости от части составного ключа, то такая зависимость называется частичной. Полная функциональная зависимость означает, что ключ однозначно опреде­ляет неключевой атрибут и одному значению ключа соответствует только одно значение неключевого атрибута. Если ключ составной, то подобная зависимость должна выполняться на уровне всего ключа, а не какой-либо его части.

При третьей нормальной форме выполняются требования 1НФ и 2НФ, а каждый неключевой атрибут нетранзитивно зависит от ключа. Атрибут С зависит от атрибута А транзитивно, если для атрибутов А, В и С выполняются условия:

А->В и В->С.

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

Типы полей

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

полем. От длины поля зависит, сколько данных (символов) или какой величины число в нем сможет разместиться. Обычно длина поля измеряется в байтах. Любое поле имеет имя, причем в одной таблице не может быть двух полей с одним и тем же именем. Кроме имени у поля есть еще свойство - подпись, которая представляет собой информацию, отображаемую в заголовке столбца. Ее нельзя путать с именем поля, хотя если подпись не задана, то в заголов­ке отображается имя поля. При этом разным полям можно задать одинаковые подписи.

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

1) числовое поле служит для ввода числовых данных. Его длина и способ (формат) представления зависят от типа числа: целое, с плавающей запятой и др.;

2) поле для ввода дат или времени;

3) логическое поле предназначено для ввода логических данных, имеющих только два значения («Да» или «Нет»; «0> или «1»и т.п.). Длина этого поля всег­да равна 1 байту, что достаточно для выражения логического значения;

4) поле для хранения значений денежных сумм (их можно хранить и в числовом поле, но в денежном формате работать удобнее). В этом случае ЭВМ при работке различает различную валюту (рубли и копейки, фунты и пенсы, доллары и центы);

5) поле объекта OLE (Object Linking and Embedding - связывание и внед­рение объектов) используется для хранения картинок, музыкальных клипов и видеоданных;

6) поле MEMO используется для хранения длинного текста (до нескольких тысяч символов). Особенность ноля MEMO состоит в том, что реально в поле хранятся не данные, а только указатель места, где расположен текст;

7) поле Счетчик - числовое поле, но имеющее свойство автоматического наращивания. Если в базе есть такое поле, то при вводе новой записи в него авто­матически записывается число, на единицу большее, чем значение того же поля в предыдущей записи. Это более удобно для нумерации записей.

Операции с данными реляционной модели

В своей теории построения реляционных БД В.Ф. Кодд ввел понятия реляционной алгебры и реляционного исчисления. Фактически это два языка формулирования и реализации запросов пользователя.

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

Реляционное исчисление - непроцедурный язык создания запросов. Описа­ние с помощью операторов реляционного исчисления содержит сам запрос и не определяет порядок действий при его реализации.

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

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


ЗАКЛЮЧЕНИЕ
Если можно говорить об основной идее СУБД, то она заключается в передаче управления данными из прикладной программы и/или от пользователя одной специальной системе, которая вне зависимости от того, какая программа или версия программы, или же какой пользователь работает с данными, единым во всех случаях образом отслеживает защиту данных от рассогласованности, оптимизирует выполнение операций над данными, обращения к ним и т.д.

Использование модели данных при работе с БД (в "компьютерном" смысле, в смысле хранения структур данных) неизбежно по нескольким причинам. Во-первых, модель дает общий язык пользователям, работающим с данными. Во-вторых, модель может обеспечить предсказуемость результатов работы с данными. Становится возможным объяснить пользователю, почему он получил конкретный результат при просмотре или изменении данных, и наоборот, работающий с базой может предвидеть, какого сорта он получит результат. За время существования разработок программных систем предложено много различных моделей разной степени распространенности.

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

В реляционной модели считается, что все данные ИС представлены в виде таблиц. Строки в каждой таблице - это кортеж неструктурированных единиц данных, "атрибутов". Набор кортежей, составляющий таблицу, образует математическое отношение; таким образом, модель данных представляется множеством таблиц-отношений (называемых также R-таблицами); отсюда название "реляционная", т.е. модель, представленная отношениями.

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

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

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

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


^ СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ


  1. Семенов Н.И. Автоматизированные информационные технологии. Учебник. – Москва.: «Инфра-М». 2237с. 2000г.

  2. Дрога А. А., Жукова П. Н., Копонев Д. Н., Лукьянов Д. Б., Прокопенко А. Н. Информатика и математика. – Белгород.: Белгородский юридический институт МВД РФ, 2008.

  3. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — 3-е изд. — М.: «Вильямс», 2003.

  4. Кузнецов С. Д. Основы баз данных. — 1-е изд. — М.: «Интернет-университет информационных технологий - ИНТУИТ.ру», 2005.

  5. Никитина Т.П., Рубцов С.А. Базы данных и знаний/Под ред. д-ра техн.наук, проф. Д.О.Бытева. Изд-во ЯГТУ.-108с., 2003.

  6. Малышенко Ю.В., Федоров В.В. Информационные таможенные технологии Том(часть) 2.: Учебник (ГРИФ) - М.: «Рио РТА», 2008

  7. Балдин К.В., Уткин В.Б. Информационные системы в экономике. 5-е изд. – М.: «Дашков и К», 2008. – 395 с.



Челябинск

2010



Скачать файл (630.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации