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




Название"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных"
страница2/5
Дата публикации23.09.2013
Размер0.68 Mb.
ТипРеферат
litcey.ru > Информатика > Реферат
1   2   3   4   5

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

Acme

Mfg.

Bill

Adams

Size 4

Widget

Заказы

#112963

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

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

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

Записи

Заказы

#112961

#112962

#112963

#112964

#112965

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

Товары

Клиенты

Size 4

Widget

4D

Bolt

First

Corp.

Acme

Mfg.

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

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

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

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

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

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

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

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

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

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

Таблица CUSTOMERS







COMPANY

CUST_REP

CREDIT_LIMIT

JSP Inc.

103

$50,000.00

First Corp.

101

$65,000.00





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

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

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

Таблицы

Таблица OFFICES
















OFFICE

CITY

REGION

MGR

TARGET

SALES

22

Denver

Western

108

$300,000.00

$186,042.00

11

New York

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

Los Angeles

Western

108

$725,000.00

$835,915.00


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица PRODUCTS













MFR_ID

PRODUCT_ID

DESCRIPTION

PRICE

QTY_ON_HAND

REI

2A45C

Ratchet Link

$79.00

210

ACI

4100Y

Widget Remover

$2,750.00

25

QSA

KX47

Reducer

$355.00

38

BIC

41672

Plate

$180.00

0


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

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

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

Похожие:

\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconКурс, 1 поток, 5-й семестр лекции (34 часа), экзамен
В курсе обсуждаются общие вопросы систем управления базами данных (субд) и основы реляционных баз данных: введение в реляционные...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconУпрощение разработки, администрирования и настройки производительности баз данных
Е и разработку баз данных. Разработанный для профессионалов баз данных, которые работают в смешанной среде субд, набор инструментов...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconЛабораторная работа №1. Microsoft Word. Задание №1 Документ "Приглашение"
Задание №1 Базы данных. Реляционные базы данных. Интерфейс Microsoft Access. Создание Базы данных. 53
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconПрограммирование баз данных в Microsoft sql server 2000
Цель: Курс предоставляет слушателям технические навыки, требующиеся для программирования и оптимизации баз данных с использованием...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconDb powerstudio™ for sql server
Разработанный для профессионалов баз данных на платформе sql server набор инструментов db powerStudio дополняет ssms важнейшими возможностями,...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconЗадание 2а. Реляционные базы данных
Требуется разработать схему реляционной базы данных для хранения информации о типах облаков (см задание 1), создать приложение для...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconDb powerstudio™ for oracle
Бд повысить производительность баз данных различных версий субд oracle. Разработанный для профессионалов баз данных на платформе...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconМоделирование корпоративных данных
Благодаря двунаправленной поддержке баз данных архитекторы данных могут без труда выполнять реконструирование, анализ и оптимизацию...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconМетодические указания к курсовому проектированию по дисциплине «Информационное...
Целью курсового проекта является изучение методов и закрепление знаний в проектировании локальных реляционных баз данных в среде...
\"Реляционные Базы Данных. Sql стандартный язык реляционных баз данных\" iconИнформационные сети и системы
История развития бд и субд. Понятие базы данных. Иерархические, сетевые, реляционные субд. Объектно–ориен­ти­ро­ван­ные и объектно–реляционные...
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
litcey.ru
Главная страница