|
Читать в оригинале |
| Оглавление | Следующая >> |
Глава 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Таблица 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 |
| Оглавление | Следующая >> |