Relational Database Structure Exercise Result

Compare your response to the reference answers below. Focus on matching the *meaning* of each concept (table subject, columns, row, and key).

1. What does Reports represent?
   Answer: Reports is the table name. It represents the subject (the thing the table stores data about).
2. What do the columns Editor and DeptName represent?
   Answer: They are columns (also called fields or attributes). Each column describes one property of the subject.
3. What does the highlighted row represent?
   Answer: A row is a record (also called a tuple). It represents one specific instance of the subject (one report entry).
4. What does the column ReportID represent?
   Answer: ReportID is the primary key. It uniquely identifies each row so the DBMS can reference, join, and update rows reliably.

Good naming improves query readability and reduces mistakes. As a rule, choose names that are meaningful, easy to remember, and consistent across the schema. Avoid unclear abbreviations, and use a consistent convention for multiword names (either underscores or consistent casing).

In larger systems, a consistent naming approach becomes a practical discipline: tables, columns, and constraints should be named so that another developer can infer intent without needing to open application code.

Relational systems have levels of objects (database → schema/owner → tables → columns → data values). A useful guideline is to name objects at each level for what they *are* at that level, without mixing concerns from other levels.

For example, table names should describe the subject being stored, column names should describe attributes of that subject, and key/constraint names should reflect the rule being enforced.