LESSON 2:

CONCEPTUAL DESIGN
Coronel and Morris, 2015, chapter 9
Hoffer et al., 2019, Part II, chapter 2
Conceptual Design
 Goal: Build a conceptual model to represent objects of a given
problem domain (entities, attributes, relationships, and constraints)
 Definition: The process of constructing a data model used in an
enterprise, independent of all physical considerations using the
information documented in the users’ requirements specification.
 Output: A conceptual model, which is a source of information for the
logical database design.
 Tools: Data models (ER), ER editors (Visio, …)

2
Conceptual Design
 Criteria:
o Software- and hardware- independent
o Provide a clear comprehension of the business and its functional areas
o The collection of data becomes meaningful only when business rules are
defined.
o Minimum Data Rule:

3
Conceptual Design
 Recall: Business rules
o Brief and precise description of a policy, procedure, or principle within a
specific organization’s environment
o Business rules, derived from a detailed description of an organization’s
operations
 Example
o A customer may make many payments on an account.
o Each payment on an account is credited to only one customer.
o A customer may generate many invoices.
o Each invoice is generated by only one customer

4
Conceptual Design Process

5
Conceptual Design
Step 2: ER modeling and normalization
oObjective: All objects (entities, attributes, relations, views, and so on)
are defined in a data dictionary, which is used in tandem with the
normalization process to help eliminate data anomalies and
redundancy problems.
oOutput: Refined (E) ERD
oTools: Data models, Graphical editors

7
Conceptual Design
Step 2: ER modeling and normalization

8
Conceptual Design
Step 2: ER modeling and normalization
oResponsibilities of a designers (define & decide):
• Define entities, attributes, keys, and relationships
• Make decisions about adding new key attributes
• Make decisions about the treatment of composite and multivalued attributes
• Make decisions about adding derived attributes to satisfy processing
requirements

9
Conceptual Design
Step 2: ER modeling and normalization
oPoints to remember:
• Avoid unnecessary ternary relationships.
• Draw the corresponding ER diagram.
• Normalize the entities.
• Include all data element definitions in the data dictionary.
• Make decisions about standard naming conventions.

10
Conceptual Design
Step 2: ER modeling and normalization
oRecall: Naming Conventions
• Facilitates communication between parties
• Promotes self-documentation
• Entity name requirements
• Attribute name requirements
• Relationship name requirements

11
Conceptual Design
Step 2: ER modeling and normalization
oRecall: Naming Conventions
• Facilitates communication between parties
• Promotes self-documentation
• Entity name requirements
A singular noun or noun phrase
Specific to the organization (e.g., Customer or Client)
Clear and descriptive
Familiar to the users
Concise (as few words as possible)
Consistent

12
Conceptual Design
Step 2: ER modeling and normalization
oRecall: Naming Conventions
• Facilitates communication between parties
• Promotes self-documentation
• Entity name requirements
• A singular noun or noun phrase
Unique for clarity purposes  Follow a standard format
[Entity type name { [ Qualifier ] } ] Class
Defined using the same qualifiers and classes with other similar attributes of
different entity types

13
Conceptual Design
Step 2: ER modeling and normalization
oRecall: Naming Conventions
• Facilitates communication between parties
• Promotes self-documentation
• Entity name requirements
• A singular noun or noun phrase
• Relationship name requirements
Be a verb or verb phrase
Represent business rules in a meaningful manner
Indicate the action taken (or interaction) rather than the action results or process
void vague names (e.g., Has, Is related to, …)

14
Conceptual Design
Step 2: ER modeling and normalization

15
Conceptual Design
Step 3: Data model verification
o Objective: Verify the conceptual model against the proposed system processes
to ensure they can be supported by the data model by running series of tests:
• End-user data views
• Required transactions (select, insert, delete, update)
• Access rights and security
• Business requirements and constraints
o Output: Verified data model

16
Conceptual Design
Step 3: Data model verification

17
Design case #1
Attributes OR Entities/Relationships?
oComposite attribute vs. Entity

18
Design case #1
Attributes OR Entities/Relationships?
oMulti-valued attribute vs. Entity?

19
Design case #1
Attributes OR Entities/Relationships?
oMulti-valued, Composite attribute vs. Entity?

20
Design case #1
Attributes OR Entities/Relationships?
oAttributes could be modeled as entity/relationship when:
• Have Identifiers
• Be shared by multiple entity instances
• Defined by a set of sub-attributes with implicit dependence, typically forming
a new implicit entity

21
Design case #2
Relationship OR Associative Entity

22
Design case #2
Relationship OR Associative Entity
o Relationship should be converted to associative entity when:
• Binary M-N relationships
Have business meaning independent of other entities
Have an identifier, and should also have other attributes
• Ternary relationships
o The associative entity may participate in other relationships other than
the entities of the associated relationship

23
Design case #3
Selecting Identifiers (Primary Keys)
o Identifiers (Primary Keys): Aim to guarantee entity integrity, not to
“describe” the entity.
o Guidelines for selecting Identifiers
• Unique values (uniquely identify each entity instance)
• Not intelligent (not have embedded semantic meaning)
• No change over time (be permanent and unchangeable)
• Preferably single-attribute (minimum set of attributes)
• Preferably numeric (for better managed)
• Security-compliant (not be considered as a security risk)

24
Design case #3
Selecting Identifiers (Primary Keys)
o Natural Identifiers
• Real-world identifiers to uniquely identify a real-world object (e.g., social security number,
phone number).
• Useful when there are no suitable primary keys available
o Composite Identifiers
• A set of attributes to uniquely identify an entity instances
• Useful when identifying:
Associative Entities
M-N Relationships
Weak Entities

25
Design case #3
Selecting Identifiers (Primary Keys)
o Surrogate Identifiers
• Key generated by systems to simplify the identification of entity instances.
• Have no meaning outside of the system  Should not be included in the conceptual
model
Identifier for the Event?
(DATE, TIME_START, ROOM) or (DATE, TIME_END, ROOM)
 Surrogate key possible

26
Design case #4
Implementing 1-1 Relationship

(0,1)-(1,1)

(0,1)-(0,1)

(1,1)-(1,1)
27
Design case #5
Maintaining History of Time-Variant Data
o Time-variant data refers to data whose values change over time  must keep a
history of the data changes.
o Solution : Create a new entity in a (1:M) / (M:N) relationship with the
original entity

28
Design case #6
Resolving Fan Traps Problem
o Fan Traps: Where a model represents a relationship between entity types, but
the pathway between certain entity occurrences is ambiguous.

How to know which members of staff work at a particular

29
Design case #7
Resolving Chasm Traps Problem
o Chasm Traps: Where a model suggests the existence of a relationship between
entity types, but the pathway does not exist between certain entity occurrences

At which branch is property number PA14 available?

30
Design case #8
Resolving Recurrency Problem
o Redundant relationships occur when there are multiple relationship paths
between related entities.
o Main concerns: Consistency in the data model  Redundant relationship
may be eliminated?

31
32