Copyright © Curt Hill Components and Artifacts Data and Information

Recall the Cube Copyright © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

UML Purchase Diagram Copyright © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

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 © Curt Hill

Example Copyright © Curt Hill

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 © Curt Hill

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 © Curt Hill

A simplified ER diagram Copyright © Curt Hill Sells Airline Ticket Passenger Notifies Purchases

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 © Curt Hill

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

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 © Curt Hill

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 © Curt Hill

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

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 © Curt Hill

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 © Curt Hill

Example Copyright © Curt Hill

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 © Curt Hill

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 © Curt Hill

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

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 © Curt Hill

Example Copyright © Curt Hill

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 © Curt Hill

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 © Curt Hill

Representation Copyright © Curt Hill

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

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 © Curt Hill