Homework Assignment (Individual part)

1. Wrap up everything in a document explaining your working process.

For example: What decision did you have to take? What elements of the business model influenced
mostly your design? What information was missing?

Deliverable: a short written report in .pdf

The deliverable of our group assignment is quite different from where we started from. At the outset,
we had formed a rough definition of the use case and we brainstormed on the scenario from clients
angle. Then we jotted down all the fields that came to our mind. After cutting out some fields we
assigned them to groups (tables) and identified PK, FK and linkages. All these steps involved some
decision-making which had its trade-offs as well as some assumptions. The elements of business model
that influenced our design during this journey have been included under Decisions and Assumptions
respectively.

Decisions:

1. We scanned and eliminated any redundant information/calculated fields (e.g. Size of the class,
Total Credits for the program), as well as that which was not critical to the case (e.g. Emergency
contact). In one instance have semester and year in two different tables: Course_Schedule and
Acad_Schedule. This is because they cater to two different contexts: the first gives us the time
period in which a course was taken up by a particular student whereas the second tells us the
time period in which an Instructor taught a particular course. It was confusing to have these
twice and we had almost mistaken these for redundancy.
We learnt that these decisions can be quite subjective since something which not critical for us
could be critical for someone else. In a real-world scenario, its important to align with the client
on what is critical, and verify the redundant or not-significant fields before removing them.

2. As we proceeded to the next stage of grouping information into separate entities/tables, we

realised that there could be overlaps and in some instances an element in one table could have
multi-level information attached to it. (e.g. Having Instructor information included within
Courses whereas an Instructor might be teaching multiple courses and in different semesters).
Here we had the choice of enhancing the dimensions of this table to incorporate the macro
information, or create another table for this info and then link it back to the main table. The first
one was easier to visualise, so more tempting than creating a linking table. The offside to this
was that creating and updating this table would be more cumbersome, and additionally it had
more dependencies than were required in the actual design. So, we decided to maintain the
two separately.

3. The next challenge was identifying the primary key in a table. There were more than one
candidates stepping up for each role, we had to find the best fit (though we liked all of them).
For example: (1) For the transaction history of a student, we thought of having Student
(Student_ID) as the PK and we could roll-up the information to that, but then we introduced
Transaction ID (Trnsc_ID) since a Student would make repeat transactions across different time
periods. (2) We decided to move fields like grades and attendance to the academic schedule
table instead of a Student_Info or a Courses table, since Student_ID and Course_ID had a many-
on-many relationship to themselves on which these fields depended.
 The logic for assigning PK is straightforward: the objective is to have a unique identifier in each
row. But understanding the purpose and structure of the table is critical to point out that unique
identifier/ combination of identifiers.

4. Assigning datatypes to the fields was a debatable topic in some cases, while being
straightforward in some others. We had assigned all IDs except Trnsc_Status as string since they
arent meant to be multiplied/added or modified mathematically. Trnsc_Status just had 3 types
of statuses which were integer in nature. Fields that involved date and amount were more
obvious (date and double).

Missing Information/ Assumptions:

We had taken many assumptions on the way including assuming that:

(1) our listed fields were sufficient for the database creation, and
(2) the granularity at which we were defining the data was the deepest level.
(3) Our assigned datatypes would suffice the purpose
(4) the dimensions of the structure defined by us would complete it, and not be affected by any
future enhancement (e.g. adding emergency contact to Student table or an Instructor bio to
Instructor table would not affect the PKs, FKs and linkages in the database).
(5) data in linked fields would have consistent format and not create any issues in linkages (needs
to be validated in a real-world scenario)

With these assumptions, we made up for our missing information.