2011 DB Slide 3

8/6/2019 2011 DB Slide 3

1/251

LOGICAL DATA MODEL

LDM1 : Identify Major EntitiesLDM2 : Determine Relationships Between EntitiesLDM3 : Determine Primary and Alternate Keys

LDM4 : Determine Foreign KeysLDM5 : Determine Key Business RulesLDM6 : Add Remaining AttributesLDM7 : Validate Normalization RulesLDM8 : Determine DomainsLDM9 : Determine Other Attribute Business Rules

(Triggering Operations)LDM10: Combine User ViewsLDM11: Integrate With Existing Data ModelsLDM12: Analyze for Stability and Growth

8/6/2019 2011 DB Slide 3

2/251

RELATIONAL DATABASE DESIGN

RDD1 : Identify TablesRDD2 : Identify ColumnsRDD3 : Adapt Data Structure to Product Environment

RDD4 : Design for Business Rules about EntitiesRDD5 : Design for Business Rules about RelationshipsRDD6 : Design for Additional Business Rules About AttributesRDD7 : Tune for Scan EfficiencyRDD8 : Define Clustering SequencesRDD9 : Define Hash KeysRDD10 : Add Indexes - Tune by Adding IndexesRDD11 : Add Duplicate DataRDD12 : Redefine ColumnsRDD13 : Redefine Tables

8/6/2019 2011 DB Slide 3

3/251

Handbookof

RelationalDatabase

Designby

Candace C. Fleming

Barbara von Halle

8/6/2019 2011 DB Slide 3

4/251

LOGICALDATA

MODEL

8/6/2019 2011 DB Slide 3

5/251

LDM1

Identify Major Entities

8/6/2019 2011 DB Slide 3

6/251

LDM1

Identify Major Entities

LDM1.1

Name, define, diagram, and documententities in the data dictionary (or designdocumentation).

8/6/2019 2011 DB Slide 3

7/251

LDM2

Determine Relationships Between Entities

8/6/2019 2011 DB Slide 3

8/251

LDM2


LDM2.1

Name, define, diagram, and documentrelationships in the data dictionary (ordesign documentation)

8/6/2019 2011 DB Slide 3

9/251

LDM2


LDM2.2

Classify relationships as being either one-to-one (1:1) or one-to-many (1:N). Forsimplicity, reduce each many-to-many(M:N) relationship to a new entity type

and two 1:N relationships

8/6/2019 2011 DB Slide 3

10/251

LDM2


LDM2.3

For simplicity, reclassify a complexrelationship as an entity, relatedthrough binary relationships to eachof the original entities.

8/6/2019 2011 DB Slide 3

11/251

LDM2


LDM2.4

Eliminate redundant relationships from thelogical model.

8/6/2019 2011 DB Slide 3

12/251

LDM2


LDM2.5

Establish 1:1 relationships betweensupertypes and subtypes. Establish aspecial types of 1:1 relationship, knownas a category, between a supertype and a

set of mutually exclusive subtypes.

8/6/2019 2011 DB Slide 3

13/251

LDM2


LDM2.6

Represent a 1:N bill-of-materialsrelationships as a 1:N relationship fromand to the same entity. Represent an M:Nbill-of-materials relationship by creating a

second entity type and relating it to theoriginal (now parent) entity type throughtwo 1:N relationships.

8/6/2019 2011 DB Slide 3

14/251

LDM3

Determine Primary and Alternate Keys

8/6/2019 2011 DB Slide 3

15/251

LDM3


LDM3.1

Choose one primary key for each entity.

8/6/2019 2011 DB Slide 3

16/251

LDM3


LDM3.2

Identify alternate keys for each entity.

8/6/2019 2011 DB Slide 3

17/251

LDM3


LDM3.3

Choose the primary key of an entity thatis a subtype of another entity (known asa supertype) to be the same as theprimary key of the supertype.

8/6/2019 2011 DB Slide 3

18/251

8/6/2019 2011 DB Slide 3

19/251

8/6/2019 2011 DB Slide 3

20/251

LDM3


LDM3.6

For brevity and simplicity, use a standardabbreviations given word

8/6/2019 2011 DB Slide 3

21/251

LDM4

Determine Foreign Keys

8/6/2019 2011 DB Slide 3

22/251

LDM4


LDM4.1

For each relationship in the logicaldata model, identify the foreign key.

8/6/2019 2011 DB Slide 3

23/251

LDM4


LDM4.2

Name, diagram and document foreignkeys in the data dictionary (or designdocumentation).

8/6/2019 2011 DB Slide 3

24/251

LDM5

Determine Key Business Rules

8/6/2019 2011 DB Slide 3

25/251

LDM5


LDM5.1

Identify one insert rule for eachrelationship.

8/6/2019 2011 DB Slide 3

26/251

LDM5

Determine Key Business RulesInsert Rule - We classify insert constraints into six types:Dependent - Permit insertion of child entity occurrence only when

matching parent entity occurrence already exists.Automatic - Always permit insertion of child entity occurrence. If

matching parent entity occurrence does not already exist, create it.Nullify - Always permit insertion of child entity occurrence. If matching

parent entity occurrence does not exist, set foreign key in child tonull.

Default - Always permit insertion of child entity occurrence. If matchingparent entity occurrence does not exist, set foreign key in child to a

previously defined default value.Customized - Permit insertion of child entity occurrence only if certain

customized validity constraints are met.No Effect - Always permit insertion of child entity occurrence. No

matching parent entity occurrence need exist, and thus no validitychecking need be done.

8/6/2019 2011 DB Slide 3

27/251

LDM5


LDM5.2

Identify one delete rule for eachrelationship.

8/6/2019 2011 DB Slide 3

28/251

LDM5

Determine Key Business RulesDelete Rules - Six types of delete constraints govern valid deletion of a

parent entity (or update of its primary key):Restrict - Permit deletion of parent entity occurrence only when there are

no matching child entity occurrences.

Cascade - Always permit deletion of parent entity occurrence andcascade the deletion to any matching child entity occurrences (i.e.,delete all matching child entity occurrences).

Nullify - Always permit deletion of parent entity occurrence. If anymatching child entity occurrences exist, set their foreign keys to null.

Default - Always permit deletion of parent entity occurrence. If any

matching child entity occurrences exist, set their foreign keys to apreviously defined default value.Customized - Permit deletion of parent entity occurrence only if certain

customized validity constraints are met.No Effect - Always permit deletion of parent entity occurrence. Matching

child entity occurrences mayor may not exist, and thus no validity

checking need be done.

8/6/2019 2011 DB Slide 3

29/251

LDM5


LDM5.3

Avoid the use of nullify insert or deleterules. Favor default rules instead.

8/6/2019 2011 DB Slide 3

30/251

LDM5


LDM5.4

Never define a nullify insert or deleterule when the foreign key also is part ofthe primary key of the child entity.

8/6/2019 2011 DB Slide 3

31/251

LDM5

Determine Key Business RulesLDM5.5

Always define the insert rule for a

supertype-subtype (or supertype-category) relationship as a tailored versionof either automatic or dependent (tailored

to enforce the 1:1 relationship). Definethe delete rule for such relationships ascascade.

8/6/2019 2011 DB Slide 3

32/251

LDM6

Add Remaining Attributes

8/6/2019 2011 DB Slide 3

33/251

LDM6

Add Remaining AttributesLDM6.1

Associate each attribute with the entity

the entire primary key of which isnecessary and sufficient to identify ordetermine it uniquely.

8/6/2019 2011 DB Slide 3

34/251

LDM6


LDM6.2

Place nonkey attributes as high aspossible in the logical data model (as longas the primary key of the entity uniquelyidentifies the attribute).

8/6/2019 2011 DB Slide 3

35/251

LDM6

Add Remaining AttributesLDM6.3

If an attribute in an entity depends on theprimary key but is multivalues (i.e., may have

multiple values for one particular value of theprimary key), reclassify the attributes as a newchild entity type. If unique, that attributeconstitutes the primary key of the new childentity. If not unique, that attribute plus theprimary key of the original (now parent) entityconstitute the primary key of the new childentity.

8/6/2019 2011 DB Slide 3

36/251

LDM6


LDM6.4

Name, diagram, and documentattributes in the data dictionary(or design documentation).

8/6/2019 2011 DB Slide 3

37/251

LDM6


LDM6.5

If there are attributes that seem todescribe a relationships (rather than anentity), reclassify the relationship as a newentity and as child to each of the original

two entities.

8/6/2019 2011 DB Slide 3

38/251

LDM6


LDM6.6

Avoid representing attributes in encodeform (e.g., 01 = red, 02 = blue) unlessthe codes are user-defined and aremeaningful within the industry or

business area.

8/6/2019 2011 DB Slide 3

39/251

8/6/2019 2011 DB Slide 3

40/251

LDM6


LDM6.8

If you must represent attributes inencoded form for business reasons,keep the coded values mutuallyindependent.

8/6/2019 2011 DB Slide 3

41/251

LDM6


LDM6.9

Optionally represent derived data asattributes within the logical data modelwhen they have a significant businessmeaning, but indicate that they are

derived.

8/6/2019 2011 DB Slide 3

42/251

LDM6


LDM6.10

Use a special designation for subtypeidentifiers in the logical data model.

8/6/2019 2011 DB Slide 3

43/251

LDM6


LDM6.11

Place attributes that are common to alloccurrences of a supertype entity in thesupertype rather than in each of itsassociated subtypes.

8/6/2019 2011 DB Slide 3

44/251

LDM6


LDM6.12

In general, combine entities with thesame primary key into one entity.Exceptions include entities with trulydistinct business meanings.

8/6/2019 2011 DB Slide 3

45/251

LDM6


LDM6.13

In general, combine into one subtypeall subtypes having the same attributesand the same relationships. (Possiblyinclude a new attribute representing the

distinction among the originalsubtypes.)

8/6/2019 2011 DB Slide 3

46/251

LDM6


LDM6.14

In general, combine with its associatedsupertype any subtype that spans thesupertype.

8/6/2019 2011 DB Slide 3

47/251

LDM6


LDM6.15

In general, combine entities containingno nonkey attributes with their childentities (if any).

8/6/2019 2011 DB Slide 3

48/251

8/6/2019 2011 DB Slide 3

49/251

Normalization

Logical database design is concernedwith grouping the attributes identified

during requirements analysis intorelevant entities. It can be shown thatcertain rules must be followed if the data

is to have desirable maintenanceproperties. These rules are based on thetheory of NORMALIZATION.

8/6/2019 2011 DB Slide 3

50/251

Normalization

Normalization is the process of deriving orchecking a relational model. Data gathered

but not formed into relations is termedunnormalized. The process of normalizationprogressively refines the data in a threestage process, corresponding to:

First Normal Form 1NFSecond Normal Form 2NF

Third Normal Form 3NF

8/6/2019 2011 DB Slide 3

51/251

3NF

2NF

1NF

Normal Forms

Unnormalized

8/6/2019 2011 DB Slide 3

52/251

Normalization

The rules for this process are explicit but anunderstanding of the organizations businessrules is imperative.

1NF all repeating groups of attributes removed2NF in 1NF, and each non-key attribute

depends on the entire key

(remove partial dependencies)3NF in 2NF, and each non-key attribute

depends only on the key(remove transitive dependencies)

8/6/2019 2011 DB Slide 3

53/251

Normalization Example

Unnormalized:

PRESCRIPTION (pres_num, pres_date, pat_name,pat_address, doc_name, drug_name, drug_quant,issue_status, drug_name, drug_quant, issue_status,

)

8/6/2019 2011 DB Slide 3

54/251

8/6/2019 2011 DB Slide 3

55/251

8/6/2019 2011 DB Slide 3

56/251

8/6/2019 2011 DB Slide 3

57/251

LDM7

Validate Normalization Rules

8/6/2019 2011 DB Slide 3

58/251

LDM7

Validate Normalization RulesLDM7.1

Reduce entities to first normal form (1NF)

by removing repeating or multivaluedattributes to another, child entity.

8/6/2019 2011 DB Slide 3

59/251

LDM7


Reduce first normal form entities to

second normal form (2NF) by removingattributes that are not dependent on thewhole primary key.

8/6/2019 2011 DB Slide 3

60/251

8/6/2019 2011 DB Slide 3

61/251

8/6/2019 2011 DB Slide 3

62/251

LDM7


Reduce Boyce/Codd normal form entities to

fourth normal form (4NF) by removing anyindependently multivalued components of theprimary key to two new parent entities.Retain the original (new child) entity only if itcontains other, nonkey attributes.

8/6/2019 2011 DB Slide 3

63/251

LDM7


Reduce fourth normal form entities to fifth

normal form (5NF) by removing pairwisecyclic dependencies (appearing withcomposite primary keys with three or more

component attributes) to three or morenew parent entities.

8/6/2019 2011 DB Slide 3

64/251

LDM7


In general, do not split fully normalized

entities into smaller entities.

8/6/2019 2011 DB Slide 3

65/251

LDM7


Reevaluate the normalized data model in

light of insert and delete rules and timingconsiderations. Introduce additionalattributes or entities if necessary to

prevent temporal integrity anomalies(loss of data due to historical events andtiming differences).

8/6/2019 2011 DB Slide 3

66/251

8/6/2019 2011 DB Slide 3

67/251

8/6/2019 2011 DB Slide 3

68/251

LDM8

Determine DomainsLDM8.2

Document the domain or set of domain

characteristics for each attributes in thedata dictionary or design documentation.Include data type, length, format or mask,

allowable value constraints, meaning,uniqueness, null support, and defaultvalue if applicable.

8/6/2019 2011 DB Slide 3

69/251

LDM8 :Determine Domains

LDM8.3

Define domains for primary keys to be consistentwith the following rules:

- Primary keys are unique

- Components of composite primary keys are notunique

- Neither primary keys nor primary key components

may be null- Both primary keys and primary key componentsmay accept default values (as long as primary keyuniqueness still holds)

8/6/2019 2011 DB Slide 3

70/251


LDM8.4

Define domains for alternate keys to be

consistent with the following rules:

- Alternate keys are unique

- Components of composite alternate

keys are not unique

8/6/2019 2011 DB Slide 3

71/251

8/6/2019 2011 DB Slide 3

72/251


LDM8.5

Define domain for foreign keys to be

consistent with the following rules:- Data type, length, and format (mask) offoreign key components must be thesame as data type, length, and format ofcorresponding primary key components inparent entities

8/6/2019 2011 DB Slide 3

73/251


LDM8.5 (cont.)

- Uniqueness property for foreign keys must

be consistent with relationship type (i.e., 1:1relationship implies unique foreign key, 1:Nrelationship implies nonunique foreign key)

- Null support, default values, allowable valueconstraints for foreign keys must be consistentwith key business rules (insert/deleteconstraints), but may include additionalconstraints as needed

8/6/2019 2011 DB Slide 3

74/251

8/6/2019 2011 DB Slide 3

75/251


LDM8.6 (cont.)

- Meaning must be defined using the

derivation algorithm and sourceattribute(s) meaning

8/6/2019 2011 DB Slide 3

76/251


LDM8.7

Define the domain for a subtype primary

key (which is also a foreign key) to besubset of the domain for the associatedsupertype primary key. Specially,

- Data type, length and format must bethe same as those for the supertypeprimary key

8/6/2019 2011 DB Slide 3

77/251


LDM8.7 (cont.)

- Allowable value constraints must be based

on the subtype identifier (whether thesubtype identifier is explicitly represented inthe logical data model or not)

- Meaning must be similar to that of the

supertype primary key but based on thesubtype identifier

- Uniqueness must be specified (for the entireprimary key)

8/6/2019 2011 DB Slide 3

78/251

LDM9

8/6/2019 2011 DB Slide 3

79/251

LDM9Determine Other Attribute Business Rules

(Triggering Operations)

8/6/2019 2011 DB Slide 3

80/251

LDM9 : Determine Other Attribute

Business Rules (Triggering Operations)LDM9.1

Define for all business rules triggering

operations that maintain integrity andconsistency of attribute values.

8/6/2019 2011 DB Slide 3

81/251



Document all triggering operations in the data

dictionary or design documentation. Includedocumentation about the trigger:

- Event that initiates the triggering operation(i.e., insert, update, delete, or retrieval)

- Object of event (i.e., name of entity and/orattribute being modified or accessed)

8/6/2019 2011 DB Slide 3

82/251


Business Rules (Triggering Operations)LDM9.2 (cont.)

- Condition under which the triggering

operation is initiated

Also include documentation about theoperation:

- Action to take place (such as reject eventor trigger related event)

8/6/2019 2011 DB Slide 3

83/251



Define triggering operations for all

attributes that are sources for derivedattributes, such that update of a sourceattribute triggers update of the derived

attribute.

8/6/2019 2011 DB Slide 3

84/251



Typically define triggering operations for

subtypes such that, when a subtypeoccurrence is deleted, the correspondingsupertype also is deleted.

8/6/2019 2011 DB Slide 3

85/251



Define triggering operations for time-

initiated integrity constraints. Specify theevent initiating the operation (i.e., thetrigger) as a change in a system current

date/time variable.

8/6/2019 2011 DB Slide 3

86/251

LDM10Combine User Views

8/6/2019 2011 DB Slide 3

87/251

LDM10 : Combine User Views

LDM10.1

When combining user views, merge

entities with the same primary key andequivalent primary key domains. Include inthe merged entity all attributes from the

original entities (eliminating redundantattributes).

8/6/2019 2011 DB Slide 3

88/251


LDM10.2

When combining user views, establish a

supertype-subtype relationship betweenentities with the same primary key, whereone primary key domain is a subset of the

other. Eliminate from the new subtype anyattributes that are also in the supertype.

8/6/2019 2011 DB Slide 3

89/251


LDM10.3

When combining user views, establish a

common supertype to relate two entitieswith the same primary key. Primary keydomains that differ in allowable value

constraints but are otherwise equivalent.

8/6/2019 2011 DB Slide 3

90/251


LDM10.4

When combining use views, merge entities

the primary keys of which serve ascandidate keys for each other. Include inthe merged entity all attributes from the

original entities (eliminating redundantattributes).

8/6/2019 2011 DB Slide 3

91/251


LDM10.5

When combining user views, include

without change (i.e., do not merge) allentities with different primary keys.

8/6/2019 2011 DB Slide 3

92/251


LDM10.6When combining user views, retain allbusiness rules about candidates keys fromthe original user views (e.g., primary andalternate key uniqueness and null support).

Allow an exception for primary keys in theoriginal user views that are reclassified as

alternate keys in the combined user view:Consider whether the no-null constraint canbe relaxed.

8/6/2019 2011 DB Slide 3

93/251


LDM10.7When combining user views, merge relationshipsbetween entities where the entities themselves

are the results of merging, but only when suchrelationships convey the same meaning. Applyto the resultant merged relationships acardinality incorporating cardinalities of theoriginal source relationships. If the resultant

relationship is many-to- many (M:N), resolve itby defining a new entity type and two one-to-many (1:N) relationships.

8/6/2019 2011 DB Slide 3

94/251


LDM10.8

When combining user views, initially

include without change (i.e., do notmerge) all relationships with differentmeanings. Then identity and eliminate

any redundant

8/6/2019 2011 DB Slide 3

95/251


LDM10.9

When combining user views, look for

missing relationships between entitiesoriginating in different user views. Addthese relationships to the combined user

view.

8/6/2019 2011 DB Slide 3

96/251


LDM10.10

Correct all foreign keys in a combined

user view to reflect primary keys (ratherthan the alternate keys) of parententities.

8/6/2019 2011 DB Slide 3

97/251


LDM10.11

When combining user views, initially

include key business rules (insert/deleteconstraints) as defined in the source userviews. Add key business rules for new

relationships. Then evaluate forinconsistencies. Resolve throughdiscussions with users.

8/6/2019 2011 DB Slide 3

98/251


LDM10.12

When combining user views, merge

attributes having the same meanings inthe same entity. Reconcile or union theirdomains and triggering operations.

8/6/2019 2011 DB Slide 3

99/251


LDM10.13

When combining user views, eliminate

or flag derived attributes.

8/6/2019 2011 DB Slide 3

100/251


LDM10.14

When combining user views, after

merging, eliminating, and adding newrelationships as appropriate, againnormalize to eliminate any newly

introduced redundancies.

8/6/2019 2011 DB Slide 3

101/251


LDM10.15

After combining user views, reexamine

attributes to identify changes in domaincharacteristics such as null support.

LDM11

8/6/2019 2011 DB Slide 3

102/251

LDM11Integrate With Existing Data Models

8/6/2019 2011 DB Slide 3

103/251

LDM11 : Integrate With

8/6/2019 2011 DB Slide 3

104/251


Existing Data ModelsLDM11.2

Evolve the business conceptual schema

by integrating and incorporating eachnew logical data model that isdeveloped.


8/6/2019 2011 DB Slide 3

105/251


Existing Data ModelsLDM11.3

Identify the mappings between each logical datamodel and the business conceptual schema.

Document these mappings in the data dictionary,including:

- Naming differences

- Operations performed on the conceptual schema to

obtain a specific logical data model, such as selects,projects, joins, or aggregations of entities andsummarization or other derivations of attributes

8/6/2019 2011 DB Slide 3

106/251

LDM12

8/6/2019 2011 DB Slide 3

107/251

LDM12

Analyze for Stability and Growth

LDM12 : Analyze for Stability

8/6/2019 2011 DB Slide 3

108/251

LDM12 : Analyze for Stability

and GrowthLDM12.1

Incorporate into at least document with

the logical data model changes that areimminent, significant, and/or probable, forfurther evaluation during database design

or future logical data modeling projects.

8/6/2019 2011 DB Slide 3

109/251

RELATIONALDATABASE

DESIGN

8/6/2019 2011 DB Slide 3

110/251

8/6/2019 2011 DB Slide 3

111/251

8/6/2019 2011 DB Slide 3

112/251

RDD2

8/6/2019 2011 DB Slide 3

113/251

RDD2Identify Columns

8/6/2019 2011 DB Slide 3

114/251

8/6/2019 2011 DB Slide 3

115/251

8/6/2019 2011 DB Slide 3

116/251

8/6/2019 2011 DB Slide 3

117/251

8/6/2019 2011 DB Slide 3

118/251

8/6/2019 2011 DB Slide 3

119/251

RDD3 :Adapt Data Structure

8/6/2019 2011 DB Slide 3

120/251


to Product EnvironmentRDD3.2

Require users and programs to explicitly

name (and therefore sequence columns) tobe returned by a query; i.e., discourage useof SQL SELECT * syntax (or equivalent).

Also discourage INSERT commands that donot specify column names.

8/6/2019 2011 DB Slide 3

121/251

8/6/2019 2011 DB Slide 3

122/251


8/6/2019 2011 DB Slide 3

123/251


to Product EnvironmentRDD3.5

In general, assign to one database

tables representing entities that areclosely related in business meaning.

8/6/2019 2011 DB Slide 3

124/251

8/6/2019 2011 DB Slide 3

125/251

8/6/2019 2011 DB Slide 3

126/251

8/6/2019 2011 DB Slide 3

127/251

8/6/2019 2011 DB Slide 3

128/251

8/6/2019 2011 DB Slide 3

129/251

RDD4 :Design for Business

8/6/2019 2011 DB Slide 3

130/251

es g o us ess

Rules about EntitiesRDD4.2

If an entity has an alternate key, enforce

the logical properties (uniqueness,minimality, and, if applicable, disallowanceof nulls) of the alternate key through the

relational implementation.

RDD4 :Design for Business

8/6/2019 2011 DB Slide 3

131/251

s g s ss

Rules about EntitiesRDD4.3

Document primary and alternate keys

for each relational table in the catalog ordata dictionary, including mechanismsfor enforcing the keys' properties.

8/6/2019 2011 DB Slide 3

132/251

8/6/2019 2011 DB Slide 3

133/251

8/6/2019 2011 DB Slide 3

134/251

RDD6Design for Additional Business Rules About

8/6/2019 2011 DB Slide 3

135/251

Design for Additional Business Rules About

Attributes

RDD6 : Design for Additional

8/6/2019 2011 DB Slide 3

136/251

gBusiness Rules About Attributes

RDD6.1

Enforce business rules about attributes

(domains and triggering operations)through the relation implementation.

8/6/2019 2011 DB Slide 3

137/251


8/6/2019 2011 DB Slide 3

138/251


RDD6.3

In general, do not permit null values for

any column.


8/6/2019 2011 DB Slide 3

139/251


RDD6.4

In the relational implementation, favor

use of default values over null values.


8/6/2019 2011 DB Slide 3

140/251


RDD6.5

Automate assignment of default values,

if feasible.

8/6/2019 2011 DB Slide 3

141/251

8/6/2019 2011 DB Slide 3

142/251


8/6/2019 2011 DB Slide 3

143/251

Business Rules About Attributes

RDD6.8

Enforce business rules about tables and

columns through standard maintenanceroutines, always executed in the place ofor in addition to native DML updatecommands, when the DBMS tabledefinition cannot enforce these rulesautomatically.


8/6/2019 2011 DB Slide 3

144/251

Business Rules About Attributes

RDD6.9

Make each standard maintenance

routine table-specific. Embed calls totable-specific subroutines to avoidproliferation of duplicate code.

8/6/2019 2011 DB Slide 3

145/251

RDD7

8/6/2019 2011 DB Slide 3

146/251

Tune for Scan Efficiency

RDD7 :Tune for Scan

8/6/2019 2011 DB Slide 3

147/251

Efficiency

RDD7.1

Encourage scan processing for

- Small tables (e.g., six or fewer physical blocks)- Medium and large tables (e.g., more than sixphysical blocks) when accessed to satisfyrequests for which a large percentage of rows

(e.g., 20 percent or more) qualify.

8/6/2019 2011 DB Slide 3

148/251

RDD7 :Tune for Scan

8/6/2019 2011 DB Slide 3

149/251

Efficiency

RDD7.3

In general, do not store multiple tables

within the same DBMS storagestructure.

RDD7 :Tune for Scan

8/6/2019 2011 DB Slide 3

150/251

Efficiency

RDD7.4

Accelerate scan processing where feasible(product-specific) by

- Facilitating parallel scan processing

- Using high-speed storage devices

- Employing high-speed scanning techniques

- Specifying appropriate numbers and sizes ofdata buffers

RDD8

8/6/2019 2011 DB Slide 3

151/251

Define Clustering Sequences

8/6/2019 2011 DB Slide 3

152/251

RDD8 :Define Clustering

8/6/2019 2011 DB Slide 3

153/251

Sequences

- Frequently processes sequentially usingthe same sequence, and are

- infrequently inserted or deleted- infrequently updated, where updatesinvolve change to the columns that

determine the clustering.


8/6/2019 2011 DB Slide 3

154/251

Sequences

RDD8.2

Do not cluster a table if the overhead is

detrimental to other critical processingrequirement (e.g., insert/update/ deleteprocessing).

8/6/2019 2011 DB Slide 3

155/251


8/6/2019 2011 DB Slide 3

156/251

Sequences

RDD8.4

Consider clustering rows on columns involved in

- ORDER BY- GROUP BY

- UNION, DISTINCT, and other operationsinvolving sorts

- joins

- Selection over range of values

RDD8 :Define ClusteringS

8/6/2019 2011 DB Slide 3

157/251

Sequences

RDD8.5

When choosing a clustering sequence,

evaluate the effect of clustering onconcurrency.

8/6/2019 2011 DB Slide 3

158/251

8/6/2019 2011 DB Slide 3

159/251

RDD8 :Define ClusteringS

8/6/2019 2011 DB Slide 3

160/251

Sequences

RDD8.8

Minimize cost of clustering through

appropriate specification of free spaceand frequent table reorganizations.

8/6/2019 2011 DB Slide 3

161/251

8/6/2019 2011 DB Slide 3

162/251

RDD9 :Define Hash Keys

8/6/2019 2011 DB Slide 3

163/251


RDD9.2

Define hash keys and (if possible) hash

algorithms that ensure a useful distributionof data.


8/6/2019 2011 DB Slide 3

164/251


RDD9.3

In general, avoid hash synonyms.


8/6/2019 2011 DB Slide 3

165/251

RDD9 Define Hash Keys

RDD9.4

Consider hashing the column or set of

columns most frequently equated todiscrete values in selection criteria.


8/6/2019 2011 DB Slide 3

166/251

9 e e as eys

RDD9.5

In general, do not hash on a set of

columns if a subset (e.g. one column ofmulticolumn hash key) is frequentlyreferenced alone in selection criteria.Define a clustering sequence or orderedindex instead.


8/6/2019 2011 DB Slide 3

167/251

y

RDD9.6

Avoid hashes on frequently updated

columns.

8/6/2019 2011 DB Slide 3

168/251

8/6/2019 2011 DB Slide 3

169/251

RDD10Add Indexes Tune by Adding Indexes

8/6/2019 2011 DB Slide 3

170/251

Add Indexes - Tune by Adding Indexes

RDD10 : Add Indexes - Tuneby Adding Indexes

8/6/2019 2011 DB Slide 3

171/251

by Adding Indexes

RDD10.1In general, build indexes on medium to largetables (e.g., more than six physical blocks) to

do either of the following:- Facilitate access of a small percentage(e.g., less than 20 percent) of rows in a table- Avoid table access altogether for requests

involving a small subset of columnsAssuming that the additional overheadimposed on updates is acceptable.


8/6/2019 2011 DB Slide 3

172/251

by Adding Indexes

RDD10.2

Build clustering indexes to facilitate

clustering of table rows (for productsthat require an index to accompanyclustering).


8/6/2019 2011 DB Slide 3

173/251

by Adding Indexes

RDD10.3

Build ordered indexes and specify

ascending or descending (if supported bythe product) to facilitate sequential orsorted access to a small percentage (e.g.,less than 20 percent) of the rows.


8/6/2019 2011 DB Slide 3

174/251

by Adding Indexes

RDD10.4

If you store multiple tables in the same

DBMS storage structure, establish indexeson each table to minimize inappropriatemultitable scanning.


8/6/2019 2011 DB Slide 3

175/251

by Adding Indexes

RDD10.5

Avoid building indexes for which the overheadseverely degrades critical processingrequirements or for which the cost (related toindex storage and maintenance) is excessiverelative to the benefits. Consider

- Storage requirements- Influence on inserts, updates, deletes


8/6/2019 2011 DB Slide 3

176/251

by Adding Indexes

- Implications for load times

- Table reorganization performance

- Recovery times- Backup performance

- Statistics gathering


8/6/2019 2011 DB Slide 3

177/251

by Adding Indexes

RDD10.6

Do not create (non unique) indexes on

small tables.

8/6/2019 2011 DB Slide 3

178/251


8/6/2019 2011 DB Slide 3

179/251

by Adding Indexes

RDD10.8

Consider building indexes on foreign

key columns.


8/6/2019 2011 DB Slide 3

180/251

by Adding Indexes

RDD10.9

Consider building to encourage index-only accesswhen

- A reasonable subset of columns is required tosatisfy certain requests

- The optimizer is smart enough to invoke index-only access

- Index-only access is more efficient than tableaccess


8/6/2019 2011 DB Slide 3

181/251

by Adding Indexes

RDD10.10

Consider building indexes on columns

in built-in functions, together with the(SQL GROUP BY) columns used thebuilt-in functions.


8/6/2019 2011 DB Slide 3

182/251

by Adding Indexes

RDD10.11

Choose sequence of columns in a

composite (multicolumn) ordered indexesto facilitate processing of as many typesof requests as possible.


8/6/2019 2011 DB Slide 3

183/251

by Adding Indexes

RDD10.12

Evaluate ways in which the DBMS

optimizer uses indexes when you choosebetween a composite index and single-column indexes.


8/6/2019 2011 DB Slide 3

184/251

by Adding Indexes

RDD10.13

Avoid indexes on frequently updated

columns.


8/6/2019 2011 DB Slide 3

185/251

by Adding Indexes

RDD10.14

Avoid indexes on columns with such an

irregular distribution of values that theoptimizer frequently misjudges indexusefulness.


8/6/2019 2011 DB Slide 3

186/251

by Adding Indexes

RDD10.15

In general, create one to four indexes per

table, or perhaps more if the tables arerarely updated.


8/6/2019 2011 DB Slide 3

187/251

by Adding Indexes

RDD10.16

In planning for the process of creatingindexes, consider

- Availabilities implications for the tablebeing accessed and perhaps for othertables or the DBMS catalog

- Efficiency implications of building in theindex during or after table load


8/6/2019 2011 DB Slide 3

188/251

by Adding Indexes

RDD10.17

Where feasible, store indexes and

indexed tables on different storagedevices.


8/6/2019 2011 DB Slide 3

189/251

by Adding Indexes

RDD10.18

Specify index locking and index free

space options to minimize the effects ofthe index on concurrent processing andon updates.


8/6/2019 2011 DB Slide 3

190/251

by Adding Indexes

RDD10.19

Update the catalog statistics by

executing a utility (if supported by theDBMS) immediately after adding anindex.

8/6/2019 2011 DB Slide 3

191/251

8/6/2019 2011 DB Slide 3

192/251


8/6/2019 2011 DB Slide 3

193/251

by Adding Indexes

RDD10.22

For DBMS products that support multiple

types of storage structures for indexes,choose the most efficient structure basedon user access requirements. Regardlessof structure, also tune for efficiency of

index scans as you did for tables scans(RDD7.2, RDD7.3, and RDD7.4).

RDD11Add Duplicate Data

8/6/2019 2011 DB Slide 3

194/251

Add Duplicate Data

8/6/2019 2011 DB Slide 3

195/251

RDD11 : Add Duplicate Data

8/6/2019 2011 DB Slide 3

196/251

RDD11.2

Specify the domain of a copied column

to be consistent with that of the sourcecolumn.


8/6/2019 2011 DB Slide 3

197/251

RDD11.3

Consider adding column derived from existing,nonvolatile column

- To reduce multitable access- To improve performance of frequent of criticalrequests involving calculations (by performingthe calculations in advance)

- To circumvent DML limitations that preventexpressing the derivation in DML


8/6/2019 2011 DB Slide 3

198/251

RDD11.4

Use special naming conventions to denote

columns that are copied or derived fromexisting columns.


8/6/2019 2011 DB Slide 3

199/251

RDD11.5

Document copied and derived columns

in the data dictionary or catalog, withreasons for duplication.


8/6/2019 2011 DB Slide 3

200/251

RDD11.6

Enforce consistency of source and copied orderived columns by

- Permitting users (and programs) to updateonly the source (not copied of derived) columns

- Establishing triggering operations on the

source columns that automatically cascadeupdates to all copied or derived columns

8/6/2019 2011 DB Slide 3

201/251

8/6/2019 2011 DB Slide 3

202/251


8/6/2019 2011 DB Slide 3

203/251

RDD11.9

Instead of replacing a primary key by a

contrived substitute, consider redefiningan alternate key as the primary key.

8/6/2019 2011 DB Slide 3

204/251


8/6/2019 2011 DB Slide 3

205/251

RDD11.11

Avoid storing rows derived from existing

rows with in the same relational table,because such derived rows destroy theassociation of every column with exactlyone domain.


8/6/2019 2011 DB Slide 3

206/251

RDD11.12

To effect an outer join, consider adding rows tothe joined tables, so that, in effect, all rows

match. However, do so only after evaluating DMLalternatives for simulating an outer join, such as

- UNION, NOT EXISTS syntax

- UNION, NOT IN syntax

- Insert into temporary table- Insert into non-relational file


8/6/2019 2011 DB Slide 3

207/251

RDD11.13

To effect an outer join, consider contrivingcolumns to substitute for the joined columns in

nonmatching rows. (This will include non-matching rows in the result.) Do so inpreference to adding extra rows (RDD11.12)when the number of extra rows is excessive.

However, consider DML alternatives (seeRDD11.12) first.

RDD12Redefine Columns

8/6/2019 2011 DB Slide 3

208/251

8/6/2019 2011 DB Slide 3

209/251

RDD12 : Redefine Columns

8/6/2019 2011 DB Slide 3

210/251

RDD12.2

Consider selective redefinition of foreign keys toreference alternate rather than primary keys

when- Such redefinition eliminates multitable accessand improves performance of critical requests

- Referenced alternate keys do not allow nulls

- Referential integrity still can be enforced

8/6/2019 2011 DB Slide 3

211/251

RDD13 : Redefine Tables

8/6/2019 2011 DB Slide 3

212/251

RDD13.1

In general, eliminate (choose not to

create) tables that- Add no new information

- Are not referenced by any (known)

data requests

8/6/2019 2011 DB Slide 3

213/251


8/6/2019 2011 DB Slide 3

214/251

RDD13.3Treat column in duplicate tables as duplicatecolumns. Specially, apply RDD11.5 and RDD11.6- To document the duplicate columns in the data

dictionary or catalog (RDD11.5)- To permit update of only the source (not theduplicate) columns (RDD11.6)- To establish triggering operations on sourcecolumns to automatically cascade updates toduplicate columns (RDD11.6)


8/6/2019 2011 DB Slide 3

215/251

RDD13.4

Consider segmenting a table vertically intoseparate tables if different users consistently

access specific subsets of columns in the table.Consider not doing so if either of the following:

- Other frequent or critical requests wouldreference multiple table segments

- Update processing would span table segments


8/6/2019 2011 DB Slide 3

216/251

RDD13.5

In general, when segmenting a table

vertically, store the primary key in everysegment but each nonkey column inexactly one of the segments.

8/6/2019 2011 DB Slide 3

217/251

8/6/2019 2011 DB Slide 3

218/251


8/6/2019 2011 DB Slide 3

219/251

RDD13.8

In general, when segmenting a table

horizontally, store each row in exactlyone of the segments.


8/6/2019 2011 DB Slide 3

220/251

RDD13.9

When segmenting a table horizontally,

include all columns in each segment toavoid the need for outer unions.


8/6/2019 2011 DB Slide 3

221/251

RDD13.10

Consider combining tables that

- Represent entities involved in 1:1 relationships

- Are frequently referenced together by users

- Are infrequently referenced separately

assuming the effect on performance, dataavailability, and storage is acceptable.


8/6/2019 2011 DB Slide 3

222/251

RDD13.11

Consider combining subtype tables that share thesame supertype if the subtypes

- Have similar columns- Are involved in similar relationships

- Are frequently accessed together

- Are infrequently accessed separately

assuming the effect on performance, dataavailability, and storage is acceptable.

8/6/2019 2011 DB Slide 3

223/251


8/6/2019 2011 DB Slide 3

224/251

RDD13.13

Consider combining a parent table with a childtable if

- Every parent row is associated with at leastchild row

- Users often reference the parent table with thechild

- Users infrequently reference one without theother

The effect on performance, data availability, andstorage is acceptable


8/6/2019 2011 DB Slide 3

225/251

RDD13.14To effect an outer join, consider combining thetables into one table. However, do so only afterevaluating other alternatives for simulating the outer

join, such as- UNION, NOT EXISTS syntax- UNION, NOT IN syntax- Insert into temporary table

- Insert into nonrelational file- Adding extra rows so that in effect all rows match(RDD11.12)- Contriving substitute columns to facilitate joiningnon matching rows (RDD11.13)

8/6/2019 2011 DB Slide 3

226/251

Relational DatabaseDesignTechniques

Relational Database DesignTechniques

8/6/2019 2011 DB Slide 3

227/251

RDDT.1

Allow users to access data only through

views. Do not permit users to accessbase tables directly.


8/6/2019 2011 DB Slide 3

228/251

RDDT.2

Create one master view for each table

and build all other views on the masterviews (i.e., not directly on the basetables).


8/6/2019 2011 DB Slide 3

229/251

RDDT.3

Create views on master views as

needed to simplify or restrict read-onlyaccess.


8/6/2019 2011 DB Slide 3

230/251

RDDT.4

Build the standard maintenance (insert,

update, and delete) routines and theintegrity audit routines to access master(or potentially more restricted) viewsrather than base tables.


8/6/2019 2011 DB Slide 3

231/251

RDDT.5

Name and document views in the data

dictionary or catalog.


8/6/2019 2011 DB Slide 3

232/251

RDDT.6

Where possible, enforce user security

through master views or throughsecond-level security views defined onthe master views.


8/6/2019 2011 DB Slide 3

233/251

RDDT.7

Consider creating a user authorization

table to control access to row subsetsby user ID.


8/6/2019 2011 DB Slide 3

234/251

RDDT.8

When using standard maintenance

routines to enforce integrity, grantappropriate user access to theroutines and prohibit use of nativeDBMS update commands.


8/6/2019 2011 DB Slide 3

235/251

RDDT.9

In a production environment, generally restrictaccess to base table definitions and storage

structure specifications to designated databaseadministrators. If users are permitted to createtheir own (e.g., temporary) tables, isolate suchuser definitions to their own space or even their

own databases.


8/6/2019 2011 DB Slide 3

236/251

RDDT.10

Tune performance of data retrieval from

VLRDB by- Selecting appropriate accessmechanisms

- Implementing sample tables

- Implementing summarized tables


8/6/2019 2011 DB Slide 3

237/251

RDDT.11

Facilitate maximum throughput against aVLRDB by appropriate

- Choice of locking options

- Clustering

- Table partitioning or segmentation

- Commit processing- Segmentation of updates


8/6/2019 2011 DB Slide 3

238/251

RDDT.12

Tune mass insert processing against aVLRDB by

- Using a load utility

- Disabling logging

- Temporarily dropping andsubsequently recreating indexes


8/6/2019 2011 DB Slide 3

239/251

RDDT.13

Tune mass delete processing against aVLRDB by partitioning and segmenting.


8/6/2019 2011 DB Slide 3

240/251

RDDT.14

For VLRDBs, ensure that long-runningrequests can be recovered andrestarted within reasonable timeframes.


8/6/2019 2011 DB Slide 3

241/251

RDDT.15

Accommodate utility processing against aVLRDB by

- Encouraging parallel utility execution- Taking advantage of partial utilities

- Scheduling statistics-gathering utilities onlyas needed

- Assessing recovery times


8/6/2019 2011 DB Slide 3

242/251

RDDT.16

Be cognizant of the structuralmodifications that require dropping,redefining, and recreating existing objects(product-specific).


8/6/2019 2011 DB Slide 3

243/251

RDDT.17

Determine the effect that dropping arelational object will have on existingrelational objects, applications, and users.


8/6/2019 2011 DB Slide 3

244/251

RDDT.18

Notify user prior to dropping an object.


8/6/2019 2011 DB Slide 3

245/251

RDDT.19

In environments where object dropsautomatically cascade to dependent objects

or where objects cannot be dropped until alldependent objects have been dropped,establish mechanisms or procedures foridentifying and subsequently recreating such

dependent objects.


8/6/2019 2011 DB Slide 3

246/251

RDDT.20

When adding a table, identify itsrelationships with existing tablesand enforce associated integrityrules.


8/6/2019 2011 DB Slide 3

247/251

RDDT.21

Make structural database change astransparent as possible to existing usersand applications.


8/6/2019 2011 DB Slide 3

248/251

RDDT.22

Use synonyms or views to rename objects(instead of using a RENAME command).


8/6/2019 2011 DB Slide 3

249/251

RDDT.23

When adding columns, considerimplication with respect to domain andsequencing of columns within a table.


8/6/2019 2011 DB Slide 3

250/251

RDDT.24

Document all design change in the datadictionary. Include a description of theoriginal design, the changed design,and the reason of change.


8/6/2019 2011 DB Slide 3

251/251

RDDT.25

Create a scenario for incorporating changebefore attempting to implement them.

2011 DB Slide 3

Documents

Transcript of 2011 DB Slide 3