0% found this document useful (0 votes)
21 views30 pages

CSE303 Lecture03-04 ERD01 2023

Uploaded by

hasnainkabir74
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views30 pages

CSE303 Lecture03-04 ERD01 2023

Uploaded by

hasnainkabir74
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 30

Departmen Computer

CSE Science
t of &Engineering

Entity Relationship Diagram

Lecture 03-04
CSE 303: Database Management
System
Importance of Data Model
● The characteristics of data captured during data modeling
are crucial in the design of databases, programs, and other
system components. The facts and rules captured during
the process of data modeling are essential in assuring data
integrity in an information system.
● Data rather than processes are the most complex aspect of
many modern information systems and hence require a
central role in structuring system requirements.
● Data tend to be more stable than the business processes
that use that data.
THE E-R MODEL
● Entity-relationship model (E-R model)

A logical representation of the data for an


organization or for a business area, using entities for
categories of data and relationships for associations
between entities.
● Entity-relationship diagram (E-R diagram, or ERD)

A graphical representation of an entity-relationship


model.
Sample E-R diagram
Entities
● A person, a place, an object, an event, or a concept
in the user environment about which the
organization wishes to maintain data.

● Entity type A collection of entities that share


common properties or characteristics.
● Entity instance A single occurrence of an entity type.

● Strong entity type An entity that exists


independently of other entity types.

● Weak entity type An entity type whose existence


depends on some other entity type.
Entity Types
What Should an Entity Be?
● SHOULD BE:

● An object that will have many instances in the


database
● An object that will be composed of multiple attributes
● An object that we are trying to model
● SHOULD NOT BE:

● A user of the database system


● Input, output of the database system (e.g. a report)
System user
System output
Naming Entity Type
● An entity type name is a singular noun. E.g. CUSTOMER,
STUDENT
● An entity type name should be specific to the organization.
CUSTOMER or CLIENT
● An entity type name should be concise. REGISTRATION vs
STUDENT REGISTRATION FOR CLASS
● An abbreviation, or a short name, should be specified for each
entity type name.
should be named for the result of the
● Event entity types
event, not the activity or process of the event.
● The name used for the same entity type should be the same on
all E-R diagrams on which the entity type appears.
Attributes
A property or characteristic of an entity or
relationship type that is of interest to the
organization.
● REQUIRED VERSUS OPTIONAL ATTRIBUTES
● Required attributeAn attribute that must have a
value for every entity (or relationship) instance
with which it is associated.
● Optional attributeAn attribute that may not have a
value for every entity (or relationship) instance
with which it is associated.
Attributes
● SIMPLE VERSUS COMPOSITE ATTRIBUTES
● Simple (or atomic) attribute An
attribute that cannot be broken
down into smaller components that are meaningful to
the organization.
● Composite attribute An
attribute that has meaningful
component parts (attributes).
● SINGLE-VALUED VERSUS MULTIVALUED ATTRIBUTES
● Multivalued attribute An
attribute that may take on more than
one value for a given entity (or relationship) instance.
● STORED VERSUS DERIVED ATTRIBUTES

● Derived attribute An
attribute whose values can be calculated
from related attribute values.
Attributes
Identifiers (Keys)
● Identifier (Key) - An attribute (or combination of
attributes) that uniquely identifies individual
instances of an entity type
● Simple Key versus Composite Key
● Composite identifier An identifier that consists of a
composite attribute.
● Candidate Key – an attribute that could be a
key…satisfies the requirements for being a key
Composite attribute

An attribute
broken into
component parts
Simple key attribute
Composite key attribute
Multivalued and derived attribute
Criteria for selecting identifiers
● will not change its value over the life of each instance
of the entity type.
● Guaranteed to have valid values and not be null (or
unknown).
● Avoid the use of so-called intelligent identifiers (or
keys), whose structure indicates classifications,
locations, and so on. (e.g. containing locations or
people that might change)
● Substitute single-attribute surrogate identifiers for
large composite identifiers.
NAMING AND DEFINING ATTRIBUTES
● An attribute name is a singular noun or noun phrase (such as
Customer ID, Age, Product Minimum Price, or Major).
● An attribute name should be unique.
● To make an attribute name unique and for clarity
purposes, each attribute name should follow a standard format.
● Similar attributes of different entity types should use the same
qualifiers and classes, as long as those are the names used in
the organization.
Guidelines for defining attributes
● what the attribute is and possibly why it is important

● what is included and not included

● aliases,

● the source of values for the attribute

● if a value for the attribute is required or optional

● whether a value for the attribute may change

● the maximum and minimum number of occurrences of an


attribute value for an entity instance
● any relationships that attribute has with other attributes
Job of Data Analyst
● Identify, collect and understand business rules that

govern data.
● Represent those rules so that they can be

unambiguously understood by information systems


developers and users
● Implement those rules in database technology
Business Rules
● Business rules, the foundation of data models, are derived from
policies, procedures, events, functions, and other business
objects, and they state constraints on the organization.
● Business rules represent the language and fundamental
structure of an organization.
● Business rules formalize the understanding of the organization
by organization owners, managers, and leaders with that of
information systems architects.
● Business rules are important in data modeling because they
govern how data are handled and stored.
● Business rules and policies are not universal.
Business Rule: Overview
● A statement that defines or constrains some aspect of the business. It is

intended to assert business structure or to control or influence the


behavior of the business.
● Business rules are a core concept in an enterprise because they are an

expression of business policy and guide individual and aggregate


behavior.
● Business rules can be expressed in terms that are familiar to end users.

● Business rules are highly maintainable.

● Enforcement of business rules can be automated through the use of

software that can interpret the rules and enforce them using the
integrity mechanisms of the database management system.
Good Business Rules:
● Declarative – what, not how

● Precise – clear, agreed-upon meaning

● Atomic – one statement

● Consistent – internally and externally

● Expressible – structured, natural language

● Distinct – non-redundant

● Business-oriented – understood by business

people
Data Name
● Relate to business

● Be meaningful

● Be unique

● Be readable

● Be composed of words taken from an approved

list
● Be repeatable

● Follow a standard syntax


Data name development process
● Preparing a definition of the data.

● Removing insignificant or illegal words note that the


presence of ‘AND’ and ‘OR’ in the definition may imply
that two or more data objects are combined, and you
may want to separate the objects and assign different
names.
● Arranging the words in a meaningful, repeatable way

● Assigning a standard abbreviation for each word.

● Determining whether the name already exists, and if so,


adding other qualifiers that make the name unique.
DATA DEFINITIONS
● A definition is an explanation of a term or a fact.
● Term A word or phrase that has a specific meaning
for the business.
● Fact An association between two or more terms.
● Definitions (and all other types of business rules) are gathered
from the same sources as all requirements for information
systems.
● Definitions will usually be accompanied by diagrams, such as
entity-relationship diagrams.
● Definitions will be stated in the singular and explain what the
data is, not what it is not.
● A data object should not be added to a data model, such as an
entity-relationship diagram, until after it has been carefully
defined (and named) and there is agreement on this definition.
Multiple definition accommodation
● Use multiple definitions to cover the various

situations.
● Use a very general definition that will cover most

situations.
● Consider using multiple, related, data objects for

definition.
Business rules
Thank You

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy