Danh mục tài liệu

Beginning Database Design- P20

Số trang: 20      Loại file: pdf      Dung lượng: 664.47 KB      Lượt xem: 21      Lượt tải: 0    
Xem trước 2 trang đầu tiên của tài liệu này:

Thông tin tài liệu:

Beginning Database Design- P20:This book focuses on the relational database model from a beginning perspective. The title is, therefore,Beginning Database Design. A database is a repository for data. In other words, you can store lots of informationin a database. A relational database is a special type of database using structures called tables.Tables are linked together using what are called relationships. You can build tables with relationshipsbetween those tables, not only to organize your data, but also to allow later retrieval of information fromthe database....
Nội dung trích xuất từ tài liệu:
Beginning Database Design- P20 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 altogetherThis 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 relationshipsbetween tables, identifying fields, their datatypes, and various other factors including things suchas validation. Field settings including display formats, input maskings, default values, and checkconstraints are included. There is also a brief section on applying business rules by way of storingcode 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 analysisand design process for both OLTP and data warehouse database models, all the way through fromstart to finish.By the end of this chapter, you should know how to apply field setting business rules in theextreme, 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 itcomes 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 rulesChapter 12What 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. 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. 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 application354 Business Rules and Field Settings 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 ...