Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "DAT375 Modeling Business Requirements using Object Role Modeling (Part 1) LeRoy Tuttle, Jr. Program Manager Microsoft."— Presentation transcript:

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

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

3 VSEA Database Design Tools Visio-based (VEA) 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 Non-Visio – Online physical database design tools – SQL query designer 3

4 Visio for EnterpriseArchitects(VEA) Database and Software modeling Networkdiagramming subsumes part of

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

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

7 Examining a Scheduling Theme 7

8 Examining a Scheduling Theme (Tabular Information) Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri Team Meeting Manager 1:1 Brownbag Lunch: ORM Data Modeling Project All-hands Quarterly Meeting Offsite Training Class Out of Office: Doctor Apt Team Meeting Manager 1:1 Brownbag Lunch: ORM Data Modeling Project All-hands Quarterly Meeting Offsite Training Class Out of Office: Doctor Apt Conf A 246 101 151 101 NA Conf A 246 101 151 101 NA 1.0 2.5 1.5 5.0 2.5 1.0 2.5 1.5 5.0 2.5 Meeting subject LocationLocation RoomRoom DurationDuration 27 117 62 117 NA 27 117 62 117 NA BuildingBuilding 10:30 9:30 12:00 1:30 10:00 11:00 9:00 10:30 9:30 12:00 1:30 10:00 11:00 9:00 Yes No Yes No Yes No Yes No RecurringRecurring Appointment time HourHourWeekdayWeekday 1234567812345678 1234567812345678 IDID 8

9 Examining a Scheduling Theme (Object Role Modeling) 9

10 It is impossible that more than one Room at the same HourSlot is booked for the same Activity 10

11 It is impossible that more than one Room at the same HourSlot is booked for the same Activity 11

12

13

14 ORM -> ER -> DDL demo demo 14

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

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

17 Analysis Is A Joint Activity The domain expert best understands the application domain The domain expert best understands the application domain The modeler elicits and formalizes this understanding The modeler elicits and formalizes this understanding 17

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

19 Database Design Roles External and Conceptual LogicalPhysical Principal database design roles Domain experts ModelerModelerDeveloperDeveloperModeler Focus Capture business requirements Document relational design Implement relational design Modeling methodology ORMER Transact-SQL DDL 19

20 Set Theory Review Instances, Populations, Sets, and Collections Instances, Populations, Sets, and Collections Instance Relationships Instance Relationships Set Existence Set Existence Set Forming Operations Set Forming Operations

21 Instances, Populations, Sets, and Collections Instance Instance Population Population Set Set Member Member Collection Collection 21 Population CC EE AA DD BB Collection CC EE DD AA AADD

22 1:1 n:m 1:n Instance Relationships Cardinality Cardinality – One-to-one (1:1) – One-to-many (1:n) – Many-to-many (n:m) Mandatory vs. optional cardinality Mandatory vs. optional cardinality 22 AA AA BB BB BB BB AA AA BB BB BB

23 Set Existence 23 Identity AABB Mutual exclusion A A B B Overlap B A Subset AA B

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

25 Conceptual Schema Design Procedure (CSDP) Model Relationships 1) Analyze External Information and Create a Conceptual Model 2) Draw a Fact Types and Apply a Population Check 3) Identify Primitive Entity Types and Reformulate Arithmetically Derived Fact Types Derived Fact Types Constrain Relationships 4) Add Uniqueness Constraints and Check Arity of Fact Types 5) Add Mandatory Role Constraints and Check for Logical Derivations Derivations 6) Add Value and Set Constraints, and Create Entity Subtypes 7) Add Frequency, Ring, and Other Constraints

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

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

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

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

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

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

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

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

34 CSDP Step 1 demo demo 34

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

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

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

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

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

40 CSDP Step 2 demo demo 40

41 CSDP Step 3 Check 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

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

43 Partitioning Object Types Atomic Numbers Atomic Strings Atomic Nested Entity Types Value Types Object Types in the Universe of Discourse 43

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

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

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

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

48 CSDP Step 3 demo demo 48

49 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 Documenting the Model Implementing the Model Implementing the Model

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

51 Further Resources MOC Course 2090: Modeling Business Requirements to Create a Database Using Visual Studio.NET Enterprise Architect MOC Course 2090: Modeling Business Requirements to Create a Database Using Visual Studio.NET Enterprise Architect http://msdn.microsoft.com/theshow/ (Episode 25) http://msdn.microsoft.com/theshow/ (Episode 25) http://msdn.microsoft.com/theshow/ http://www.msdn.microsoft.com/library/en- us/dv_vstechart/html/vstchvsea_ormoverview.asp http://www.msdn.microsoft.com/library/en- us/dv_vstechart/html/vstchvsea_ormoverview.asp http://www.msdn.microsoft.com/library/en- us/dv_vstechart/html/vstchvsea_ormoverview.asp http://www.msdn.microsoft.com/library/en- us/dv_vstechart/html/vstchvsea_ormoverview.asp (+ articles on use of VEA) (+ articles on use of VEA) http://www.orm.net http://www.orm.net http://www.orm.net http://www.inconcept.com http://www.inconcept.com http://www.inconcept.com http://www.ormcentral.com http://www.ormcentral.com http://www.ormcentral.com Halpin, T.A. 2001, Information Modeling and Relational Databases, Morgan Kaufmann (ISBN 1-55860-672-6) Halpin, T.A. 2001, Information Modeling and Relational Databases, Morgan Kaufmann (ISBN 1-55860-672-6)

52 Don’t forget to complete the on-line Session Feedback form on the Attendee Web site https://web.mseventseurope.com/teched/ https://web.mseventseurope.com/teched/

53


Download ppt "DAT375 Modeling Business Requirements using Object Role Modeling (Part 1) LeRoy Tuttle, Jr. Program Manager Microsoft."

Similar presentations


Ads by Google