1. Welcome to Logical Data Modeling, What is it Really? An Overview of Logical Data Modeling Chris Crisci ESPN Data Modelerrchitect - DAIS This is the first in a series of four presentations about Logical Data Modeling and its practice.
4. Logical Analysis & Design Discussion Topics 08/19/10 Today’s Agenda What is Logical Data Modeling, in a nutshell? What is Semantic Analysis and Word Classification? Where does Logical Data Modeling fit into the Enterprise Architecture? What is a Logical Functional Approach? Are Logical Data Models Really Necessary? What is a Relational Database, Really? What is Data Normalization, Really? An Example of a General Purpose Artifact What Might Artifact Integration Look Like?
5. Logical Analysis & Design I What is Logical Data Modeling, in a nutshell? 08/19/10 Part I
6. What is Logical Data Modeling, in a nutshell? Normalizing the Land of Oz 08/19/10
7.
8. What is Logical Data Modeling, in a nutshell? Generalizationpecification and The Wizard of OZ 08/19/10
9. What is Logical Data Modeling, in a nutshell? Generalizationpecification and The Wizard of OZ 08/19/10 Looks similar to a Domain Class Diagram.
10. What is Logical Data Modeling, in a nutshell? The Steps of Data Normalization 08/19/10
11. What is Logical Data Modeling, in a nutshell? Normalization and The Wizard of OZ 08/19/10
12. What is Logical Data Modeling, in a nutshell? Application Work: Entity Relationship Analysis 08/19/10
13. What is Logical Data Modeling, in a nutshell? Relationship Analysis: Data Analysis 08/19/10 Normalization and Application Requirements create entities by their own momentum. Relationship, Cardinality, Set and Dependency Analysis are all part of Logical Data Modeling.
14. What is Logical Data Modeling, in a nutshell? Modeling the Plot of the Wizard of Oz 08/19/10
15. What is Logical Data Modeling, in a nutshell? Modeling the Plot of the Wizard of Oz 08/19/10
16. What is Logical Data Modeling, in a nutshell? Modeling the Plot of the Wizard of Oz 08/19/10
17. Logical Analysis & Design II What is Semantic Analysis & Word Classification? 08/19/10 Part II
18. What is Semantic Analysis & Word Classing? Conceptual Analysis: Semantic Modeling 08/19/10 “ The better I can describe the business entities, the better I can model them.” For example: What are the contexts within which the word or phrase can be used? How does each context change the meaning of the word or phrase? Semantics: Information is Data in Context “ From the user's perspective.” Word Classes: How we interpret Semantics Noun, Verb, Adjective, Adverb, Conjunctive, Preposition, etc.
19. 08/19/10 What is Semantic Analysis & Word Classing? Conceptual Analysis: Context
20. What is Semantic Analysis & Word Classing? Conceptual Analysis: Semantic Methodology 08/19/10 Semantic Analysis: How do we do this? Classify (parse) the phrases and words Generalize (don’t get too specific at first) Generalizing and Classifying information leads to type definition: Identify Concrete and Abstract Objects as: Base Types (Entities) Composite Types (with attributes)
21. What is Semantic Analysis & Word Classing? Conceptual Analysis: Semantic Sources 08/19/10 PAST REQUIREMENTS REPORTS APPLICATION SCREENS INDUSTRY LANGUAGE
22. What is Semantic Analysis & Word Classing? Conceptual Analysis: Semantic Sources 08/19/10 During Semantic Analysis, we’re building a Conceptual Model based on what we hear, read and see. It is a form of Analytical Prototyping that allows the analyst to confirm knowledge through an artifact before moving on to the Logical phase. For Example, a new analyst might start with a broad definition, intended for a general audience: Format - Guideline that accommodates all commercial and promotional inventories, in addition to production elements . Used as the template for Ad Sales avails . Source: Wiki Page
23. What is Semantic Analysis & Word Classing? The Episode Break Format in Context 08/19/10 Application configuration context, the Format describes how a Program will be segmented by Breaks and then what Ad Types may appear within Breaks – and on what Days, during an original, a repeat or both, etc.
24. What is Semantic Analysis & Word Classing? Generalization: The Base Types – Conceptually Correct? 08/19/10 An entity is not really described without its predicates, attributes and relationships. Now, I know: To be described, a Format depends upon Networks, Programs, Segments within Programs, Breaks, Ad Types within Breaks, Days, and whether it is defined for an original, a repeat or both, etc.
25. What is Semantic Analysis & Word Classing? Generalization: Base Types Grow by Conversation 08/19/10
26. What is Semantic Analysis & Word Classing? Generalization: Base Types Will Change 08/19/10 Now I know: A Format describes availability of commercial Units and Units are Ad Types for Sale within a specific Program’s Selling Rotations. Selling Rotations coordinate a Customer's commercial air time and define which Episode broadcasts will meet demand for the Units Requested on a Customer Proposal.
27. What is Semantic Analysis & Word Classing? Generalization: Building on the Base Types 08/19/10 In its Program Scheduling context, Format versions may be created for any number of reasons. A new Format, intended to be employed over time, would cause Program Scheduling to version an existing Format. Causes: Program Duration Variations in Local vs. National time Variations in # Billboards, # Features Vendor agreements (impacts attributes) Institutional Agreements (impacts attributes) Government Regulations -usually foreign (impact attributes) Live Vs Taped programming Sales initiatives
28. 08/19/10 Now I know: Format versions may be created from an existing Format, based on the following: Program Duration, Variations in Local vs. National time, Variations in # Billboards or # Features, Vendor Agreements Institutional Agreements Government Regulations -usually foreign Live Programming Vs Taped Airings, Sales Initiatives What is Semantic Analysis & Word Classing? Generalization: Building on the Base Types
29. What is Semantic Analysis & Word Classing? The End Result: A Conceptual Data Model 08/19/10 CONCEPTUAL DATA MODEL INTEGRATION The Conceptual entities defined as a result of Semantic Analysis may be integrated to the Logical Diagram.
30. 08/19/10 Take Away: In order to perform complete analysis, is it necessary to have an advanced understanding of the business language in use at ESPN? What is Semantic Analysis & Word Classing? Take Away
31. Logical Analysis & Design III Where does LDM fit into the Enterprise? 08/19/10 Part III
32. Where does LDM fit into the Enterprise? The Cycle 08/19/10 The highest level view of everything we will define, design, develop and deploy moves from Contextual, through Conceptual and Logical, and on to Physical Stages. The phases we will look at in this presentation drill down on the Information System Architecture and touch on the Business Architecture: The Conceptual and Logical Contextual Conceptual Logical Logical Physical
33. Where does LDM fit into the Enterprise? The Zachman Framework 08/19/10
34. Where does LDM fit into the Enterprise? The Zachman Framework: Artifact Integration 08/19/10 THE ZACHMAN FRAMEWORK ‘ It is the integration of the answers to those six interrogatives, specifically the Logical models, that enables the comprehensive description of complex requirements.’ KEY: The Framework is Not a Methodology but a collection of artifacts intended to work together to unite an organization’s design and development efforts.
35. 08/19/10 GENERATION LINKS - are created during model or object generation. Each generated object is linked with its origin object . Where does LDM fit into the Enterprise? What We Mean by Integration: Two Definitions SHORTCUTS - create a reference to an object in another model. They are either created explicitly in order to share or reuse an object in another model, or implicitly when creating other kinds of links in a CASE tool.
36. Where does LDM fit into the Enterprise? The Framework Simplified 08/19/10
37. Where does LDM fit into the Enterprise? Take Away 08/19/10 Take Away: Which of the artifacts outlined in the Zachman Framework do we need in the ESPN Enterprise Architecture?
38. Logical Analysis & Design IV What is a Logical Functional approach? 08/19/10 Part IV
39. What is a Logical Functional approach? Conceptual Level: Business Process Model 08/19/10 A Business Process Model exists at a level of abstraction above the System Component Diagram. It captures real-world business processes, and their dependencies, sequence and hierarchy.
40. What is a Logical Functional approach? Conceptual Level: Business Process Model 08/19/10 A Conceptual Functional Model: The BPM
41.
42. 08/19/10 What is a Logical Functional approach? Logical Application Level: ESPN Components
43. What is a Logical Functional approach? Logical Application Level: Domain Class Object 08/19/10 The Component is drawn at a level of abstraction above the Domain Class.
44. 08/19/10 What is a Logical Functional approach? Logical Application Level: Domain Class Objects
45. What is a Logical Functional approach? How is a Logical Data Model Constructed? 08/19/10 DOMAIN CLASS INTEGRATION The Classes defined on a Domain Class Diagram may be integrated by Reference or by Generation to or from the Logical Diagram, as composite data entities.
46. 08/19/10 Categorization Generalizationpecification What is Data Normalization? Ensuring Stability Against Rapid Change Normalization of Entities by Domains IDEF4 is used for Object-Oriented Design Methods. Data Entities may have Object-Relational influence – even integrate with Domain Class designs. IDEF1X provides support for Normalizing entities this way.
47. 08/19/10 How can Application Architecture and Data Architecture integrate and work in parallel here at ESPN? Take Away: What are the components of Logical Modeling? Take Away
48. Logical Analysis & Design V Are Logical Data Models Really Necessary? 08/19/10 Part V
49.
50. Are Logical Data Models Really Necessary? Do We Believe in Codd? 08/19/10
51.
52.
53. Logical Analysis & Design VI What is a Relational Database, Really? 08/19/10 Part VI
54.
55.
56.
57.
58.
59.
60. 08/19/10 “ No.” What is a Relational Database, Really? Codd’s Theories Are Still Relevant to ESPN
61. Logical Analysis & Design VII What is Data Normalization, really? 08/19/10 Part VII
62.
63. What is Data Normalization? Avoiding Data Anomalies Down the Road 08/19/10 Functional Dependency Full Functional Dependency Partial Functional Dependency Transitive Functional Dependency Multi-Valued Dependency The RDBMS Engine is Designed to Protect the Integrity of Data, so long as Codd’s Principles are followed within it. Analysis to Avoid Data Anomalies in the Database
64. What is Data Normalization? Reliable Transactions: Functional Dependency 08/19/10 Functional Dependency If Brand and Advertiser are attributes of a table, then Brand is Functionally Dependent on Advertiser, if each value of Brand is associated with exactly one instance of Advertiser. FD: Advertiser Brand (1) Advertiser (n) Brands
65. 08/19/10 Full Functional Dependency (composite keys) To be Fully Functional, an attribute must be dependent upon a composite key (a key made up of more than one attribute). Of the following dependencies, which is Fully Functionally Dependent? Agency + Advertiser Agency Contact Agency + Advertiser ESPN Account Rep Which relationship is Partially Dependent? What is Data Normalization? Reliable Transactions: Full Functional Dependency
66. 08/19/10 Transitive Functional Dependency Suppose we want to collect information for an ESPN Account Rep, relative to his contact with an Agency representing a specific Advertiser. We would keep Comments about the communication, the Date of the last communication, the Name of the person we spoke with at the Agency, and that person’s formal Title. Agency + Advertiser + ESPN Account Rep + Date of Last Contact Comment, Contact Name, Contact Title What is Data Normalization? Reliable Transactions: Transitive Functional Dependency
67. 08/19/10 Logically, if all those Proposals existed within the same entity, that would indicate the existence of one kind of row (the master Proposal) implied the existence of other related kinds of rows (the child or linked Proposals). Those related rows would be based on different values, however. There would be at least one multi-valued dependency: Proposal Identifier Rating Type and Proposal Identifier Brand ID Multi-Valued Dependency Suppose we have a Proposal for an Agency which includes a master Proposal for Nike and several linked proposals created to address a) different Ratings Types (audience coverage) Nike wishes to reach, and b) Ad Sales for different Nike Brands. What is Data Normalization? Reliable Transactions: Multi-Valued Dependency
68. Logical Analysis & Design VIII An Example of a General Purpose Artifact 08/19/10 Part VIII
69. An Example of a General Purpose Artifact Logical Data Modeling: Reifying Chaos 08/19/10
70. An Example of a General Purpose Artifact Logical Data Modeling: The Data Model (ErD) 08/19/10 How do we get from all of that to something that looks like this?
71. An Example of a General Purpose Artifact A More in Depth Look at the Data Artifacts 08/19/10
72. An Example of a General Purpose Artifact What are the Primary Data Artifacts? 08/19/10 DOMAIN CLASS DIAGRAM LOGICAL DATA MODEL DATA FLOW DIAGRAM
73. An Example of a General Purpose Artifact What is a Data Flow Diagram? 08/19/10 DFD “ Different vendors, consultants, and authors may have alternative views on this, but I have always considered DFD's to be more-or-less equivalent to Business Process Models, in the sense that they show a "workflow" progression of data inputs being transformed into outputs, and then sent on to the next process. DFDs are (also) generally considered to be the lower-level "details" of inputs/processes/outputs that are contained within the components of a System Component Diagram.” Ed Yourdon
74. An Example of a General Purpose Artifact Conceptual Process with Data Sets: Data Flow Diagram 08/19/10 A Data Flow Diagram reifies context, roles, organizational units, external entities, process, workflow splits - and most significantly: Data Stores. The DFD is an artifact intended to integrate Application Design and the Data Model. A DFD is one example of an artifact which may be used by more than one IT group, at either the Conceptual or Logical Stages.
75. An Example of a General Purpose Artifact An Alternative Conceptual Approach to Semantics 08/19/10 DATA STORES As with the Semantic Analysis, an analyst can collect conceptual data base types and composites as a by-product of reviewing and recording application components, business processes and work-flow study.
76. An Example of a General Purpose Artifact The Transformation Process and the Data Store 08/19/10 A Process is defined as an activity that transforms data, whether it be a system component, a business function -or both. A Data Store may be derived from either a system component or a business function.
77. An Example of a General Purpose Artifact The Context Diagram 08/19/10
78. An Example of a General Purpose Artifact Component Decomposition 08/19/10
79. An Example of a General Purpose Artifact Decomposition Continues… 08/19/10
80. An Example of a General Purpose Artifact The Objective: The Data Dictionary 08/19/10
81. An Example of a General Purpose Artifact How is a Logical Data Model Constructed? 08/19/10 DATA STORE INTEGRATION Data Stores are the Base and Composite Types of a Semantic Model. Once defined within an artifact, they may be integrated by Generation from their Conceptual state to other Conceptual or Logical Diagrams.
82. 08/19/10 An Example of a General Purpose Artifact Normalizing the Data Stores: The ESPN Method
83. What is Data Normalization? The Normalized Logical Data Model 08/19/10 The End Result of the Normalization Process.
84. Logical Analysis & Design IX What might artifact integration look like? 08/19/10 Part IX
85. 08/19/10 What might artifact integration look like? Model Integration: By Reference or by Generation
86. What might artifact integration look like? Model Integration: An Illustration 08/19/10 Generation links - are created during model or object generation. Each generated object is linked with its origin object. Shortcuts - create a reference to an object in another model. They are either created explicitly in order to share or reuse an object in another model, or implicitly when creating other kinds of links in a CASE tool. Generation links - are created during model or object generation. Each generated object is linked with its origin object. Shortcuts - create a reference to an object in another model. They are either created explicitly in order to share or reuse an object in another model, or implicitly when creating other kinds of links in a CASE tool. Conceptual Logical Logical Logical Conceptual Physical Physical As Is
87. What might artifact integration look like? Take Away 08/19/10 Take Away: Will a common selection and integration of artifacts further unite ESPN IT as an organization?
I have an agenda we’ll take a look at in a minute.
TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
TROUBLE - Hopefully, I’ve already convinced you that LOGICAL DATA MODELING is all about language, words.
This is an organizational-level look at the enterprise architecture we use to define, design, deliver and manage solutions.
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.
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.
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
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.
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
Data requirements are Conceptual Base Types and key columns.
Data requirements are designed to fulfill functional requirements at the class level.
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.
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
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”)?
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.
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.
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
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
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
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