Logical Data Models

FlexNet Manager Suite 2022 R1 (On-Premises)
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 FlexNet Manager Suite 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.


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

A model of the major objects used in FNMS
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 FlexNet Manager Suite, 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

A subsection of the overall model, focused on hardware assets

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 FlexNet Manager Suite 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

An aspect of the logical model focused on inventory device

Software title model

A software title database object models what is called an application in the web interface of FlexNet Manager Suite. 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

A data model aspect focused on application records

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

A data model aspect focused on license records

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 FlexNet Manager Suite, 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

A data model aspect focused on purchases and purchase orders

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

A data model aspect focused on contracts

User model

A user is not a person operating the FlexNet Manager Suite 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

A data model aspect focused on end-users