Developer Tutorial: Student Record System
- Capella Operational
- tutorial
Learn how to create and deploy a student records database on Capella Operational and connect it to your application.
This tutorial teaches you about the key concepts behind Couchbase and how they differ from traditional SQL database systems like MySQL and Oracle NoSQL.
This tutorial is designed for use with a Capella operational cluster. To use a standalone or Docker installation of Couchbase, see the Couchbase Server Developer Tutorial. |
Data Model
The data model for this tutorial consists of 3 record types:
student |
Information about individual students, like name and date of birth. |
course |
Courses the students can take. Includes course name, faculty, and the number of credit points associated with the course. Students can take more than 1 course at a time. |
enrollment |
Information related to courses the students are taking. In a relational database, this is usually a link record that creates a relationship between a student and a course. |
Relational Model
In a relational model database, the data for this example contains a list of students and a list of courses. Each student can enroll in multiple courses.
A student’s enrollment record is stored in a separate table called enrollment
, which links that record to the courses they’re enrolling in.
The enrollment
table highlights a challenge with the relational model.
Each table is based on a fixed schema that only supports a single data object type, which means you cannot store a student in the same table as their enrollment record.
Document Model
If you create the same data using the document model supported by Couchbase databases, each record is stored as a JSON document. The document model:
-
Contains scalar types and complex types, like nested records and arrays
-
Lets you store complex types without decomposing them to a second table
In this tutorial, the document model stores the list of enrollment records with the student records. Each enrollment record contains a reference to the course that it relates to.
With JSON, you can change the structure of the document without having to rebuild schemas. For example, you can add a new field to store students' email addresses without migrating existing data to a new schema.
In a document database, a student’s record and their course records can look similar to this:
{
"student-id": "000001",
"name": "Hilary Smith",
"date-of-birth": "21-12-1980",
"enrollments": [
{
"course-id": "ART-HISTORY-00003",
"date-enrolled": "07-9-2021"
},
{
"course-id": "GRAPHIC-DESIGN-00001",
"date-enrolled": "15-9-2021"
}
]
}
{
"course-id": "ART-HISTORY-00003",
"course-name": "art history",
"faculty": "fine art",
"credit-points" : 100
}
{
"course-id": "GRAPHIC-DESIGN-00001",
"course-name": "graphic design",
"faculty": "media and communication",
"credit-points" : 200
}
Hilary’s enrollment is stored in the same document as her student details, which means child information is stored with its parent. This structure lets you access and retrieve all of Hilary’s details with 1 search and without the need for complex table joins.
You should not store a student with their course record as it can lead to data duplication and make it difficult to maintain your data.
For example, you would need to access every single student record in your cluster to change the credit-points .
|
Next Steps
To complete this tutorial, follow these steps:
Step 1 |
Create an Account and Deploy Your Free Tier Operational Cluster |
Step 2 | |
Step 3 | |
Step 4 | |
Step 5 | |
Step 6 |
For troubleshooting information, see Troubleshooting the Developer Tutorial.