Cisco Unity Deployment and Solutions Guide

Data Storage 105

Data Storage

With a basic understanding of how the objects in the Unity system relate to one another, the

next obvious question to ask is where is all the configuration information actually stored on

the system? Configuration data is located in four different areas for Unity. We cover the

important items in each area:

• SQL database

• Windows Registry

• Directory (Exchange 5.5, AD, or Domino)

• Local files on the hard drive

SQL

The majority of the Unity-related information is stored in the SQL database, which runs

locally on each Unity server. When conversations in the telephone interface or the SA/PCA

pull up information about users, call handlers, interviewers, and so on, they generally pull

this from the SQL database. As of the Unity 4.0 release, most of the clients that get at this

data still go through the abstracted Data Object Hierarchy (DOH) interface that has been

around since Unity 1.0 instead of going directly to SQL. The DOH interface was necessary

when the data was strung out in the Exchange 5.5 directory, and getting at it required

complex and error-prone LDAP queries. Now that Unity has transitioned to SQL as the

primary back end, this abstracted (and slow and somewhat cumbersome) interface is no

longer necessary.

Moving forward with releases after Unity 4.0, the DOH interface will be retired and even-

tually no longer supported. Other interfaces into the Unity database, such as the Simple

Object Access Protocol (SOAP), might come online. Currently, however, the only viable

alternative to the DOH is to go directly to the SQL database itself. The Customer Applica-

tions Team (CAT) within the ECSBU is using SQL exclusively to generate all new tools and

utilities that ship with Unity; see http://www.ciscounitytools.com. The details of doing

basic administrative functions using SQL directly are covered later in Chapter 21. For now,

we just cover the high-level functions of each of the tables in SQL.

Make sure you have read the data object model covered earlier in this chapter to get the

most out of this section. It also is a good idea to have the Cisco Unity Data Link Explorer

(CUDLE—see Figure 3-4) application in front of you: Many of the details of what specific

columns are used for and what valid data can be contained in them is held in its data dictio-

nary tables. When exploring the data object model, you will want to use DOHPropTest;

when exploring the database itself, CUDLE is a handy tool.

106 Chapter 3: Components and Subsystems: Object Model

Figure 3-4 The Main CUDLE User Interface

Apart from having basic data dictionary and advanced database-navigation features built in,

CUDLE includes information about Unity Registry settings, lets you switch dynamically

between views and tables, includes a fully featured query builder, and enables you to

explore stored procedure parameters and source code, among other features. You will find

the latest version of CUDLE along with a couple of training videos on how to use it at

www.ciscounitytools.com.

A quick word about tables versus views is necessary. A view can be thought of as either a

virtual table or a stored query. What is stored in the view is not the actual data, but rather

a SELECT statement that is used to pull data from the raw tables. The result set of the

SELECT statement forms the virtual table returned by the view. Using views provides a

number of benefits, such as allowing data from multiple tables to be presented in one spot

without requiring complex inner join statements and the like. Views also can be used to

restrict access to specific data that you might not want external developers to get at (not

a big concern for us here). One of the big benefits that views provide is a mechanism that

allows the back-end database tables themselves to be updated, while still providing a con-

sistent interface that is backward compatible across versions. This way, clients that have

written applications that use these views do not have to change their code to remain current

for each version of Unity that is released.

In Unity 4.0, each of the tables has a corresponding view. However, initially many of them

are simply a straight mapping of columns from their corresponding table. As Unity moves

forward, the database is reorganized to make it more efficient and faster. As data moves

between tables, or as tables are collapsed into each other and the like, any client writing

directly to the tables themselves has to update its applications each time a new release of