1. Copyright © 1998-2011 Curt Hill Entities and Relationships The basics and what they have to do with database

2. Copyright © 1998-2011 Curt Hill Entities and Relationships Entity –Usually a real world thing College: faculty, course, students –Each entity has attributes People have names, ages Courses have names, hours, times Relationship –A logical connection between two or more entities –These may have attributes

3. Copyright © 1998-2011 Curt Hill Relationships In mathematics a relation is an represented by an ordered n-tuple Each record is an ordered n-tuple –Every table expresses relationship –Table is a file with just one record type Relationships may span tables

4. Copyright © 1998-2011 Curt Hill Relationship Arity or Cardinality How many are on either side of the relationship One to one –A person and SSN –Keys need this arity One to many –Instructor to student in a course Many to many –People to organizations –Hardest to represent

5. Copyright © 1998-2011 Curt Hill Table Use We use a table to collect a group of entities of the same type –The student table The attributes of the relationship form the fields of a record One to one relationships are just a field in the table One to many relationships and many to many relationships are often their own table

6. Copyright © 1998-2011 Curt Hill ER Model The Entity-Relationship model helps us to think about and design a database The only data in a database consists of entities, relationships and their attributes Helps us to bridge the gap between informal user desires to a formal database design

7. Copyright © 1998-2011 Curt Hill Entity-Relationship Diagrams A pictorial mechanism to show what is going on Not standardized –They come in many variations Entities – rectangles Attributes – ovals Relationships – diamonds Connections – lines

8. Copyright © 1998-2011 Curt Hill A simplified ER diagram Licenses Manufacturer Dealer Car Shipper Builds Stocks Contracts Transports

9. Copyright © 1998-2011 Curt Hill A manufacturing ER diagram Last one had no attributes for several reasons Often that is how we get started –Refine as we go along These tend to be both formal and informal The graphic had no space

10. Copyright © 1998-2011 Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID

11. Copyright © 1998-2011 Curt Hill Legend on the above Two perpendicular lines indicate an arity of one Terminating with three lines indicates an arity of many Underlined name indicates key –There may be more than one Relationships do not have to be between just two different types of entities –Binary, ternary, n-ary –One or more different tables

12. Variants The above diagram is often called Crow’s Foot diagram –The arity relationship is done using crow’s feet or perpendicular lines The alternative is called Chen notation –This must 1,n,m to identify Copyright © 1998-2011 Curt Hill

13. ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID 1 M

14. Copyright © 1998-2011 Curt Hill Key Constraints Another way to consider the arity issue is with key constraints Suppose a dealer is only allowed one license –We would denote that uniqueness property with an arrow from dealers to the license relationship –This gives us the next screen

15. Copyright © 1998-2011 Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID

16. Copyright © 1998-2011 Curt Hill Participation Constraints Total: every record in the table participates in this relationship –All manufacturers have dealers –Usually a heavy line Partial: there may be some records without this relationship –Suppose dealers includes used car dealers –Some have no license from a manufacturer –Denoted by a light line

17. Copyright © 1998-2011 Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID

18. Copyright © 1998-2011 Curt Hill Some Definitions Entity set –Any set of similar entities –Could be a whole table or subset of this table’s records Relationship set

19. Copyright © 1998-2011 Curt Hill Steps for DB Design Requirements Conceptual Logical Schema Refinement Physical Design Application Security

20. Copyright © 1998-2011 Curt Hill Requirements What to find –What data is needed –What applications will be needed How to go about it –Interview the staff –Study any prior systems

21. Copyright © 1998-2011 Curt Hill Conceptual When the requirements are understood, then take a shot at the high level design This is a high level approach A simple model is required since it must be understood by non- technical personnel

22. Copyright © 1998-2011 Curt Hill Logical Choose a DBMS Translate conceptual design into a schema supportable by the DBMS –Table definitions –Relationships –Primary and foreign keys

23. Copyright © 1998-2011 Curt Hill Schema Refinement It is never perfect the first time Put the tables in the desired normal form There are objective techniques to drive the process

24. Copyright © 1998-2011 Curt Hill Physical Design Performance is the key in this step What expected usage will be Where to use indexing or other performance enhancements or re- factor the tables

25. Copyright © 1998-2011 Curt Hill Applications The requirements of the applications that interface with the database cause the last refinement These applications may interface with the web as well

26. Copyright © 1998-2011 Curt Hill Security Tailoring the views with security in mind