1. Relational Database Model & Database Development Process IST359 M005 Yang Wang ywang@syr.edu 342 Hinds http://blackboard.syr.edu

2. Acknowledgements and caveat These slides draw liberally, with permission, from the following sources: IST359 materials by Prof. Michael Fudge Jr. Caveat (beware): At best, PowerPoint slides are only a pale limitation of the entirety of a class meeting. In IST359 in particular, the lectures will cover topics beyond what appears in these slides. Don’t rely on them as a substitute for attending class.

3. Learning Objectives Describe the Relational Model Define relational terms and understand the terminology in practice Understand these relational terms through practice Explain the System Development Life Cycle Explain the Database Life Cycle

4. Learning Objectives Describe the Relational Model Define relational terms and understand the terminology in practice Understand these relational terms through practice Explain the System Development Life Cycle Explain the Database Life Cycle

5. The Relational Database Model  Many DBMS products implement the Relational Model, but none of them enforce it. This permits rookie database designers to shoot themselves in the foot. And many have (including yours truly).  The Relational Model has: (Codd’s 3 rules)  1)Data Independence  Clear separation between data and metadata  2) Data Consistency  Minimal redundancy; the data adopts the “DRY” principle  3) Easy to use - abstracted  You don’t have to understand the implementation to use it.

6. You too can make a crappy DB like this one! Do you see problems with this database design? Think Codd: Independence? Consistency? Ease-of-Use? Change Sally Jones’s phone #? Add New Employee Bob Smith?

7. Activity: Relational Terminology Identify each of these : Table Relation Row Column Tuple Attribute Atomic (Attrib.) Logical Domain Physical Domain

8. Tables are “Buckets for your data” Customers Orders Products “Customers Place Orders” “Products Appear on Orders” Tables: Specialized Order doesn’t matter Contain real items Relationships among tables: Enforce business rules Apply to real items

9. What makes a table a relation? A column or a set of columns uniquely identify each row

10. DBMS : Physical Domain SQL ServerMySQLWhat Is It? int Signed Integer values -2G  +2G int identityserial Auto-incrementing integer (surrogate keys) bit Used for true / false yes/no values. decimal(n,d) A fixed-point signed decimal of n digits with d decimal places. char(n) Exactly n characters, useful for fixed-length data. varchar(n) Variable length of no more than n characters. text Variable length of 2G characters; not index able datetime For storing dates and or times. Notes: Different “flavors” of DBMSs use different data types. It’s not part of the SQL Spec, but part of the DBMS implementation.

11. DBMS: Logical Domain / Constraints Default Value – a value entered into an attribute for a row when one isn’t specified. Check Constraint – an expression which must be evaluated prior to the insertion of a row. E.g., employee_hourly_wage >= 0 Unique Constraint – ensures duplicate values are not inserted into a column. Lookup table – a separate table containing all of the acceptable values for a given column.

12. Keys Candidate Key – any attribute or combination of attributes that can uniquely identify each row Primary Key - A candidate key which has been chosen by the database designer to uniquely identify each Surrogate Key - A primary key whose values are automatically generated by the DBMS Secondary Key - An attribute or combination of attributes used for row retrieval from a table. In practice, secondary keys are index candidates in the table design. Foreign Key – an attribute or combination of attributes in one table whose values either match those of the primary key in another table or are null. Used to link relations.

13. Activity: The Relational Table Relation Name? Attributes? Logical Domain of Columns? Physical Domain of Columns? Candidate keys? NameTeamTotal YdsTDs Emmitt SmithCowboys17162153 Walter PaytonBears16726110 Barry SandersLions1526999 Emmitt SmithCardinals9379

14. The Primary Key Constraint Special selected constraint (you choose it) Enforces entity integrity on the table. Must be data unique for each row Should be a candidate key

15. Good PK … Bad PK Good candidate key choices? Customer Name? Email Address? Name and DOB? SSN? Customer Selected value? Random Unique #? Sequential Unique #? Last two are examples of surrogate keys The best PK’s – Don’t change … ever! – Have no external meaning – Do not compromise security… – Do not hinder performance …

16. Activity: Which of these is a good PK? Candidate keys? Best primary key? Why? Should a Surrogate key be used?

17. The Foreign Key constraint The foreign key is a constraint on a column of one relation so that it can be associated with another relation. Foreign keys must have referential integrity – their values must come from the corresponding Primary Key column in the relation.

18. Example of FK: The Lookup Table CategoryID Book Hardware Software Foreign Key

19. Activity: Find the keys Candidate? Primary? Foreign? Secondary? Surrogate?

20. One more time. Rule for joining tables Tables Columns: Physical Domain? Logical Domain? Allow Null? Keys: Candidate? Primary? Foreign, Surrogate, Secondary?

21. The Equi-Join of PK-FK at Work Equi Join

22. Activity: Where’s the Integrity? Which of the 4 tables exhibit Entity Integrity? Which of the 3 relationships exhibit Referential Integrity?

23. FK Example: Implementation of a 1-M Relationship

24. FK Example: Implementation of a M-N Relationship This M-M Relationship has been resolved into two 1-M relationships

25. Example:Null and Flags Null makes sense for this column 103 and 105 are null for different reasons! Flags used to represent different status Nulls typically cause problems in Varchar and Numeric, and bit fields

26. Data Models: Abstraction Levels Conceptual Internal External Physical Logical Highly Abstract Hardware and Software Independent Somewhat Abstract Hardware Independent Software Dependent Not Abstract (Concrete) Hardware and Software Dependent

27. An Concrete Example SU administration asks us to build a database for class enrollment o E.g., student info, class info, a student enrolls in a class Logical model: what database model to use? Relational, object- oriented, object-relational, etc. o E.g., we use relational model (entities, relations). Internal model: use a DBMS to implement our relational model o E.g., what do the student, class tables look like? External model: what the internal model looks like to end users (hide details of the implementation, e.g., tables) o E.g., you can see a student enrolls in a class Physical model: how database is implemented by the DBMS o E.g., how is the database physically stored? In a single file? Conceptual model: represent requirements, what needs to be represent in the database?

28. Systems Development Lifecycle I Planning II Analysis III Design IV Implementation V Maintenance & Support Time Resources Conceptual Model Logical Model Internal / External Model SDLC / DBLC Physical Model

29. Alternatives Fast prototyping Agile development eXtreme programming Hackathon

30. Exercise Design a database for on-campus parking info – Car – Parking lots – A parking permit allows a car to park in a certain parking lot Tables and keys

31. Permit_IDSUIDCar LicenseLot numPrice Permits (table) SUIDLast nameFirst nameGenderSchool Persons (table) Car LicenseBrandModelColor Cars (table)