Проектная академия «KAZGOR»

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

 

2.1 Модели данных

 

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

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

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

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

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

 

2.2 Иерархическая модель данных

 

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

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

 

Рис 1. Иерархическая база данных, содержащая информацию о составных частях

 

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

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

• найти конкретную деталь (правую дверь) по её номеру;
• перейти "вниз" к первому потомку (ручка двери);
• перейти "вверх" к предку (корпус);
• перейти "в сторону" к другому потомку (правая дверь).

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены преимущества IMS и реализованной в ней иерархической модели.

• Простота модели. Принцип построения IMS был легок для понимания. Иерархия базы данных напоминала структуру компании или генеалогическое дерево.
• Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".
• Быстродействие. В СУБД IMS отношения предок/потомок были реализованы в виде физических указателей из одной записи на другую, вследствие чего перемещение по базе данных происходило быстро. Поскольку структура данных в этой СУБД отличалась простотой, IMS могла размещать записи предков и потомков на диске рядом друг с другом, что позволяло свести к минимуму количество операций записи-чтения.

СУБД IMS все ещё является одной из наиболее распространённых СУБД для больших ЭВМ компании IBM. Доля мэйнфреймов этой компании, на которых используется данная СУБД, превышает 25%.

 

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

 

   Понятие реляционный (англ. relation — отношение) связано с разработками известного американского специалиста в области систем баз данных, сотрудника фирмы IBM доктора Е. Коддом, которым впервые был применен термин "реляционная модель данных".

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

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

   Реляционная модель ориентирована  на организацию данных в виде  двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

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

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

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

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

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

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

 

Рис.2. Некоторые операции реляционной алгебры

 

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

   Проектирование  баз данных традиционно считалось  очень трудной задачей. Реляционная  технология значительно упрощает эту задачу.

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

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

   Данная модель позволяет определять:

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

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

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

   Основным преимуществом  реляционных СУБД является возможность связывания на основе определенных соотношений файлов БД.

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

   СУБД считается реляционной при выполнении следующих двух условий, предложенных еще Э. Коддом:

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

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

   Суть реляционной СУБД можно пояснить на следующем простом примере.

                                        

Таблица 1

 

Файл авторов публикаций БД
№ п/п	Автор	Адрес	Телефон	Число публ.
	…	…	…	…
6	Купцов	Москва	635-6078	140
7	Бухтяк	Томск	637-2050	140
8	Терпугов	Томск	538-584	250

 

Таблица 2

 

Файл публикаций РБД
№ п/п	Назв. Публикации	Тип публ.	Дата	Объём в п. л.
6	Основы …	Статья	2.95	2.5
7	Проблема …	Книга	3.97	35
8	Теория …	Статья	6.96	3.8
	…	…	…	…

 

  В некоторой реляционной  БД (РБД) имеются два файла авторов и публикаций, каждый из которых содержит определенное число записей, состоящих из фиксированного числа полей (соответственно 4 и 5), представляющих данные по соответствующим элементам предметной области. Можно сказать, что определены два отношения (фaйла), имеющие общий элемент — значения поля № п/п. Операции реляцианной алгебры могут объединять два типа записей по этому общему элементу. Например, в результате соединения запись Бухтяк может представится в следующем виде:

Бухтяк<Томск><637-2050><40><Основы...><статья><2.95><2.5>....

т.е. к сведениям  об авторе добавляются сведения обо  всех его публикациях, имеющихся в РБД.

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