Designed for your comfort by Vincent HOUDY

Here is some information about FireBase Realtime Database that you need to know.

First, what is a Database?

At its simplest expression, a database is a gathering of information, here called data, stored on a server. The data is organized in a way it can easily be retrieved, managed and edited in significant ways by the end-user. The data could be something very simple such as personal information about clients or customers. It could also be inventory, sales, calls or anything anyone needs to track. It’s up to the user to determine what data needs to be aggregated and the format it will take.
When you’re using a database, the data is not stored on your computer’s hard drive but in the cloud on a server, somewhere. Using a database management system (DBMS), calls/queries are made to retrieve the information. This part is called the back-end. To present the data in a consequential way to the user, web developers create a web site and easy to use database applications. This part is called the front-end.
Even if there are many other database models such as hierarchical and network models, the relational database model is the most common. The relational database model was developed in the early 1970’s and it is still the most common model to this day. The data is stored in relations, taking the form of tables made of columns (fields) and rows (records/items). To access and interact with the data contained in a relational database, its user needs to use a relational database management system (RDBMS). The most common language used to query and manage relational databases is SQL (Structured Query Language).
Source: 4 examples of database application
Let's see through an example what is - in a concrete way - a database:
The University Database example:
A common example in most database books is a university database. This is used because students understand the business rules a university uses (a student may not be enrolled more than once simultaneously in the same section, a course may have many sections, ...).
Relational Schema
Tables



TablePurpose
Student Describes each student. Not all students may be currently enrolled.
EnrollmentBridge table for M:N Student-Section enrollments for the current term. Grade recorded here.
Section The particular instance of a course being offered at a specific time, place, etc.
Course The abstract course. Each crs_code is like IFSM410. Corresponds to catalog entry.
Location The loc_code has values like RAMST. Country codes are 2 char internet suffixes (eg, 'de').
InstructorEach instructor. Not all instructors may currently be teaching a Section. Each instructor reports to one department.
Qualified Bridge table specifying which courses an instructor is qualified to teach.
DepartmentAn administrative unit of the University.
PrerequisiteDefines which courses are prerequisites to other courses.
SQL to create the tables
The following SQL can be used to define the tables. The order of some table definitions may be important so that the REFERENCES constraint only references previously defined tables. Comments that start with "--position" may be ignored as these are produced by the schema drawing program. 
  1 
  2 
  3 
  4 
  5 
  6 
  7 
  8 
  9 
 10 
 11 
 12 
 13 
 14 
 15 
 16 
 17 
 18 
 19 
 20 
 21 
 22 
 23 
 24 
 25 
 26 
 27 
 28 
 29 
 30 
 31 
 32 
 33 
 34 
 35 
 36 
 37 
 38 
 39 
 40 
 41 
 42 
 43 
 44 
 45 
 46 
 47 
 48 
 49 
 50 
 51 
 52 
 53 
 54 
 55 
 56 
 57 
 58 
 59 
 60 
 61 

CREATE TABLE Student ( --position 15 87,
    stu_id    char(9)   PRIMARY KEY,
    stu_fname char(20)  NOT NULL,
    stu_lname char(20)  NOT NULL
);

CREATE TABLE Department ( --position 281 371,
    dep_code char(4)  PRIMARY KEY,
    dep_name char(40) NOT NULL UNIQUE
);

CREATE TABLE Instructor ( --position 108 267,
    ins_id    char(9)  PRIMARY KEY,
    ins_fname char(20) NOT NULL,
    ins_lname char(20) NOT NULL,
    dep_code  char(4)  NOT NULL REFERENCES Department(dep_code)
);

CREATE TABLE Location ( --position 128 153,
    loc_code    char(5)  PRIMARY KEY,
    loc_name    char(40) NOT NULL,
    loc_country char(2)  NOT NULL
);

CREATE TABLE Course ( --position 498 159,
    crs_code        char(10)     PRIMARY KEY,
    crs_title       varchar(100) NOT NULL,
    crs_credits     tinyint      NOT NULL,
    dep_code        char(4)      NOT NULL REFERENCES Department(dep_code),
    crs_description varchar(255) NOT NULL
);

CREATE TABLE Section ( --position 294 110,
    sec_id   int      PRIMARY KEY,
    sec_term char(8)  NOT NULL,
    sec_bldg char(6),
    sec_room char(4),
    sec_time char(10),
    crs_code char(10) NOT NULL REFERENCES Course(crs_code),
    loc_code char(5)  NOT NULL REFERENCES Location(loc_code),
    ins_id   char(9)  REFERENCES Instructor(ins_id)
);

CREATE TABLE Enrollment ( --position 151 36,
    stu_id     char(9)  REFERENCES Student(stu_id),
    sec_id     int      REFERENCES Section(sec_id),
    grade_code char(2),
    PRIMARY KEY (stu_id, sec_id)
);

CREATE TABLE Prerequisite ( --position 283 21,
    crs_code     char(10) REFERENCES Course(crs_code),
    crs_requires char(10) REFERENCES Course(crs_code),
    PRIMARY KEY (crs_code, crs_requires)
);

CREATE TABLE Qualified ( --position 283 303,
    ins_id   char(9)  REFERENCES Instructor(ins_id),
    crs_code char(10) REFERENCES Course(crs_code),
    PRIMARY KEY (ins_id, crs_code)
);
Source: Example University

Now, let's focus on FireBase Realtime Database

Here is a cool video to watch for a better understanding:
The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client. When you build cross-platform apps with our iOS, Android, and JavaScript SDKs, all of your clients share one Realtime Database instance and automatically receive updates with the newest data.
Source: Firebase

Key capabilities

Realtime Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds. Provide collaborative and immersive experiences without thinking about networking code.
Offline Firebase apps remain responsive even when offline because the Firebase Realtime Database SDK persists your data to disk. Once connectivity is reestablished, the client device receives any changes it missed, synchronizing it with the current server state.
Accessible from Client Devices The Firebase Realtime Database can be accessed directly from a mobile device or web browser; there’s no need for an application server. Security and data validation are available through the Firebase Realtime Database Security Rules, expression-based rules that are executed when data is read or written.
Scale across multiple databases With Firebase Realtime Database on the Blaze pricing plan, you can support your app's data needs at scale by splitting your data across multiple database instances in the same Firebase project. Streamline authentication with Firebase Authentication on your project and authenticate users across your database instances. Control access to the data in each database with custom Firebase Realtime Database Rules for each database instance.
Source: Firebase KC

How does it work?

The Firebase Realtime Database lets you build rich, collaborative applications by allowing secure access to the database directly from client-side code. Data is persisted locally, and even while offline, realtime events continue to fire, giving the end user a responsive experience. When the device regains connection, the Realtime Database synchronizes the local data changes with the remote updates that occurred while the client was offline, merging any conflicts automatically.

The Realtime Database provides a flexible, expression-based rules language, called Firebase Realtime Database Security Rules, to define how your data should be structured and when data can be read from or written to. When integrated with Firebase Authentication, developers can define who has access to what data, and how they can access it.

The Realtime Database is a NoSQL database and as such has different optimizations and functionality compared to a relational database. The Realtime Database API is designed to only allow operations that can be executed quickly. This enables you to build a great realtime experience that can serve millions of users without compromising on responsiveness. Because of this, it is important to think about how users need to access your data and then structure it accordingly.
Source: Firebase How Does It Work?

Implementation path

Integrate the Firebase Realtime Database SDKs Quickly include clients via Gradle, CocoaPods, or a script include.
Create Realtime Database References Reference your JSON data, such as "users/user:1234/phone_number" to set data or subscribe to data changes.
Set Data and Listen for Changes Use these references to write data or subscribe to changes.
Enable Offline Persistence Allow data to be written to the device's local disk so it can be available while offline.
Secure your data Use Firebase Realtime Database Security Rules to secure your data.
Source: Firebase Implementation Path

Looking to store other types of data?

Source: Firebase Other Data

Next steps:

Source: Firebase Next steps