Cacophoné Studios runs a medium-sized music school. They have a fixed series of courses in mind, and a roster of teachers that can fill in for most of them. They also have a long list of past and potential customers. Last year, a small catastrophe happened when 273 students were crammed into the same class and no teacher was assigned to teach it. (Next door, a class of 14 had somehow ended up with three instructors.) They’re hoping that Access can help them avoid the same embarrassment this time around.
Tip: Want to play along with Cacophoné Studios? Try to pick out possible tables and their relationships before reading ahead.
Identifying the tables
Every business is a little different, and it would take a long, detailed analysis to get the perfect table structure for Cacophoné Studios. However, even without knowing that much, you can pick out some fairly obvious candidates:
-
Teachers. A table to store a list of all the teachers on their roster, complete with contact information.
-
Students. A table to store all class-goers past, present, and potential. You don’t need to distinguish between these different groups of people in the Students tableinstead, you can sort out the current students from the others by looking for related data (namely, their class enrollments). So you can keep things simple in the Students table, and just store name and contact information.
-
Classes. A table to store the classes that Cacophoné Studios is running. This table should include the class name, date it starts, date it ends, maximum enrollment number, and any other key information.
Note: Course requirements are stored using a multi-value lookup field named PreviousClassRequirements. This field contains the ID values of each required class. (In other words, every record in the Classes table has the nifty ability to point to other classes in the same table.)
Cacophoné Studios will certainly want many more tables before long. But these tables are enough to get started.
Popularity: 2% [?]
Recent Comments