The document outlines the relational model of databases, describing key components such as relations, relation schemas, and attributes. It explains how entity-relationship diagrams can be converted into relational tables, detailing the rules for embedding relationships and handling weak entities. The importance of avoiding redundancy in the relational design is also emphasized.

1. Relational
Model

2. Relational Model
• A Database is a collection of relations, where
– Each relation is a table, consisting of tuples
(records) with given names and types
• Two components of a relation:
1. Relation schema, describes properties of the table
(meta-data)
2. Relation instance, a table (data)
• Sometimes abbreviated as Relation

3. Relation Schema
• R = (A1, A2, …, An ) is a relation schema
• Where:
– R is the relation
– A1, A2, …, An are attributes

4. Relation Schema
• An example to Relation Schema:
Student( id:String, name:String, gpa:integer )
• Name of the Relation/Table:
– Student
• Name of the Fields:
– id
– name
– gpa
• Types/Domains:
– String for id and name,
– integer for gpa

5. Attribute Types
• Each attribute of a relation has
– a name
– a type with allowed set of values, called as domain
• Attribute values are (normally) required to be atomic;
that is, indivisible
• The special value null is a member of every domain
– null value causes complications in many cases

6. Table
• A Table is an instance of a Relation
• A Table consists of tuples / records
• Each tuple has to include values of all fields of the
Relation Schema

7. A Relation is a Table
Drink
name producer
Y B
X A
Attributes
(fields)
Tuples
(records)

8. From E/R Diagrams to Relations
• E/R Diagrams can be transferred to Relational Diagram
almost mechanically
• There exists two components of an E/R diagram which
are to be converted to Relational Model components:
– (Strong & Weak) Entity Set
– Relationship

9. Entity Set → Table
• Each Entity set becomes a table
• Attributes of the Entity set becomes a field of the
corresponding table

10. Entity Set → Table
Drinker
name address
Drink
name producer
Drinker(name, address)
Drink(name, producer)

11. Relationship → Table
• Relationships also are transferred into tables
• The created table includes (only and all) attributes of the
related Entity Sets those provide uniqueness (only)
• Hence, the attributes of the entity sets those does not
provide uniqueness are not included within the
corresponding table

12. Relationship → Table
Like(dname, bname)
Prefer(dname, bname)
Married(hname, wname)
Buddy(d1name, d2name)
Prefer
Like
Married
husband
wife
Drinker
name address
Drink
name producer
Buddy
1 2
• Name conversion is performed as required
• First two tables includes all attributes (as fields), while
others include only the ones which provide uniqueness
Drinker(name, address)
Drink(name, producer)

13. Embedding Relations
• Sometimes Relationships may be embedded, or merged
into one of the Entity Set that is attached before creating
the tables

14. Embedding Relations
• Assume that each drinker prefers only one Drink
• In this case, you can merge prefer relationship:
– Drinker(name, address)
– Prefer(drinkername, drinkname)
• So that:
– Drinker(drinkername, address, preferreddrinkname)
Prefer
Drinker
name address
Drink
name producer
Drinker
drinkername
address
preferredbeer

15. Embedding Relations
• Relationships may be embedded into one relation if it is
either:
– one to one
– many to one
• Other kinds of relationships may not be embedded into
one relation:
– one to many
– many to many

16. Risk in Embedding Relations
• Note that a drinker can prefer only one Drink, but may like
many Drink brands
• Combining Drinker with Like would be a mistake
• It leads to redundancy of address field, since one drinker
may be required to included more than once:
name address likedDrink
Ayse No:1 X
Ayse No:5 Y
Redundancy

17. Handling Weak Entity Sets
• Relation for a weak entity set must include:
1. attributes for its complete key set, including:
a. its own key attributes
b. key attributes of the entity set that belongs to
entity set(s)that it is dependent to
2. its own nonkey attributes
Responsible
Dependent
name type
Employee
id

18. Handling Weak Relationships
• A weak/supporting/double-diamond relationship is
redundant and yields no relation (table)

19. Example
Host( hostName )
Login ( loginName, hostName, time )
To( loginName, hostName, hostName )
Redundant
Login Host
To
name name
time
To becomes part of
Login

20. Thank you. ☺

21. responsible
Dependent
name type
Employee
id
SalaryIncrease month
amount