Data Modeling Presentations I

Editor's Notes

• #3: I have an agenda we’ll take a look at in a minute.
• #19: TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
• #21: TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
• #22: TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
• #33: This is an organizational-level look at the enterprise architecture we use to define, design, deliver and manage solutions.
• #34: INTRODUCTION The Zachman "Framework" is NOT A METHODOLOGY – it’s a FRAMEWORK of ARTIFACTS and their Integration. It was invented in the 1980s but it was too early and there was very little interest in it and no real application for it. So, again, this is a way of CLASSIFYING architectural artifacts – and recognizing that they must fit together, to work together. Questions can be inferred from the Framework like: What levels of analysis, design or implementation do we believe is relevant to a given project? What artifacts are we going to use across the IT organization and through the LIFE CYCLE of a project? How do we get the variety of artifacts in use by IT groups to work together? OVERVIEW ZACHMAN takes into account both whom the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed by the artifact (design or implementation). There are six(6) “interrogatives” (questions) that define the columns. Each column recognizes a separate component of the system we are attempting to build – or rebuild. Down the rows are the different phases of a project – beginning with the CONTEXT and ending with the “AS BUILT,” FUNCTIONING SYSTEM. In between, are the artifact layers. Specifically, CONCEPTUAL, LOGICAL and PHYSICAL. This presentation will deal with the LOGICAL.
• #35: What Zachman really means here is, “We have to find a way to get the models to work together.” If we can do that, we could have artifacts that share a common understanding among Business Analysts, Developers and Data Modelers, for example. We could then leverage those same artifacts to materialize (in the Physical stage) what we learned during the Conceptual or Logical phases. That’s the point of LOGICAL MODELING. It’s the hinge between the concepts in the real world and the running system and its database.
• #36: Imagine we have a project that required some significant changes to the Proposal Programming Modules. Further, imagine that this project touched on the Programming subject area and required some changes there to support what we’re trying to do. This diagram shows us what’s in scope and what’s out (Advertisers, Audience and Agencies). It also tells us
• #37: This is another look at the Zachman Framework which highlights WHERE a DATA DESIGN fits in with other IT ANALYSTS and ARCHITECTS: We’re going to focus on the four boxes @ the bottom left. The SEMANTIC MODEL describes the requirements and rules of the system. The PROCESS MODEL describes how the business operates at a level above its computer systems. Below them, the LOGICAL DATA MODEL describes the Information used enterprise-wide, its relationships, the normal rules of its critical attributes and the constraints that keep it accurate. the APPLICATION ARCHITECTURE describes the component and class-level parts of the computer system that will ultimately automate the BUSINESS PROCESSES.
• #42: Traces component flow and sequence, classifications (objects) and interface requirements (I/O) Leverages Decomposition. Use Cases drive NEW requirements Data requirements go directly to schema. A Component diagram illustrates the pieces of software, embedded controllers and such that make up a system, and their organization and dependencies. A Component diagram has a higher level of abstraction than a Class diagram ; usually a component is implemented by one or more Classes (or Objects ) at runtime. They are building blocks, built up so that eventually a component can encompass a large portion of a system
• #43: Data requirements are Conceptual Base Types and key columns.
• #45: Data requirements are designed to fulfill functional requirements at the class level.
• #47: If Data Modeling is about Language, then we need a Grammar to ensure we’re all speaking the right language. IDEF1X is a method for designing relational databases with a syntax designed to support the constructs necessary in developing a conceptual or Logical schema. Its focus is on actual data elements in a relational database. IDEF1X is not the best choice for OO schemes because it requires, for example, the modeler designate a key class to distinguish one entity from another, whereas object-oriented systems do not require keys to individuate objects CAD tools like PowerDesigner have “modeling checks” that compile the model against IDEF1X standards. When using CAD tools like PowerDesigner, in a situation where it seems that an IDEF1X rule cannot hold, the model is likely wrong.
• #53: The article shown on this slide was published on 6 November, 1970 – forty years ago. #1 I shield the business from having to understand the much more cryptic looking schema. The Logical Model is how the business imagines its database. It captures and maintains Business language. It captures and maintains ROLE and RELATIONSHIP DEFINITION. The reasons for design are de-normalized and obscured in a PHYSICAL MODEL – which may have never been normalized at all. #2 Normalization provides for more complete definition of entities; the better I describe them, the better I can model them; the nearer I am to 3 rd NORMAL FORM the more protected I am from change #3 Distribution of rules, constraints, domains, data integrity and referential integrity enforcement – outside of the application code – automatically creates independence and stability from changes in technology, specifically on the front-end GUI; How many GUIs have come and gone? History shows that the front end of applications are replaced ten times as often as the database itself; Distribution of services keeps cost and development cycles down: imagine I had to replace all my plumbing because I was upgrading my electrical wiring; #4 Normalization eliminates DATA INCONSISTENCIES and DATA REDUNANCY – it’s the reason it was invented
• #61: When we ask the question about whether Logical Data Modeling is even necessary, we’re asking if the principles CODD invented to guide database development are still relevant. There are three fundamental questions we’ll ask when weighing the value of Logical Data Modeling inside an organization: #1 Where does Data Modeling fit into the Enterprise Architecture? #2 Does documenting the movement of data between business processes have as much value to as tracing it by between program modules according to individual requirements? #3 Is it really necessary to explain the Information Asset in complete and real world terms (a “Single Analytical Life Cycle”)?
• #70: This diagram suggests another approach to how Data Architecture may integrate into an OO development process. Business Object Classification and Definition are the first and most important steps. Once I reify my abstract ideas like an Avail, a Program Schedule, Formatting an Episode, Universe and Ratings, I can begin to NORMALIZE each and then define services for each. In this map, Business Analysis precedes Data Modeling which precedes Development. Requirements thread through the entire map, however, as the Zachman Framework demonstrates.
• #72: This is another look at the Zachman Framework which highlights WHERE a DATA DESIGN fits in with other IT ANALYSTS and ARCHITECTS: We’re going to focus on the four boxes @ the bottom left. The SEMANTIC MODEL describes the requirements and rules of the system. The PROCESS MODEL describes how the business operates at a level above its computer systems. Below them, the LOGICAL DATA MODEL describes the Information used enterprise-wide, its relationships, the normal rules of its critical attributes and the constraints that keep it accurate. the APPLICATION ARCHITECTURE describes the component and class-level parts of the computer system that will ultimately automate the BUSINESS PROCESSES.
• #78: Imagine we have a project that required some significant changes to the Proposal Programming Modules. Further, imagine that this project touched on the Programming subject area and required some changes there to support what we’re trying to do. This diagram shows us what’s in scope and what’s out (Advertisers, Audience and Agencies). It also tells us
• #79: Imagine we have a project that required some significant changes to the Proposal Programming Modules. Further, imagine that this project touched on the Programming subject area and required some changes there to support what we’re trying to do. This diagram shows us what’s in scope and what’s out (Advertisers, Audience and Agencies). It also tells us
• #81: Imagine we have a project that required some significant changes to the Proposal Programming Modules. Further, imagine that this project touched on the Programming subject area and required some changes there to support what we’re trying to do. This diagram shows us what’s in scope and what’s out (Advertisers, Audience and Agencies). It also tells us
• #89: Imagine we have a project that required some significant changes to the Proposal Programming Modules. Further, imagine that this project touched on the Programming subject area and required some changes there to support what we’re trying to do. This diagram shows us what’s in scope and what’s out (Advertisers, Audience and Agencies). It also tells us