Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real...
-
Upload
eileen-cameron -
Category
Documents
-
view
212 -
download
0
Transcript of Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real...
![Page 1: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/1.jpg)
Copyright © 2009 David C. Hay
1
Converting An Essential Entity/Relationship Model Into A Real Database Design
Enterprise Data WorldDavid Hay
Tampa, FloridaApril 6, 2009
David C. Hay
Enterprise Data WorldAustin, TexasMay 1, 2014
Essential Strategies International13 Hilshire Grove LaneHouston, TX 77055http://essentialstrategies.com
![Page 2: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/2.jpg)
Copyright © 2014 David C. Hay 2
Different points of view . . .
Data modeler
End User
Designer
![Page 3: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/3.jpg)
Copyright © 2014 David C. Hay 3
Data Modeler’s Assignment . . .
Capture the language of the business Do so in as flexible and robust a manner as
possible.
Data modeler
![Page 4: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/4.jpg)
Copyright © 2014 David C. Hay 4
How to achieve flexibility and robustness . . . Generalize entity classes,
Each describes as large a population of phenomena as possible.
For example, a Party is a Person or an Organization that is of interest to the company. Organization in this case can then have more specific sub-types, like Company, Government Agency, Household, etc.
Separate roles from the definitions of things. For example, an “Employee” is a Person who is
employed by an Organization, such as a company. A “Vendor” is a Party who is a vendor in an Order.
![Page 5: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/5.jpg)
Copyright © 2014 David C. Hay 5
How to achieve flexibility and robustness . . .
Put as much of the language of the business as instances of ...type entity classes. This includes categories, like Activity Type and
Product Type.
Treat nearly all attributes as being multi-valued, requiring a separate entity class.For example, Party Characteristic, with an intersect
entity class Party Characteristic Value each instance of which contains a “Value” of a Party Characteristic for a particular Party.
Essential Data Model – General conceptsSuper-set of user views
![Page 6: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/6.jpg)
Copyright © 2014 David C. Hay
The End User’s view . . .
The end user, on the other hand deals with very concrete, particular things.
The user interface must reflect the way the user deals with things today.
The behavior of the system is an extension of the user’s behavior.
Ideally ‘e participated in the modeling and agreed with the overall concepts.
But those abstractions have little to do with today’s problems.
6
End User
![Page 7: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/7.jpg)
Copyright © 2014 David C. Hay 7
Designer’s Assignment . . .
Designers may not be experienced with models this abstract.
This paper is intended to present some of the more basic steps required to convert an essential data model into a database design.
It turns out that abstract models are implemented using the same steps as not so abstract models.
![Page 8: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/8.jpg)
Copyright © 2014 David C. Hay 8
Connections to System Users . . .
Conceptual Data Model – General conceptsSuper-set of user views
User Views – Concrete termsHabits and personal preferences
Database and Application DesignTrue to conceptual modelAccommodates technological limitsMakes user views possible
![Page 9: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/9.jpg)
Copyright © 2014 David C. Hay
UML Alert!
Both the Essential Data Model and the Relational Database Design shown here use constrained versions of the Unified Modeling Language.
Translation:
9
UML Symbol Essential Symbol
Design Symbol
Class Entity Type Table
Association Relationship Foreign Key
Attribute Attribute Column
Inheritance Sub-type (resolved)
![Page 10: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/10.jpg)
Copyright © 2014 David C. Hay 10
Four Steps to Design
1. Resolve sub-types.2. Perform default database design3. Design computed columns.4. De-normalize as necessary.5. Deal with those parameters.
![Page 11: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/11.jpg)
Copyright © 2014 David C. Hay 11
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. Deal with those parameters
![Page 12: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/12.jpg)
Copyright © 2014 David C. Hay 12
The Default Database Design . . .
Each entity class becomes a table.
Each attribute becomes a column.
Each primary identifier becomes a primary key. Each component of the identifier is a reference to a column in the table.
Each role on the “many” end of a relationship becomes a foreign key, composed of pointers to the columns in the other table’s primary key.
If a relationship from table A to table B was part of a unique identifier, the columns in table A that are the foreign key implementation of that relationship become part of the primary key for Table A.
![Page 13: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/13.jpg)
Copyright © 2014 David C. Hay
{id}
13
An Entity/Relationship Diagram . . .
Identifiers
![Page 14: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/14.jpg)
Copyright © 2014 David C. Hay 14
The Default Conversion . . .
Primary Keys
Foreign Key Columns
Foreign Keys
![Page 15: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/15.jpg)
Copyright © 2014 David C. Hay 15
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. Deal with those parameters
![Page 16: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/16.jpg)
Copyright © 2014 David C. Hay 16
Resolve sub-types
V1: One table for the super-type.All attributes from all sub-types become columns.Cannot meaningfully enforce mandatory columns.Requires adding “type” column.
V2: One table for each sub-type.Attributes for super-type plus sub-type form
columns for each sub-type table.Foreign keys for each relationship linked to super-
type in each sub-type table.
V3: CombinationsMost complex.Most “true”.
![Page 17: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/17.jpg)
Copyright © 2014 David C. Hay 17
For example, this model . . .
Implement Sub-types
Inherit super-type attributes
Collapse un-implemented sub-types
![Page 18: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/18.jpg)
Copyright © 2014 David C. Hay 18
Could be implemented, thus . . .
“Department number is only required if “Organization Type Name” is “Department”.
![Page 19: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/19.jpg)
Copyright © 2014 David C. Hay
Criteria
Relative frequency of sub-type retrieval? Who is going to do it?
Different populations?Different timings?
19
![Page 20: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/20.jpg)
Copyright © 2014 David C. Hay 20
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. Deal with those parameters
![Page 21: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/21.jpg)
Copyright © 2014 David C. Hay 21
Design Computed Columns . . .
Compute on input: if values are relatively stable, or if retrieval volume per day is significantly greater than update
volume. Maintenance is required to keep values consistent.
Compute on output: if values are relatively dynamic, or if retrieval volume is relatively low. Additional maintenance is unnecessary.
Kinds of calculations: Simple: A*B+C Inference: INFER-THRU (<relationship>,<parent entity>,
<target attribute>) Summation: SUM-THRU (<relationship>, <child entity>,
<target attribute>)
![Page 22: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/22.jpg)
Copyright © 2014 David C. Hay 22
For example, this model . . .
/PriceINFER-THRU (to buy, Product Type, Unit Price)/Value =Quantity * Price
/Contract Value =SUM-THRU (composed of, Line Item, Value)
/Total Sales to Date =SUM-THRU (bought via, Line Item, Value)
![Page 23: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/23.jpg)
Copyright © 2014 David C. Hay 23
Could be implemented thus . . .
Computed on input (and stored)
Computed on query*
* Note that translating the formula into, for example, a stored procedure, is left to the viewer.
![Page 24: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/24.jpg)
Copyright © 2014 David C. Hay 24
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. Deal with those parameters
![Page 25: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/25.jpg)
Copyright © 2014 David C. Hay 25
De-normalize (three methods) . . .
1. Inherit reference values.
2. Split tables horizontally (by instance).
3. Split tables vertically (by column).
![Page 26: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/26.jpg)
Copyright © 2014 David C. Hay 26
PARTY# GLOBAL IDENTIFIER* NAME
PARTY TYPE# NAME* DESCRIPTION
LINE ITEM# LINE NUMBER* QUANTITYo COST* (VALUE)
PHYSICAL ASSET SPECIFICATION# GLOBAL IDENTIFIER* DEFAULT NAME* DESCRIPTION* EFFECTIVE DATEo DISCONTINUE DATEo STANDARD PRICE* (TOTAL SALES VALUE)
CONTRACT# CONTRACT NUMBER* ISSUE DATE* (TOTAL VALUE)
PERSON
ORGANIZATION* DESCRIPTION
PRODUCT MATERIAL
GOVERNMENT
GOVERNMENTAGENCY
OTHERORGANIZATION
COMPANY
INTERNALORGANIZATION
an example of
embodied in
for
purchased via
a sub-type of
a super-type of
from
buyer in
composed of
part of
seller in
to
Inherit from reference tables . . .
buyer in
seller in
This model . ..
![Page 27: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/27.jpg)
Copyright © 2014 David C. Hay 27
Could be implemented as . . .
CONTRACTSCONTRACT_NUMBER(PK)ISSUE_DATETOTAL_VALUEBUYER_NAMESELLER_NAME
LINE_ITEMCONTRACT_NUMBER(FK)PRODUCT_NAMEQUANTITYCOSTSTANDARD_PRICEVALUE
![Page 28: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/28.jpg)
Copyright © 2014 David C. Hay
Note:
When replicating values, recognize the maintenance required to keep them consistent.
Note that the paradigm of INFER-THRU and SUM-THRU already anticipated this.
If these are implemented as dynamic columns, maintenance is automatic.
If they are implemented as static copies, maintenance must be added.
28
Have you heard this before?
Denormalization replicates
computed fields
![Page 29: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/29.jpg)
Copyright © 2014 David C. Hay 29
Split Horizontally (instances) . . .
For example, By Geographic Area
Some tables for North American customers Some tables for European customers Etc.
By Customer Type, etc. Some tables for corporate customers Some tables for individual customers Etc.
Note the problems that will arise if a significant number of customers (for example) fall into more than one category.
![Page 30: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/30.jpg)
Copyright © 2014 David C. Hay 30
Split Vertically (columns) . . .
For example, People with customer attributes
Annual sales Sales representative Etc.
People with employee attributes Social security number Employment date
Note that people with both kinds of attributes would appear redundantly in both tables.
![Page 31: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/31.jpg)
Copyright © 2014 David C. Hay 31
NOTE . . .
De-normalization optimizes some operations at the expense of others.
Test the effects before making them permanent.
Document the rationale for the de-normalization.
![Page 32: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/32.jpg)
Copyright © 2014 David C. Hay 32
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. Deal with those parameters.
![Page 33: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/33.jpg)
Copyright © 2014 David C. Hay 33
About those parameters . . .
Some entity classes (Party, for example) invariably have a lot of attributes.
And they change over time.
Their definitions change over time.
We need an alternative.
Define attributes as data.
Also called:
Characteristics,
Parameters,
Variables,
Etc.
Here’s an approach for Party, for example
![Page 34: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/34.jpg)
Copyright © 2014 David C. Hay 34
Party parameters as “Characteristics” . . .
PARTY CHARACTERISTIC:
“Height”“Number of employees”“Regulatory target”,Etc.
PARTY CHARACTERISTIC VALUE:
“Height” of “Jerry Smith” has CHARACTERISTIC VALUE of “6.1” (feet)…
according to “Jerry Smith”.
![Page 35: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/35.jpg)
Copyright © 2014 David C. Hay 35
Party Characteristic Constraints . . .NOTE: the CONTINUOUS PARTY CHARACTERISTIC “Height”
-- may only be used as a PARTY CHARACTERISTIC VALUE
-- for a PARTY that is an example of the PARTY TYPE “Person”.
![Page 36: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/36.jpg)
Copyright © 2014 David C. Hay 36
Designing those parameters . . .
While it is a powerful way of dealing with the complexity of data …
…the Parameter Model makes common manipulations harder, however.
Convert parameters that are . . . Relatively stable Not multi-valued (Over time?)
Do not convert parameters that are . . . Multi-valued Changeable over time and this must be reported.
![Page 37: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/37.jpg)
Copyright © 2014 David C. Hay 37
For example, in this model . . .
![Page 38: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/38.jpg)
Copyright © 2014 David C. Hay 38
These Characteristics:
Could be implemented as:
Can be implemented thus . . .
PEOPLEBIRTHDATE HEIGHT
PARTY CHARACTERISTIC
Name Description (Party Type)Birthdate The day the person appeared PersonHeight Vertical distance PersonAnnual Sales Average sales in a year CompanyTax ID IRS tax identifier Company
COMPANIESANNUAL SALES TAX IDENTIFICATION NUMBER
Bad idea!
![Page 39: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/39.jpg)
Copyright © 2014 David C. Hay 39
Four Steps to Design
1. Perform default database design
2. Resolve sub-types.
3. Design computed columns.
4. De-normalize as necessary.
5. About those parameters.
6. About those user views.
![Page 40: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/40.jpg)
Copyright © 2014 David C. Hay 40
In summary: About Those User Views . . .
The database designer need only balance data model integrity with performance issues.
The application designer must take the data as organized in a database and present it reasonably to each particular end user.
This requires skill in understanding both the database and the underlying data model.
![Page 41: Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.](https://reader035.fdocuments.us/reader035/viewer/2022070407/56649e1b5503460f94b09318/html5/thumbnails/41.jpg)
Copyright © 2014 David C. Hay 41
Questions . . . ?