File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes UML / Relational Modeling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "UML / Relational Modeling " Watch "UML / Relational Modeling " New topic
Author

UML / Relational Modeling

Jose Ortuno
Ranch Hand

Joined: Nov 10, 2002
Posts: 39
Hi all out there,
Perhaps this is a silly questions but will help me clarify some issues.

We are working in a human resources/pay roll project. Currently we are at the designing stage and I am facing a problem with the UML/RELATIONAL MODEL mapping.

Here I will show a little part of our class diagram just to keep it ease:

class employee
id
name
lasName
addres
etc
some methods
m1, m2,m3 ...

class secretary inherits from employee
class Clerk inherits from employee
class Manager inherits from employee
...


In my relational model I have:

Table Employee
id
name
lasName
addres
type -> witch maps to EmployeeType.id
etc

Table EmployeeType
id
description
example >>>> 01 Manager
02 Secretary
03 Clerk
04 Etc

My question is:

Should I have a class EmployeeType since it is a entity in my db model?

I am avoiding to have a class so I will add Employee subclasses as we need another employee type. However, that will change my class diagram and will add some NEW code.

From the user perspective, however, it will be just another record in the EmployeeType table that I will associate to an employee later on.

At this point I get confuse because I should not change my model just because a new Type of something appears.

I will like to know the right way to model this situation. So if anybody can point me in the right direction I will really appreciate it.

Thanks in advance!
Jose.

PD: Hope my explanation depicts the problem right.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Jose Ortuno:

Should I have a class EmployeeType since it is a entity in my db model?

I am avoiding to have a class so I will add Employee subclasses as we need another employee type. However, that will change my class diagram and will add some NEW code.


The relational <-> object mapping is rarely one-to-one.

Employee type can simply be a property of the class and nothing more - as long as that type does not affect behavior. You will have to add new code anyway once the type has an affect on object behavior.

Agile Data: Introduction to Object-Orientation and the UML
Agile Data: Object Relational Impedance Mismatch
Agile Data: Mapping Objects to Relational Databases: O/R Mapping In Detail

Refactoring: Replace Type Code with Subclasses
Refactoring: Replace Subclass with Fields

A UML Profile for Data Modeling
Notation Summary
[ April 03, 2007: Message edited by: Peer Reynders ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I would not be surprised to see a bunch of code-value lookups in a system. A lookup API might let you look up one code to get a value to display for a given employee or a collection of all codes & values to put into a drop-down list. With that in place you wouldn't need an EmployeeType class. You might see:

A more specific thing to think about ... You're building a class hierarchy where some kind of role-based permissioning or behavior might be better. For example, if you promote a Clerk to a Manager you can't change the type of an object in memory from Clerk to Manager. But you could change it's permissions or behavior:


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jose Ortuno
Ranch Hand

Joined: Nov 10, 2002
Posts: 39
Thanks you guys for your help/references, this is and excellent starting point.

Cheers!

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: UML / Relational Modeling