EventJoin us at AWS re:Invent 2024! Learn how to use MongoDB for AI use cases. Learn more >>

Database Examples — Real-World Applications

Learn how non-relational databases could work for you.

When deciding on what type of database to use in your project, it can be helpful to see some real-world examples for different types of data. This can help you decide not only what type of database to use, but how the data might be modeled.

In this article, you will see some examples for different types of databases and the kinds of data that might be stored in them.

Relational Database Example

Relational databases, or SQL databases as they are sometimes called (due to the language that is used to query them), use tables, columns, and rows to store data. Columns that are common between tables help form relationships between the data.

Healthcare Database Example

One common use case for relational databases is storing patient healthcare data.

For example, one healthcare provider might have multiple offices where they see patients. This would lead to the creation of an “Office” table, that stores information such as the office's name and address.

An office could have many doctors, meaning there is a one-to-many relationship between offices and doctors. Similarly, there is a one-to-many relationship between offices and patients. Entities with one-to-many relationships are typically stored in separate tables. This would mean separate tables for “Doctor” and “Patient.” These tables would have columns such as their unique ID, address, and other relevant information.

The relationship between the tables would be formed from shared columns. For example, a column in the "Doctor" table would store the officeId value from the “Office” table, to represent their office location. A patient would also be associated with a doctor via their doctorId, as well as an office they attend for appointments with the officeId attribute.

An example relationship diagram showing the tables and columns for a healthcare provider

Non-Relational Database Example

A non-relational or NoSQL database is any kind of data store that doesn’t use the traditional tables, column, and rows (sometimes called records) functionality of a traditional relational/SQL database. This means that there are many types of non-relational databases. In this section, we'll discuss examples for graph databases, hierarchical databases, distributed databases, and document databases.

To learn more, we have an article about NoSQL database examples.

Graph Database Example

A graph database uses nodes to hold data, and edges define relationships between them.

Movie Database

One example of data you can store in a graph database is information about movies and the people who make them. The nodes hold information about things such as a person or film. The edges define the relationships between them, such as a person acting in, directing, or producing a film.

This is helpful when building up queries for film suggestions. If a viewer has watched a film starring an actor, they can be shown recommendations of other films that actor has starred in or films directed by someone.

"A graph diagram showing relationships between actors, directors, and films

Hierarchical Database Example

Hierarchical databases represent data in a tree-like form. Each ‘parent’ node can have many ‘children.’ The node without a parent is considered the root node.

Organizational Chart

An organizational chart is a great example of data that can be modeled easily in a hierarchical database. The root node would be the Chief Executive Officer (CEO) who would have perhaps an ‘EmployeeID’ of 1 and a ‘Level’ value of 0 as they are the root.

The CEO could then have many direct reports, such as Chief Technical Officer (CTO), Chief Finance Officer (CFO), and Chief Operating Officer (COO). They too would have many direct reports. This tree structure would continue until you reached a level of employee with no direct reports.

Sample tree diagram of organizational chart

Distributed Database Example

A distributed database is one where the data is related logically but stored in multiple databases across different geographical sites.

Domain Name Service

The Domain Name System (DNS) uses a distributed database. Internet users everywhere use web addresses, or URLs as they are also known, to access websites and other internet services. However, underneath the hood, these names actually map to unique IP addresses.

Name servers are used to store these mappings and there are multiple across the globe. Different name servers are owned by different companies. However, they are all accessed the same way when searching the internet. A user types the address they want to access and the rest is taken care of. The information is distributed but it is all accessed through one large database management system.

Distributed database diagram showing domain name databases

Document Database Example

A document database stores information, most commonly in JSON-like structures, as documents. It allows for related data to be stored in one place, rather than distributed across tables.

Like relational databases, document databases are able to handle general-purpose use cases which makes them suitable for many types of applications and data.

Healthcare Database Example

A document database is a great database for a healthcare organization and information such as offices, doctors, and patients.

Each patient, for example, has a single document which contains all their information such as name, address, date of birth, doctor, local healthcare office, list of previous or current illnesses, and any medications they are on.

The document model allows related data to be embedded together. By storing information together that is accessed together, data can be retrieved incredibly quickly without any expensive joins — and it is easier to shape the data in a way that suits the application.

Patient Document showing all information stored together

Example document for a doctor showing the office they work at and their patient's names

Example document for an office showing details such as address, doctors, and patients

MongoDB Atlas: The Advantages of Cloud Databases

Non-relational databases, including document databases, have many advantages, like scalability, flexibility, and high availability. MongoDB Atlas provides all the advantages of a document database, available in the cloud, which means that your database is fully managed and highly available, as well as being able to scale in/out to handle demand.

If you would like to try a non-relational database, you can get started with MongoDB Atlas using the free tier today.

Ready to get started?

Summary

In this article, you have learned about different examples of when you might use the different types of databases, and seen diagrams showing how the data might look when used in that database.

To learn more about types of databases and when you might want to use them, you can read this article on relational vs. non-relational databases.

FAQ

What is a database?

A database is any electronic container for storing information. Examples include relational databases that store information in tables and columns, and non-relational, or NoSQL, databases. There are also other types of data storage, and you can learn more in our article databases vs. data warehouses vs. data lakes.

What are some examples of databases?

There are different types of databases but it helps to consider examples of data in everyday life that would be stored in databases.

This includes social media websites such as Twitter, movie services such as Netflix, your patient records for healthcare, and even banking.

How can I create a database?

How you create a database will depend on the type of database that you want to create. MongoDB’s document database is general purpose and suitable for most scenarios. However, before starting a project, you should always consider when to use a NoSQL database.

To take advantage of the cloud and the managed database as a service model, use MongoDB Atlas. There is even a free tier so you can get a feel for the product and how you might model your data.