Home/ Questions/Q 6906903
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T08:22:08+00:00

Note: I’ve seen a few related question about similar issues; however, none of them

  • 0

Note: I’ve seen a few related question about similar issues; however, none of them would fully answer my question.

I have exam data for schools. There are around 500 schools, and around 12 subject exams in my dataset (each school has data for each exam). Each exam has 6 attributes (columns). After the initial data is loaded to the database, no modifications are expected. With respect to SELECT queries, I imagine that separate exam data is used as often as queries over a number of exams. However, the database would be used by a website visualizing the data, thus those SELECT queries might have to be run rather often. With that in mind, I can think of three ways of organizing that data, with each way producing (apparently) BCNF tables.

First scema:

school
exam1_attr1
exam1_attr2
...
exam12_attr6

This schema feels wrong, though I do not have strong arguments against it. As I said, my data would not change, thus having exams carved into attribute names is not that much of an issue. However, such a setup would pose some aggregation difficulties over the entire dataset (i.e., resulting queries would possibly be unnecessarily complicated).

Second schema:

school
examID
attr1
attr2
...
attr6

While this schema looks attractive, I find it hard to convince myself that it is a good idea to represent exams as values rather than columns or separate tables. That is, the set of exams is known, finite and final, and each exam has exact same properties – sounds like a primary candidate for a separate table. On the other hand, under such an arrangement, both aggregation and single-exam queries are very clean and straight-forward.

Third schema would be identical for 12 separate exam tables:

school
attr1
attr2
...
attr6

Conceptually, I would feel that this schema represents my data best: each exam is logically separated into its own table. However, any queries requiring aggregate data over all exams would then include 12 tables, and that makes me feel rather uneasy.

Thus, my question: which database design would be best in my case? While I am looking for an answer, I am also very interested in reasons for choosing one schema over the other. Specifically, I wonder:

  • how efficiency of running queries changes with each database design,
  • how important in real life is the ease of writing queries (given that the data would be primarily used by a website – I would seldom write queries over the data after the website has been finished),
  • which design is better if potential future changes to the data of the website are taken into account,
  • whether your answer would be different if the number of schools was not 500, but 50,000.

In short, I am interested in any opinions that would help me understand why one design is better than the other. Any database design theories are welcome as well. Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In an operational relational database, the speed of changes is more important than speed of selects. In a data warehouse, the speed of selects is more important than the speed of changes.

    You have a data warehouse.

    Operational relational databases are normalized.

    Data warehouses use some variation of a star schema.

    Your second schema is a good schema for the reason you stated. Both aggregation and single-exam queries are very clean and straight-forward. However, you should put the school information in a separate school table, and reference the school table ID (primary key field, auto-increment integer) as a foreign key in the exam table. This allows you to scale from 500 to 50,000 schools more easily.

    • 0