Overview

This document is gives an overview of the VISTA Repository database. The intended audience is for users who want to create their own reports. It is divided into five sections: Space, Racks, Device, Power, and Connectivity. Each section includes a description of some key concepts, conceptual diagram of objects and their relationships, and a physical ER diagram of the associated tables.
Not every table is included in this document. Most of these undocumented tables fall into two categories:

System tables – Tables controlled by VISTA that should not be used in customer reports.
Unused tables – Empty tables left over from prior versions of VISTA.

Note:
The VISTA database schema is proprietary. Aperture reserves the right to change it as needed between releases. Therefore, if you create your own reports, you should either:

Be prepared to change your reports when you upgrade to a new VISTA release, or
Create a new view on which to base your report, so that if the underlying tables or views change when upgrading, you can ideally just change your view definition without having to change your reports.

There are many existing views that may contain the data you need for your report. However, if you need to add a field to an existing view or report, DO NOT modify it. Create a new view based on the existing table or view, and add the extra fields to the new view. Include your company name or abbreviation in the name to easily distinguish it from system views.

The conceptual model in this document shows the most common cases supported by the model. It does not attempt to show every possible case. Database Keys

The primary key field for most tables is named VOB_ID. It is in the format of a generated GUID (Globally Unique Identifier), a 16-byte number that provides reasonable confidence in its world-wide uniqueness.
The Aperture Client (i.e. Repository Administrator) also generates a key when an object is added to a drawing. This is called a UNIQUEID, and is an 18-character string. A UNIQUEID is only guaranteed to be unique within one Aperture project; it may not be unique across projects.

VISTA Concepts

Device Classification

VISTA models many different kinds of devices. These can be summarized as follows:

Racks/Cabinets - Racks can have devices installed in them.
Power Consuming Devices – Devices such as servers, storage, or networking gear that require power to operate.
Non Power Consuming Devices – Devices such as Patch panels that do not require any power
Power Distribution Devices – Devices such as PDUs, RPPs, Power Strips, etc that supply the power to the Power consuming devices.

All these devices are described in the DV_DEVICE_T table. Some of these devices have specific characteristics that are modeled in different tables. Power Distribution devices for example, have their own set of tables that describe power aspects of these devices.
Each device is represented by a Symbol. A Symbol is a physical representation of the device. This representation has two parts. One part is an actual visual of the device and the other is a description in the database of the physical characteristics of the devices such as its dimensions, number of slots, ports, etc.
Devices are further described by their classification. The fields that help categorize the Device Classification are:

Asset Class – This describes the class of device such as Server, Rack, Cabinet, etc.
Asset Sub Class – This provides a more granular description of the device. This is used to further distinguish the device where Asset Class alone is not enough. For example, Blade Servers are described with an Asset Class of CARD and an Asset Sub Class of BLADE SERVER. Most of the time this value will be the same as the value for ASSET_CLASS.

Here are some typical ASSET CLASS and ASSET SUB CLASS combinations.

Device	Asset Class	Asset Sub Class
Racks/Cabinets	RACK, CABINET	RACK, CABINET
Power Consuming Devices	SERVER, CHASSIS, ROUTER, SWITCH, etc.	SERVER, CHASSIS, ROUTER, SWITCH, etc.
Non Power Consuming	PATCH PANEL, etc.	PATCH PANEL, etc.
Cards	CARD	CARD
Blade Server	CARD	BLADE SERVER
Power Distribution Devices	PDU, RPP	PDU, RPP

Although all these devices are described in the DV_DEVICE_T table, the use of the Asset Class and Asset Sub Class can be used to distinguish these devices during reporting.

Device Placement

VISTA supports three main placement types. These are placing devices on a raised floor space, in a rack or inside a slot.
The field Mount Type in the DV_DEVICE_T table describes these placement types. The possible values for this field are:

RACK MOUNT – Indicates this device will typically get placed inside of a rack, but it can be placed outside of the rack.

FLOOR MOUNT – Indicates the default placement for this device is on the Raised Floor Surface, however it can also be placed elsewhere such as relative to a rack.

DEVICE MOUNT – This indicates this device can only be placed inside another device. This device will always go inside a Slot belonging to another device.

Power Connections

VISTA describes power connections as upstream power connections and downstream power connections.
Upstream and downstream indicate the direction of the connections. Downstream connections mean the connection move in the downward direction from the Generator to UPS to PDU all the way down to the power consuming devices. Upstream connections move in the upward direction from the Power Consuming device to power strip all the way to generator.
So any connection moving in the direction of the Generator is Upstream and any connection moving in the direction of the power consuming device is Downstream.

Space Management

Conceptual Model

VISTA supports tracking Buildings, Floors, and Spaces and the spaces inside of a rack. The conceptual relationships in space management are indicated in the diagram below.

Buildings can contain one or more Floors
Floors can contain one or more spaces
Spaces can contain one or more Grid Locations
Spaces can contain devices placed inside of them. These devices can be:
- Racks/Cabinets
- Floor Mounted Devices (Servers, CRACs, Storage, etc)
- PDUs or RPPs

Physical Model

Building Info (DV_BUILDING_INFO_T) describes a building containing a raised floor space. A building can have one or more Floors (DV_FLOOR_T. A Floor can have one or more Spaces (DV_SPACE_T). Typically only raised floor spaces are represented, but Space can also be used for offices and other kinds of spaces.
There is one Floor Grid (DV_FLOOR_GRID_T) object for each raised floor space. Floor Grid Column and Floor Grid Row objects define the column labels and row labels for the grid, and are used to construct the Grid Location object. There is one Grid Location for each tile of the raised floor space.

Racks and Cabinets

Conceptual Model

VISTA support tracking Racks and devices inside of them and it keeps track of available inside the rack. The conceptual relationships are modeled in the diagram below:

Each rack or cabinet has Rack Summary information with it. The Rack Summary information tracks key metrics about the rack such as total weight, largest free RU space, total Watts, etc.
Each rack or cabinet can have one or more Rack Attribute instances. This tracks the Power and Thermal capacity of the rack as well as its weight threshold and the Rack Use.
Each rack or cabinet can have one or more Rack Freespace instances associated with it. This describes the free space inside of the rack. There is Freespace associated to the Front of the rack separate from the Freespace in the Rear of the rack.
Each Rack or cabinet can contain devices installed at a rack unit or relative to the rack (TOP, BOTTOM, LEFT, etc)
Each Rack or cabinet can contain Power Strips installed at a rack unit or relative to the rack (TOP, BOTTOM, LEFT, etc)

Physical Model

The DV_DEVICE_T table is used to track all Racks and Cabinets. The Asset Class for Racks is RACK or CABINET.
The Rack Freespace information is tracked in the DV_RACK_FREESPACE_T table. It tracks the contiguous Rack Units in the Front and Rear of the rack separately. The SIDE field is used to separate out the free space for the Front or the Rear of the rack.
The Rack Summary information is tracked in the DV_RACK_SUMMARY_T table.
The DV_RACK_ATTRIBUTES_T tracks the design power capacity and the thermal rack capacity and the respective operational threshold limits. It also holds the weight threshold and the rack use.

Device

Conceptual Model

There are many different aspects to devices that are tracked in VISTA. VISTA tracks the location of devices, the slots and cards and ports on devices, the applications installed on devices, IP Addresses, MAC Addresses, and their Power. The Power connections and Network connections are also aspects of devices but these are described elsewhere in this document.
The conceptual relationships for are modeled in the diagram below:

A device
- contains one or more slots
- contains one or more ports
- has one or more IP Addresses
- has one or more Applications
- has one or more Power supplies (these only exist when a device has power connections)
- has one model specifications that describes the symbol
A slot
- contains only one card
A card
- contains one or more ports
A port
- has one or more WWN Addresses
- has one or more IP Addresses
- has one or more MAC Addresses

Physical Model

Devices are modeled in the DV_DEVICE_T table. They represent physical objects in the data center, such as a floor-mounted objects (e.g. tape drive or rack), rack-mounted objects (e.g. server), or device-mounted objects (e.g. card or blade server). It is also used to represent a generic load in a rack, such as a fan unit.
The slots are modeled in the DV_SLOT_T table. The slot table tracks status if its occupied or open and what side of the device the slot is located.
The ports on a device or card are modeled in the CNT_PORT_T table. This table contains VISTA ports or any user defined ports.
The power supplies are tracked in the PWR_LOAD_POWER_SUPPLY_T table. Entries in this table exist only when power connections have been made. This table is only relevant for Power Consuming devices. Power Distribution devices for example, would not have any entries in this table because those devices do not have any Power Supplies.
The IP Addresses for Devices or ports are tracked in the CNT_IP_ADDRESS_T table.
The WWN Addresses for Ports are tracked in the CNT_WWN_ADDRESS_T table.
The MAC Addresses for ports are tracked in the CNT_MAC_ADDRESS_T table.
The device model specifications are tracked in the DV_MANUFACTURER_DEVICE_SPECS_T table. The data in this table has a three part key: Manufacturer, Model, Model Info and comes from the VISTA Symbols Library database.
Note: Some of the fields in this table are left over from prior versions, and are no longer used. For example, POWER_KVA, AMPS, VOLTS, and PHASES are no longer used. Instead, fields like WATTS and OP_VOLTS are stored in DV_DEVICE_T, and KVA and Amp values are calculated as needed. So be careful which attributes you choose if you create an SQL view that joins DV_DEVICE_T against DV_MANUFACTURER_DEVICE_SPECS_T.
The DV_APPLICATION_CATALOG_T table contains a list of potential applications that can be associated to devices.
The applications installed on a device can be tracked in the DV_APPLICATION_T table. Typically devices that are servers only track applications (Asset Class ="Server").

Power

Conceptual Model

VISTA tracks all the power distribution devices involved is supplying power to data center power consuming devices and all the connections in between. The Power Distribution devices tracked in VISTA are:

Generators
UPSs
PDUs – plus the panels and breakers
RPPs – plus the panels and breakers.
ATS and Power Strips – plus the receptacles

Generators can be connected to one or more UPS devices.
UPSs can be connected to one or more PDUs
PDUs contain one or more panels
PDU Panels contain one or more breakers
PDUs can be connected to one or more RPPs
PDUs can be connected to a maximum of two UPSs
RPPs contain one or more panels
RPP Panels contain one or more breakers

Conceptual Model – RPP Connectivity

PDUs can be connected to one or more RPPs
Other RPPs can be connected to one or more RPPs
Breakers in PDUs can be connected to one or more RPPs
Breakers in RPPs can be connected to one or more RPPs.

Conceptual Model – RPP Panel Connectivity

PDUs can be connected to one or more RPP panels. This is known as a PDU Direct connection
RPPs can be connected to one or more RPP panels. This is known as a RPP Direct connection
Breakers on PDUs can be connected to one or more RPP panels. This is known as a PDU Breaker connection
Breakers on RPPs can be connected to one or more RPP Panels. This is known as a RPP Breaker connection.

Note: When Panels in an RPP are connected "Directly", the load is placed on the PDU/RPP the panel is connected to. No load is placed on the containing RPP.

Conceptual Model – Power Connections to Devices and Power Strips/ATSs

PDUs/RPPs can be connected to one or more Power Supplies in devices. This is known as an unaudited connection.
Breakers can be connected to one or more Power Strips/ ATSs.
Breakers can be connected to one or more Power Supplies in devices
Power Strips/ATSs can be directly connected to Power Supplies in devices
Power Strips contain receptacles
Each Receptacle on a Power Strip/ATS can be connected to only one Power Supply in a device.

Conceptual Model – Power Strip/ATS connections to other Power Strips/ATS

Power Strips/ATSs contain receptacles
Power Strips or ATSs can be connected upstream to other Power Strip or ATS receptacles.

Physical Model

Power objects consist of the following:

Generator (PWR_GENERATOR_T),
UPS (PWR_UPS_T),
PDU (PWR_PDU_T),
RPP (PWR_RPP_T),
Panel (PWR_PANEL_T),
Breaker (PWR_BREAKER_T),
Power Strip (PWR_POWER_STRIP).
Automatic Transfer Switch (ATS, PWR_ATS_T),
Receptacle (PWR_RECEPTACLE_T), and
Power Supply (PWR_LOAD_POWER_SUPPLY_T).

Of these, Generator, UPS, PDU, RPP, Power Strip, and ATS are also considered Devices, and therefore have a corresponding record in the DV_DEVICE_T table. Power Supplies are not explicitly created by the user; they are created as connections are made to the device.
A Connection (PWR_CONNECTION_T) is made between Nodes (PWR_NODE_T) of power objects. One Node per phase is created when the object is created. For example, when you create a 3-phase UPS and a 3-phase PDU, three Nodes are created for each object. When you connect the PDU to the UPS, three connections are made between the PDU and UPS; one for each phase using each of the three Nodes.
When a Power Supply is connected to a power object, or two upstream power objects are connected, a Node List (PWR_NODE_LIST_T) is created for each Node of each power object to identify every Power Supply that can accumulate load at this Node. Node List is a system-computed object that exists for performance reasons, so that it is not necessary to traverse Connections whenever connection paths must be evaluated.
Likewise, a Flattened Connection (PWR_FLATTENED_CONNECTION_T) is also a system-computed object for performance reasons. Since Power Strips and ATSs can be connected to other Power Strips and ATSs before eventually being connected to a Breaker, a Flattened Connection object connects a Power Strip or ATS to the first upstream Breaker, eliminating the intermediate Power Strips or ATSs.
In general, this data model is very flexible, allowing any object to be connected to any object. However, business rules in the user interface create the following connection restrictions:

A UPS can be connected to one Generator,
A PDU can be connected to either one or two UPS's, depending on whether it is defined as single-feed or dual-feel,
An RPP can be connected to a PDU or to another RPP, either directly or to a Breaker on a Panel of the PDU or RPP. If the RPP has a panel connection type of Direct, each panel of the RPP is connected rather than the RPP itself.
A Power Strip can be connected to one Breaker
An ATS can be connected to two Breakers
When connecting a Power Strip or ATS to a Breaker, the number of poles of the Breaker must match the number of legs of the Power Strip.

Connectivity

Conceptual Model

VISTA tracks network and storage connections between devices. The connections can be made at the port level or device to port. The conceptual diagram below shows how this is modeled:

A device
- Can contain one or more ports
- Can be connected directly to a port (Note a device cannot be connected directly to another device only via a port on the target device.)
A port
- Can be connected to another port

Physical Model

A Device (DV_DEVICE_T) can have multiple onboard Ports (CNT_PORT_T). A Device can also have multiple Slots (DV_SLOT_T). A Slot can contain a card, which is also a Device, and can therefore also have Ports.
To make a Connection (CNT_CONNECTION_T) between two Devices, a Node (CNT_NODE_T) is first created for each Device. The Node may or may not be associated with a Port. The Connection is made between the two Nodes. A Node can only have one connection to it, except for Nodes on a patch panel Device.
A Connection between two Nodes creates a Path (CNT_PATH_T). Each hop (i.e. Node) in the Path is a Path Detail (CNT_PATH_DETAIL_T). A Path can contain more than two hops (and therefore more than two Path Details) if patch panels are used as intermediate Nodes, since patch panel Nodes can have two connections. The Path Detail has a Hop Ordinal field to order the Nodes in the Path. When a Connection is made between two existing Paths, the Paths are merged into one. Both Paths and Path Details are system-computed objects. They exist for performance reasons, so that hops do not need to be traced from start to end each time Connection data is retrieved.

Browser not supported