IST 220 – Intro to DB Lecture 4 Database Design thru ER Modeling

 We have used several DBs with a Relational design:  Tables each dedicated to a single set of business entities, such as books, publishers, orders, etc.  Columns in a table define attributes of the entities  Rows store an occurrence of the entity set  The tables are (usually) related through PK-FK  Now it is time for us to discuss how to come up with a sound relational design DB Design

 A data model that encompasses the entire truth of data needs of the business is to be worked out first  A practical approach is ER modeling, where  E or entity is something exists in the business domain and can be described by relevant attributes  R or relationship defines how entities are associated with one another  ERM depicts a business-oriented view of information Basic Concepts

 Attributes share some common properties  Each allows for a specific type and valid range of values  Each may or may not allow for a NULL value  But some attributes are keys that identify entities or define relationships between them  Candidate key:  Primary key:  Foreign key: Types of Attributes

 Cardinality  One-to-one  One-to-many or many-to-one  Many-to-many  Notations Types of Relationships ISBN Title … Book AuthorID FName LName Author * *

 General rules for transforming ERM into tables  Each entity set becomes a table, with  Each attribute being a column  A primary key assigned to each table  Candidate key and not null constrains possible  A foreign key added to tables on the many side of a one-to- many relationship by copying PK from table on the one side  An additional (junction) table is needed for each many- to-many relationship, with  FKs copied from both related tables  A PK formed by both FKs From ERM to Relational Design

 Normalization: to reduce duplication and to optimize design by placing attributes to the right tables  Normal forms: 1 st thru 3 rd NFs are required for each table for practical purposes  1NF: a row is in 1NF if and only if all underlying column domains contain atomic values only  Eliminates repeating groups and non-atomic data (i.e. multi-part values like name, address) from an entity Rules for Good Design All possible forms 1NF

 2NF: a row is in 2NF if and only if it’s in 1NF and every non-key attribute is fully dependent on the key  Ensures that all the attributes of each entity are dependent on the PK  3NF: a row is in 3NF if and only if it’s in 2NF and every non-key attribute is non-transitively dependent on the primary key  Ensures that no relationships between attributes within an entity Rules for Good Design (cont’d) All possible forms 1NF 2NF 3NF