Relational Database Model Tables By Bob Larson

Relational Database Model Introduced by E. F. Codd in 1970 A Logical View of Data Enables developer to view data logically rather than physically Greater logical simplicity tends to yield simpler and more effective database design methodologies

Tables Cornerstone of Relational DBMS Advantages – structural and data independence Conceptually Resembles a file Note a file is actually a physical structure Easier to understand than its hierarchical and network database predecessors

Table Characteristics

Keys – Key Attributes (Fields) Consists of one or more attributes that determine appropriateness of other attributes Primary Key (PK) – Attribute or a combination of attributes that uniquely identifies each entity (row) Key’s role is based on determination If you know the value of attribute A, you can look up (determine) the value of attribute B

Keys Types

Keys – Primary & Foreign

Null Values No data entry – Not the same as zero (0) Can represent An unknown attribute value A known, but missing, attribute value A “not applicable” condition Not permitted in primary key Should be avoided in other fields (when possible) Create problems with math functions such as COUNT, AVERAGE, and SUM Can create logical problems when relational tables are linked

Field (Column) Redundancy (?) Controlled redundancy: Makes the relational database work Database tables share common attributes only to enable the tables to be linked Multiple occurrences of a field in a database is not redundant when required to make the relationship work Redundancy exists only when there is unnecessary duplication of attribute values (? - click)

Entity Integrity Rules

Integrity Rules

Database Normalization Process of efficiently organizing data in a database Two goals: Eliminate redundant data (storing same data in multiple tables) Reduce the amount of space a database consumes Ensure data dependencies make sense (only storing related data in a table) Ensure that data is logically stored Database community developed a guidelines Normal forms Numbered from one (lowest or 1NF) through five (5NF) Typical applications use 1NF, 2NF, and 3NF (occasional 4NF) Fifth normal form is very rarely seen and won't be Important to point out that they are guidelines only Occasionally, it becomes necessary to meet business requirements

Normal Forms (1-4) First normal form (1NF) Second normal form (2NF) Eliminate duplicative columns from the same table Create separate tables for each group of related data Identify each row with a unique column or set of columns (the primary key) Second normal form (2NF) Meet all the requirements of the first normal form Remove subsets of data that apply to multiple rows of a table and place them in separate tables Create relationships between these new tables and their predecessors through foreign keys Third normal form (3NF) Meet all the requirements of the second normal form Remove columns that are not dependent upon the primary key Fourth normal form (4NF) Meet all the requirements of the third normal form Remove columns with multi-valued dependencies Guidelines are cumulative For a database to be in 2NF, it must meet the criteria of a 1NF database

Table Normalized

Indexes (Index Fields) Used to logically access rows in a table Index key Index’s reference point Points to data location identified by the key Unique index Index in which the index key can have only one pointer value (row) associated with it Each index is associated with only one table

Table Types Data (Entities / Nouns) Transaction (Events / Verbs) Subset Validation

Data Tables Sometimes called inventory tables Generally your object (entity) tables Important persons, places, or things Not the processing of those things Clearly relationships between the tables But no common (link) fields

Transaction Tables Sometimes called linking, event or junction tables Used to link data tables which can’t be linked directly Event tables linked at a point in time when something happened

Subset Tables Includes fields directly related to another data table Cruise Example Security Example Includes fields directly related to another data table Can’t be included in the original data table For security reasons They would represent multiple entries in a single field Often we discovered as we start entering test data

Validation Tables Helps maintain data integrity for a field Used for field lookups and combo boxes on forms Limits user choices to a drop-down list Not data tables because they are secondary in importance We didn’t build the database to track states or department codes

Problem Fields (Don’ts) Calculated field – can be computed by mathematical calculation or text concatenation Waste of storage space (redundant), No assurance the calculated value is updated when the user changes the input field(s) Multipart field – contains that should be two or more fields Extra work when you want to analyze your data Multivalue field – multiple correct entries for the field Create a separate subset table with each value in its own record. Derived field – contents of one or more fields absolutely predicts the contents of another Should be dropped from the table

Table Name Guidelines Keep it short, simple and descriptive without using acronyms, abbreviations or codes Do not include object names like File, Records, Table and List Use the plural form of the name Do not use names that refer to or imply more than one subject Materials and Supplies – should be two fields Do not use names that unnecessarily restrict the scope of your data Names that imply a time frame, regional location or organizational status – Manufacturing Employees

Field Name Guidelines Keep it unique Should be unique in entire DBMS except to link Keep it short, simple and descriptive Use the singular form of the name Do not use names that refer to or imply more than one attribute or subject Avoid codes and acronyms Use abbreviations only if their meaning is absolutely clear

The Data Dictionary/Catalog Provides detailed accounting of all tables found within the user/designer-created database Contains (at least) all the attribute names and characteristics for each table in the system Contains metadata—data about data Sometimes described as “the database designer’s database” because it records the design decisions about tables and their structures Terms “system catalog” and “data dictionary” are often used interchangeably

A Sample Data Dictionary

Fin…