Copyright © Curt Hill Entities and Relationships The basics and what they have to do with database
Copyright © 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
Copyright © 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
Copyright © 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
Copyright © 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
Copyright © 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
Copyright © 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
Copyright © Curt Hill A simplified ER diagram Licenses Manufacturer Dealer Car Shipper Builds Stocks Contracts Transports
Copyright © 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
Copyright © Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID
Copyright © 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
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 © Curt Hill
ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID 1 M
Copyright © 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
Copyright © Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID
Copyright © 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
Copyright © Curt Hill ER diagram Again Licenses Manufacturer Dealer Name Address Type StartDate Address Fee Name MID Lines DID LID
Copyright © 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
Copyright © Curt Hill Steps for DB Design Requirements Conceptual Logical Schema Refinement Physical Design Application Security
Copyright © 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
Copyright © 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
Copyright © Curt Hill Logical Choose a DBMS Translate conceptual design into a schema supportable by the DBMS –Table definitions –Relationships –Primary and foreign keys
Copyright © 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
Copyright © 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
Copyright © 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
Copyright © Curt Hill Security Tailoring the views with security in mind