I am delving into the science of UML. The tool I am using is ArgoUML. I feel very confident portraying OO designs through this tool. But what still vexes me is the incorporation of the database. What does one do in UML to show table structure? Stored procedures? So on and so forth.
Classes are tables. They just lack methods. Perfectly simple UML. Indeed, the UML for entities and relationships was carefully considered.
Just set your class definitions so they don't show the compartment with methods. That's all.
You can use a stereotype to identify those classes that map to tables.
Stored procedures are an abomination. You can think of them as free-standing objects (i.e., special-purpose classes with only one instance and only one method.)
You can think of the "schema" as class which contains stored procedures as methods. That's not too bad.
My preference is to simply disallow them entirely and save yourself the agony of designing and documenting them. Everything you think you might want to do with a stored procedure can be done with a "Model-layer" class (and methods) that maps to a "Persistence-layer" RDBMS tables.
It seems quite clear.
I think that there are two opposite visions of UML and databases.
On one side you have traditional and old methodology using Model Driven Development and books such as Scoot Ambler.
On the other hand you have new initiative where UML is reversing Java annotations and adding this information in the code. I mean that UML is synchronized with the java code persistence annotations used by the EJB3 specifications (e.g. hibernate annotations). These annotations are created by using a Database profile composed by database stereotypes. This database modeling at the same stage as the object UML model modeling is only possible because of the use of JDK 5..7 annotations with ORM mappers. It means that you have to know not only UML but also the way the mapper will be working. Pretty hard but really powerful and time saving approach.