Database SchemaThe RHQ database schema is defined in two ways, by the EJB3 mappings to the domain module and as an XML format maintained in the dbsetup module. The dbsetup module is a method to create an abstract, multi-database schema that can be maintained in specific databases according to their specific DDL. It also includes a standard way to define schema versions and to support upgrading between versions. This tool and these XML defined data schemas are used to install and setup the database for use by the EJB3 bindings in the domain module. Full List of TablesThere is also a page with the full list of tables. Modifying the SchemaIf you ever need to remove an obsolete table, add a new table or modify a table and its columns, read the How To Change The Schema page. The ModelSince the database schema directly maps the domain module project they are parallel definitions. The RHQ_RESOURCE_TYPE / ResourceType definitions are core to the metadata definitions surrounding the extensible typing system and the RHQ_RESOURCE / Resource definitions are the core to the instantiated inventory model defining real instances of those types. Plugins expose their metadata to construct the types metadata and the plugin auto-discovery code is involved in the creation of the instances of the resources. MetadataThe metadata model revolves around the Resource Types that are declared by each plugin. The type system is a parent-child model where types can be children of types in their own plugins or even reference types defined by other plugins. Types defined as the category "server" and without a parent are automatically assumed to be supported by any platform type. Otherwise type parents are all specified through the XML hierarchy in the plugin or through the plugin extension mechanism as defined in the plugin documentation. Each type includes several types of related metadata, mostly in a format that maps it to one of the other RHQ subsystems.
InventoryThe inventory is a strict hierarchical model for the resources that RHQ manages. These can be brought in by approving the import of auto-discovered resources or by the manual creation of those resources. Some of the additional data you'll see attached here is instance data for the subsystems. This includes defined and fired alerts, installed packages, operation schedules and results and for some of those group links to the same types of data where group aggregate interaction applies.
SecuritySecurity is layered into the inventory model by collection resources into groups and linking those groups to users through a role model that includes applicable permissions.
|


