Beginning Database Design- P13 docx

Part IIIA Case Study in Relational Database Modeling In this Par t: Chapter 9: Planning and Preparation Through Analysis Chapter 10: Creating and Refining Tables During the Design Phase

Exercises Answer the following questions:

1. Which of these apply to OLTP databases?

a Large transactions

b High concurrency

c Frequent servicing opportunities

d Real-time response to end-users

2. Which of these apply to data warehouse databases?

a Lots of users

b High concurrency

c Very large database

d High granularity

3. Which aspect of a query affects performance most profoundly? Select the most appropriate answer

a WHEREclause filtering

b Sorting with the ORDER BYclause

c Aggregating with the GROUP BYclause

d The number of tables in join queries

e The number of fields in join queries

4. Assume that there 1,000,000 records in a table One record has AUTHOR_ID = 50 AUTHOR_IDas the primary key Which is the fastest query?

a SELECT * FROM AUTHOR WHERE AUTHOR_ID != 50;

b SELECT * FROM AUTHOR WHERE AUTHOR_ID = 50;

213

Building Fast-Performing Database Models

Part III

A Case Study in Relational Database

Modeling

In this Par t:

Chapter 9: Planning and Preparation Through Analysis

Chapter 10: Creating and Refining Tables During the Design Phase

Chapter 11: Filling in the Details with a Detailed Design

Chapter 12: Business Rules and Field Settings

Planning and Preparation

Through Analysis

“The temptation to form premature theories upon insufficient data is the bane of our profession.”

(Sherlock Holmes)

“It almost looks like analysis were the third of those impossible professions in which one can be quite sure of unsatisfying results The other two, much older-established, are the bringing up of

children and the government of nations.” (Sigmund Freud)

Rocket science is an exact science Analysis is by no means an exact science.

In planning this book, I thought of just that — planning Where would the human race be without planning? Probably still up in the trees hanging from gnarly branches, shouting “Aaark!” every now and again Previous chapters in this book have examined not only the theory of how to create

a relational database model but also some other interesting topics, such as the history of it all, and why these things came about

At this stage, why the relational database model was devised should make some sense Additionally, different applications cause a need for different variations on the same theme, leading to the invention of specialized data warehouse database models A data warehouse database model is denormalized to the point of being more or less totally unrecognizable when compared to an OLTP (transactional) type relational database model structure ERDs for OLTP and data warehouse database models only appear similar The two are completely different in structure because the data warehouse database model is completely denormalized This is why it is so important to present both OLTP and data warehouse database models in this book Both are relevant, and both require intensive planning and preparation to ensure useful results

This chapter begins a case study where theoretical information (absorbed from previous chapters)

is applied in a practical real-world scenario This chapter (and the next three following chapters) uses practice to apply theory presented in the first seven chapters Why? Theory and practice are two completely different things Theory describes and expounds on a set of rules, attempting to quantify and explain the real world in a formal manner, with formal methods Formal methods are essentially a precise mathematical expression as a methodology A methodology is an approach as

applied to a real-world scenario In this book, the desired result is usable underlying structure — a

relational database model

Without placing a set of rules into practice, in a recognizable form, from start to finish, understanding of theory is often lost through memorization In other words, there is no point learning something by heart without actually having a clear understanding of what you are learning, and why you are learning it Using a case study helps to teach by application of theory

This might all seem a little silly, but I have always found that a little understanding lends itself to not requiring my conscious mind to mindlessly memorize everything about a topic I prefer to understand rather than memorize I find that understanding makes me much more capable of applying what I have learned in not-yet-encountered scenarios By understanding a multiple-chapter case study, you should learn how everything fits together

So far, you have read about history, some practical application, and lots and lots of theory Even some advanced stuff (such as data warehousing and performance) has been skimmed over briefly What’s the point of all this information, crammed into your head, without any kind of demonstration? The act of demonstrating is exactly how this book proceeds from here on in with a progressive, fictitious case study example There are plenty of examples in previous chapters, but it’s all been little pieces This chapter starts the development of a larger case study example The idea is to demonstrate and describe the process of creating a database model for an entire application And it starts at the very beginning The only assumptions made are that everyone knows how to work the mouse, and we all know what a computer is This chapter begins the process of creating appropriate database models for an OLTP database and a data warehouse The specific company type will be an online auctioning Web site Online auctions have high concurrent activity (OLTP activity), and a large amount of potential historical trans-actions (data warehouse activity)

This chapter begins with the very basics The very basics are not getting out a piece of paper and drawing table structures, or installing your favorite ERD tool and getting to it The very beginning of database model design (and any software project for that matter) is drawing up a specific analysis of what is actually needed You should talk to people and analyze what software should be built, if any There are,

of course, other important factors How much is it going to cost? How long will it take? The intention of this chapter is to subliminally give a message of focusing on how to obtain the correct information, from

the right people The goal is to present information as structure.

By the time you have completed reading this chapter, you should have a good understanding of the analytical process, not only for database modeling, but also as applicable for any software development process More importantly, you should get a grip on the importance of planning It is possible to build

a bridge without drawing, designing, and architecting An engineer could avoid doing lots of nasty complicated mathematical civil engineering calculations What about planning that bridge? Imagine a bridge that is built from the ground up with no planning Whoever pays the engineer to build the bridge

is probably prudent to ask the builder to be the first to walk across it

In this chapter, you learn about the following:

❑ The basics of analysis and design

❑ The steps in the analysis process

❑ Common problem areas and misconceptions associated with analysis

❑ The value of following a paper trail

❑ How to create a database model to cover objectives

❑ How to refine a database model using business rules

❑ How to apply everything learned so far with a comprehensive case study

Steps to Creating a Database Model Before beginning in earnest with the case study example, you need to sidestep a little over the course of this and the next few chapters There is an abundance of information covering the systematized process (the “what and how”) of building a database model

The building of a database model can be divided up into distinct steps (as can any software development process) These steps can be loosely defined as follows:

1. Analysis

3. Construction

4. Implementation Take a brief look at each of these in a bit more detail

Step 1: Analysis

Analyzing a situation or company is a process of initial fact-finding through interviews with end-users If there are technical computer staff members on hand, with the added bonus of inside company operational knowledge, interview them as well

A proper analysis cannot be achieved by interviewing just the technical people An all-around picture of

a client or scenario is required End-users are those who will eventually use what you are building The end-users are more important! A database system is built for applications Technical people program the applications End-users are the ultimate recipients of whatever you are providing as the database designer or modeler.

As stated previously, analysis is more about what is required, not how it will be provided What will the database model do to fulfill requirements? How it will fulfill requirements is a different issue Analysis essentially describes a business What does the company do to earn its keep? If a company manufactures tires for automobiles, it very likely does such things as buying rubber, steel, and nylon for reinforcement, purchasing valves, advertising its tires, and selling tires, among a myriad of other things Analysis helps

to establish what a company does to get from raw materials to finished product In the case of the tire manufacturer, the raw materials are rubber, steel, nylon, and valves The finished products are the tires

Analysis is all about what a company does for a living? This equates to analyzing what are the tables in the database? And what are the most basic and essential relationships between those tables?

219

Planning and Preparation Through Analysis

Analysis defines general table structure An auction Web site might contain a seller table and a bidder table You must know what tables should generally contain in terms of information content Should both the seller and bidder tables contain addresses of sellers and bidders respectively? Analysis merely defines Analysis does not describe how many fields should be used for an address, or what datatypes those fields should be Analysis simply determines that an address field actually exists, and, obviously, which table or tables require address information

Step 2: Design

Design involves using what was discovered during analysis, and figuring out how those analyzed things can be catered for, with the software tools available The analysis stage decided what should be created The design stage applies more precision by deciding how tables should be created This

includes the tables, their fields, and datatypes Most importantly, it includes how everything is linked together

Analysis defines tables, information in tables, and basic relationships between tables The linking together

aspect of the design stage is, in its most basic form, the precise definition of referential integrity Referential

integrity is a design process because it enforces relationships between tables The initial establishment of

inter-table relationships is an analysis process, not one of designs

In other words, analysis defines what is to be done; design organizes how it’s done The design stage introduces database modeling refinement processing, such as normalization and denormalization In terms of application construction, the design stage begins to define front-end user “bits and pieces” such

as reports and graphical user interface (GUI) screens

Build the tables graphically, add fields, define datatypes, and apply referential integrity Refine through use of processes such as normalization and denormalization.

Step 3: Construction

In this stage, you build and test code For a database model, you build scripts to create tables, referential integrity keys, indexes, and anything else such as stored procedures In other words, with this step, you build scripts to create tables and execute them

Step 4: Implementation

This is the final step in the process Here you create a production database In other words, it is at this stage of the process that you actually put it all into practice

This book is primarily concerned with the analysis stage but partially with the

design stage as well As already stated, construction is all about testing and

verification Implementation is putting it into production This book is about

database modeling — analysis and design The construction and implementation

phases are largely irrelevant to this text; however, it is important to understand

that analysis and design do not complete the entire building process Physical

construction and implementation are required to achieve an end result.

The case study example introduced later in this chapter is all about analyzing what is needed for a database model — the analysis stage of the process Let’s turn our attention to analysis What is analysis and how can you go about the process of analyzing for a database model?

Understanding Analysis

As you have learned, analysis is the beginning point in the building of a good relational database model Analysis is about the operational factors of a company, the business of a company It is not about the technical aspects of the computer system It is not about the database model, or what the administrators,

or programmers want, and would like to see The analyst must understand the business Participation from people in the business — the company employees, both technical and non-technical (end-users), even up to and including executive management level — is critical to success On the other hand, complete control cannot be passed to the company Some companies develop software using only temporarily hired staff, with no in-house technical involvement whatsoever This can result in an entirely end-user oriented database model There needs to be a balance between both technical and non-technical input

It is important to understand that the analysis stage is a requirements activity What is needed? When building a database model, an application or a software product, it is important to understand that there is a process to figuring what is in a database What tables do you need? In computer jargon, these

processes are often called methodologies (a set of rules) by which a builder of computer systems gets from

A to B (from doodles on scrap paper, to a useful computer system) A lot of people have spent many years mulling over these sets of rules, refining and redefining, giving anyone and everyone a series of sometimes easy or sometimes incredibly complex steps to follow, in getting from A to B

Normalization is a methodology Normalization is a complex set of rules for refining relational database table structures Dividing up the database model design process into separate steps of analysis, design, construction, and implementation, is also a methodology

The best database models are produced by paying attention to detail in the analysis stage It is important

to understand exactly what is needed before jumping in and “just getting to it.” If changes are required

at a later stage of development, changes can be added at a later stage; however, making changes to a database model used in a production system can be extremely problematic, so much so as to not be

an option This is because applications are usually dependent on a database and therefore usually dependent on the database model

Analysis is planning It is doubly important to plan for a database model The reason is that the database model forms the basis of all database-driven applications, quite often for an entire company In the case of

an off-the-shelf product, that database model could drive duplicated and semi-customized applications for hundreds and even thousands of companies Getting the database model right in the first place is critical The more that is understood about requirements in the analysis stage, the better a database model and product will ultimately be produced

Some database modeling and design tools allow generation of table scripts into different database engines The tool used for database modeling in this book is called ERWin ERWin can be used to generate table creation scripts for a number of database engines Microsoft Access has its own built-in ERD modeling tool Database models can generally be designed using pretty pictures in a graphical database modeling tool, such as ERWin Building a database model using pretty pictures and fancy graphics packages allows for an

221

Planning and Preparation Through Analysis

analytical mindset and approach, ignoring some of the more technical details when performing analysis Deep-level technical aspects (such as field datatypes and precise composition) can actually muddy the perspective of analysis by including too much complexity at the outset

Analysis is about what is needed Design is about how to provide what is needed by an already

com-pleted analysis.

In the case of a rewrite of an existing system (reconstruction of an existing database model), analysis simply includes the old system in interviews and discussions with end-users and technical staff If a system is being rewritten, it is likely that the original system is inadequate, for one or more reasons The analysis process should be partially performed to enlighten as to exactly what is missing, incorrect, or inadequate

End-users are likely to tell you what they cannot do with the existing system End-users are also likely to have a long list of what they would like A conservative approach on the part of the analyst is to assess what enhancements and new features are most important This is because one of the most important features of the analysis stage is how much it is all going to cost The more work that is done, the more it will cost

Technical staffers, such as programmers and administrators, are likely to tell you what is wrong They can also tell you how they “got around” inadequacies, such as what “kludges” they used

A “kludge” is a term often used by computer programmers to describe a clumsy or inelegant solution to

a problem The result is often a computer system consisting of a number of poorly matched elements.

Analysis Considerations

Because the analysis stage is a process of establishing and quantifying what is needed, you should keep

in mind several factors and considerations, including the following:

❑ Overall objectives — These include the objectives of a company when creating a database model

What should be in the database model? What is the expected result? What should be achieved? For example, is it a new application or a rewrite?

❑ Company operations — These include the operations of a company in terms of what the company

does to make its keep How can all this be computerized?

❑ Business rules — This is the heart of the analysis stage, describing what has been analyzed and

what needs to be created to design the database model What tables are needed and what are the basic relationships between those tables?

❑ Planning and timelines — A project plan and timeline are useful for larger projects Project plans

typically include who does what and when More sophisticated plans integrate multiple tasks, sharing them among many people, and ensuring that dependencies are catered for For example,

if task B requires completion of task A, the same person can do both tasks A and B If there is no dependency, two people can do both tasks A an B at the same time