пожалуйста, рассмотрите следующий сценарий. У владельца домашнего животного может быть несколько кошек, а также может быть несколько собак. Некоторые собаки связаны (т.е. дерутся :-) ) с некоторыми кошками одного владельца.
Следующий реляционный дизайн не накладывает это ограничение, поскольку кошки и собаки разных владельцев могут быть связаны. Есть ли способ наложить это ограничение с помощью реляционного дизайна?
Вам нужно будет использовать идентифицирующие отношения для переноса ПК владельца вниз с обеих сторон и в нижнюю часть ромбовидной зависимости:
Поскольку CatDog.OwnerId — это всего лишь одно поле, оно не может идентифицировать нескольких владельцев в строке, а поскольку это FK для обоих видов животных, этот один владелец должен соответствовать владельцу как кошки, так и собаки.
Другими словами, кошка может иметь отношение только к собаке того же хозяина.
Как видите, кошки и собаки идентифицируются не так, как вы, вероятно, ожидали. Кошка идентифицируется своим владельцем и отличается от других кошек того же владельца своим CatNo. То же самое для собак.
Если вам нужен «более простой» ключ, вы всегда можете просто добавить суррогатный ключ или, в качестве альтернативы, вы можете полностью исключить CatNo и DogNo, «злоупотребляя» ограничением UNIQUE исключительно для переноса OwnerId:
(U1 обозначает ограничения UNIQUE.)
Теперь вы можете идентифицировать животных более точно, но есть и обратная сторона: ограничение UNIQUE совершенно избыточно с точки зрения обеспечения уникальности. Это супер-набор PK, и PK сам по себе обеспечивает уникальность. Единственная цель ограничения UNIQUE — разрешить CatDog.OwnerId ссылаться на Cat.OwnerId (и Dog.OwnerId) — большинству СУБД требуется, чтобы родительская конечная точка внешнего ключа была ключом.
Некоторые СУБД (Oracle) позволит вам использовать только один индекс для обеспечения ограничения как PK, так и UNIQUE, но большинство из них этого не сделает. Каждый дополнительный индекс ухудшает производительность вставки/обновления/удаления.
