DBSYS1
Data Models
Objectives
This chapter examines data modeling.
Data modeling is the first step in the database design journey,
serving as a bridge between real-world objects and the computer
database.
Learn some basic data-modeling concepts and how current data
models have developed from earlier models.
Development of those database models will help you understand the
database design and implementation
Ready in 1.. 2.. 3..
Data Modeling and Data Models
Database design focuses on how the database structure will be used
to store and manage end-user data
Process of creating a specific data model for a determined problem
domain
Data model is a relatively simple representation, usually graphical, of
more complex real-world data structures.
Data modeling is an iterative,
progressive process
An implementation-ready data model should contain at least the
following components:
A description of the data structure that will store the end-user data.
A set of enforceable rules to guarantee the integrity of the data.
A data manipulation methodology to support the real-world data
transformations.
The Importance of Data Models
Facilitate interaction among the designer, the applications
programmer, and the end user
Improved understanding of the organization for which the database
design is developed
“Data is viewed in different ways by different people”
“Applications programmers have yet another view of data”
Data Model Basic Building Blocks
Basic Building Blocks:
Entities
Attributes
Relationships
Constraints
Relationships
Relationship describes an association among entities
Relationship exists between customers and agents that can be
described as follows: an agent can serve many customers, and each
customer may be served by one agent
Three Types:
one-to-many,
many-to-many, and
one-to-one
Database designers usually use the shorthand notations 1:M or 1..*, M:N or *..*,
and 1:1 or 1..1, respectively
More on relationships
One-to-many (1:M or 1..*) relationship.
A painter creates many different paintings, but each is painted by
only one painter. Thus, the painter (the “one”) is related to the
paintings (the “many”). Therefore, database designers label the
relationship “PAINTER paints PAINTING” as 1:M. Note that entity
names are often capitalized as a convention, so they are easily
identified. Similarly, a customer (the “one”) may generate many
invoices, but each invoice (the “many”) is generated by only a single
customer. The “CUSTOMER generates INVOICE” relationship would
also be labeled 1:M.
More on relationships
Many-to-many (M:N or *..*) relationship. An employee may learn
many job skills, and each job skill may be learned by many
employees. Database designers label the relationship “EMPLOYEE
learns SKILL” as M:N. Similarly, a student can take many classes and
each class can be taken by many students, thus yielding the M:N
label for the relationship expressed by “STUDENT takes CLASS.”
More on relationships
One-to-one (1:1 or 1..1) relationship. A retail company’s management
structure may require that each of its stores be managed by a single
employee. In turn, each store manager, who is an employee,
manages only a single store. Therefore, the relationship “EMPLOYEE
manages STORE” is labeled 1:1
More on relationships
The preceding discussion identified each relationship in both
directions; that is, relationships are bidirectional:
One CUSTOMER can generate many INVOICEs.
Each of the many INVOICEs is generated by only one CUSTOMER.
Constraints
A constraint is a restriction placed on the data. Constraints are
important because they help to ensure data integrity. Constraints are
normally expressed in the form of rules:
An employee’s salary must have values that are between 6,000 and
350,000.
A student’s GPA must be between 0.00 and 4.00.
Each class must have one and only one teacher.
Remember
Computer Views
data as Physical
View
Human Views data
as Logical View
Standard Formats For Data Modeling (Opening
to Create Entity Relationship Diagram(Chapter
4)
Chen's notation/Model
- The Chen's ERD notation is still used and is considered
to present a more detailed way of representing entities and
relationships.
Crow’s Foot/ Model
- represent entities as boxes, and relationships as lines between
the boxes. Different shapes at the ends of these lines represent
the cardinality of the relationship.
This section will continue on our next the its topic
“tamang panahon XD”
More on Data Models Sample
More on Data Models Sample
Parts of Data Models (Advance)
Relationship
Degree
Entity
Relationship
Name
Relationship
Parts of Data Models (Advance)
Cardinality
Entity
Attributes
Connectivit
y
Relationship Name
What is Cardinality
and Connectivity?
Cardinality– expresses the
minimum and maximum
number of entity occurrences
associated with one occurrence
of the related entity.
Connectivity – describes the
classification of the
relationship between entities:
1:1, 1:M, or M:M.
To end your sufferings,
joke, lets breather and
break for a while in
DBSYS1 :D
Questions?
