База данных нуждается в связи

Question

В Microsoft Retail Management System, если мы исследуем базу данных, она не использует одно из следующих отношений:

Один к одному

Один ко многим

Многие ко многим

один эксперт сказал мне, что иногда отношения вредны так же, как и вредны в нашей повседневной жизни.Поэтому избегайте отношений как в жизни, так и в базе данных.Я все еще считал это шуткой.

, поэтому, пожалуйста, скажите мне, что действительно нужно использовать отношения, даже если мы можем управлять запросом и т. Д.

Answer 1

реляционная база данных s и сущность-отношение s имеют очень мало общего друг с другом.

Реляционная база данных состоит из одного или несколькихсовокупность фактов, организованных в отношения.В этой модели отношение - это не более чем совокупность фактов, претендующих на то же «вид».Чтобы убедиться, что набор фактов, представленных в базе данных, действителен, обычно существуют некоторые дополнительные ограничения, применяемые к способу представления фактов.Во-первых, факты должны быть идентифицируемыми, должен быть «ключ» для каждого факта и только один такой факт для любого возможного ключа.Другое состоит в том, что когда один факт заявляет о другом факте, это, безусловно, означает, что заявленный факт о (референте) существует и согласуется с «мета-фактом».

В качестве примера приведенного вышеВы, безусловно, никогда не захотите оказаться в положении, когда вы знаете, что «клиент 10 отстает от своих платежей на 15 дней», но вы не знаете, какой клиент 10 отстает, потому что их больше, чем один, иличто нет клиента 10 вообще.Эти ограничения служат для того, чтобы заставить базу данных быть «согласованной».С другой стороны,

---

сущностные отношения имеют смысл только с точки зрения дизайна приложения.Это «язык», чтобы описать, как абстрактные компоненты программы связаны друг с другом.Реляционные базы данных обеспечивают посредством функциональной зависимости способ моделирования этого типа «есть-а», «имеет-много», «принадлежит-к», но он ни в коем случае не единственный.Другой пример - наследование и композиция, используемые в объектно-ориентированном дизайне.

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

Тем не менее, такие приложения, вероятно, будут небольшими и необычными;Эти инструменты обеспечивают значительную ценность для разработки «хорошего» приложения, и практически все будут использовать некоторые из них, а возможно и широко,

.

Answer 2

Отношения (модель ER) хороши тем, что они описывают вашу модель - просто сказано, что вам легче увидеть, какие сущности связаны друг с другом, когда на диаграмме они связаны друг с другом.

Что касается отношения, которое должно иметь внешний ключ (модель хранения), то ответ будет следующим:

Это зависит от характера отношений. В компании, в которой я работаю, мы следуем правилу: Создавайте FK только между сущностями, определенными пользователем (для значимых для него отношений, таких как Customer - Order), избегайте FK для сущностей, которые автоматически добавляются системой (например, записи журнала / аудита, особенно если их много).

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