ОСНОВНЫЕ ПОНЯТИЯ

Что такое базы данных?

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

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

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

• реляционная модель данных

Таблицы 

Первичные ключи   

Отношения предок/потомок

Внешние ключи

Спецпроцессор (Сервер) Базы Данных

• Требования, выдвигаемые спецпроцессором

• Основные функции спецпроцессора

• Атомарные транзакции

• Достоинства спецпроцессоров

• Недостатки спецпроцессоров

• Разделение функций

 

Двенадцать правил Кодда

 

Что такое базы данных?

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

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

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

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

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

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

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

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

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

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

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

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

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

 Такие структуры данных не соответствовали строгой иерархии IMS. В связи с этим для таких приложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархическоймоделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок, как показано на рис. 1.4

В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

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

• Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.
• Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.
• Быстродействие. Вопреки своей большой сложности, сетевые базы данных достигали быстродействия, сравнимого с быстродействием иерархических баз данных. Множества были представлены указателями на физические записи данных, и в некоторых системах администратор мог задать кластеризацию данных на основе множества отношений.

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее часто заказывает компания Acme Manufacturing?", программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

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

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

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

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

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

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

Таблицы

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

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

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALES содержатся объёмы продаж, обеспечиваемые офисами.

На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей нью-йоркский офис, в столбце CITY содержится значение "New York". В столбце SALES той же строки содержится значение $692.000.000, которое является объёмом продаж нью-йоркского офиса с начала года.

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце CITY содержатся только слова, в столбце SALES содержатся денежные суммы, а в столбце MGR содержатся целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца. Доменом столбца CITY является множество названий городов. Доменом столбца SALES является любая денежная сумма. Домен столбца REGION состоит всего из двух значений, "Eastern" и "Western", поскольку у компании всего два торговых региона.

У каждого столбца в таблице есть своё имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. На практике такие имена столбцов, как NAME, ADDRESS, QTY, PRICE и SALES, часто встречаются в различных таблицах одной базы данных.

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

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

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

Первичные ключи

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

В правильно построенной реляционной базе данных в каждой таблице есть один или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы. Давайте вновь посмотрим на базу данных, показанную на рис. 1.6. На первый взгляд, первичным ключом таблицы OFFICES могут служить и столбец OFFICE, и столбец CITY. Однако в случае, если компания будет расширяться и откроет в каком-либо городе второй офис, столбец CITY больше не сможет выполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса (OFFICE в таблице OFFICES), служащего (EMPL_NUM в таблице SALESREPS) и клиента (CUST_NUM в таблице CUSTOMES). А в случае; с таблицей ORDERS выбора нет — единственным столбцом, содержащим уникальные значения, является номер заказа (ORDER_NUM).

Таблица PRODUCTS, фрагмент которой показан на рис. 1.7, является примером таблицы, в которой первичный ключ представляет собой комбинацию столбцов. Такой первичный ключ называется составным. Столбец MRF_ID содержит идентификаторы производителей всех товаров, перечисленных в таблице, а столбец PRODUCT_ID содержит номера, присвоенные товарам производителями. Может показаться, что столбец PRODUCT_ID мог бы и один выполнять роль первичного ключа, однако ничто не мешает двум различным производителям присвоить своим изделиям одинаковые номера. Таким образом, в качестве первичного ключа таблицы PRODUCTS необходимо использовать комбинацию столбцов MRF_ID и PRODUCT_ID. Для каждого из товаров, содержащихся в таблице, комбинация значений в этих столбцах будет уникальной.

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

Отношения предок/потомок

Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Однако вполне очевидно, что отношения предок/потомок существуют и в реляционных базах данных. Например, в нашей базе данных каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между строками таблицы OFFICES и таблицы SALESREPS существует отношение. Не приводит ли отсутствие явных указателей в реляционной модели к потере информации?

Как следует из рис. 1.8, ответ на этот вопрос должен быть отрицательным. На рисунке изображено несколько строк из таблиц OFFICES и SALESREPS. Обратим внимание на то, что в столбце REP_OFFICE таблицы SALESREPS содержится идентификатор офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце OFFICE таблицы OFFICES. То, в каком офисе работает Мэри Джонс (Магу Jones), можно узнать, определив значение столбца REP_OFFICE в строке таблицы SALESREPS для Мэри Джонс (число II) и затем отыскав в таблице OFFICES строку с таким же значением в столбце OFFICE (это для офиса в Нью-Йорке). Таким же образом, чтобы найти всех служащих нью-йоркского офиса, следует запомнить значение столбца OFFICE для Нью-Йорка (число II), а потом просмотреть таблицу SALESREPS и найти все строки, в столбце REP_OFFICE которых содержится число 11 (это строки для Мэри Джонс и Сэма Кларка (Sam Clark)).

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

Внешние ключи

Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом. На рис. 4.9 столбец REP_OFFICE представляет собой внешний ключ для таблицы OFFICES. Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов. Эти значения соответствуют значениям в столбце OFFICE, который является первичным ключом таблицы OFFICES. Совокупно первичный и внешний ключи создают между таблицами, в которых они содержатся, такое же отношение предок/потомок, как и в иерархической базе данных.

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

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

• столбец REP является внешним ключом для таблицы SALESREPS и
  связывает каждый заказ со служащим, принявшим его;
• столбец CUST является внешним ключом для таблицы CUSTOMES и
  связывает каждый заказ с клиентом, разместившим его;
• столбцы MRF и PRODUCT совокупно представляют собой составной внешний ключ для таблицы PRODUCTS, который связывает каждый заказ с заказанным товаром.

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

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

Спецпроцессор (Сервер) Базы Данных

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

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

Требования, выдвигаемые спецпроцессором

Спецпроцессор базы данных выдвигает существенные требования к некоторым основополагающим технологиям. Во-первых, требуется, чтобы центральная машина обладала достаточной мощностью для обработки многопользовательской базы данных. Микрокомпьютеры старшего поколения, например, IBM PC XT, первые модели фирмы Macintosh, не обладали достаточной мощностью для поддержки сложных спецпроцессоров, а новые компьютеры предлагают намного большие возможности обработки. Фактически, центральные процессоры на базе микропроцессоров Intel 80386 и Motorola  68030 обеспечивают мощность, сопоставимую с мощностью миникомпьютеров. Некоторые разработчики сетей, например, фирма Novell, делают свои локальные сети открытыми и для миникомпьютеров, так что в качестве спецпроцессора базы данных в микрокомпьютерной локальной сети с успехом может использоваться миникомпьютер. Роль спецпроцессора может также выполнять большая ЭВМ; например, фирма IBM планирует обеспечить для расширенной версии подсистемы управления базами данных в OS/2 (OS/2 Extended Edition Database Manager) возможность поиска данных из базы данных DB2 на большой ЭВМ. 
Мощный процессор - это, конечно, не единственное требование, выдвигаемое спецпроцессорами. Для них требуются также жесткие диски, емкость и скорость которых достаточны для поддержания баз данных, по объему сопоставимых с хранимыми в системах на базе миникомпьютеров и больших ЭВМ. Для спецпроцессоров требуются также операционные системы, такие как Unix и OS/2, которые наиболее полно используют преимущества таких процессоров и дисков. Эти операционные системы обеспечивают мультизадачный режим и объем памяти, требующийся для развитых систем баз данных. Хотя и возможно построить спецпроцессор базы данных на основе операционной системы DOS, но ограничения однопроцессорной обработки и 640 Кбайт памяти делают DOS слабым фундаментом для спецпроцессора. Кроме того, локальная сеть должна быть достаточно мощной, для того чтобы обрабатывать передачу запросов и ответов между множеством пользователей и спецпроцессором. Многие существующие локальные сети обеспечивают производительность, необходимую для поддержки множества одновременно работающих пользователей. Наконец, система баз данных должна поддерживать многопользовательский режим, обеспечивая разумные уровни производительности, защиты и целостности. Так как системы баз данных на миникомпьютерах уже должны были столкнуться с этими проблемами, многие из современных спецпроцессоров уходят корнями в мир миникомпьютеров. Фирмы Oracle и INGRES предлагают спецпроцессоры на базе своих миникомпьютерных версий; фирма Sybase разработала одну из первых своих версий спецпроцессора Sybase/Microsoft/Ashton-Tate SQL для VAX. 
Пока еще рано говорить, насколько важной будет роль OS/2 в этой области. Она действительно предоставляет услуги, требуемые спецпроцессорами и поэтому имеет шансы стать важной основой для спецпроцессоров базы данных. В настоящее время OS/2 не может использовать преимущества некоторых особых характеристик процессора 80386, таких, как, например, подкачка памяти. Поставщики и пользователи с надеждой ожидают версию OS/2 для процессора 80386. Несмотря на упомянутый недостаток OS/2, многие поставщики объявили о спецпроцессорах базы данных на основе OS/2. Фирма IBM отметила даже, что разработанная ею расширенная версия подсистемы управления базами данных в OS/2, возможно, сможет выступать в роли спецпроцессора базы данных в локальной сети. В настоящее время уже есть такие системы, как Oracle фирмы Oracle Corp., SQL Server фирм Sybase/Microsoft/Ashton-Tate, SQL-Base фирмы Gupta Technology и др. Эти и другие подобные им программные продукты могут подтвердить право OS/2 на существование, в чем она так нуждается.

Основные функции спецпроцессора

Основной причиной того, что большинство спецпроцессоров основаны на миникомпьютерных системах баз данных, является сложность задач, которые должен обрабатывать спецпроцессор. Многие существующие системы баз данных не обладают необходимыми средствами для поддержания многопользовательского режима. Мультипользовательская система выдвигает такие требования, с которыми редко сталкиваются в автономной среде. Спецпроцессор базы данных должен быть прозрачным для пользователей. У большинства пользователей микрокомпьютеров есть полюбившиеся базы данных. В структуре пользователь - спецпроцессор пользователь использует привычную пользовательскую прикладную программу, но при этом эта программа получает данные от спецпроцессора, а не с локального диска. Многие разработчики баз данных поспешно добавляют эту возможность в свои программные продукты. Такие лидеры, как Ashton-Tate (dBase IV) и Borland (Paradox) уже объявили и поставляют средства для внутренних спецпроцессоров на базе языка SQL. Со стороны спецпроцессора все обстоит намного сложнее. Во-первых, спецпроцессор должен обрабатывать запросы в форме, подходящей для передачи по сети. Для достижения разумной производительности спецпроцессор должен минимизировать трафик сети. Это обычно означает, что должен быть язык манипулирования данными, позволяющий пользователям работать с несколькими записями одновременно. Неудивительно, что почти все имеющиеся спецпроцессоры представляют собой реляционные системы баз данных, использующие для манипулирования данными язык SQL. Пользовательские системы оформляют свои запросы на языке SQL, а спецпроцессор интерпретирует эти запросы и выбирает разумную стратегию для их выполнения. Более сложные проблемы возникают из-за необходимости одновременной поддержки нескольких пользователей. Пока речь идет только о считывании данных, проблемы не возникает: спецпроцессор легко может позволить многим пользователям одновременно считывать одни и те же данные. 
Но в случае модификации данных спецпроцессор должен обеспечить функции  блокирования файлов и записей в целях корректного обслуживания каждого пользователя. Корректность обслуживания в случае спецпроцессоров основывается на понятии логической единицы работы, называемой транзакцией.

Атомарные транзакции

Транзакция представляет собой последовательность связанных операций, которую система баз данных считает атомарной, т.е. система гарантирует, что операции в конкретной транзакции будут либо все успешно выполнены, либо все отвергнуты. Рассмотрим, например, транзакцию, которая пересылает деньги с одного счета на другой. Атомарная природа транзакции обеспечивает, что ее компоненты - снятие с одного счета и перечиление на другой счет - либо обе будут выполнены, либо обе будут отвергнуты.
Большинство систем баз данных, использующих понятие транзакции, следуют трем основным правилам. Во-первых, они поддерживают два способа завершения транзакции. Транзакция может завершиться нормально (операция "выполнение" - "commit") или аварийно (операция "откат" -"rollback"). Аварийное завершение означает отказ от всех операций, входящих в транзакцию.
Во-вторых, спецпроцессор должен гарантировать, что любые изменения базы данных, производимые транзакцией T, являются невидимыми для других транзакций до тех пор, пока транзакция T не выполнит эти изменения. Если же транзакция T оказывается возвращаемой, для базы данных это означает, что этой транзакции и не было. Следуя этому подходу, спецпроцессор предотвращает доступ к изменениям, производимым транзакцией T, со стороны других транзакций в случае аварийного завершения транзакции T.
И, наконец, в-третьих, спецпроцессору приходится считаться с тем фактом, что различные транзакции могут начинаться и завершаться в любой момент времени, в том числе и в середине других транзакций. Такие транзакции называют перемежающимися (intervealed transactions). Спецпроцессор базы данных должен выполнять перемежающиеся транзакции таким образом, что результаты их выполнения появляются последовательно; другими словами, что результат должен быть эквивалентен выполнению этих же самых транзакций по одной в каждый момент времени в некоторой последовательности. Кроме того, спецпроцессор должен выполнять эти требования таким образом, чтобы обеспечить разумную итоговую производительность. Блокирование всего файла, выполнение транзакций по одной, принцип "первым пришел - первым обслужился", - все это, конечно, соответствует вышеупомянутым правилам транзакции, но это не обеспечивает одновременности работы пользователей. Спецпроцессор базы данных должен автоматически находить правильное соотношение между блокированием таблицы (или файла), блока и записи, чтобы не только удовлетворять правилам транзакции, но и максимизировать число пользователей, одновременно разделяющих имеющиеся данные.
Так как все данные хранятся в одном месте, спецпроцессор должен также гарантировать целостность данных другими способами. Он должен обеспечить средства для резервного копирования данных и восстановления их в случае краха системы или разрушения базы данных. Проблемы могут возникать самые разные: от простых, например, в случае отказа машины пользователя в середине транзакции до разрушения диска, на котором хранятся все данные спецпроцессора. Атомарные транзакции часто играют определенную роль в этом процессе резервного копирования и восстановления. Периодически следует делать полные резервные копии базы данных спецпроцессора. Спецпроцессоры сами обычно поддерживают системные журналы с регистраций завершенных транзакций. Когда одна пользовательская транзакция срывается до своего завершения, спецпроцессор должен вернуть все в состояние, предшествующее ее началу. В случае аварии спецпроцессор может использовать последнюю полную резервную копию базы данных и свой системный журнал регистрации транзакций для восстановления базы данных. Спецпроцессор сначала загружает резервную копию, а затем использует журнал регистрации транзакций для внесения обновлений из всех завершенных транзакций; эта операция носит название "выход из аварийного состояния" (fallforward).

Достоинства спецпроцессоров

Централизованное хранение данных облегчает резервное копирование базы данных. Вместо того, чтобы выполнять резервное копирование на многих машинах, эта процедура выполняется только спецпроцессором. Пользователи освобождены от забот об этом. Централизация может также упростить решение проблемы защиты данных. Защита данных в случае автономного микрокомпьютера часто означает отыскание способов для ограничения доступа к самому микрокомпьютеру, связывая пароль со всей базой данных или удаляя базу данных, если она не используется. Большинство спецпроцессоров баз данных предлагают более мощные функции защиты. Язык SQL, например, включает операторы, позволяющие точно специфицировать, какие пользователи могут выполнять операции, какие именно операции и на каких частях базы данных. Архитектура пользователь - спецпроцессор также имеет потенциальные возможности использовать преимущества множества различных архитектур технического и программного обеспечения. В качестве пользовательских машин можно использовать машины с MS-DOS и фирмы Macintosh, а также все связанное с ними прикладное программное обеспечение. Желательно, по-видимому, чтобы спецпроцессор был мощной системой (например, миникомпьютер или микрокомпьютер на базе микропроцессора 80386). 
Спецпроцессор может также использовать более сложную операционную среду по сравнению с пользовательскими машинами, т.к. только у администраторов данных возникает потребность непосредственно использовать спецпроцессор. Таким образом, программное обеспечение спецпроцессора может выполняться на миникомпьютере под системой Unix. Хотя спецпроцессоры базы данных во многом сходны с распределенными системами баз данных, они имеют некоторые преимущества. Главное из них заключается в том, что в настоящее время имеется в продаже несколько различных спецпроцессоров базы данных и имеются они уже в течение некоторого времени, тогда как настоящие распределенные системы баз данных только начинают появляться. Спецпроцессоры базы данных также менее сложны и требуют меньших коммуникационных затрат, чем распределенные системы баз данных, причем существенно меньших, т.к. спецпроцессору не приходится управлять данными и обепечивать их целостность на множестве абонентских пунктов.

Недостатки спецпроцессоров

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

Разделение функций

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

Двенадцать правил Кодда

В статье, опубликованной в журнале "Computer World", Тэд Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. Двенадцать правил Кодда приведены в табл. 1.1. Они являются полуофициальным определением понятия реляционная база данных. Перечисленные правила основаны на теоретической работе Кодда, посвященной реляционной модели данных.

Таблица 1.1. Двенадцать правил Кодда, которым должна соответствовать _ реляционная СУБД. _

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

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

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

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

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

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

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

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

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

Правило 1 напоминает неформальное определение реляционной базы данных, приведенное ранее.

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

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

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

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

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

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

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

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

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

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