copyright © 2013-2015 curt hill components and artifacts data and information

Copyright © 2013-2015 Curt Hill

Components and Artifacts

Data and Information

Recall the Cube


Introduction• In this EA3 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


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


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


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


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


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


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


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?


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


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 artifactCopyright © 2013-2015 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


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?


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


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


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


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


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


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


UML Purchase Diagram


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


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


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


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


Example


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


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


A simplified ER diagram


Sells

Airline

Ticket

PassengerNotifies

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


Subset ER Diagram


Sells

Airline

Ticket

Name Address

TypeDate

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


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


ER Diagram Again


Sells

Airline

Ticket

Name Address

TypeDate

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


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


Example


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


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


CRUD

• Not the content of this course!• Four basic functions of persistent

data:– Create– Read– Update– Delete


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


Example


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


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


Representation


Your Turn

• What is the point of a data dictionary?

• Is program documentation sufficient for this?


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 components and artifacts data and information

Documents

curt hillcopyright

data warehousingbuilt

data flow

data warehousemust

data warehousecopyright

curt hillintroductionin

curt hillcomponents

curt hillrecall