The document provides an introduction to database management systems (DBMS) and data modeling. It discusses the evolution of data models from hierarchical and network models to relational and object-oriented models. The relational model introduced tables and relationships between entities. The entity-relationship model uses diagrams to visually represent entities, attributes, and relationships. The object-oriented model treats data and relationships as objects that can contain attributes, methods, and inherit properties from classes.

1. Introduction to DBMS

2. Data, information and knowledge
• Data
– Collection of text, numbers and symbols with no
meaning.
• Eg: cat, dog, gerbil, rabbit, cockatoo
• 161.2, 175.3, 166.4, 164.7, 169.3
• Data + Meaning = Information
• Eg: cat, dog, gerbil, rabbit, cockatoo is a list of household
pets
• 161.2, 175.3, 166.4, 164.7, 169.3 are the heights of 15-
year-old students

3. Data, information and knowledge
• Knowledge
– acquiring and remembering a set of facts, or
– the use of information to solve problems.
– Two types
• Explicit Knowledge
• Tacit knowledge
– Information + application or use = Knowledge
• Eg: The tallest student is 175.3cm.
• A lion is not a household pet as it is not in the list and it
lives in the wild.

4. Features of flat file database
• Advantages
– All records are stored in one place
– Easy to set up
– Easy to understand
– Simple sorting of records can be carried out
– Record can be extracted on the basis of simple criteria
• Disadvantages
– High level of redundancy in data
– Non-unique records
– Redundancy in data often results to inconsistency.
– Inherently inefficient
– Harder to change data format
– Poor at complex queries –because of inflexibility of files
– Poor at limiting access

5. Database
• Systematic collection of data
• Collection of information that is organized so that it
can be easily accessed, managed and updated
• Online telephone directory

6. Database Management System(DBMS)
• Collection of programs to access database, manipulate
data, representation of data
• Interface between the database and end users
• Programs which helps in creation and maintenance of a
database
– Collection of interrelated data
– Set of programs to access the data
– An environment that is both convenient and efficient to
use
• Microsoft Access, FoxPro ,SQL Server, Oracle, Ingres ,DB2

7. Drawbacks of using file systems to store data
• Data redundancy and inconsistency
• Difficulty in accessing data
• Data isolation
• Integrity problems
– Integrity constraints become “buried” in program code
rather than being stated explicitly
– Difficult to add new constraints or change existing ones
• Atomicity of updates
– Failures may leave database in an inconsistent state with
partial updates carried out
• Concurrent access by multiple users
– Uncontrolled concurrent accesses can lead to inconsistencies
• Security problems
– Hard to provide user access to some, but not all, data

8. View of Data
• Provide users with an abstract view of data
• Hides how data is stored and maintained
• Data Abstraction
– Physical level- describes how a record is stored.
– Logical level- describes what data stored in database, and the
relationships among the data.
– V iew level-describes only part of entire database

9. The three levels of data abstraction

10. The three levels of data abstraction
• Physical level
– Block of consecutive storage locations
– Physical organization of data
– DBA
• Logical level
– Type definition
– Interrelationship
– Programmers and database administrators work at this level
• View level
– Set of application programs
– Views of the database is defined
– Users

11. Instances and Schemas
• Schema
– Design of a database
– Three types: Physical schema, logical schema and
view schema.
– Physical schema
• Design of a database at physical level
• How the data stored in blocks of storage is described at this
level.
– Logical schema
– View schema
• Instance – the actual content of the database at a
particular point in time

12. Data Independence
• Ability to modify schema definition in one level without affecting a
schema definition in the next higher level
• Physical Data Independence
– Ability to modify the physical schema without changing
application program
• Logical Data Independence
– Ability to modify the logical schema without changing application
program
– When logical structure is changed

13. Data Models
• How the logical structure of a database is modeled
• A collection of tools for describing
– Data
– Data relationships
– Data semantics
– Data constraints
• Define how data is connected to each other and how they
are processed and stored inside the system

14. Data Models
• Relational model
– Tables to represent data and relationship
– Eg of record-based model
• Entity-Relationship data model (mainly for database
design)
– Objects (Entities) and relationship
• Object-based data models (Object-oriented and Object-
relational)
• Semistructured data model (XML)
– Individual data items of the same type may have different
sets of attributes
• Other older models:
– Network model
– Hierarchical model

15. Relational Databases
• Based on the relational model of data
• Uses tables to represent data and relationship
• Includes DML and DDL
• Each table has multiple columns ,each has unique name
• Eg. of record-based model
– Database is structured in fixed-format records of several types
– Table contain records of a particular type
– Each record defines a fixed number of fields or attributes

16. A Sample Relational Database

17. Relational Databases
• SQL: widely used non-procedural language
• Data-Manipulation Language
– select customer.customer_name
from customer
where customer.customer_id = ‘192-83-7465’
• Data-Definition Language
– Create table account(acc_no char(10), balance integer)
• Application programs generally access databases
through one of
– Language extensions to allow embedded SQL
• DML precompiler converts DML to normal procedure calls
– Application program interface (e.g., ODBC/JDBC) which
allow SQL queries to be sent to a database

18. System structure

19. Database Architecture

20. System structure
• DBMS acts as an interface between the user and the
database.
• Database System Structure are partitioned into modules for
different functions
• The functional components of a database system can be
broadly divided into the storage manager and query
processor components.

21. Database Users and User Interfaces
• Naïve users- invoke one of the permanent application
programs that have been written previously
• Application programmers-computer professional who write
application programs
– Interact with system through DML calls ,RAD tools
• Sophisticated users – form requests in a database query
language
• Specialized users – write specialized database applications
that do not fit into the traditional data processing
framework

22. The Query Processor
• DDL interpreter
– Interprets DDL statements and records the definitions in the data
dictionary
• DML compiler
– Translates DML statements in a query language into an evaluation
plan consisting of low level instructions that the query evaluation
engine understands
• Query evaluation engine
– Executes low level instructions generated by the DML compiler.

23. Storage Manager
• Program module that provides the interface between the low-level
data stored in the database and the application programs and
queries submitted to the system
• The storage manager is responsible to the following tasks:
– Interaction with the file manager
– Efficient storing, retrieving and updating of data
• Authorization and integrity manager
– Which tests for the satisfaction of integrity constraints and checks the authority of
users to access data.
• Transaction manager
– Which ensures that the database remains in a consistent correct) state despite
system failures, and that concurrent transaction executions proceed without
conflicting.
• File Manager
– Which manages the allocation of space on disk storage and the data structures used
to represent information stored on disk.
• Buffer manager
– Which is responsible for fetching data from disk storage into main memory, and
deciding what data to cache in main memory.

24. Storage Manager
• Implements several data structures as part of the physical
system implementation
– Data files, which store the database itself
– Data dictionary, which stores metadata about the structure of the
database, in particular the schema of the database
– Indices, which provide fast access to data items that hold
particular values
–

25. Two-tier and Three-tier Architecture

26. Transaction Management
• Atomicity
• Consistency
• Durability
• A transaction is a collection of operations that performs a
single logical function in a database application
• Transaction-management component ensures that the
database remains in a consistent (correct) state despite
system failures (e.g., power failures and operating system
crashes) and transaction failures.
• Concurrency-control manager controls the interaction
among the concurrent transactions, to ensure the
consistency of the database.

27. Data Models

28. Data Modeling and Data Models
• Database design
– Focuses on how the database structure will be used and manage
end-user data
– First step-Data modeling
• Process of creating specific data model for a determined problem domain
• Iterative,progressive process
• Data model
• An abstraction of a more complex real-world object
• Represents data structures ,their characteristics, relations,
constraints,transformations..
• “blueprint”

29. The Importance of Data Models
• Data models
– Relatively simple representations, usually graphical, of
complex real-world data structures
– Facilitate interaction among the designer, the
applications programmer, and the end user
• End-users have different views and needs for data
• Data model organizes data for various users

30. Data Model Basic Building Blocks
• Entity - anything about which data are to be
collected and stored
• Attribute - a characteristic of an entity
• Relationship - describes an association among
entities
– One-to-many (1:M) relationship
• Painter paint painting
– Many-to-many (M:N or M:M) relationship
• Employee learn skill
– One-to-one (1:1) relationship
• Employee manages store
• Constraint - a restriction placed on the data

31. Business Rules
• Brief, precise, and unambiguous descriptions of policies,
procedures, or principles within a specific organization
• Apply to any organization that stores and uses data to
generate information
• Help to create and enforce actions within that
organization’s environment
• Based on policies, procedures, or principles within a
specific organization
• Must be rendered in writing
• Must be kept up to date
• Sometimes are external to the organization
• Must be easy to understand and widely disseminated
• Describe characteristics of the data as viewed by the
company

32. Business Rules
• Why
– Enhance understanding & facilitate communication
• Standardize company’s view of data
• Constitute a communications tool between users and designers
• Allow designer to understand business process as well as the nature, role,
and scope of data
– Promote creation of an accurate data model
• How (sources)
– Interviews
• Company managers
• Policy makers
• Department managers
• End users
– Written documentation
• Procedures, Standards, Operations manuals
– Observation
• Business operations

33. Translating Business Rules into Data Model Components
• Nouns translate into entities
• Verbs translate into relationships among entities
• Relationships are bi-directional

34. The evolution of data models

35. The Hierarchical Model

36. The Hierarchical Model
• Each parent can have many children
• Each child has only one parent
• Tree is defined by path that traces parent segments
to child segments, beginning from the left

37. The Hierarchical Model-Advantages
– Conceptual simplicity – easy to understand the model layout
– Database security
– Data independence (a change in a data type will be automatically
cascaded throughout the database by the DBMS, thereby eliminating
the need to make changes in the program segments that reference the
changes data type)
– Database integrity – always a link between parent and child
– Efficiency – very efficient when it contains a large volume of data in 1:M
relationships and whose relationships are fixed over time

38. The Hierarchical Model-Disdvantages
– Complex implementation – detailed knowledge of the physical data storage
characteristics is required by the designers and programmers
– Difficult to manage – relocation of segments requires application changes
– Lacks structural independence
– Complex applications programming and use – programmers and end users
must know precisely how the data are physically distributed within the
database
– Implementation limitations – difficult to support M:N relationships
– Lack of standards – no standard DDL and no DML

39. The Network Model
• Created to
– Represent complex data relationships more effectively
– Improve database performance
– Impose a database standard
• Conference on Data Systems Languages (CODASYL)
• American National Standards Institute (ANSI)
• Database Task Group (DBTG)

40. Crucial Database Components
• Schema
– Conceptual organization of entire database as viewed by
the database administrator
• Subschema
– Defines database portion “seen” by the application
programs that actually produce the desired information
from data contained within the database
• Data Management Language (DML)
– Define data characteristics and data structure in order to
manipulate the data

41. Data Management
Language Components
• Schema Data Definition Language (DDL)
– Enables database administrator to define schema
components
• Subschema DDL
– Allows application programs to define database
components that will be used
• DML
– Manipulates database contents

42. Network Model—Basic Structure
• Resembles hierarchical model
• Collection of records in 1:M relationships
– A relationship is called a Set
– Composed of at least two record types
• Owner
– Equivalent to the hierarchical model’s parent
• Member
– Equivalent to the hierarchical model’s child
– A record can appear as a member in more than one set i.e., a
member may have multiple owners

44. 1
• Advantages
– Conceptual simplicity
– Handles more relationship types
– Data access flexibility – no need for a preorder traversal
– Promotes database integrity – must first define the owner
and then the member record
– Data independence
– Conformance to standards
• Disadvantages
– System complexity
– Lack of structural independence

45. The Relational Model: Basic Structure
• Relational Database Management System
(RDBMS)
• Performs same basic functions provided by
hierarchical and network DBMS systems, plus
other functions
– RDBMS handles all the complex physical details
• Most important advantage of the RDBMS is its
ability to let the user/designer operate in a
human logical environment

46. The Relational Model:Basic Structure
• Table (relations)
– Matrix consisting of a series of row/column
intersections
– Related to each other by sharing a common entity
characteristic
• Relational schema
– Visual representation of relational database’s
entities, attributes within those entities, and
relationships between those entities

47. Linking Relational Tables

48. Relational Table
• Stores a collection of related entities
– Resembles a file
• Relational table is purely logical structure
– How data are physically stored in the database is of no
concern to the user or the designer
• Rise to dominance due in part to its powerful and
flexible query language
• SQL-based relational database application involves:
– User interface
– A set of tables stored in the database
– SQL engine

49. A Relational Schema

50. The Relational Model
• Advantages
– Structural independence – changes in the relational
data structure do not affect the DBMS’s data access in
any way
– Improved conceptual simplicity by concentrating on the
logical view
– Easier database design, implementation, management,
and use
– Ad hoc query capability - SQL
– Powerful database management system

51. The Relational Model (continued)
• Disadvantages
– Substantial hardware and system software
overhead
– Can facilitate poor design and implementation
– May promote “islands of information”
problems

52. The Entity Relationship Model
• Widely accepted and adapted graphical tool
for data modeling
• Introduced by Peter Chen in 1976
• Graphical representation of entities and their
relationships in a database structure

53. The Entity Relationship Model—
Basic Structure
• Entity relationship diagram (ERD)
– Uses graphic representations to model database
components
– Entity is mapped to a relational table
• Entity instance (or occurrence) is row in table
• Entity set is collection of like entities
• Connectivity labels types of relationships
– Diamond connected to related entities through a
relationship line

54. Relationships: The Basic Chen ERD

55. Relationships:
The Basic Crow’s Foot ERD

56. The Object Oriented Model
• Semantic data model (SDM) developed by
Hammer and McLeod in 1981
• Modeled both data and their relationships in a
single structure known as an object
• Basis of object oriented data model (OODM)
• OODM becomes the basis for the object
oriented database management system
(OODBMS)

57. The Object Oriented Model
• Object is described by its factual content
– Like relational model’s entity
• Includes information about relationships
between facts within object and relationships
with other objects
– Unlike relational model’s entity
• Subsequent OODM development allowed an
object to also contain operations
• Object becomes basic building block for
autonomous structures

58. The Object Oriented Model Components
• Object –Abstraction of real-world entity
• Attributes
• Methods
• Class hierarchy
• Inheritance

59. Developments that
Boosted OODM’s Popularity
• Growing costs put a premium on code
reusability
• Complex data types and system requirements
became difficult to manage with a traditional
RDBMS
• Became possible to support increasingly
sophisticated transaction & information
requirements
• Ever-increasing computing power made it
possible to support the large computing
overhead required

60. Object Oriented Data Model—
Basic Structure
• Object: abstraction of a real-world entity
• Attributes describe the properties of an object
• Objects that share similar characteristics are
grouped in classes
• Classes are organized in a class hierarchy
• Inheritance is the ability of an object within
the class hierarchy to inherit the attributes and
methods of classes above it

61. A Comparison of the OO Model
and the ER Model

62. The Object Oriented Model
• Advantages
– Adds semantic content
– Visual presentation includes semantic content
– Database integrity
– Both structural and data independence

63. The Object Oriented Model (continued)
• Disadvantages
– Slow pace of OODM standards development
– Complex navigational data access
– Steep learning curve
– High system overhead slows transactions
– Lack of market penetration

64. Other Models
• Extended Relational Data Model (ERDM)
– Semantic data model developed in response to
increasing complexity of applications
– DBMS based on the ERDM often described as
an object/relational database management
system (O/RDBMS)
– Primarily geared to business applications

65. Data Models: A Summary
• Each new data model capitalized on the
shortcomings of previous models
• Common characteristics:
– Conceptual simplicity without compromising the
semantic completeness of the database
– Represent the real world as closely as possible
– Representation of real-world transformations
(behavior) must be in compliance with
consistency and integrity characteristics of any
data model

66. The Development of Data Models

67. Database Models and the Internet
• Characteristics of successful “Internet age” databases
– Flexible, efficient, and secure Internet access that is easily
used, developed, and supported
– Support for complex data types and relationships
– Seamless interfacing with multiple data sources and
structures
– Relative conceptual simplicity to make database design and
implementation less cumbersome
– An abundance of available database design, implementation,
and application development tools
– A powerful DBMS graphical user interface (GUI) to help make
the DBA’s job easier

68. Degrees of Data Abstraction
• Way of classifying data models
• Many processes begin at high level of abstraction and
proceed to an ever-increasing level of detail
• Designing a usable database follows the same basic
process
• American National Standards Institute/Standards
Planning and Requirements Committee (ANSI/SPARC)
– Classified data models according to their degree of
abstraction (1970s):
• Conceptual
• External
• Internal

69. Data Abstraction Levels

70. The Conceptual Model
• Represents global view of the database
• Enterprise-wide representation of data as
viewed by high-level managers
• Basis for identification and description of
main data objects, avoiding details
• Most widely used conceptual model is the
entity relationship (ER) model

72. Advantages of Conceptual Model
• Provides a relatively easily understood macro
level view of data environment
• Independent of both software and hardware
– Does not depend on the DBMS software used to
implement the model
– Does not depend on the hardware used in the
implementation of the model
– Changes in either the hardware or the DBMS
software have no effect on the database design at
the conceptual level

73. The Internal Model
• Representation of the database as “seen”
by the DBMS
• Adapts the conceptual model to the DBMS
• Software dependent
• Hardware independent

75. The External Model
• End users’ view of the data environment
• Requires that the modeler subdivide set of
requirements and constraints into functional
modules that can be examined within the
framework of their external models
• Good design should:
– Consider such relationships between views
– Provide programmers with a set of restrictions that
govern common entities

77. Advantages of External Models
• Use of database subsets makes application
program development much simpler
– Facilitates designer’s task by making it easier to
identify specific data required to support each
business unit’s operations
– Provides feedback about the conceptual
model’s adequacy
• Creation of external models helps to ensure
security constraints in the database design

78. The External Model
• DBMS dependent
• Hardware independent

79. The Physical Model
• Operates at lowest level of abstraction, describing
the way data are saved on storage media such as
disks or tapes
• Software and hardware dependent
• Requires that database designers have a detailed
knowledge of the hardware and software used to
implement database design

81. Database Design and Entity-
Relationship Model

82. Design Process
• Design of database schema
• Design of programs that access and update
data
• Design of security scheme to control access to
data

83. Design Phases
• Characterize fully the data needs of the prospective
database users
– Diagramatic or textual representation
• Chooses a data model ,translates requirements into
conceptual schema
– Detailed overview of the enterprise
– Creation of E-R diagram
• Specification of functional requirements
– Describes the kinds of operations
•

84. Design Phases
• Process of moving from an abstract data model to
the implementation of the database
• Logical-design phase
– Maps the high-level conceptual scheme onto the
implementation data model
• Physical-design phase
– Physical features of the database are specified
•

85. Design Alternatives
• Avoid two major pitfalls
– Redundancy
– Incompleteness

86. Modeling
• A database can be modeled as:
– a collection of entities,
– relationship among entities.
• An entity is an object that exists and is
distinguishable from other objects.
– Example: specific person, company, event, plant
• Entities have attributes
– Example: people have names and addresses
• An entity set is a set of entities of the same type
that share the same properties.
– Example: set of all persons, companies, trees, holidays

87. Entity Sets customer and loan
customer_id customer_ customer_ customer_ loan_ amount
name street city number

88. Attributes
• An entity is represented by a set of attributes, that is
descriptive properties possessed by all members of an
entity set.
Example:
customer = (customer_id, customer_name,
customer_street, customer_city )
loan = (loan_number, amount )
• Domain – the set of permitted values for each attribute
• Attribute types:
– Simple and composite attributes.
– Single-valued and multi-valued attributes
• Example: multivalued attribute: phone_numbers
– Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth

89. Composite Attributes

90. Relationship Sets
• A relationship is an association among several
entities
Example:
Hayes depositor A-102
customer entityrelationship setaccount entity
• A relationship set is a mathematical relation among
n  2 entities, each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
where (e1, e2, …, en) is a relationship
– Example:
(Hayes, A-102)  depositor

91. Relationship Set borrower

92. Relationship Set
• Association between two entity sets –participation
– Entity sets E1,E2….En participate in relationship set R
• Relationship instance in an E-R schema represents an
association between the named entities in the real-world
enterprise
– Individual customer entity Hayes(677-89-9011) and loan entity L-
15 participate in the relationship borrower
– Relationship instance –Person called Hayes who holds customer-id
677-89-9011 has taken the loan numbered L-15
• Function that an entity plays in a relationship—
entity’s role
– The relationship set works_for that is modeled by
ordered pairs of employee entities …(worker,manager)

93. Relationship Set
• An attribute can also be property of a relationship set—
decriptive attribute
• For instance, the depositor relationship set between entity
sets customer and account may have the attribute access-date
Cutomer and loan entity set participate in relationship set borrower….also
guarantor

94. Degree of a Relationship Set
• Refers to number of entity sets that participate in a
relationship set.
• Relationship sets that involve two entity sets are binary
(or degree two). Generally, most relationship sets in a
database system are binary.
• Relationship sets may involve more than two entity
sets.
• Example: Suppose employees of a bank may have jobs (responsibilities) at
multiple branches, with different jobs at different branches. Then there is a
ternary relationship set between entity sets employee, job, and branch
• Relationships between more than two entity sets are
rare. Most relationships are binary

95. Mapping Cardinality Constraints
• Express the number of entities to which another
entity can be associated via a relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping cardinality
must be one of the following types:
– One to one
– One to many
– Many to one
– Many to many

96. Mapping Cardinality
One to one One to many
Note: Some elements in A and B may not be mapped to any
elements in the other set

97. Mapping Cardinality
Many to one Many to many

98. Keys
• A super key of an entity set is a set of one or more
attributes whose values uniquely determine each
entity.
• A candidate key of an entity set is a minimal super key
– Superkey for which no proper subset is a superkey
– Customer_id and {customer_name,customer_address} are
candidate keys
– Customer_id and customer_name together can distinguish customer entities
,but does not form a candidate key ,since customer_id alone is a candidate key
• Although several candidate keys may exist, one of the
candidate keys is selected to be the primary key.

99. Relationship set
• Let R be a relationship set involving entity sets E1, E2, ..., En.
• Let primary-key(Ei) denote the set of attributes that forms the
primary key for entity set Ei.
• If the relationship set R has no attributes associated with it, then the
set of attributes
primary-key(E1) U primary-key(E2) U ... U primary-key(En)
describes an individual relationship in set R
• If the relationship set R has attributes a1, a2, ..., am associated with
it, then the set of attributes
primary-key(E1) U primary-key(E2) U ... U primary-key(En) U {a1, a2,
..., am}
describes an individual relationship in set R
• The set of attributes
primary-key(E1) U primary-key(E2) U ... U primary-key(En)
forms a superkey for the relationship set

100. Relationship set
• Entity set –customer and account
• Relationship set –depositor with attribute access_date
• If relationship set is many-to-many ,the primary key of depositor is
the union of pk of customer and account
• If the depositor relationship is many-to-one from customer to
account , the primary key of depositor is simply the primary key of
customer
• If the depositor relationship is many-to-one from account to
customer , the primary key of depositor is simply the primary key of
account
• If one-to-one ,either pk can be used

101. Participation constraints
• Participation of an entity set E in a relaionship
is total if every entity in E participates in
atleast one relationship in R
• Partial

102. Removing redundant attributes in entity sets
• Entity set –department ,instructor
• Attributes
– Instructor-id,name,deptname, salary id- primary key
• Phoneno,mobileno,officeno,..
– Department-deptname,building,budget,…..deptname- pk
• Each instructor has assoicated department using a relationship set inst-dept
• Deptname appear in both entity set. Since deptname is the pk ,it is redundant in
instructor and needs to be removed

103. E-R Diagrams
 Rectangles represent entity sets.
 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to relationship sets.
 Ellipses represent attributes
 Double ellipses represent multivalued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes

104. E-R Diagram With Composite, Multivalued, and Derived
Attributes

105. Relationship Sets with Attributes

106. Roles
• Entity sets of a relationship need not be distinct
• The labels “manager” and “worker” are called roles; they specify
how employee entities interact via the works_for relationship set.
• Roles are indicated in E-R diagrams by labeling the lines that
connect diamonds to rectangles.
• Role labels are optional, and are used to clarify semantics of the
relationship

107. Cardinality Constraints
• We express cardinality constraints by drawing either a directed
line (), signifying “one,” or an undirected line (—), signifying
“many,” between the relationship set and the entity set.
• One-to-one relationship:
– A customer is associated with at most one loan via the relationship
borrower
– A loan is associated with at most one customer via borrower

108. One-To-Many Relationship
• In the one-to-many relationship a loan is
associated with at most one customer via
borrower, a customer is associated with several
(including 0) loans via borrower

109. Many-To-One Relationships
• In a many-to-one relationship a loan is associated
with several (including 0) customers via borrower,
a customer is associated with at most one loan via
borrower

110. Many-To-Many Relationship
• A customer is associated with several (possibly 0) loans
via borrower
• A loan is associated with several (possibly 0) customers
via borrower

111. E-R Diagram with a Ternary Relationship

112. E-R Diagram with a Ternary Relationship

113. Cardinality Constraints on Ternary Relationship
• We allow at most one arrow out of a ternary (or
greater degree) relationship to indicate a cardinality
constraint
• E.g. an arrow from works_on to job indicates each
employee works on at most one job at any branch.
• If there is more than one arrow, there are two ways of
defining the meaning.
– E.g a ternary relationship R between A, B and C with arrows
to B and C could mean
1. each A entity is associated with a unique entity from B
and C or
2. each pair of entities from (A, B) is associated with a
unique C entity,and each pair (A, C) is associated with a
unique B

114. Participation of an Entity Set in a Relationship Set
 Total participation (indicated by double line): every entity in the
entity set participates in at least one relationship in the relationship
set
 E.g. participation of loan in borrower is total
 every loan must have a customer associated to it via borrower
 Partial participation: some entities may not participate in any
relationship in the relationship set
 Example: participation of customer in borrower is partial

115. Alternative Notation for Cardinality Limits
 Cardinality limits can also express participation constraints
 l..h
 A minimum value of 1 indicate total participation of the entity set in
the relationship set
 A maximum value of 1 indicates that the entity participates in
atmost one relationship
 * no limit

116. Alternative Notation for Cardinality Limits
 Each loan must have exactly one associated customer
 A customer can have zero or more loans
 Relationship borrower is one-to-many from customer to loan
 Participation of loan in borrower is total

118. Design Issues
• Use of entity sets vs. attributes
Choice mainly depends on the structure of the
enterprise being modeled, and on the semantics
associated with the attribute in question.
• Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to
describe an action that occurs between entities
• Binary versus n-ary relationship sets
Although it is possible to replace any nonbinary (n-ary,
for n > 2) relationship set by a number of distinct binary
relationship sets, a n-ary relationship set shows more
clearly that several entities participate in a single
relationship.
• Placement of relationship attributes

119. Use of entity sets vs. attributes
• Employee-employee_id and employee_name
• Telephone-telephone_no and location
• Relationship set emp_telephone
• Attribute telephone_number employee have one telephone
number
• Entity telephone number several telephone numbers
• As multivalued attribute ?
• Mistake
– Use the primary key of an entity et a an attribute of another
entity set,intead of using a relationship
– Designate primary key attribute of related entity set as attribute
of relationship

120. Use of entity sets vs. relationship sets
• customer-customerid,customername,customerstreet,customercity
• Loan-loannumber,amount
• Branch-branchname,branchcity,assets
• If every loan is held by exactly one customer and is associated with
exactly one branch---loan is represented as a relationship
• Several customer hold a loan jointly , same value for descriptive
attributes loannumber and amount
• Two problems
– Data are stored multiple time ,wasting storage space
– Updates potentially leave the data in an inconsistent state
• So loan as entity ;borrower relationship between customer and loan

121. Binary Vs. Non-Binary Relationships
• Some relationships that appear to be non-binary
may be better represented using binary
relationships
– E.g. A ternary relationship parents, relating a child to
his/her father and mother, is best replaced by two
binary relationships, father and mother
• Using two binary relationships allows partial information
(e.g. only mother being know)

122. Converting Non-Binary Relationships to Binary Form
• In general, any non-binary relationship can be represented using binary
relationships by creating an artificial entity set.
– Replace R between entity sets A, B and C by an entity set E, and three
relationship sets:
1. RA, relating E and A 2.RB, relating E and B
3. RC, relating E and C
– Create a special identifying attribute for E
– Add any attributes of R to E
– For each relationship (ai , bi , ci) in R, create
1. a new entity ei in the entity set E 2. add (ei , ai ) to RA
3. add (ei , bi ) to RB 4. add (ei , ci ) to RC

123. Converting Non-Binary Relationships
• Also need to translate constraints
– Translating all constraints may not be possible
– There may be instances in the translated schema that
cannot correspond to any instance of R
• Exercise: add constraints to the relationships RA, RB and RC to
ensure that a newly created entity corresponds to exactly one
entity in each of entity sets A, B and C
– We can avoid creating an identifying attribute by
making E a weak entity set identified by the three
relationship sets

124. Placement of relationship attribute
 Depositor is a one-to-many relationship set such that one customer may have
several accounts , but each account can have only one customer
 Can make access-date an attribute of account, instead of a relationship
attribute
 Attribute of a one-to-many relationship set can be repositioned to entity set on
the ”many” side
 For one-to-one ,the relationship attribute can be associated with either one
participating entities
 For many-to-many relationship ,access_date should be a relationship attribute

125. Weak Entity Sets
• An entity set that does not have a primary key is referred to
as a weak entity set.
• The existence of a weak entity set depends on the existence
of a identifying entity set
– it must relate to the identifying entity set via a total, one-to-
many relationship set from the identifying to the weak entity set
– Identifying relationship depicted using a double diamond
• The discriminator (or partial key) of a weak entity set is the
set of attributes that distinguishes among all the entities of a
weak entity set.
• The primary key of a weak entity set is formed by the
primary key of the strong entity set on which the weak entity
set is existence dependent, plus the weak entity set’s
discriminator.

126. Weak Entity Sets (Cont.)
• We depict a weak entity set by double rectangles.
• We underline the discriminator of a weak entity set with a
dashed line.
• payment_number – discriminator of the payment entity set
• Primary key for payment – (loan_number, payment_number)

127. Weak Entity Sets (Cont.)
• Note: the primary key of the strong entity set is
not explicitly stored with the weak entity set, since
it is implicit in the identifying relationship.
• If loan_number were explicitly stored, payment
could be made a strong entity, but then the
relationship between payment and loan would be
duplicated by an implicit relationship defined by
the attribute loan_number common to payment
and loan

128. Specialization Example

129. E-R Diagram for a Banking Enterprise

130. The Unified Modeling Language
• Class Diagram
• Use case diagram
• Activity diagram
• Implementation diagram

131. Class Diagram

132. Use case Diagram

133. Activity Diagram

136. Database Schema
• Database Schema-logical design of database
• Database schema-snapshot of the data in the
database at a given instant in time
– Change with time
• Relation- variable
• Relation schema-type definition
• Relation instance-value of a variable

137. Database Schema

138. • 1

140. CODD’s 12 RULES OF RELATIONAL
DATABASE
 A relational database management system
(RDBMS) is a database management system
(DBMS) that is based on the relational model as
introduced by E. F. Codd.
 A short definition of an RDBMS may be a DBMS
in which data is stored in the form of tables and
the relationship among the data is also stored in
the form of tables.
 E.F. Codd, the famous mathematician has
introduced 12 rules (0-12)for the relational model
for databases commonly known as Codd's rules.

141. • This rule states that all subsequent rules are
based on the notation that in order for a
database to be considered relational, it must
use it’s relational facilities exclusively to
manage the database.
Rule 0

142.  All information in the relational database is
represented in exactly one and only one way -by
values in tables.
 This is achieved by values in column and rows of
tables.
 All information including table names, column names
and column data types should be available in same
table within the database.
Rule 1: INFORMATION RULE

143. Rule 2: GUARANTEED ACCESS RULE
• Each and every datum(atomic value) is
guaranteed to be logically accessible by resorting
to a combination of table name, primary key value
and column name
– Each unique piece of data should be accessible
by:table name+primary key(row) + attribute(column).
– All data are uniquely identified and accessible via this
identity.

144. Rule 3 : Systematic treatment of null values
• "Null values (distinct from the empty character
string or a string of blank characters and distinct
from zero or any other number) are supported in
fully RDBMS for representing missing information
in a systematic way, independent of data type.“
– NULLs may mean: Missing data, Not applicable
– This is distinct to zero or empty strings
– Primary keys — Not NULL
– Separate handling of missing and/or non applicable
data.

145. Rule 4:Dynamic Online Catalog Based
on the relational model
• The data base description is represented at the
logical level in the same way as-ordinary data, so
that authorized users can apply the same relational
language to its interrogation as they apply to the
regular data.
– The authorized users can access the database structure
by using common language
– Database structure description is contained in user-
accessible tables

146. • A relational system may support several languages
and various modes of terminal use .However, there
must be at least one language whose statements
are expressible, per some well-defined syntax, as
character strings and the ability to support all of the
following is comprehensive
– Data Definition (create,insert,update)
– View Definition
– Data Manipulation (alter,delete,truncate)
– Integrity Constraints (primary key,foreign key,null values)
– Authorization (GRANT , REVOKE)
– Transaction boundaries (begin,commit,rollbacketc)
•
Rule 5: COMPREHENSIVE DATA
SUBLANGUAGE

147. • All view that are theoretically updatable are also
updatable by the system
– View = ”Virtual table”, temporarily derived from base
tables.
– Example: If a view is formed as join of 3 tables,
changes to view should be reflected in base tables.
• Create view record as select name,marks from
student;
Rule 6: VIEW UPDATING RULE

148.  The database must support set-level inserts,updates and
deletes
 This rule states that insert, update, and delete operations should be
supported for any retrievable set rather than just for a single row in a
single table.
 It also perform the operation on multiple row simultaneously .
RULE 7 : HIGH-LEVEL INSERT , UPDATE AND DELETE

149. • Application programs and terminal activities remain logically unimpaired
whenever any changes are made in either storage representation or access
methods
– The ability to change the physical schema without changing the logical
schema is called physical data independence.
– This is saying that users shouldn’t be concerned about how the data is
stored or how it’s accessed. In fact, users of the data need only be able
to get the basic definition of the data they need.
– EXAMPLE:
A change to the internal schema, such as using different file organization or
storage structures, storage devices, or indexing strategy, should be
possible without having to change the conceptual or external schemas.
RULE 8:PHYSICAL DATA INDEPENDENCE

150. • Application program and ad hoc facilities are logically unaffected when
changes are made to the table structures that preserve the original
table values (changing order of column or inserting column)
– What is independence?
The ability to modify schema definition in on level without affecting schema
definition in the next higher level is called data independence
– The ability to change the logical (conceptual) schema without changing
the External schema (User View) is called logical data independence.
– EXAMPLE:
The addition or removal of new entities, attributes, or relationships to the
conceptual schema should be possible without having to change existing
external schemas or having to rewrite existing application programs.
RULE 9 :LOGICAL DATA INDEPENDENCE RULE

152. RULE 10 : INTEGRITY INDEPENDENCE RULE
All relational integrity constraint must be definable
in the relational language and stored in the system
catalog ,not at the application level
 Data integrity refers to maintaining assuring the
accuracy and consistency of data over its entire life
cycle.
 Entity integrity—no component of pk is allowed to have
null value
 Referential integrity

153. RULE 11 : DISTRIBUTION INDEPENDENCE RULE
• The end users and application programs are unaware of and
unaffected by the data location (distributed v. local databases)
– Distribution independence implies that user should not have to
be aware of whether a database is distributed at different sites
or not.
– Application program and adhoc request are not affected by the
change in distribution of physical data. Application program will
work even if the programs and data are moved on different site
– The RDBMS may spread across the more one system or several
networks

154. RULE 12 : NON-SUBVERSION RULE
• If the system support low-level access to the
data,users must not be allowed to bypass the
integrity rules of the database
– There should be no way to modify to database structure other
then through the multiple row data base language(SQL).
Example:
A relational system has a low-level (single-record-at-a-time)
language, that low level cannot be used to subvert or bypass the
integrity Rules and constraints expressed in the higher level
relational language (multiple-records-at-a-time).”