I wonder if your difficulty stems from trying to anticipate and handle all kinds of reports in a single conception of the problem, envisioning a monolithic data structure that encompasses all the tabulations. Try an incremental approach instead:

Pick one tabulation to do first, load and manipulate the data to solve that tabulation. Keep it simple, and just think a little about how you'll need to re-use the data in the next tabulation.

Now pick the next tabulation to do. The data is already loaded and manageable, and the plan for this tabulation will dictate how you need to re-shuffle the data. Do that, then move on to the next tabulation.

If you keep the primary data in a somewhat minimalist structure, it will be easier to compartmentalize each distinct tabulation, pass the basic data to each compartment for that flavor of output, and add more tabulations / compartments to the code as you need to.

It's okay for the code to grow incrementally in this fashion. In some (most?) cases, coding the next tabulation will seem easier if you make up additional structures (keeping each one relatively simple) during the initial data read loops. Having three or four distinct HoA and/or HoH to feed four or five tables will get you finished more easily than one or two HoHoA, HoAoHoA or whatever -- especially if you design your simpler data structures the same way you would design a good RDB schema, e.g. one hash keyed by ssn to store "name, major,status", then a HoA keyed by course-id that stores lists of ssn's in each course, and so on.