Change the Tool, Change the Model When you join a DW project, you usually start by reviewing the existing model. There’s one thing that, if left unchecked, will cause problems later: which tool was used to draw the model, and what notation does that tool use. Open an ERwin model in DA# and the relationship lines get interpreted differently. A dashed line that means “non-identifying relationship” in one tool means “optional participation” in the other. Both are correct — the notation is just different. The problem is that if you don’t know this during a model review, people end up having different conversations while looking at the same ERD. An ERD is a shared language read by modelers, developers, and business stakeholders alike. If you don’t realize that language has multiple dialects, communication breaks down. Same Crow’s Foot, Different Interpretations The most widely used ERD notation family is Crow’s Foot. It combines symbols at the ends of relationship lines — dash (1), circle (0), and crow’s foot (N) — to express cardinality. That much is common. The problem is that there are two schools within the Crow’s Foot family. The IE (Information Engineering) approach is the default in ERwin, PowerDesigner, and similar tools. Identifying relationships use solid lines; non-identifying relationships use dashed lines. An identifying relationship means the parent entity’s PK is included as part of the child entity’s PK. The Barker approach is used in Oracle-family tools and DA#. It looks like the same Crow’s Foot, but the symbols carry different meanings. Symbol IE Approach Barker Approach Dashed line Non-identifying relationship Optional participation (0 or 1) Solid line Identifying relationship Mandatory participation (exactly 1) Dash Exactly 1 Identifying relationship The meaning of a dashed line is completely different. In IE, a dashed line conveys structural information: “the parent PK is not part of the child PK.” In Barker, a dashed line conveys a business rule: “participation is optional.” The same symbol carries information from different layers of abstraction. When you review a model designed in DA# using ERwin, someone unfamiliar with this difference will read every dashed line as a non-identifying relationship. The design intent gets distorted. Notations That Don’t Use Crow’s Foot IDEF1X is a notation that uses circles instead of Crow’s Foot to indicate cardinality. No circle means exactly 1, an empty circle means 0 or 1, and a filled circle means 0 or N. Identifying vs. non-identifying is distinguished the same way as IE — solid vs. dashed lines. There are variations. One approach uses filled circles for everything and adds letters like Z (0 or 1) and P (1 or N). Switching ERwin to IDEF1X mode enables this notation. The Crow’s Foot family and IDEF1X have fundamentally different symbol systems for expressing cardinality. While confusion within the Crow’s Foot family (IE vs. Barker) is about reading the same symbol differently, the difference with IDEF1X is about not being able to read the symbols at all if you don’t know them. These are different types of confusion. The Reality on Projects The point isn’t to memorize every notation. It’s to be aware of the issues that actually arise on projects. When switching modeling tools, notation conversion happens automatically — but it’s not perfect. Subtle expressions may change, and structures like super-sub types (covered later) can be altered entirely. Even within the same IE notation, minor differences exist between tools — like representing two dashes as one. At the start of a project, align on three things: Decide which notation you’ll use Make sure everyone on the team understands the symbols in that notation Check the tool’s help documentation for notation details at least once On projects where this isn’t done, model reviews devolve into notation debates. Time that should be spent discussing design gets consumed by “what does this line mean?” Code-Based ERD In cloud DW environments, many teams don’t draw ERDs in GUI tools at all. They define models in SQL via dbt and express relationships using text-based diagrams like Mermaid or DBML. The advantage is being able to track model change history like code reviews. Even when the tool changes, what needs to be expressed stays the same: cardinality, identifying vs. non-identifying relationships, mandatory vs. optional participation. Without understanding these concepts, you can’t properly read a model — whether it’s built in a GUI tool or text-based notation. The next post covers super-sub types. It’s the structure where you split “Customer” into “Individual Customer” and “Corporate Customer.” When moving from logical to physical models, the options diverge — and in a DW, those choices directly shape dimension design.