Beginning Database Design- P20 ppt

Business rules are implemented into a database model by creating tables, establishing relationships between tables, identifying fields, their datatypes, and various other factors includi

Business Rules and

F ield Settings

“In business or in life, don’t follow the wagon tracks too closely.” (H Jackson Brown)

Database modeling analysis and design are an art form Use your imagination and you might find that,

sometimes rules are made to be bent — if not broken altogether

This chapter covers the deepest layer of implementation into a database model — business rules Business rules are implemented into a database model by creating tables, establishing relationships between tables, identifying fields, their datatypes, and various other factors including things such

as validation Field settings including display formats, input maskings, default values, and check constraints are included There is also a brief section on applying business rules by way of storing code in the database model

This chapter is the last of four chapters using the case study example of the online auction house

By reading through the last few chapters and this one, you should have a good idea of the analysis and design process for both OLTP and data warehouse database models, all the way through from start to finish

By the end of this chapter, you should know how to apply field setting business rules in the extreme, and also that this extreme might be best left to application Software Development Kits (SDKs) Application SDKs are much more powerful than database modeling methods when it comes to number crunching, and some of the more detailed aspects of database modeling

In this chapter, you learn about the following:

❑ Database model business rules classification

❑ Implementation of business rules can be implemented as table and relations (links between tables) design

❑ Using individual field settings as applications of deeper level business rules

❑ Using stored database code to implement highly complex business rules

What Are Business Rules Again?

When applied as a database model, the business rules of a company become the structure of that database model The most basic implementation of business rules in a database model, are the tables, relationships between those tables, and even constraint rules, such as validation checks Validation checks apply to individual fields For example, a field called SEXcan be restricted to having values of M for Male and Ffor Female Insisting that a field only be set to Mor Fis a business rule, applied to the field SEX Now I should have your full attention!

The application of normalization and Normal Forms to a set of not yet normalized data tables, applies

a progressively more complex implementation of business rules, as you apply the successive Normal Form layers to the data set — 1NF, 2NF, 3NF, and so on

As already seen previously in this book, a definition of the term business rules appears to be somewhat

open to debate Technically speaking, business rules require that intra-table and inter-table validation be placed into a database model Database implementation of business rules includes validation for some

or all fields in tables Even any type of coding stored and executed within the bounds of a database engine is, technically speaking, business rules implementation So business rules are not just about nor-malization, Normal Forms, and field validation checks Business rules are also about stored procedures

Number crunching is computer jargon for large quantities of extremely complex calculations

An object database model can encapsulate processing into class methods A relational database can use stored (database) procedures and event or rule triggers to perform a similar function to that of object class methods For the purposes of efficiency, it is usually best to avoid business rules in the database, unless they are included within the relationship structure of the database itself You don’t want to go too far in forcing business rules implementation into a database model The most efficient implementation

of business rules in a database model is anything non-coded and non-field-specific validation (valida-tion checks or CHECKconstraints) The only business rules that should absolutely be implemented in a database model is referential integrity (primary keys, foreign keys, and their representative inter-table relationships) Other layers can be, but are not strictly necessary

So, it should be clear that implementing all types and layers of business rules into a database model may not the most prudent approach As already stated, the most effective and efficient implementation of business rules in a database model is that of referential integrity Other, deeper and more complex layers

of business rules implementation are more often than not far more effectively managed in application

A stored procedure is a chunk of code stored in a database — ostensibly to execute

against data stored in one or more tables In other words, the function of a stored

procedure should be directly associated with some data in a database On the

con-trary, the function of a stored procedure is not always directly associated with data

in a database This would not be an implementation of business rules Business

rules in a database model imply company operations as applied to data In other

words, not all stored procedures are an implementation of business rules Stored

procedures can implement number crunching as well.

coding Why? Database models need to avoid number crunching processing Application SDKs such as the Java SDK (incorporating the Java programming language) simply excel at managing large numbers

of hugely complex calculations

Excluding number-crunching processing from a database model applies to relational databases only Quite to the contrary, object databases (object database modeling) are as adept at number crunching as

an SDK such as Java is In fact, an object database may even be more adept at complexity than a front-end application SDK such as Java An object database is a data-processing tool, not weighed down with all the GUI bits and pieces that Java is

Classifying Business Rules

in a Database Model Previously in this book, business rules have been classified from an operational perspective Now clas-sify business rules, and their implementation in a relational database model, according to the sequence

in which they are implemented in a database model

Normalization, Normal Forms, and Relations

Applying the normal form layers of normalization to a set of data applies business rules to that data For example, a trucking company, owning many trucks, has trucks on the road with loads, and other trucks

in a depot undergoing maintenance for two weeks Over a period of a week, the trucks on the road could be hauling one or more loads Trucks undergoing maintenance have not necessarily hauled any loads in the last two weeks These points are important:

❑ There is potentially more than one load hauled, per truck, over the two-week period

❑ Trucks always exist as either being on the road and working, or in a depot undergoing maintenance

❑ Trucks in the maintenance depot haul nothing

The following implement the previous operational facts as business rules:

❑ The relationship between trucks and loads is one-to-many The one-to-many relationship imple-ments the business rule between trucks and hauled loads

❑ Trucks must always be defined as one and only one

❑ Trucks being maintained are hauling nothing, and thus have no loads; therefore, loads are defined as zero, one, or many This implies that each truck could have one load, many loads, or

no loads at all; therefore, the one-to-many relationship between trucks and loads is more spe-cific, as being, one and only one, to zero, one or many

That’s a simple form of implementing business rules for a trucking company and its hauled loads over a two-week period Figure 12-1 shows an equivalent database model ERD representation

Figure 12-1: Trucks are related to hauled loads as one to zero, one or many.

Classifying Relationship Types

The ERD shown in Figure 12-1 demonstrates a one to zero, one, or many relationship between trucks and the loads they haul You can see that relationships are not only classified as one containing many, but also, more specifically, where a related item is not necessarily required (represented by zero) In general, relationships are classified as follows:

❑ One-to-many — This is the most common and usually represents a 1NF master detail

relation-ship, or a 2NF static-to-transactional referential relationship (dimensional to fact table, in a data warehouse database model)

❑ One-to-one — These are common of the higher Normal Forms beyond 3NF, where perhaps less

commonly used fields are separated out to new tables

❑ Many-to-many — This relationship represents an unresolved relationship between two tables.

For example, students in a college can take many courses at once So, a student can be enrolled

in many courses at once, and a course can contain many enrolled students The solution is to resolve the many-to-many relationship into three, rather than two tables Each of the original tables is related to the new table as a one-to-many relationship, allowing access to unique records (in this example, unique course and student combinations)

Zero can apply to a many-to-many relationship, such as a course with no enrolled students This is

unusual, quite probably pointless and, therefore, usually ignored.

One-to-many and one-to-one relationships can have either side of their specifications set as zero So, all the following combinations are valid:

❑ One or zero, to one or many — For example, publishers publish many books Some books are

self-published (no publisher) A publisher has to publish at least one book to be called a publisher; therefore, a publisher can’t exist without at least one book published, and a book can exist with-out a publisher

Load

load_id truck_id (FK) load_type load_content origination_city destination_city origination_date destination_date weight

Truck

truck_id driver_id (FK) truck_type last_maintenance_date

A load has to be transported by a truck

A load can’t drive itself!

Trucks do not always have loads Maintenance requires

a truck to be sitting still

❑ One to zero, one, or many — In this case, a publisher does not have to publish any books to be called

a publisher Also, self-publishing is not allowed — perhaps the author becomes the publisher

❑ One or zero to one, many, or zero — In this case, a publisher is called a publisher, even if no books

are published Also, self-publishing with no publisher is allowed

All these combinations apply to one-to-one relationships, as for one-to-many relationships, except that many is prohibited

You can see that business rules are implemented in a relational database model using normalization (Normal Forms), the relationships established between tables, and even down to the specific value allowances, by the ends of each relationship (the crow’s foot)

Explicitly Declared Field Settings

This topic area includes NULLvalues, uniqueness, and individual field settings (validation checks are included) You begin with NULLvalues and uniqueness, as these are simple:

❑ NULLand default values —NULLvalue requirements can be set for each field and are usually coded in data definition language (DDL) commands as NULL, NOT NULL, or WITH NULL The default setting is usually NULLfor any field with nothing specified WITH NULLis often not nec-essary This is not the case for all database engines Ingres 6.04 defaulted to NOT NULL, requiring explicit declaration of WITH NULLto allow NULLvalues into fields NULLsimply means that a field does not have to have a value entered when a record is inserted into (or updated in) a table NOT NULLis completely the opposite and always requires a value If inserting or updating,

a field specified as NOT NULLis not specified (insertion), or is set to NULL(updating), an error should be returned by the database

❑ Default values — This is an interesting one because when a record is added to a table, if nothing

is specified for a NOT NULLset field, then the default value is added to the NOT NULLfield This can somewhat restrict the purpose of specifying a field as NOT NULL For example, a primary key field is always NOT NULLby default Setting a default insertion value for an auto counter surro-gate primary key field not specified in an insertion could ignore the auto counter, and produce

an out of sequence, or worse, a duplicated surrogate key value Default value settings are more often utilized in power-user type database engines such as Microsoft Access, rather than SQL Server or Oracle Database

A power user is a user who is between an end-user and an expert computer programmer, in terms of knowing how to use a computer An end-user uses a computer as a tool to solve business problems A computer programmer writes the software that end-users make use of A power user is someone in between, typically an end-user who writes his or her own software.

❑ Uniqueness — This is simply a declaration of a field as being a unique key You have seen these

specifications before in this book where a non-surrogate unique field is declared as being UNIQUE For example, a table of customers, using a surrogate primary key auto counter integer CUSTOMER_ID, with a customer name, would not want to store customers having the same name That could make things confusing, to say the least The customer’s name field would be declared as being unique

❑ Validation Check — These settings are sometimes called check constraints All they do is to check

the value in a field when a new record is added, or an existing record is changed The validation

check itself can be a simple list check (such as a person being Male or Female) Validation checks can also be fairly complex executing functions or even stored procedures Some database engines will even allow check constraints on a record as a whole, as opposed to being an indi-vidual field validation restriction A check constraint made against an entire record would apply

to multiple fields in a record, as opposed to just a single field An example validation check would be declared for a field something like the following:

SEX CHAR(1) CHECK(SEX IN (M,F))

SEX CHAR(1) CHECK(SEX = “M” OR SEX = “F”)

The following is for more than a single column check constraint:

CREATE TABLE INVOICES

(

INVOICE# INTEGER PRIMARY KEY NOT NULL, CUSTOMER CHAR VARYING(32) NOT NULL, INVOICE_AMOUNT MONEY NOT NULL, SALES_TAX MONEY,

SALES_COMMISSION MONEY, CONSTRAINT TOTAL_CHECK CHECK((INVOICE_AMOUNT + SALES_TAX + SALES_COMMISSION) > 0) );

❑ Other field settings — The term “other field settings” is a little vague That is the intention These

include field settings such as formatted input masks, default value settings, field lengths, and a host of other possibilities The easiest way to demonstrate this is by showing graphical snap-shots from with Microsoft Access Figure 12-2 shows the different settings that can be applied to

a simple short string datatype (Microsoft Access Textdatatype)

Figure 12-3 shows some detail for various field-setting options for a Microsoft Access Numberdatatype

ANumberdatatype can be of a specific field size, in the form of Byte, Integer, Long Integer, Single, Double, Replication ID, Decimal These format options are all different types of numbers The format setting is essentially the way in which the number is displayed when queried in the database As you can see from the central picture in Figure 12-3, there are various currency display formatting options The last screen on the right of Figure 12-3 shows optional decimal place selection for each number value Datedatatypes, as shown in Figure 12-4, often require some specialized formatting Figure 12-4 shows various options

Storing Code in the Database

Code can be stored in a database in the form of modular scripted sections These scripts can be com-pletely independent of anything in the database, or can operate on data in the database These coded

procedures can be called stored procedures, database procedures, triggers, rules, events, macros, modules, or

other names, depending on the database engine in use They all mean the same thing — code stored with data A distinction needs to be made in that stored procedural code can operate on data in the database but not necessarily For the purposes of database modeling, it should be stated that any stored procedure code, embedded in the database, is likely an application of business rules to a database model, if that stored procedure code operates on data stored in the database

Figure 12-2: Text datatype field property (settings) in Microsoft Access.

Figure 12-3: Numberdatatype field size, format and decimal places settings in Microsoft Access

Figure 12-4: Datedatatype field properties in Microsoft Access.

Some database engines allow extremely versatile stored procedural coding, whereas other databases only allow extremely simplistic stored procedural coding Oracle Database allows a more or less full-fledged programming language in the form of Programming Language for SQL (PL/SQL) Ingres 6.04 database, on the other hand, allows only the simplest of commands, such as INSERT, UPDATE, DELETE, COMMIT, ROLLBACK— and a few others In other words, some database engines go to town with stored procedure coding and others severely restrict it It’s not a matter of preference or lack of development It’s more of how the original writers of these various database engines, pictured how stored procedures should be used Some database engines essentially allow anything, and some database engines deliber-ately restrict what can be coded in a database model Essentially, the more coding options allowed in database engine, the more likely that coding will be over-utilized, become overcomplicated, and the less likely that coding database embedded coding (stored procedures) will cover only business rules That’s the theory, anyway On the contrary, some benefits to using stored procedures to contain database activ-ity can help to protect a database from misuse and abuse Then again, proper training for developers in writing efficient SQL code might be a better option

Take a very brief look at the different types of database embedded coding allowed, and what the various general types of embedded coding blocks are

Stored Procedure

A stored procedure is just that — a modular chunk of code stored in the database It does not have to operate on data, but if custom-written, that is usually the most prudent option Any procedural code not directly written about database data, or not operating on data in a database, might be best migrated to application code To demonstrate briefly, return to the trucking company example, as shown in Figure 12-1

Add to the trucking company model a little, as shown in Figure 12-5 Long field names have been used in Figure 12-5 for descriptive purposes It is inadvisable to name fields with great big, nasty, long names — programmers can get confused, and so can end users for that matter

Figure 12-5: Expanding the trucking company database model ERD from Figure 12-1

Figure 12-5 shows the LOADtable containing a WEIGHTfield (the weight of each load hauled), and a MILEGAGEfield (the distance in miles that each load was hauled over) The following procedure can be used to periodically update the totals, up through the table hierarchy, on both the TRUCKand DRIVER tables, from the LOAD.WEIGHTand LOAD MILEAGEfields

CREATE PROCEDURE AGGREGATE_TOTALS AS BEGIN

UPDATE TRUCK SET TOTAL_MILEAGE_SINCE_LAST_MAINTENANCE, TOTAL_WEIGHT_HAULED_SINCE_LAST_MAINTENANCE

= ( SELECT S.MILEAGE, S.WEIGHT FROM (

SELECT TRUCK_ID,

SUM(MILEAGE) “MILEAGE”, SUM(WEIGHT) “WEIGHT”

FROM LOAD ) S

WHERE S.TRUCK_ID = LOAD.TRUCK_ID );

UPDATE DRIVER SET TOTAL_MILEAGE, TOTAL_HAULED

= (

Driver

driver_id driver sex pay_rate total_mileage total_weight

Load

load_id truck_id (FK) load_type load_content origination_city destination_city origination_date destination_date mileage weight

Truck

truck_id driver_id (FK) truck_type last_maintenance_date total_mileage_since_last_maintenance total_weight_hauled_since_last_maintenance

Hour

hour_id driver_id (FK) load_id (FK) start_time end_time

Log

hour_id (FK) hours minutes

SELECT MILEAGE, WEIGHT FROM (

SELECT DRIVER_ID, SUM(TOTAL_MILEAGE_SINCE_LAST_MAINTENANCE) “MILEAGE”, SUM(TOTAL_WEIGHT_HAULED_SINCE_LAST_MAINTENANCE) “WEIGHT”

FROM TRUCK ) S

WHERE S.DRIVER_ID = TRUCK.DRIVER_ID );

COMMIT;

EXCEPTION TRAP WHEN ERROR THEN

PRINT(“ERROR IN PROCEDURE AGGREGATE_TOTALS”);

ROLLBACK;

END;

The preceding procedure would be executed with a comment like this:

EXECUTE AGGREGATE_TOTALS;

The preceding procedure is nice and neat and tidy; however, this type of coding can cause serious perfor-mance problems because it can lock of all three tables.

Stored Function

A stored function is precisely the same as a stored procedure, except that it returns a single value In programming parlance, a procedure accepts parameter values, but does not return anything (unless resetting dynamic parameters) By definition, in programming terms, a function (much like a mathemat-ical function) always returns a value, even if the return value is NULL Additionally, because a function always returns a value, a function is always executed as an expression, or embedded within another expression A function is actually an expression itself The following function directly accesses data in the LOADtable, producing a calculation based on the MILEAGEand WEIGHTfields All fields are input with zero-valued defaults, and a COST_FACTORis defaulted to 1.304 (arbitrary) for the purposes of mak-ing a calculation The function accepts and returns simple values

CREATE FUNCTION LOAD_COST

(

MILEAGE INTEGER DEFAULT 0, WEIGHT INTEGER DEFAULT 0, COST_FACTOR FLOAT DEFAILT 1.304 )

RETURN INTEGER BEGIN

RETURN (MILEAGE * WEIGHT) * COST_FACTOR;

END;

The preceding function would be executed similar to this:

SELECT

LOAD_TYPE, LOAD_CONTENT, MILEAGE, WEIGHT,

LOAD_COST(MILEAGE, WEIGHT) FROM LOAD;