Instructor: Amol Deshpande [email protected]
} New topics to discuss ◦ More constructs in E/R modeling ◦ Conver@ng from E/R to rela@onal schema ◦ Crea@ng some E/R models ◦ Ruby on Rails
} Other things ◦ Grading of SQL: today or tomorrow ◦ Assignment/Project 2 released yesterday � Make sure the basic setup is working – many more configura7on issues compared to PostgreSQL
◦ Will start collec7ng in-‐class worksheets
} Some@mes a rela@onship associates an en@ty set to itself
} Need “roles” to dis@nguish
coursecourse_idtitlecredits
course_id
prereq_id prereq
} An en@ty set without enough aQributes to have a primary key
} E.g. Sec@on En@ty } S@ll need to be able to dis@nguish between weak en@@es ◦ Called “discriminator aQributes”: dashed underline
coursecourse_idtitlecredits
sectionsec_idsemesteryear
sec_course
} Some@mes needed, and useful } Can replace with another en@ty set and three binary rela@onships 7.5 Entity-Relationship Diagrams 279
instructor
IDnamesalary
student
IDnametot_cred
. . .project
proj_guide
Figure 7.13 E-R diagram with a ternary relationship.
We can specify some types of many-to-one relationships in the case of non-binary relationship sets. Suppose a student can have at most one instructor asa guide on a project. This constraint can be specified by an arrow pointing toinstructor on the edge from proj guide.
We permit at most one arrow out of a relationship set, since an E-R diagramwith two or more arrows out of a nonbinary relationship set can be interpreted intwo ways. Suppose there is a relationship set R between entity sets A1, A2, . . . , An,and the only arrows are on the edges to entity sets Ai+1, Ai+2, . . . , An. Then, thetwo possible interpretations are:
1. A particular combination of entities from A1, A2, . . . , Ai can be associatedwith at most one combination of entities from Ai+1, Ai+2, . . . , An. Thus, theprimary key for the relationship R can be constructed by the union of theprimary keys of A1, A2, . . . , Ai .
2. For each entity set Ak , i < k ≤ n, each combination of the entities from theother entity sets can be associated with at most one entity from Ak . Each set{A1, A2, . . . , Ak−1, Ak+1, . . . , An}, for i < k ≤ n, then forms a candidate key.
Each of these interpretations has been used in different books and systems. Toavoid confusion, we permit only one arrow out of a relationship set, in whichcase the two interpretations are equivalent. In Chapter 8 (Section 8.4), we studyfunctional dependencies, which allow either of these interpretations to be specifiedin an unambiguous manner.
7.5.6 Weak Entity Sets
Consider a section entity, which is uniquely identified by a course identifier,semester, year, and section identifier. Clearly, section entities are related to courseentities. Suppose we create a relationship set sec course between entity sets sectionand course.
Now, observe that the information in sec course is redundant, since sectionalready has an attribute course id, which identifies the course with which thesection is related. One option to deal with this redundancy is to get rid of the
personIDnameaddress
student
instructorrank
secretaryhours_per_week
employeesalary tot_credits
Similar to object-oriented programming: allows inheritance etc.
Disjoint vs Overlapping: No person can be both employee and student
Partial vs Total There may be “Persons” who are neither employee or student
Different ways to convert to a Relational schema based on the above issues
} No rela@onships allowed between rela@onships } Suppose we want to record evalua@ons of a student by a guide on a project
evaluation
proj_ guideinstructor student
eval_ for
project
} Nothing about actual data ◦ How is it stored ?
} No talk about the query languages ◦ How do we access the data ?
} Seman@c vs Syntac@c Data Models ◦ Remember: E/R Model is used for conceptual modeling ◦ Many conceptual models have the same proper@es
} They are much more about represen@ng the knowledge than about database storage/querying
} Basic design principles ◦ Faithful � Must make sense ◦ Sa@sfies the applica@on requirements ◦ Models the requisite domain knowledge � If not modeled, lost a[erwards ◦ Avoid redundancy � Poten@al for inconsistencies ◦ Go for simplicity
} Typically an itera@ve process that goes back and forth
} En@ty sets vs aQributes ◦ Depends on the seman@cs of the applica@on ◦ Consider telephone
290 Chapter 7 Database Design and the E-R Model
added to the instructor relation when the schema for inst dept is merged intoinstructor.
7.7 Entity-Relationship Design Issues
The notions of an entity set and a relationship set are not precise, and it is possibleto define a set of entities and the relationships among them in a number ofdifferent ways. In this section, we examine basic issues in the design of an E-Rdatabase schema. Section 7.10 covers the design process in further detail.
7.7.1 Use of Entity Sets versus Attributes
Consider the entity set instructor with the additional attribute phone number (Fig-ure 7.17a.) It can easily be argued that a phone is an entity in its own right withattributes phone number and location; the location may be the office or home wherethe phone is located, with mobile (cell) phones perhaps represented by the value“mobile.” If we take this point of view, we do not add the attribute phone numberto the instructor. Rather, we create:
• A phone entity set with attributes phone number and location.
• A relationship set inst phone, denoting the association between instructorsand the phones that they have.
This alternative is shown in Figure 7.17b.What, then, is the main difference between these two definitions of an instruc-
tor? Treating a phone as an attribute phone number implies that instructors haveprecisely one phone number each. Treating a phone as an entity phone permitsinstructors to have several phone numbers (including zero) associated with them.However, we could instead easily define phone number as a multivalued attributeto allow multiple phones per instructor.
The main difference then is that treating a phone as an entity better modelsa situation where one may want to keep extra information about a phone, suchas its location, or its type (mobile, IP phone, or plain old phone), or all who share
instructor
IDnamesalary
phonephone_numberlocation
instructor
IDnamesalaryphone_number
(a) (b)
inst_phone
Figure 7.17 Alternatives for adding phone to the instructor entity set.
} En@ty sets vs Rela@onsihp sets ◦ Consider takes
292 Chapter 7 Database Design and the E-R Model
registration.........
sectionsec_idsemesteryear
studentIDnametot_cred
section_reg student_reg
Figure 7.18 Replacement of takes by registration and two relationship sets
Both the approach of Figure 7.15 and that of Figure 7.18 accurately representthe university’s information, but the use of takes is more compact and probablypreferable. However, if the registrar’s office associates other information with acourse-registration record, it might be best to make it an entity in its own right.
One possible guideline in determining whether to use an entity set or arelationship set is to designate a relationship set to describe an action that occursbetween entities. This approach can also be useful in deciding whether certainattributes may be more appropriately expressed as relationships.
7.7.3 Binary versus n-ary Relationship Sets
Relationships in databases are often binary. Some relationships that appear to benonbinary could actually be better represented by several binary relationships.For instance, one could create a ternary relationship parent, relating a child tohis/her mother and father. However, such a relationship could also be representedby two binary relationships, mother and father, relating a child to his/her motherand father separately. Using the two relationships mother and father provides us arecord of a child’s mother, even if we are not aware of the father’s identity; a nullvalue would be required if the ternary relationship parent is used. Using binaryrelationship sets is preferable in this case.
In fact, it is always possible to replace a nonbinary (n-ary, for n > 2) relation-ship set by a number of distinct binary relationship sets. For simplicity, considerthe abstract ternary (n = 3) relationship set R, relating entity sets A, B, and C . Wereplace the relationship set R by an entity set E , and create three relationship setsas shown in Figure 7.19:
• RA, relating E and A.
• RB , relating E and B.
• RC , relating E and C .
} En@ty sets vs aQributes ◦ Depends on the seman@cs of the applica@on ◦ Consider telephone
} En@ty sets vs Rela@onsihp sets ◦ Consider takes
} N-‐ary vs binary rela@onships ◦ Possible to avoid n-‐ary rela@onships, but there are some cases where it is advantageous to use them
} It is not an exact science !!
} En@ty-‐rela@onship Model ◦ Intui@ve diagram-‐based representa@on of domain knowledge, data proper@es etc… ◦ Two key concepts: � En@@es � Rela@onships ◦ We also looked at: � Rela@onship cardinali@es � Keys � Weak en@ty sets � …
} En@ty-‐rela@onship Model ◦ No standardized model (as far as I know) � You will see different types of symbols/constructs ◦ Easy to reason about/understand/construct
◦ Not as easy to implement � Came a[er the rela@onal model, so no real implementa@on was ever done
� Mainly used in the design phase
} Convert en@ty sets into a rela@onal schema with the same set of aQributes
Customer
cname ccity cstreet
Customer_Schema(cname, ccity, cstreet)
Branch
bname bcity assets Branch_Schema(bname, bcity, assets)
} Convert rela@onship sets also into a rela@onal schema } Remember: A rela@onship is completely described by primary keys of associate en@@es and its own aQributes
Depositor_Schema(cname, acct-no, access-date)
Account
Customer
Depositor
acct-no balance
cname ccity cstreet
access-date
Well… Not quite. We can do better. It depends on the relationship cardinality
Customer_Schema(cname, ccity, cstreet)
Account_Schema(acct-no, balance)
} Say One-‐to-‐Many Rela@onship from Customer to Account à Many accounts per customer
Account
Customer
Depositor
acct-no balance
cname ccity cstreet
access-date
Customer_Schema(cname, ccity, cstreet)
Account_Schema(acct-no, balance, cname, access-date)
Exactly same information, fewer tables
E/R Relational Schema Entity Sets
E = (a1, …, an)
Relationship Sets R = (a1, b1, c1, …, cn)
a1: E1’s key b1: E2’s key
c1, …, ck: attributes of R
Not the whole story for Relationship Sets …
E1
… a1 an
E1
… …
…
R E2
a1 an
c1 ck
b1 bm
Relationship Cardinality Relational Schema
n:m E1 = (a1, …, an) E2 = (b1, …, bm) R = (a1, b1, c1, …, cn)
n:1 E1 = (a1, …, an, b1, c1, …, cn) E2 = (b1, …, bm)
1:n E1 = (a1, …, an) E2 = (b1, …, bm,, a1, c1, …, cn)
1:1 Treat as n:1 or 1:n
R
R
R
R
E1
… …
…
R E2
a1 an
c1 ck
b1 bm
Acct-Branch Account Branch
Borrower Customer Loan
Depositor Loan-Branch
Q. How many tables does this get translated into? A. 6 (account, branch, customer, loan, depositor, borrower)
acct_no balance bname bcity assets
cname ccity cstreet lno amt
E/R Relational Schema Weak Entity Sets
E1 = (a1, …, an) E2 = (a1, b1, …, bm)
E1
… …
IR E2
a1 an b1 bm
E/R Relational Schema Multivalued Attributes
Emp = (ssn, name) Emp-Phones = (ssn, phone)
Emp
ssn name 001 …
Smith …
Emp-Phones
Employee
ssn name phone ssn phone 001 001 …
4-1234 4-5678 …
E/R Relational Schema Subclasses
Method 1: E = (a1, …, an) E1 = (a1, b1, …, bm) E2 = (a1, c1, …, ck) Method 2: E1 = (a1, …, an, b1, …, bm) E2 = (a1, …, an, c1, …, ck)
E
E2
ISA
E1
… … b1 bm c1 ck
… a1 an
} Subclasses example: } Method 1: } Account = (acct_no, balance) } SAccount = (acct_no, interest) } CAccount = (acct_no, overdra[)
} Method 2: } SAccount = (acct_no, balance, interest) } CAccount = (acct_no, balance, overdra[)
Q: When is method 2 not possible? A: When subclassing is partial
} Web applica@on framework wriQen in Ruby } Uses a Model-‐View-‐Controller paQern } Paradigms: ◦ Conven@on-‐over-‐configura@on ◦ Don’t repeat yourself ◦ Ac@ve record paQern
} Models (stored in app/models) ◦ Map to database tables ◦ E.g., Instructor model maps to instructors table in the database ◦ Can keep track of associa@ons between different models (e.g., rela@onships, foreign keys, etc).
} Controllers (stored in app/controllers) ◦ Responds to external requests from the web server ◦ Manipulates the models and passes informa@on to views
} Views (stored in app/views) ◦ ERB files that control what is shown to the user ◦ Get translated into HTML
} Config/routes.rb ◦ Dictates what controllers to call in response to different requests
} Basic skeleton already created for you } You have to figure out what more en@@es to add, and set up the controllers/views/models appropriately ◦ Probably don’t need to add anything to config/routes.rb
} To get started: ◦ Create the student lis@ng and course lis@ng pages ◦ Understand how to set up associa@ons between different models (see appropriate Rails guide)