14 Data Model

Oracle Backend for Firebase supports multiple data models for your app data. This chapter explains the collection-document model and how relational data can be mapped into it (if needed). If you are new to Oracle Backend for Firebase, start with the Document-Collection Model. It is the core SDK experience and works well for most app backends.

• Document-Collection Model
  
• Relational-to-Collection Mapping
  
• Standalone Duality Views (Advanced)
  
• Hierarchical Structure and Subcollections
  
• Supported Data Types
  

14.1 Document-Collection Model

The Document-Collection Model stores data as JSON documents grouped into collections. A collection groups documents of the same type, like users or orders. Each document is a single record with fields, and documents can include nested objects or subcollections. You access data by its collection path and document ID.

Key features include:

• Collections contain documents. Each document is a JSON object with key-value fields.

• Documents can contain nested objects and subcollections for hierarchical data.

• You can create, read, update, and delete documents.

• Document-level access control is managed through security rules.

• Real-time change notifications are available.

• Indexing is supported to keep queries fast as data grows.

The following examples show the hierarchy used throughout this section.

The first example stores each user’s recipes (and each recipe’s notes/photos) nested under users/{uuid} for a per-user hierarchy.

users (collection)
└── {uuid} (document)
    ├── displayName
    └── photoURL
    └── recipes (subcollection)
        └── {recipeId} (document)
            ├── title
            ├── ingredients
            ├── steps
            ├── category
            ├── difficulty
            ├── tags
            ├── avgRating
            ├── photoRefs
            ├── createdAt
            └── updatedAt
            ├── notes (subcollection)
            │   └── {noteId} (document)
            │       ├── content
            │       └── createdAt
            └── photos (subcollection)
                └── {photoId} (document)
                    ├── url
                    ├── storageRef
                    └── createdAt

The second example follows same nested structure, but records uuid on recipe/note/photo documents to make ownership explicit and support easier querying:

users (collection)
└── {uuid} (document)
    ├── displayName
    └── photoURL
    └── recipes (subcollection)
        └── {recipeId} (document)
            ├── uuid (owner)
            ├── title
            ├── ingredients
            ├── steps
            ├── category
            ├── difficulty
            ├── tags
            ├── avgRating
            ├── photoRefs
            ├── createdAt
            └── updatedAt
            ├── notes (subcollection)
            │   └── {noteId} (document)
            │       ├── uuid
            │       ├── content
            │       └── createdAt
            └── photos (subcollection)
                └── {photoId} (document)
                    ├── uuid
                    ├── url
                    ├── storageRef
                    └── createdAt

This model is ideal for JSON-style, schema-less storage for applications that require agility in data modeling, such as flexible schemas and hierarchical data access - like user profiles, chat messages, or product catalogs.

14.2 Relational-to-Collection Mapping

Oracle Backend for Firebase is optimized for the collection-document model, but existing Oracle Database users often have data in relational tables. In that case, you can map relational tables into a hierarchical collection structure without copying data.

Key features:

• Relational-to-collection mapping is configured in the Oracle Backend for Firebase Console.

• Mappings are based on primary key and foreign key relationships.

• The mapping creates a strict hierarchy (linear and non-cyclic). Each child has at most one parent.

• Oracle Backend for Firebase represents each relationship as a duality view in the published hierarchy.

Figure 14-1 Relational Data Model

This option is best for apps that already store data in relational tables and need to expose it through the SDK. For new app data, prefer the Document-Collection Model.

14.3 Standalone Duality Views (Advanced)

The duality view is a powerful feature that allows relational tables to be exposed as hierarchical document structures. You can create standalone duality views and use them as collections. Use this advanced option only when you need a custom document shape over relational data. These views are created outside the Oracle Backend for Firebase Console and are not generated by an Oracle Backend for Firebase project.

Requirements

• The duality view must include an OID field at the root level.

• OID must be unique and should be autogenerated if not provided in the document.

• The duality view must support inserts, updates, and deletes.

• The view must be created in the project owner schema.

• A security rule must exist for the view name and each supported operation.

Supported Operations

• Add document

• Update document

• Read collection or document

14.4 Hierarchical Structure and Subcollections

Oracle Backend for Firebase documents can contain subcollections, which are nested collections within a parent document. This structure supports deeply nested data models.

Example 14-1 Hierarchy

Each level can contain documents with their own fields and subcollections, enabling rich data modeling.

users (collection)
  └── Scott (document)
        └── recipes (subcollection)
              └── Cookies (document)
                    └── notes (subcollection)

14.5 Supported Data Types

Oracle Backend for Firebase supports a wide range of data types for document fields:

Data Type	Description
string	Text values
number	Integer or floating-point numbers
boolean	true or false
map	Nested object
array	List of values
timestamp	Server or client time