Author Topic: database schema  (Read 3089 times)

Peter_Cheung

  • EA Novice
  • *
  • Posts: 17
  • Karma: +0/-0
  • Nam-myoho-renge -kyo
    • View Profile
database schema
« on: November 24, 2002, 02:08:32 am »
Hi Everyone,

Does anyone know if EA help generate SQL database schema scripts from class diagrams?

Thank you all.  

Peter Cheung

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: database schema
« Reply #1 on: November 24, 2002, 01:12:59 pm »
Hi Peter,

You can generate it either for a single class or for a whole package. See "Generate DDL" in help, and keep us posted if you run into any problems. Make sure the classes you want to use for generating SQL are stereotyped as tables, and check that your target RBMS is specified in "Database".

Jaime Gonzalez

Peter_Cheung

  • EA Novice
  • *
  • Posts: 17
  • Karma: +0/-0
  • Nam-myoho-renge -kyo
    • View Profile
Re: database schema
« Reply #2 on: November 24, 2002, 01:46:27 pm »
Hi Jaime,

Thank you for that.  I have tried Generate DDL and it gives the sql schema script.  However, if set my class to a table stereotype I cannot do my code generation.   Is there a way to represent a class as both table and general class (for code generation)?   Or should I create a new table entity to represent my class.  I want to be able to generate both database schema sql and code stubs with methods etc...

Peter Cheung

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: database schema
« Reply #3 on: November 24, 2002, 02:10:04 pm »
If you want to generate SQL for a class, and also generate code --say, C++ or Delphi-- for the same class, this is means is that you are addressing two different artifacts: one would be a table, and the other would be --most probably-- an interface object (say, a dialog).

My suggestion would be to have tables modeled in a database (structural) diagram (t_CA, etc...), and interfaces modeled in an interface diagram (w_CA, etc...). t_CA should be stereotyped as a table.

Hope this helps,

Jaime

dougp

  • Guest
Re: database schema
« Reply #4 on: March 19, 2003, 10:21:09 am »
Hi Peter/Jaime,

I have the same question/issue as Peter brought up.
Wanted to effectively "map" my programming classes (state) to their persistent destination (tables).
Jaime wrote:
<<
this is means is that you are addressing two different artifacts: one would be a table, and the other would be --most probably-- an interface object (say, a dialog).
>>
Now, I understand that these are "two different artifacts", but they are also intimately related;  You may look at this as two different views the same artifact: 1. It's active state (whilst the classes is instatiated and attributes can change) and 2. It's persistent state (when the attribute/state is stored for use later)
Just as when you create a Property for attribute to act as a Getter/Setter and a Property is a different artifact than the attribute itself, the two are still linked in the model and can track different logic/data pertaining to the same attribute.

If the modeling tool could simply allow a attribute to have an additional type of linked artifact (just like a property) that represents its persistent state (example: pointing to a table/column) you would have a much more useful manner of modeling both your dynamic (classes) and static (persistent tables/files) states.
I hope I explained this well enough.
It just seems so obvious to me... you'd be able to automate testing for model integrity (making sure class attributes which are designated for persistent storage have persistent destinations... perhaps even testing for data-type compatibility... or even sharing names...etc).

Sorry for rambling so much about this, but this is the one element of UML modeling tools/code{ddl} generation that just seems so obvious/intuitive, yet is totally missed in this current generation of modeling tools.

It seems ludicrous that we model our classes and their persistent state/tables (commonly class=table) in the same tool, but have no way of "linking" the two.

Thoughts/ideas/opinions are appreciated.

fares1

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: database schema
« Reply #5 on: March 19, 2003, 10:27:52 am »
Oops.  Hadn't logged in and can't edit the grammar/spelling mistakes.  Will preview next time!  :)

BTW - Great forums!  
I've purchased two copies of EA Corp. for the project I'm working on and love the tool.  After using it for the past couple of weeks, RRose's obscene price seems even more obscene.  :P

-Doug
« Last Edit: March 19, 2003, 10:53:30 am by fares1 »
"Whoever fights monsters should see to it that in the process he does not become a monster and when you look long into an abyss, the abyss also looks into you."

CJ

  • EA User
  • **
  • Posts: 288
  • Karma: +0/-0
    • View Profile
Re: database schema
« Reply #6 on: March 19, 2003, 11:07:16 am »
G'day,

Although I prefer to keep classes that generate code and classes that generate DDL as separate and distinct artifacts, I would love to see a way to link the two types of classes and their attributes.

All that said, shouldn't there be a UML standard before case tool vendors implement something like that?
Cheers and best regards.

Fintan

  • EA User
  • **
  • Posts: 28
  • Karma: +0/-0
    • View Profile
Re: database schema
« Reply #7 on: March 20, 2003, 04:41:22 am »
Hi All,

There is a range of tools out there already called "Object-Relational Mapping" tools (ORM).  These can take your classes and map them to relational database tools.  The better ones can also do mappings where there is not a simple one table to one class mapping.

Perhaps someone could develop an add-in / plug-in for EA ?  Anyone ?

Regards,

Fintan