1 / 53

DAT375 Modeling Business Requirements using Object Role Modeling (Part 1)

DAT375 Modeling Business Requirements using Object Role Modeling (Part 1). LeRoy Tuttle, Jr. Program Manager Microsoft. Agenda – Part 1 (DAT375). Visual Studio .NET Enterprise Architect Object Role Modeling Database Design Process Set Theory Review Object Role Modeling

aquila
Download Presentation

DAT375 Modeling Business Requirements using Object Role Modeling (Part 1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DAT375Modeling Business Requirements using Object Role Modeling (Part 1) LeRoy Tuttle, Jr. Program Manager Microsoft

  2. Agenda – Part 1(DAT375) • Visual Studio .NET Enterprise Architect • Object Role Modeling • Database Design Process • Set Theory Review • Object Role Modeling • Conceptual Schema Design Procedure • Modeling fact types • Constraining fact types • Documenting the Model • Implementing the Model

  3. VSEA Database Design Tools • Visio-based (VEA) • Conceptual data modeling (ORM) • Logical database modeling (Relational, IDEF1X, “ER”) • Physical database modeling(SQL Server, Access, Oracle, DB2, etc.) • Forward and reverse engineering, sync, import/export, reports, etc. • Non-Visio • Online physical database design tools • SQL query designer 3

  4. Database and Software modeling Visio for Enterprise Architects (VEA) part of Network diagramming subsumes

  5. Object Role Modeling (ORM) • Understandable • Express facts and rules in plain language • Capable • Capture more business rules • Reliable • Validate rules in English with sample data • Stable • Minimize the impact of change • Executable 5

  6. Fact-Orientation • Data examples are expressed as facts • How facts are grouped into structures (tables, classes, etc.) is not a conceptual issue • Fact-orientation is at a level above object-orientation • Here is where domain expert and modeler should communicate 6

  7. Examining a Scheduling Theme 7

  8. ID Recurring Location Duration Appointment time Meeting subject Building Room Weekday Hour 1 2 3 4 5 6 7 8 Yes Yes No Yes Yes No No No Mon Tue Tue Tue Wed Thu Thu Fri 27 27 117 62 62 117 NA NA Conf A 246 101 151 151 101 NA NA 1.0 1.0 1.0 2.5 2.5 1.5 5.0 2.5 10:30 9:30 12:00 1:30 1:30 10:00 11:00 9:00 Team Meeting Manager 1:1 Brownbag Lunch: ORM Data Modeling Project Data Modeling Project All-hands Quarterly Meeting Offsite Training Class Out of Office: Doctor Apt Examining a Scheduling Theme(Tabular Information) 8

  9. Examining a Scheduling Theme(Object Role Modeling) 9

  10. It is impossible that more than oneRoom atthe sameHourSlot is booked forthe sameActivity 10

  11. It is impossible that more than oneRoom atthe sameHourSlot is booked forthe sameActivity 11

  12. demo ORM -> ER -> DDL 14

  13. The Baseline Database Design Process Modeling business requirements Modeling databases External Conceptual Logical Physical 15

  14. Universe of Discourse Record Keeping SQL Business Context as a Foundation 16

  15. Analysis Is A Joint Activity • The domain expertbest understands the application domain • The modelerelicits and formalizes this understanding 17

  16. Who Are Domain Experts? • Definition Domain experts are the people who provide business requirements to the modeler • Examples • Subject matter experts • Knowledge workers • Business analysts • System architects • Developers 18

  17. Database Design Roles 19

  18. Set Theory Review • Instances, Populations, Sets, and Collections • Instance Relationships • Set Existence • Set Forming Operations

  19. Instances, Populations, Sets, and Collections Population • Instance • Population • Set • Member • Collection A C E B D Collection C E A D A D 21

  20. Cardinality One-to-one (1:1) One-to-many (1:n) Many-to-many (n:m) Mandatory vs. optional cardinality B B B B B B Instance Relationships 1:1 A B 1:n A n:m A A 22

  21. A B Set Existence Mutual exclusion Overlap A B B A Identity Subset A B 23

  22. X Y X Y X Y Set Forming Operations Union of sets X U Y Intersection of sets X Y U Difference of sets X - Y 24

  23. Conceptual Schema Design Procedure (CSDP)

  24. CSDP Step 1Analyze External Information and Create a Conceptual Model • Creates the conceptual model • Fact-driven design • Object types • Predicates • Communicating intent

  25. Fact-Driven Design • Goals of the modeler • Represent semantic relationships between objects • Capture business rules • Do not capture business processes • Purpose of the data model • Represent allowable states of data in the UoD • Reflect the scope of the UoD 27

  26. What Are Fact Instances? • Definition A fact instance is an individual observation of the relationship between two or more data values • Characteristics • Are examples of relationships between specific data • Are related through an action statement • May have constraints 28

  27. What Are Object Types? • Definition An object type represents the set of all possible instances of a given object • Characteristics • Generic representations of populations • Always named singularly • Always title case • Object kind 29

  28. What Are Predicates? • Definition A predicate is a verb phrase that the domain expert uses to relate object types • Characteristics • Are sentence fragments with holes in them for object type names • Describe unqualified relationships • Have reversible readings 30

  29. What Are Fact Types? • Definition A fact type is the set of fact instances that share the same object types and predicate relationships • Characteristics • Syntax: [Object type] predicate [Object type] • Arity of a fact type • Generic representation • Reversible predicate reading 31

  30. London (LHR) London (LHR) London (LHR) London (LHR) London (LHR) UK11 UK11 UK11 UK11 UK11 US72 US72 US72 US72 US72 IT37 IT37 IT37 IT37 IT37 New York (JFK) New York (JFK) New York (JFK) New York (JFK) New York (JFK) Rome (FCO) Rome (FCO) Rome (FCO) Rome (FCO) Rome (FCO) Madrid (MAD) Madrid (MAD) Madrid (MAD) Madrid (MAD) Madrid (MAD) ES23 ES23 ES23 ES23 ES23 2 1 3 US62 US62 Atlanta (ATL) Atlanta (ATL) US62 US62 US56 Atlanta (ATL) Atlanta (ATL) Atlanta (ATL) VE56 VE56 VE56 VE56 VE56 VE59 VE59 VE59 VE59 VE59 US68 US68 Dakar (DKR) Dakar (DKR) US68 US68 US68 Dakar (DKR) Dakar (DKR) Dakar (DKR) VE56 VE56 VE56 VE56 VE56 Flight US62 originates in Atlanta and terminates in Rome. Flight VE56 originates in Caracas and terminates in Rome. Flight UK11 originates in London and terminates in New York. Caracas (CCS) Caracas (CCS) Caracas (CCS) Caracas (CCS) Caracas (CCS) Practice: Verbalizing Fact Types(Graphical Information) 32

  31. Flight number Origination city Destination city Departure info Status Terminal Gate Time UK11 US72 IT37 ES23 US56 VE59 VE56 US68 London New York Rome Madrid Atlanta Caracas Caracas Atlanta 3 4E Int’l 3 T Int’l Int’l T 5 19 12 5 9 2 4 8 14:25 1:55 11:12 11:12 23:50 8:03 8:48 4:54 On Time Delayed Boarding On Time On Time Canceled On Time Boarding New York London New York Atlanta Rome New York Rome Caracas Practice: Verbalizing Fact Types(Tabular Information) 33

  32. demo CSDP Step 1 34

  33. CSDP Step 2Draw a Conceptual Model and Apply a Population Check • Conceptual data model vs. the diagram • Meaningful sample population

  34. How Objects Types Are Symbolized Kinds of Object Types Object Type Names and Reference Mode 36

  35. How Predicates Are Symbolized Role Arity Binary Ternary Quaternary Role Connector Predicate Phrase 37

  36. 2 1 3 How Fact Types Are Symbolized Object Types Predicate Location’s Role in the Predicate Time’s Role in the Predicate Subject’s Role in the Predicate 38

  37. Validate Fact Types with a Meaningful Sample Population • Data is representative • Data has meaningful variations • DATA IS REAL!! 39

  38. demo CSDP Step 2 40

  39. CSDP Step 3Check for entity types that should be combined, and note any arithmetic derivations • Trim schema • Coalesce like sets • Eliminate use of value types for calculated data

  40. What Is a Conceptual Partitioning Scheme? • Definition A conceptual partitioning scheme is the systematic separation of the UoD’s population into meaningful object types • Characteristics • Group and division of UoD • Mutually exclusive partitions • Exhaustive partitions 42

  41. Object Types in the Universe of Discourse EntityTypes Value Types Atomic Nested Strings Numbers Atomic Atomic Atomic Partitioning Object Types 43

  42. What Are Primitive Entity Types? • Definition Primitive entity types represent the most basic entity types in the UoD • Characteristics • Atomic • Mutually exclusive 44

  43. Car, Bus Van, Boat Vehicle Student, Parent, Firefighter City, State, County Person Location Subject History, Math Literature Example of Primitive Entity Types 45

  44. Look for commonalities Look for need to manipulate query results Guidelines for Coalescing Entity Types • Common instances • Common relationships • Common partitioning scheme • Common unit-based reference mode • Common primitive entity type • Need to perform union on results • Use intersection of sets to create results 46

  45. What Are Derived Fact Types? • Definition A derived fact type is inferred from roles in other fact types • Characteristics • Derivation rule • Derived vs. derived and stored • Use of role names • How derived fact types are symbolized 47

  46. demo CSDP Step 3 48

  47. Agenda – Part 2(DAT376) • Visual Studio .NET Enterprise Architect • Object Role Modeling • Database Design Process • Set Theory Review • Object Role Modeling • Conceptual Schema Design Procedure • Modeling fact types • Constraining fact types • Documenting the Model • Implementing the Model

  48. Concluding Remarks • Modeling Business Requirements vs. Modeling a Database • Use ORM for information analysis • Use data use cases to seed data models • Use Visual Studio .NET Ent. Architect for conceptual, logical, and physical database modeling

More Related