What is Objectivity/DB's storage hierarchy? Starting from the highest level in the Objectivity/DB storage hierarchy:
➤ Each database contains one or more containers. ➤ Each container contains one or more persistent objects. ➤ Persistent objects, including instances of application-defined container classes, can be linked together using to-one or to-many relationships (associations). What is a Federated Database? The federated database is the highest level in the Objectivity/DB logical storage hierarchy. Logically, a federated database contains application-created data in one or more databases. Physically, each federated database exists as a file containing a single system database, which stores:
➤ A global catalog of the federation’s application-created databases. ➤ Any federation-wide structures (indexes and scope names) created by applications. The federated database provides unified management of database files and a collection of other Objectivity/DB resources (files and processes):
➤ A system database maintains internal Objectivity/DB information such as the global catalog of databases. ➤ A lock server is a process that manages concurrent access to a federated database's data. ➤ Data servers enable applications to obtain data from distributed databases on local or remote hosts. ➤ A journal directory contains files that maintain information for recovering transactions. What are databases and containers? A database is the second highest level in the Objectivity/DB logical storage hierarchy. Each database stores an application’s persistent data in structures called containers, which constitute the third level in the Objectivity/DB logical storage hierarchy. Within a container, persistent data is stored in fundamental units called basic objects. A database is physically represented by a database file, which contains:
➤ Zero or more containers created by applications. ➤ A catalog of the containers belonging to the database. Database files are typically used to distribute related containers and their basic objects to different physical locations in your network. Most containers are physically embedded in the files of the databases to which they belong. For various reasons, such as keeping the size of database files within manageable limits, an application can choose to store selected containers in their own separate container files. Such containers, called external containers, differ from embedded containers only in terms of their physical representation; a database can logically contain any combination of embedded and external containers. Because all persistent data physically resides in a database file, a system-database file, or a container file, these files are collectively called the data files of a federated database. Each container manages a group of physical storage pages allocated in the database; the container's persistent objects are stored in binary form on these pages. Some or even all of these physical storage pages also serve as logical pages, which means that they store one or more small persistent objects, or the beginning of a large (multi-page) persistent object. What is a persistent object? Persistent objects are the fundamental logical units of data storage in an Objectivity/DB federated database. Persistent objects are created by applications. Each persistent object has an object identifier (OID) and is an instance of a class. The class may be defined in an object-oriented programming language, or it may be a class defined by Objectivity/DB (for example, ooObj). In either case, the class is described in the federated database's schema. A persistent object continues to exist and retain its data beyond the duration of the process that creates it. In contrast, a transient object exists only within the memory of the process that creates it; when that process terminates, the transient object ceases to exist. |
|||
 |
||||||||
|
||||||||
|
|