The relational data model part[1]

Data Model
The Relational Data Model
1

Relational Model Concepts
 The relational model represents the database as a collection of relations.
 When a relation is thought of as a table of values, each row in the table
represents a collection of related data values.
 A row represents a fact that typically corresponds to a real-world entity or
relationship.
 In the formal relational model terminology, a row is called a tuple, a
column header is called an attribute, and the table is called a relation.
 The data type describing the types of values that can appear in each
column is represented by a domain of possible values.
 The table name and column names are used to help to interpret the
meaning of the values in each row.
2

Domains
 A domain D is a set of atomic values.
 By atomic we mean that each value in the domain is indivisible as far as the
formal relational model is concerned.
 Some examples of domains follow:
 Usa_phone_numbers. The set of ten-digit phone numbers valid in the United States.
 Names: The set of character strings that represent names of persons.
 The preceding are called logical definitions of domains.
 A data type or format is also specified for each domain.
 For example, the data type for the domain Usa_phone_numbers can be
declared as a character string of the form (ddd)ddddddd, where each d is a
numeric (decimal) digit and the first three digits form a valid telephone area
code.
3

Relation
 A relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation
name R and a list of attributes, A1, A2, ..., An.
 Each attribute Ai is the name of a role played by some domain D in the
relation schema R.
 D is called the domain of Ai and is denoted by dom(Ai).
 A relation schema is used to describe a relation; R is called the name of this
relation.
 The degree (or arity) of a relation is the number of attributes n of its relation
schema.
4

Relation State
 A relation (or relation state) r of the relation schema R(A1, A2, ..., An), also
denoted by r(R), is a set of n-tuples r = {t1, t2, ..., tm}.
 Each n-tuple t is an ordered list of n values t =<v1, v2, ..., vn>, where each
value vi, 1 ≤ i ≤ n, is an element of dom (Ai) or is a special NULL value.
 The ith value in tuple t, which corresponds to the attribute Ai, is referred to as
t[Ai] or t.Ai .
 The terms relation intension for the schema R and relation extension for a
relation state r(R) are also commonly used.
 It is possible for several attributes to have the same domain. The attribute
names indicate different roles, or interpretations, for the domain.
5

Characteristics of Relations
 A relation is defined as a set of tuples. tuples in a relation do not have any
particular order.
 Each value in a tuple is an atomic value. Hence, composite and
multivalued attributes are not allowed. This model is sometimes called the
flat relational model.
 multivalued attributes must be represented by separate relations, and
composite attributes are represented only by their simple component
attributes in the basic relational model.
 The relation schema can be interpreted as a declaration or a type of
assertion.
 An alternative interpretation of a relation schema is as a predicate; in this
case, the values in each tuple are interpreted as values that satisfy the
predicate.
6

Relational Model Notation
We will use the following notation in our presentation:
 A relation schema R of degree n is denoted by R(A1, A2, ..., An).
 The uppercase letters Q, R, S denote relation names.
 The lowercase letters q, r, s denote relation states.
 The letters t, u, v denote tuples.
 An attribute A can be qualified with the relation name R to which it belongs
by using the dot notation R.A—for example, STUDENT.Name.
 As an example, consider the tuple t = <‘Barbara Benson’, ‘533-69-1238’,
‘(817)839- 8461’, ‘7384 Fontana Lane’, NULL, 19, 3.25> from the STUDENT
relation; we have t[Name] = <‘Barbara Benson’>, and t[Ssn, Gpa, Age] =
<‘533-69-1238’, 3.25, 19>.
7

Relational Model Constraints
 The state of the whole database will correspond to the states of all its
relations at a particular point in time.
 There are generally many restrictions or constraints on the actual values in a
database state.
 These constraints are derived from the rules in the miniworld that the
database represents.
 Constraints on databases can generally be divided into three main
categories:
 Constraints that are inherent in the data model. We call these inherent model-
based constraints or implicit constraints.
 Constraints that can be directly expressed in schemas of the data model,
typically by specifying them in the DDL.We call these schema-based constraints
or explicit constraints.
 Constraints that cannot be directly expressed in the schemas of the data model,
and hence must be expressed and enforced by the application programs. We
call these application-based or semantic constraints or business rules.
8

 The constraint that a relation cannot have duplicate tuples is an inherent
constraint.
 In this section we will focus on schema-based constraints .
 Application-based constraints are more general, relate to the meaning as
well as behavior of attributes, and are difficult to express and enforce within
the data model, so they are usually checked within the application
programs that perform database updates.
 Another important category of constraints is data dependencies, which
include functional dependencies and multivalued dependencies.
 They are used mainly for testing the “goodness” of the design of a relational
database and are utilized in a process called normalization
 The schema-based constraints include domain constraints, key constraints,
constraints on NULLs, entity integrity constraints, and referential integrity
constraints.
9

Domain Constraints
 Domain constraints specify that within each tuple, the value of each
attribute A must be an atomic value from the domain dom(A).
 The data types associated with domains typically include:
 standard numeric data types for integers (such as short integer, integer,
and long integer).
 real numbers (float and doubleprecision float).
 Characters, Booleans, fixed-length strings, and variable-length strings are
also available, as are date, time, timestamp, and money, or other special
data types.
 Other possible domains may be described by a subrange of values from a
data type or as an enumerated data type in which all possible values are
explicitly listed.
10

Key Constraints
 In the formal relational model, a relation is defined as a set of tuples. By
definition, all elements of a set are distinct; hence, all tuples in a relation must
also be distinct.
 This means that no two tuples can have the same combination of values for all
their attributes.
 To achieve this goal we use keys.
 In general we have super key and key.
 A super key is a subset of attributes of a relation schema R with the property that
no two tuples in any relation state r of R should have the same combination of
values for these attributes. t1[SK]≠ t2[SK]
 A superkey SK specifies a uniqueness constraint that no two distinct tuples in any
state r of R can have the same value for SK.
 As we said superkey is a subset of attributes, we can remove some of those
attributes and it can’t affect on uniqueness constraint that made by this
superkey.
11

 A key is the subset of attributes of a relation that, we can’t remove any
attribute of that . So every key is a super key, but not vice versa.
 For example, we have a superkey consist of {ID,Name,Lastname} , we can
remove Name or Lastname or even both and it doesn't affect on
uniqueness constraint of this key. The { ID } is a key attribute.
 a key satisfies two properties:
1. Two distinct tuples in any state of the relation cannot have identical values for
(all) the attributes in the key. This first property also applies to a superkey.
2. It is a minimal superkey—that is, a superkey from which we cannot remove any
attributes and still have the uniqueness constraint in condition 1 hold. This
property is not required by a superkey.
 In general, a relation schema may have more than one key. In this case,
each of the keys is called a candidate key.
 It is common to designate one of the candidate keys as the primary key of
the relation.
12

13
Another constraint on attributes specifies whether NULL values are or are not
permitted.
For example, if every STUDENT tuple must have a valid, non-NULL value for
the Name attribute, then Name of STUDENT is constrained to be NOT NULL.
Constraints on NULL Values

Relational Databases and Relational
Database Schemas
 A relational database usually contains many relations, with tuples in
relations that are related in various ways.
 A relational database schema S is a set of relation schemas S = {R1, R2, ...,
Rm} and a set of integrity constraints IC.
 A relational database state DB of S is a set of relation states DB = {r1, r2, ..., rm}
such that each ri is a state of Ri and such that the ri relation states satisfy the
integrity constraints specified in IC.
 Figure 1 on the next page shows a relational database schema that we
call COMPANY = {EMPLOYEE, DEPARTMENT, DEPT_LOCATIONS, PROJECT,
WORKS_ON, DEPENDENT}.
 Figure 2 shows a relational database state corresponding to the
COMPANY schema.
14

15
When we refer to a relational database, we
implicitly include both its schema and its
current state.

 A database state that does not obey all the integrity constraints is called an
invalid state, and a state that satisfies all the constraints in the defined set
of integrity constraints IC is called a valid state.
 Attributes that represent the same real-world concept may or may not
have identical names in different relations. Alternatively, attributes that
represent different concepts may have the same name in different
relations.
 Each relational DBMS must have a data definition language (DDL) for
defining a relational database schema. Current relational DBMSs are mostly
using SQL for this purpose.
 Integrity constraints are specified on a database schema and are
expected to hold on every valid database state of that schema.
16

Entity Integrity and Referential Integrity
 The entity integrity constraint states that no primary key value can be NULL.
 This is because the primary key value is used to identify individual tuples in a
relation.
 Key constraints and entity integrity constraints are specified on individual
relations.
 The referential integrity constraint is specified between two relations and is
used to maintain the consistency among tuples in the two relations.
 Informally, the referential integrity constraint states that a tuple in one
relation that refers to another relation must refer to an existing tuple in that
relation.
 For example, the attribute Dno of EMPLOYEE gives the department number
for which each employee works; hence, its value in every EMPLOYEE tuple
must match the Dnumber value of some tuple in the DEPARTMENT relation.
17

Foreign Key
 A set of attributes FK in relation schema R1 is a foreign key of R1 that
references relation R2 if it satisfies the following rules:
1. The attributes in FK have the same domain(s) as the primary key
attributes PK of R2; the attributes FK are said to reference or refer to the
relation R2.
2. A value of FK in a tuple t1 of the current state r1(R1) either occurs as a
value of PK for some tuple t2 in the current state r2(R2) or is NULL. In the
former case, we have t1[FK] = t2[PK], and we say that the tuple t1
references or refers to the tuple t2.
 In this definition, R1 is called the referencing relation and R2 is the
referenced relation.
 If these two conditions hold, a referential integrity constraint from R1
to R2 is said to hold.
18

The relational data model part[1]

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to The relational data model part[1] (20)

Recently uploaded (20)

The relational data model part[1]