Scribd
Upload
11 views34 pages

Emtity Attributes

The document discusses the concept of entities in data modeling, defining them as persons, places, objects, events, or concepts that organizations maintain data about. It outlines the characteristics of strong and weak entities, as well as various types of attributes, including required, optional, simple, composite, single-valued, and multi-valued attributes. Additionally, it emphasizes the importance of unique identifiers for entities and provides guidelines for naming and defining them effectively.

Uploaded by

mairabsatti04
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
11 views34 pages

Emtity Attributes

The document discusses the concept of entities in data modeling, defining them as persons, places, objects, events, or concepts that organizations maintain data about. It outlines the characteristics of strong and weak entities, as well as various types of attributes, including required, optional, simple, composite, single-valued, and multi-valued attributes. Additionally, it emphasizes the importance of unique identifiers for entities and provides guidelines for naming and defining them effectively.

Uploaded by

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

• Modeling entities and attributes

Entities
 An entity is a person, a place, an object, an event, or a
concept in the user environment about which the
organization wishes to maintain data.

 Thus, an entity has a noun name


Entities
• Person: Employee, Student, Patient, Teacher, Player, Doctor
• Place: store, Warehouse, Country, city
• object: machine, building, automobile, toy ,furniture
• event: sale, registration, renewal, admission, purchase
• concept: account, course, programming
Naming and Defining entity

• An entity name is a singular noun (such as CUSTOMER, STUDENT, or


AUTOMOBILE)
• An entity name should be specific to the organization. Thus, one
organization may use the entity type name CUSTOMER, and
another organization may use the entity type name CLIENT
Naming and Defining entity

• The entity name should be descriptive and distinct from all other
entity type names within that organization.
– For example, a PURCHASE ORDER for orders placed with
suppliers is distinct from a CUSTOMER ORDER for orders placed
with a company by its customers.
– Both of these entity types cannot be named ORDER.
Naming and Defining entity

• An entity name should be concise, For example, in a university


database, an entity REGISTRATION is better instead of
STUDENT REGISTRATION FOR CLASS

• Event entity should be named for the result of the event, not
the activity or process of the event.
– For example, the event of a project manager assigning an
employee to work on a project results in an ASSIGNMENT
.
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
 An output of the database system (e.g., a
report)
7
entity versus system input, output or user

• a college expense system in which the treasurer


manages accounts, receives expense reports, and
records expense transactions against each account

• However, do we need to keep track of data about


the Treasurer (the TREASURER entity type) and her
supervision of accounts (the Manages relationship)
and receipt of reports (the Receives relationship)?
entity versus system input, output or user

– The Treasurer is the person entering data about


accounts and expenses and receiving expense
reports i.e , she is a user of the database. Because
there is only one Treasurer, TREASURER data do
not need to be kept
entity versus system input, output or user

• Further, is the EXPENSE REPORT entity necessary?


– An expense report is computed from expense
transactions and account balances, it is the result of
extracting data from the database and received by the
Treasurer.
– data needed to compute the report contents each
time are already represented by the ACCOUNT and
EXPENSE entity types.
entity versus system input, output or user
strong entity
• A strong entity type is one that exists independently of other
entity types.
• Examples include STUDENT, EMPLOYEE, AUTOMOBILE, and
COURSE.
• Instances of a strong entity type always have a unique
characteristic (called an identifier)
Weak entity
• A weak entity type is an entity type whose existence
depends on some other entity type.
• A weak entity type has no business meaning in an E-R
diagram without the entity on which it depends
• The entity type on which the weak entity type depends is
called the identifying owner (or simply owner for short).
• A weak entity type does not typically have its own
identifier
• The relationship between a weak entity type and its
owner is called an identifying relationship.)
Example
EXAMPLE OF WEAK AND STRONG ENTITY
EXAMPLE OF WEAK AND STRONG ENTITY
If an attribute name consists of more than one words, we use a space between
the words and we start each word with a capital letter; for example Employee
Name or Student Home Address
Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
 Identifier Attributes
Required versus Optional Attributes

• An attribute that must be present for each


entity instance is called a required attribute,
whereas an attribute that may not have a
value is called an optional attribute.
•
Required versus Optional Attributes
Simple attributes
• A simple (or atomic) attribute is an attribute that cannot be
broken down into smaller components that are meaningful
for the organization.
• For example, all the attributes associated with AUTOMOBILE
are simple: Vehicle ID, Color, Weight,
Composite attributes
• An attribute that has meaningful component parts (attributes).
• Some attributes can be broken down into
meaningful component parts (detailed attributes)
• A composite attribute is an attribute, such as Address, that has
meaningful component parts, which are more detailed attributes.

• The decision about whether to subdivide an attribute


into its component parts depends on whether users will need to
refer to those individual components
EXAMPLE OF COMPOSITE ATTRIBUTE

24
SINGLE VALUED ATTRIBUTE VS
MULTIVALUED ATTRIBUTE
EXAMPLE OF MULTIVALUED ATTRIBUTE

we indicate a multi valued attribute with curly brackets around


the attribute name,

Entity with multivalued attribute (Skill)

Multivalued
an employee can have
more than one skill e.g
php programmer, c++
programmer

26
DERIVED ATTRIBUTE VS STORED ATTRIBUTE
Derived attribute EXAMPLE
If users need to know how many years a person has been employed, that value can be
calculated using Date Employed and today’s date.
derived attribute (Years_Employed)
Derived
from date
employed and current
date

30
IDENTIFIER ATTRIBUTE
 An identifier is an attribute (or combination of attributes) whose
value distinguishes individual instances of an entity type.

 No two instances of the entity type may have the same value for
the identifier attribute.

The identifier for the STUDENT entity type introduced earlier is


Student ID, whereas the identifier for AUTOMOBILE is Vehicle ID.

Notice that an attribute such as Student Name is not a candidate


identifier, because many students may potentially have the same
name, and students, like all people, can change their names.
IDENTIFIER ATTRIBUTE
 For some entity types, there is no single (or atomic) attribute that can serve as
the identifier (i.e., that will ensure uniqueness)

 However, two (or more) attributes used in combination i.e. a composite attribute may
serve as the identifier.

The identifier is boldfaced and underlined

You might also like