Logical Data Modelling PDF

Process & Logical Data
Modeling
BA Certification
This document is to be used as a Reference Guide in
conjunction with the curriculum for the BA training course. This
course material describes the key concepts and topics outlined
in the curriculum. The information contained in this document
is only a brief insight into the topics described.
Jag
BA Certification Process & Logical Data Modeling
Table of Contents
Course Objectives ...........................................................................................................................................4
Course Synopsis ..............................................................................................................................................4
4. Introduction to Logical Data Modeling ...........................................................................................................6
4.1What is a model? .......................................................................................................................................6
4.2 Unified Modeling Language (UML) ...........................................................................................................6
4.3Types of Models ........................................................................................................................................7
4.3.1 Process Models ..................................................................................................................................8
4.3.2 Data Models.....................................................................................................................................11
4.3.3 Object Models .................................................................................................................................13
4.4 Components of a Data Model ................................................................................................................13
4.4.1 Entities .............................................................................................................................................13
4.4.2 Attributes .........................................................................................................................................14
4.4.3 Relationship .....................................................................................................................................14
4.4.4 Unique Identifiers ............................................................................................................................14
4.5 Why is a Logical Data Model important? ...............................................................................................15
5. Logical and Conceptual Modeling.................................................................................................................16
5.1Conceptual Data Model ...........................................................................................................................16
5.1.1 Components ....................................................................................................................................16
5.1.2 Using Conceptual Data Models .......................................................................................................20
5.2Logical Data Model ..................................................................................................................................20
5.2.1 Entity Types .....................................................................................................................................20
5.2.2 Using Logical Data Models...............................................................................................................24
5.3 Logical Data Flow diagram ......................................................................................................................24
5.3.1 Rules for a Logical DFD ....................................................................................................................24
5.3.2 Common errors in a DFD .................................................................................................................25
5.3.3 Conventions .....................................................................................................................................25
5.3.4 Data Normalization ..........................................................................................................................26
6. Transition to UML .........................................................................................................................................26
6.1 UML Diagrams ........................................................................................................................................26
6.2 Use Case Diagram ...................................................................................................................................27
6.3 Activity Diagram .....................................................................................................................................28
Page 2
Information Classification: Internal
6.4 Class Diagram .........................................................................................................................................28

6.5 Significance to BA ...................................................................................................................................29
Page 3
Course Topic: Logical Data Modeling
Course Objectives
 Introduction to Logical Data Modeling

 Logical Data modeling concepts and techniques
 Data Flow Diagrams
Course Synopsis
Logical data modeling is also one of the important tools in the BA tool kit. It is necessary that your
requirements are accurately converted into products and for that Logical data modeling is a very
essential modeling technique.
The course would also touch upon the concepts of logical data modeling and the tools and
techniques required for building a good data model.
This course would give an overview of process modeling and data modeling, and tools and
techniques required for building a strong foundation in Business Analysis.
Pre Requisites: BA introductory course on requirement analysis should have been completed so as
to easily understand the Business Analysis terms.
Class Length: 8 hrs Theory / Case study + 1 hr Evaluation
Page 4
Page 5
4. Introduction to Logical Data Modeling
4.1What is a model?
A data model is a simplification of reality, which usually takes the form of a diagram supported by
textual descriptions.
In Business Analysis, a data model is used to
 Describe the concepts related to a domain

 Identify the relationship between the concepts
 Document and Organize the business data
 Show the data needed/created for a Business Process
4.2 Unified Modeling Language (UML)
Unified Modeling Language, popularly known as UML is a worldwide modeling notation, used to
visually represent various components of a system. It is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive system
UML includes a set of graphic notation techniques to create models of object-oriented software-
intensive systems. Some of the Commonly Used UML symbols are
Actor Use Case
Process / Activity Class
An Actor models a type of role played by an entity that interacts with the subject, but is external to
the subject. Actors don’t necessarily have to be people. They can be anything, which influences or
is influenced by the system. For example, a clock or an external system, etc.
A process or an activity is represented by a rounded rectangle. An activity can represent a step in a

business process, or the entire business process.
Page 6
A Use case is a list of steps, which define the interactions between an actor and a system, to
achieve a goal. A use case is represented by an ellipse.
The classes in a class diagram represent both the main objects and or interactions in the
application and the objects to be programmed.
UML has 14 types of diagrams, segregated into two categories, namely Structural diagrams and
Behavioral diagrams
 Structural Diagrams
o Class Diagram
o Component Diagram
o Composite Structure Diagram
o Deployment Diagram
o Object Diagram
o Package Diagram
o Profile Diagram
 Behavioral Diagrams
o Activity Diagram
o Sequence Diagram
o State Diagram
o Timing Diagram
o Use Case Diagram
o Communication Diagram
o Interaction Overview diagram
UML does not restrict UML element types to a certain diagram type. In general, every UML
element may appear on almost all types of diagrams
4.3Types of Models
Models give a clear understanding of the Business Process. Modeling the Business process allows
better identification and verification of the requirements. The models are normally classified as
follows
o Process Models
o Business Process Models
o Workflow Models
o Use Case Models
Page 7
o Data Flow Diagrams

o Data Models
o Conceptual Model
o Logical Model
o Physical Model
o Object Models
4.3.1 Process Models

Process Model is the description of the Business Area (Business Process) at the type
level. Process Models set the context for building Logical Data Models.
4.3.1.1 Business Process Models
Business Process Modeling (BPM) is the activity of representing the processes of an enterprise, so
that the current process may be analyzed and improved. In short, it is used to model the “AS-IS”
process. They are used to identify
How the company operates
The partners, customers and suppliers of a company
An example for a Business Process model:
Page 8
4.3.1.2 Workflow Models

A workflow can usually be described using formal or informal flow diagramming techniques,
showing directed flows between processing steps. Single processing steps or components of a
workflow can basically be defined by three parameters:
1. Input
2. Transformation Rules / Decisions, which may be carried out by associated human roles,
machines, or combination of both
3. Output
The Algorithms' or Rules' description can only be included when there are several
alternative ways to transform one type of input into one type of output. They are used to identify
o How various tasks interact with each other

o How information flows through a process
o How the actors are involved with each business activity
An example for a Workflow model:
4.3.1.3 Use Case Diagrams
A Use case is a list of steps, which define the interactions between an actor and a system, to
achieve a goal. It is used to identify what is “In Scope” and “Out of Scope” for a project.
An example for a Use Case Diagram:
Page 9
4.3.1.4 Data Flow Diagrams

Data Flow Diagram is a graphical representation of the “flow of data” through a system. It shows
what kind of data would be input to the system, and output from the system.
An example for a Data Flow Diagram:
Page 10
4.3.2 Data Models
A data model is the representation of an organization’s information requirements. They show the
data required for a business process, and the relationship between the entities of the business
process.
4.3.2.1 Levels of Data Modelling

There are three levels of Data Modelling, namely
o Conceptual Model
o Logical Model
o Physical Model
4.3.2.1.1 Conceptual Data Model

A conceptual data model is the high level logical data model. It focuses on how Business “sees” the
data. It is a simple model, which highlights the entities and relationships.
An example for Conceptual Data Model:
4.3.2.1.2 Logical Data Model

A Logical Data Model graphically represents the Business Data requirements. It is built using Entity
Relationship Diagram
An example for Logical Data Model:
Page 11
4.3.2.1.3 Physical Data Model
A Physical Data Model describes the implementation of a Logical Data Model. It includes tables,
columns, keys, data types, validation rules, database triggers, stored procedures, domains, and
access constraints.
An example for a Physical Data Model:
Page 12
4.3.3 Object Models

An object model represents the objects (both Business and Software objects) in an Object
Oriented environment, showing how they are represented, organized, interact with each other
and what are the functions they can do?
The most popular and developed model is a class-based model, as opposed to an object-based
model. In this model, objects are entities that combine state (i.e., data), behavior (i.e., procedures,
or methods) and identity (unique existence among all other objects).
An example for Class Diagram:
4.4 Components of a Data Model

Data model usually consists of the following components
o Entities
o Attributes
o Relationships
o Unique Identifiers
4.4.1 Entities
Entities are the items, for which a Business process requires data. Entities can be thought of as
nouns. For example, employee, customer, system. The commonly used rules for an entity are as
follows:
o Use a noun or a noun phrase

o While naming an entity, use Capitals
o Are always singular
Page 13
o Must have an unique identifier
4.4.2 Attributes
Attributes are the pieces of data, which define an entity. Entities and relationships can both have
attributes. For example: a “CUSTOMER” entity can have an attribute “Customer ID”
4.4.3 Relationship
A relationship captures how entities are related to one another. Relationships can be thought of as
verbs, linking two or more nouns. For example, a “places” relationship exists between a
“CUSTOMER” entity and an “ORDER” entity. Customer places an order. Order is placed by a
customer.
4.4.4 Unique Identifiers

Every entity must have a minimal set of uniquely identifying attributes, which is called the entity's
primary key. They show how each occurrence of an entity can be uniquely identified. For example,
in a “CUSTOMER” entity, “Customer ID” can be chosen as a “Unique identifier”
Page 14
4.5 Why is a Logical Data Model important?

A Logical Data Model captures the important “Business rules” and provides a detailed specification
of the data requirements. A Logical Data Model is important because
 It helps in understanding the business data elements and business requirements

 It provides foundation for designing the database
 It facilitates the avoidance of data redundancy and prevents data & business transaction
inconsistency
 It helps in data re-use and sharing
 It decreases the development and maintenance time and cost
 It establishes a consistent naming scheme.
Page 15
5. Logical and Conceptual Modeling
5.1Conceptual Data Model

We had briefly explained the Conceptual Data Model in the previous chapter. In this Chapter, we
would be looking in depth about the Conceptual Modeling Topics
5.1.1 Components
As described earlier, a Conceptual Model consists of the following components
 Entities
 Attributes
 Relationships
 Unique Identifiers
5.1.1.1 Entities
An entity is a person, place, thing or event for which data is collected and maintained. For example
a library system may contain data about different entities like BOOK and MEMBER.An entity may
be a physical object such as a house or a car, an event such as a house sale or a car service, or a
concept such as a customer transaction or order
How to identify an entity in a Business Process?
An entity can be discovered by identifying the nouns in the description. For example in the
Business Description, “A customer places order for books. After the order is placed, we deliver
them the books and they send us a payment”, the entities are Customer, Order, Books and
Payment
An entity is not usually
 Form or report
 The Business Process itself
 Activities in a Business Process
If your answer is “Yes” for the following questions, then you had discovered a valid entity
 Can the entity be uniquely identified?

 Does it have any relationship with other entity?
 Does it have any significance to the Business Process?
5.1.1.2 Attributes
An attribute is used to describe an entity. For example a Customer entity can have “Customer ID”
and “Customer Name” as attributes
Page 16
How to identify an attribute in a Business Process?
If your answer is “Yes” for the following questions, then you had discovered a valid attribute
 Does it describe the entity?

 Does it apply only to one entity?
 Does it have any significance to the Business Process?
An attribute can be
 Atomic
 Non-Atomic
An atomic attribute represents only one fact (For example, a Customer ID represents a singular
fact, and can be tagged as an atomic attribute), whereas a non-atomic attribute can have multiple
values for a single occurrence (For example the skills which an employee possesses, can have
multiple values)
5.1.1.3 Relationships
A relationship captures how entities are related to one another. Relationships can be thought of as
verbs, linking two or more nouns. Each relationship can be identified by its name and cardinality.
Examples: an “owns” relationship exists between a company and a computer
Relationships are read in clockwise direction. The cardinality is noted at the end of the line.
Cardinalities are usually one of the following
 Zero or one
 Zero or many
 One or many
 One and only one
Consider the following example
The above relationship can be read as
 Each Employee is assigned to zero or one departments
Page 17
 Each department employs one or many employees
Representations of different cardinalities
Zero or one
Zero or many
One and only one
One or many
5.1.1.4 Unique Identifiers

Unique identifiers show how each occurrence of an entity is uniquely identified. Every entity must
have a minimum set of uniquely identifying attributes, which is called the entity's primary key. The
unique identifier can contain one or more attributes. For example, an “Order” entity can have
“Order ID” as the unique identifier.
A unique identifier can be selected by answering the following questions about attributes
 Is the attribute Mandatory or Optional

 Is the attribute Single-valued or Multi-valued
 Is the attribute Unique or Non-Unique
A unique identifier must be mandatory and Single-valued.
Attribute Name Mandatory / Optional Single / Multi Valued Uniqueness
Employee ID Mandatory Single Unique
Employee Name Mandatory Single Not Unique
Employee Skill Mandatory Multi Not Unique
Social Security Number Mandatory Single Unique
A unique identifier must be
 Stable (The value shouldn’t change over time)

 Minimal (Minimum number of attributes should be selected)
Page 18
Concatenated Unique Identifier
If there is no single attribute, which can be identified as a Unique Identifier, two or more attributes
can be combined to create a Unique Identifier. Such Unique Identifiers are named as
Concatenated Unique Identifiers.
In the above example, Order item id alone is not sufficient as a unique identifier for “Order Items”
entity. The addition of Order ID forms the Concatenated Unique Identifier
Surrogate Unique Identifier
A Surrogate Unique Identifier can be used when
 There are no attributes, which can be classified as a Unique Identifier.

 There is more than one candidate for a Unique Identifier, and no candidate key is
obviously preferred.
In the above example, an applicant can have many address, say Office address, Home Address, etc.
Hence none of the columns can be classified as a Unique Identifier.
Hence adding a new Surrogate Unique identifier “Address ID” would solve the problem
Page 19
5.1.2 Using Conceptual Data Models
Conceptual models
 Form the base for a Logical Data Model.

 Are used for developing a high level understanding of a process.
 Become a powerful communication tool with business users
 Is used to communicate core data concepts, rules, and definitions to a business user.
5.2Logical Data Model

We had briefly explained the Logical Data Model in the previous chapter. In this Chapter, we
would be looking in depth about the Logical Modeling Topics
Logical Data Model is a detailed version of the Conceptual Data Model. It can also be called as the
extension of a Conceptual Data Model. It includes all the entities, attributes, relationships,
cardinalities and unique identifiers required for a Business Process.
5.2.1 Entity Types
Entities can be categorized into
 Super type and Subtype

 Attributive entities and Multi valued attributes
 Associative Entity
5.2.1.1 Super type and Sub typing

Super type and Sub types can also be referred to as Generalization and Specialization. A subtype
entity implicitly inherits all the attributes and relationships of a Super type. For example, if a
company has both Contracted employees and regular employees, they can be generalized into a
Super type entity “Employee”
Page 20
Since a sub-type entity inherits all the attributes and relationships from Super-types, unique
identifiers for a sub-type would be the same as that of the super type.
5.2.1.2 Attributive entities and Multi-valued attributes

Attributive entity depends on another entity for its existence. For example, Employee Address
depends on Employee. An attributive entity depends on another entity for parts of its primary
key.
Attributive entities are found out by identifying the multi valued attributes in an entity and moving
them to a new entity, here they have a single value
Steps to create an attributive entity
 Move the multi valued attributes to a new entity

 Name the new entity
 Define a unique identifier
 Show the relationship and cardinality
For example, consider the following entity “LOAN APPLICANT” with the attributes “Applicant ID”,
“Applicant Name”, “Applicant Designation” and “Address”
LOAN APPLICANT
PK Applicant ID
Applicant Name
Applicant Designation
Applicant Address
Applicant ID Applicant Name Applicant Designation Applicant Address Applicant Address
101 JOHN DEVELOPER INAUTIX, 10TH DOOR NO 12, 24TH

FLOOR, TIDEL PARK, STREET, CHENNAI
CHENNAI
102 SMITH MANAGER INAUTIX, 10TH DOOR NO 32, 32ND
Page 21
FLOOR, TIDEL PARK, STREET, CHENNAI

CHENNAI
Multi valued attributes
Move the multi valued attribute “Applicant Address” to a new entity “LOAN APPLICANT ADDRESS”
LOAN APPLICANT ADDRESS
PK Applicant ID
PK Address Type
Building Name
Street Name
City
The new entity name is “LOAN APPLICANT ADDRESS”
The Unique identifiers are Applicant ID, Address Type
The relationship and cardinality are defined as
LOAN APPLICANT ADDRESS is dependent on the entity LOAN APPLICANT (if there were no Loan
Applicants, there would be no Loan Applicant address)
5.2.1.3 Associative Entities

Associative entity describes a connection between two entities with an otherwise many-to-many
relationship. A many to many relationship can be resolved by creating an associative entity. For
example, a customer can place one or more orders from a store; however each order can contain
one or more items. The problem is that there's no way to tie a unique customer order to a unique
Page 22
order item, without the use of an associative entity “Order Item”. The order item table serves to
connect a given order item with a given order:
Item <----> Order Item <----> Order
Let us take one more example of an assignment of Employee to Project (an Employee can be
assigned to more than one Project and a Project can be assigned to more than one Employee).
If we want to find the number of hours booked by a particular employee in a project A, it would
be difficult to find out using the many to many relationship. If information exists about the
relationship, this information is kept in an associative entity.
The above many to many relationship can be resolved by creating an associative entity “PROJECT
ASSIGNMENT”
5.2.1.4 Data Constraints

A Data constraint is used to further describe an attribute. For each attribute, a general data
constraint must be identified. For example, Numeric / String / Alpha Numeric / Currency / Date
Some additional data constraints like list of possible values and length can also be used. The
following example illustrates the usage of data constraints.
Attribute Name General Data Constraint Additional Data Constraint Length
Joining Date Date MM/DD/YYYY
Name String Alphabets, Spaces 20
Amount Numeric $999,999.99
Page 23
5.2.2 Using Logical Data Models

Logical models
 Help common understanding of business data elements and requirements

 Provide a foundation for designing a database
 Facilitates data re-use and sharing
 Decreases development and maintenance time and cost
 Confirms a logical process model and helps impact analysis.
5.3 Logical Data Flow diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through a process,
modelling its process aspects. They form the preliminary step to create an overview of the
process. In short DFD’s are used for visualizing a process. A DFD shows the inputs and outputs
from the system and data store.
A data store represents the data “at rest” in a business process. A data store doesn’t imply any
physical database / cabinet. It doesn’t have information about how the databases are defined and
organized. A data store is usually named in capitals and usually a plural noun. An example for a
data store is given below
5.3.1 Rules for a Logical DFD

Logical DFD’s don’t show
 The sequence of process

 The triggers for a process
 The Database access
They should have at least one input and one output terminal.
Page 24
5.3.2 Common errors in a DFD

 A black hole is a process that has only inputs, but no outputs
 A miracle is a process that has only outputs, but no inputs
 A gray hole is a process where inputs are insufficient to produce outputs
5.3.3 Conventions
 Data cannot flow directly from one process to another
 Data cannot flow between an external agent and a data store
 Data cannot flow directly from one data store to another
Page 25
5.3.4 Data Normalization
 A method of organizing data to reduce or eliminate insertion, deletion and update

anomalies
 Reduces data redundancy
 Increases data integrity
 Can be applied to a logical model to validate and simplify the transition to design
5.3.4.1 Forms
 First Normal Form

o Has no multi valued attributes
 Second Normal Form
o An entity is said to be in 2NF, if it is already in 1NF and its attributes are fully
dependent upon concatenated unique identifier
 Third Normal Form
o An entity is said to be in 3NF, if it is already in 2NF and its attributes are fully
dependent upon unique identifier
6. Transition to UML
6.1 UML Diagrams
As discussed earlier, UML has 14 types of diagrams, segregated into two categories, namely
Structural diagrams and Behavioral diagrams
 Structural Diagrams
o Class Diagram
o Component Diagram
o Composite Structure Diagram
o Deployment Diagram
o Object Diagram
o Package Diagram
o Profile Diagram
 Behavioral Diagrams
o Activity Diagram
o Sequence Diagram
o State Diagram
o Timing Diagram
o Use Case Diagram
Page 26
o Communication Diagram
o Interaction Overview diagram
But the common diagrams used by a BA are Class Diagrams, Activity Diagrams and Use Case
Diagrams.
6.2 Use Case Diagram

Use Case Diagrams describe the functionality provided by a system in terms of actors, their goals
represented as use cases and any dependencies among those use cases. In short, use case diagram
is a graphical representation of a user's interaction with the system and depicting the
specifications of a use case.
A use case is a list of steps, typically defining interactions between a role (actor) and a system, to
achieve a goal. The actor can be a human or an external system.
The structure of a use case would be as follows:
 Use Case Title: The Business goal

 Main Success Scenario: Also called as happy path. It is used to specify all the normal steps
in a process, without exception.
 Exception Scenario: List all the possible steps in case the normal path fails
The actors in the above example are “Employee” and “Manager”. The rectangle represents the
boundary. Everything within the boundary is considered to be “In Scope” and outside the
boundary is “Out of Scope”. The use cases (normally depicted as ellipses) in the above example are
“Apply for Leave”, “Approve Leave” and “Check Leave Balance”.
Page 27
6.3 Activity Diagram

Activity diagrams are the graphical representations of workflows of stepwise activities and actions,
iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to
describe the business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control. Arrows run from the start towards the end and
represent the order in which activities happen.
Activity diagrams are constructed from a limited number of shapes, connected with arrows. The
most important shape types:
 Rounded rectangles represent activities

 Diamonds represent decisions
 Bars represent the start (split) or end (join) of concurrent activities
 A black circle represents the start (initial state) of the workflow
 An encircled black circle represents the end (final state).
In the above example, the activities are “Apply for Leave”, “Send to Manager for Approval”,
“Calculate the new Leave Balance”, “Notify “Leave Rejected” and “Notify Balance not available”.
The arrows represent the sequence flow. The diamond “Check Leave Balance” represents the
decision box.
6.4 Class Diagram

Class Diagram is the Main building block of Object oriented modelling. A Class diagramin the UML
is a type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among the
classes.
Page 28
The classes in a class diagram represent both the main objects and or interactions in the
application and the objects to be programmed. In the class diagram these classes are represented
with boxes which contain three parts
 The upper part holds the Class name

 The middle part contains the Class attributes
 The bottom part gives the methods or operations the class can take
In the above example, the two classes used are “Order” and “Customer”.
6.5 Significance to BA
The Object Oriented approach requires BA’s to make a transition to UML diagrams. Object
Orientation is a common approach to System design and programming. The change for a BA is less
profound. What is important is the degree to which a BA’s deliverables can be used by the
developer.
Page 29

Logical Data Modelling PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Logical Data Modelling PDF

Uploaded by

Copyright:

Available Formats

Process & Logical Data

6.4 Class Diagram .........................................................................................................................................28

Course Topic: Logical Data Modeling

 Introduction to Logical Data Modeling

Class Length: 8 hrs Theory / Case study + 1 hr Evaluation

4. Introduction to Logical Data Modeling

In Business Analysis, a data model is used to

 Describe the concepts related to a domain

4.2 Unified Modeling Language (UML)

Actor Use Case

Process / Activity Class

A process or an activity is represented by a rounded rectangle. An activity can represent a step in a

o Data Flow Diagrams

4.3.1 Process Models

4.3.1.1 Business Process Models

How the company operates

The partners, customers and suppliers of a company

An example for a Business Process model:

4.3.1.2 Workflow Models

o How various tasks interact with each other

An example for a Workflow model:

4.3.1.3 Use Case Diagrams

An example for a Use Case Diagram:

4.3.1.4 Data Flow Diagrams

An example for a Data Flow Diagram:

4.3.2 Data Models

4.3.2.1 Levels of Data Modelling

4.3.2.1.1 Conceptual Data Model

An example for Conceptual Data Model:

4.3.2.1.2 Logical Data Model

An example for Logical Data Model:

4.3.2.1.3 Physical Data Model

An example for a Physical Data Model:

4.3.3 Object Models

An example for Class Diagram:

4.4 Components of a Data Model

o Use a noun or a noun phrase

o Must have an unique identifier

4.4.4 Unique Identifiers

4.5 Why is a Logical Data Model important?

 It helps in understanding the business data elements and business requirements

5. Logical and Conceptual Modeling

5.1Conceptual Data Model

How to identify an entity in a Business Process?

An entity is not usually

 Can the entity be uniquely identified?

How to identify an attribute in a Business Process?

 Does it describe the entity?

Consider the following example

The above relationship can be read as

 Each Employee is assigned to zero or one departments

 Each department employs one or many employees

Representations of different cardinalities

One and only one

5.1.1.4 Unique Identifiers

 Is the attribute Mandatory or Optional

A unique identifier must be mandatory and Single-valued.

Attribute Name Mandatory / Optional Single / Multi Valued Uniqueness

Employee ID Mandatory Single Unique

Employee Name Mandatory Single Not Unique

Employee Skill Mandatory Multi Not Unique

Social Security Number Mandatory Single Unique