Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Содержание
Что такое базы данных и СУБД.
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого.
Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
физическом размещении в памяти данных и их описаний;
механизмах поиска запрашиваемых данных;
проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
поддержании баз данных в актуальном состоянии
и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных.
Основные понятия.
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут.
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Реляционный подход.
В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".
Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц.
Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа.
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву").
Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.
Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).
Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.
Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным.
Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.
Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:
Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.
Каждое отношение обладает хотя бы одним возможным ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.
Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных.
Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.
Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы.
Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language – структуризованный язык запросов) и QBE (Quere-By-Example – запросы по образцу) .Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.
С помощью единственного запроса на любом из этих языков можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).
Введение в проектирование реляционных баз данных.
Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.)
Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые – предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями). (Первые можно сравнить с базами материально-технического снабжения или отдыха, а вторые – с овощными и обувными базами.)
Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений.
Основывая же проектирование БД на текущих и предвидимых приложениях, можно существенно ускорить создание высокоэффективной информационной системы, т.е. системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных.
При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации) [2, 3, 4, 6, 8, 9, 10]. Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет – пассажир, преподаватель – дисциплина, студент – сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик – по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с рассмотрения причин, которые заставили Кодда создать основы теории нормализации.
Пример проектирования базы данных "Библиотека”
База данных предназначена для хранения данных о приобретенных библиотекой изданиях (монографиях, справочниках, сборниках статей и т.п.), информации о местонахождении отдельных экземпляров (переплетов) каждого издания и сведений о читателях.
Для ведения библиотечных каталогов, организации поиска требуемых изданий и библиотечной статистики в базе должны храниться сведения, большая часть которых размещаются в аннотированных каталожных карточках. Анализ запросов на литературу (как читателями, так и сотрудниками библиотек) показывает, что для поиска подходящих изданий (по тематике, автору, художнику, издательству и т.п.) и отбора нужного (например, по аннотации) следует выделить следующие атрибуты каталожной карточки:
1. Автор (фамилия и имена (инициалы) или псевдоним каждого автора издания).
2. Название (заглавие) издания.
3. Номер тома (части, книги, выпуска).
4. Вид издания (сборник, справочник, монография, ...).
5. Составитель (фамилия и имена (инициалы) каждого из составителе издания).
6. Язык, с которого выполнен перевод издания.
7. Переводчик (фамилия и инициалы каждого переводчика).
8. Под чей редакцией (фамилия и имена (инициалы) каждого из титульных редакторов).
9. Художник (фамилия и имена (инициалы) каждого художника-иллюстратора) - для художественных изданий, иллюстрируемых оригинальными рисунками.
10. Повторность издания (второе, одиннадцатое и т.п.).
11. Характер переиздания (исправленное, дополненное, переработанное, стереотипное и т.п.).
12. Место издания (город).
13. Издательство (название издательства).
14. Год выпуска издания.
15. Издательская аннотация или реферат.
16. Библиотечный шифр (например, ББК 32.973).
17. Авторский знак (например, Д27).
Анализ определенных выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель на языке "Таблицы-связи".
К стержневым сущностям можно отнести:
Создатели (Код создателя, Создатель).Эта сущность отводится для хранения сведений об основных людях, принимавших участие в подготовке рукописи издания (авторах, составителях, титульных редакторах, переводчиках и художниках). Такое объединение допустимо, так как данные о разных создателях выбираются из одного домена (фамилия и имена) и исключает дублирование данных (один и тот же человек может играть разные роли в подготовке разных изданий). Например, С.Я.Маршак писал стихи (Сказка о глупом мышонке) и пьесы (Двенадцать месяцев), переводил Дж.Байрона, Р.Бернса, Г.Гейне и составлял сборники стихов.
Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жюль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код_создателя", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя.
Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_пере- плета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.
Издательства (Код_издательства, Название, Город).
Заглавия (Код_заглавия, Заглавие).
Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости (исключается необходимость ввода длинных текстовых названий для различных томов собраний сочинений, повторных изданий, учебников и т.п.).
Вид_издания (Вид_издания, Название_вида).
Характеры (Код_характера, Характер_переиздания).
Языки (Код_языка, Язык, Сокращение).
Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.
Места (Код_места, Номер_комнаты, Номер_стеллажа, Номер_ полки).
Один из кодов этой сущности (например, "-1") отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).
Читатели (Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон).
Две ключевые сущности, описывающие издание и его конкретные экземпляры, оказываются зависимыми от других сущностей и попадают в класс обозначений:
Издание (Код_издания, Код_заглавия, Вид_издания, Номер_тома, Авторский_знак, Библиотечн_шифр, Повторность, Код_издательства, Год_издания, Аннотация) [Заглавия, Вид_издания, Издательства];
Переплеты (Номер_переплета, Код_издания, Цена, Дата_приобретения)[Издания];
Стержневые сущности и обозначения связаны между собой ассоциациями:
Авторы [Создатели M, Издание N] (Код_создателя, Код_издания).
Составители [Создатели M, Издания N] (Код_создателя, Код_издания).
Редакторы [Создатели M, Издания N] (Код_создателя, Код_издания).
Художники [Создатели M, Издания N] (Код_создателя, Код_издания).
Переводчики [Создатели M, Издания N] (Код_создателя, Код_издания, Язык).
Переиздания [Характеры M, Издания N] (Код_характера, Код_издания).
Размещение [Места M, Переплеты N] (Код_места, Номер_переплета, Дата_размещения, Дата_изъятия).
Выдача [Читатели M, Переплеты N] (Номер_билета, Номер_переплета, Дата_выдачи, Срок, Дата_возврата).
И, наконец, для уменьшения объема часто используемого обозначения "Издания" из него выделена характеристика:
Аннотации (Код_издания, Аннотация) {Издание}.
Инфологическая модель базы данных "Библиотека", построенная с помощью языка "Таблицы-связи"
Листинг программы.
Представленная программа строит БД. БД представляет собой список учащихся в школе и распределение их по классам.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Grids, DBGrids, DB, DBTables, ExtCtrls, DBCtrls, StdCtrls,
ComCtrls, ToolWin, Menus, RpCon, RpConDS, RpDefine, RpRave, Buttons, shellapi,
XPMan, inifiles;
type
TForm1 = class(TForm)
DataSource1: TDataSource;
Table1: TTable;
DBGrid1: TDBGrid;
DBNavigator1: TDBNavigator;
Query1: TQuery;
Button1: TButton;
Button2: TButton;
MainMenu1: TMainMenu;
N1: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
N4: TMenuItem;
N5: TMenuItem;
ToolBar1: TToolBar;
RvProject1: TRvProject;
RvDataSetConnection1: TRvDataSetConnection;
SpeedButton1: TSpeedButton;
StatusBar1: TStatusBar;
Timer1: TTimer;
SpeedButton2: TSpeedButton;
XPManifest1: TXPManifest;
N6: TMenuItem;
Button3: TButton;
PageControl1: TPageControl;
TabSheet1: TTabSheet;
TabSheet2: TTabSheet;
TabSheet3: TTabSheet;
DBGrid2: TDBGrid;
DBGrid3: TDBGrid;
DBNavigator2: TDBNavigator;
DBNavigator3: TDBNavigator;
Table2: TTable;
Table3: TTable;
DataSource2: TDataSource;
DataSource3: TDataSource;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure FormActivate(Sender: TObject);
procedure N2Click(Sender: TObject);
procedure N5Click(Sender: TObject);
// procedure FormShow(Sender: TObject);
procedure SpeedButton1Click(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
procedure SpeedButton2Click(Sender: TObject);
procedure N3Click(Sender: TObject);
procedure N6Click(Sender: TObject);
procedure FormDestroy(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
Implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
fam:string[50];
begin
fam:=inputbox('Выборка информации из БД','Укажите фамилию и щелкните ОК.', '');
if fam<>'' then
begin
with form1.Query1 do
begin
close;
Close;
SQL.Clear;
SQL.Add('SELECT Fam, Name, Class');
SQL.Add('FROM ":nik-school:school.DB"');
SQL.Add('WHERE');
SQL.Add('(Fam = "'+ fam + '")');
SQL.Add('ORDER BY Name, Fam');
Open;
end;
if Query1.RecordCount <> 0 then
DataSource1.DataSet:=Query1
else begin
ShowMessage('В БД нет записей, удовлетворяющих критерию запроса.');
DataSource1.DataSet:=Table1;
end;
end;
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
datasource1.DataSet:=table1;
end;
procedure TForm1.FormActivate(Sender: TObject);
begin
with session do
begin
configmode:=cmsession;
try
addstandardalias('nik-school',extractfilepath(paramstr(0))+'data\','PARADOX');
datasource1.DataSet:=table1;
table1.Active:=true;
datasource2.DataSet:=table2;
table2.Active:=true;
datasource3.DataSet:=table3;
table3.Active:=true;
finally
configmode:=cmall;
end;
end;
end;
procedure TForm1.N2Click(Sender: TObject);
begin
RvProject1.Execute;
end;
procedure TForm1.N5Click(Sender: TObject);
begin
ShellExecute(form1.Handle,nil,'index.html',nil,nil,sw_show);
end;
{
procedure TForm1.FormShow(Sender: TObject);
begin
logo.showmodal;
end; }
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
RvProject1.Execute;
end;
procedure TForm1.Timer1Timer(Sender: TObject);
begin
form1.StatusBar1.Panels[4].Text:=' Время: ' + timetostr(now());
form1.StatusBar1.Panels[3].Text:=' Сегодня: ' + datetostr(date());
form1.StatusBar1.Panels[0].Text:='Кол-во записей: '+ inttostr(DBGrid1.DataSource.DataSet.RecordCount);
end;
procedure TForm1.SpeedButton2Click(Sender: TObject);
begin
ShellExecute(form1.Handle,nil,'index.html',nil,nil,sw_show);
end;
procedure TForm1.N3Click(Sender: TObject);
begin
close;
end;
procedure TForm1.N6Click(Sender: TObject);
begin
form3.Show;
end;
procedure TForm1.FormDestroy(Sender: TObject);
var
ini:tinifile;
begin
ini:=tinifile.Create(extractfilepath(paramstr(0))+'option.ini');
ini.WriteInteger('FORM_SIZE','height',form1.Height);
ini.WriteInteger('FORM_SIZE','width',form1.Width);
ini.WriteInteger('FORM_POSITION','x',form1.Left);
ini.WriteInteger('FORM_POSITION','y',form1.Top);
ini.WriteInteger('FORM_COLOR','color',form1.Color);
{настройки шрифта}
ini.WriteString('FORM_FONT','font',form1.Font.Name);
ini.WriteInteger('FORM_FONT','size',form1.Font.Size);
ini.Free;
end;
procedure TForm1.FormCreate(Sender: TObject);
var
ini:tinifile;
begin
form1.TabSheet1.Caption:='Таблица "Ученики"';
form1.TabSheet2.Caption:='Таблица "Преподаватели"';
form1.TabSheet3.Caption:='Таблица "Классы"';
ini:=tinifile.Create(extractfilepath(paramstr(0))+'option.ini');
form1.Height:=ini.ReadInteger('FORM_SIZE','height',100);
form1.Width:=ini.ReadInteger('FORM_SIZE','width',100);
form1.Left:=ini.ReadInteger('FORM_POSITION','x',10);
form1.Top:=ini.ReadInteger('FORM_POSITION','y',10);
form1.Color:=ini.ReadInteger('FORM_COLOR','color',10);
form1.Font.Name:=ini.ReadString('FORM_FONT','font','10');
form1.Button2.Font.Name:=ini.ReadString('FORM_FONT','font','10');
form1.Button1.Font.Name:=ini.ReadString('FORM_FONT','font','10');
form1.Font.Size:=ini.ReadInteger('FORM_FONT','size',10);
ini.Free;
end;
procedure TForm1.Button3Click(Sender: TObject);
var
fam:string[20];
begin
fam:=inputbox('Выборка информации из БД','Укажите фамилию и щелкните ОК.', '');
if fam<>'' then
begin
with form1.Query1 do
begin
close;
Close;
SQL.Clear;
SQL.Add('SELECT Fam, Name, Class');
SQL.Add('FROM ":nik-school:school.DB"');
SQL.Add('WHERE');
SQL.Add('(Name = "'+ fam + '")');
SQL.Add('ORDER BY Name, Fam');
Open;
end;
if Query1.RecordCount <> 0 then
DataSource1.DataSet:=Query1
else begin
ShowMessage('В БД нет записей, удовлетворяющих критерию запроса.');
DataSource1.DataSet:=Table1;
end;
end;
end;
end.
Список литературы
1.Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
2.Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
3.Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.
4.Джексон Г. Проектирование реляционных баз данных для и пользования с микроЭВМ. -М.: Мир, 1991. – 252 с.
5.Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
6.Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.
7.Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.
8.Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.
9.Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990. – 386 с.
10.Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
11.Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.