Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Linking Reference Data

If you have a number of projects that use the same reference data, you can use a central repository containing all common data and configure the other repositories to link directly to this data. This data includes system resources such as Security Users and Groups, Permissions, Scripts, Glossary terms or Data Types.  Sharing common data between repositories makes it possible for teams working on multiple projects to leverage a common and consistent set of system resources, thereby promoting or enforcing common usage and standards. 

Sharing common data can be applied to both existing and new projects, however each individual repository can be configured to use as much of the common data as is deemed necessary.

The ability to link to common data in a central repository uses the native features provided by the various Database Management System (DBMS), MySQL, SQL Server and Oracle.  Meaning that it is configured at the database level. The benefit of this is that Enterprise Architect will function normally without needing any modifications in order to access the data, in fact it is not even aware that the common data is physically located in another repository.

Access

Ribbon

Settings > Model > Transfer > Shared Repository

Configure a Repository to use shared data

The 'Shared Repository' screen provides an Administrator the ability to generate a SQL script that can be run on the current repository's database and configure it to share common data of a centralized repository.  The generated script is tailored based on user selection and the DBMS of the current repository.

The process to configure the current repository to share a centralized repository's data, is:

Step

Action

See also

1

In 'Script File' field, enter the complete filename and path of the script, or click on the Browse. button and search for it.

2

In the 'External Repository' field enter the database name of the centralized repository.  Enterprise Architect will only continue if the entered database name exists on the Database Server hosting the Current Repository.

3

Select which Table Group(s) will be shared, as explained in this table.

4

Click the Generate button to create the script and save it to the specified location.

5

Open the SQL console of your choice and execute the generated SQL script.  Since the schema of the database is being updated an elevated level of permissions are required to execute these statements.

Select Table Groups

There are approximately 30 tables that can be potentially shared between repositories, the 'Shared Repository' screen organizes these tables into logical Groups.  While some Table Groups only contain 1 table, others contain multiple.

You can select all Table Groups or as many as is appropriate for the current repository.

Option

Action

See also

Security Users and Groups

This group of tables contains a number of tables that define the Model Users, the Security Groups and the Security Groups each Model User belongs to.

Security Permissions

This group of tables contains the security permissions that are assigned to each Model User and Security Group.  While at first glance it might seem strange that the Security User and Group does not include Security Permissions, it was a deliberate decision to keep these two separate because it provides a greater level of flexibility.  

People

This group of tables contains the definition of all people/resources in the repository.

Glossary

This group contains the Glossary table that defines the glossary terms for the repository.

Types

This group of tables contains the definition of reference types that are typically used to populate drop down lists within Enterprise Architect's screens.  Types like Complexity, Constraints, Effort, Problem, Property, Risk, etc.

Complexity Factors

This group of tables contains the definition of complexity factors, like ECF and TCF.

Scripts

This group contains the Script table that defines all custom JSScript, JavaScript and VBScript.

Editing Source Code

Data Types

This group contains the Data Types table that defines both the data types for all code languages and DBMSs.

How it works

The scripts generated by this screen work by renaming each Enterprise Architect Table that has been selected and then creating a Synonym (or View) that references the centralized database's table of the same name. 

Consider the example that the current repository/database called EA1 should be configured to share EAMAIN's T_GLOSSARY table.

The script will:

- renamed table EA1.T_GLOSSARY to EA1.T_GLOSSARY_BAK

- create a new synonym (or view) call EA1.T_GLOSSARY that references EAMAIN.T_GLOSSARY

Both Microsoft SQL Server and Oracle support database Synonyms, which are  a mechanism that provides an alternative name for another database object, in the case of shared data the other database object is a table in another database.  MySQL does not support Synonyms, however a View can be used to achieve the same behavior.

Removing Shared data

As described in the 'How it works' section, since the scripts generated by this screen simply rename the original tables by appending "_BAK" to their names, it is a relative easy process to rename (or delete) the synonym (or view) and then rename the table back its original name.

Notes

  • Enterprise Architect can only generate Shared Repository scripts for  MySQL, SQL Server and Oracle based DBMS repositories
  • In order to share common data all repositories must use the same DBMS and must be on the same network, preferable on the same database server (for performance reasons); that is, if the central repository is MySQL then all repositories that will use the common data must be MySQL and have direct network access
  • The Shared Repository screen cannot be opened while the current connection is using a Cloud connection, because Cloud-based connections do not provide the necessary database information needed to generate a working SQL script; however, once the script has been generated (while connected with a direct ODBC connection) and then executed, Cloud-based connections will read shared data in the same way as their direct connection counter-parts