Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UML for Data Architects


Published on

Published in: Technology
  • Sex in your area is here: ♥♥♥ ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❤❤❤ ❤❤❤
    Are you sure you want to  Yes  No
    Your message goes here

UML for Data Architects

  1. 1. UML for Data Architects:A Painless IntroductionDr. Vladimir
  2. 2. About the Speaker: Dr. Vladimir Bacvanski Mission: to make organizations successful in solving problems through adoption of modern software technologies – Founder of SciSpike – a training and consulting firm specializing in advanced software technologies – Over two decades of experience with software and data technologies – Vladimir has helped a number of organizations including US Treasury, Federal Reserve Bank, US Navy, IBM, Dell, Hewlett Packard, JP Morgan Chase, Nokia, g Lucent, Nortel Networks, General Electric, BAE Systems, AMD, and others – Frequent speaker at leading industry events. q p g y – For three years in a row awarded the title "IBM Information Champion" for his contributions to the information management community g y Copyright © SciSpike 2011 2
  3. 3. Outline What is UML? How to approach UML? (aka "Avoiding pain") UML diagrams: use only what you need! g y y Representing structure: class (aka type) diagrams UML for database design Automation Conclusion Copyright © SciSpike 2011 3
  4. 4. What is UML? The UML is a graphical language for software intensive systems f – Note: UML is just a notation: the way we visualize our decisions h i li d ii UML covers a broad area of software development d l t UML is a standard: it enables you to express your models i a way th t d l in that can be understood by others Copyright © SciSpike 2011 4
  5. 5. Models and Diagrams Model is a view of a system from a particular perspective Diagram visually presents elements of a model – One model can be presented with several diagrams, each focusing on a separate aspect Copyright © SciSpike 2011 5
  6. 6. UML Diagrams Diagrams in italics are introduced in UML 2 Copyright © SciSpike 2011 6
  7. 7. Choose your Approach to UML! Painful Painless• Focus on > 95% of UML • Focus on < 5% of UML that th t you d t need dont d that th t you need d• Start with a 1000+ • Start with a subset pages UML Reference relevant to data• Avoid practical modeling examples • Seek practical guides• Use UML for all the and examples wrong reasons • Use UML to communicate and automate Copyright © SciSpike 2011 7
  8. 8. Modeling Data with UML Class Diagrams A subset of UML Class Diagram is very close to notations used in d d data modeling d l UML Class Diagrams have features not needed for data modeling: d l – Operations (methods) – Visibility (public, private, …) We can use only a subset that make sense for data modeling: – Classes (aka "types") – Attributes – Associations – Generalization Copyright © SciSpike 2011 8
  9. 9. UML Classes and Attributes Class Similar to entity in ERD. Customer Class name Typically capitalized. Attribute Compartment The only compartment we care about.  UML classes can have other  compartments, e.g. for operations. It is fine to skip parts we dont need! pp Note: N tAttribute Name Attribute Type High level class Typically  E.g. String, Integer,…  diagrams typically dont lowercase.  but also other class names need primary and  foreign keys. Copyright © SciSpike 2011 9
  10. 10. UML Associations Association Association Name Multiplicity Usually skipped. *: zero or many 1..*: one or many 0..1: zero or one Association Role Start from a class, follow the  Start from a class follow the Note: association, read the role of the  Foreign key attributes are  not needed associated objects. Copyright © SciSpike 2011 10
  11. 11. Navigability 1..* * Person Address homeAddress High level diagrams typically do not show navigability Navigability is a design decision! – It is a bad practice to assign navigability prematurely – Typically not needed for modeling when we target relational databases Copyright © SciSpike 2011 11
  12. 12. Associations vs. Attributes Person P Multiplicity M lti li it Company C employer: Company[*] p y p y[ ] employee: Person[1..*] p y [ ] In UML, attributes and associations are equivalent! Choose the representation that is more suitable to the reader Important relationships are often represented as associations – they bring the visual emphasis Copyright © SciSpike 2011 12
  13. 13. Association Class Association  Class Cl Association class allows to attach information to an association – Often refined into two associations to a class Copyright © SciSpike 2011 13
  14. 14. Association Class Refined Association classes are commonly refined in lower level y diagrams Copyright © SciSpike 2011 14
  15. 15. Semantics of Aggregation and Composition 1 Car Engine Aggregation 1 Car Engine Composition Aggregation: shortcut for "has" relationship has – Does not have a well defined semantics. Use sparingly! Composition lifetime of the owner determines the lifetime Composition: of the owned objects – Similar to "cascading" cascading Copyright © SciSpike 2011 15
  16. 16. Generalization (aka Inheritance) Employee Generalization G li i Engineer Manager TechWriter Subclasses extend superclasses with additional attributes and associations This relationship eventually needs to be mapped to tables for relational database design – Several solutions possible with different performance impact. Choice impact depends on the typical pattern of usage. Copyright © SciSpike 2011 16
  17. 17. Constraints Constraints can be expressed as: – Plain text – OCL: Object Constraint Language, part of UML • Not common in mainstream projects • Enforcable Copyright © SciSpike 2011 17
  18. 18. Organizing UML Models: Packages  A package is a structuring element Customer Management – It contains other elements and diagrams Sales  P k Packages are important i for managing complexity of models  Prefer models organized Inventory into packages to huge diagrams Copyright © SciSpike 2011 18
  19. 19. Mapping UML to ER Models… Class  Entity – Add primary key Simple Attribute Type  Column Type Complex Attribute Type  Relationship to an entity for the attribute type Association  Foreign Key relationships – Use role names for foreign keys – Many-to-many association  add an associative table – Aggregation: treat as ordinary relationships Copyright © SciSpike 2011 19
  20. 20. …Mapping UML to ER Models Generalization: use the usual mappings: – Table per class hierarchy – Table per subclass – Table per concrete class Constraints – Set constraints on the database – Some only enforceable in application logic y pp g This is just a simplified set of rules to get you going! Copyright © SciSpike 2011 20
  21. 21. UML for Database Design Agile teams often use UML for both software and database design UML data modeling profile introduces extensions to UML: – <<PK>>, <<FK>>, <<Auto Generated>>, <<Not Null>>, <<View>>, <<Stored Procedures>>,… Use relational data types – String  CHAR(x), VARCHAR(x) Copyright © SciSpike 2011 21
  22. 22. Automation Code Transformer DDL Input Models Models Output Tools can convert from UML to ERD and vice versa Model transformation tools operate at a MOF/EMF level and can transform UML to various targets – Visual Domain Specific Languages (DSLs) based on UML may provide better alignment with the p g problem domain than vanilla UML Copyright © SciSpike 2011 22
  23. 23. Conclusion You will need just a small part of UML! UML is a common starting point for data models Mapping of UML to ER is quite straightforward pp g q g Knowing UML makes you a more significant player in the software development p p process Copyright © SciSpike 2011 23
  24. 24. Getting in Touch Email: Blog: Twitter: p LinkedIn: SciSpike Training and Consulting: http://www scispike com – Related training for data architects: • Visual Modeling with UML • Mastering Data Modeling with InfoSphere Data Architect Copyright © SciSpike 2011 24