The application generates a lot of information about images acquired or processed by it. Depending on the operations done, the amount of data generated could be vast. In order for such a quantity of data to be valuable, or even useful, it is necessary to both persist their values and search these persisted values to identify items of significance or interest. provides this data archiving and mining functionality through its database modules.

From a technical standpoint, databases are object oriented and accessed via a number of Component Object Model (COM) objects. Traditional databases are relational in nature. That is, the data stored within them are stored in a fixed-layout set of tables, each much like a spreadsheet. These tables can then be joined together to represent an actual data instance or object. However, the relational approach has several drawbacks, including: a rigid schema (i.e. object "shape" or description, mandating that stored objects be homogeneous in format), the fragmentation of data among database tables, and the performance overhead of transforming database table rows into/from the actual objects they represent. To circumvent these limitations, uses object-oriented databases. That is, the data stored within each database is a set of the objects themselves. This approach both circumvents the problems associated with relational databases and provides a more familiar (and parallel) model for dealing with database objects through the Application Programming Interface (API).

The API provides two sets of COM objects to manipulate databases: the Data Management Objects and the Database Engine Objects. Each of these groups of objects serves a distinct purpose and is described in detail later.

Whenever an image is opened into IQbase, whether acquired from a camera, opened from a file, or retrieved from a database, automatically records certain information about the image (e.g. its name and size) and stores it into a session database called the Journal. Also, whenever creates an image object, it is immediately populated with objects describing the appearance of image data. All of this functionality happens automatically, and is generally not even thought about, because manipulates image databases. The Data Management Objects provide the interface for interacting with image databases, and is the set of objects to use in order to retain all of the "behind the scenes" functionality associated with manipulating images through the user interface.

However, at its lowest level, databases are generic, object-oriented databases. In order to manipulate databases at this base level, exposes the Database Engine Objects. However, using these objects places a substantial additional burden on the programmer. As mentioned previously, the Data Management Objects provide and use a framework for storing images within databases. When the Database Engine Objects are used, none of this framework is created or used. Therefore, performing an operation that could be done in one line with a Data Management Object might take many lines (or even multiple functions) when Database Engine Objects are used. However, on the flip side, anything that is done by a Data Management Object can also be done with Database Engine Objects. Further, there are many advanced database features for which no Data Management Object exists, so a Database Engine Object must be used (e.g. Database security). Lastly, when it actually comes to manipulating data, the Data Management Objects provide a Database Engine Object to manipulate. Therefore, to completely understand and utilize database API functionality, it is important to understand at least portions of both sets of Objects.

The Database Engine Objects (summarized previously) are encapsulated in the Media Cybernetics Database Library (McDBLib) as a collection of Component Object Model (COM) objects. These objects can be thought of as a hierarchical set of objects for manipulating and representing both database objects and the databases themselves. At the root of the McDBLib object hierarchy is the Databases collection object, which links into the Application Object Model (AOM) as the Databases operator of a McApplicaton object. That is, the Application.Databases object describes the databases available for manipulation by IQbase. Other COM objects obtainable from the Databases object encapsulate the actual data.

To facilitate ease of use, McDBLib database objects are arranged in the familiar form of file/operating system objects: a tree of objects (files and folders). That is, each McDBLib database has a "root" object, having zero or more "child" objects. Each child object, in turn, can have zero or more children. Therefore the database objects (McDBNode instances) in a McDBLib database can be represented in a classic and familiar (directory) tree manner/diagram, with each McDBNode representing a distinct, discrete point in the tree, either a leaf or a container (a file or a folder). Like file system objects, each McDBNode object has a dynamic and distinct set of properties and attributes encapsulating its associated data/contents. However, unlike file system objects, database objects are potentially heterogeneous. That is, there is no guarantee that an attribute present on one McDBNode instance will be present on another. Further, a set of McDBNode objects may be searched for set members matching (or failing to match) any criteria or combination of criteria by which a McDBNode can be identified/classified (i.e. any property or attribute value). Also unlike file system objects, database objects can be found (queried) based on their properties and/or attributes efficiently. The following chart depicts the organization and association of the objects in the McDBLib COM object hierarchy:

As the hierarchy chart shows, McDBLib objects can be divided into instance objects contained within a collection object grouping them together. As mentioned earlier, McDBNode instances (database objects) are arranged like file system objects (as files within folders). To illustrate, a data image (a McDBNode) exists within a McDBNodes collection (i.e. the children of its parent node), which is, in turn, contained within a McDBNode instance (i.e. the parent node). This relationship continues recursively until there is no longer a parent node for the "current" McDBNode, thereby making the "current" McDBNode the database RootNode. The RootNode is contained within a McDBDatabase object, representing one of potentially many databases available to IQbase. Therefore the McDBDatabase object is one (of perhaps many) objects of its kind in the McDBDatabases collection/object. The McDBDatabases object is the link between the Application and the Database Engine COM objects described earlier, which brings everything together.

The previously described COM objects are capable of representing the databases available to and the hierarchical positioning of the objects within them. However, the heterogeneous and dynamic nature of database objects implies the necessity of additional Database Engine-level COM objects to describe the shape and contents of particular McDBNode instances. Therefore, each McDBNode instance is additionally associated with additional Database Engine COM objects, each encapsulating an aspect of the McDBNode to which it is attached. These additional COM objects are the McDBAttributes, McDBCategories, McDBType, and McDBRights objects. Each of these objects is described individually in the following paragraphs and the succeeding section on database security.

The McDBAttributes collection object encapsulates the attributes associated with a particular McDBNode. For example, if a McDBNode represents an Image, some of the attributes contained in its associated McDBAttributes collection might be the image’s width, height, creation date, size, and description. Since attributes are represented by a variety of types, both numeric and textual, the elements of the McDBAttributes collection are Variants (variables capable of containing any data type). This method of representing attributes simplifies the COM object hierarchy, because there is no McDBAttribute (instance) object, only the collection object. However, accessing the McDBAttributes object should be done with care, so that the desired information is obtained. See the later section describing the McDBAttributes object in detail for complete information.

The McDBCategories collection object encapsulates one or more grouping categories associated with a particular McDBNode. These grouping categories a user-definable strings describing the group. For example, if the McDBNodes in a database representing images that need processing before they can be analyzed, there may be the categories: Needs Processing, Processed, and Analyzed. Like the McDBAttributes object described in the preceding paragraph, the McDBCategories collection object does not have an associated McDBCategory instance object, thereby keeping the COM object hierarchy simpler. However, because McDBCategories are always strings, this simplification does not introduce any confusion. Each McDBNode has a McDBCategories collection associated with it containing zero or more strings, depending on how many database categories describe the McDBNode. This last distinction is important, because categories are database-centric. In other words, each McDBDatabase also has its own associated McDBCategories collection object, which contains all of the categories that may be associated with any node in it. Therefore, before a category may be added to a McDBNode’s McDBCategories collection, it must first exist in the McDBNode’s McDBDatabase’s McDBCategories collection. See the later section describing the McDBCategories object in detail for complete information.

The McDBType object encapsulates classification information about its associated McDBNode. That is, the McDBType object describes items commonly associated with all McDBNode instances that are associated with it. For example, some of the images in a database may be experiments, each of which is typically associated with a common set of attributes, a common icon, etcetera. A McDBType object can be created to represent the Experiment type (of image), which can define a set of suggested (expected) attributes, an associated icon, and categories to be automatically associated with newly created McDBNode instances of that McDBType. Like the McDBCategories objects, the McDBType objects are database-centric. Each McDBDatabase has an associated McDBTypes collection object containing all of the McDBType objects that may be used to describe the McDBNode instances within it. See the following sections on the McDBType and McDBTypes objects for complete information.

The McDBRights  object encapsulates the access permissions of its associated McDBNode. Therefore, this object is only relevant in secure databases and does not even exist in insecure databases. Database security is one of the more advanced features provided by the Database Engine objects, and is covered in more detail in the next section.