2011 db slide 3
Post on 07-Apr-2018
214 Views
Preview:
TRANSCRIPT
-
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
Determine Relationships Between Entities
LDM2.1
Name, define, diagram, and documentrelationships in the data dictionary (ordesign documentation)
-
8/6/2019 2011 DB Slide 3
9/251
LDM2
Determine Relationships Between Entities
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
Determine Relationships Between Entities
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
Determine Relationships Between Entities
LDM2.4
Eliminate redundant relationships from thelogical model.
-
8/6/2019 2011 DB Slide 3
12/251
LDM2
Determine Relationships Between Entities
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
Determine Relationships Between Entities
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
Determine Primary and Alternate Keys
LDM3.1
Choose one primary key for each entity.
-
8/6/2019 2011 DB Slide 3
16/251
LDM3
Determine Primary and Alternate Keys
LDM3.2
Identify alternate keys for each entity.
-
8/6/2019 2011 DB Slide 3
17/251
LDM3
Determine Primary and Alternate Keys
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
Determine Primary and Alternate Keys
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
Determine Foreign Keys
LDM4.1
For each relationship in the logicaldata model, identify the foreign key.
-
8/6/2019 2011 DB Slide 3
23/251
LDM4
Determine Foreign Keys
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
Determine Key Business Rules
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
Determine Key Business Rules
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
Determine Key Business Rules
LDM5.3
Avoid the use of nullify insert or deleterules. Favor default rules instead.
-
8/6/2019 2011 DB Slide 3
30/251
LDM5
Determine Key Business Rules
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
Add Remaining Attributes
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
Add Remaining Attributes
LDM6.4
Name, diagram, and documentattributes in the data dictionary(or design documentation).
-
8/6/2019 2011 DB Slide 3
37/251
LDM6
Add Remaining Attributes
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
Add Remaining Attributes
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
Add Remaining Attributes
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
Add Remaining Attributes
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
Add Remaining Attributes
LDM6.10
Use a special designation for subtypeidentifiers in the logical data model.
-
8/6/2019 2011 DB Slide 3
43/251
LDM6
Add Remaining Attributes
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
Add Remaining Attributes
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
Add Remaining Attributes
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
Add Remaining Attributes
LDM6.14
In general, combine with its associatedsupertype any subtype that spans thesupertype.
-
8/6/2019 2011 DB Slide 3
47/251
LDM6
Add Remaining Attributes
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
Validate Normalization RulesLDM7.2
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
Validate Normalization RulesLDM7.5
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
Validate Normalization RulesLDM7.6
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
Validate Normalization RulesLDM7.7
In general, do not split fully normalized
entities into smaller entities.
-
8/6/2019 2011 DB Slide 3
65/251
LDM7
Validate Normalization RulesLDM7.8
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 :Determine Domains
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 :Determine Domains
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 :Determine Domains
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 :Determine Domains
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 :Determine Domains
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 :Determine Domains
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
LDM9 : Determine Other Attribute
Business Rules (Triggering Operations)LDM9.2
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
LDM9 : Determine Other Attribute
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
LDM9 : Determine Other Attribute
Business Rules (Triggering Operations)LDM9.3
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
LDM9 : Determine Other Attribute
Business Rules (Triggering Operations)LDM9.4
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
LDM9 : Determine Other Attribute
Business Rules (Triggering Operations)LDM9.5
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
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 : Combine User Views
LDM10.13
When combining user views, eliminate
or flag derived attributes.
-
8/6/2019 2011 DB Slide 3
100/251
LDM10 : Combine User Views
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 : Combine User Views
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
LDM11 : Integrate With
Existing Data ModelsLDM11.2
Evolve the business conceptual schema
by integrating and incorporating eachnew logical data model that isdeveloped.
LDM11 : Integrate With
-
8/6/2019 2011 DB Slide 3
105/251
LDM11 : Integrate With
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
RDD3 :Adapt Data Structure
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
RDD3 :Adapt Data Structure
-
8/6/2019 2011 DB Slide 3
123/251
RDD3 :Adapt Data Structure
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
RDD6 : Design for Additional
-
8/6/2019 2011 DB Slide 3
138/251
gBusiness Rules About Attributes
RDD6.3
In general, do not permit null values for
any column.
RDD6 : Design for Additional
-
8/6/2019 2011 DB Slide 3
139/251
gBusiness Rules About Attributes
RDD6.4
In the relational implementation, favor
use of default values over null values.
RDD6 : Design for Additional
-
8/6/2019 2011 DB Slide 3
140/251
gBusiness Rules About Attributes
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
RDD6 : Design for Additional
-
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.
RDD6 : Design for Additional
-
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.
RDD8 :Define 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
RDD8 :Define Clustering
-
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 :Define Hash Keys
RDD9.2
Define hash keys and (if possible) hash
algorithms that ensure a useful distributionof data.
RDD9 :Define Hash Keys
-
8/6/2019 2011 DB Slide 3
164/251
RDD9 :Define Hash Keys
RDD9.3
In general, avoid hash synonyms.
RDD9 :Define Hash Keys
-
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.
RDD9 :Define Hash Keys
-
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.
RDD9 :Define Hash Keys
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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).
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
8/6/2019 2011 DB Slide 3
179/251
by Adding Indexes
RDD10.8
Consider building indexes on foreign
key columns.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
8/6/2019 2011 DB Slide 3
184/251
by Adding Indexes
RDD10.13
Avoid indexes on frequently updated
columns.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
8/6/2019 2011 DB Slide 3
188/251
by Adding Indexes
RDD10.17
Where feasible, store indexes and
indexed tables on different storagedevices.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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
RDD10 : Add Indexes - Tuneby Adding Indexes
-
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.
RDD11 : Add Duplicate Data
-
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
RDD11 : Add Duplicate Data
-
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.
RDD11 : Add Duplicate Data
-
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.
RDD11 : Add Duplicate Data
-
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
RDD11 : Add Duplicate Data
-
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
RDD11 : Add Duplicate Data
-
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.
RDD11 : Add Duplicate Data
-
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
RDD11 : Add Duplicate Data
-
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
RDD13 : Redefine Tables
-
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)
RDD13 : Redefine Tables
-
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
RDD13 : Redefine Tables
-
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
RDD13 : Redefine Tables
-
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.
RDD13 : Redefine Tables
-
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.
RDD13 : Redefine Tables
-
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.
RDD13 : Redefine Tables
-
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
RDD13 : Redefine Tables
-
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
RDD13 : Redefine Tables
-
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.
Relational Database DesignTechniques
-
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).
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
229/251
RDDT.3
Create views on master views as
needed to simplify or restrict read-onlyaccess.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
231/251
RDDT.5
Name and document views in the data
dictionary or catalog.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
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
Relational Database DesignTechniques
-
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
Relational Database DesignTechniques
-
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
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
239/251
RDDT.13
Tune mass delete processing against aVLRDB by partitioning and segmenting.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
240/251
RDDT.14
For VLRDBs, ensure that long-runningrequests can be recovered andrestarted within reasonable timeframes.
Relational Database DesignTechniques
-
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
Relational Database DesignTechniques
-
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).
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
244/251
RDDT.18
Notify user prior to dropping an object.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
246/251
RDDT.20
When adding a table, identify itsrelationships with existing tablesand enforce associated integrityrules.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
247/251
RDDT.21
Make structural database change astransparent as possible to existing usersand applications.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
248/251
RDDT.22
Use synonyms or views to rename objects(instead of using a RENAME command).
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
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.
Relational Database DesignTechniques
-
8/6/2019 2011 DB Slide 3
251/251
RDDT.25
Create a scenario for incorporating changebefore attempting to implement them.
top related