Использование системного каталога

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

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

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

■ SUSTEMCATALOG - здесь хранится информация о базовых таблицах и представлениях;

■ SUSTEMCOLUMNS - данные о полях таблиц;

■ SUSTEMTABLES - данные о системных таблицах системного каталога;

■ SUSTEMINDEXES - информация об индексах в таблице;

■ SUSTEMUSERAUTH - данные о пользователях БД;

■ SUSTEMTABAUTH - данные об объектных привилегиях пользователей;

■ SUSTEMCOLAUTH - данные о привилегиях пользователей в полях таблиц;

■ SUSTEMSYNONS -синонимы для таблиц №;

■ SUSTEMSYNONS - синонимы для таблиц.

Администратор БД может предоставить пользователю право просматривать SUSTEMCATALOG

следующей командой,

GRANT SELECTP ON SYSTEM CATALOG TO SHER;

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

CREATE VIEW OWNDB AS SELECT* FROM SUSTEMCATALOG WHERE OWNER = USER;

Подразделы SQL

Согласно рекомендации ANSI, SQL состоит из следующих разделов: Язык Определения Данных (ЯОД или DDL), Язык Манипулирования Данными (ЯМД или DML), Язык Управления Данными (ЯМД или DCL). Последний раздел может включаться в ЯМД. Первый раздел служит для определения схем данных (таблиц), второй – для манипуляций данными, которые выполняются через запросы к базе данных.Интерактивный и встроенный SQL

В стандарте предусмотрено существование двух форм языка: интерактивной и встроенной. Первая форма предполагает работу непосредственно в среде SQL и не требует наличия какой-либо другой программной среды. Считается, что запросы формулируются в режиме диалога и выполняются интерпретатором языка. Во втором случае язык каким-то способом встраивается в другую языковую систему и общается с пользователем через нее. То есть, интерфейс обеспечивает среда другого языка, а SQL выполняет запросы, поступающие из программы. В чистом виде это реализовано, например, в среде Delphi, а FoxPro даже включает операторы SQL в базовый язык.

Модели транзакций

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

Транзакция рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. В то же время это логическая единица работы системы. Рассмотрим несколько примеров. Что может быть названо транзакцией? Кем определяется, какая последовательность операций над базой данных составляет транзакцию? Конечно, однозначно именно разработчик определяет, какая последовательность операций составляет единое целое, то есть транзакцию. Разработчик приложений или хранимых процедур определяет это исходя из смысла обработки данных, именно семантика совокупности операций над базой данных, которая моделирует с точки зрения разработчика некоторую одну неразрывную работу, и составляет транзакцию. Допустим, выделим работу по вводу данных о поступивших книгах, новых книгах, которых не было раньше в библиотеке. Тогда эту операцию можно разбить на две последовательные: сначала ввод данных о книге — это новая строка в таблице ВООКS, а потом ввод данных обо всех экземплярах новой книги — это ввод набора новых строк в таблицу ЕХЕМРLAR в количестве, равном количеству поступивших экземпляров книги. Если эта последовательность работ будет прервана, то наша база данных не будет соответствовать реальному объекту, поэтому желательно выполнять ее как единую работу над базой данных.

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

ввод нового заказа со всеми реквизитами заказчика;

изменения состояния для всех выбранных комплектующих на складе на “занято” с привязкой их к определенному заказу;

подсчет стоимости заказа с формированием платежного документа типа выставляемого счета к оплате;

включение нового заказа в производство.

С точки зрения работника, это единая последовательность операций; если она будет прервана, то база данных потеряет свое целостное состояние.

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

Свойства транзакций. Способы завершения транзакций

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

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

Плоские, или традиционные, транзакции, характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) — АСID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют АСID-транзакциями. Упомянутые выше свойства означают следующее:

Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных.

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

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

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

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

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

Если в процессе выполнения транзакции случилось нечто такое, что делает невозможным ее нормальное завершение, база данных должна быть возвращена в исходное состояние. Откат транзакции — это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами 50Ь в теле текущей незавершенной транзакции.

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

В стандарте АNSI/ISO SQL определены модель транзакций и функции операторов СОММIТ и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе, изменяющего текущее состояние базы данных. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных путей (рис. 11.1):

1) оператор СОММIТ означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;

2) оператор ROLLВАСК прерывает транзакцию, отменяя изменения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLВАСК;

3) успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор СОММIТ);

4) ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLВАСК).

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

В первых версиях коммерческих СУБД была реализована модель транзакций АNSI/ISO. В дальнейшем в СУБД SYВАSЕ была реализована расширенная модель транзакций, которая включает еще ряд дополнительных операций. В модели SУВАSЕ используются следующие четыре оператора:

Оператор ВЕGIN ТRANSACTION сообщает о начале транзакции. В отличие от модели в стандарте АNSI/ISO, где начало транзакции неявно задается первым оператором модификации данных, в модели 5УВА8Е начало транзакции задается явно с помощью оператора начала транзакции.

Оператор СОММIT ТRANSACTION сообщает об успешном завершении транзакции.

Он эквивалентен оператору СОММ1Т в модели стандарта АNSI/ISO. Этот оператор, как и оператор СОММIТ, фиксирует все изменения, которые производились в БД в процессе выполнения транзакции.

Оператор SАVЕ TRANSACTION создает внутри транзакции точку сохранения, которая соответствует промежуточному состоянию БД, сохраненному на момент выполнения этого оператора. В операторе SAVE TRANSACTION может стоять имя точки сохранения. Поэтому в ходе выполнения транзакции может быть запомнено несколько точек сохранения, соответствующих нескольким промежуточным состояниям.

Оператор ROLLВАСК имеет две модификации. Если этот оператор используется без дополнительного параметра, то он интерпретируется как оператор отката всей транзакции, то есть в этом случае он эквивалентен оператору отката ROLLВАСК в модели АNSI/ISO. Если же оператор отката имеет параметр и записан в виде ROLLВАСК В, то он интерпретируется как оператор частичного отката транзакции в точку сохранения В.

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

Транзакция начинается явным оператором начала транзакции, который имеет в нашей схеме номер 1. Далее идет оператор 2, который является оператором поиска и не меняет текущее состояние БД, а следующие за ним операторы 3 и 4 переводят базу данных уже в новое состояние. Оператор 5 сохраняет это новое промежуточное состояние БД и помечает его как промежуточное состояние в точке А. Далее следуют операторы 6 и 7, которые переводят базу данных в новое состояние. А оператор 8 сохраняет это состояние как промежуточное состояние в точке В. Оператор 9 выполняет ввод новых данных, а оператор 10 проводит некоторую проверку условия 1; если условие 1 выполнено, то выполняется оператор 11, который проводит откат транзакции в промежуточное состояние В. Это означает, что последствия действий оператора 9 как бы стираются и база данных снова возвращается в промежуточное состояние В, хотя после выполнения оператора 9 она уже находилась в новом состоянии. И после отката транзакции вместо оператора 9, который выполнялся раньше из состояния В БД, выполняется оператор 13 ввода новых данных, и далее управление передается оператору 14. Оператор 14 снова проверяет условие, но уже некоторое новое условие 2; если условие выполнено, то управление передается оператору 15, который выполняет откат транзакции в промежуточное состояние А, то есть все операторы, которые изменяли БД, начиная с 6 и заканчивая 13, считаются невыполненными, то есть результаты их выполнения исчезли и мы снова находимся в состоянии А, как после выполнения оператора 4. Далее управление передается оператору 17, который обновляет содержимое БД, после этого управление передается оператору 18, который связан с проверкой условия 3.

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

Конечно, расширенная модель транзакции, предложенная фирмой 5УВАЗЕ, поддерживьет гораздо более гибкий механизм выполнения транзакций. Точки сохранения позволяют устанавливать маркеры внутри транзакции таким образом, чтобы имелась возможность отмены только части работы, проделанной в транзакции. Целесообразно использовать точки сохранения в длинных и сложных транзакциях, чтобы обеспечить возможность отмены изменения для определенных операторов. Однако это обусловливает дополнительные затраты ресурсов системы — оператор выполняет работу, а изменения затем отменяются; обычно усовершенствования в логике обработки могут оказаться более оптимальным решением.

Журнал транзакций

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

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

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

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

результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

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

Индивидуальный откат транзакции.

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

стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLВАСК;

аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLВАСК, но физически имеет иной механизм выполнения;

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

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

при аварийном выключении электрического питания;

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

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

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

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

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

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

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

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

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

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

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

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

1. Когда транзакция Т1 начинается, в протокол заносится запись

<Т1 Begin Transaction>

2. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <Т1, ID_RECORD, атрибут, новое значение... >. Здесь ID_RECORD — уникальный номер записи.

3. Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <ТI СОММIТ>.

4. После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД.

5. Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <Т1 ВЕGIN TRANSACTION> и <Т1 СОММIТ>. БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDO(), которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке.

6. Если в протоколе не содержится команда фиксации транзакции СОММIТ, то никаких действий проводить не требуется, а транзакция запускается заново.

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1, ID_RECORD, атрибут новое значение старое значение...>. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда <Т1 СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды ВЕGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

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

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

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

Журнализация и буферизация

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

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

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

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

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

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

Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется WRITE AHEAD LOG (WAL) — “пиши сначала в журнал” и состоит в том, что если требуется записать во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать запись во внешнюю память журнала транзакций записи о его изменении.

Интерактивный и встроенный SQL

Интерактивный SQL более близок к стандартному, а во вложенном очень часто

встречаются отклонения и дополнения. Например, в стандартном SQL различаются

только два типа данных: строки и числа, но некоторые производители добавляют свои

типы (Date, Time, Binary и т.д.). Числа в SQL делятся на два типа: целые (INTEGER или

INT) и дробные (DECIMAL или DEC). Строки ограничены размером в 254 символа.

Более подробную информацию о SQL ты найдешь в документе «Язык запросов

Литература

1. Астахова И.Ф., Толстобров А.П. SQL в примерах и задачах. Учебное пособие, 2002.

2. Атре Ш. Структурный подход к организации баз данных: Пер. с англ. – М.: Финансы и статистика, 1983. –317 с.

3. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2002.

4. Грабер М. Введение в SQL. – М.: «ЛОРИ», 1996. – 375 с.

5. Дейт К. Введение в системы баз данных, 8 изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2005.

6. Дейт К. Руководство по реляционной СУБД DB2: Пер. с англ. – М.: Финансы и статистика, 1988. –320 с.

7. Жоголев Е.А. Введению в технологию программирования. Конспект лекций. – М.: «ДИАЛОГ-МГУ», 1994. – 112 с.

8. Когаловский М.Р. Энциклопедия технологий баз данных. – М.: Финансы и статистика, 2002.

9. Кодд Э.Ф. Реляционная база данных: практическая основа эффективности. // Лекции лауреатов премии Тьюринга за первые двадцать лет 1966-1985. // Пер. с англ. – М.: Мир, 1993, с. 451-474.

10.Конноли Т. и др. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. – М.: Addison-Wesley, 2001.

11.Крёнке Д. Теория и практика построения баз данных, 9 изд. – М.: Питер, 2005.

12.Лукин В.Н.,.Марасанов А.М, Ротанина М.В., Чернышов Л.Н / Под ред. Марасанова А.М.. Использование СУБД в прикладных программных системах. – М.: МАИ, 1996. – 56 с.

13.Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. – М.: Финансы и статистика, 2004.

14.Мейер Д. Теория реляционных баз данных: Пер. с англ.: – М.: Мир 1987. – 608 с.

15.Озкарахан Э. Машины баз данных и управление базами данных: Пер с англ. – М.: Мир, 1989.

16.Попов А.А. FoxPro 2.6. – М.: Финансы и статистика.

17.Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление: Пер. с англ. – СПб.: БХВ-Петербург, 2004.

18.Тиори Т., Фрай Дж. Проектирование структур баз данных (в 2 томах): Пер. с англ. – М.: Мир, 1985.

19.Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 1983.

20.Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999.

21.Чен П. Модель "Сущность-Связь" – шаг к единому представлению данных. // СУБД, 1995, №3.