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

Get Cisco Unity Deployment and Solutions Guide now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.