Changes between Version 6 and Version 7 of RelationalModel

Timestamp:

04/24/26 02:25:59 (9 days ago)

Author:

231082

Comment:

update wrong details, add more accurate details

RelationalModel

@@ -17 +17 @@
 === Oracle SQL Developer Data Modeler (Barker's notation)
 
-The following two diagrams were produced in Oracle SQL Developer Data Modeler using Barker's notation as a supplementary model. The Visual Paradigm diagrams above are the mandatory deliverable. The Data Modeler diagrams are provided because they overcome several limitations of Visual Paradigm documented in the section below, and allow the model to be expressed with proper per-side participation, bilateral relationship naming, correct data types, non-transferability, and direct recursive relationship lines without intermediate entities.
+The following two diagrams were produced in Oracle SQL Developer Data Modeler using Barker's notation as a supplementary model. The Visual Paradigm diagrams above are the mandatory deliverable. The Data Modeler diagrams are provided because they overcome several limitations of Visual Paradigm documented in the section below, and allow the model to be expressed with proper per-side participation, bilateral relationship naming, correct data types, non-transferability, and direct recursive relationship lines without intermediate entities in most cases.
 
 ==== Logical Diagram
@@ -41 +41 @@
 The Visual Paradigm diagram is the mandatory deliverable for this phase and was presented to the supervising professor during the required consultation. The professor's remarks were subsequently implemented in both the Visual Paradigm and the Oracle SQL Developer Data Modeler diagrams.
 
-The two diagrams are conceptually equivalent and nearly visually identical. The only structural differences between them stem from tool behaviour: `Survey_Response`, `Course_Equivalence`, `Course_Prerequisite`, and `Announcement_Replies` are represented as entity boxes in Visual Paradigm but as relationship lines in Data Modeler. `Teaches` was previously also in this category, but has been promoted to a deliberate entity in Data Modeler following the decision to connect `Announcement` to `Teaches` rather than separately to `Course_Edition` and `Member`.
+The two diagrams are conceptually equivalent and nearly visually identical. The only structural differences between them stem from tool behaviour: `Survey_Response` and `Course_Equivalence` are represented as entity boxes in Visual Paradigm but as relationship lines in Data Modeler. `Course_Prerequisite` appears as an intermediate entity box in Visual Paradigm due to the recursive relationship limitation; in Data Modeler it is a pure relationship line. `Announcement_Replies` appears as an intermediate entity box in Visual Paradigm for the same reason; in the Data Modeler logical diagram the threading is expressed as a nullable `parent_announcement_id` attribute on `Announcement` itself, while in the relational diagram it materialises as a separate `REPLIES_TO` table. `Teaches` was previously also in this category as a VP tooling artefact, but has been promoted to a deliberate entity in both diagrams following the decision to connect `Announcement` to `Teaches` rather than separately to `Course_Edition` and `Member`.
 
 === Member / Student / Teacher (ISA specialisation)
@@ -81 +81 @@
 === Announcement threading (recursive 1:N on Announcement)
 
-Announcements support threaded replies: an announcement may be a reply to at most one parent announcement, and a parent may have zero or more replies. This is a one-to-many recursive relationship on `Announcement`, expressed as a nullable self-referencing foreign key. Because Visual Paradigm does not support connecting an entity directly to itself, the tool introduced an intermediate entity; the underlying structure is a simple nullable FK on the same table.
+Announcements support threaded replies: an announcement may be a reply to at most one parent announcement, and a parent may have zero or more replies. This is a one-to-many recursive relationship on `Announcement`, expressed as a nullable self-referencing foreign key. Because Visual Paradigm does not support connecting an entity directly to itself, the tool introduced an intermediate entity (`Announcement_Replies`). In the Data Modeler logical diagram this is expressed as a nullable `parent_announcement_id` attribute directly on `Announcement`, correctly reflecting the underlying structure. In the Data Modeler relational diagram it materialises as a separate `REPLIES_TO` table, which is the standard physical representation of a 1:N recursive relationship in a relational schema generator.
 
 === Member_Message (recursive M:N on Member)
@@ -93 +93 @@
 - Line style (dashed vs. solid) denotes non-identifying vs. identifying relationships, not partial vs. total participation, because Visual Paradigm does not support mixed participation on a single line.
 
-- Recursive relationships required intermediate entities introduced automatically by the tool. This affects the prerequisite and equivalence relationships on `Course`, the threaded reply relationship on `Announcement`, and the direct messaging relationship on `Member`. In the Data Modeler diagram all four are drawn as direct recursive relationship lines.
+- Recursive relationships required intermediate entities introduced automatically by the tool. This affects the prerequisite and equivalence relationships on `Course`, the threaded reply relationship on `Announcement`, and the direct messaging relationship on `Member`. In the Data Modeler logical diagram, the prerequisite and equivalence relationships on `Course` and the direct messaging relationship on `Member` are drawn as direct recursive relationship lines. The announcement threading is instead expressed as a nullable `parent_announcement_id` attribute directly on `Announcement` in the logical diagram, and materialises as a separate `REPLIES_TO` table in the relational diagram — consistent with standard relational normalisation of a 1:N recursive relationship.
 
 - Data types in the diagram use `varchar(255)` and `integer(10)` as approximations of the intended PostgreSQL `TEXT` and `INT` types, which Visual Paradigm does not natively support.