Database Design – ERD for Yearly Budget Ceiling Advice

There are a few issues with your ERD.

A. Your ERD does not account for these business requirements:

Certain customers might wish some different information displayed on their emails, so my database design need to account for this. E.g. Customer John Smith might want his emails to also list the 'Item Color', where as Emma Watson is not too fussed about that detail, and does not want that listed in the emails.

If customers have not explicitly mentioned that they want customized emails sent, then a Standard Template email is sent.

You need to add a location to maintain your customer email preferences. The model for that depends on what the rules are for recording the preferences. Your question isn't explicit enough on this point.

B. You might also want to include an EMAIL_TEMPLATE table with a foreign key from EMAIL to this new table. That will allow you to record which template was used for each email.

C. You aren't clear about what your m:n relationship is recording. Are these columns: EMAIL.TO, EMAIL.CC, EMAIL.BCC foreign keys? If so, are they single or multivalued? (i.e. can you have multiple email addresses in any or all of these fields?) If they are single valued foreign keys, then you can do away with the many-to-many and make them each a many-to-one from EMAIL to CUSTOMER (so you will have three 1:m relationships) If they are multi-valued foreign keys, then you need to create an explicit intersection table instead of using a simple m:n relationship and you will want to have an ADDRESSEE_TYPE column ("TO", "CC", "BCC") as part of the composite key.

EDIT: Entity Relationship Diagram

This would be a logical data model that could support your business rules:

The TEMPLATE_FIELD_TYPE table is optional. You could use it if you have a standard list of fields that can be added to a template. If you don't want to lock down this list or reuse fields then you can skip this table and just use TEMPLATE_FIELD by itself.

To answer your questions:

1. Year number is part of a (three column) composite primary key. There will be one record per employee + year + type of leave (vacation/sick/...) Year number probably means the calendar year stored as an integer.

2. der_leave_cumulative_days_taken means the total of leave actually taken, which would be derived by summing the days between Employee_Leave_Taken.leave_from_date and Employee_Leave_Taken.leave_to_date where those dates fall within the year given by Employee_Annual_Leave.year_number for the same employee_id and leave_type_code.

3. der_leave_days_remaining is next to pointless because it would be Employee_Annual_Leave.leave_days_allowed less der_leave_cumulative_days_taken. A real scenario would be that an employee is allowed three weeks vacation (15 days) and has taken two weeks so far (der_leave_cumulative_days_taken=10 days) and so they have 5 days remaining. The point of keeping these precalculated in this way is that you can refer easily to these values in a query or report. Notice the date_updated field. This implies that there is a regular (perhaps scheduled) batch job that calculates these derived values periodically, or perhaps they are recalculated when changes are made to either leave allowed or leave taken.