Using Dia to Interact With tedia2sql


Notes on Case

In general, you should try to use lowercase when dealing with tedia2sql and dealing with Dia in preparation for using tedia2sql to generate SQL DDL. Where you don't use lowercase, assume tedia2sql will be case-sensitive. In the near future, tedia2sql will support an option to convert every object, datatype, and keyword in your schema to UPPERCASE or lowercase.

In any case, tedia2sql prefers to get commands in lowercase. Attempts have been made to allow ALL UPPERCASE in such items as "NULL" or "NOT NULL" or whatever, but it is known that the code will perform best if you use lowercase when passing keywords to tedia2sql. In some cases, tedia2sql will convert your input to lowercase when dealing with it.

It bears repeating, soon there will be an option you can pass to tedia2sql to specify you want keywords, datatypes, and the like in ALL UPPERCASE, so you shouldn't sweat this small detail right now.

Creating the Dia UML Diagram

Start up your copy of Dia. Choose the UML shape set.

It's important to note that you're editing a UML diagram, and not a database ERD. Thus, we don't call things "tables" and "columns," but instead, we call them "classes" and "attributes." However, since we're all DBAs here, sometimes we lapse into table/column terminology when it's convenient or when we forget. For the purpose of this document, they're synonymous. Here's a short list of common synonyms:

In general, you should find the following instructions mostly intuitive. In fact, you might start creating Classes and Associations right away without reading further, pausing to read these instructions again when you're ready to create views, figure out how to specify datatypes, nullability, primary keys, indexes, permissions, etc.

UML Classes

Create a new class and pick its background colour. Whenever you want to create another class of the same style, copy this generic class and paste it to make the new one.

Edit your class. Set the name to whatever you want. Note that the generated SQL DDL script will use the same case as you name your class here. This doesn't matter on RDBMSs like Oracle and Postgres that are case-insensitive, but it does matter on others like Sybase that are case-sensitive.

If you choose the "Abstract" checkbox, this will represent a view, rather than a table, in the final DDL.

Attributes for Tables

Each Attribute that you create will become a column in your table. The Attribute name and type will become column name/type.

Attribute types should be ANSI SQL 1992 (SQL'92) standard datatypes. Of course you can use datatypes for your target database, but this will limit portability of your schema. If you use SQL'92 datatypes, tedia2sql will automatically pick a datatype for your RDBMS if yours does not support SQL'92 datatypes. For example, if you use "timestamp" as a datatype and generate SQL DDL for Oracle, it will automatically convert this to "date".

The Value field can be "NULL" "NOT NULL" to generate DDL indicating this column is NULLable or not NULLable.

Value can also indicate default values: "default defaultValue" will specify that the column should default to defaultValue. Follow your RDBMS syntax here. In most RDBMSs, if the column type is a string, you must put single-quotes (or even, sometimes, double-quotes) around the default value, thusly: "default 'defaultValue'".

You can mix the NULLability of the column and DEFAULT of the column as well. For example, "default defaultValue NOT NULL" or "default defaultValue NULL" will specify a default value of defaultValue and that the column is not NULLable and NULLable respectively.

If your style (like mine) calls for not capitalising NULL and NOT NULL, you can put them in lowercase. However, tedia2sql will not properly parse mixed-case "NULL" and "NOT NULL". Choose either all uppercase or all lowercase and stick with it.

Set Visibility to "Protected" if you want this Attribute to be part of the Primary Key. This will put the "pound sign" ("#") to the left of the Attribute on the Class object in your diagram, visually indicating it's part of the Primary Key. Do not put "NOT NULL" or any variation into your value field, as tedia2sql will add "NOT NULL" automatically to all attributes that participate in the primary key.

Operations for Tables

Operations are used to create either indexes or permissions (grant) statements.

In the case of creating indexes, you want to fill out the operation as follows:

Example statement created:

create unique index INDEXNAME on CLASSNAME (param1, param2)

In the case of creating permissions statments, you should fill out the operation thusly:

Each parameter name given will create a separate permissions statement in the DDL file.

Example statements created:

grant select,insert,update on CLASSNAME to param1
grant select,insert,update on CLASSNAME to param2
You can ignore the Stereotype, Visibility, Class Scope, Query, and Inheritance types of the Operation in both Index and Permissions cases.

You can also ignore the Type and Default Value fields for parameters.

Attributes for Views

If you have chosen the Abstract checkbox for the Class, then this represents a view. Each attribute will be a column. If your view joins multiple tables, you should prefix each column with the table name or table alias, ie: table.column.

You do not need to fill in the type or value fields of the attributes, since a view doesn't have such a concept.

Each attribute name will be turned into a single part of the select statement for the view, so you can get creative here, such as:

tab1.name || '.' || tab2.owner as owner.

Operations for Views

Each operation will become part of the from, where, order by, group by, and having clauses of your view. The operation name is the argument to the select section, and the type is the section it belongs to.

For instance, you might want two parts in your where clause. Thus, you'd choose for two different operations:

name: (tab1.col1 = 'hello') type: where
name: and (tab2.col1 = 7) type: where
Note that you should include the 'and' or 'or' in the Operation name field for the second and subsequent parts of the where clause.

UML Associations

Make sure both sides of your association are really attached to a connection point on the classes, or your SQL DDL won't properly create foreign key statements.

Association Name

This will be the name of the foreign key created. Commonly, DBAs name their foreign keys to give an idea of what two tables are related, eg: a Person and Account tables are related by a foreign key called fk_prsn_acct.

Role

Each role is the name of an attribute in the class. This must be correct for the foreign-key statement to be syntactically correct.

Aggregate

Whichever side is aggregate is the many side in the one-to-many relationship. tedia2sql does not automatically create the centre table for many-to-many relationships, this is the responsibility of the ERD author.

To create a one-to-one relationship, do not make either end of the relationship aggregate, but choose the proper direction to decide which is the parent table and which the child. I believe, but am not certain today (October 6th 2002) that the child table is really either 0 or 1 entry, and the parent 1, so that this is really one-to-0,1.

Multiplicity

If you would like to add constraint enforcement clauses, such as MySQL:

alter table child add foreign key (idx_iiparent_id) references parent (id) on delete cascade;

Then add the "on delete cascade" or other constraint enforcement into the Multiplicity text box. Currently, this constraint enforcement clause is only inserted for MySQL, but if your DBMS of choice allows this, by all means submit a (trivial) patch to generate this syntax.

UML Components

The UML Component is used to insert initial values into tables in the SQL DDL. This is useful for codes tables and the like. tedia2sql uses the Component 'stereotype' as the table that will be inserted into, including columns if you don't want to insert all column values. The text inside the Component become the list of values that are inserted into the table.

Stereotype

This value simply becomes the table name in the insert statement, thusly:
insert into stereotype values ( . . . )

Component Text

The text you type in simply become the values to put inside the values clause of the insert statement, thusly:
insert . . . values ( componentText )
Each newline denotes a new set of values to insert. You must specify every column in your table, even if the column is nullable or has a default value. If you want to generate a SQL statement thusly:
insert into stereotype ( col1, col2 ) values ( 1, 2)
Then you should define your Component stereotype as name ( col1, col2 ) and define the columns correctly after that.

UML SmallPackages

The UML SmallPackage is how tedia2sql inserts database-specific SQL that you want to include in your schema. This was specifically implemented for dropping and creating sequences and triggers, but it could be any RDBMS-specific SQL you want.

Stereotype

This value should be a comma-separated list of the databases for which you want to generate the SQL. Use all lowercase. Valid values are: sybase, oracle, db2, postgres, mysql, mssql, informix. In other words, any string valid to pass to the -t option is (once made lowercase) valid here.

At the end of your comma-separated list of databases, you must also put a colon then "pre" or "post" to instruct tedia2sql to place these special SQL statements before (pre) or after (post) the schema (table) statements.

Typically, sequences would be :pre statements, and triggers would be :post.

SmallPackage Text

All this text is passed as-is into the SQL DDL. Thus, you must create valid SQL for the RDBMSs you put into Stereotype into this area.

Example

The Stereotype might be "oracle,postgres:pre" meaning put these SQL statements before the table create statements, and put this SQL only for Oracle and Postgres databases.