TP

Hello community,

I'm trying to solve a very particular concern relating to database reorganisation and matrix models. Any input would be greatly appreciated.

As we know, a reorganisation will delete any objects and occurrences that do not occur somewhere in the database. However, when matrix models are involved, things work a little differently. The (approximate) logic runs along the following lines:

  1. If there are graphical occurrences of the connection def, retain it.
  2. If there are are no graphical occurrences of the connection def, check the object occurrences of the source and target.
  3. If the source and target appear together on a matrix model, retain the connection def.
  4. Otherwise, delete the connection def.

This seems to make sense at first; however consider that two objects can occur on the same matrix model without the connection being visible. This may be because the matrix shows relationships of a different type. It may also be because the objects appear on the same axis of the matrix model and thus do not intersect to form a matrix cell.

The functionality we require is to retain the connection if one of the following is true:

  1. There is an occurrence of the relationship on a graphical model; and/or
  2. The connection is visible on a matrix model

SoftwareAG has advised that the current functionality is by design, so we have had to build our own report to reorganise according to our requirements. However, I have only been able to achieve this having the report iterate through every cell in every matrix model to build a list of connections, and then check every connection definition against this list. Obviously this is grossly inefficient, but there seems to be no function on a connection definition to simply check which matrix models it is visible in.

This is one of those problems where I feel there must be a better way that I'm somehow missing. Could anybody point me to a better way?

by Carsten Pitz
Posted on Fri, 06/06/2014 - 15:13

What do do mean with database reorganisation?

  1. a database defragmentation
  2. a change of the database schema

In both cases make twos full backup first. And verify twice, if the backups are readable.

A database defragmentation MUST NOT delete or alter any data. If it does, it is a severe database engine issue, that has to be reported immediately.

An alternative procedure to do a database defragmentation is writing a dump (a dump, not a backup), dropping the tablespaces, building new table spaces, tables, ... and importing the dump. This alternate procedure is often performed if a new major release of the database engine is installed. But it also results in a database defragmentation. And you can introduce optimized tablespace, table, index, ... parameters performing this procedure.

A change of the database schema can result in data deleted or altered. In this case a higly advise use to rethink every change at least twice. And ask your Software AG representative if you have the slightest doubt.

 

 

0
by Matias Kokko
Posted on Mon, 06/09/2014 - 10:57

Hi,

ARIS database reorganization is the procedure that removes object and connection definitions that don't have any occurrences from the logical modeling database. Creating an occurrence also creates a definition (if not already existing) but removing an occurrence does not remove the definition. Therefore it's common that relations exist on definition level that are obsolete/not wanted and it is advised to reorganize regularly to remove these also on definition level.

Regarding the requested report I unfortunately don't know of a better solution. You probably tested that CxnDef.OccList() doesn't return connections visible in Matrix models.

In my opinion the reorganization logic should work according to Tom's requested functionality where only connections visible in Matrix model are spared along with connections existing in a "real" model (I actually thought it did).

0
by Tom Purcival Author
Posted on Tue, 06/10/2014 - 02:33

Hi Carsten and Matias, thanks for taking the time to respond.

Matias is right; by 'database reorganisation' I'm referring to the administrative operation on ARIS' internal/logical 'database' concept, not the SQL database supporting the application.

Matius, although you're not aware of a better solution, it's good to know I'm not alone in thinking this would be a sensible way to do things.

0
by Tom Purcival Author
Posted on Wed, 07/23/2014 - 01:40

Hi all, I thought I would post a quick update on this for 9.6.

From discussions with our technical team, who has liaised with SoftwareAG on the topic, ARIS 9.6 has an option that switches the matrix model behaviour on or off. In one setting, matrix models are not considered for reorganisation at all; in the other you have the behaviour described in the thread above. So, if you wish to not consider matrix connections at all for your reorganisations, you may wish to speak with technical support about how that can be configured.

As I understand it, in 9.6 this setting ignores matrix models by default; in 9.6 SR1 this default setting was reversed.

The behaviour when matrix models are considered in reorganisations appears to remain the same in 9.6.

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock