Классика баз данных - статьи
Это тот же случай, что
Пример: Это тот же случай, что и 1.4, но A и B поменяны местами; см. случай 1.4.
4.2 Для каждого a имеется много элементов b, для каждого b имеется ровно один a.
Пример: Это тот же случай, что и 2.4, но A и B поменяны местами; см. случай 2.4.
4.3 Для каждого a имеется много элементов b, для каждого b имеется не менее одного a.
Пример: Это тот же случай, что и 3.4, но A и B поменяны местами; см. случай 3.4.
4.4 Для каждого a имеется много элементов b, для каждого b имеется много элементов a.
Пример: В хорошо известной базе данных поставщиков и деталей каждый поставщик размещается в том же городе, что и ноль или большее число деталей, и каждая деталь располагается в том же городе, что и ноль или большее число поставщиков.
Так что в действительности разных случаев не 16, а всего лишь 10. Заметим, кстати, что несколько примеров соответствует бизнес-политике или бизнес-правилам (см., например, случаи 1.4 и 2.3). Другие примеры носят всего лишь случайный характер (см., например, случай 4.4), но, тем не менее, могут быть интересны – какой-либо пользователь мог бы захотеть, как принято выражаться, «воспользоваться связью» для определения, например, того, какие детали располагаются в том же городе, что и данный поставщик.
Я начал это раздел с вопроса: сколько различных видов связей может разумно существовать с участием двух множеств A и B? Конечно, здесь подчеркивается слово разумно. Очевидно, что можно было бы далее классифицировать случаи «много» (не больше двух, ровно два, не меньше двух, не больше трех и т.д.). Как говорится в , «например, в собрании должно участвовать не менее двух человек, а конкурсе танго должно принимать участие четное число танцоров». Однако эта дальнейшая классификация кажется не слишком полезной (она добавляет массу сложностей, и очень быстро начинает действовать закон уменьшающегося плодородия), и далее в этой статье я не буду рассматривать такие возможности.
