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.
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:
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.
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.
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 param1You can ignore the Stereotype, Visibility, Class Scope, Query, and Inheritance types of the Operation in both Index and Permissions cases.
grant select,insert,update on CLASSNAME to param2
You can also ignore the Type and Default Value fields for parameters.
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.
For instance, you might want two parts in your where clause. Thus, you'd choose for two different operations:
name: (tab1.col1 = 'hello') type: whereNote that you should include the 'and' or 'or' in the Operation name field for the second and subsequent parts of the where clause.
name: and (tab2.col1 = 7) type: where
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.
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.
insert into stereotype values ( . . . )
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.
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.