This exercise asked you to answer a series of questions relating to the following sample table:
The questions are reiterated below, along with their answers.
Question: What does Reports represent? Answer: Reports represents the subject of the table.
Question: What do the columns Editor and DeptName represent? Answer: These represent fields in the table.
Question: What does the highlighted row represent? Answer: The highlighted row represents a record in the table.
Question: What does the column ReportID represent? Answer: The column ReportID represents the primary key.
Toward Object Name Normalization
The basic approach to naming is to choose meaningful, memorable, and descriptive readable names, avoiding abbreviations and codes, and using underscores either consistently or not at all. In a large application, table, column, and data names will often be multiword, as in the case of ReversedSuspenseAccount or Last_GL_Close_Date. The goal of thoughtful naming methods is ease of use: The names must be easily remembered and must follow rules that are easily explained and applied.
In the pages ahead, a somewhat more rigorous approach to naming is presented, with the ultimate goal of developing a formal process of object name normalization.
In a relational database system, the hierarchy of objects ranges from the database, to the table owners, to the tables, to the columns, to the data values. In very large systems, there may even be multiple databases, and these may be distributed within locations. For the sake of brevity, the higher levels will be ignored, but what is said will apply to them as well. Each level in this hierarchy is defined within the level above it, and each level should be given names appropriate to its own level and should not incorporate names from outside its own level.