28 terms

Data Modeling

STUDY
PLAY

Terms in this set (...)

Conceptual Design : Purpose
- To understand an organization's data needs and how that
data is related to each other
- To document the data needs in form of an Entity-relationship
diagram (ERD) for database designers
Conceptual Design :Data-centric approach
- Data is more stable than business processes, which may
change as business evolves
- Accurate data is critical for operations
Conceptual Design : Output
ERD or similar model
Conceptual Design : Goal
Create an Entity-Relationship Diagram (ERD)
Entity-relationship Model : Definition
A visual representation of entities, their attributes, and the
relationships between entities
Entity
People, places, objects, things, events, or concepts
about which data is being collected
Attribute
Property or characteristics of entities
Relationship
Business rules governing associations
between entities
Identifier
One or more attributes
is a unique identifier
Candidate keys
All
attributes that can
uniquely identify an
entity instance
Composite key
candidate key of
multiple attributes
Primary key
The
chosen candidate key, Should not change over
time, Must have non-null
unique values
Types of Relationships
-Binary (Relationship between two different entities)
-Unary (Recursive relationship between instances of the same entity)
-Ternary (Relationship among three different entities)
Cardinality
How many instances of one entity are associated with an
instance of the other entity? Maximum, Outer symbol on the relationship
Modality
Can an instance of an entity exist without a related instance
of the other entity? Minimum, Inner symbol on the relationship
One-to-one (1:1) relationship
One instance of an entity is related to only one instance of
another entity (and vice versa)
One-to-many (1:N) relationship
One instance of an entity is related to many instances of
another entity
Many-to-many (M:N) relationship
Many instances of one entity can be related to many
instances of the other entity
| in modality
mandatory
0 in modality
optional
| in cardinality
one
< in cardinality
many
Mandatory
An instance in the related entity must exist for an instance in
the other entity
Optional
No instance in the related entity is necessary for an instance
in the other entity
Intersection Data
Some (M:N) relationships can have their own attributes
Associative Entity
When there is a many-to-many relationship, there is
always an "intersection" entity, where intersection data is stored, reversed cardinality and modality
Strong entity
Can exist independently
Weak (dependent) entity
Cannot exist without an "owner" or strong entity