0% found this document useful (0 votes)
3 views

ch 3 data modeling

Chapter 3 of BACS3183 focuses on data modeling, describing its importance in database design and the various types of data models including relational, object-oriented, and semi-structured models. It outlines the ANSI-SPARC framework for data abstraction and discusses the entity-relationship model, early data models, and integrity constraints in relational databases. The chapter also highlights the flexibility and advantages of semi-structured data models like JSON and XML in representing complex and dynamic data.

Uploaded by

ngyx-wp22
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

ch 3 data modeling

Chapter 3 of BACS3183 focuses on data modeling, describing its importance in database design and the various types of data models including relational, object-oriented, and semi-structured models. It outlines the ANSI-SPARC framework for data abstraction and discusses the entity-relationship model, early data models, and integrity constraints in relational databases. The chapter also highlights the flexibility and advantages of semi-structured data models like JSON and XML in representing complex and dynamic data.

Uploaded by

ngyx-wp22
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

BACS3183

Advanced Database Management


Chapter 3
Data Modeling
Learning Outcomes
• Compare and contrast appropriate data
models.
• Describe concepts in conceptual modeling
notation.
• Describe the main concepts of the relational,
object-oriented and semi-structured data
models.
1. Data Modeling
• Data Modeling
– the first step in designing a database
– the process of creating a specific data model for an
information system.
– an iterative and progressive process
Importance of Data Models
• Data models can facilitate interaction among the designer, the
applications programmer, and the end user.
• A well-developed data model can foster improved understanding
of the organization for which the database design is developed.
• Give an overall view of the database
• Organize data for various users
• Are an abstraction for the creation of good database
Data Modeling
• Data model is a collection of concepts for describing
– a structural part
– a manipulative part - types of operation that are
allowed on the data
– possibly a set of integrity rules which ensures that
the data is accurate.
Database system: Design, Implementation & Management, Rob & Colonel
Data Modeling
ANSI-SPARC ( American National Standards Institute, Standards
Planning And Requirements Committee) defined a framework for
data modeling based on degrees of data abstraction

Most modern commercial DBMS are based on this framework.


Data Modeling
• External model:
– End-user view of the data
environment
– Can be many different models
• Conceptual model
– Describes what data to be stored
used in an enterprise,
independent of all physical
considerations.
– Describes the relationships among
data.
• Internal model
– How the data are stored.
– Complex low-level structures
described in detail. 8
ANSI-SPARC Architecture and Database Design
 Three phases of database design:
- Conceptual database design
- Logical database design
- Physical database design.
2. The Entity-Relationship Model
• An entity is a distinguishable
object that exists.
• a person, a place, an item, an
event, or a concept in the
user environment about
which the organization
wishes to maintain data
• Each entity contains a set
of attributes - Properties or
characteristics of an entity
• A relationship is an
association among several
entities.
Basic E-R Model

Entity Attribute
symbols symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
3. Early Data Models
Hierarchical model
Represented by an upside-down “tree”
It contains Levels or Segments
It depicts a set of one-to-many (1:M) relationships
between parent and its children segments.

12
Network model
Created to represent complex data relationships more
effectively than the hierarchical model, to improve
database performance and to impose database standard.

supports
many-to-many
relationship

• data are stored in rigid, predetermined relationships.


• no DDL existed, changing the structure of the data was difficult.
• lacked a simple query language, which hindered application
13
development.
4. Relational Model
• Data and relationships are represented by a collection
of tables.
• Each table has a number of columns with unique names,
called as attributes.
• Degree is the number of attributes in a relation.
• Cardinality is the number of tuples in a relation.

14
• User sees the DB as a collection of tables in which data is
stored.
• Each table is independent from another.
• Rows in different tables are related based on common
values in common attributes
Relational Model - Integrity Constraints
• Three basic types
• Entity integrity, not allowing multiple rows to have the
same identity within a table.
 Primary key
• Domain integrity, restricting data
 predefined data types, e.g.: dates.
 Set allowable values
Eg CREATE DOMAIN PriceChange AS DECIMAL
CHECK (VALUE BETWEEN .001 and .15);
• Referential integrity, requiring the existence of a related row
in another table, e.g. a customer for a given customer ID.
 Foreign key

16
5. Object-Oriented Model
• Object is an abstraction of a real-world entity
• An object includes information - attributes/state,
operations/behavior, and identity.
• Attributes/state describe the properties of an object
• Behavior/operation specity how an object acts and reacts
• Objects that share similar characteristics are grouped in classes
Object-Oriented Model
• Classes are organized in a class hierarchy.
• Inheritance: object inherits methods and attributes of parent class
Object-Oriented Model

Aggregation and Composition

Composition Aggregation

1 1 1..3 1
Name Student Address

19
UML
Object-oriented modeling is commonly represented
using UML
Why OO?
• Conventional data models (e.g., relational) are
inadequate
– Cannot model complex data and unstructured
data
– Cannot model processes (dynamic behaviour)
– Does not support reuse

• OO model is a more ‘natural’ way to represent the


real world
6. Semi-Structured Data Model
• Structured data
– Represented in a strict format

• Semi-structured data
– Has a certain structure
– structure may not be rigid, regular, or complete
– Eg. scientific data, E-Catalogs
• Unstructured data
– Very limited indication of the type of data
– Eg. text document containing maps, images, sound,
and video segments
Semi-Structured Data Model
• Semi-structured data
IMDb – A Motivating Example
• The Internet Movie Database is a classical example of
a collection of semi-structured data
• Although the information pertaining to different
movies may be essentially similar, their structure may
be different!

www.imdb.com
Irregularity In Structure
• Example: Some movie
may annotate information
about the actors,
choreographer, director
and producer, while
another movie may
annotate additional
information about the
lyricist and the music
director
Irregularity In Structure
• Example: An actor’s name
may be represented as a
– string or
– as a tuple (first_name,
last_name)

• When data are added to


the database dynamically,
the structure of the
database as a whole, also
keeps changing
Semi-Structured Data Model
JSON, XML, other markup languages, email are all forms of
semi-structured data.
JSON & JSON Data Schema
{ "id": 1,
"name": "Foo", JSON Data Schema
"price": 123,
"tags": {
"Bar",
"Eek"
],
"stock": {
"warehouse": 300,
"retail": 20
}
}

JSON data schema


• defines the structure of JSON data.
• define validation, documentation,
hyperlink navigation, and
interaction control of JSON data
Semi-Structured Data Model
• The advantages of this model :
– can represent the information of data sources that cannot
be constrained by schema.
– It provides a flexible format for data exchange between
different types of databases.
– The schema can easily be changed.

http://en.wikipedia.org/wiki/Semi-structured_data
http://en.wikipedia.org/wiki/Semi-structured_model
Comparison with Relational Data
• Inefficient: tags which represent
{ "id": 1,
schema information, are repeated "name": "Foo",
• Better than relational tuples as a "price": 123,
"tags": {
data-exchange format "Bar",
–Unlike relational tuples, "Eek"
XML/JSON data is self- ],
documenting due to use of tags "stock": {
"warehouse": 300,
–Non-rigid format: tags can be "retail": 20
added ie schema can easily be }
changed. }
- Allows nested structures
–Wide acceptance, not only in
database systems, but also in
browsers, tools, and applications
1

References
• Database Systems: A Practical Approach to
Design, Implementation and Management.
Connolly, T. M. and Begg, C. E. .
• Modern Database Management.Hoffer, J.A.,
Prescott, M., and McFadden,F.
• Database System Concepts . Silberschatz, A.,
Korth, H,. and Sudarshan, S.
• Fundamentals of Database Systems.
Elmasri, R. and Navathe, S.B.

You might also like