Database

Logical Data Model

The data model for DFE consists of a few core entities and many supporting entities. Below is the overall diagram of the entire model. We'll have a look at the pieces in the following sections.

App Keys

Many of the logical entities managed by the system communicate with each other. The Dashboard, as an example, needs to validate login requests with the Console. The App Keys provide a set of *keys* for the two entities to communicate in a semi-secure manner. Semi-secure in that the communication is not encrypted, but the Console is able to validate the request is coming from the alleged requestor.

The keys consist of a `client_id` and `client_secret`. Those familiar with OAuth will recognize the similarity. The security implementation is provided through middleware in the Console, and the Ops Client Library on the client-side.

When the system is initially created, the Console and Dashboard each have a set of keys generated for them to use for communication. When new users and instances are created, they too are granted keys enabling communication.

These keys are self-managing and are destroyed automatically when the owning entity is deleted or otherwise removed.

There is no archive of previously generated application security keys for security reasons.

Core Entities

Several tables in the data model act as **core** entities. That is to say, all other models, in one way or another, rely on their existence. Take the *User* table, for instance. Without it, the instances cannot be launched.

The following entities are considered **core** entities of DreamFactory Enterprise:

* Cluster
* Server
* Mount
* Instance
* ServiceUser
* User

Owned Entities

Four (AppKey, Cluster, User, and Instance) of the core entities are considered to be *owned*. This means that they can be the virtual property of a *user* or other core entity, instead of being *system-owned*. This notion is intended for the future use, and expansion of, instance automation services. Currently, unless otherwise specified, the system **owns** all core entities *except* instances. Instances are, by default, owned by the user that requested the deployment.

Associative Entities

The relationship of servers to clusters, and instances to servers are maintained via *associative entities*. These entities consist, usually, of a primary key and time stamps. The primary key, however, is a composite key of the `id` columns of the two entities being associated. The associative entities relating to the core entities are:

* ClusterServerAssign
* InstanceServerAssign

The first, ClusterServerAssign (`cluster_server_asgn_t`), associates servers to clusters. This maintains servers within a cluster's sphere of influence. The second, InstanceServerAssign (`instance_server_asgn_t`), associates instances to servers. This relationship is maintained for performance, metrics, and future load-balancing purposes.

Archive Entities

Clusters, servers, and instances (and their associations) are never truly *deleted*. The system operates in a *soft-delete* mode whereby these core entities are recoverable via simple SQL statements. These archive entities are:

* ClusterArchive
* ClusterServerAssignArchive
* InstanceArchive
* InstanceGuestArchive
* InstanceServerAssignArchive
* ServerArchive

Physical Diagram

ServiceUser is not included as it is currently only used to authorize Console logins.