Beginning Database Design- P21 pot

LISTING_NUMBER_OF_BIDS INTEGER FORMAT “999” NULL,LISTING_WINNING_PRICE MONEY NULL, LISTING_BID_INCREMENT MONEY NULL, BID_PRICE MONEY NULL ; The LISTING_NUMBER_OF_BIDSis output formatted

LISTING_NUMBER_OF_BIDS INTEGER FORMAT “999” NULL,

LISTING_WINNING_PRICE MONEY NULL, LISTING_BID_INCREMENT MONEY NULL, BID_PRICE MONEY NULL );

The LISTING_NUMBER_OF_BIDSis output formatted as for number of bids in the OLTP database model LISTINGtable

Encoding Business Rules

As with the previous section covering individual field business rules, this section covers the case study online auction house database models, but this time attempting to encode a few things into a pseudo database programming language The intention here is to demonstrate what can be done It is a matter for some debate among computer professionals as to whether business rules should be written into stored procedures Some think implementing business rules in stored procedures is good for some rea-sons Others consider that applications handle this type of complexity more effectively and efficiently Encoding Business Rules for the OLTP Database Model

You already know the difference between a stored procedure, a stored function, and an event-based trig-ger What can be done to the OLTP database model for this case study, to utilize some type of database stored coding? The BIDtable is a good candidate for some basic stored functions:

CREATE TABLE BID (

LISTING# CHAR(10) NOT NULL, BUYER_ID INTEGER FOREIGN KEY REFERENCES BUYER NOT NULL, BID_PRICE MONEY

CHECK(VERIFY_BID(LISTING#, BID_PRICE))

NOT NULL, PROXY_BID MONEY

CHECK(PROXY_BID > BID_PRICE AND VERIFY_BID(LISTING#, PROXY_BID))

NULL,

BID_DATE DATE FORMAT “DD MON, YEAR” NOT NULL,

CONSTRAINT PRIMARY KEY (LISTING#, BUYER_ID) );

The preceding script has a CHECKconstraint on the BID_PRICEand PROXY_BIDfields Both of these CHECKconstraints execute a function A bid price is entered by a bidder That bid price must exceed the starting and current prices, both of which are stored in the listing table This can be encoded using a stored function as follows:

CREATE FUNCTION VERIFY_BID(LISTNUM CHAR(10), BID MONEY DEFAULT NULL) RETURN BOOLEAN

DECLARE START_PRICE MONEY;

373

Business Rules and Field Settings

CURR_PRICE MONEY;

BEGIN

REMARK - Throw out bids that are incorrectly passed in

IF LISTING# IS NULL OR BID IS NULL OR BID <= 0 THEN RETURN FALSE;

REMARK – bidding price (including proxy bids) must exceed starting price REMARK – if current price is NULL, otherwise must exceed current price SELECT STARTING_PRICE, CURRENT_PRICE

INTO START_PRICE, CURR_PRICE FROM LISTING WHERE LISTING# = LISTNUM;

IF CURR_PRICE IS NULL THEN

IF BID <= START_PRICE THEN RETURN FALSE;

ELSE

IF BID <= CURR_PRICE THEN RETURN FALSE;

END IF;

RETURN TRUE;

END;

The preceding script applies to both normal (regular) bids and to proxy bids as well A proxy bid must always be greater than the current bid price; otherwise, the proxy bid is just a normal bid A proxy bid is where a buyer sets a maximum price that they will bid to Whenever other bidders place bids, the system automatically increments the highest bid price with the current increment, until the proxy bid is reached

If the competing bidder exceeds the proxy bid, the other buyer becomes the current highest bidder Encoding Business Rules for the Data Warehouse Database Model

In short, there is nothing that you would want to attach to a data warehouse database model in the form

of database model embedded coding, acting on the database model structures It would simply be con-trary to the existence of a data warehouse

Figure 12-8 shows an ERD for the musicians OLTP database model Here’s a basic approach to business rules field settings:

1. Individual field business rules (including defaults, CHECKconstraints, display formats, and input masks)

2. Encoding business rules using some kind of stored database coding, if and where appropriate

(usually CHECKconstraint functions)

374

Chapter 12

Figure 12-8: Musicians, bands, online advertisements OLTP database model.

How It Works There are no appropriate CHECKconstraints and no appropriate stored encoding This script contains appropriate changes:

CREATE TABLE INSTRUMENT (

INSTRUMENT_ID INTEGER PRIMARY KEY NOT NULL, SECTION_ID INTEGER FOREIGN KEY REFERENCES INSTRUMENT WITH NULL, INSTRUMENT CHAR VARYING(32) UNIQUE NOT NULL

);

CREATE TABLE GENRE (

GENRE_ID INTEGER PRIMARY KEY NOT NULL, PARENT_ID INTEGER FOREIGN KEY REFERENCES GENRE WITH NULL, GENRE CHAR VARYING(32) UNIQUE NOT NULL

);

CREATE TABLE VENUE

Musician musician_id instrument_id (FK) band_id (FK) musician phone email skills

Advertisement advertisement_id band_id (FK) musician_id (FK) date

text

Band band_id genre_id (FK) band founding_date

Venue venue_id location address_line_1 address_line_2 town

zip postal_code country directions phone

Merchandise merchandise_id band_id (FK) type price

Show show_id band_id (FK) venue_id (FK) date time

Genre genre_id parent_id (FK) genre

Instrument instrument_id section_id (FK) instrument

Discography discography_id band_id (FK) cd_name release_date price

375

Business Rules and Field Settings

VENUE_ID INTEGER PRIMARY KEY NOT NULL, LOCATION CHAR VARYING(32) UNIQUE NOT NULL, ADDRESS_LINE_1 CHAR VARYING(32) NOT NULL, ADDRESS_LINE_2 CHAR VARYING(32) NULL, TOWN CHAR VARYING(32) NOT NULL,

ZIP NUMBER(5) FORMAT “99999” MASK “99999” NULL,

POSTAL_CODE CHAR VARYING(32) NULL, COUNTRY CHAR VARYING(32) NULL, DIRECTIONS MEMO NULL,

PHONE CHAR VARYING(32) NULL );

CREATE TABLE MERCHANDISE

(

MERCHANDISE_ID INTEGER PRIMARY KEY NOT NULL, BAND_ID INTEGER FOREIGN KEY REFERENCES BAND NOT NULL, TYPE CHAR VARYING(32) UNIQUE NOT NULL,

PRICE MONEY FORMAT “$9,999,990.99” MASK “9999990.00” NOT NULL

);

CREATE TABLE DISCOGRAPHY

(

DISCOGRAPHY_ID INTEGER PRIMARY KEY NOT NULL, BAND_ID INTEGER FOREIGN REFERENCES BAND NOT NULL, CD_NAME CHAR VARYING(32) NOT NULL,

RELEASE_DATE DATE FORMAT “DD MON, YEAR” MASK “MM/DD/YYYY” NOT NULL, PRICE MONEY FORMAT “$9,999,990.99” MASK “9999990.00” NOT NULL

);

CREATE TABLE SHOW

(

SHOW_ID INTEGER PRIMARY KEY NOT NULL, BAND_ID INTEGER FOREIGN KEY REFERENCES BAND NOT NULL, VENUE_ID INTEGER FOREIGN KEY REFERENES VENUE NOT NULL,

DATE DATE FORMAT “DD MON, YEAR” MASK “MM/DD/YYYY” NOT NULL,

TIME CHAR VARYING(16)

FORMAT “90:90:90” MASK “90:90:90”

NOT NULL );

CREATE TABLE BAND

(

BAND_ID INTEGER PRIMARY KEY NOT NULL, GENRE_ID INTEGER FOREIGN KEY REFERENCES GENRE NOT NULL, BAND CHAR VARYING(32) UNIQUE NOT NULL,

FOUNDING_DATE DATE FORMAT “DD MON, YEAR” MASK “MM/DD/YYYY” NOT NULL

);

CREATE TABLE MUSICIAN

(

MUSICIAN_ID INTEGER PRIMARY KEY NOT NULL, INSTRUMENT_ID INTEGER FOREIGN KEY REFERENCES INSTRUMENT NOT NULL, BAND_ID INTEGER FOREIGN KEY REFERENCES BAND WITH NULL, MUSICIAN CHAR VARYING(32) UNIQUE NOT NULL,

PHONE CHAR VARYING(32) NULL,

376

Chapter 12

EMAIL CHAR VARYING(32) NULL, SKILLS CHAR VARYING(256) NULL );

CREATE TABLE ADVERTISEMENT (

ADVERTISEMENT_ID INTEGER PRIMARY KEY NOT NULL, BAND_ID INTEGER FOREIGN KEY REFERENCES BAND WITH NULL, MUSICIAN_ID INTEGER FOREIGN KEY REFERENCES MUSICIAN WITH NULL,

DATE DATE FORMAT “DD MON, YEAR” MASK “MM/DD/YYYY” NOT NULL,

TEXT MEMO NOT NULL );

Figure 12-9 shows an ERD for the musician’s data warehouse database model Here’s a basic approach

to business rules field settings:

1. Individual field business rules (including defaults, CHECKconstraints, display formats, and input masks)

2. Encoding business rules using some kind of stored database coding, if and where appropriate

(usually CHECKconstraint functions)

Figure 12-9: Musicians, bands, and their online advertisements data warehouse database model

Artists artist_id

merchandise_id (FK) genre_id (FK) instrument_id (FK) musician_name musician_phone musician_email band_name band_founding_date discography_cd_name discography_release_date discography_price show_date show_time venue_name venue_address venue_directions venue_phone advertisement_date advertisement_text

Genre

genre_id parent_id (FK) genre

Merchandise

merchandise_id type

price

Instrument

instrument_id section_id (FK) instrument

377

Business Rules and Field Settings

How It Works

There are no appropriate CHECKconstraints and no appropriate stored encoding Remember that input

to a data warehouse is unlikely to be manual input, so input MASKsettings and CHECKconstraints gener-ally do not apply Additiongener-ally, UNIQUEconstraints are not needed either (they are overhead) when data

is application generated anyway This script contains appropriate changes:

CREATE TABLE INSTRUMENT

(

INSTRUMENT_ID INTEGER PRIMARY KEY NOT NULL, SECTION_ID INTEGER FOREIGN KEY REFERENCES INSTRUMENT WITH NULL, INSTRUMENT CHAR VARYING(32) NOT NULL

);

CREATE TABLE MUSICIAN

(

MUSICIAN_ID INTEGER PRIMARY KEY NOT NULL, MUSICIAN CHAR VARYING(32) NOT NULL, PHONE CHAR VARYING(32) NULL, EMAIL CHAR VARYING(32) NULL );

CREATE TABLE GENRE

(

GENRE_ID INTEGER PRIMARY KEY NOT NULL, PARENT_ID INTEGER FOREIGN KEY REFERENCES GENRE WITH NULL, GENRE CHAR VARYING(32) NOT NULL

);

CREATE TABLE BAND

(

BAND_ID INTEGER PRIMARY KEY NOT NULL, BAND CHAR VARYING(32) NOT NULL,

FOUNDING_DATE DATE FORMAT “DD MON, YEAR” NOT NULL

);

CREATE TABLE ADVERTISEMENT

(

ADVERTISEMENT_ID INTEGER PRIMARY KEY NOT NULL,

DATE DATE FORMAT “DD MON, YEAR” NOT NULL,

TEXT MEMO NOT NULL );

CREATE TABLE DISCOGRAPHY

(

DISCOGRAPHY_ID INTEGER PRIMARY KEY NOT NULL, CD_NAME CHAR VARYING(32) NOT NULL,

RELEASE_DATE DATE FORMAT “DD MON, YEAR” NULL, PRICE MONEY FORMAT “$9,999,990.99” NULL

);

CREATE TABLE MERCHANDISE

(

MERCHANDISE_ID INTEGER PRIMARY KEY NOT NULL, TYPE CHAR VARYING(32) NOT NULL,

378

Chapter 12

PRICE MONEY FORMAT “$9,999,990.99” NOT NULL

);

CREATE TABLE SHOW_VENUE (

SHOW_ID INTEGER PRIMARY KEY NOT NULL, LOCATION CHAR VARYING(32) NOT NULL, ADDRESS_LINE_1 CHAR VARYING(32) NOT NULL, ADDRESS_LINE_2 CHAR VARYING(32) NULL, TOWN CHAR VARYING(32) NOT NULL, ZIP NUMBER(5) FORMAT “99999” NULL, POSTAL_CODE CHAR VARYING(32) NULL,

COUNTRY CHAR VARYING(32) NULL, DIRECTIONS MEMO NULL,

PHONE CHAR VARYING(32) NULL

SHOW_DATE DATE FORMAT “$9,999,990.99” NOT NULL, SHOW_TIME CHAR VARYING(16) FORMAT “90:90:90” NOT NULL

);

CREATE TABLE FACT (

FACT_ID INTEGER NOT NULL, SHOW_ID INTEGER FOREIGN KEY REFERENCES SHOW WITH NULL, MUSICIAN_ID INTEGER FOREIGN KEY REFERENCES MUSICIAN WITH NULL, BAND_ID INTEGER FOREIGN KEY REFERENCES BAND WITH NULL, ADVERTISEMENT_ID INTEGER FOREIGN KEY REFERENCES ADVERTISEMENT

WITH NULL, DISCOGRAPHY_ID INTEGER FOREIGN KEY REFERENCES DISCOGRAPHY

WITH NULL, MERCHANDISE_ID INTEGER FOREIGN KEY REFERENCES MERCHANDISE

WITH NULL, GENRE_ID INTEGER FOREIGN KEY REFERENCES GENRE WITH NULL, INSTRUMENT_ID INTEGER FOREIGN KEY REFERENCES INSTRUMENT WITH NULL,

CD_SALE_AMOUNT MONEY FORMAT “$9,999,990.99” NULL, MERCHANDISE_SALE_AMOUNT MONEY FORMAT “$9,999,990.99” NULL, ADVERTISING_COST_AMOUNT MONEY FORMAT “$9,999,990.99” NULL, SHOW_TICKET_SALES_AMOUNT MONEY FORMAT “$9,999,990.99” NULL

);

Summar y

In this chapter, you learned about:

❑ How basic database model business rules classifications are normalization, Normal Forms, tables, and relations

❑ How more complex business rules can be implemented in a database model using field settings, such as display FORMATs, input MASKings, CHECKconstraints, UNIQUEkey constraints, and DEFAULTsettings

❑ How stored database code can be used to implement highly complex business rules, using stored procedures, stored functions and event triggers

379

Business Rules and Field Settings

This chapter ends the case study of the OLTP and data warehouse database models using the online auc-tion house This chapter has refined the implementaauc-tion of business rules to the hilt by applying field-level attributes and settings as being part of table field structure Additionally, very advanced business rules can be applied using stored database coding (encoding) The next chapter discusses hardware resources, as applied to database modeling

380

Chapter 12

Part IV

Advanced Topics

In this Par t:

Chapter 13: Advanced Database Structures and Hardware Resources

Advanced Database Str uctures and Hardware

Resources

This final chapter of this book wraps up the database modeling design process, delving a bit into some advanced aspects of the implementation process Implementation is essentially the actual database building process When you build a database, as opposed to just the database model, you create the database itself During the database-creation process, implementing the database model, you might want to consider various other factors These other factors include specialized database model structures (other than tables and indexes) Additionally, there are certain hardware issues such as how big of a computer do you need? Other than hardware, there are certain database installation issues to consider, with respect to configuration Configuration can affect various fac-tors, such as how fast your database ultimately performs Or how much recoverability do you need? How often should backups be executed?

Configuration is computer jargon used to describe the way in which a computer system, or part thereof (such as a database) is installed and set up For example, when you start up a Windows com-puter, all your desktop icons are part of the configuration of you starting up your computer What the desktop icons are, and where on your desktop they are placed, are stored in a configuration file

on your computer somewhere When you start up your computer, the Windows software retrieves that configuration file, interprets its contents, and displays all your icons on the screen for you.

This chapter essentially appears at the culmination of database model analysis and design; how-ever, its contents should in the very least be considered as a part of the design process, before going ahead and purchasing hardware, and creating the physical database itself

By the end of this chapter, you will realize that database modeling is not just about creating tables, getting the correct relationships between them, and doing lots of hairy stuff with fields Between the database modeling phase and the creation of a database, you might want to consider material-ized views for a data warehouse, for example Or, perhaps you might consider a specialmaterial-ized type

of hardware configuration using something called a RAID array

In this chapter,you learn about the following:

❑ Views

❑ Materialized views

❑ Different types of indexes

❑ Auto counters

❑ Partitioning and parallel processing

❑ Hardware factors (including memory usage, as applied to OLTP or data warehouse databases)

❑ RAID arrays

❑ Standby databases

❑ Replication

❑ Grid computing and clustering

Advanced Database Str uctures

This section covers those logical objects in a relational database, either overlaying one or more tables or making duplicates of records in one or more tables Objects of interest are views, materialized views, index types and clustering, auto counters, and, finally, partitioning and parallel processing

What and Where?

“What and where” implies what objects can be used, and in which scenarios These specialized objects

do fall under the guise of database modeling design because they are generally used to enhance a database model, and its attendant applications, in one way or another Enhancements imply easier usability, easier access, controlled access, better performance, and the list goes on Examine the practical applications of each of these additional specialized database objects in turn, in terms of where they can and should be used

Views

A view overlays underlying records in tables It does not copy records from tables A view contains a

query that reads underlying tables when the view is accessed, and is accessed in a query in exactly the same way that a table is

Views can cause performance problems because they are often inappropriately used The most appropri-ate use of views is to implement table and field level security You can restrict users to examining only specific fields in a table, for example One of the most problematic uses of views is to ease and speed the development process What typically happens is that developers will use a view, and filter over the top

of the view with WHEREclauses If the view executes a full table scan, even a single record retrieved from

a view accessing 1 million records from an underlying table will still effectively read all 1 million records That’s a serious waste of resources!

Materialized Views

A materialized view copies records from one or more underlying tables Unlike a view, when a query is

executed against a materialized view, the materialized view is physically accessed, rather than the underlying tables

384

Chapter 13