Beginning Database Design- P16 doc

Seller_History Seller seller_id seller popularity_rating join_date address return_policy international payment_methods seller_id FK buyer comment_date listing# comments Buyer_History buy

Trang 1

In Figure 10-8, the relationship between the CATEGORY_PRIMARYand CATEGORY_SECONDARYtables is one-to-zero, one, or many What this means is that a CATEGORY_PRIMARYrecord can exist with no related CATEGORY_SECONDARYrecords On the contrary, a CATEGORY_SECONDARYrecord cannot exist unless it has a related parent CATEGORY_PRIMARYrecord Similarly, a seller does not have to have any history (SELLER_HISTORYrecords), but there will be no SELLER_HISTORYif there is no seller for that history to

be entered against

Figure 10-8: Parent records can exist and child records are not absolutely required (one-to-zero, one,

or many)

Child Records with Optional Parents

A table containing child records with optional parent records is often typical of data warehouse fact tables, such that not all dimensions need be defined for every fact This is especially true where facts stem from differing sources, such as BID in Figure 10-8 The result is some fact records with one or more NULLvalued foreign keys In Figure 10-8, a LISTINGtable record can be set as either being a secondary or a tertiary category Thus, the relationship between both CATEGORY_SECONDARYand CATEGORY_TERTIARYtables to that of LISTING, is zero or one-to-zero, one, or zero In other words, a listing can be specified as a secondary or a tertiary category (not both) The result is that for every LISTINGrecord, that either the SECONDARY_ID, or the TERTIARY_IDfields can be NULLvalued

Thus, LISTINGtable records can be said to have optional parents.

Optional parents are technically and more commonly known as NULLvalued foreign keys.

Seller_History

Seller seller_id seller popularity_rating join_date address return_policy international payment_methods

seller_id (FK) buyer comment_date listing#

comments

Buyer_History buyer_id (FK) seller comment_date listing# comments

Buyer buyer_id buyer popularity_rating join_date address

Category_Primary primary_id primary

secondary

Category_Secondary secondary_id primary_id (FK)

tertiary

Category_Tertiary tertiary_id secondary_id (FK)

Listing

buyer_id (FK) seller_id (FK) secondary_id (FK) tertiary_id (FK) description image start_date listing_days currency starting_price reserve_price buy_now_price number_of_bids winning_price Bid

buyer_id (FK) listing# (FK) bidder bid_price bid_date listing#

Trang 2

The OLTP Database Model with Referential Integrity

The final step in this section on enforcing table relationships is to create the tables In this version, all the primary and foreign keys to enforce referential integrity relationships are included This is a sample script for creating tables for the OLTP database model of the online auction house In this version, all primary and foreign key definitions are included, to enforce referential integrity:

CREATE TABLE CATEGORY_PRIMARY

(

PRIMARY_ID INTEGER PRIMARY KEY, PRIMARY STRING

);

CREATE TABLE CATEGORY_SECONDARY

(

SECONDARY_ID INTEGER PRIMARY KEY, PRIMARY_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_PRIMARY, SECONDARY STRING

);

CREATE TABLE CATEGORY_TERTIARY

(

TERTIARY_ID INTEGER PRIMARY KEY, SECONDARY_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_SECONDARY, TERTIARY STRING

);

The CATEGORY_ PRIMARYtable has no foreign keys The CATEGORY_TERTIARYtable has no link to the CATEGORY_PRIMARYtable, as a result of surrogate key use, and non-identifying relationships A foreign key specification references the parent table, not the parent table primary key The parent table already “knows” what its primary key field is.

CREATE TABLE SELLER

(

SELLER_ID INTEGER PRIMARY KEY, SELLER STRING,

POPULARITY_RATING INTEGER, JOIN_DATE DATE,

ADDRESS STRING, RETURN_POLICY STRING, INTERNATIONAL STRING, PAYMENT_METHODS STRING );

CREATE TABLE BUYER

(

BUYER_ID INTEGER PRIMARY KEY, BUYER STRING,

ADDRESS STRING );

The SELLERand BUYERtables are at the top of the hierarchy, so they have no foreign keys.

Trang 3

The SELLER_HISTORYand BUYER_HISTORYtables are incorrect as shown in Figure 10-8 because the lone foreign key is also the primary key With the structure as it is in Figure 10-8, each seller and buyer would

be restricted to a single history record each A primary key value must also be unique across all records for an entire table One solution is shown in Figure 10-9, with the script following it In Figure 10-9, the primary key becomes a composite of the non-unique SELLER_IDor BUYER_ID, plus a subsidiary SEQ#

(counting sequence number) The counting sequence number counts upwards from 1, for each seller and

buyer (with history records) So, if one buyer has 10 history entries, that buyers history SEQvalues would be 1 to 10, for those 10 records Similarly, a second buyer with 25 history records would have SEQ#fields values valued at 1 to 25

Figure 10-9: Non-unique table records become unique using subsidiary sequence auto counters

Following is the script for Figure 10-9:

CREATE TABLE SELLER_HISTORY (

SELLER_ID INTEGER FOREIGN KEY REFERENCES SELLER NOT NULL, SEQ# INTEGER NOT NULL,

BUYER STRING, COMMENT_DATE DATE, LISTING# STRING, COMMENTS STRING, CONSTRAINT PRIMARY KEY(SELLER_ID, SEQ#) );

Seller_History

seller_id (FK) seq#

buyer comment_date listing#

comments

Buyer_History buyer_id (FK) seq#

seller comment_date listing# comments

Category_Primary primary_id primary

secondary

Category_Secondary secondary_id primary_id (FK)

tertiary

Category_Tertiary tertiary_id secondary_id (FK)

Listing

buyer_id (FK) listing# (FK) bidder bid_price bid_date listing#

Trang 4

BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER NOT NULL, SEQ# INTEGER NOT NULL

SELLER STRING, COMMENT_DATE DATE, LISTING# STRING, COMMENTS STRING, CONSTRAINT PRIMARY KEY(BUYER_ID, SEQ#) );

The SELLER_ID, BUYER_IDand SEQ#fields have all been specifically declared as being NOT NULL This means that a value must be entered into these fields for the creation of a new record (or a change to

an existing record) All the fields in a composite (multiple field) primary key must be declared as NOT NULL This ensures uniqueness of the resulting composite primary key.

A primary key declared on more than one field (a composite key) cannot be specified inline with that

specific field definition This is because there is more than one field The primary key is declared out-of-line

to field definitions, as a specific constraint This forces the requirement for the NOT NULLspecifications of all the primary key fields.

Another more elegant but perhaps more mathematical and somewhat confusing solution is to create a surrogate key for the BUYER_HISTORYand SELLER_HISTORYtables as well The result is shown in Figure 10-10 The result is non-identifying relationships from SELLERto SELLER_HISTORY, and BUYER

toBUYER_HISTORYtables

Figure 10-10: Non-unique table records can become unique by using surrogate key auto counters

Seller_History

seller_history_id buyer_id (FK) seller_id (FK) comment_date comments

Buyer_History buyer_history_id seller_id (FK) buyer_id (FK) comment_date comments

Category_Primary

primary_id

primary

secondary

Category_Secondary

secondary_id

primary_id (FK)

tertiary

Category_Tertiary

tertiary_id

secondary_id (FK)

Listing

bidder_id (FK) listing# (FK) bid_price bid_date listing#

Trang 5

As a reminder, a non-identifying relationship is when the parent table primary key is not part of the pri-mary key in the child table A child table record is not specifically or uniquely identified by a child table record.

Further changes in Figure 10-10 are as follows:

❑ The addition of the relationships between SELLERto BUYER_HISTORYtables, and BUYERto SELLER_HISTORYtables Every history record of seller activity is related to something pur-chased from that seller (by a buyer) The same applies to buyers

❑ A buyer can be a seller as well, and visa versa This database model is beginning to look a little messy

Following is the script for changes introduced in Figure 10-10:

CREATE TABLE SELLER_HISTORY (

SELLER_HISTORY_ID INTEGER PRIMARY KEY, SELLER_ID INTEGER FOREIGN KEY REFERENCES SELLER, BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER, COMMENT_DATE DATE,

COMMENTS STRING );

CREATE TABLE BUYER_HISTORY (

BUYER_HISTORY_ID INTEGER PRIMARY KEY, BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER, SELLER_ID INTEGER FOREIGN KEY REFERENCES SELLER, COMMENT_DATE DATE,

COMMENTS STRING );

Figure 10-11 shows further refinement for the BIDtable Essentially, this section has included some specific analysis-design reworking Some things can’t be assessed accurately by simple analysis Don’t mistake the fiddling with relationships, and specific fields, for primary and foreign keys as normalization

or denormalization Note, however, that some extensive normalization has occurred merely by the establishment of one-to-many relationships This normalization activity has actually been performed from

an analytical perspective

Trang 6

Figure 10-11: Refining the BIDtable and related tables.

Figure 10-11 has essentially redefined the BIDtable and made a few other small necessary changes These changes all make analytical sense and don’t need normalization Potential buyers place bids on auction listings, but do not necessarily win the auction; however, the history of all bids for a listing needs to be retained The BIDtable, therefore, contains all bids for a listing, including all losing bids and the final winning bid The final winning bid is recorded as the winning bid, by setting the BUYER_IDfield in the LISTINGtable As a result, a losing buyer is not stored in the LISTINGtable as a buyer because he or she

is only a bidder (a buyer is only a bidder who wins the listing) The results are as follows:

❑ LISTINGto BIDis one-to-zero, one, or many — A listing that has just been listed is likely to have

no bids Also, an unpopular listing may have no bids placed over the life of the auction listing

It is still a listing, but it has no bids

❑ BUYERto LISTINGis zero or one to zero, one, or many — A losing buyer is only a bidder and not the

winning bidder Losing bidders are not entered into the LISTINGtable as buyers because they lost the auction

You don’t actually have to apply the rules of normalization, using Normal Forms, to

create a first pass of a database model So far, it’s all been common sense This is one

of the reasons why these final chapters are presented as a case study example This

case study is not an application of theory, by applying normalization and Normal

Forms, to a bucket of information A bucket of information implies a whole pile of

things thrown into a heap, on the floor in front of you.

Seller_History

seller_history_id buyer_id (FK) seller_id (FK) comment_date comments

Buyer_History buyer_history_id seller_id (FK) buyer_id (FK) comment_date comments

Category_Primary

primary_id

primary

secondary

Category_Secondary

secondary_id

primary_id (FK)

tertiary

Category_Tertiary

tertiary_id

secondary_id (FK)

Listing

bidder_id (FK) listing# (FK) bid_price bid_date listing#

Trang 7

❑ BUYERto BIDis one-to-one or many (zero is not allowed) — A bid cannot exist without a potential

buyer This item is not a change, but listed as a reinforcing explanation of said relationships between BID, BUYER, and LISTINGtables

The result is the following script for creating the LISTINGand BIDtables:

CREATE TABLE LISTING (

LISTING# STRING PRIMARY KEY, BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER WITH NULL, SELLER_ID INTEGER FOREIGN KEY REFERENCES SELLER,

SECONDARY_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_SECONDARY WITH NULL, TERTIARY_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_TERTIARY WITH NULL, DESCRIPTION STRING,

IMAGE BINARY, START_DATE DATE, LISTING_DAYS INTEGER, CURRENCY STRING, STARTING_PRICE MONEY, RESERVE_PRICE MONEY, BUY_NOW_PRICE MONEY, NUMBER_OF_BIDS INTEGER, WINNING_PRICE MONEY );

The BUYER_IDfield is specified as a WITH NULLforeign key, indicating that LISTINGrecords only contain the BUYER_IDfor the winning bidder If no one bids, then a LISTINGrecord will never have a

BUYER_IDvalue The SECONDARY_IDand TERTIARY_IDcategory fields are also listed as WITH NULLforeign key fields because either is allowed (not both).

CREATE TABLE BID (

BIDDER_ID INTEGER FOREIGN KEY REFERENCES BIDDER, LISTING# INTEGER FOREIGN KEY REFERENCES LISTING, BID_PRICE MONEY,

BID_DATE DATE, CONSTRAINT PRIMARY KEY(BIDDER_ID, LISTING#) );

CREATE TABLEcommands would have to be preceded by DROP TABLEcommands for all tables, preferably

in reverse order to that of creation Some databases will allow changes to primary and foreign keys using

ALTER TABLEcommands Some databases even allow these changes directly into an ERD GUI tool.

Microsoft Access allows these changes to be made very easily, using a GUI.

The Data Warehouse Database Model with Referential Integrity

The data warehouse database model for the online auction house is altered slightly in Figure 10-12, including addition of surrogate primary keys to all tables All of the dimensional-fact table relationships are zero or one, to zero, one, or many This indicates that the fact table contains a mixture of multiple fact sources (multiple transaction types, including listings, bids, and histories) Essentially, a fact table does not

Trang 8

absolutely have to contain all fields from all records, for all facts In other words, fact records do not always have to contain location (LOCATIONtable) information, for example The LOCATIONtable LOCATION_ID foreign key in the fact table can contain NULLvalues

Figure 10-12: The data warehouse database model ERD

Location location_id region country state city

Time time_id month quarter year

Category_Hierarchy category_id parent_id category

Listing_Bids_History fact_id

time_id (FK) buyer_id (FK) location_id (FK) seller_id (FK) category_id (FK) listing#

listing_description listing_image listing_start_date listing_days listing_currency listing_starting_price listing_reserve_price listing_buy_now_price listing_number_of_bids listing_winning_price listing_winner_buyer bidder

bidder_price bidder_date history_buyer history_buyer_comment_date history_buyer_comments history_seller

history_seller_comment_date history_seller_comments

Trang 9

A script to create the tables shown in Figure 10-12 is as follows:

CREATE TABLE CATEGORY_HIERARCHY (

CATEGORY_ID INTEGER PRIMARY KEY, PARENT_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_HIERARCHY WITH NULL, CATEGORY STRING

);

The PARENT_IDfield points at a possible parent category If there is no parent, then the PARENT_IDis

NULLvalued (WITH NULL) Primary categories will have NULLvalued PARENT_IDfields.

Data warehouse database model SELLERand BUYERtables are the same as for the OLTP database model:

CREATE TABLE SELLER (

SELLER_ID INTEGER PRIMARY KEY, SELLER STRING,

ADDRESS STRING, RETURN_POLICY STRING, INTERNATIONAL STRING, PAYMENT_METHODS STRING );

CREATE TABLE BUYER (

BUYER_ID INTEGER PRIMARY KEY, BUYER STRING,

ADDRESS STRING );

The LOCATIONand TIMEtables are as follows:

CREATE TABLE LOCATION (

LOCATION_ID INTEGER PRIMARY KEY, REGION STRING,

COUNTRY STRING, STATE STRING, CITY STRING );

CREATE TABLE TIME (

TIME_ID INTEGER PRIMARY KEY, MONTH STRING,

QUARTER STRING, YEAR STRING );

Trang 10

Finally, the single fact table has optional dimensions for all but sellers, and thus all foreign keys (except the SELLER_IDforeign key) are declared as WITH NULLfields:

CREATE TABLE LISTING_BIDS_HISTORY

(

FACT_ID INTEGER PRIMARY KEY, CATEGORY_ID INTEGER FOREIGN KEY REFERENCES CATEGORY_HIERARCHY WITH NULL, TIME_ID INTEGER FOREIGN KEY REFERENCES TIME WITH NULL,

LOCATION_ID INTEGER FOREIGN KEY REFERENCES LOCATION WITH NULL, BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER WITH NULL, SELLER_ID INTEGER FOREIGN KEY REFERENCES SELLER,

);

That is how referential integrity is enforced using primary and foreign keys There are other ways of enforcing referential integrity, such as using stored procedures, event triggers, or even application code These methods are, of course, not necessarily built in database model business rules Even so, primary and foreign keys are a direct application of business rules in the database model and thus are the only relevant topic

So, where do normalization and denormalization come in here?

Normalization and Denormalization

Normalization divides things up into smaller pieces Denormalization does the opposite of

normaliza-tion by reconstituting those little-bitty pieces back into larger pieces When implementing normalizanormaliza-tion

and denormalization, there are a number of general conceptual approaches to consider:

❑ Don’t go overboard with normalization for an OLTP database model

❑ Don’t be afraid to denormalize, even in an OLTP database model

❑ Generally, an OLTP database model is normalized and a data warehouse model is denormalized Doing the opposite to each database model is usually secondary, and usually as a result of going too far initially, in the opposite direction

❑ An OLTP database model should be normalized and a data warehouse database model should

be denormalized, where appropriate

At this stage, to maintain the case study approach, it makes sense to continue with use of the online auction company to go through the normalization and denormalization process in detail Use of the term “detail” implies going through the whole process from scratch once again, as for analysis in Chapter 9, but

executing the process using the mathematical approach (normalization), rather than the analytical

approach

Định dạng
Số trang	20
Dung lượng	725 KB