Copyright © 2013-2015 Curt Hill
Components and Artifacts
Data and Information
Recall the Cube
Copyright © 2013-2015 Curt Hill
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
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 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
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 Curt Hill
UML Purchase Diagram
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 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 © 2013-2015 Curt Hill
Example
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 Curt Hill
A simplified ER diagram
Copyright © 2013-2015 Curt Hill
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
Copyright © 2013-2015 Curt Hill
Subset ER Diagram
Copyright © 2013-2015 Curt Hill
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
Copyright © 2013-2015 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 © 2013-2015 Curt Hill
ER Diagram Again
Copyright © 2013-2015 Curt Hill
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
Copyright © 2013-2015 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 © 2013-2015 Curt Hill
Example
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 Curt Hill
CRUD
• Not the content of this course!• Four basic functions of persistent
data:– Create– Read– Update– Delete
Copyright © 2013-2015 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 © 2013-2015 Curt Hill
Example
Copyright © 2013-2015 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 © 2013-2015 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 © 2013-2015 Curt Hill
Representation
Copyright © 2013-2015 Curt Hill
Your Turn
• What is the point of a data dictionary?
• Is program documentation sufficient for this?
Copyright © 2013-2015 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 © 2013-2015 Curt Hill