Data Models --- Lecture 3

Data Modeling Tools

• Entity Relationship Diagram

• Unified Modeling Language
• Data Flow Diagram
• Data Dictionary

3 levels of architecture/abstraction:

• Internal level --- Physical level

o The closest to the physical storage
o Concerned with the way the data is physically stored.
o Organization on disk, indexes (indices), etc.
o Describes how record (e.g., customer) is stored.
o Described by means of the INTERNAL SCHEMA (which not only defines the various stored record types but also
specifies what indexes exist, how stored fields are represented, what physical sequence the stored records are in and
so on.)
 INTERNAL SCHEMA
- defines how to store physically on storage devices the database defined by the
conceptual schema
- one internal schema corresponds to one conceptual schema.

• External level --- Logical level

o Closest to the users
o Concerned with the way data is seen by individual users.
o What users/programmers see – program or query interface
o Describes data stored in database and the relationships among the data.
o Defined by means of an EXTERNAL SCHEMA (consists basically of definitions of each of the various external record
types in that external view.)
 EXTERNAL SCHEMA
- Defines the database from viewpoint of the program using the database.
- Considered as part of the data structure defined by the conceptual schema.

• Conceptual level --- Community logical level

o Representation of the entire information content of the database in a form that is somewhat abstract in comparison with
the way in which the data is physically stored.
o Defined by means of the CONCEPTUAL SCHEMA (includes definitions of each of the various conceptual records
types)
 CONCEPTUAL SCHEMA
- logically defines the data of the whole world necessary for the computer system to
process
- defines data from its own viewpoint, without taking into consideration the characteristics
of computer and programs
- one conceptual schema corresponds to one database.

*** SCHEMA - “database description”

- the logical structure of the database.
Example: The database consists of information about a set of customers and accounts and the relationship between
them. View 1 View 2 …
View N
The Three-level Architecture for
Databases
Logical,
Schema
Conceptual
Level
Physical Level
(file organization,
indexing)

Data Independence

A user of a relational database system should be able to use the database without knowing precisely how the data is stored, e.g.
SELECT When, Where
FROM Calendar
WHERE Who = “Jane"

Logical data independence --- Protects the user from changes in the logical structure of the data:
• Could reorganize the calendar “schema” without changing how we query it if the query conforms to a view
that stays the same
Physical data independence --- Protects the user from changes in the physical structure of data:
• Could add an index on who (or sort by when) without changing how the user would write the query, but the
query would execute faster (query optimization)

How Does One Build a Database?

 Start with a conceptual model

 Design & implement schema
  Write applications using DBMS and other tools
 Many ways of doing this where the hard problems are taken care of by other people (DBMS, API writers, library authors,
web server, etc.)
 Common applications include PHP/JSP/servlet-driven web sites
 The DBMS takes care of query optimization and execution

Conceptual Data Model

■ Represents data from the viewpoint of the user independent of any technology that will be used to implement the model
■ Representation of the structure and constraints of a database that is independent of the software

Entity Relationship Diagram

■ Detailed, logical representation of the data for an organization or business area.
• Introduced in a key article by Chen (1976)
• Other extensions (with additional / different constructs)
• De facto standard to construct conceptual data model
• Often used as a tool for communications between database designers and end users during analysis phase

Concepts of ER Diagram
• Entity
• An object or concept that is uniquely identifiable
• Diagrammatic representation:
Strong Entity – an entity type that is NOT
Student existence-dependent on some other entity type.

Weak Entity – an entity type that is existence-

dependent on some other entity type.

• Basically, an entity can be an object, a person, place, event, subsystem or organization

• A weak entity is dependent in a strong entity
• An example of a strong entity is EMPLOYEE
• An example of a weak entity is a CHARACTER_REFERENCE
• If expressed in a grammatical construct, entities are nouns in a relation. Although not all nouns are
entities, some are attributes

• Attribute
• A property of an entity or a relationship type.
• Classification of Attributes:
• Simple – atomic, attribute is one that cannot be decomposed into meaningful components .
Example: GENDER (either male or female)

• Composite – an attribute with sub-attributes.

Example: BANK_ACCOUNT_NO

• Single-valued - there is only one value at a given time for the attribute. Example: IDNO

• Multi-valued – an attribute that can have one or more values.

Example: EMAIL_ADDRESS

•Derived – an attribute that is computed or calculated.

Example: TOTAL
• The symbol used for attribute is ellipse. Derived attributes are represented using dashed lines.

Diagrammatic Representation CityAdd Composite

ress BrgyNo

Guardian Single-Valued
StreetN Addres ZipCod
o s e

Simp
Name StudentID
Student le

TelNo Gender
_______

Multi- Bday Age

Valued
Derived

• Keys
• Classification of Keys

• Candidate – potential primary keys

• Customer-id is candidate key of customer
• account-number is candidate key of account
• Primary – an attribute that is has the following characteristics:
• NO duplicate values
• NO null values
• NON changeable values
• Composite –a combination of one or more attributes that make the attribute unique. It also called as multi-key field or
attribute.
Diagrammatic Representation
Student

StudentI
D

• Relationship Sets

• Relationships are also known as association of entities.

• Degree of Relations (number of Participants) Student
• Unary – one entity set is related to itself
IdNo M ENo
• Binary – one entity set is related to another entity set.
• Ex: Teacher –Student relationship is of degree 2.
• Ternary – association where three entity sets are
involved IsEnrolle
• N-nary – association where more than 3 entity sets d
are involved

1 Date
DeptCo
Relationship sets may involve more than two entity sets. de

Department
E.g. 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
•
• In the diagram, the association of entity types student and department is the association “Is Enrolled”.

• Cardinality - Express the number of entities to which another entity can be associated via a relationship set.
• Most useful in describing binary relationship sets.
– One (1), Many (M)
• 1 means at most one instance
• M means one or more instances
• One to One
• One to Many
• Many to Many
• Many to One
• Zero to One

One to one One to many Many to one Many to many

Note: Some elements in A and B may not be mapped to any elements in the other set

• Mapping Cardinalities affect ER Design

Can make access-date an attribute of account, instead of a relationship attribute, if each account can have only one customer
I.e., the relationship from account to customer is many to one, or equivalently, customer to account is one to many

• Relationship Sets with Attributes

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
o Double ellipses represent
multivalued attributes.
o Dashed ellipses denote derived attributes.

• Underline indicates primary key attributes

• 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

• 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

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

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

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

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
o 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
o E.g. participation of customer in borrower is partial