CHAPTER 2 DATABASE MODELING IN THE WORKPLACE

1. CHAPTER 2 DATABASE MODELING IN THE WORKPLACE

2. Ch2: Database Modeling in the Workplace • In this chapter, you learn about the following: • Business rules • Database structure of business rules • How to deal with people • Listen as much as talk when analyzing a design • Getting information from end-users • ❑ End-users specifications versus database model design • ❑ The importance of an in-house technical perspective • ❑ The bird’s eye view from management • ❑ Some unfavorable scenarios The only fool is the data model designer who assume to know all

3. Ch2: Database Modeling in the Workplace • Understanding Business Rules and Objectives: • You must understand that you are designing for practical solution • Understanding the nature of the business or the structure of data and the daily flow of information is key (if not the key) to understanding how to build a database model for that business • A relational database model allows the implementation of the most significance business rules into its basic structure • What are business rule?

4. Ch2: Database Modeling in the Workplace A simple database model

5. Ch2: Database Modeling in the Workplace • What are Business rules: • Business rules for an organization are essentially the process and flows of whatever is involved in the daily working of that organization • What does the organization do to operate? • What its task? • What is the meaning and purpose of its existence? • How does it make its money?

6. Ch2: Database Modeling in the Workplace • Business rules cover the following aspects of an organization: • Any types of organizational policies of any form and at all levels of the organization • Any types of calculations or formulas (such as loan amortization calculations for a mortgage lending company) • Any types of regulations (such as rules applied because of legal requirements, self-imposed restrictions, or industry-standard requirements)

7. Ch2: Database Modeling in the Workplace • Business rule • In slide 4: • A book (PUBLICATION) requires at least one author • one author who can have zero, one, or many publications. • an author can exist, but the author does not have to have any books published • a publication cannot exist unless it has an author • The point is that the relationship forces the database model to accept only books that have actually been written by someone, • The business rule is that a non-existent book cannot be entered into the database. • Constraints are things that place restrictions on values stored in a database (F,M)

8. Ch2: Database Modeling in the Workplace • The importance of business rules • A relational database model cannot avoid defining some business rules, simply because of the existence of relationships between tables and enforcement of referential integrity.

9. Ch2: Database Modeling in the Workplace • Incorporating the Human Factor: • You cannot create a database model without the involvement of the people who will ultimately use that database model • There is only one important thing to remember about company employees: as a whole, they know their business, how it operates, and how it works. • Your first task is to talk with and listen to company personnel • By talking and listening, you can discover how to design a better database model for them

10. Ch2: Database Modeling in the Workplace • People as a Resource • The people the database model is being built for can often tell you the most about what should be in the model • The database designer applies technical skills to the thoughts and statements of the user • Ultimately, you (the designer) are 95 percent responsible for figuring out the design and building the database model. • All you really need to do is to organize everything into sequences of logical, mathematical steps • Users are likely to think of it in terms of priorities and how they react to different situations—plus how important each task on their desk is related to the importance of the running of their business.

11. Ch2: Database Modeling in the Workplace • People as a Resource • The database designer must be objective, clinical, analytical, and (above all) precise. • Designing a database model is an abstraction of specifics. Abstraction is a logical or mathematical process, designed to make handling of specific situations much easier (car models) • The database • Model designer has the final say on what a database model should do and what it should look like • A database model must take all special circumstances into account, but it must remain abstract.

12. Ch2: Database Modeling in the Workplace • Talking to the Right People • For large companies, the best option is the high-level managers with a good overall picture of the business. • A database designer must talk to different types of people on multiple levels and in multiple skills arenas, in the same company • The more complexity a database model requires, the more questions you must ask. The more questions there are to ask • The more questions you have, the more people you might want to talk to, and, thus, the more people in different roles you will probably need to talk to as well. • The more special-case scenarios you get, the more likely you will begin to observe similarities between those supposedly opposing special-case scenarios • Your objective is to create a single set of tables and relationships to cover as much of the operational functioning of a company as possible

13. Ch2: Database Modeling in the Workplace • Getting the Right Information • What is the right information? • Getting the right information is really an extension of talking to the right people • the correct detail comes from the mouths of the people who know how a company functions operationally • The more people you talk to in a greater number of sections and levels the more being able to dissimilate between correct and incorrect information and advise • Finally, if you are an outside consultant, bear in mind that what you think is correct and what you think is incorrect may not be the reality of the situation. You could be completely wrong. • Never assume that you know more than in-house employees • Above all, listen! Listen, learn, and examine every piece of nformationyou are given

14. Ch2: Database Modeling in the Workplace Computerizing a Pile of Papers Converting legacy database Homogenous Integration of Heterogeneous Databases Converting from Spreadsheets Sorting Out a Messed-up Database

15. Ch2: Database Modeling in the Workplace Summary In this chapter, you learned about: ❑ Business rules are partially built into a relational database model design ❑ Talk to users to get the information you need ❑ Abstraction requires management perspective ❑ Assess the culture of in-house technical people to understand their perspective ❑ Higher-level personnel in small companies are more accessible than those in large companies ❑ Different types of people in different roles can give differing perspectives ❑ Talk to the right people to get the right information in a specific topic area ❑ Unfavorable scenarios are difficult conversion situations, but not necessarily as daunting as they seem