Беспокойство и «ловушки» вентилятора не являются объектами конструкций. Это способы ненадлежащего использования базы данных путем слепого написания (неправильного) запроса на основе определенных свойств конструкций (а именно ограничений), а не правильно (а именно значений таблиц). Наличие таких свойств в вашем дизайне не означает, что что-то не так. Конечно, у вас все еще могут быть неверно выбранные базовые таблицы.
Каждая базовая таблица имеет соответствующий предикат aka fill-in-the- [named-] оператор пробелов, описывающий ситуацию приложения. Имена пробелов в предикате являются столбцами таблицы. Базовая таблица содержит строки, которые делают истинное утверждение. Каждое выражение запроса объединяет имена базовых таблиц через JOIN, UNION, SELECT, EXCEPT, WHERE и т. Д. И имеет соответствующий предикат, который объединяет предикаты базовой таблицы через (соответственно) AND, OR, EXISTS, AND NOT, AND и т. Д. Запрос результат содержит строки, которые делают истинное утверждение.
Таблица и ее предикат представляют собой отношение приложения. (Отношение Aka. Следовательно, реляционная модель и моделирование сущностей). В таблице содержатся строки, которые удовлетворяют предикату. Вы не можете обновлять или интерпретировать таблицу, не зная предиката. Многие методы и продукты проектирования не делают все это ясным.
Но стрелки/линии, которые называются «отношениями» в (плохие представления) ERM и ORM, обозначают не отношения приложений, а ограничения. Они известны ограничениям того, что состояние базы данных может быть связано с установкой базовых таблиц на предикаты. Они не имеют никакого отношения к написанию запросов. (Хотя ограничения на значения базовой таблицы, естественно, будут отражаться как ограничения в результатах запроса.) Таким образом, нечего «разрешать».
Циклы «Циклы» в этих стрелках/линиях просто отражают определенные ограничения нескольких таблиц, и нет ничего плохого в этом. Но стрелки/строки, соответствующие ограничениям внешнего ключа, также используются СУБД SQL для каскадов, поскольку для такого ограничения с несколькими таблицами часто требуется обновление с несколькими таблицами. Это каскады, которые должны быть ациклическими. Просто случается, что некоторые СУБД ограничивают выражение ограничений как побочный продукт ограничения каскадов. Поэтому вам, возможно, придется «разрешить» их для удовлетворения такой СУБД.
См. this answer и this one.
Это довольно широкий вопрос. В * general *, решение этих проблем в базе данных является предпочтительным, поскольку оно не только облегчает разработку юниверса, но также поддерживает запросы без BO. Но это не всегда возможно. То есть, может быть веская причина для дизайна datamart, и вам просто нужно обойти его во вселенной. Если вы можете быть более конкретным в своем вопросе, я могу предложить лучшее руководство. – Joe
Что именно вы имеете в виду, что вы «сталкиваетесь» с петлями и ловушками? Что есть определенные стрелки на картине вашего дизайна? Что SQL, который вы пишете, не возвращает нужные вам строки? Что значит «разрешать» их? – philipxy