Welcome to the first lesson of your course on Database Administration and Security. We're kicking things off by building a solid foundation. Before we dive into the practical tasks of installing and configuring different database systems, it's crucial to understand why these different systems exist and what problems they are designed to solve.
This lesson directly addresses the first learning outcome of the course: to describe the high-level structural differences between the three database paradigms we will be studying—relational (Oracle), document (MongoDB), and graph (Neo4j). Understanding their core data models and philosophies will provide essential context for all the practical skills you'll develop in the upcoming modules.
The Database Landscape: A Tale of Two Philosophies
At the highest level, the world of modern databases is often split into two major categories: Relational (SQL) and Non-Relational (NoSQL). You've likely encountered these terms before. Relational databases have been the industry standard for decades, while NoSQL databases emerged to handle the challenges of large-scale, rapidly changing internet applications.
This infographic provides a great visual overview of the landscape. You can see the three categories we will focus on: Relational/SQL, and two popular types of NoSQL databases—Document and Graph.
Let's briefly formalize the distinction between these two philosophies.
Different Types of Databases & When To Use Them
This article from Rivery provides a clear introduction to the fundamental split between relational and NoSQL databases.
Please read the introduction and the first main section. Start from the beginning and read down to the end of the section on the main types of databases. Focus on the initial comparison table and the descriptions of Relational and NoSQL databases. Specifically, read from this introductory part to understand the core attributes that differentiate SQL and NoSQL databases.
As you read, the key takeaway is that the choice between a relational and a NoSQL database isn't about which is "better," but which is better suited for a specific task. Relational databases prioritize structure, consistency, and data integrity. NoSQL databases prioritize flexibility, performance, and scalability, particularly for unstructured or semi-structured data.
Now, let's explore the three specific models we'll be working with in this course.
1. The Relational Model: Order and Structure (Oracle)
The relational model is built on the mathematical concept of a relation, which is practically implemented as a table. Data is organized into tables composed of rows (records) and columns (attributes). Every row in a table is uniquely identified by a primary key. Relationships between tables are created by using a foreign key, which is a column in one table that refers to the primary key in another.
This model enforces a rigid schema, meaning the structure of the table (the columns and their data types) must be defined before you can add data. This ensures predictability and data integrity. Your background in IT likely gives you an appreciation for how such strict rules can prevent data corruption and are essential for systems where accuracy is paramount, such as financial or transactional systems.
This video provides an excellent, concise explanation of the relational model.
Types of Databases: Relational vs. Columnar vs. Document vs. Graph vs. Vector vs. Key-value & more
This video, "Types of Databases," clearly explains the fundamentals of the relational model using a simple example.
Please watch the section on relational databases from the beginning. Pay close attention to the concepts of tables, primary keys, foreign keys, and ACID transactions.
The specific relational database management system (RDBMS) we will use is Oracle Database, a powerful, enterprise-grade system widely used for critical applications.
2. The Document Model: Flexibility and Speed (MongoDB)
The document model is a popular type of NoSQL database. Instead of tables and rows, it stores data in documents. These documents are typically in a format like JSON (JavaScript Object Notation) or BSON (a binary version of JSON), which consists of key-value pairs.
A key principle of the document model is that data accessed together should be stored together. Instead of normalizing data and splitting it across many tables (like a book's details, its author, and its reviews), a document can contain all of this related information within itself, often through nested objects and arrays. This structure closely mirrors the objects used in many programming languages, which can simplify development.
The following video from MongoDB's official channel provides a fantastic comparison of how you would model the same application in a relational database versus a document database.
MongoDB Data Modeling and Schema Fundamentals | From Relational to Document Model
This video, "MongoDB Data Modeling and Schema Fundamentals," effectively contrasts the rigid, normalized structure of relational databases with the flexible, embedded nature of the document model.
Watch the segment from the relational model example. Notice how the bookstore data is spread across four different tables in the relational example. Then, see how the same data is elegantly stored in a single document in the MongoDB example, using embedded documents for reviews.
This approach gives document databases a flexible schema. While a group of documents (called a collection) holds similar types of data, each individual document can have a slightly different structure. This is ideal for managing unstructured or semi-structured data, like user profiles, product catalogs, or articles in a content management system. Our tool of choice for this model will be MongoDB.
3. The Graph Model: The Power of Relationships (Neo4j)
The graph model represents a fundamental shift in perspective. While relational and document databases focus on the entities themselves, graph databases treat the relationships between entities as first-class citizens, just as important as the entities themselves.
The core components of a graph database are:
- Nodes: These represent the entities (e.g., a person, a company, a product).
- Relationships (or Edges): These represent the connections between nodes. They are always directed and have a type (e.g.,
WORKS_AT,FRIENDS_WITH,BOUGHT). - Properties: Both nodes and relationships can have properties, which are key-value pairs that store data (e.g., a person node can have a
nameproperty, aFRIENDS_WITHrelationship can have asinceproperty).
This structure is exceptionally powerful for querying complex, interconnected data. The classic example is a social network. Finding "friends of friends" in a relational database requires multiple complex JOIN operations, which become computationally expensive as the network grows. In a graph database, this is a simple and fast traversal along relationship edges.
This image perfectly illustrates the difference in modeling the same simple "friendship" data.
To solidify this concept, let's turn to a detailed comparison.
Graph Databases Explained: Better Way to Represent Connections
This article from Cognee offers a clear breakdown of how graph databases differ from their relational and document counterparts.
Please read the sections titled Graph vs. Traditional and Graph vs. Relational/Document. Finally, carefully study the comparison table at the end of that section. It serves as an excellent summary of the three models.
The graph database we will install and learn to use is Neo4j, a leader in this space.
Conclusion
In this lesson, we've surveyed the landscape of the three database models that will form the basis of this course. You should now be able to describe their fundamental structural differences.
Here are the key takeaways:
- Relational Databases (Oracle): Organize structured data into tables with rigid schemas. Relationships are defined by primary and foreign keys. Their strength lies in data integrity and consistency, making them ideal for transactional systems. Querying complex relationships can require costly
JOINoperations. - Document Databases (MongoDB): Store semi-structured data in flexible, JSON-like documents within collections. They excel at storing related data together (embedding), which simplifies development and improves read performance for certain workloads. They offer a flexible schema and are built to scale horizontally.
- Graph Databases (Neo4j): Model data as a network of nodes and relationships. The relationships are a core part of the data model, not an afterthought. This makes them incredibly efficient at traversing and querying highly interconnected data, perfect for social networks, fraud detection, and recommendation engines.
In our next lesson, we will move from theory to practice. Now that you understand the "what," we will begin with the "how" by downloading and installing our first database system: the Oracle Database.