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

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

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

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

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

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

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

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

<div v:shape="_x0000_s1190">

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

<img src="/cache/referats/3349/image001.gif" v:shapes="_x0000_s1026">
<img src="/cache/referats/3349/image002.gif" v:shapes="_x0000_s1052"><img src="/cache/referats/3349/image003.gif" v:shapes="_x0000_s1055"><img src="/cache/referats/3349/image004.gif" v:shapes="_x0000_s1054"><img src="/cache/referats/3349/image003.gif" v:shapes="_x0000_s1053"><img src="/cache/referats/3349/image005.gif" v:shapes="_x0000_s1047"><img src="/cache/referats/3349/image006.gif" v:shapes="_x0000_s1057"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1058"><img src="/cache/referats/3349/image008.gif" v:shapes="_x0000_s1059"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1060"><img src="/cache/referats/3349/image009.gif" v:shapes="_x0000_s1056"><img src="/cache/referats/3349/image010.gif" v:shapes="_x0000_s1039">

Файл учета рабочего времени

<img src="/cache/referats/3349/image011.gif" v:shapes="_x0000_s1034"><div v:shape="_x0000_s1030">

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

         ОСД

         ОСД

<img src="/cache/referats/3349/image012.gif" v:shapes="_x0000_s1036"><img src="/cache/referats/3349/image006.gif" v:shapes="_x0000_s1048"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1050"><img src="/cache/referats/3349/image006.gif" v:shapes="_x0000_s1049"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1051"><img src="/cache/referats/3349/image009.gif" v:shapes="_x0000_s1046"><img src="/cache/referats/3349/image013.gif" v:shapes="_x0000_s1037"><div v:shape="_x0000_s1031">

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

         ОСД

<img src="/cache/referats/3349/image006.gif" v:shapes="_x0000_s1043"><img src="/cache/referats/3349/image006.gif" v:shapes="_x0000_s1041"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1042"><img src="/cache/referats/3349/image007.gif" v:shapes="_x0000_s1044"><img src="/cache/referats/3349/image009.gif" v:shapes="_x0000_s1040"><div v:shape="_x0000_s1028">

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

         ОСД

<img src="/cache/referats/3349/image014.gif" v:shapes="_x0000_s1038">

Главный файл с данными о служащих

<img src="/cache/referats/3349/image015.gif" v:shapes="_x0000_s1035"><div v:shape="_x0000_s1027">

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

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

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

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

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

<img src="/cache/referats/3349/image016.gif" v:shapes="_x0000_s1118"><div v:shape="_x0000_s1117">

Записи

<img src="/cache/referats/3349/image017.gif" v:shapes="_x0000_s1121"><img src="/cache/referats/3349/image018.gif" v:shapes="_x0000_s1119">

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

<img src="/cache/referats/3349/image019.gif" " " v:shapes="_x0000_s1062">

Ручка

<img src="/cache/referats/3349/image020.gif" v:shapes="_x0000_s1077">

Окно

<img src="/cache/referats/3349/image021.gif" v:shapes="_x0000_s1076">

Замок

<img src="/cache/referats/3349/image022.gif" v:shapes="_x0000_s1075"><img src="/cache/referats/3349/image023.gif" v:shapes="_x0000_s1116"><img src="/cache/referats/3349/image024.gif" v:shapes="_x0000_s1115"><img src="/cache/referats/3349/image025.gif" v:shapes="_x0000_s1114"> <img src="/cache/referats/3349/image026.gif" v:shapes="_x0000_s1061">
<img src="/cache/referats/3349/image027.gif" v:shapes="_x0000_s1113"><img src="/cache/referats/3349/image028.gif" v:shapes="_x0000_s1112"><img src="/cache/referats/3349/image023.gif" v:shapes="_x0000_s1111"><img src="/cache/referats/3349/image029.gif" v:shapes="_x0000_s1110"><img src="/cache/referats/3349/image030.gif" v:shapes="_x0000_s1109"><img src="/cache/referats/3349/image031.gif" v:shapes="_x0000_s1108"><img src="/cache/referats/3349/image032.gif" v:shapes="_x0000_s1107"><img src="/cache/referats/3349/image033.gif" v:shapes="_x0000_s1102"><img src="/cache/referats/3349/image034.gif" v:shapes="_x0000_s1101"><img src="/cache/referats/3349/image035.gif" v:shapes="_x0000_s1100"><img src="/cache/referats/3349/image023.gif" v:shapes="_x0000_s1099"><img src="/cache/referats/3349/image036.gif" v:shapes="_x0000_s1098"><img src="/cache/referats/3349/image037.gif" v:shapes="_x0000_s1097"><img src="/cache/referats/3349/image038.gif" v:shapes="_x0000_s1096"><img src="/cache/referats/3349/image028.gif" v:shapes="_x0000_s1095">

Левая дверь

<img src="/cache/referats/3349/image039.gif" v:shapes="_x0000_s1074">

Правая дверь

<img src="/cache/referats/3349/image040.gif" v:shapes="_x0000_s1073">

Днище

<img src="/cache/referats/3349/image041.gif" v:shapes="_x0000_s1072">

Крыша

<img src="/cache/referats/3349/image042.gif" v:shapes="_x0000_s1071"><img src="/cache/referats/3349/image023.gif" v:shapes="_x0000_s1090"><img src="/cache/referats/3349/image024.gif" v:shapes="_x0000_s1089"><img src="/cache/referats/3349/image025.gif" v:shapes="_x0000_s1088"><img src="/cache/referats/3349/image027.gif" v:shapes="_x0000_s1087"><img src="/cache/referats/3349/image028.gif" v:shapes="_x0000_s1086"><img src="/cache/referats/3349/image043.gif" v:shapes="_x0000_s1094"><img src="/cache/referats/3349/image044.gif" v:shapes="_x0000_s1093"><img src="/cache/referats/3349/image045.gif" v:shapes="_x0000_s1092"><img src="/cache/referats/3349/image046.gif" v:shapes="_x0000_s1091"><img src="/cache/referats/3349/image047.gif" v:shapes="_x0000_s1085"><img src="/cache/referats/3349/image048.gif" v:shapes="_x0000_s1084"><img src="/cache/referats/3349/image049.gif" v:shapes="_x0000_s1083"><img src="/cache/referats/3349/image050.gif" v:shapes="_x0000_s1082"><img src="/cache/referats/3349/image028.gif" v:shapes="_x0000_s1081">

Корпус

<img src="/cache/referats/3349/image051.gif" v:shapes="_x0000_s1069">

Ходовая часть

<img src="/cache/referats/3349/image052.gif" v:shapes="_x0000_s1070">

Двигатель

<img src="/cache/referats/3349/image053.gif" v:shapes="_x0000_s1068"><img src="/cache/referats/3349/image054.gif" v:shapes="_x0000_s1080"><img src="/cache/referats/3349/image055.gif" v:shapes="_x0000_s1079"><img src="/cache/referats/3349/image056.gif" v:shapes="_x0000_s1078">

Автомобиль

<img src="/cache/referats/3349/image057.gif" v:shapes="_x0000_s1063">Список составных частейизделия по своей природе является иерархической структурой. Для храненияданных, имеющих такую структуру, была разработана иерархическая модель данных, которую иллюстрирует рис. 1.2.

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

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

·<span Times New Roman"">     

найти конкретную деталь (правую дверь) по её номеру;

·<span Times New Roman"">     

перейти «вниз» к первому потомку (ручка двери);

·<span Times New Roman"">     

перейти «вверх» к предку (корпус);

·<span Times New Roman"">     

перейти «в сторону» к другому потомку (правая дверь).

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

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

·<span Times New Roman"">     

Простота модели. Принцип построенияIMSбыллегок для понимания. Иерархия базы данных напоминала структуру компании илигенеалогическое дерево.

·<span Times New Roman"">     

Использование отношенийпредок/потомок.СУБД IMS позволяла легко представлять отношения предок/потомок, например:«А является частью В» или «А владеет В».

·<span Times New Roman"">     

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

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

<img src="/cache/referats/3349/image058.gif" v:shapes="_x0000_s1139"><div v:shape="_x0000_s1138">

Товары

<div v:shape="_x0000_s1137">

Служащие

<div v:shape="_x0000_s1136">

Клиенты

<img src="/cache/referats/3349/image059.gif" v:shapes="_x0000_s1133"><img src="/cache/referats/3349/image060.gif" v:shapes="_x0000_s1132">Сетевыебазы данных

<img src="/cache/referats/3349/image061.gif" v:shapes="_x0000_s1122">
<img src="/cache/referats/3349/image059.gif" v:shapes="_x0000_s1123"><img src="/cache/referats/3349/image062.gif" v:shapes="_x0000_s1124">

Acme

Mfg.

<img src="/cache/referats/3349/image063.gif" v:shapes="_x0000_s1125"><img src="/cache/referats/3349/image064.gif" v:shapes="_x0000_s1126"><img src="/cache/referats/3349/image065.gif" v:shapes="_x0000_s1127">

Bill

Adams

<img src="/cache/referats/3349/image066.gif" v:shapes="_x0000_s1128"><img src="/cache/referats/3349/image067.gif" v:shapes="_x0000_s1129"><img src="/cache/referats/3349/image068.gif" v:shapes="_x0000_s1130">

Size 4

Widget

<img src="/cache/referats/3349/image069.gif" v:shapes="_x0000_s1131"><img src="/cache/referats/3349/image070.gif" v:shapes="_x0000_s1141"><img src="/cache/referats/3349/image071.gif" v:shapes="_x0000_s1140"><div v:shape="_x0000_s1135">

Заказы

#112963

<img src="/cache/referats/3349/image072.gif" v:shapes="_x0000_s1134">

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

<img src="/cache/referats/3349/image073.gif" " v:shapes="_x0000_s1144">
Если структура данныхоказывалась сложнее, чем обычная иерархия, простота структуры иерархическойбазы данных становилась её недостатком. Например, в базе данных для хранения заказоводин заказ мог участвовать в трёх различныхотношениях предок/потомок, связывающих заказ с клиентом, разместившим его, сослужащим, принявшим его, и с заказанным товаром, что иллюстрирует рис. 1.3.Такие структуры данных не соответствовали строгой иерархии IMS.

В связи с этим для такихприложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархической <img src="/cache/referats/3349/image074.gif" v:shapes="_x0000_s1176">моделью, в которой одназапись могла участвовать в нескольких отношениях предок/потомок, как показанона рис. 1.4. В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных былопубликован официальный стандарт сетевых баз данных, который известен какмодель CODASYL.Компания IBMне стала разрабатывать собственнуюсетевую СУБД и вместо этого продолжала наращивать возможность IMS. Нов 70-х годах независимые производители программного обеспечения реализовалисетевую модель в таких продуктах, как IDMSкомпании Cullinet, Total <img src="/cache/referats/3349/image075.gif" v:shapes="_x0000_s1183"><img src="/cache/referats/3349/image076.gif" v:shapes="_x0000_s1182"><img src="/cache/referats/3349/image077.gif" v:shapes="_x0000_s1179"><div v:shape="_x0000_s1178">

Множество

<img src="/cache/referats/3349/image078.gif" v:shapes="_x0000_s1177"><div v:shape="_x0000_s1175">

Записи

<div v:shape="_x0000_s1174">

Заказы

<img src="/cache/referats/3349/image079.gif" v:shapes="_x0000_s1156"><img src="/cache/referats/3349/image080.gif" v:shapes="_x0000_s1167"><img src="/cache/referats/3349/image081.gif" v:shapes="_x0000_s1159"><img src="/cache/referats/3349/image082.gif" v:shapes="_x0000_s1163"><img src="/cache/referats/3349/image083.gif" v:shapes="_x0000_s1157"><img src="/cache/referats/3349/image084.gif" v:shapes="_x0000_s1164"><img src="/cache/referats/3349/image085.gif" v:shapes="_x0000_s1160"><img src="/cache/referats/3349/image081.gif" v:shapes="_x0000_s1165"><img src="/cache/referats/3349/image086.gif" v:shapes="_x0000_s1161"><img src="/cache/referats/3349/image087.gif" v:shapes="_x0000_s1168">

#112961

<img src="/cache/referats/3349/image088.gif" v:shapes="_x0000_s1152">

#112962

<img src="/cache/referats/3349/image089.gif" v:shapes="_x0000_s1154">

#112963

<img src="/cache/referats/3349/image090.gif" v:shapes="_x0000_s1155">

#112964

<img src="/cache/referats/3349/image091.gif" v:shapes="_x0000_s1153">

#112965

<img src="/cache/referats/3349/image092.gif" v:shapes="_x0000_s1151">

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

<img src="/cache/referats/3349/image093.gif" v:shapes="_x0000_s1146 _x0000_s1170">
<div v:shape="_x0000_s1173">

Товары

<div v:shape="_x0000_s1172">

Клиенты

<img src="/cache/referats/3349/image094.gif" v:shapes="_x0000_s1169"><img src="/cache/referats/3349/image095.gif" v:shapes="_x0000_s1166"><img src="/cache/referats/3349/image096.gif" v:shapes="_x0000_s1158"><img src="/cache/referats/3349/image097.gif" v:shapes="_x0000_s1162">

Size 4

Widget

<img src="/cache/referats/3349/image098.gif" v:shapes="_x0000_s1149">

4D

Bolt

<img src="/cache/referats/3349/image099.gif" v:shapes="_x0000_s1150">

First

Corp.

<img src="/cache/referats/3349/image100.gif" v:shapes="_x0000_s1148">

Acme

Mfg.

<img src="/cache/referats/3349/image101.gif" v:shapes="_x0000_s1147">компании Cincom иСУБД Adabas, которые приобрели большую популярность.

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

·<span Times New Roman"">     

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

·<span Times New Roman"">     

Стандартизация.  Появление стандарта CODASYLпопулярность сетевоймодели, а такие поставщики мини-компьютеров, как DigitalEquipment Corporation и Data General, реализовали сетевые СУБД.

·<span Times New Roman"">     

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

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

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

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

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

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

Таблица CUSTOMERS

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">COMPANY

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">CUST_REP

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">CREDIT_LIMIT

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">JSP Inc.

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">103

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">$50,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">First Corp.

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">101

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">$65,000.00

<img src="/cache/referats/3349/image104.gif" v:shapes="_x0000_s1185 _x0000_s1186 _x0000_s1187"> <div v:shape="_x0000_s1189">

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

<img src="/cache/referats/3349/image105.gif" v:shapes="_x0000_s1184">

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

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

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

Таблицы

<div v:shape="_x0000_s1192">

Таблица OFFICES

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">OFFICE

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">CITY

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">REGION

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">MGR

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">TARGET

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">SALES

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">22

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Denver

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Western

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">108

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$300,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$186,042.00

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">11

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">New York

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Easten

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">106

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$575,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$692,000.00

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">12

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Chicago

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Easten

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">104

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$800,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$739,000.00

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">13

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Atlanta

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Easten

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">105

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$350,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$735,157.00

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">21

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Los Angeles

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">Western

<span Arial",«sans-serif»; mso-bidi-font-family:«Times New Roman»;color:black;mso-fareast-language: RU;layout-grid-mode:line">108

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$725,000.00

<span Arial",«sans-serif»;mso-bidi-font-family:«Times New Roman»; color:black;mso-fareast-language:RU;layout-grid-mode:line">$835,915.00

<img src="/cache/referats/3349/image106.gif" v:shapes="_x0000_s1191">
<div v:shape="_x0000_s1204">

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

<div v:shape="_x0000_s1193">

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

<div v:shape="_x0000_s1195">

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

<div v:shape="_x0000_s1197">

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

<img src="/cache/referats/3349/image107.gif" v:shapes="_x0000_s1198"><img src="/cache/referats/3349/image108.gif" v:shapes="_x0000_s1196"><img src="/cache/referats/3349/image109.gif" v:shapes="_x0000_s1194"><img src="/cache/referats/3349/image110.gif" v:shapes="_x0000_s1203"><div v:shape="_x0000_s1202">

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

<img src="/cache/referats/3349/image037.gif" v:shapes="_x0000_s1201"><img src="/cache/referats/3349/image111.gif" v:shapes="_x0000_s1200"><div v:shape="_x0000_s1199">

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

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

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

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

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

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

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

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

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

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

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

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

еще рефераты
Еще работы по программированию, базе данных