The ORM Foundation

Hello again,

 Still learning VisoModeler, I'm trying to reverse engineer a subset of our existing DB.  I used Database-->Extract Physical Catelog to bring in about 20 tables into a new logical model.  (Unfortunately, the DB doesn't have PK/FK constraints defined, that's all handled at the application level)

So far so good. 

 Except that the table diagram objects are pretty large, showing index usage ect, so that a single table takes up almost half a page.

I've used tools before that let your diagram be as large as you wanted, if you printed it, it would "tile" the diagram onto multiple physical pages.  But VisoModeler seems tied to the physical page size and apparently you can't have a relationship between tables on different pages??? 

I figure I must be doing something wrong, but I have no idea what.

Help!

Thank you,

Charles

Hi Charles,

To help solve your immediate problem I suggest that you simplify the table display by switching off some of the options you will see in the dialog box at Tools>Document Options.
Another thing you could try is to  switch to multi-page mode (View>Multi-Page Mode)
In this mode you can drag tables from one page to another. (A big screen helps)

Whilst these suggestions may help you to learn the mechanics of the Logical Model view in VisioModeler, I see a deeper issue behind your questions.
You can think of ORM as a "data first" approach to systems analysis and development.
In the data first approach, domain information and the related rules are stored in a database and the "application layer" is then "just" about CRUD, SQL DML and presentation.

Your comment " the DB doesn't have PK/FK constraints defined.." tells me that in your application, the "domain information" is spread across a mixture of process code and some tables that the developers probably used to meet their perceived technical need for a "persistent data store".

If you want to use the power of ORM, then you have to begin with two paradigms:
1: Your domain information is a set of "elementary facts"
2: A properly designed relational database is a "deductive logic system" for managing instances of "elementary facts".

In your case, it seems to me that that, whilst the "elementary facts" are there, they have been encoded across a mixture of process code and tables.

So if you want to use an ORM tool for analysis, it's best to begin by studying your application and finding ouit where the "domain information" is actually stored. Your next step will probably involve a "manual extraction" of the elementary facts from the existing application.

So, whilst VisoModeler can do a lot of things, it seems to me that your first step should be to "Get the facts!"

Hope this helps
Ken

Ken Evans:

Hi Charles,

To help solve your immediate problem I suggest that you simplify the table display by switching off some of the options you will see in the dialog box at Tools>Document Options.
Another thing you could try is to  switch to multi-page mode (View>Multi-Page Mode)
In this mode you can drag tables from one page to another. (A big screen helps)

 I've simplified the diagram as much as possible, and have switch to Multi-Page mode.  The problem is that when I drag a table to another page, I lose the links to/from that table.

Can you not show links across pages?

Ken Evans:

Whilst these suggestions may help you to learn the mechanics of the Logical Model view in VisioModeler, I see a deeper issue behind your questions.
You can think of ORM as a "data first" approach to systems analysis and development.
In the data first approach, domain information and the related rules are stored in a database and the "application layer" is then "just" about CRUD, SQL DML and presentation.

Your comment " the DB doesn't have PK/FK constraints defined.." tells me that in your application, the "domain information" is spread across a mixture of process code and some tables that the developers probably used to meet their perceived technical need for a "persistent data store".

If you want to use the power of ORM, then you have to begin with two paradigms:
1: Your domain information is a set of "elementary facts"
2: A properly designed relational database is a "deductive logic system" for managing instances of "elementary facts".

In your case, it seems to me that that, whilst the "elementary facts" are there, they have been encoded across a mixture of process code and tables.

So if you want to use an ORM tool for analysis, it's best to begin by studying your application and finding ouit where the "domain information" is actually stored. Your next step will probably involve a "manual extraction" of the elementary facts from the existing application.

So, whilst VisoModeler can do a lot of things, it seems to me that your first step should be to "Get the facts!"

 I agree with and generally understand all you've said. In fact, my team is experimenting with an ORM diagram for a small new project.

However, in this case, with the existing application, I am simply looking for a quick & dirty way to provide an ERD to another team that's going to access the data with Business Objects / Crystal Reports

 Thanks!

Charles