Реляционные Базы Данных. SQL - стандартный язык реляционных баз данных

Содержание:

Содержание2

Реляционныебазы данных3

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

Первые моделиданных3

Системыуправленияфайлами3

ИерархическиеСУБД4

Сетевые базыданных5

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

Таблицы8

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

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

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

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

ЯзыкSQLкак стандартныйязык баз данных14

Язык SQL15

РольSQL16

ДостоинстваSQL17

Независимостьот конкретныхСУБД18

Переносимостьс одной вычислительнойсистемы

на другую18

СтандартыязыкаSQL18

ОдобрениеSQLкомпанией IBM(DB2)19

ПротоколODBCи компанияMicrosoft19

Реляционнаяоснова19

Высокоуровневаяструктура,

напоминающаяанглийскийязык20

Интерактивныезапросы20

Программныйдоступ к базеданных20

Различныепредставленияданных20

Полноценныйязык для работыс базами данных20

Динамическоеопределениеданных21

Архитектураклиент/сервер21

СтандартыSQL21

СтандартыANSI/ISO21

Другие стандартыSQL22

ODBC иконсорциумSQL Access Group23

Миф о переносимости23

ВлияниеSQL25

SQL испецификацияSAAкомпании IBM25

SQL намини-компьютерах26

SQL на системахUNIX26
SQL и обработкатранзакций26

SQL на персональныхкомпьютерах27

SQL в локальныхсетях28

Списокиспользованнойлитературы30

Списокиспользованнойлитературы:

"SQLПолноеруководство"

BHV,Киев, 1998

"Программированиев среде СУБДFoxPro2.0"

Радиои связь, Москва,1993

"Эффективнаяработа с MicrosoftAccess 7.0"

Питер,Санкт-Петербург,1997

Санкт-ПетербургскийГосударственныйТехническийУниверситет

ФакультетЭкономики иМенеджмента

Кафедра"Мировая Экономика"

РЕФЕРАТ

По Информатике

на тему:

"РеляционныеБазы Данных.

SQL -стандартныйязык реляционныхбаз данных"

Выполнил:Егоров С. Н.гр.2078/2

Проверил:Первицкий А.Ю.

Санкт-Петербург

1999

1. Реляционныебазы данных

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

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

Первыемодели данных

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

Системыуправленияфайлами.

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

Рис 1.1. Приложениедля начислениязарплаты,использующеесистему управленияфайлами.

Программадля обновленияданных по служащим

ОСД

Программадля начислениязарплаты

ОСД

Программадля создания отчетов послужащим

ОСД

Рис. 1.1. Приложениедля начислениязарплаты,использующеесистему управленияфайлами.

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

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

ИерархическиеСУБД

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

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

Записи

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

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

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

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

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

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

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

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

Клиенты

Служащие

Товары

етевыебазы данных

Заказы

Рис. 1.3. Множественныеотношенияпредок/потомок

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

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

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

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

Клиенты

Товары

Заказы

Записи

Множество

омпанииCincom иСУБД Adabas,которые приобрелибольшую популярность.

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

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

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

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

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

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

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

ТаблицаCUSTOMERS
	COMPANY	CUST_REP	CREDIT_LIMIT
	JSPInc.	103	$50,000.00
FirstCorp.	101	$65,000.00

Рис.1.5. Реляционнаябаза данных,содержащаяинформациюо заказах

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

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

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

Таблицы

ТаблицаOFFICES
	OFFICE	CITY	REGION	MGR	TARGET	SALES
	22	Denver	Western	108	$300,000.00	$186,042.00
11	NewYork	Easten	106	$575,000.00	$692,000.00
12	Chicago	Easten	104	$800,000.00	$739,000.00
13	Atlanta	Easten	105	$350,000.00	$735,157.00
21	LosAngeles	Western	108	$725,000.00	$835,915.00

Город,в котором расположенофис

Идентификаторслужащего,управляющегоофисом

Объёмпродаж офисас начала года

Данныеоб офисе в Нью-Йорке

Данныеоб офисе вЛос-Анджелесе

Рис.1.6. Структурареляционнойтаблицы.

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

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

На пересечениикаждой строкис каждым столбцомтаблицы содержитсяв точности однозначение данных.Например, встроке, представляющейнью-йоркскийофис, в столбцеCITYсодержитсязначение "NewYork". В столбце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.Для каждогоиз товаров,содержащихсяв таблице, к

ТаблицаPRODUCTS
	MFR_ID	PRODUCT_ID	DESCRIPTION	PRICE	QTY_ON_HAND
	REI	2A45C	RatchetLink	$79.00	210
ACI	4100Y	WidgetRemover	$2,750.00	25
QSA	KX47	Reducer	$355.00	38
BIC	41672	Plate	$180.00	0

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

Рис.1.7. Пример таблицыс составнымпервичнымключом

омбинациязначений в этихстолбцах будетуникальной.

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

Хотя первичныеключи являютсяважной частьюреляционноймодели данных,в первых реляционныхСУБД(System/R, DB2, Oracle и других)не была обеспеченаявным образомих поддержка.Как правило,проектировщикибазы данныхсами следилиза тем, чтобыу всех таблицбыли первичныеключи, однаков самих СУБДне было возможностиопределитьдля таблицыпервичный ключ.И только в СУБДDB2 Version2, появившейсяв апреле 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 (это строкидля Мэри Джонси С

ТаблицаOFFICES
ТаблицаOFFICES	OFFICE	CITY	REGION
22	Denver	Western
11	NewYork	Eastern
12	Chicago	Eastern

ТаблицаSALESREPS
ТаблицаSALESREPS	EMPL_NUM	NAME	AGE	REP_OFFICE
105	BillAdams	37	13
109	MaryJones	31	11
102	SueSmith	48	21
106	SamClark	52	11

Рис.1.8. Отношениепредок/потомокв реляционнойбазе данных

эма Кларка(Sam Clark)).

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

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

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

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

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

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

ТаблицаCUSTOMERS
ТаблицаCUSTOMERS	CUST_NUM	COMPANY
…
2117	J.P.Sinclair
…

ТаблицаSALESREPS
ТаблицаSALESREPS	EMPL_NUM	NAME
…
106	SamClark
…

ТаблицаPRODUCTS
ТаблицаPRODUCTS	MFR_ID	PRODUCT_ID	DESCRIPTION
…
REI	2A44L	LeftHinge
…

ТаблицаORDERS
ТаблицаORDERS	ORDER_NUM	ORDER_DATE	CUST	REP	MFR	PRODUCT
…
112967	17-DEC-89	2117	106	REI	2A44L
…

Рис. 1.9. Множественныеотношенияпредок/потомокв реляционнойбазе данных

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

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

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

В статье,опубликованнойв журнале"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 предотвращаетиспользованиедругих возможностейдля работы сбазой данных,помимо языкабазы данных,поскольку этоможет нарушитьее целостность.

2. ЯзыкSQLкак стандартныйязык баз данных.

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

ЯзыкSQL

Рис.2.1. ПрименениеSQLдля доступак базе данных

QL являетсяинструментом,предназначеннымдля обработкии чтения данных,содержащихсяв компьютернойбазе данных.SQL- это сокращенноеназваниеструктурированногоязыка запросов(Structured Query Language).Как следуетиз названия,SQL являетсяязыкомпрограммирования,который применяетсядля организациивзаимодействияпользователяс базой данных.На самом делеSQLработает толькос базами данныходного определенноготипа, называемыхреляционными.На рис.2.1 изображенасхема работыSQL. Согласноэтой схеме, ввычислительнойсистеме имеетсябаза данных,в которой хранитсяважная информация.Если вычислительнаясистема относитсяк сфере бизнеса,то в базе данныхможет хранитьсяинформацияо материальныхценностях,выпускаемойпродукции,объемах продажи зарплате. Вбазе данныхна персональномкомпьютереможет хранитьсяинформацияо выписанныхчеках, телефонахи адресах илиинформация,извлеченнаяиз более крупнойвычислительнойсистемы. Компьютернаяпрограмма,которая управляетбазой данных,называетсясистемойуправлениябазой данных,или СУБД.

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

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

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

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

Таким образом,SQL являетсядостаточномощным языкомдля взаимодействияс СУБД.

Во-вторых,SQL —это не полноценныйкомпьютерныйязык типа COBOL,FORTRAN или С. ВSQL нет оператораIFдля проверкиусловий, нетоператораGOTO для организациипереходов инет операторовDOили FORдля созданияциклов.SQL являетсяподъязыкомбаз данных, вкоторый входитоколо тридцатиоператоров,предназначенныхдля управлениябазами данных.ОператорыSQL встраиваютсяв базовый язык,напримерCOBOL, FORTRAN или С,и дают возможностьполучать доступк базам данных.Кроме того, изтакого языка,как С, операторыSQL можнопосылать СУБДв явном виде,используяинтерфейсвызовов функций.

Наконец,SQL —это слабоструктурированныйязык, особеннопо сравнениюс такими сильноструктурированнымиязыками, какС илиPascal. ОператорыSQL напоминаютанглийскиепредложенияи содержат"слова-пустышки",не влияющиена смысл оператора,но облегчающиеего чтение. ВSQL почтинет нелогичностей,к тому же имеетсяряд специальныхправил, предотвращающихсоздание операторовSQL, которыевыглядят какабсолютноправильные,но не имеютсмысла.

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

РольSQL

Сам по себеSQL не являетсяни системойуправлениябазами данных,ни отдельнымпрограммнымпродуктом.Нельзя пойтив компьютерныймагазини "купитьSQL". SQL —это неотъемлемаячасть СУБД,инструмент,с помощьюкоторогоосуществляетсясвязь пользователяс ней. На рис.2.2. изображенаструктурнаясхема типичнойСУБД, компонентыкоторой соединяютсяв единое целоес помощьюSQL (своегорода "клея").

Ядро базыданныхявляется сердцевинойСУБД; оно отвечаетза физическоеструктурированиеи запись данныхна диск, а такжеза физическоечтение данныхс диска. Крометого, оно принимаетSQL-запросыот других компонентовСУБД (таких какгенератор форм,генераторотчетов илимодуль формированияинтерактивныхзапросов), отпользовательскихприложенийи даже от другихвычислительныхсистем. Каквидно из рисунка,SQLвыполняет многоразличныхфункций:

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

Рис.2.2. Компонентытипичной СУБД

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

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

ДостоинстваSQL

SQL— это легкийдля пониманияязык и в то жевремя универсальноепрограммноесредство управленияданными.

Успех языкуSQL принеслиследующие егоособенности:

• независимостьот конкретныхСУБД;

• переносимостьс одной вычислительнойсистемы надругую;

• наличиестандартов;

• одобрениекомпаниейIBM (СУБДDB2);

• поддержкасо стороныкомпанииMicrosoft (протоколODBC);

• реляционнаяоснова;

• высокоуровневаяструктура,напоминающаяанглийскийязык;

• возможностьвыполненияспециальныхинтерактивныхзапросов:

• обеспечениепрограммногодоступа к базамданных;

• возможностьразличногопредставленияданных;

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

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

• поддержкаархитектурыклиент/сервер.

Все перечисленныевыше факторыявились причинойтого, чтоSQL сталстандартныминструментомдля управленияданными наперсональныхкомпьютерах,мини-компьютерахи больших ЭВМ.Ниже эти факторырассмотреныболее подробно.

Независимостьот конкретныхСУБД

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

Переносимостьс одной вычислительнойсистемы надругие

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

СтандартыязыкаSQL

Официальныйстандарт языкаSQL был опубликованАмериканскиминститутомнациональныхстандартов(American National Standards Institute— ANSI)и Международнойорганизациейпо стандартам(International Standards Organization— ISO)в 1986году и значительнорасширен в1992 году. Крометого,SQL являетсяфедеральнымстандартомСША по обработкеинформации(FIPS —Federal Information Processing Standard)и, следовательно,соответствиеему являетсяодним из основныхтребований,содержащихсяв большихправительственныхконтрактах,относящихсяк областивычислительнойтехники. В ЕвропестандартX/OPEN для переносимойсреды программированияна основеоперационнойсистемыUNIX включаетв себя SQLв качествестандарта длядоступа к базамданных.SQL Access Group —консорциумпоставщиковкомпьютерногооборудованияи баз данных— определилдля SQLстандартныйинтерфейсвызовов функций,который являетсяосновой протоколаODBC компанииMicrosoft и входиттакже в стандартX/OPEN. Эти стандартыслужат как быофициальнойпечатью, одобряющейSQL, и ониускорили завоеваниеим рынка.

ОдобрениеSQL компаниейIBM (СУБДDB2)

SQL былпридуман научнымисотрудникамикомпанииIBM и широкоиспользуетсяею во множествепакетов программногообеспечения.Подтверждениемэтому служитфлагманскаяСУБД DB2компанииIBM. Все основныесемействакомпьютеровкомпанииIBM поддерживаютSQL: системаPS/2 дляперсональныхкомпьютеров,система среднегоуровняAS/400. системаRS/6000 на базеUNIX, а такжеоперационныесистемыMVS иVM большихЭВМ. ШирокаяподдержкаSQL фирмойIBM ускорилаего признаниеи еще в самомначале возникновенияи развитиярынка баз данныхявилась своегорода недвусмысленнымуказанием длядругих поставщиковбаз данных ипрограммныхсистем, в какомнаправлениинеобходимодвигаться.

ПротоколODBC и компанияMicrosoft

КомпанияMicrosoft рассматриваетдоступ к базамданных какважную частьсвоей операционнойсистемыWindows. Стандартомэтой компаниипо обеспечениюдоступа к базамданных являетсяODBC (Open Database Connectivity— взаимодействиес открытымибазами данных)— программныйинтерфейс,основанныйна SQL.ПротоколODBC поддерживаетсянаиболеераспространеннымиприложениямиWindows (электроннымитаблицами,текстовымипроцессорами,базами данныхи т.п.), разработаннымикак самой компаниейMicrosoft, так идругими ведущимипоставщиками.Поддержка ODBCобеспечиваетсявсеми ведущимиреляционнымибазами данных.Кроме того,ODBC опираетсяна стандарты,одобренныеконсорциумомпоставщиковSQL Access Group, чтоделаетODBC как стандартомде-факто компанииMicrosoft, так истандартом,независимымот конкретныхСУБД.

Реляционнаяоснова

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

Высокоуровневаяструктура,

напоминающаяанглийскийязык

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

Интерактивныезапросы

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

Программныйдоступ к базеданных

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

Различныепредставленияданных

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

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

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

Динамическоеопределениеданных

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

Архитектураклиент/сервер

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

3.Стандарты SQL

Одним изнаиболее важныхшагов на путик признаниюSQL на рынкестало появлениестандартовна этот язык.Обычно приупоминаниистандарта SQLимеют в видуофициальныйстандарт,утвержденныйАмериканскиминститутомнациональныхстандартов(American National Standards Institute— ANSI)и Международнойорганизациейпо стандартам(International Standards Organization—ISO). Однакосуществуюти другие важныестандартыSQL, включаяSQL, реализованныйв системеDB2 компанииIBM, и стандартX/OPEN дляSQL в средеUNIX.

СтандартыANSI/ISO

Работа надофициальнымстандартомSQL началасьв 1982году, когдаANSIпоставил передсвоим комитетомХЗН2 задачу посозданию стандартаязыка реляционныхбаз данных.Вначале в комитетеобсуждалисьдостоинстваразличныхпредложенныхязыков. Однакопоскольку ктому времениSQLуже стал фактическимстандартом,комитетХЗН2 остановилсвой выбор нанем и занялсястандартизациейSQL.

Разработанныйв результатестандарт вбольшой степенибыл основанна диалектеSQL системыDB/2, хотя исодержал в себеряд существенныхотличий отэтого диалекта.После несколькихдоработок, в1986 году стандартбыл официальноутвержден какстандартANSI номерХ3.135, а в 1987году —в качествестандартаISO. ЗатемстандартANSI/ISO был принятправительствомСША как федеральныйстандарт СШАпо обработкеинформации(FIPS— FederalInformation Processing Standard). Этотстандарт,незначительнопересмотренныйв 1989году, обычноназывают стандартом"SQL-89", ил"SQLI".Когда в даннойкниге упоминается"стандартANSI/ISO", топодразумеваетсяSQLI, которыйв настоящеевремя лежитв основе большинствакоммерческихпродуктов.

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

Чтобы заполнитьэти пробелы,комитетANSI продолжилсвою работуи создал проектнового, болеежесткого стандартаSQL2. В отличиеот стандарта1989года, проектSQL2 предусматривалвозможности,выходящие зарамки таковых,уже существующихв реальныхкоммерческихпродуктах. Адля следующегоза ним стандартаSQL3 былипредложеныеще более глубокиеизменения. ВрезультатепредложенныестандартыSQL2 иSQL3 оказалисьболее противоречивыми,чем исходныйстандарт. СтандартSQL2 прошелпроцесс утвержденияв ANSIи был окончательнопринят в октябре1992 года. Вто время, какпервый стандарт1986 года занимаетне более стастраниц, официальныйстандартSQL2 содержитоколо шестисот.

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

ДругиестандартыSQL

Хотя стандартANSI/ISO наиболеешироко распространен,он не являетсяединственнымстандартомSQL. Европейскаягруппа поставщиковX/OPEN такжепринялаSQL в качествеодного из своихстандартовдля "средыпереносимыхприложений"на основеUNIX. СтандартыгруппыX/OPEN играютважную рольна европейскомкомпьютерномрынке, где основнойпроблемойявляетсяпереносимостьприложениймежду компьютернымисистемамиразличныхпроизводителей.К несчастью,стандартX/OPEN отличаетсяот стандартаANSI/ISO.

Кроме того,компанияIBM включилаSQL в своюспецификациюSystems Application Architecture(архитектураприкладныхсистем) и пообещала,что все ее продукты,очевидно, будутпереведенына этот диалектSQL. Хотя даннаяспецификацияи не оправдаланадежд на унификациюлинии продуктовкомпанииIBM, движениев сторону унификацииSQL вIBM продолжается.СистемаDB2 остаетсяосновной СУБДкомпанииIBM для мэйнфреймов.Однако компаниявыпустилареализациюDB2 и дляOS/2собственнойоперационнойсистемы дляперсональныхкомпьютеров,и для линиисерверов ирабочих станцийRS/6000, работающихпод управлениемUNIX.Таким образом,диалектDB2 языкаSQL являетсямощным стандартомде-факто.

ODBC uконсорциумSQL Access Group

В технологиибаз данныхсуществуетважная область,которую незатрагиваютофициальныестандарты. Этоспособностьк взаимодействиюс другими базамиданных— методы,с помощью которыхразличные базыданных могутобмениватьсяданными (какправило, посети). В1989 годунесколькопоставщиковсформироваликонсорциумSQL Access Group специальнодля решенияэтой проблемы.В 1991году консорциумопубликовалспецификациюRDA (Remote Database Access— удаленныйдоступ к базамданных). К несчастью,эта спецификациятесно связанас протоколамиOSI, которыене смогли завоеватьширокого признания,поэтому онаоказывает нарынок незначительноевлияние. Прозрачностьвзаимодействиямежду различнымибазами данныхостается иллюзорноймечтой.

Тем не менее,второй стандартот SQL AccessGroup имеетна рынке большийвес. В результатенастойчивыхтребованийкомпанииMicrosoft, консорциумSQL Access Group включилв стандартSQL интерфейсвызовов функций.ПолученнаяспецификацияCLI (Call Level Interface), основаннаяна разработкахкомпанииMicrosoft, увиделасвет в1992 году. Вэтом же году
былаопубликованасобственнаяспецификацияODBC (Open Database Connectivity— взаимодействиес открытымибазами данных)компанииMicrosoft, основаннаяна стандартеCLI. Благодарярыночной силеMicrosoft и благословению,полученному"открытымстандартом"от SQL AccessGroup, ODBC оказалсястандартомде-факто дляинтерфейсовдоступа к базамданных наперсональныхкомпьютерах.Весной1993 года компанииApple и Microsoftобъявили осоглашенииотносительноподдержкиODBC вMacOS иWindows, что закрепилоза этой спецификациейстатус стандартав обеих популярныхсредах с графическимпользовательскиминтерфейсом.

Миф опереносимости

ПоявлениестандартаSQL вызвалодовольно многовосторженныхзаявлений опереносимостиSQL и использующихего приложений.Для иллюстрациитого, как любоеприложение,используяSQL, можетработать слюбой СУБД,часто приводятдиаграммы,подобные изображеннойна рис.3.1. На самомделе пробелыв стандартеSQL-89 и различиямежду существующимидиалектамиSQL достаточнозначительны,и при переводеприложенияпод другую СУБДего всегдаприходитсямодифицировать.Эти отличия,большинствоиз которыхустранено встандартеSQL2, включаютв себя:

Коды ошибок.В стандартеSQL-89 не определеныкоды, которыевозвращаютоператорыSQL при возникновенииошибок, и в каждойиз коммерческихреализацийиспользуетсясобственныйнабор такихкодов. В стандартеSQL2 определеныстандартныекоды ошибок.
Типы данных.В стандартеSQL-89 определенминимальныйнабор типовданных, однаков нем отсутствуютнекоторые изнаиболеераспространенныхи полезныхтипов, напримерсимвольныестроки переменнойдлины, дата ивремя, а такжеденежные единицы.В стандартеSQL2 упомянутыэти типы данных,однако отсутствуют"новые" типыданных, такиекак графическиеи мультимедийныеобъекты.
Системныетаблицы.В стандартеSQL-89 умалчиваетсяо системныхтаблицах, вкоторых содержитсяинформацияо структуресамой базыданных. Поэтомукаждый поставщиксоздавал собственныесистемныетаблицы, и ихструктураотличаетсядаже в четырехреализацияхSQL компанииIBM. Системныетаблицы стандартизированыв SQL2.
ИнтерактивныйSQL. В стандартеопределентолько программныйSQL, используемыйприкладнойпрограммой,но не интерактивныйSQL. Например,операторselect,предназначенныйдля выполнениязапросов кбазе данныхв интерактивномрежиме, в стандартеотсутствует.
Программныйинтерфейс.В первом стандартеопределенабстрактныйспособ использованияSQL в программах,написанныхна таких языкахпрограммирования,как COBOL,FORTRAN и другие.Этот способне используетсяни в одномкоммерческомпродукте, а всуществующихпрограммныхинтерфейсахимеются значительныеотличия. В стандартеSQL2определенинтерфейсвстроенногоSQL для популярныхязыков программирования,но не интерфейсвызова функций.
ДинамическийSQL. В стандартеSQL-89 не описаныэлементыSQL, необходимыедля разработкиприложенийобщего назначения,таких как генераторыотчетов и программысоздания ивыполнениязапросов. Однакоэти элементы,известные подназваниемдинамическийSQL, имеютсяпочти во всехСУБД и в различныхсистемах значительноотличаются.В SQL2входит стандартдинамическогоSQL.
Семантическиеотличия.Посколькунекоторыеэлементы определеныв стандартахкак зависящиеот реализации,может возникнутьситуация, когдав результатевыполненияодного и тогоже запроса вдвух совместимыхСУБД будутполучены дваразличныхнабора результатов.Отличия результатовобусловленыразличиямив обработкезначенийnull,разнымиагрегатнымифункциями инесовпадениемпроцедур удаленияповторяющихсястрок.
Последовательностьсравнения.В стандартеSQL-89 не упоминаютсяпоследовательностисравнения(сортировки)символов, хранящихсяв базе данных.Результатызапроса ссортировкойбудут отличатьсяпри выполненииэтого запросана персональномкомпьютере(с кодировкойASCII) и на мэйнфрейме(с кодировкойEBCDIC). СтандартSQL2 позволяетпрограмме илипользователюуказыватьтребуемуюпоследовательностьсортировки.
С

Приложение# 1

Приложение# 2

Приложение# 3

Приложение# 4

СтандартSQL

СУБД # 1

СУБД # 2

СУБД # 3

Рис.3.1. Миф о переносимостиSQL
труктура базыданных.В стандартеSQL-89 определенSQL, которыйиспользуетсяуже после того,как база данныхбыла открытаи подготовленак работе. Деталинаименованиябаз данных ипервоначальногоподключенияк ним сильноотличаютсяи несовместимы.СтандартSQL2 в некоторойстепени унифицируетэтот процесс,но не можетполностьюликвидироватьвсе отличия.

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

4. ВлияниеSQL

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

SQL испецификацияSAAкомпании IBM

SQL играетключевую рольв качествеязыка доступак базам данных,объединяющегомногочисленныенесовместимыекомпьютерныесемействакомпанииIBM. Эта рольбыла отведенаему еще в спецификацииSAA (SystemsApplication Architecture —архитектураприкладныхсистем)компанииIBM в1987 году. Хотяглавные целиSAA так и небыли достигнуты,объединяющаярольSQL со временемстала еще важнее.СтратегическимипрограммнымипродуктамикомпанииIBM, предназначеннымидля работыс базамиданных, являются

DB2.ФлагманскаяреляционнаяСУБД, являющаясястандартомSQL длямэйнфреймовкомпанииIBM, работающихпод управлениемОС MVS.
SQL/DS.РеляционнаяСУБД дляVM, другойОС мэйнфреймовкомпанииIBM.
SQL/400.Эта реализацияSQL для системсреднего уровняподдерживаетвстроеннуюреляционнуюбазу данныхкомпьютеровсерииAS/400.
DB2/6000.Эта реализацияDB2 работаетна рабочихстанциях исерверахсемействаRS/6000, работающихпод управлениемоперационнойсистемыUNIX.
DB2/2. ЭтареализацияSQL для персональныхкомпьютеровкомпанииIBM основанана реализацииDB2 для мэйнфреймов.Она заменилаOS/2 Extended Edition,которая былапервой реляционнойСУБД компанииIBM для персональныхкомпьютеров,и обеспечилалучшую совместимостьсDB2.

SQL намини-компьютерах

Сегмент рынкареляционныхСУБД для мини-компьютеровначал развиватьсяодним из первых.Первые продуктыкомпанийOracle иIngres предназначалисьдля мини-компьютеровVAX/VMS компанииDigital. С тех пороба продуктабыли перенесенына множестводругих платформ.СУБД компанииSybase, появившаясяпозднее ипредназначеннаядля оперативнойобработкитранзакций,работала нанесколькихплатформах,включаяVAX.

Кроме того,поставщикимини-компьютеровразрабатывалина основе SQLсобственныереляционныебазы данных.КомпанияDigital на каждуюсистемуVAX/VMS устанавливаласобственнуюСУБДRdb/VMS. КомпанияHewlett-PackardпредложилаAllbase, СУБД,поддерживающуюкак собственныйдиалектHPSQL, так инереляционныйинтерфейс.КомпанияData General замениласвои старыенереляционныебазы данныхна СУБДDG/SQL. К томуже многие изпоставщиковмини-компьютеровперепродаютреляционныеСУБД независимыхпоставщиков.

SQL насиcтемахUNIX

SQL былоднозначнопризнан лучшимрешением вобласти управленияданнымидля компьютерныхсистем на основеUNIX. ОперационнаясистемаUNIX, котораябыла разработанав Bell Laboratories,в 80-х годах сталазавоевыватьпопулярностьв качествестандартнойоперационнойсистемы. Онаработает наразнообразныхкомпьютерныхсистемах, начинаяот рабочихстанций и заканчиваямэйнфреймами,и стала стандартнойОС для научныхи инженерныхприложений.В начале 80-х ужебыли доступнычетыре большиеСУБД дляUNIX-систем.Две из них,производствакомпанийOracle иIngres, былиUNIX-версиямипродуктов длямини-компьютеровкомпанииDEC, Две другиеСУБД, производствакомпанийInformix иUnify, былисозданы специальнодля UNIX.Вначале ни однаиз них не предлагалаподдержкуSQL, но к1985 году компанииUnify иInformix ввелиэту поддержкув свои СУБД. Насегодняшнийдень существуютверсии СУБДкомпанийOracle, Sybase, Informix иIngres для всехведущих системна базеUNIX.

SQL иобработкатранзакций

В процессесвоего развитияSQL и реляционныебазы данныхпочти не применялисьв приложениях,предназначенныхдля оперативнойобработкитранзакций(OLTP —On-Line Transaction Processing). Посколькув реляционныхбазах данныхупор делаетсяна запросы,такие базыданных традиционноиспользовалисьв приложениях,служащих дляподдержкипринятия решений,и приложенияхс маленькимобъемом транзакций,где их низкоебыстродействиене было недостатком.В области оперативнойобработкитранзакций,где требовалосьобеспечитьодновременныйдоступ к даннымсотням пользователей,и время ожиданиякаждого из нихне должно былопревышать долисекунды, доминироваланереляционнаяСУБДIMS (Information Management System— системауправленияинформацией)компании IBM.

В 1986году компанияSybase, новаяна рынке СУБД,представилареляционнуюбазу данных,предназначеннуюспециальнодля оперативнойобработкитранзакций.СУБД компанииSybase работалана мини-компьютерахVAX и рабочихстанцияхSun и обеспечивалауровень быстродействия,необходимыйдля обработкибольших объемовтранзакций.Вскоре вследза нею компанииOracle Corporation иRelational Technology объявили,что они такжевыпустят версиисвоих продуктовOracle иIngres для оперативнойобработкитранзакций.На рынкеUNIX-системкомпанияInformix анонсировалаOLTP-версиюсвоей СУБД подназваниемInformix-Turbo.

В апреле1988 года компанияIBM присоединиласьк поставщикамреляционныхСУБД дляOLTP, выпустивсистемуDB2 Version 2.Тесты показали,что на большихмэйнфреймахэта системамогла обрабатыватьдо 250транзакцийв секунду. КомпанияIBM утверждала,что теперьбыстродействиеDB2 позволяетиспользоватьее во всехOLTP-приложениях,кроме наиболеетребовательныхк быстродействию,и поощрялаклиентов использоватьее вместоIMS. Послеэтого тестыстали стандартныммаркетинговыминструментомдля реляционныхСУБД, вопрекисерьезнымсомнениям втом, насколькоони отражаютбыстродействиереальных приложений.

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

SQL наперсональныхкомпьютерах

С появлениемпервой моделиIBM PC базы данныхстали приобретатьпопулярностьна рынке персональныхкомпьютеров.СУБДdBASE компанииAshton-Tateбыла инсталлированаболее чем намиллионеPC, работавшихпод управлениемMS-DOS; другиепродукты, такиекак R-BASE,PFS: File и Paradox,также достиглизначительногоуспеха. НакомпьютерахсемействаMacintoshтакие СУБД, как4th Dimension, объединилив себе управлениеданными и графическийинтерфейспользователя.Хотя в большинствеСУБД для персональныхкомпьютеровданные хранилисьв табличнойформе, эти СУБДне обладалиполной мощьюреляционнойбазы данныхи не поддерживалиSQL.

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

Первые СУБДдля персональныхкомпьютеровпредставлялисобой соответствующимобразом переработанныеверсии известныхСУБД для миникомпьютерови с трудом умещалисьна персональныхкомпьютерах.Система ProfessionalOracle, анонсированнаяв 1984году, требоваладвух мегабайтовпамяти наIBM PC, a Oracle for Macintosh,представленнаяв 1988году, имеласхожие требования.Версия СУБДIngres дляPC, выпущеннаяв 1984году, едваудовлетворялаограничениюMS-DOS на объемиспользуемойоперативнойпамяти(640 Кб). СУБДInformix-SQL дляMS-DOS былавыпущена в 1986году и представляласобой версиюпопулярнойСУБД, работавшейпод управлениемUNIX. В том же1986 году компанияGupta Technologies, основаннаябывшим менеджеромиз Oracle,выпустилаSQLBase, СУБД длялокальныхсетей, котораяодной из первыхреализовалаархитектуруклиент/сервери была прототипомнынешних СУБДдля ЛВС.

С появлениемв апреле1987 годаоперационнойсистемыOS/2, созданнойкомпаниямиMicrosoft иIBM, началсярост популярностиSQL применительнок персональнымкомпьютерам.Кроме стандартнойверсииOS/2, компанияIBM выпустиларасширеннуюредакциюOS/2 (OS/2 Extended Edition— OS/2ЕЕ) со встроеннойподдержкойреляционныхбаз данных.СделавSQL частьюоперационнойсистемы, компанияIBM тем самымвновь подтвердиласвою приверженностьему.

ПоявлениеOS/2 ЕЕ сталопроблемой длякомпанииMicrosoft. Посколькуона была разработчикомстандартнойOS/2 и продавалаее другимпроизводителямперсональныхкомпьютеров,потребоваласьальтернативаOS/2 ЕЕ. ОтветомMicrosoft сталапокупка лицензиина СУБД компанииSybase, разработаннойдля VAX,и перенос этойСУБД в системуOS/2.

В январе1988 годаMicrosoft иAshton-Tate неожиданнообъявили, чтоони будут совместнопродавать новуюСУБД, получившуюназваниеSQL Server. КомпанияMicrosoft будетпродаватьSQL Server вместес OS/2 производителямкомпьютеров,а компанияAshton-Tate будетпродаватьSQL Server по розничнымканалам пользователямPC. В сентябре1989 года
компанияLotus Development внесласвой вклад вSQL Server, сделавинвестициюв компаниюSybase. Черезгод с небольшимкомпанияAshton-Tate отказаласьот исключительныхправ на распространениеи продала своюдолю компанииLotus. Хотя успехSQL Server дляOS/2 былограниченным,
онапродолжаетиграть ключевуюроль в планахкомпанииMicrosoft. Эта СУБДявляется реляционнойбазой данныхдля WindowsNT, флагманскойоперационнойсистемы компанииMicrosoft, предназначеннойдля работы всреде клиент/сервер.

SQL влокальных сетях

ПоявлениеOS/2 Extended Edition иSQL Server привлекловнимание кпотенциальнымвозможностямSQL в локальныхвычислительныхсетях. Заказчикистали всерьезрассматриватьархитектуруклиент/серверв качествеальтернативыцентральномумини-компьютеруили мэйнфрейму.

Вначале нарынкеSQL для ЛВСв качествеплатформы длясервера базданных доминировалаOS/2. В отличиеот MS-DOS,у этой операционнойсистемы не былоограниченияна объем ОЗУ(640 Кб), а еемногозадачнаяархитектурахорошо подходиладля созданиясервера базданных. К концу1989года компанииIBM, Microsoft, Oracle, Gupta идругие представилисвои СУБД дляOS/2. Однакообъемы продажOS/2 оказалисьменьше ожидаемых,в то время какобъемы продажMicrosoft Windows 3.0возросли. Вопрекивсем попыткамподчеркнутьих различия,междуOS/2 иWindows 3.0возникла конкуренция,которая постепеннопривела к разрывумеждуIBM иMicrosoft. В концеконцов компанияMicrosoft призналасвою приверженностьWindows 3.0и отказаласьот поддержкиOS/2, оставивза нею статус"собственностиIBM". ХотяOS/2 продолжаетзанимать важноеместо в планахкомпанииIBM, ее шансстать доминирующейпромышленнойоперационнойсистемой дляперсональныхкомпьютеров— а значит,и наиболееподходящейплатформойдля SQLв ЛВС —упущен.

В то времякак шла борьбамеждуOS/2 иWindows, сталирасти объемыпродаж реляционныхбаз данных длядругих сетевыхплатформ. Ценына компьютеры,работающиепод управлениемUNIX, постоянноснижались, аверсияUNIX от компанииSanta Cruz Operation (SCO UNIX) сталанаиболее популярнойплатформойдля персональныхкомпьютеровна базе процессоровIntel. В начале90-х годовSCO UNIX моглаподдерживатьнесколькопроцессоров,что позволилоделить загрузкукомпьютерамежду двумя,тремя или болеемикропроцессорами.Имея в своемраспоряжениивычислительнуюмощь четырех-восьмипроцессоров,работающихпараллельно,СУБДOracle, Informix иSybase смоглидостичь быстродействиямини-компьютеровна
серверахсемействаPC стоимостьюот $20000.На сегодняшнийдень многопроцессорныесерверы откомпанийCompaq, Dell, IBM и другихпоставщиковперсональныхкомпьютеровимеют наилучшеесоотношениецена/производительностьсреди всехдоступных нарынке компьютерныхсистем.

ХотяUNIX сталапопулярнойплатформойдля серверовбаз данных,подавляющеебольшинствосерверов ЛВСвсе еще применяютсятолько длясовместногоиспользованияфайлов и принтеров,и большинствоэтих серверовработают подуправлениемNovell Netware. СервернаяоперационнаясистемаNovell Netware реализуетменьшие возможности,чем UNIXили OS/2,но у нее естьодно большоепреимущество— объемпродаж. Первыереляционныебазы данныхдля Netwareкотировалисьхуже, чем СУБДдля UNIXи OS/2,однако начинаяс 1992года все ведущиепоставщикибаз данныхпредставиливерсии своихпродуктов дляNetware. ОбъемыПродаж этихпродуктов сталибыстро расти,и Netwareоказаласьжизнеспособнойплатформойдля серверовбаз данных.

В противоборствес UNIX, OS/2и NetwareкомпанияMicrosoft сделалаупор наWindows NT, клиент/сервернуюплатформу дляЛВС, УWindows NT естьряд значительныхпреимуществнад конкурентами;это новаяоперационнаясистема, неотягощенная"обратнойсовместимостью".Учитывая вескомпанииMicrosoft на компьютерномрынке, большинствоаналитиковполагает, чтоNT завоюетлидирующееположение вобласти сетейс архитектуройклиент/сервер.В результатевсе поставщикиСУБД в настоящеевремя выпускаютверсии своихпродуктов дляработы подуправлениемWindows NT.

Сегодня рынокСУБД для сетейс архитектуройклиент/серверявляется наиболеебыстро растущимсегментом рынкасерверов ЛВС.