Book a Demo

Author Topic: Domain Creation in EA  (Read 5278 times)

rneelakantan

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Domain Creation in EA
« on: March 03, 2006, 09:46:19 am »
Tools such as ERWin, CaseStudio, QDesigner, ERStudio, oracle designer allow a data modeler to create DOMAINS.  Domains are very helpful if an attribute type is used many times in different entity.  For e.g., I can create a domain "NAME VARCHAR2(50)" and then whenever I want to add  column "FIRST_NAME" "MIDDLE_NAME", "LAST_NAME" I can set the data type of these columns as NAME instead of setting it to VARCHAR2(50) each time.  The advantage of this is if in future I want to change the length of these 3 columns to 60, all i need to do is increase domain NAME length to 60 and it gets propagated to all the columns which have datatype set to NAME.  When DDL is created, these tools either can create a TYPE (based on db support or option selected) or create columns as VARCHAR2(50).  

Does EA support this feature?

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Domain Creation in EA
« Reply #1 on: March 05, 2006, 02:09:05 pm »
No.
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Domain Creation in EA
« Reply #2 on: March 05, 2006, 04:22:05 pm »
Quote
No.
Unfortunately!

This is a useful feature both for DDL and Object-Oriented models.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Domain Creation in EA
« Reply #3 on: March 05, 2006, 05:26:25 pm »
 
Quote
This is a useful feature both for DDL and Object-Oriented models.

Quite possibly.  However, I would prefer that Sparx fix the existing base level UML modelling bugs before embarking on yet more non-core functionality.
I have just spent most of my Sunday trying to get a sequence model to cope adequately with a simple create-destruct-recreate cycle to no avail.  The handling of fragments is getting worse not better, the ability to manipulate messages without having to resort to a magnification level of 1000% is irksome.  Etc etc etc. I am right now not terribly impressed.

Let me expand.  The sheer brilliance of introducing a "Quick Linker" for the diagrams is far outweighed by the sheer idiocy of not including the "use" link for actor to usecase.
bruce
« Last Edit: March 05, 2006, 05:34:44 pm by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Domain Creation in EA
« Reply #4 on: March 05, 2006, 06:39:55 pm »
Quote

Quite possibly.  However, I would prefer that Sparx fix the existing base level UML modelling bugs before embarking on yet more non-core functionality.
[size=13][SNIP][/size]
bruce
Agreed!

I was just trying to point out the utility of domains in the OO world.  This is often not appreciated at all or at best only lightly.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: Domain Creation in EA
« Reply #5 on: March 05, 2006, 08:03:44 pm »
Hi,

There is a workaround in EA for creating domains:

1. Create a package for data domains (I created it under my Database Model package).

2. Create tags for DataType, DataTypePrecision and DatatypeSize. Create a "data domain" stereotype for classes.

3. Create a data domain class inheritance tree in the top diagram in your package, with data domains as classes and "data domain" stereotype. For example: primitive domains can be dt_string, dt_number, dt_datetime, dt_boolean...

3. For each primitive type, create a class diagram and populate it with lower-level datatypes (int, float, char, varying, etc.). Assign proper tag values for each datatype class. For example, dt_money would have DataType = FLOAT, DataTypePrecision = 2, DataTypeSize = 15 (or whatever values you preffer). I would suggest that DataType have the ANSI data types as the valid types.

5. Add each non-abstract data type as a database data type (Settings -> Database data types...). This will make them visible and usable for your tables. In other words, intead of using the RDBMS datatypes, use your own dt_s

6. For RDBMSs that support data domains (SQL Server, PostGreSQL...) generate your data types with the code generation templates: at the Class Body level (be sure that the upper levels call Class Body), create a Stereotype Override for "data domain". In that template, you can create an "if" cascade to transform your ANSI types to your databases' data types:

%if classTag:"DataType" == "FLOAT"%
$dt = "NUMERIC"
%elseIf...%

And at the end just make the code to create your user defined datatype. For instance:

IF (
   SELECT COUNT(*)
   FROM systypes WHERE name = '%className%'
   ) > 0 EXEC sp_droptype '%className%'
     
EXEC sp_addtype %className%,$dt
GO

7. You can generate your domains (Ctrl + G) either into individual files, or into a sigle file, and run it in your RDBMS.

The above procedure can take some time, especially if you have not defined your domain tree. However, it is quite worthwhile if you are using EA (or are planning to use EA) in several projects, and you recognize the usefulness of data domains. It can also make your models (or model elements) transportable from one RDBMS to another, without having to change datatypes ("the forest guard ain't gonna like that, Yogi..").

I have been using this approach for about three years now,  and it has been enormously useful. I have found a problem, however, and it has to do with the fact that Oracle does not suppor ANSI data domains: you can create user-defined types in Oracle, but these are not what you would expect. It would take me a long time to explain it, but the heart of the matter is that the datatype generation approach does not work for Oracle. So what I have to do to transport reusable model elements into Oracle is to use a multi-change routine (outside EA) that transforms dt_int into NUMBER(10), dt_weight into NUMBER(8,5), dt_address into VARCHAR2(70)...

Hope this helps, but please take into account that there is a Code Generation Template learning curve involved.

Jaime
« Last Edit: March 05, 2006, 08:13:46 pm by jaimeglz »