From database schema to ERD: drawing entity-relationship diagrams

A common flaw in software engineering dissertations is an Entity-Relationship Diagram (ERD) that drifts away from the actual database schema in the repository. Examiners look for exact alignment between Chapter 4 diagram entities and repository migration files or ORM models.

1. The Disconnection Problem

When students manually draw ERDs using general-purpose vector tools, discrepancies inevitably occur:

• Table names pluralized in diagrams (users, orders) but singular in code (User, Order).
• Foreign key attributes omitted or misnamed (e.g., user_id vs studentId).
• Cardinality mismatches: declaring 1:1 in the text while the schema supports 1:N relations.

UniReport solves this by parsing schema definitions directly from codebases—such as Prisma, SQLAlchemy, or raw SQL DDL—and generating deterministic Mermaid ERDs.

2. Crow’s Foot Notation Standards

Academic FYP guidelines almost universally require Crow’s Foot notation. The primary cardinality markers are:

• ||--|| : Exactly one to exactly one.
• ||--o{ : One to zero-or-more.
• ||--|{ : One to one-or-more.
• o|--o{ : Zero-or-one to zero-or-more.

erDiagram
    STUDENT ||--o{ SUBMISSION : submits
    STUDENT {
        uuid id PK
        string matric_no UK
        string full_name
        timestamp created_at
    }
    SUBMISSION ||--|{ EVALUATION : receives
    SUBMISSION {
        uuid id PK
        uuid student_id FK
        string report_title
        string status
    }
    EVALUATION {
        uuid id PK
        uuid submission_id FK
        float rubric_score
        text remarks
    }

3. Pairing ERDs with Data Dictionaries

An ERD diagram is never sufficient on its own. University dissertation guidelines require an accompanying Data Dictionary table for every entity in the diagram.

Each data dictionary table must detail:

1. Attribute Name: Exact identifier from source code.
2. Data Type: SQL or primitive type with length constraints (e.g., VARCHAR(64)).
3. Key / Index: PK, FK, or UK status.
4. Nullability: NOT NULL or nullable.
5. Description: Business logic meaning.

Grounding both the Mermaid ERD and the data dictionary in your active code guarantees zero discrepancies during thesis inspection.