В иерархической модели связи между данными можно описать с помощью упорядоченного графа (или дерева). Упрощенно представление связей между данными в иерархической модели показано на рис.1

Для описания структуры (схемы) иерархической БД на некотором языке программирования используется тип данных «дерево».Тип «дерево» схож с тинами данных «структура» языков программирования IIЛ/1 и С и «запись» языка Паскаль. В них допускается вложенность типов, каждый из которых находится на некотором уровне. Тип «дерево» является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каж-дый из типов «дерево» состоит из одного «корневого» типа и упорядоченного набора (возможно, пустого) подчиненных типов. Каждый из элементарных типов, включенных в тип «дерево», является простым или составным типом«запись». Простая «запись» состоит из одного типа, например числового, а составная «запись» объединяет некоторую совокупность типов, например, целое, строку символов и указатель (ссылку). Корневым называется тип, который имеет подчиненные типы и сам не является подтипом. Подчиненный тип (подтип) является потомком по отношению к типу, который выступает для него в роли предка (родителя). Потомки одного и того же типа являются близнецами по отношению друг к другу. В целом тип «дерево» представляет собой иерархически организованный набор типов «запись».

Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи)Кузин А. В. Базы данных: учеб, пособие для студ. высш. учеб, заведений /А.В.Кузин, С.В.Левонисова. -- 2-е изд., стер. -- М. : Изда-тельский центр «Академия», 2008 . Часто отношения родства между типами переносят на отношения между самими записями. Поля записей хранят собственно числовые или символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо. В иерархических СУБД может использоваться терминология, отличающаяся от приведенной. Так, в системе 1М8 понятию «запись» соответствует термин «сегмент», а под «записью БД» понимается вся совокупность записей, относящаяся к одному экземпляру типа «дерево». Для организации физического размещения иерархических данных в памяти ЭВМ могут использоваться следующие группы методов:

* представление линейным списком с последовательным распределением памяти (адресная арифметика, левосписковые структуры);

* представление связными линейными списками (методы, использующие указатели и справочники).

К основным операциям манипулирования иерархически организованными данными относятся следующие: поиск указанного экземпляра БД :

* переход от одного дерева к другому;

* переход от одной записи к другой внутри дерева

* вставка новой записи в указанную позицию;

* удаление текущей записи и т. д.

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

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

Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понимания для обычного пользователя. На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IМS, РС/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС.

1.2 Сетевая модель

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

Рис.2

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

* поиск записи в БД;

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

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

* создание новой записи;

* удаление текущей записи;

* обновление текущей записи;

* включение записи в связь;

* исключение записи из связи;

* изменение связей и т. д.

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

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

1.3 Реляционная модель

Реляционная модель основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов Райордан Р. Основы реляционных баз данных/Пер, с англ. -- М.: Издательско-торговый дом «Русская Редакция», 2001. Реляционная модель определяет способ представления данных (структуру данных),методы зашиты данных (целостность данных), а также операции, выполняемые с данными (манипулирование данными). Реляционная модель не единственный метод хранения и манипулирования данными. Существуют альтернативные варианты: иерархическая, сетевая, а также звездообразная модели данных. У каждой из них свои преимущества при решении задач определенного типа. Например, применение реляционной модели в обработке данных с иерархической организацией недостаточно хорошо изучено, для решения подобных задач используют специально созданную звездообразную модель данных. Однако гибкость и эффективность реляционной модели делают ее наиболее популярным инструментом для разработки баз данных. В этой книге мы будем рассматривать только реляционную модель, на которой основаны механизмы СУБД Microsoft , Jet и Microsoft SQL Server.

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

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

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

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

Если у вас имеется опыт работы с базами данных Microsoft Access, вы, конечно, догадались, что в данном случае представляет собой отношение -- это набор записей или, в терминах SQL Server, набор результатов. Формулируя принципы реляционной модели, доктор Код выбрал термин «отношение» (relation), потому что он однозначен (в то время как, например, термин «таблица» имеет множество дополнительных значений). Весьма распространено следующее заблуждение: реляционная модель названа так потому, что она определяет отношения между таблицами. На самом деле название этой модели происходит от отношений, лежащих в ее основе. В рамках реляционной модели данные представлены в виде отношения на концептуальном уровне; однако при этом совсем не дается никаких указаний, каким образом данные будут реализованы на физическом уровне. Разделение концептуального и логического уровней давно стало привычным для нас; но всего лишь 30 лет назад этот метод произвел настоящий переворот в области программирования баз данных. Ранее программирование баз данных сводилось в основном к написанию программного кода для физического управления устройствами, предназначенными для хранения данных. В действительности отношения не нуждаются в физическом представлении. Некий набор записей может соответствовать некоей физической таблице, размещенной на диске, а может быть и сформирован из столбцов нескольких десятков таблиц с вычисляемыми полями, значения которых вообще нигде не хранятся. Такой набор записей является отношением, поскольку организован в виде строк и столбцов, и его значения -- скаляры. Его существование абсолютно никак не зависит от физической реализации. Принцип замыкания заключается в том, что и базовые таблицы, и результаты операций над ними на концептуальном уровне представляются как отношения. Он позволяет непосредственно использовать результаты одной операции в качестве исходных данных для выполнения другой. Таким образом, и Microsoft Jet, и SQL Server дают возможность использовать результаты одного запроса для составления нового. Этот принцип реализует в области разработки баз данных функциональность, аналогичную подпрограммам в процедурном программировании -- возможность инкапсуляции сложных или часто повторяющихся операций для повторного использования. Предположим, вы составили запрос с именем FullNameQuery, выполняющий операцию конкатенации над данными и помещающий имя и фамилию физического лица в вычисляемое поле FullName. Вы можете составить следующий запрос, в котором FullNameQuery будет выступать в качестве источника. Вычисляемое поле FullName используется в этом случае точно так же, как любое другое поле базовой таблицы. Заново выполнять вычисления, в результате которых будет получено имя физического лица, не нужно. Требование, чтобы все значения в отношении являлись скалярами, может иногда создавать дополнительные трудности и соблюдается не абсолютно строго. Принцип существования одного и только одного значения для любой строки и любого столбца субъективен и зависит от семантики модели данных. Например, имя и фамилия физического лица в одной модели могут быть представлены как одно значение, а в других моделях -- разбиты на несколько отдельных значений (например, имя и фамилию или обращение, имя, отчество и фамилию). С точки зрения абстрактной теории ни один из этих вариантов не является более правильным, чем остальные; представление данных зависит от выбранного варианта реализации системы. Примерами зарубежных реляционных СУБД для ПЭВМ являются следу- ющие: (dBaseIII Plus и dBase IY ,DB2, Fox Pro более поздних версий, FoxBASE, Paradox и Acess, Clarion, Ingres(ASKComputer Systems) иОгас1е (Огас1е). К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech(МИФИ). Заметим, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектно-реляционными. Примером такой системы можно считать продукты Огас1е 8.x. Системы предыдущих версий вплоть до Огас1е 7.x считаются «чисто» реляционными.

Основы реляционных баз

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

Каждая строка, содержащая данные, является кортежем. Строго говоря, каждая строка является w-кортежем, однако «п-», как правило, опускается. Число кортежей в отношении определяет мощность отношения- В приведенном примере мощность отношения равна П. Каждый столбец отношения называется атрибутом. Число атрибутов в отношении определяет размерность этого отношения, для проиллюстрированного примера она равняется трем. Каждое отношение можно разделить на две части -- заголовок и тело. Тело отношения состоит из кортежей, в то время как заголовок не имеет более мелких компонентов структуры. Обратите внимание --название каждого из атрибутов состоит из двух терминов, разделенных двоеточием (например, UnitPrice:Currency). Первая часть названия -- непосредственно имя атрибута, вторая -- имя домена. Домен атрибута -- это «вид» данных, которые представляет данный атрибут (в приведенном примере -- валюта). Понятие «домен» не эквивалентно понятию «тип данных». Различие между этими двумя понятиями будет подробно обсуждаться далее в этой главе. На практике домен в заголовках часто не указывается. Тело отношения состоит из неупорядоченного набора кортежей (число кортежей может быть любым, от 0 и более). Остановимся на некоторых важных моментах. Во-первых, отношение не упорядочено. Понятие «номер строки» не применимо к отношению. Для отношений не существует никакого внутреннего порядка. Во-вторых, отношение может иметь нулевое число кортежей (это так называемое пустое отношение, которое, тем не менее, является отношением). В третьих, отношение представляет собой набор. Элементы в этом наборе по определению уникально идентифицируемые. Поэтому чтобы таблица являлась отношением, каждая ее строка должна быть уникально идентифицируемой, записи в ней не должны повторяться. Знакомых с документацией к Access или SQL Server, возможно, удивит, что они не встречали там терминов, используемых в этой книге. Однако следует заметить, что здесь я использую терминологию, общепринятую в технической литературе; терминология, используемая Microsoft, несколько отличается от нее. Ни в коем случае не следует забывать, что отношения определяются исключительно на концептуальном уровне. Как только речь заходит о конкретных примерах из области баз данных, отношения становятся наборами записей (для Microsoft Jet) или наборами результатов (для SQL Server). И для Microsoft Jet, и для SQL Server атрибут «превращается» в поле, а кортеж, соответственно -- в запись. Эти соотношения практически взаимно однозначны; однако нужно помнить, что отношения существуют на концептуальном уровне, в то время как наборы записей и наборы результатов -- на физическом. Элементами описания модели данных являются сущности, атрибуты, домены и отношения, Рассмотрим подробно каждый из них.

Рис.3

Элементы реляционной базы данных

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные. Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении. Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы. На рис/ приведен пример представления отношения СОТРУДНИК. В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в' реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода.

Рис.4

Формально, если переставить атрибуты в отношении, то получается новое отношение. Однако в реляционных БД перестановка атрибутов не приводит к образованию нового отношения. Домен представляет собой множество всех возможных значений определенного атрибута отношения. Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 -- номера всех отделов фирмы, домен 3 -- названия всех должностей, домен 4 -- даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, например, числовые или символьные. Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4 элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы. Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК(ФИО, Отдел, Должность, Д Рождения). Множество собственно кортежей отношения часто называют содержимым (телом) отношения. Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК(ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут «ФИО». Ключ может быть составным (сложным), то есть состоять из нескольких атрибутов. Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется тем, что отношение это множество, которое не содержит одинаковых элементов -- кортежей. То есть в отношении нет повторяющихся кортежей, а это значит, что по крайней мере вся совокупность атрибутов обладает свойством однозначно идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи. Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный. Если выбранный первичный ключ состоит из минимально необходимого набора атрибутов, говорят, что он является не избыточным. Ключи обычно используют для достижения следующих целей:

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

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

3) ускорения работы к кортежами отношения

4) организации связывания таблиц

Пусть в отношении К1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения К.2. Тогда говорят, что атрибут А отношения К1 есть внешний ключ. С помощью внешних ключей устанавливаются связи между отношениями. Например, имеются два отношения СТУДЕНТ (ФИО. Группа, Специальность) и 11РЕЛМЕТ(Назв.Пр. Часы), которые связаны отношением СТУ-ЛЕНТ_ПРЕЛМЁТ(ФИО. Назв.Пр. Оценка) (рис.Приложение Б). В связующем отношении атрибуты ФИО и Назв. Пр образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений. Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях. Поскольку не всякой таблице можно поставить в соответствие отношение, приведем условия, выполнение которых позволяет таблицу считать отношением.

1. Все строки таблицы должны быть уникальны, то есть не может быть строк с одинаковыми первичными ключами.

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

3. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.

4. Порядок размещения строк в таблице может быть произвольным. Наиболее часто таблица с отношением размещается в отдельном файле.

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

Индексирование

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

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

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

* вида содержимого в поле ключа записей индексного файла;

* типа используемых ссылок (указателей) на запись основной таблицы;

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

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

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

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

Связывание таблиц.

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

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

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

* один -- один (1:1);

* один -- много (1:М);

* много -- один (М:1);

* много -- много (М:М или М:М).

Теоретические языки запросов

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

* реляционная алгебра;

* реляционное исчисление.

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

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

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

Рис.2

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

* поиск записи в БД;

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

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

* создание новой записи;

* удаление текущей записи;

* обновление текущей записи;

* включение записи в связь;

* исключение записи из связи;

* изменение связей и т. д.

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

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

2 Преимущества и недостатки реляционной Б.Д

СМД - сетевая модель данных.

СУБД - система управления базами данных

БД - база данных.

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

Размещено на Allbest.ru