Beginning Database Design- P20 ppt

12 Business Rules and Field 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 18_574906 ch12.qxd 10/28/05 11:42 PM Page 353 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 SEX can be restricted to having values of M for Male and F for Female. Insisting that a field only be set to M or F is 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 CHECK constraints). 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. 354 Chapter 12 18_574906 ch12.qxd 10/28/05 11:42 PM Page 354 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. 355 Business Rules and Field Settings 18_574906 ch12.qxd 10/28/05 11:42 PM Page 355 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 356 Chapter 12 18_574906 ch12.qxd 10/28/05 11:42 PM Page 356 ❑ 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 NULL values, uniqueness, and individual field settings (validation checks are included). You begin with NULL values and uniqueness, as these are simple: ❑ NULL and default values — NULL value 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 NULL for any field with nothing specified. WITH NULL is 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 NULL to allow NULL values into fields. NULL simply means that a field does not have to have a value entered when a record is inserted into (or updated in) a table. NOT NULL is completely the opposite and always requires a value. If inserting or updating, a field specified as NOT NULL is 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 NULL set field, then the default value is added to the NOT NULL field. This can somewhat restrict the purpose of specifying a field as NOT NULL. For example, a primary key field is always NOT NULL by 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 357 Business Rules and Field Settings 18_574906 ch12.qxd 10/28/05 11:42 PM Page 357 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 Text datatype). Figure 12-3 shows some detail for various field-setting options for a Microsoft Access Number datatype. A Number datatype 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. Date datatypes, 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. 358 Chapter 12 18_574906 ch12.qxd 10/28/05 11:42 PM Page 358 Figure 12-2: Text datatype field property (settings) in Microsoft Access. Figure 12-3: Number datatype field size, format and decimal places settings in Microsoft Access. 359 Business Rules and Field Settings 18_574906 ch12.qxd 10/28/05 11:42 PM Page 359 Figure 12-4: Date datatype 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. 360 Chapter 12 18_574906 ch12.qxd 10/28/05 11:42 PM Page 360 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 LOAD table containing a WEIGHT field (the weight of each load hauled), and a MILEGAGE field (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 TRUCK and DRIVER tables, from the LOAD.WEIGHT and LOAD MILEAGE fields. 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 361 Business Rules and Field Settings 18_574906 ch12.qxd 10/28/05 11:42 PM Page 361 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 LOAD table, producing a calculation based on the MILEAGE and WEIGHT fields. All fields are input with zero-valued defaults, and a COST_FACTOR is 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; 362 Chapter 12 18_574906 ch12.qxd 10/28/05 11:42 PM Page 362 [...]... same trigger) is inadvertent and can result in a database slowing down, tying itself up in great big granny knots, and even appearing to halt Some database engines call event triggers just triggers, some call them rules (used for expert system construction), and some call them database events (implying something happens in a database, to trigger the database event to occur) 363 Chapter 12 External... very similar to stored procedures, except they are written a non-databasespecific programming language External procedures are a chunk of code written in a language not native to the database engine (such as Java or C++) However, external procedures are still executed from within the database engine itself, perhaps on data within the database Macro A macro is a little like a pseudo-type series of commands,... depth business model development, for the OLTP and data warehouse database models — using the online auction house Case Study: Implementing Field Level Business Rules in a Database Model The whole objective of this chapter is to show very detailed application of business rules into a database model This can be placing too much detail into a database model It might be too much detail because this type of... of business rules implementation into a database model can overcomplicate a database model, and quite often lead to serious performance problems, and serious difficulty in the day-to-day maintenance of production level databases Table and Relation Level Business Rules In the case study so far in previous chapters, all factors for both OLTP and data warehouse database models, for all table and relational...Business Rules and Field Settings Event Trigger Event triggers are used to automatically trigger events, generally in response to something that happens inside a database Triggers typically are executed automatically based on specific database change commands (such as INSERT, UPDATE, and DELETE commands) The easiest way to demonstrate use of triggers is that of log file generation, as in the trigger... what a database engine may allow TO_CHAR converts a time stamp date value (the subtraction) to a string, where the HH and MM format specify extraction of hours and minutes from the timestamp, respectively The most significant factor to note about triggers is that they are not allowed to contain COMMIT or ROLLBACK commands Triggers are automatically executed either before or after the execution of a database. .. of a database change command Database change commands are INSERT, UPDATE, and DELETE commands Transactional control is essentially the control of where and when a transaction is terminated Transactions are terminated either by direct or indirect execution of a COMMIT or ROLLBACK command A trigger is contained within a parent transaction If the trigger doesn’t change any database data, then you don’t... uncommitted changes) Transactional control must be retained outside of a trigger Even if a trigger does change database data, transactional control must still remain within the purview of the calling command or procedure Triggers can’t directly call each other, but if a trigger includes a database change command, it can also execute other triggers, or even itself One of the biggest dangers with profligate... already Default values, validation checks, and other settings (such as formatting and input maskings) are not yet covered Field Level Business Rules for the OLTP Database Model Figure 12-6 shows the most recent version of the ERD for the OLTP database model, for the online auction house Figure 12-6 shows that a CURRENT_PRICE field has been added to the LISTING table to 364 Business Rules and Field Settings... be output formatted because in these database models, they are based on currency decimal places Currency decimal places can be 0, 2, or 3 decimal places There is no point placing an output display format of FORMAT “9999990.99” on one of the monetary amount fields because this particular format specifies two decimal places only — which would be incorrect for these database models Take a look at the BID . 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. 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. . 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