3.9. База данных поставщиков и деталей

Наш пример, используемый на протяжении почти всей книги, известен как база данных поставщиков и деталей. Цель настоящего раздела — познакомить с этой базой дан­ных, которая будет служить примером для ссылок в последующих главах. На рис. 3.8 показано множество значений данных примера. Эти конкретные значения будут факти­чески использоваться и в последующих примерах (где это имеет смысл). На рис. 3.9 по­казано определение базы данных, синтаксис этого описания объясняется в главе 4. Об­ратите внимание, в частности, на спецификации первичного и внешнего ключей.

S

SP

S#

SNAME

STATUS

CITY

S#

Р#

QТУ

S1

Smith

20

London

81

Р1

300

S2

Jones

10

Рагis

81

Р2

200

S3

В1асk

30

Рагis

81

РЗ

400

S4

С1агk

20

London

81

Р4

200

S5

Adams

30

Аthens

81

Р5

100

P

81

Р6

100

Р#

PNAME

COLOR

WEIGHTT

CITY

82

Р1

300

Р1

Nut

Red

12

London

82

Р2

400

Р2

Во1t

Green

17

Рагis

83

Р2

200

РЗ

Screw

Вlue

17

Rome

84

Р2

200

Р4

Screw

Red

14

London

84

Р4

300

Р5

Cam

Вlue

12

Рагis

84

Р5

400

Р6

Cog

Red

19

London

Рис. 3.8. База данных поставщиков и деталей (значения для примера)

СREATE DOMAIN S# СНАR(5) ; СRЕАТЕ DOMAIN NАМЕ СНАR(20) ; СRЕАТЕ DOMAIN STATUS NUMERIC(5) ; СRЕАТЕ DOMAIN СIТУ СНАR(15) ; СRЕАТЕ DOMAIN Р# СНАR(6) ; СRЕАТЕ DOMAIN СОLOR СНАR(6) ; СRЕАТЕ DOMAIN WEIGHT NUMERIC(5) ; СRЕАТЕ DOMAIN QTY NUMERIC(9) ; СRЕАТЕ ВАSЕ RELATION S ( S# DOMAIN ( S# ), SNАМЕ DOMAIN ( NAME ) , STATUS DOMAIN ( STATUS ), СIТУ DOMAIN ( СIТУ ) ) РRIМАRУ КЕУ ( S# ) ; СRЕАТЕ ВАSЕ RЕLАТION Р ( Р# DOMAIN ( Р# ), РМАМЕ DOMAIN ( NАМЕ ), СОLОR DOMAIN ( СОLOR ) , WEIGHT DOMAIN ( WEIGHT ), СIТУ DOMAIN ( СIТУ ) ) РRIМАRУ КЕУ ( Р# ) ; СRЕАТЕ ВАSЕ RELATION SР ( S# DOMAIN ( S# ), Р# DOMAIN ( Р# ), QТУ DOMAIN ( ОТУ ) ) РRIМАRУ КЕУ ( S#, Р# ) FOREIGN КЕУ ( S# ) REFERENCES S FOREIGN КЕУ ( Р# ) REFERENCES Р ;

Рис. 3.9. База данных поставщиков и деталей (определение данных)

В базе данных предполагается следующая семантика.

• Таблица S представляет поставщиков. Каждый поставщик имеет уникальный но­мер (S#); имя (SNAME), не обязательно уникальное (хотя оно может быть, как в случае на рис. 3.8, уникальным); значение рейтинга или статуса (STATUS); место расположения (CITY). Предполагается, что каждый поставщик расположен точно в одном городе (т.е. у нас всегда будет одно значение CITY — город).

• Таблица Р представляет детали (точнее, виды деталей). У каждого вида детали есть номер детали (Р#), который является уникальным; название детали (PNAME); цвет (COLOR); вес (WEIGHT); место расположения, где хранится этот вид дета­лей (CITY). Предполагается (где это имеет значение), что вес детали приведен в фунтах. Также предполагается, что каждый отдельный вид детали только одного цвета и хранится на складе точно в одном городе.

• Таблица SP представляет поставки. Она в известном смысле служит для соедине­ния двух других таблиц. Например, первая строка таблицы SP на рис. 3.8 соединя­ет поставщика S1 таблицы S с соответствующей деталью Р1 таблицы Р, т.е. пред­ставляет факт поставки деталей Р1 поставщиком S1 (а также указывает количество деталей — 300 штук). Таким образом, каждая поставка характеризуется номером поставщика (S#), номером детали (Р#) и количеством (QTY). Предполагается, что в одно и то же время может быть не более одной поставки для одного поставщика и одной детали; поэтому для данной поставки комбинация значений S# и Р# уни­кальна с точки зрения набора текущих поставок, находящихся в таблице SP.

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

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

И последнее замечание: наша база данных поставщиков и деталей очень простая, гораздо проще любой реальной базы данных, которая может встретиться на практике; в большинстве реальных баз данных используется значительно больше объектов и отношений, чем в нашей. Но несмотря на это, наш пример вполне подходит для объ­яснения большинства вопросов, которые будут обсуждаться в следующих частях кни­ги, и (как уже упоминалось) будет использоваться как основа для большинства (не для всех) примеров последующих нескольких глав. И еще один комментарий: конеч­но, нет ничего плохого в том, чтобы использовать описательные названия таблиц, та­кие какSUPPLIERS(поставщики),PARTS(в качестве таблицы деталей) иSHIPMENTS(поставки), вместо сокращенных названий S, Р и SP; более того, на практике рекомендуется использовать именно такие описательные названия. Однако в нашем конкретном случае в последующих главах так часто будут употребляться на­звания этих таблиц, что целесообразнее использовать именно короткие названия. Многократно употребляемые длинные названия начинают раздражать.