For example:
- A campus will have many colleges
- A college will have many students
- A college’s students will have many courses
| Campus | College | Student | Course |
|---|---|---|---|
| UMNTC | CEHD | Example Student | Intro to Basket Weaving |
| UMNTC | CEHD | Example Student | Basket Weaving Lab |
Those first three columns all have redundant data. This example doesn’t seem so bad, but if you multiply that by millions of students going back decades, that information starts to take up a lot of space. Not only that, but updating a single student might mean updating hundreds or thousands of rows. Splitting the data up into related tables like this is called normalization.
We can create a report like the spreadsheet by joining tables on their related IDs. It’s intuitive that the campus_id field in the colleges table maps to the ID field in the campus table. Joining them is fairly straightforward. We handle queries that are much more complicated than this simple example.
There are many other kinds of databases that structure their data differently depending on the use case. However, Oracle is the University-provided solution that holds all our Peoplesoft data. Retrieving that data is easier for us if we stay in that world. Besides, we don’t want to run and manage our own databases.
