IT - 304
Database Systems
for BS (IT)
Lecture 3:
Database Development and Data Modeling
Hasan Raza
Lecturer CS & IT
Govt. Postgraduate College, Sheikhupura
What is Model?
■ A model is a simplified way to describe or explain a complex
reality
Scientific models
Image sources:
http://www.redorbit.com/education/reference_library/space_1/universe/2574692/geocentric_model/
http://hendrianusthe.wordpress.com/2012/06/21/heliocentric-vs-geocentric/
What is data model?
■ A set of concepts to describe the structure of a database,
the operations for manipulating these structures, and
certain constraints that the database should obey.
■ Structure:
❑ Typically include elements (and their data types) as well as groups of elements
(e.g. entity, record, table), and relationships among such groups
■ Constraints:
❑ Constraints specify some restrictions on valid data; these constraints must be enforced at
all times
What is data model?
■ Operations:
❑ These operations are used for specifying database retrievals and
updates by referring to the structure of the data model.
❑ basic model operations (e.g. generic insert, delete, update)
❑ user-defined operations (e.g. compute_student_gpa,
update_inventory)
Importance of data model
Communication tool
• Facilitate interaction among the designer, the applications
programmer, and the end user
Give an overall view of the database
• End users have different views and needs for data
Importance of data model
Organize data for various users
• Data model organizes data for various users
Are an abstraction for the creation of well-designed good database
• Cannot draw required data out of the data model
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
❑ Many-to-many (M:N or M:M) relationship
❑ One-to-one (1:1) relationship
■ Constraint: a restriction placed on the data
Business Rules
■ Descriptions of policies, procedures, or principles within a
specific organization
❑ Apply to any organization that stores and uses data to generate
information
■ Description of operations to create/enforce actions within an
organization’s environment
❑ Must be in writing and kept up to date
❑ Must be easy to understand and widely disseminated
■ Describe characteristics of data as viewed by the company
Discovering Business Rules
■ Sources of business rules:
❑ Company managers
❑ Policy makers
❑ Department managers
❑ Written documentation
■ Procedures
■ Standards
■ Operations manuals
❑ Direct interviews with end users
Discovering Business Rules (cont’d.)
■ Standardize company’s view of data
■ Communications tool between users and designers
■ Allow designer to understand the nature, role, and scope of
data
■ Allow designer to understand business processes
■ Allow designer to develop appropriate relationship
participation rules and constraints
Translating Business Rules into Data Model
Components
■ Nouns translate into entities
■ Verbs translate into relationships among entities
■ Relationships are bidirectional
■ Two questions to identify the relationship type:
❑ How many instances of B are related to one instance of A?
❑ How many instances of A are related to one instance of B?
Naming Conventions
■ Naming occurs during translation of business rules to data
model components
■ Names should make the object unique and distinguishable
from other objects
■ Names should also be descriptive of objects in the
environment and be familiar to users
■ Proper naming:
❑ Facilitates communication between parties
❑ Promotes self-documentation
Categories of Data Models
■ Conceptual (high-level, semantic) data models:
❑ Provide concepts that are close to the way many users perceive data.
❑ logical nature of data representation; it emphasizes on what entity is presented; it is
used for database design as blueprint
■ (Also called entity-based or object-based data models.)
■ Physical (low-level, internal) data models:
❑ Provide concepts that describe details of how data is stored in the computer. These
are usually specified in an ad-hoc manner through DBMS design and administration
manuals
■ Implementation (representational) data models:
❑ Provide concepts that fall between the above two, used by many commercial DBMS
implementations (e.g. relational data models used in many commercial systems).
Database Models
❑ Conceptual models include
■ Entity-relationship database model (ERDBD)
■ Object-oriented model (OODBM)
❑ Implementation models include
■ Hierarchical database model (HDBM)
■ Network database model (NDBM)
■ Relational database model (RDBM)
■ Object-oriented database model (ODBM)
Database Models (con’t.)
■ Relationships in Conceptual Models
❑ One-to-one (1:1)
❑ One-to-many (1:M)
❑ Many-to-many (M:N)
■ Implementation Database Models
❑ Hierarchical
❑ Network
❑ Relational
❑ Object-Oriented
THE EVOLUTION OF DATA MODELS
Evolution of Database Modals
2000s
1990s
1980s
1970s
1960s
Object oriented ?
Hierarchical
Relational
Client Oriented
Traditional files Object-relational
Network
History of Database Model
■ Hierarchical database model (HDBM)
■ Network database model (NDBM)
■ Relational database model (RDBM)
■ Object-oriented database model (ODBM)
Hierarchical database model (HDBM)
Hierarchical Database Model (HDBM)
■ Logically represented by an upside-down tree
❑ Each parent can have many children (segment linkage)
❑ Each child has only one parent
❑ A single table acts as the "root" of the database from which
other tables "branch" out.
❑ Relationships in such a system are children and parents.
❑ Parents and children are tied together by links called
"pointers
Hierarchical Database Model
■ Logically represented by an upside-down tree
❑ 1:M relationship
Hierarchical Database Model
❑ Hierarchical path (beginning from left)
❑ Left-list hierarchical path, or preorder traversal, or hierarchical
sequence
Final assembly->Component A->Assembly A-> Part
A ->Part B -> Component B -> Component C
–Assembly B -> Part C ->Part D
❑ Re-list sequence, if the segment is frequently accessed
❑ Bank systems commonly use HD model
Hierarchical Database Model
❑ Bank systems commonly use the HDBM
■ customer account can be subject to many
transactions (1:M relationship)
■ Relationship is fixed (debiting and crediting)
■ Frequently access large amount of transactions
Hierarchical Database Model
■ Advantages
❑ Conceptual simplicity: relationship between layers is logically simple;
design process is simple
❑ Database security: enforced uniformly through the system
❑ Data integrity
❑ Data independence
❑ Efficiency in 1:M relationships and when uses require large numbers of
transactions
❑ Dominant in 1970s , when we used mainframe system with large
databases
Hierarchical Database Model
■ Disadvantages
❑ Complex implementation: physical data storage characteristics;
database design is complicated
❑ Difficult to manage and lack of standards
❑ Lacks structural independence
❑ Applications programming and use complexity (pointer based)
❑ Implementation limitations, i.e. especially it only handle 1:M type of
model
Network Database Model (NDBM)
Network Database Model (NDBM)
■ Each record can have multiple parents
❑ Called by Database Task Group (DBTG) to define standards
❑ Three crucial database components
■ Network schema: conceptual organization of the entire database
■ Subschema: portion of database as information for application
programs
■ Database management language: defining data characteristics and
data structure
❑ Schema Data definition language (DDL): define schema components
❑ Subschema Data definition language
❑ Data manipulating language: manipulate data content
Network Database Model
■ Each record can have multiple parents
■ Introduce set to describe relationship
■ Each set has owner record and member record, parallel to parent and child
in HDM
❑ Member may have several owners
❑ One-ownership
■ Hierarchical model is a subset of the network model.
■ The network model uses set theory to provide a tree-like hierarchy.
Network Database Model
❑ Member may have several owners
Network Database Model
■ Advantages
❑ Conceptual simplicity, just lime HDM
❑ Handles more relationship types (but all 1:M relationship)
❑ Data access flexibility
❑ Promotes database integrity
❑ Data independence
❑ Conformance to standards
Network Database Model
■ Disadvantages
❑ System complexity
(Develop by the Computer programmers for the Computer
Programmers rather than user)
❑ Lack of structural independence
Relational Database Model (RDBM)
■ Let’s user or database designer to operate human logical
environment
■ Perceived by user as a collection of tables for data
storage, while let RDBMS handles the physical details.
■ Tables are a series of row/column intersections
■ Tables related by sharing common entity characteristics
■ It allows 1:1, 1:M, M:N relationships
Relational Database Model
Relational Database Model
■ Advantages
❑ Structural independence: data access path is irrelevant to
database design; change structure will not affect the database
❑ Improved conceptual simplicity
❑ Easier database design, implementation, management, and use
❑ Ad hoc query capability with SQL (4GL is added)
❑ Powerful database management system
Relational Database Model
■ Disadvantages
❑ Substantial hardware and system software overhead
❑ Poor design and implementation is made easy
❑ May promote “islands of information” problems
Textbook
Carlos Coronel, Steve Morris, “Database Systems” Design, Implementation,
Management, 12th Ed. Course Technology, 2016”.
Reference book
□ Jeffrey Hoffer, “Modern Database Management ” Design, Implementation, Management,
10th Edition”
□ Thomas Connolly, “Database Systems: A Practical Approach to Design, Implementation
and Management (6th Ed.)”
□ Elmasri, “Fundamentals of Database Systems: (7th Ed.)”
