3. Relational Model Concepts
• The relational Model of Data is based on the
concept of a Relation.
• A Relation is a mathematical concept based
on the ideas of sets.
• The strength of the relational approach to
data management comes from the formal
foundation provided by the theory of relations.
4. INFORMAL DEFINITIONS
• RELATION: A table of values
– A relation may be thought of as a set of rows.
– A relation may alternately be though of as a set of columns.
– Each row represents a fact that corresponds to a real-world
entity or relationship.
– Each row has a value of an item or set of items that uniquely
identifies that row in the table.
– Sometimes row-ids or sequential numbers are assigned to
identify the rows in the table.
– Each column typically is called by its column name or column
header or attribute name.
5. FORMAL DEFINITIONS
• A Relation may be defined in multiple ways.
• The Schema of a Relation: R (A1, A2, .....An)
Relation schema R is defined over attributes A1,
A2, .....An
For Example -
CUSTOMER (Cust-id, Cust-name, Address,
Phone#)
Here, CUSTOMER is a relation defined over the four
attributes Cust-id, Cust-name, Address, Phone#, each
of which has a domain or a set of valid values. For
example, the domain of Cust-id is 6 digit numbers.
7. Typical DBMS Functionality
• Define a database : in terms of data types,
structures and constraints
• Construct or Load the Database on a
secondary storage medium
• Manipulating the database : querying,
generating reports, insertions, deletions
and modifications to its content
• Concurrent Processing and Sharing by a
set of users and programs – yet, keeping all
data valid and consistent
8. CODD’S RULES
1 Information Rule
2 Guaranteed Access Rule
3 Systematic Treatment of Nulls Rule
4 Active On-line catalog based on the relational model
5 Comprehensive Data Sub-language Rule
6 View Updating Rule
7 High-Level Insert, Update and Delete
8 Physical Data Independence
9 Logical Data Independence
10 Integrity Independence
11 Distribution Independence
12 No subversion Rule
9. Definitions
• An entity is an object in the miniworld.
• An attribute of an entity can have a value
from a value set (domain)
• Each entity belongs to some one entity
type s.t. entities in one entity type have the
same attributes (so each entity type is a
set of similar entities).
10. Definitions (con’t)
• A key attribute of an entity type is one
whose value uniquely identifies an entity
of that type.
• A combination of attributes may form a
composite key.
• If there is no applicable value for an
attribute that attribute is set to a null value.
11. Entity Type / Entity Set
Entity Type (Intension): EMPLOYEE
Attributes: Name, Age, Salary
Entity Set (Extension): e1 = (John Smith, 55, 80000)
e2 = (Joe Doe, 40, 20000)
e3 = (Jane Doe, 27, 30000)
.
.
.
16. Relationship Type
• A relationship type R among n entity types
E1,…,En is a set of relationship instances
ri, where each ri associates n entities (e1,
…,en), s.t. each ej ∈ Ej. Informally, a
relationship instance is an association of
entities, with exactly one entity from each
participating entity type.
17. Relationship Type (con’t)
• The degree n of a relationship type is the
number of participating entity types.
• In the ER model relationships are
explicitly represented.
18. Entity Roles
• Each entity type in a relationship type
plays a particular role that is described by
a role name. Role names are especially
important in recursive relationship types
where the same entity participates in
more than one role:
Employee
Supervisor 1 N Supervisee
Supervision
19. Weak Entity Type
• A weak entity type is one without any key
attributes of its own. Entities belonging to
a weak entity type are identified by being
related to another entity type ( called
identifying owner) through a relationship
type ( called identifying relationship), in
combination with values of a set of its own
attributes (called partial key). A weak entity
type has total participation constraint w.r.t.
its identifying relationship.
20. Relationship Attributes
• Relationship types can have attributes as
well. in case of 1:1 or 1:N relationships,
attributes can be migrated to one of the
participating entity types.
21. Structural Constraints
• Structural constraints of a relationship
type:
– Cardinality ratio: Limits the number of
relationship instances an entity can participate
in, eg. 1:1, 1:N, M:N
– Participation constraint: If each entity of
an entity type is required to participate in
some instance of a relationship type, then that
participation is total; otherwise, it is partial.
22. Structural Constraint Min, Max
• A more complete specification of the
structural constraint on a relationship type
can be given by the integer pair (min,
max), which means an entity must
participate in at least min and at most max
relationship instances.
23.
24. A ternary relationship generally represents
more information than 3 binary relationships