MiniUML is a subset of Universal Modelling Language, which can be conveniently specified using GraphViz graph description language. Picture is the definition.

GraphViz is somewhat simpler than full UML, yet it still allows for rich expression of many concepts used in software intensive systems.

Several notational conventions are used for denoting particular semantic meaning. Where possible, direct UML notation is used.

It is of particular interest to object oriented database modelling. It is used by the WDBI project as a modelling language.

Domains

This represents actual SQL domain, used for storing data of particular type. They are marked with «domain» stereotype.

<graphviz> digraph u { rankdir=LR

email [shape="house",label="«domain»\nnid"]

} </graphviz>

Domain nid is usually used for unique numeric identifier for all objects, generated from single sequence.

By putting nid column in all SQL tables representing objects, primary and foreign key constraints can be implemented.

The SQL type of domain can be specified by using a dependancy.

<graphviz> digraph u { rankdir=LR

email [shape="house",label="«domain»\nnid"]
numeric [shape="house",label="«type»\nnumeric"]
edge [arrowhead="vee"]
email->numeric[style="dashed"]

} </graphviz>

Tables and columns

Tables are denoted by «table» stereotype. Edges to datatypes are created as columns. If edge is not labeled, the name of the domain or type is used for the column name as well.

<graphviz> digraph u { rankdir=LR

user [label="«table»\nuser",shape="box"]
varchar [shape="house",label="«type»\nvarchar"]
numeric [shape="house",label="«type»\nnumeric"]
username [shape="house",label="«domain»\nusername"]
password [shape="house",label="«domain»\npassword"]
nid [shape="house",label="«domain»\nnid"]
edge [arrowhead="vee"]
user->username;
user->password;
user->nid [label="uid"]
edge [style="dashed",arrowhead="vee"]
username->varchar;
password->varchar;
nid->numeric;

} </graphviz>

This can be coded in SQL as:

CREATE DOMAIN username varchar;
CREATE DOMAIN password varchar;
CREATE DOMAIN nid numeric;
CREATE TABLE user (
 uid nid,
 username username,
 password password
);

Inheritance, Subclassing, Generalization

Class subclass inherits from class superclass.

<graphviz> digraph u { rankdir=LR

node [shape="box"]
subclass->superclass[arrowhead="empty"]

} </graphviz>

Subclasses honour constraints imposed by superclass and have access to superclass public and protected attributes and methods.

When implemented in SQL, an instance of subclasses typically creates (with trigger) an instance of superclass, linked by foreign-key.

CREATE TABLE superclass ( nid nid primary key default nid() );
CREATE TABLE subclass ( nid nid primary key default nid() );
ALTER TABLE subclass ADD FOREIGN KEY (nid) REFERENCES superclass(nid) ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE;
CREATE TRIGGER "$ISA superclass" BEFORE INSERT OR UPDATE ON subclass FOR EACH ROW EXECUTE PROCEDURE subclass_isa_superclass();
CREATE TRIGGER "~ISA superclass" AFTER DELETE ON subclass FOR EACH ROW EXECUTE PROCEDURE subclass_isa_superclass();

Equivalence

Equivalence between two classes really means that class is known under two distinct names. It can be thought of mutual inheritance.

<graphviz> digraph u { rankdir=LR

node [shape="box"]
"atom:Person"->"foaf:Person" [arrowtail="empty",arrowhead="empty"]

} </graphviz>

Association

Many-to-one (* to 1) relationship. In the example case, each file has one owner, but each user can own multiple files.

It can be implemented in SQL as a foreign key constraint named owner from file to user.

Note that it does not specify what columns are used by the foreign key.

<graphviz> digraph u { rankdir=LR

node [shape="box"]
file->user[arrowhead="vee",label="owner"]

} </graphviz>

is the same as

<graphviz> digraph u { rankdir=LR

node [shape="box"]
file->user[arrowhead="none",headlabel="1" taillabel="*"]

} </graphviz>

ALTER TABLE file ADD CONSTRAINT owner FOREIGN KEY (owner) REFERENCES user(nid);

UML Association classes are not supported as such. You can do something like this instead:

<graphviz> digraph u { rankdir=LR

node [shape="box"]
user_categorization;
user_categorization->user[arrowhead="vee"]
user_categorization->category[arrowhead="vee"]
user_categorization->entry[arrowhead="vee"]

} </graphviz>

ALTER TABLE user_categorization ADD CONSTRAINT user FOREIGN KEY (user) REFERENCES user(nid);
ALTER TABLE user_categorization ADD CONSTRAINT category FOREIGN KEY (category) REFERENCES category(nid);
ALTER TABLE user_categorization ADD CONSTRAINT entry FOREIGN KEY (entry) REFERENCES entry(nid);

Composition

Composition is a special form of association. When associated object is destroyed, so are all instances associated to it. It can be implemented in database with a ON DELETE CASCADE foreign key constraint setting.

Example: When user is deleted, so are all his files.

<graphviz> digraph u { rankdir=LR

node [shape="box"]
file->user[arrowhead="diamond",label="owner"]

} </graphviz>

Dependancy

Dependancy is indicated by a dashed arrow:

<graphviz> digraph u { rankdir=LR

node [shape="box"]
client->server[arrowhead="vee",style="dashed"]

} </graphviz>