SQIT3043 Data Modeling and Database

CHAPTER 2 : DATA MODELS

2.1 INTRODUCTION TO DATA MODELS

2.1.1 What is a Data Model?

 Definitions:
- … a notation for describing data or information (Garcia-Mollina, Ullman, &
Wildom, 2009, p.17).
- … an integrated collection of concepts for describing and manipulating
data, relationships between data, and constraints on the data
organization (Connoly & Begg, 2010, p. 95)
- …a collection of concept that can be used to describe the structure of a
database – provides the necessary means to achieve this abstraction
(Elmasri & Navathe, 2011, p.28).

2.1.2 The Importance of Data Model

 A major aim of a database is to provide users with an abstract view of data,
hiding certain details of how data is stored and manipulated.
 One of the main characteristics of the database approach is to support data
abstraction so that users can perceive data at their preferred level of detail.
 A data model provides the necessary means to achieve this abstraction.

2.2 DATA MODEL BASIC BUILDING BLOCKS

 Data model generally consist of three parts:
a. Structure of the data (Structural Part)– or sometimes referred to as conceptual
model to describe the structure of the data (including the relationships
between data) and emphasize the different levels of the data.
b. Operations on the data (Manipulative Part)– a limited set of operations that
can be performed on the data such as queries (operations that retrieve
information) and modification (operations that change the database).
c. Constraints on the data - describe the limitations on what the data can be.
Example, the field ‘Day’ (i.e. a day of the week) is an integer between 1 to 7. It
ensures that the data is accurate.

2.3 TYPES OF DATA MODELS AND THEIR EVOLUTION

 The purpose of data model is to represent data and to make the data
understandable.
 There have been many data models proposed in literature and they all fall in three
broad categories:

2.3.1 Object-based Data Model

 Use concepts such as entities, attributes, and relationships.
 Entity – a distinct object (a person, place, thing, concept, event) in the
organization that is to be represented in the database.

MOHD. NOOR BIN ABDUL HAMID 1

[email protected]
SQIT3043 Data Modeling and Database
 Attribute – is a property that describes some aspect of the object that we
wish to record.
 Relationship – an association between entities.
 Some of the more common types of object-based data model are:
a) Entity-Relationship (ER):
- model the data based on entities and their relationships
(including their attributes and constraints) in a non technical
and free of ambiguities way.
- One of the main techniques for database design and will be
used in this course.
b) Semantic:
- models that represent more of the meaning of data. For more
information, read Hull & King (1987)and (Peckham &
Maryanski (1988)
c) Functional:
- one of the family of semantic data model which model the
data based on the entities and functional relationships.
- Read more about functional data model from Connoly and
Begg (2010) in page 869 – 874.
d) Object-oriented:
- extends the definitions of an entity to include not only the
attributes that describe the state of the object but also the
actions that are associated with the object, that it, its
behavior.

2.3.2 Record-based Data Model

 Database consists of a number of fixed-format records, possibly of differing
types.
 Each record type defines a fixed number of fields, typically of a fixed
length.
 Record-based (logical) data models are used to specify the overall
structure of the database and higher level description of the
implementation.
 Their main drawback is that they do not provide adequate facilities for
explicitly specifying constraint on the data, whereas the object-based
data model lack the means of logical structure specification but provide
more semantic substance by allowing the user to specify constraint on the
data.
 Three principal types of record-based data model are:
a) Relational Data Model
- Based on the concept of mathematical relationships
- Data and relationships are represented as tables, each of
which has a number of columns with unique name.
- Figure 2.1 is an example of a relational schema. It shows
relationship between Branch and Staff. In particular, the
schema shows that employee John White is a Manager with
MOHD. NOOR BIN ABDUL HAMID 2
[email protected]
SQIT3043 Data Modeling and Database
a salary of 30,000, who works at branch (branchNo)B005,
which, from the first table is located at 22 Deer Rd London.
However, there is no explicit link between these two tables; it
is only by knowing that the attribute branchNo in the Staff
relation is the same as the branchNo of the Branch relation
that we can establish that a relationship exist.
Branch
branchNo. street city postCode
B005 22 Deer Rd London SW1 4EH
B007 16 Argyll St Aberdeen AB2 3SU
B003 163 Main St Glasgow G11 9QX
B004 32 Manse Rd Bristol B599 1NZ
B002 56 Clover Dr London NW10 6EU

Staff
staffNo fName lName position sex DOB salary branchNo
SL21 John White Manager M 1-Oct-45 30000 B005
SG37 Ann Beech Assistant F 10-Nov-60 12000 B003
SG14 David Ford Supervisor M 24-Mar-58 18000 B003
SA9 Mary Howe Assistant F 19-Feb-70 9000 B007
SG5 Susan Brand Manager F 3-Jun-40 24000 B003
SL41 Julie Lee Assistant F 13-Jun-65 9000 B005

Figure 2.1 Example of a Relational Schema

b) Network Data Model

- Data is represented as collections of records and relationships
are represented by sets.
- The records are organized as generalized graph structures
with records appearing as nodes (also called segments) and
sets as edges in the graph.

B005 22 Deer Rd London SL41 Julie Lee . . . Assistant 9000

.

SL21 John White . . . Manager 3000

B007 16 Argyll St Aberdeen .

SA9 Mary Howe . . . Assistant 9000

B003 163 Main St Glasgow .

SG37 Ann Beech . . . Assistant 12000

.
B004 32 Manse Rd Bristol
SG14 David Ford . . . Superviso 18000
. r

B002 56 Clover Dr London SG5 Susan Brand . . . Manager 24000

.

Figure 2.2 Example of a network schema

MOHD. NOOR BIN ABDUL HAMID 3

[email protected]
 SQIT3043 Data Modeling and Database
c) Hierarchical Data Model
- A restricted type of network model.
- Data is represented as a collection of records and
relationships are represented by sets.
- However, network model allows a node to have only one
parent.
- Can be represented as a tree graph; with records appearing
as nodes (also called segments) and sets as edges.

B004 32 Manse Rd Bristol B002 56 Clover Dr London

B005 22 Deer Rd London B003 163 Main St Glasgow B007 16 Argyll St Aberdeen

SL41 Julie Lee . . . Assistant 9000

.

SL21 John White . . . Manager 3000

.

SG37 Ann Beech . . . Assistant 12000

.

SG14 David Ford . . . Superviso 18000

. r

SG5 Susan Brand . . . Manager 24000

.

SA9 Mary Howe . . . Assistant 9000

.

Figure 2.3 Example of a hierarchy schema

 Comparisons between Relational, Network and Hierarchy Data Model

- The majority of modern commercial systems are based on the
relational paradigm, whereas early database systems were based
on either the network or hierarchical data models.
- Network and hierarchical data models required user to have
knowledge of the physical database being accessed, whereas
relational data models provides a substantial amount of data
independence.
- Hence, relational systems adopt a declarative approach to
database processing (that is, they specify what data is to be
retrieved), but network and hierarchical systems adopt a
navigational approach (that is they specify how the data is to be
retrieved).

MOHD. NOOR BIN ABDUL HAMID 4

[email protected]
SQIT3043 Data Modeling and Database

2.3.3 Physical Data Model (Low level Data Model)

 Describes how data is stored in the computer, representing information
such as record structures, record ordering and access paths.
 Generally meant for computer specialist and not for end user.
 There are not as many physical data models as logical data models.
 The most common ones are:
- Unifying Model
- Frame Memory

2.4 THE RELATIONAL MODEL

 The Relational Database Management System (RDBMS) has become the
dominant data-processing software in use today.
 This software represents the second generation of DBMSs and is based on the
relational data model proposed by Codd (1970).
 In the relational data model, all data is logically structured within relations (tables).
Each relation has a name and is made up of named attributes (columns) of data.
Each tuple (row) contains one value per attributes.
 A great strength of the relational model is this simple logical structure. Yet behind
this simple structure is a sound theoretical foundation that is lacking in the first
generation of DBMS (the network and hierarchical DBMSs).
 Read about the History of the Relational Model in Connoly & Begg (2010) page 142
to 142.

2.4.1 Terminology
a. Relation
 A relation(sometimes called file) is a table with column and rows.
 An RDMS requires only that the database be perceived by users as tables –
however this only applies to the logical structure of the database and not
the physical structure which can be implemented using variety of storage
structures.
b. Attribute
 An attribute (sometimes called field) is a named column of a relation.
 In relational model, relations are used to hold information about the objects
to be represented in the database.
 A relation is represented as a two-dimensional table in which the rows of the
table correspond to individual records and the table columns correspond to
attributes.
 Attributes can appear in any order and the relation will still be the same
relation, and therefore will convey the same meaning.
 Figure 2.4 show instances of the Branch and Staff relations. As you can see
in this example, a column contains value of a single attribute; for example,
the branchNo column contain only number of existing branch.

MOHD. NOOR BIN ABDUL HAMID 5

[email protected]
 SQIT3043 Data Modeling and Database

Attributes

Branch
branchNo. street city postCode
B005 22 Deer Rd London SW1 4EH

Cardinality
B007 16 Argyll St Aberdeen AB2 3SU
Relation

B003 163 Main St Glasgow G11 9QX

B004 32 Manse Rd Bristol B599 1NZ
B002 56 Clover Dr London NW10 6EU

Degree

Primary Key Foreign key

Staff
staffNo fName lName position sex DOB salary branchNo
SL21 John White Manager M 1-Oct-45 30000 B005
SG37 Ann Beech Assistant F 10-Nov-60 12000 B003
Relation

SG14 David Ford Supervisor M 24-Mar-58 18000 B003

SA9 Mary Howe Assistant F 19-Feb-70 9000 B007
SG5 Susan Brand Manager F 3-Jun-40 24000 B003
SL41 Julie Lee Assistant F 13-Jun-65 9000 B005

Figure 2.4 Instances of the Staff and Ward relations.

c. Domain
 A domain is the set of allowable values for one or more attributes.
 Every attribute in a relation is defined on a domain.
 Domain may be distinct for each attribute, or two or more attributes may be
defined on the same domain.
 Figure 2.5 shows the domain for some of the attributes of the Branch and
Staff relations.
 The domain concept is important, because it allows the user to define in a
central place the meaning and source of values that attributes can hold. As
a result, more information is available to the system when it undertakes the
execution of a relational operation, and operations that are semantically
incorrect can be avoided. Eg; it is not sensible to compare an street name
with a telephone number, even though the domain definitions for both of
these attributes are character strings.
Attribute Domain Name Meaning Domain Definition
branchNo BranchNumber The set of all possible branch numbers Character: size 4, range B001 – B999
street StreetNames The set of all street names in Britain Character: size 25
city CityNames The set of all city names in Britain Character: size 15
postcode Postcodes The set of all postcodes in Britain . Character: size 8
sex Sex The sex of a person Character : size 1, value M or F
DOB DateOfBirth Possible values of staff birth date Date, range from 1-Jan-20, format
dd-mm-yy
salary Salaries Possible values of staff salaries Monetary : 7 digits, range 6000.00 –
40000.00

Figure 2.5 Domains for some attributes of the Ward and Staff relations.

MOHD. NOOR BIN ABDUL HAMID 6

[email protected]
SQIT3043 Data Modeling and Database

d. Tuple
 A tuple is a row of a relation (sometimes called record).
 Tuples can appear in any order and the relation will still be the same relation,
and therefore convey the same meaning.
 The structure of a relation, together with a specification of the domains and
any other restrictions on possible values, is sometimes called its intention,
which is usually fixed, unless the meaning of a relation is changed to include
additional attributes.
 The tuples are called the extension (or state) of a relation, which changes
over time.

e. Degree
 The degree of a relation is the number of attributes it contains.
 The Ward relation in figure 2.4 has five attributes or degree five.
 A relation with only one attribute would have degree one and be called a
unary relation or one tuple.
 A relation with two attributes is called binary, one with three attributes is
called ternary, and after that the term n-ary is usually used.
 The degree of a relation is the property of the intention of the relation.

f. Cardinality
 The cardinality of a relation is the number of tuples it contains.
 This changes as tuples are added or deleted.
 The cardinality is a property of the extension and is determined from the
particular instance of the relation at any given moment.

g. Relational Database
 A relational database is a collection of normalized relations with distinct
relation names.
 Normalization is a process of structuring relations into an appropriate form.
This will be covered in chapter 5.

2.4.2 Mathematical Relations

 To understand the true meaning of the term relation, we have to review
some concepts from mathematics.
 Suppose that we have two sets, D1 and D2, where D1 = {2,4} and D2 = {1,3,5}.
 The Cartesian product of these two sets, written D1 x D2, is the set of all
ordered pairs such that the first element is a member of D1 and the second
element is the member of D2.
 An alternative way of expressing this is to find all combination of elements
with the first from D1 and the second from D2.
 In our case, we have;
D1 x D2 = {(2,1),(2,3),(2,5),(4,1),(4,3),(4,5)}

MOHD. NOOR BIN ABDUL HAMID 7

[email protected]
SQIT3043 Data Modeling and Database
 Any subset of this Cartesian product is a relation. For example, we could
produce a relation R such that;
R = {(2,1),(4,1)}
 We may specify which ordered pair will be in the relation by giving some
condition for their selection. For example, if we observe that R includes all
those ordered pairs in which the second element is 1, then we could write R
as;
D1, 2 , and y =1)}
 Using the same sets, we could form another relation S in which the first
element is always twice the second. Thus we could write S as;
1 2 , and x =2y} or in this instance,
S = {(2,1)}
as there is only one ordered pair in the Cartesian product that satisfies this
condition.
 We can easily extend the notion of a relation to three sets. Let D1, D2and D3
be three sets. The Cartesian product D1 x D2 x D3 of these three sets is the set
of all ordered triples such that the first element is from D1, the second
element is from D2 and the third element is from D3. Any subset of this
Cartesian product is a relation. For example, suppose we have;
D1 = {1,3} and D2 = {2,4} and D3 = {5,6},

D1 x D2 x D3 = {(1,2,5),(1,2,6),(1,4,5),(1,4,6),(3,2,5),(3,2,6),(3,4,5),(3,4,6)}
Any subset of these ordered triples is a relation.
 We can extend the three sets and define a general relation on n domains.
Let D1, D2,……., Dn be n sets. Their Cartesian product is defined as;
D1 x D2 x…. xDn = {(d1,d2,…..,dn)| d1 D1 , d2 D2,……, dn Dn }
and is usually written as,
n

D
i 1
1

 Any set of n-tuples from this Cartesian product is a relation of the N sets.
 Note that in defining these relations we have to specify the sets, or domains
from which we choose values.

2.4.3 Database Relations

 Applying the previous discussed concepts to databases, we can define a
relation schema.
Relation schema:
 A named relation defined by a set of attribute and domain name pairs.
 Let A1,A2,…..,An be attributes with domain D1, D2,…..Dn. Then set { A1 : D1 , A2 :
D2 ,……, An : Dn} is a relation schema.
 A relation R defined by a relation schema S is a set of mappings from the
attribute names to their corresponding domains.
 Thus, relation R is a set of n-tuples;
MOHD. NOOR BIN ABDUL HAMID 8
[email protected]
SQIT3043 Data Modeling and Database
( A1 : d1 , A2 : d2 ,……, An : dn) such that d1 D1 , d2 D2,……, dn Dn
 Each element in the n-tuple consists of an attribute and a value for that
attribute.
 Normally when we write out a relation as a table, we list the attribute names
as column headings and write out the tuples as rows having the form (d1, d2
,……, dn) where each value is taken from the appropriate domain.
 In this way we can think of a relation in the relational model as any subset of
the Cartesian product of the domain of the attributes. A table is a physical
representation of such a relation.
 In our example, the Branch relation shown in figure 2.4 has attributes
branchNo, street, city,and postcode each with its corresponding
domain.
 The branch relation is any subset of the Cartesian product of the domain, or
any set of four-tuples in which the first element is from the domain
WardName, the second is from the domain WardLocation and so on.
 One of the four-tuples is;
{(B005, 22 Deer Rd, London, SW1 4EH)}
or more correctly;
{(branchNo :B005, street : 22 Deer St, city: London, postcode:SW1 4EH)}
 We refer to this as a relation instance.

Relational database schema

 If R1,R2,….Rn are set of relation schema, then we can write the relational
database schema or simply relational schema, R, as;
R = { R1,R2,….Rn }

2.4.4 Properties of Relations

 A relation has the following properties;
- The relation has a name that is distinct from all other relation names in the
relational schema
- Each cell of the relation contains exactly one atomic (single)value.
- Each attribute has a distinct name.
- Each tuple is distinct; there are no duplicate tuples.
- The order of attributes has no significance.
- The order of tuples has no significance, theoretically. However, in
practice, the order may affect the efficiency of accessing tuples.

2.4.5 Relational Keys

 Since there can be no duplicate tuples, one or more attributes (called
relational keys)are needed to uniquely identifies each tuple in a relationship.
a. Superkey
 An attribute, or set of attributes, that uniquely identify a tuple within a
relation.

MOHD. NOOR BIN ABDUL HAMID 9

[email protected]
SQIT3043 Data Modeling and Database
b. Candidate key
 A superkey such that no proper subset is a superkey within the relation.
 A candidate key K for a relation R has two properties;
- Uniqueness – in each tuple of R, the values ok K uniquely identify
that tuple.
- Irreducibility – no proper subset of K has the uniqueness property.
 There maybe several candidate keys for a relation.
 When a key consists of more than one attribute, we call it a composite key.
 Consider the Branch relation shown in Figure 2.4. Given a value of city, we
can determine several branch offices (for example, London has two branch
offices). This attribute cannot be a candidate key.
 On the other hands, because DreamHome allocates each branch office a
unique branch number, given a branch number value, branchNo, we can
determine at most one tuple, so that branchNo is a candidate key. Similarly
postcode is also a candidate key for this relation.
 Now consider a relation Viewing, which contains information relating to
properties viewed by clients. The relation comprises a client number
(clientNo), a property number (propertyNo), a date of viewing (viewDate),
and optionally, a comment (comment). Given a client number,
clientNo,there may be several corresponding viewings for different
properties. Similarly, given a property number, propertyNo, there may be
several clients who viewed this property. Therefore clientNo and
propertyNo cannot be selected as candidate key. However combination of
clientNo and propertyNo identifies at most one tuple. So for the Viewing
relation, clientNo and propertyNo together form the (composite)
candidate key. If we need to take into account that a client may view a
property morethan once, then we could add viewDate to the composite
key.
 Identifying a candidate key requires that we know the ‘real world’ meaning
of the attribute(s) involve so that we can decide whether duplicates are
possible.

c. Primary key
 The candidate key that is selected to identify tuples uniquely within the
relation.
 Because a relation has no duplicate tuples, it is always possible to identify
each row uniquely. This means that a relation always has a primary key.
 In the worst case, the entire set of attributes could serve as the primary key.
 The candidate keys that are not selected to be the primary keys are called
alternate keys.
 For branch relation, if we choose branchNo as the primary key, postcode
would then be an alternate key.

MOHD. NOOR BIN ABDUL HAMID 10

[email protected]
SQIT3043 Data Modeling and Database
d. Foreign key
 An attribute, or set of attributes, within one relation that matches the
candidate key of some (possibly the same) relation.
 When an attribute appears in more than one relation, its appearance usually
represents a relationship between tuples of the two relations.
 For example, the inclusion of branchNo in both the Branch and Staff
relation is quite deliberate and links each branch to the details of staff
working at that branch. In the Branch relation, branchNo is the primary key.
However in Staff relation, branchNo is a foreign key. We say that the
attribute branchNo in the Staff relation targets the primary key attribute
branchNo in the home relation, Branch.

2.4.6 Representing Relational Database Schemas

 A relational database consists of any number of normalized relations.
 The relation schema for part of the DreamHome case study is:
Branch (branchNo, street, city, postcode
Staff (staffNo, fName,lName, position, sex, DOB,
salary, branchNo)
PropertyForRent (propertyNo, street, city, postcode, type,
rooms, rent. ownerNo, staffNo, branchNo)
Client (clientNo, fName, lName, telNo, prefType,
maxRent, eMail)
PrivateOwner (ownerNo, fName, lName, address, telNo,
eMail, password)
Viewing (clientNo, propertyNo, viewDate, comment)
Registration (clientNo, branchNo, staffNo, dateJoined)
 The common convention for representing a relation schema is to give the
name of the relation followed by the attribute names in parentheses.
Normally the primary key is underlined.
 The conceptual model or conceptual schema, is the set of all such schemas
for the database as shown in figure 2.6.

MOHD. NOOR BIN ABDUL HAMID 11

[email protected]
SQIT3043 Data Modeling and Database

Branch
branchNo street city postcode
B005 22 Deer Rd London SW1 4EH
B007 16 Argyll St Aberdeen AB2 3SU
B003 163 Main St Glasgow G11 9QX
B004 32 Manse Rd Bristol BS99 1NZ
B002 56 Clover Dr London NW10 6EU

Staff
staffNo fName lName position sex DOB salary branchNo
SL21 John White Manager M 1-Oct-45 30000 B005
SG37 Ann Beech Assistant F 10-Nov-60 12000 B003
SG14 David Ford Supervisor M 24-Mar-58 18000 B003
SA9 Mary Howe Assistant F 19-Feb-70 9000 B007
SG5 Susan Brand Manager F 3-Jun-40 24000 B003
SL41 Julie Lee Assistant F 13-Jun-65 9000 B005

PropertyForRent
propertyNo street city postcode type rooms rent ownerNo staffNo branchNo
PA14 16 Hollhead Aberdeen AB7 5SU House 6 650 C046 SA9 B007
PL94 6 Argyll St London NW2 Flat 4 400 C087 SL41 B005
PG4 6 Lawrence St Glasgow G11 9QX Flat 3 350 C040 B003
PG36 2 Manor Rd Glasgow G32 4QX Flat 3 375 C093 SG37 B003
PG21 18 Dale Rd Glasgow G12 House 5 600 C087 SG37 B003
PG16 5 Novar Dr Glasgow G12 9AX Flat 4 450 C093 SG14 B003

Client
clientNo fName lName telNo prefType maxRent eMail
CR76 John Kay 0207-774-5632 Flat 425 [email protected]
CR56 Aline Stewart 0141-848-1825 Flat 350 [email protected]
CR74 Mike Ritchie 01475-392178 House 750 [email protected]
CR62 Mary Tregear 01224-196720 Flat 600 [email protected]

PrivateOwner
ownerNo fName lName address telNo eMail password
C046 Joe Keogh 2 Fergus Dr, Aberdeen AB2 7SX 01224-861212 [email protected] ******
C087 Carol Farrel 6 Achray St, Glasgow G32 9DX 0141-357-7419 [email protected] ******
C040 Tina Murphy 63 Well St, Glasgow G42 0141-943-1728 [email protected] ******
C093 Tony Shaw 12 Park Pl, Glasgow G4 0QR 0141-225-7025 [email protected] ******

Viewing
clientNo propertyNo ViewDate comment
CR56 PA14 24-May-08 Too small
CR76 PG4 20-Apr-08 Too remote
CR56 PG4 26-May-08
CR62 PA14 14-May-08 No dining room
CR56 PG36 28-May-08

Registration
clientNo branchNo staffNo dateJoined
CR76 B005 SL41 2-Jan-08
CR56 B003 SG37 11-Apr-07
CR74 B003 SG37 16-Nov-06
CR62 B007 SA9 7-Mar-07

Figure 2.6 Instance of the DreamHome rental database

MOHD. NOOR BIN ABDUL HAMID 12

[email protected]
SQIT3043 Data Modeling and Database
2.4.7 Integrity Constraints
 As stated in section 2.2, a data model has two other parts: a manipulative part,
defining the types of operation that are allowed on the data, and a set of
integrity constraints, which ensure that the data is accurate. In this section we
discuss the relational integrity constraints.
 Because every attribute has an associated domain, there are constraints (called
domain constraints) that form restrictions on the set of values allowed for the
attributes of relations.
 In addition, there are two important integrity rules, which are constraints or
restrictions that apply to all instances of the database.
 The two principal rules for the relational model are known as entity integrity and
referential integrity.
 Other types of integrity constraints are general constraints and multiplicity,
which is discussed in chapter 4.

a. Nulls
 Represents a value for an attribute that is currently unknown or is not applicable
for this tuple.
 A null can be taken to mean the logical value ‘unknown’. It can mean that a
value is not applicable to a particular tuple, or it could merely mean that no
value has yet been supplied.
 Nulls are a way to deal with incomplete or exceptional data.
 However null is not the same as a zero numeric value or a text string filled with
spaces; zeros and spaces are values, but a null represents the absence of a
value.
 For example, in the Viewing relation shown in figure 2.6, the comment attribute
may be undefined until the potential renter has visited the property and
returned his or her comment to the agency. Without nulls, it becomes necessary
to introduce false data to represents this state or to add additional attributes
that may not be meaningful to user. In our example, we may try to represent a
null comment with value -1. Alternatively, we may add a new attribute
hasCommentBeenSupplied to the viewing relation, which contains a Y (Yes) and
N (No). Both these approach can be confusing to the user.

b. Entity Integrity
 This rule applies to the primary keys of base relations.
 For the present we define a base relation as a relation that corresponds to an
entity in the conceptual schema.
 Entity integrity – means, in a base relation, no attribute of a primary key can be
null.
 If we allow a null for any part of a primary key, we are implying that not all the
attributes are needed to distinguish between tuples, which contradicts the
definition of the primary key.
 Hence in our example, we should not be able to insert a tuple into the Branch
relation with a null for the branchNo attribute.

MOHD. NOOR BIN ABDUL HAMID 13

[email protected]
SQIT3043 Data Modeling and Database

c. Referential Integrity
 This rule applies to foreign key.
 Referential integrity – means, if a foreign key exists in a relation, either the foreign
key value must match a candidate key value of some tuple in its home relation
or the foreign key value must be wholly null.
 For example, branchNo in the Staff relation is a foreign key targeting the
BranchNo attribute in the home relation, Branch. It should not be possible to
create a staff record with branch number B025, for example, unless there is
already a record for branch number B025 in Branch relation.

d. General Constraints
 General constraints are additional rules specified by the users or database
administrators of a database that define or constrain some aspect of the
enterprise.
 It is also possible for users to specify additional constraints that the data must
satisfy. For example, if an upper limit of 20 has been placed upon the number of
staff that may work at a branch office, then the user must be able to specify this
general constraint and expect the DBMS to enforce it. In this case it should not
be possible to add a new staff member at a given branch to the Staff relation if
the number of staff currently assigned to that branch is 20.

SOURCE:

Codd, E. F. (1970). A Relational Model for Large Shared Data Banks. Communications of the
ACM, 13(6), 377-387.

REFERENCES:

Connoly, T., & Begg, C. (2010). Database Systems Apractical Approach to Design, Implementation,
and Management (5 ed.). Boston: Pearson.
Elmasri, R., & Navathe, S. B. (2011). Database Systems Models, Languages, Design and Application
Programming (6 ed.). Boston: Pearson.
Garcia-Mollina, H., Ullman, J. D., & Wildom, J. (2009). Database Systems The Complete Book.
New Jersey: Prentice Hall.
Hull, R., & King, R. (1987). Semantic Database Modelling - Surveys, Applications and Research
Issues. ACM Computing Survey, 19(3), 201-260.
Peckham, J., & Maryanski, F. (1988). Semantic data models. ACM Comput. Surv., 20(3), 153-189.

MOHD. NOOR BIN ABDUL HAMID 14

[email protected]