J
John Saunders
I'm trying to improve the reverse-engineered model of a legacy database.
This means that I have to maintain some duplicate columns. I need help
modeling this:
SalesRegion(srId) is named SalesRegionName
Each SalesRegion is named some SalesRegionName.
Each SalesRegion is named at most one SalesRegionName.
Each SalesRegionName is the name of at most one SalesRegion.
Employee(empId) is in SalesRegion(srId)
Each Employee is in some SalesRegion.
Each Employee is in at most one SalesRegion.
Now, unfortunately, the Employees table also contains a SalesRegionName
column. That's what I don't quite know how to model. I tried creating a
derived and stored fact:
Employee is in the SalesRegion named SalesRegionName
Each Employee is in the some SalesRegion named some SalesRegionName.
Derived (and stored) by rule: Employee is in SalesRegion and that
SalesRegion is named SalesRegionName.
The problem is that this derived fact has no uniqueness constraints. If I'm
understanding correctly, these constraints should be computed from the
conceptual join of the Employee and SalesRegion objects, so that there are
three uniqueness constraints: over Employee, over SalesRegion and over
SalesRegionName. But this won't validate!
Is there a way to model this which will leave me with the same logical
database structure?
This means that I have to maintain some duplicate columns. I need help
modeling this:
SalesRegion(srId) is named SalesRegionName
Each SalesRegion is named some SalesRegionName.
Each SalesRegion is named at most one SalesRegionName.
Each SalesRegionName is the name of at most one SalesRegion.
Employee(empId) is in SalesRegion(srId)
Each Employee is in some SalesRegion.
Each Employee is in at most one SalesRegion.
Now, unfortunately, the Employees table also contains a SalesRegionName
column. That's what I don't quite know how to model. I tried creating a
derived and stored fact:
Employee is in the SalesRegion named SalesRegionName
Each Employee is in the some SalesRegion named some SalesRegionName.
Derived (and stored) by rule: Employee is in SalesRegion and that
SalesRegion is named SalesRegionName.
The problem is that this derived fact has no uniqueness constraints. If I'm
understanding correctly, these constraints should be computed from the
conceptual join of the Employee and SalesRegion objects, so that there are
three uniqueness constraints: over Employee, over SalesRegion and over
SalesRegionName. But this won't validate!
Is there a way to model this which will leave me with the same logical
database structure?