Читать в оригинале

ОглавлениеСледующая >>


Глава 1. Описание практического примера

Перед непосредственным рассмотрением языка SQL и системы управления базами данных Oracle 10g необходимо определиться с теми исходными данными, которые будем применять в примерах учебного пособия.

В качестве примера рассматривается база данных небольшой художе­ственной галереи [1]. Перечень требований к приложению для галереи:

1. Вести учет покупателей и их художественных интересов.

2. Отслеживать приобретения, которые делает галерея.

3. Отслеживать покупки клиентов.

4. Вести список художников и произведений, когда-либо появлявшихся в галерее.

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

6. Отображать на веб-странице список произведений, выставленных на продажу.

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

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

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

Рис. 1.1. Модель данных  для практического примера

 

Модель данных такого примера приведена на рис. 1.1. В ней есть две сильных сущностей CUSTOMER (клиент) и ARTIST (художник). Кроме того, имеется сущность WORK (произведение), идентификационно- зависимая от сущности ARTIST, и сущность TRANSACTION (транзакция), идентификационно-зависимая от сущности WORK. Между сущностями CUSTOMER и WORK имеется неидеитифицирующая связь принадлежности.

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

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

Клиент может приобрести множество работ; этот факт обозначен свя­зью вида 1 между сущностями CUSTOMER и TRANSACTION. Кроме того, между сущностями CUSTOMER и ARTIST существует связь вида N:M.

Удаление строк в таблицах CUSTOMER и ARTIST вызывает каскад­ное удаление в таблице CUSTOMER_ARTIST_INT. Это имеет смысл, по­скольку когда сведения о клиенте или художнике удаляются из базы дан­ных, нет нужды сохранять информацию о предпочтениях данного клиента или интересе к данному художнику. Если с клиентом связана хотя бы одна транзакция, этот клиент не может быть удален из базы данных. Аналогич­но, если с художником связана хотя бы одна картина, удалить его будет нельзя. Кроме того, записи о работах, по которым имели место какие-либо транзакции, удалению также не подлежат.

Данные для рассматриваемого примера приведены в табл. 1.1 -1.5.

Таблица 1.1. Данные для таблицы ARTIST

ArtistID

Name

Nationality BirthDate

DeceasedDate

3

Miro

Spanish 1870

1950

 

4

Kandinskv

Russian 1854

1900

 

5

Frings

US 1700

1800

 

6

Klee

German 1900

MIL

 

8

Moos

US MIL

<NULL>

 

14

Tobev

US MIL

<NULL>

 

15

Matisse

French MIL

<NULL>

 

16

Chagall

French MIL

<NULL>

 

Таблица 1.2. Данные для таблицы WORK

WorkID

Title

Description

Copy

ArtistID

505

Mystic Fabric

One of the only pr

99/135

14

506

Mi Vida

Very black, but ve

7/100

3

507

Slow Embers

From the artist's

HC

14

525

Mystic Fabric

Some water damage

105/135

14

530

Northwest by Night Wonderful, moody

37/50

16

Таблица 1.3. Данные для таблицы TRANSACTION

TransactionID DateAcquired

AcquisitionPrice PurchaseDate

SalesPrice

AskingPrice

CustomerlD WorkID

100 2/27/1974

8750

3/18/1974

18500

20000

1015

505

101 7/17/1989

28900

10/14/1989

46700

47000

1001

505

121 11/17/1989

4500

11/21/2000

9750

10000

1040

525

122 2/27/1999

8000

3/15/2000

17500

17500

1036

506

124 4/7/2001

38700

8/17/2000

73500

75000

1036

506

129 11/21/2001

6750

3/18/2002

14500

15000

1040

507

130 11/21/2001

21500

Mil.

MIL

Mil.

Mil.

525

135 7/17/2002

47000

10/2/2002

71500

72500

1015

530

 

Таблица 1.4. Данные для таблицы CUSTOMER

Таблица 1.5. Данные для таблицы CUSTOMER_ARTIST_INT

ArtistID

CustomerlD

ArtistID

CustomerlD

3

1036

14

1015

5

1015

14

1033

5

1034

14

1034

5

1041

14

1036

5

1051

14

1040

8

1034

14

1041

8

1041

14

1051

14

1001

16

1015

 



ОглавлениеСледующая >>