Доброе время суток.

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

Пусть есть упрощенная модель данных, в которой рассматриваем только:
- произведения
- книги
- язык

Произведения хранят информацию о названии.
Книги это то что непосредственно лежит на полке. Они могут быть разного издания и на разных языках.
Язык - справочник языков.
Читатель может запросить одну и туже книжку на разных языках.


Пример данных:

У нас есть "война и мир"
- русское издание 2 книги
- английское 1 книга
- испанское 1 книга

1. Нам необходимо знать что это одно и тоже произведение.
2. Книга должна содержать ключ по которому мы можем выбрать издание на нужном языке.
3. Названия не должны дублироваться в разных таблицах.

1 Вариант реализации связей:
Произведение -> Название на нужном языке(+связь со справочником языков) -> Книга

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


2 Вариант.

Язык -> Произведение -> Книга

Дублирования нет, но теряем сущность которая могла бы ответить на вопрос "Выдайте мне все варианты книги "Война и Мир"".

3. ?

значок "->" - показывает связь от родительской к дочерней. один ко многим.

Кореец,

может быть "Произведения" замкнуть на себя с помощью id+id_parent?

но тогда запрос на полный список будет строиться некрасиво в 2 шага

1. найти книгу по названию
2. выбрать все ее родительские и дочерние записи

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

вопрос интересует чисто с точки зрения теории нормализации.

как схема должна обеспечить отсутствие аномалий обновления и нужную выборку классическим SQL?

SERG1257>Такая схема не защищает от аномалии.
О какой аномалии идет речь. Это РАЗНЫЕ сущности. Которые однако часто совпадают.
"Пособие по укладке парашюта. Издание второе исправленное"
Короче, я за вариант первый. KISS

Тут исходит из понимания автора. Если автор изменил даже название книги, то возможно что он ее переписал так, что это стала другая книга. Тогда да. Как и например "Справочник Oracle 8 ", "Справочник Oracle 9 ", "Справочник Oracle 10 " - это будут все разные книги.
И в то же время если издание второе включает себя только исправления ошибок и опечаток, то это уже та же книжка и "издание " это ее атрибут .

В любом случае представьте пример:

1. Приходит читатель и спрашивает книгу "War and Peace". Учитывая что библиотекарь не может помнить все названия переводов на все языки, то он так ее и введет. И вот тут запрос к таблице "Произведения" становится бессмысленен. А значит мы не имеем права вообще к ней строить запрос, а должны сразу искать по второй табличке.
2. Тот же читатель говорит, а дайте эту же книжку на испанском, как она на испанском называется не помнит, как раз его изучает и вот тут эта же таблица Произведение сослужит службу - ибо по ключу произведений мы можем из таблиц переводов выдать все варианты книг.

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

guest_20040621Это некорректная постановка задачи. Об идентичности есть смысл говорить для произведения и версии его издания. Для подобия - да, достаточно только произведения.

> 3. Названия не должны дублироваться в разных таблицах.

Очевидное решение: вынесите названия в отдельную таблицу. Постройте семантические связи.

Ни один из предложенных вами вариантов не является решением задачи, но думаете вы в правильном направлении. Попутно вам придется решать более сложную задачу: языковые эквиваленты имен авторов и переводчиков.

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

По поводу идентичности - это зависит от того, что просит найти читатель:

1. Один изучает саму историю произведения и запрашивает конкретное издание книги и это + AND издание = ? к запросу по книгам. Издание пусть будет атрибутом книги.
2. Другой изучает языки, учится литературному переводу и издание ему не важно какое. Ему просто нужно получить Войну и Мир на английском и испанском.

А вот произведения входящие в сборник - это да. Тут сложнее.
Сам по себе сборник это отдельное произведение, допустим сборник сказок разных народов мира для детей. Но в одной книге и Оловянный солдатик и сказка о попе и работнике балде.

И вот ту чет сложно все получается. Хуже всего если книгу придется наследовать всегда от Сборника. Тогда возможностей для аномалий еще больше будет.

Mainframe_старый Книги могут быть в отношениях - перевод, новое издание, расширенное издание и т.п.
а потом отчеты настраивать на эти отношения с учетом приоритетов, которые определяют приоритетность отношений. Т.е. разные отчеты могут учитывать разные отношения. В каких-то выводить объекты в отношениях "Перевод", а в других - нет.


Переводят то не книгу, переводят произведение. А книга это просто как носитель информации с переплетом. Есть от издательства Амфора, а есть от издательства Художник.

Но ваша мысль ясна. Спасибо.