1. Copyright © 2013-2015 Curt Hill Components and Artifacts Data and Information

2. Recall the Cube Copyright © 2013-2015 Curt Hill

3. Introduction In this EA 3 model there are five levels Goals and Initiatives Products and Services Data and Information Systems and Applications Network and Infrastructure This considers the components and artifacts of the Data and Information Copyright © 2013-2015 Curt Hill

4. What is here? Description of –Information systems –Transactional databases –Knowledge warehouses –Data marts We are interested in the how and why at this level –The next level documents the individual software pieces Copyright © 2013-2015 Curt Hill

5. Some Definitions Data –Small measurable pieces of information –Foundation of knowledge Information –Organized data –Putting data into meaningful patterns Knowledge –A higher aggregation of information and data that enables interpretation –Ability to use information –Sets of rules and relationships Copyright © 2013-2015 Curt Hill

6. Data Mart A data warehouse restricted to a single subject –Such as a group or line of business within a larger organization A dependent data mart obtains its data from the central organizational data warehouse An independent data mart obtains data from other sources –Incomplete overlap with the data warehouse Copyright © 2013-2015 Curt Hill

7. Knowledge Warehouse An architectural integration of knowledge management, decision support, artificial intelligence and data warehousing Built on top of a data warehouse Must also encode the rules and processes of the business –These rules used to only be in the minds of employees –Next captured on documents Copyright © 2013-2015 Curt Hill

8. Your Turn Who would use a data mart? –How would it be built? –How many would a large organization have? Why would we want a Knowledge Warehouse? –How many would a large organization have Copyright © 2013-2015 Curt Hill

9. What Artifacts? Knowledge Management Plan Information Exchange Matrix Object State Transition Diagram Object Event Sequence Diagram Logical Data Model Physical Data Model Activity/Entry Matrix Data Dictionary Copyright © 2013-2015 Curt Hill

10. Knowledge Management Plan General plan about managing data, information and knowledge It intends to answer a large variety of questions: –Where does the data come from? –How is it maintained? –Where is it used? –How does the data support the business plan? –How is it used by each LOB? Copyright © 2013-2015 Curt Hill

11. KM Plan Usually two components to this A diagram that considers the pieces –LOBs –Transactional databases –Data warehouses and data marts –Knowledge warehouses –Web sites –Document repositories Document that narrates how these interact Copyright © 2013-2015 Curt Hill

12. Information Exchange Matrix Generally how is data transferred inside and across enterprise boundaries –How does data flow? This should consider the following exchange characteristics: –Content and format of the data –The timing of exchanges –Events that trigger the exchange –Who is performing this exchange Each exchange gets its own artifact Copyright © 2013-2015 Curt Hill

13. Exchange Security Every transfer of data involves multiple systems It also raises security issues Movement of data from one system to another is the prime opportunity to smuggle it out of the enterprise Copyright © 2013-2015 Curt Hill

14. Your Turn Consider two scenarios: –Data transferred from an external partner. –Data transferred from one department to another What are the dangers in regards to security? Copyright © 2013-2015 Curt Hill

15. Document Contents Source and target systems Logical description of data Attributes of the data The event that triggers the exchange The needline of the node connectivity diagram from the Products and Services level Others as well Copyright © 2013-2015 Curt Hill

16. Objects There are several definitions of object Here these may collide –We use one and then another The next screen defines an object from a programming language perspective We may also think of an object in terms of a system, a transaction and several other ways Copyright © 2013-2015 Curt Hill

17. Objects An object is a representation of a real world entity on a computer –A thing or event They may be simple or complicated –A date is simple –A transaction is more complicated Each object has: –Attributes –Behaviors In programming we consider the details, but here a higher level view Copyright © 2013-2015 Curt Hill

18. Interlude We will next look at several artifacts that record information on objects We will look at a two examples –Buying airline tickets online –Buying cars We will then see several different views None of them tell us everything Someone may need just one or all of them while studying the repository Copyright © 2013-2015 Curt Hill

19. Object State Transition Diagram Shows how an object is transformed during processing This is the object lifecycle Here the ‘object’ is transformed as it goes through the system Copyright © 2013-2015 Curt Hill

20. Ticket Purchase User specifies the trip details –Day, origination, destination, number System checks if sufficient seats are available –If not transaction is cancelled Gives choice of flights User accepts Obtain credit card Generate order Remove seats Copyright © 2013-2015 Curt Hill

21. UML Purchase Diagram Copyright © 2013-2015 Curt Hill

22. Object Sequencing For this artifact let object have the following meaning: –An application or system which is running –Examples include: A database Web interface Even a person Here we are interested in how independent objects communicate Copyright © 2013-2015 Curt Hill

23. Object Sequence Diagram Each object is a service that should be always available to take requests and respond to them We have communication between any two objects –We are mostly interested in sequencing and timing These diagrams are also known as –Event sequence diagrams –Object event sequence diagrams Copyright © 2013-2015 Curt Hill

24. Object Diagram Each object is represented by a vertical line –This represents the object through time –Higher is older – so time flows down Horizontal lines between two represent messages –We are mostly interested in sequencing and timing A rectangle around the vertical line indicates processing –Approximating duration Copyright © 2013-2015 Curt Hill

25. Example We will look at an example involving four objects A person ordering airline tickets The web interface –Central object in this diagram The flight database –All the flights and all the seats A credit card authorization/charging system All systems are available continuously Copyright © 2013-2015 Curt Hill

26. Example Copyright © 2013-2015 Curt Hill

27. Logical Data Model Another model that is needed shows relationships between objects Several possibilities exist –Entity Relationship Diagram –Class or object diagram The goal in both cases is to show relationship among a set of objects Copyright © 2013-2015 Curt Hill

28. Entity-Relationship Diagrams A pictorial mechanism to show what is going on –Typically used in databases to model tables Not standardized –They come in many variations Entities – rectangles Attributes – ovals Relationships – diamonds Connections – lines Copyright © 2013-2015 Curt Hill

29. A simplified ER diagram Copyright © 2013-2015 Curt Hill Sells Airline Ticket Passenger Notifies Purchases

30. A manufacturing ER diagram Last one had no attributes for several reasons Often that is how we get started –Refine as we go along These tend to be both formal and informal The graphic had no space Copyright © 2013-2015 Curt Hill

31. Subset ER Diagram Copyright © 2013-2015 Curt Hill Sells Airline Ticket Name Address Type Date Row/No Fee Flight AID Date TID SID

32. Legend on the above Two perpendicular lines indicate an arity of one Terminating with three lines indicates an arity of many Underlined name indicates key –There may be more than one Relationships do not have to be between just two different types of entities –Binary, ternary, n-ary –One or more different tables Copyright © 2013-2015 Curt Hill

33. Variants The above diagram is often called Crow’s Foot diagram –The arity relationship is done using crow’s feet or perpendicular lines The alternative is called Chen notation –This must 1,n,m to identify Copyright © 2013-2015 Curt Hill

34. ER Diagram Again Copyright © 2013-2015 Curt Hill Sells Airline Ticket Name Address Type Date Row/No Fee Flight AID Date TID SID 1 M

35. Class Diagram In a database each table has the same format for each row The format type corresponds to a class Each row could be an object of that class Therefore we may also use class diagrams to represent the same things Copyright © 2013-2015 Curt Hill

36. Class Diagram Pieces The basic class is a rectangle Usually partitioned into two or three pieces horizontally –Top is class name –Second is properties –Third is methods or behaviors Arrows usually connect the rectangles –These show the arities Many other pieces –Most not needed today Copyright © 2013-2015 Curt Hill

37. Example Copyright © 2013-2015 Curt Hill

38. Physical Data Model The logical data model is concerned about what makes sense from the business perspective However this needs to be mapped onto physical storage in a computer system This could be: –Relational database –Other type of database –Flat file structure Copyright © 2013-2015 Curt Hill

39. Physical Data Model What we find are often text descriptions –ERDs may exist What we want –Schemas Such as SQL DDL –File structure definitions File names and record descriptions –Message format Format, type, source, destination Any of these may describe the Logical Data Model being considered Copyright © 2013-2015 Curt Hill

40. CRUD Not the content of this course! Four basic functions of persistent data: –Create –Read –Update –Delete Copyright © 2013-2015 Curt Hill

41. Activity/Entity Matrix A table with entities (that is objects) on one axis and activities as the other For each activity, what action is performed on each entity? The intersection will often be one of the CRUD actions We may also see departmental involvement Copyright © 2013-2015 Curt Hill

42. Example Copyright © 2013-2015 Curt Hill

43. Commentary The example activity/entry said nothing about who performed the actions These may be added by signifying departments in different colors and enclosing them in boxes or ovals Copyright © 2013-2015 Curt Hill

44. Data Dictionary A centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format IBM Dictionary of Computing Meta data For every field in every table or file there should be a description Type Length Origin Container Copyright © 2013-2015 Curt Hill

45. Representation Copyright © 2013-2015 Curt Hill

46. Your Turn What is the point of a data dictionary? Is program documentation sufficient for this? Copyright © 2013-2015 Curt Hill

47. Finally In this level we mostly examine IT things These need a technical documentation, unlike what we have seen in levels above this It will get more technical as we go to the next level Copyright © 2013-2015 Curt Hill