In a database schema of this size, it can be hard to get your bearings. To help you
understand the territory, this topic contains some logical data models, generally centered
around key database objects.
Note: These illustrations are not detailed schema diagrams (such
as you could generate using Microsoft SQL Server). Instead, they provide high-level "mud
maps" of key objects in the IT Asset Management system, with some indications of how
they relate to one another. These are logical or conceptual models. For details about how
individual database tables link to each other, see the detailed descriptions in the
following pages.
Overview
The first diagram gives an overview of the major components (database objects) in the
system. Because the four kinds of enterprise groups shown across the bottom of the diagram
have so many possible links to the other objects, no links for these are included in the
overview (more links are visible in the following more specialized diagrams).
Figure: Overview model
The following logical models focus on one of these objects at a time, providing a few
of the more important attributes or properties of those key objects in the database, and
fleshing out more details of their relationships to other objects.
Asset model
In IT Asset Management, an asset is an item of hardware (including, but not limited
to, computer hardware). Like a physical asset register, these records are kept separate from
the inventory records that may contribute to the details about computer hardware. For this
reason, you see the close link between the asset object and the inventory device object.
Also notice that an asset may be linked to one of each kind of enterprise group (shown in
gray across the bottom of the diagram).Figure: Asset model
Inventory device model
Inventory devices are records of hardware objects from which hardware and (most often)
software inventory has been collected. Even though inventory devices are closely related to
assets, they have their own potential links to one of each kind of enterprise group. To
avoid double handling, there are settings in the web interface for IT Asset Management to have the ownership of one track the other. However, it is possible to
assign these records separately, so that (for example) you may link an asset to the Illinois
state head office for its asset register, but have the inventory device linked to a location
in the Itasca local office.Figure: Inventory device model
Software title model
A software title database object models what is called an application in the
web interface of IT Asset Management. Evidence of various types
is whatever may be found on a computer that identifies the application, with the mapping
between evidence and application normally supplied through the Application Recognition
Library. Applications do not link directly with inventory devices: there is an intermediate
installation object that provides this link. Note also that some server-based software has
additional evidence types (such as access and usage evidence) that helps to track
requirements for CALs.Figure: Software title model
License model
The license is perhaps the most central object in the data model, since ultimately
everything else exists to allow correct calculation of incoming entitlements and consumption
of those entitlements within your enterprise. Notice that individual allocations, controlled
through the license properties in the web interface, are kept as separate
records linking the license record either to an inventory device or a user.Figure: License model
Purchase order model
For historical reasons, the database models a purchase order as a separate header record
and one or more line items from that purchase order. In the web interface for
IT Asset Management, purchases are now represented as separate objects (each purchase
maps to one PO line in the database), with purchase order headers represented only by a few
common values appended to the top of the purchase properties. The common structure for
purchases may be used for a variety of objects: software and hardware purchases, as well as
renewals of maintenance contracts and the like.Figure: Purchase model
Contract model
Contracts may be used to track any kind of real-world contract, and they are particularly
useful for modeling support contracts or maintenance (or in Microsoft terms, Software
Assurance). These are also the mechanism for tracking regular payments. Since a contract may
include many terms and conditions, these are modeled as separate objects in the
database.Figure: Contract model
User model
A user is not a person operating the IT Asset Management system itself (these people
are called operators, and are managed separately). A user is a person allowed to use an
inventory device, or may be also be linked as the owner of an asset. In earlier
incarnations, these were called "end users", if that helps to clarify the distinction from
operators.Figure: User model
