The schema reader compares five fixed source revisions. It retains enrollments’ composite key, removes an undeclared F2 arrow, flags a missing target, preserves conflicting constraint labels and marks CHECK interpretation unsupported. A clean diagram cannot erase a declaration gap. Each revision shows its references below the three table boxes, with any unresolved declaration kept visible.
Make the enrollment key one visible group
PostgreSQL primary keys require unique, non-null identifying values and can span multiple columns. A grouped constraint applies to the combination rather than making each participating column independently unique. Foreign keys declare references to matching target values. PostgreSQL 18 constraints documentation
In this example, show a single enrollment key group labeled PK (member_id, club_id). Both rows can carry “part of PK” labels, but neither should be labeled “individually unique.”
Consider three illustrative enrollment pairs: (1, 10), (1, 11), and (2, 10). Member 1 appears twice, and club 10 appears twice. The pairs are different. Adding a second (1, 10) repeats the identifying pair. Use the pairs to explain why a repeated member or club differs from a repeated enrollment.
Preserve the declared tuple order. A diagram rearrangement should never silently rewrite it. Put the complete group below the enrollment fields so readers can understand it without interpreting a bracket or color.
Draw only relationships you can trace
The view has three table boxes and two directed references. Each arrow starts at its enrollment field and ends at the named parent field. The text references below the boxes name both endpoints and their status.
For this example, each enrollment has one referenced member and one referenced club when the declared constraints are satisfied. A member or club can have zero enrollments; the declarations do not require every parent to participate. These are implications of this model, not observed row counts. Avoid badges that suggest there are currently many members or that every club has at least one enrollment.
A matching field name is insufficient. If F2 is removed in a separate source revision, keep enrollments.club_id as a field but remove its declared-reference arrow. Display “No declared foreign key” rather than reconstructing an edge from the name.
The table boxes stay in a fixed layout and stack on narrow screens. Read the full endpoint text to follow a relationship; a box’s screen position does not change its declared keys.
Keep unresolved declarations in the output
Choose S3 to see F2 target clubs.missing_id. The table exists, but the named field does not. The page keeps the reference visible and reports the unresolved target without creating a field.
S4 assigns the label enrollment_ref to both F1 and F2 in the enrollment table. Keep both source records visible and flag the name conflict for review. Do not merge them or conclude that every repeated unnamed reference is necessarily invalid.
An unsupported declaration also needs a place to stay. For a revision that adds CHECK (member_id > 0) to enrollments, this limited example does not interpret CHECK expressions. Preserve the raw declaration and mark that interpretation incomplete; unsupported by this view does not mean invalid PostgreSQL. Read the unsupported CHECK note before treating the reference view as a complete account of the constraints.
For this limited model, resolve each endpoint against the declared field and eligible key records. If a required record is absent or an interpretation is unsupported, show an issue instead of a successful relationship. Choosing a revision recomputes the displayed references and issues. The source panel shows the selected declarations, so you can trace each status back to its endpoint.
Compare the source revisions
S1 declares members(member_id, display_name), clubs(club_id, title), and enrollments(member_id, club_id). IDs use integer types and names/titles use text. The enrollment primary key is exactly (member_id, club_id). F1 points to members.member_id and F2 to clubs.club_id. The page supplies these declarations directly; it does not connect to a database.
Choose S2 to keep club_id while removing F2’s declaration. S3 retains F2 but changes its target to clubs.missing_id; the missing field is not invented to complete the line. S4 gives both references the same constraint label and preserves both conflict records. S5 adds raw CHECK (member_id > 0) and explicitly leaves its interpretation incomplete.
Read each issue before reusing the view. Source revision changes rebuild the reference outcomes instead of carrying an old resolved label forward. Use your database tools to validate a real schema. This page compares five supplied revisions and neither parses arbitrary SQL nor executes DDL.
Copy this prompt
Build a SQL schema reading page with three table boxes and five source-revision buttons. Use supplied declarations rather than a SQL parser or database connection. Display source details in an expandable panel and explain reference outcomes beneath the table boxes.
Members has member_id integer and display_name text, with primary key member_id. Clubs has club_id integer and title text, with primary key club_id. Enrollments has member_id integer and club_id integer, with one composite primary key in that order. Show "PK (member_id, club_id)" as a group. Do not imply that either enrollment column is individually unique.
In S1, F1 references members.member_id from enrollments.member_id, and F2 references clubs.club_id from enrollments.club_id. Resolve endpoints against declared fields and eligible keys. Use directed text arrows with complete table and field names.
S2 removes F2 but keeps club_id, showing no declared foreign key for it. S3 changes F2's target to clubs.missing_id and preserves the unresolved reference. S4 names both references enrollment_ref and flags both conflicting labels without merging them. S5 adds raw CHECK (member_id > 0), which this limited reader preserves as unsupported interpretation rather than invalid PostgreSQL.
Each revision button rebuilds references, issues and source text. Include the example pairs (1, 10), (1, 11) and (2, 10). Explain that each pair is distinct, while another (1, 10) duplicates the composite key. A member or club may have no enrollments.
Return one self-contained HTML file with embedded styling and JavaScript. Stack table boxes and full endpoint text on narrow screens, with large readable key labels and click-driven revision controls.
Explain the pair, then the reference
Ask whether member 1 can occur in both (1, 10) and (1, 11), then select S2 and check whether club_id still has a declared reference. NOS can render the HTML schema reader for this design discussion. Continue with S3 and identify the exact missing target field before deciding what a real schema needs to change.