Book a Demo

Author Topic: Database Sub-Models  (Read 5058 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Database Sub-Models
« on: October 06, 2006, 05:33:52 am »
Database modelling is not the same as object-oriented application modelling.  The principal difference is that in most (if not all) database management systems, the notion of partitioning the schema into sub-schemas is not present.  Consequently, reverse engineering the database (such as EA does with ODBC) means having to select from a "flat" list of database objects.

For anything other than a trivial database, managing this flat set of database objects without some sort of structure is very, to extremely, difficult.  Most database modelling tools allow the creation of sub-models.  Many allow synchronisation (both forward and reverse engineering) via these sub-models.

Typically, these sub-models are sets of tables and views linked back to the main model.  We can simulate this in EA by the use of diagrams as the definition of the sub-models.  A given database object can thus appear in many sub-models (diagrams).  Also analogously, a database object may be rendered differently in one sub-model from how it is rendered in another sub-model.  EA can also do this via diagrams.

However, what's missing is the ability to easily select subsets of the database for synchronization.  Without a doubt, there will need to be a package that is the equivalent of the schema and all database objects below that are considered to belong to that schema.

In the thread: Packages, Namespaces & groupings, I observed that the application of a "Grouping Only" would solve some of the problems with UML Namespaces and groupings of Classifiers for OO modelling.

It seems to me that the same idea can be applied to this problem.  Grouping Only packages can be used to "flatten out" a structure.  The schema package mentioned above acts like a Namespace Root.  Thus if I select the schema package and request an Import DB Schema from ODBC; I would get the full list of tables with all objects selected (by default).  I could then tune the import manually.  If I select a lower level package, and repeat the procedure, I'd get all the objects below the selected package selected in the dialog.  I could then modify the selection manually.

In all cases however, the selected objects are synchronised with the named objects below the schema, regardless of where they exist in the grouping hierarchy.

I think this would make a great feature and make database modelling a lot easier (might even make a neat USP for EA).
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
Thoughts?  Votes?
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Database Sub-Models
« Reply #1 on: November 07, 2006, 11:20:19 pm »
Notwithstanding my proposal above, we are starting to experience problems with having our database objects in one monolithic set.

We believe that an interim solution would be for the Import DB Schema from ODBC... option to check which DB objects are located immediately below the package being used for import and automatically select those in the list of DB objects returned by ODBC.

The user can then alter the settings, if required.

This would greatly improve usability of the import process.

This could be embodied in a [Local Objects] button.

Then one could make this interface consistent with the Batch XMI Import Export by having [Save Settings] and [Restore settings] buttons

And the usual [Select All] and [Select None] buttons...

Then all you need is a radio button beside each command button to set the default.

It might look something like...

[Local Objects]   (o)

[Save Settings]
[Restore settings]   ( )

[Select All]   ( )
[Select None]   ( )

Oh... and can we have one standardised multi-select paradigm, please?

Thoughts?  Votes?
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Dave_Bullet

  • EA User
  • **
  • Posts: 295
  • Karma: +0/-0
    • View Profile
Re: Database Sub-Models
« Reply #2 on: November 08, 2006, 02:38:38 pm »
That would be very useful.  You have my vote.

David.
"I know I'm close to a good design, but it's like the balloon animals, squeeze in one spot and the problem moves down the line"

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Database Sub-Models
« Reply #3 on: November 05, 2007, 11:40:16 pm »
[size=13]Packages, Namespaces & groupings[/size] has additional, related information.

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

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Database Sub-Models
« Reply #4 on: November 06, 2007, 03:51:16 am »
I agree (strongly) throughout. Oh, and this applies to your other thread reference too.

Except...

How come you didn't include a "( )" for the [Save Settings] option in your "something like...?" All that work and I've got nowhere to click.   ;)

David
No, you can't have it!

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: Database Sub-Models
« Reply #5 on: November 06, 2007, 11:23:15 am »
This sounds like it would fit right in with some things I am doing with Progress databases to provide for assigning the schema components to specific storage areas. Got my vote.  Any time one is dealing with a schema that has hundreds of tables, some kind of partitioning is essential for making sense of it all.