This is the second edition of the training manual for the Data Modeling Master Class that Steve Hoberman teaches onsite and through public classes. This text can be purchased prior to attending the Master Class, the latest course schedule and detailed description can be found on Steve Hoberman''s website, www.stevehoberman.com.The Master Class is a complete course on requirements gathering and data modeling, containing four days of practical techniques for producing solid relational and dimensional data models. After learning the styles and steps in gathering and modeling requirements, you will apply a best practices approach to building and validating data models through the Data Model Scorecard. You will know not just how to build a data model, but also how to build a data model well. Challenging exercises and workshops will reinforce the material and enable you to apply these techniques in your current projects.

By the end of the course, you will know how to. Read a data model of any size and complexity Validate any data model with the Data Model Scorecard Build relational and dimensional subject area, logical, and physical data models Use abstraction Gather requirements Leverage a series of templates for capturing requirements Write clear, complete, and correct definitions Explain the critical factors that must be in place for a successful enterprise data model TopicsPart 1: Modeling BasicsAssuming no prior knowledge of data modeling, we will begin this section with an entertaining exercise that will illustrate an important gap filled by data models. Next, we will explain data modeling concepts and terminology. We will also explore each component on a data model and practice reading business rules. Part 2: Overview to the Data Model ScorecardThe Scorecard is a set of ten categories for validating a data model. We will explore best practices from the perspectives of both the modeler and reviewer, and you will be provided with a template to use on your current projects. Each of the following categories heavily impacts the usefulness and longevity of the model. Our discussion of them will be accompanied by many examples.

Part 3: Understanding subject area, logical, and physical data modelsThe subject area model captures a business need within a well-defined scope; the logical data model captures an application-independent business solution; and the physical data model captures the technical solution by focusing on factors such as performance and security. Each of these models will be explained in detail in this section. Part 4: Ensuring the model captures the requirements We will focus on techniques such as the use of spreadsheets and business assertions to ensure the data model meets the business requirements. Part 5: Validating model scopeWe will focus on techniques for validating that the scope of the requirements matches the scope of the model. If the scope of the model is greater than the requirements, we have a situation known as "scope creep." If the model scope is less than the requirements, we will be leaving information out of the resulting application. Part 6: Following acceptable modeling principlesWe will focus on techniques for building sound designs. Part 7: Determining the optimal use of generic conceptsWe will focus on techniques for capturing the ideal use of generic concepts such as Party and Event.

Part 8: Applying consistent naming standardsWe will focus on techniques for applying correct and consistent naming standards. Part 9: Arranging the model for maximum understandingWe will focus on techniques for arranging the entities, data elements, and relationships to maximize readability. Part 10: Writing clear, correct, and consistent definitionsWe will focus on techniques for writing useable definitions. Part 11: Matching the model with the enterprise We will focus on techniques for ensuring the model complements the "big picture". Part 12: Comparing the metadata with the dataWe will focus on techniques for confirming the data elements and their rules match reality. Does the data element Customer Last Name really contain the customer's last name?.