Базы данных

• иерархические;
• сетевые;
• реляционные;
• файловые.

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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