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:

State CodeState NameDate TimeStamp
NYNew York1/1/2005 11:23:31 AM
FLFlorida1/1/2005 11:23:31 AM
CACalifornia1/1/2005 11:23:31 AM
NJNew Jersey1/1/2005 11:23:31 AM

County Lookup:

County CodeCounty NameDate TimeStamp
NYSHShelby1/1/2005 11:23:31 AM
FLJEJefferson1/1/2005 11:23:31 AM
CAMOMontgomery1/1/2005 11:23:31 AM
NJHUHudson1/1/2005 11:23:31 AM

City Lookup:

City CodeCity NameDate TimeStamp
NYSHMAManhattan1/1/2005 11:23:31 AM
FLJEPCPanama City1/1/2005 11:23:31 AM
CAMOSHSan Hose1/1/2005 11:23:31 AM
NJHUJCJersey City1/1/2005 11:23:31 AM

Employee Lookup:

Emp IdState CodeCounty CodeCity CodeManager IdEmp First NameEmp Last NameEmp Full NameDate TimeStamp
1NYNYSHNYSHMAPaulYoungPaul Young1/1/2005 11:23:31 AM
2FLFLJEFLJEPC1ChrisDavisChris Davis1/1/2005 11:23:31 AM
3CACAMOCAMOSH1LouisJohnsonLouis Johnson1/1/2005 11:23:31 AM
4NJNJHUNJHUJC1SamMathewSam Mathew1/1/2005 11:23:31 AM
5NYNYSHNYSHMA1NancyRobinsonNancy Robinson1/1/2005 11:23:31 AM
6FLFLJEFLJEPC2Sheela ShellumSheela Shellum1/1/2005 11:23:31 AM
7CACAMOCAMOSH3JeffBillJeff Bill1/1/2005 11:23:31 AM
8NJNJHUNJHUJC4JohnBurrellJohn Burrell1/1/2005 11:23:31 AM

Employer Lookup:

Employer IdEmployer NameDateTimeStamp
1001American Bank of NewYork1/1/2005 11:23:31 AM
1002American Bank of Florida1/1/2005 11:23:31 AM
1003American Bank of California1/1/2005 11:23:31 AM
1004American Bank of New Jersey1/1/2005 11:23:31 AM

Employee Employer XREF:

Employee IdEmployer IdDateTimeStamp
110011/1/2005 11:23:31 AM
210021/1/2005 11:23:31 AM
310031/1/2005 11:23:31 AM
410041/1/2005 11:23:31 AM
510011/1/2005 11:23:31 AM
610021/1/2005 11:23:31 AM
710031/1/2005 11:23:31 AM
810041/1/2005 11:23:31 AM

 

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:

State NameCounty NameCity NameEmp First NameEmp Last NameEmp Full NameManager NameEmployer NameDate TimeStamp
New YorkShelbyManhattanPaulYoungPaul YoungAmerican Bank of New York1/1/2005 11:23:31 AM
FloridaJeffersonPanama CityChrisDavisChris DavisPaul YoungAmerican Bank of Florida1/1/2005 11:23:31 AM
CaliforniaMontgomerySan HoseLouisJohnsonLouis JohnsonPaul YoungAmerican Bank of California1/1/2005 11:23:31 AM
New JerseyHudsonJersey CitySamMathewSam MathewPaul YoungAmerican Bank of New Jersey1/1/2005 11:23:31 AM
New YorkShelbyManhattanNancyRobinsonNancy RobinsonPaul YoungAmerican Bank of New York1/1/2005 11:23:31 AM
FloridaJeffersonPanama CitySheelaShellumSheela ShellumChris DavisAmerican Bank of Florida1/1/2005 11:23:31 AM
CaliforniaMontgomeryShelbyJeffBillJeff BillLouis JohnsonAmerican Bank of California1/1/2005 11:23:31 AM
New JerseyHudsonJersey CityJohnBurrellJohn BurrellSam MathewAmerican Bank of New Jersey1/1/2005 11:23:31 AM

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