Relational Data Modeling Example – Part 3

The completed relational data model is shown in the previous part and the corresponding data stored in database are shown in separate tables below.

State Lookup:

[ultimatetables 5 /]

County Lookup:

[ultimatetables 6 /]

City Lookup:

[ultimatetables 7 /]

Employee Lookup:

[ultimatetables 8 /]

Employer Lookup:

[ultimatetables 9 /]

Employee Employer XREF:

[ultimatetables 10 /]

 

Relational Data Modeling Example – Part 2

Upon discussion with business analysts, data modeler can come up with the following conclusions regarding grouping and relationship between the data. These conclusions play a vital role in designing the data model as well as expanding for future scope.

  • Many cities can be in one county. City names will be unique across the country.
  • Many counties can be in one state. County names will be unique across the country.
  • Many states can be in USA. State names will be unique across the country USA.
  • One employee can work with many branches at same time.
  • For some employees, managers may not be there.

In order to implement the above decisions, relational data modeling is done in the following manner.

  • To achieve normalization, relevant attributes of employee, employer lookup, state lookup, county lookup and city lookup tables should be grouped and created.
  • In order to validate the data of employee table, employee table has been connected to state, county, and city lookups. Whenever state, county, city data is entered in employee table, data would be checked against respective lookup tables and correct data is stored. Hence there is no need to carry redundant data of state, county, city lookup in employee table.
  • All tables are identified by primary keys(PK). So data can be uniquely identified from tables.
  • Records can be inserted or updated directly in the respective lookup table. For example if a state name changes, then the change will be updated only in the state lookup, hence this change will not affect other tables like employee.
  • Since one employee can work in many branches at the same time, table EmployeeEmployerXREF has been created and it resolves many to many relationships.
  • Since an employee can be a manager in many occasions, column “manager identifier” has been added and becomes a foreign key to column employee identifier. The “manager identifier” column would contain the same value as of an employee identifier. Sometimes it may contain null values also. For example, Paul Young is the topmost person and doesn’t have any managers.
  • A new column DateTimeStamp has been added to all tables. This column gives the information about the date and time when the row was inserted or updated.

The completed relational data model is shown in Figure below and the corresponding data are shown in separate tables in the next page.

Relational Data Modeling Example Diagram:

Relational Data Modeling Example

 

Next: Relational Data Modeling Example – Part 3 

Relational Data Modeling Example

The sample source data shown in the table below provides the information about employees, their residential state, county, city and their employer names and manager names. It also describes employees working for an “American Bank” that has got many branches in several states. From data modeler point of view, analysis of the source data raises following questions.

  • How to group and organize the data?
  • How to avoid de-normalization since employee’s residential data like state name, county Name, city Name are repeated in most of the records.
  • What sort of relationship is between employer and employee?
  • What sort of relationship is between the employee and state, city, county?

Sample Source Data:

[ultimatetables 4 /]

In the next page, we will discuss how to resolve these problems in order to design a good relational data model.

Next: Relational Data Modeling Example – Part 2