ADB is built on the Open Source massively parallel Greenplum DBMS that in turn is based on the PostgreSQL object-relational database. That is why most of the data model concepts that make up the core of PostgreSQL can be also applied to ADB.
The main data model components used in ADB are listed below:
Database. This is a collection of data physically stored together. Every ADB cluster can contain one or more named databases. This is different from some other database management systems (e.g. Oracle) where the DBMS instance equals to the database. However, client programs can connect to and access only one ADB database at a time — cross-queries between different databases are impossible since databases are rigidly separated. Data transfer between several databases is also impossible by the DBMS functionality.
Schema. This is a logical union of entities within a single database. Unlike databases, schemas are not physically separated: users can access multiple schemas at a time (if they have the necessary privileges).
Object. This is any other entity that is defined within the database schema. For example, table, function, view or materialized view, etc. To access objects, you can use the ASCII standard:
database.schema.object. But the
schema.objectform is preferable (as you can access only the database defined in the current connection anyway). Notice, that the same object name can be used in different schemas without conflict.
The picture below illustrates the hierarchy of the ADB data model components on the basis of a simple example. It includes the
books_store_archive databases with two custom schemas
books inside each of them. Every schema in turn contains some tables and views. In this case users can access both schemas at a time while working with any of two databases specified in the connection request. But users can not cross-query between databases.