1. Database Design & Mapping
Database Application SAK 3408
Database Design & Mapping

2. Database System Design
User views
of data.
Conceptual
data model.
Implementation
(relational)
data model.
Physical
data
storage.
Class diagram that shows business entities, relationships, and rules.
Indexes and storage methods to improve performance.
List of nicely-behaved tables. Use data normalization to derive the list.

3. The Need for Design
Goal: To produce an information system that adds value for the user
Reduce costs
Increase sales/revenue
Provide competitive advantage
Objective: To understand the system
To improve it
To communicate with users and IT staff
Methodology: Build models of the system

4. Designing Systems Designs are a model of existing & proposed systems
They provide a picture or representation of reality
They are a simplification
Someone should be able to read your design (model) and describe the features of the actual system.
You build models by talking with the users
Identify processes
Identify objects
Determine current problems and future needs
Collect user documents (views)
Break complex systems into pieces and levels

5. Design Stages Initiation Physical Design Requirements Analysis
Scope
Feasibility study
Cost & Time estimates
Requirements Analysis
User Views & Needs
Forms
Reports
Processes & Events
Entity & Attributes
Conceptual Design
Models
Data flow diagram
Entity Relationships
Objects
User feedback
Physical Design
Table definitions
Application development
Queries
Forms
Reports
Application integration
Data storage
Security
Procedures
Implementation
Training
Purchases
Data conversion
Installation
Evaluation & Review

6. Initial Steps of Design
1. Identify the exact goals of the system.
2. Talk with the users to identify the basic forms and reports.
3. Identify the data items to be stored.
4. Design the classes (tables) and relationships.
5. Identify any business constraints.
6. Verify the design matches the business rules.

7. Business Rule
BR are important in data modelling because they govern how data are – handled and stored.
Basic BR :
Data names
Data definition
Names and definition must provide for :
Entity types
Attribut
Relationship

8. Guideline Data Names Relate to business – customer \ File10
Be meaningful – avoid is, it, has
Be unique – homeadd, campusadd
Repeatable–studbirthdate, stafbirthdate

9. Data Definition
“ A course is a module of instruction in a particular area.”
“A customer may request a model car from a rental branch in a particular date.”
Guideline :
A definition will state such characteristics of the data objects.
Whether the data is singular or plural
Who determine the value for the data
Whether data is static or changes over time
Whether the data is optional or an empty
Where, when and how data is created.

10. The E-R Model
E-R model – a logical representation of the data for an organization or for a business area
E-R diagram – a graphical representation of an entity-relationship model

11. E-R Model Constructs
Entity
Attribute
Relationship

12. Figure 2.4 Basic E-R Notation
A special entity that is also a relationship
Entity symbols
Attribute symbols
Relationship symbols

13. Figure 2.3 Sample E-R Diagram

14. Entity
An entity is a person, place, object, event or concept in the user environment about which the organization wishes to maintain data. Ex:
Person – EMPLOYEE, STUDENT, PATIENT
Place – STORE, WAREHOUSE, STATE
Object – MACHINE, BUILDING, AUTOMOBILE
Event – SALE, REGISTRATION, RENEWAL
Concept – ACCOUNT, COURSE
Entity type, entity instances, strong entity, weak entity

15. Entity Type vs. Entity Instance
Share common characteristic
Given a name (CAPITAL LETTER)
Rectangle
Collection of entities (often corresponds to a table). Ex: EMPLOYEE
Entity Instances
a single occurrence of an entity type (often corresponds to a row in a table)
Ex: may be 100 of instances of entity EMPLOYEE stored in database.

16. Entity Type vs. Entity Instance (cont.)
Entity Type : EMPLOYEE
Attribut : EMP_NUM CHAR(10)
NAME CHAR(25)
STATE CHAR(35)
2 instances of EMPLOYEE :
Ali Amir
Perak Kedah

17. Strong vs. Weak Entity Types
Strong Entity Type
entity that exists independently of other entity types
Unique characteristic
Called an identifier
Ex: STUDENT, EMPLOYEE
Weak Entity Type
entity type whose existence depends on some other entity type
No meaning in ERD without strong entity.

18. Figure 2.10 Strong and weak entities
Identifying relationship
Strong entity
Weak entity

19. Attribute
property or characteristic of an entity type (often corresponds to a field in a table)
Ex:
entity type – STUDENT
Attributes – name, add, id, program
Simple att vs composite att.
Single-valued att vs multivalued att
Stored att vs derived att
Identifier att.

20. Simple vs. Composite Attribute
Simple attribute – cannot broken into smaller components
Composite attribute – can broken into component parts

21. Simple key attribute
The key is underlined

22. a) Composite attribute
An attribute broken into component parts

23. b) Composite key attribute
The key is composed
of two subparts

24. Single-Valued vs. Multivalued Attribute
Single-Valued – each of the attributes has one value
Multivalued – attribute more than one value

25. Entity with a multivalued attribute (Skill)
an employee can have
more than one skill

26. Stored vs. Derived Attributes
Stored attribute – data input or set
Derived Attribute – attribute whose values can be calculated from related attribute values.

27. Entity with a derived attribute (Years_Employed)
from date employed and current date

28. Identifiers (Keys)
Identifier (Primary Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type
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

29. Characteristics of Identifiers
Will not change in value
Will not be null
No intelligent identifiers (e.g. containing locations or people that might change)
Substitute new, simple keys for long, composite keys

30. Ex: identifier
The key is composed
of two subparts

31. Relationship Relationship
link between entities (corresponds to primary key-foreign key equivalencies in related tables)

32. Relationships (cont.) Relationship Types vs. Relationship Instances
The relationship type is modeled as the diamond and lines between entity types…the instance is between specific entity instances

33. Figure 2.6 (a) Relationship type
Figure 2.6 (b) Entity and Relationship instances

34. Relationships (cont.) Relationships can have attributes
These describe features pertaining to the association between the entities in the relationship
Two entities can have more than one type of relationship between them (multiple relationships)
Associative Entity = combination of relationship and entity

35. Degree of Relationships
Degree of a Relationship is the number of entity types that participate in it
Unary Relationship
Binary Relationship
Ternary Relationship

36. Figure 2.7 Degree of relationships
Entities of two different types related to each other
One entity related to another of the same entity type
Entities of three different types related to each other

37. Cardinality of Relationships
One – to – One
Each entity in the relationship will have exactly one related entity
One – to – Many
An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity
Many – to – Many
Entities on both sides of the relationship can have many related entities on the other side

38. Figure 2.8 Degree of relationships and Cardinality
(a) Unary relationships

39. (b) Binary relationships

40. (c) Ternary relationships
Note: a relationship can have attributes of its own

41. Cardinality Constraints
Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity.
Minimum Cardinality
If zero, then optional
If one or more, then mandatory
Maximum Cardinality
The maximum number 29

42. Figure 2.8 Cardinality Mandatory and Optional

43. Figure 2.9 Cardinality Constraints
(a) Basic relationship with only maximum cardinalities showing
(b) Mandatory minimum cardinalities

44. Figure 2.10 Examples of multiple relationships
Employees and departments – entities can be related to one another in more than one way

45. Strong vs. Weak Entities, and Identifying Relationships
Strong entities
exist independently of other types of entities
has its own unique identifier
represented with single-line rectangle
Weak entity
dependent on a strong entity…cannot exist on its own
Does not have a unique identifier
represented with double-line rectangle
Identifying relationship
links strong entities to weak entities
represented with double line diamond

46. Associative Entities It’s an entity – it has attributes
AND it’s a relationship – it links entities together
When should a relationship with attributes instead be an associative entity?
All relationships for the associative entity should be many
The associative entity could have meaning independent of the other entities
The associative entity preferably has a unique identifier, and should also have other attributes
The associative may be participating in other relationships other than the entities of the associated relationship
Ternary relationships should be converted to associative entities

47. Figure 2.11 An associative entity
(a) An associative entity (CERTIFICATE)
Associative entity involves a rectangle with a diamond inside.
Note that the many-to-many cardinality symbols face toward the associative entity and not toward the other entities 21

48. (b)Ternary relationship as an associative entity36

49. Relation Requirements:
Definition: A relation is a named, two-dimensional table of data
Table is made up of rows (records), and columns (attribute or field)
Not all tables qualify as relations
Requirements:
Every relation has a unique name.
Every attribute value is atomic (not multivalued, not composite)
Every row is unique (can’t have two rows with exactly the same values for all their fields)
Attributes (columns) in tables have unique names
The order of the columns is irrelevant
The order of the rows is irrelevant

50. Correspondence with ER Model
Relations (tables) correspond with entity types and with many-to-many relationship types
Rows correspond with entity instances and with many-to-many relationship instances
Columns correspond with attributes

51. Key Keys are special fields that serve two main purposes:
Primary keys are unique identifiers of the relation. Examples include employee numbers, social security numbers, etc. This is how we can guarantee that all rows are unique
Foreign keys are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship)
Keys can be simple (a single field) or composite (more than one field)
Keys usually are used as indexes to speed up the response to user queries

52. Foreign Key (implements 1:N relationship between customer and order)
Primary Key
Foreign Key (implements 1:N relationship between customer and order)
Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)

53. Transforming E-R into Relations
Step 1: Mapping Regular Entities to Relations
Simple attributes: E-R attributes map directly onto the relation
Composite attributes: Use only their simple, component attributes
Multi-valued Attribute - Becomes a separate relation with a foreign key taken from the superior entity

54. Figure 2.12 Mapping a regular entity
(a) CUSTOMER entity type with simple attributes
(b) CUSTOMER relation

55. Figure 2.13 Mapping a composite attribute
(a) CUSTOMER entity type with composite attribute
(b) CUSTOMER relation with address detail

56. Figure 2.14 Mapping a multivalued attribute
Multivalued attribute becomes a separate relation with foreign key
(b)
1 – to – many relationship between original entity and new relation

57. Transforming E-R into Relations
Step 2: Mapping Weak Entities
Becomes a separate relation with a foreign key taken from the superior entity
Primary key composed of:
Partial identifier of weak entity
Primary key of identifying relation (strong entity)

58. Figure 2.15 Mapping a weak entity
(a) Weak entity DEPENDENT

59. (b) Relations resulting from weak entity
NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity
Foreign key
Composite primary key

60. Transforming E-R into Relations
Step 3: Mapping Binary Relationships
One-to-Many - Primary key on the one side becomes a foreign key on the many side
Many-to-Many - Create a new relation with the primary keys of the two entities as its primary key
One-to-One - Primary key on the mandatory side becomes a foreign key on the optional side

61. Figure 2.16 mapping a 1:M relationship
(a) Relationship between customers and orders

62. (b) Mapping the relationship
Foreign key

63. Figure 2.17 Mapping M:N relationship
(a) ER diagram (M:N)
The Supplies relationship will need to become a separate relation

64. New intersection relation
(b) Three resulting relations
Composite primary key
New intersection relation
Foreign key

65. Figure 2.18 Mapping a binary 1:1 relationship

66. (b) Resulting relations

67. Transforming E-R into Relations
Step 4: Mapping Associative Entities
Identifier Not Assigned
Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship)
Identifier Assigned
It is natural and familiar to end-users
Default identifier may not be unique

68. Figure 2.19 Mapping an associative entity
(a) Associative entity

69. (b) Three resulting relations

70. Transforming E-R into Relations
Step 5: Mapping Unary Relationships
One-to-Many - Recursive foreign key in the same relation
Many-to-Many - Two relations:
One for the entity type
One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity

71. Figure 2.20 Mapping a unary 1:N relationship
(a) EMPLOYEE entity with Manages relationship
(b) EMPLOYEE relation with recursive foreign key

72. Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations

73. Transforming E-R into Relations
Step 6: Mapping Ternary (and n-ary) Relationships
One relation for each entity and one for the associative entity
Associative entity has foreign keys to each entity in the relationship

74. Figure 2.21 Mapping a ternary relationship
(a) Ternary relationship with associative entity

75. Remember that the primary key MUST be unique
(b) Mapping the ternary relationship
Remember that the primary key MUST be unique