Lattix for Oracle

Architectural Governance for Oracle Databases

Large database implementations can consist of thousands of tables, views, stored procedures and a variety of other elements. To add to the complexity, all of these elements depend on each other in a variety of ways. None of the approaches in use today provide a way for database administrators and developers to visualize or understand these relationships effectively.

The DSM approach is the first which allows you to understand the architecture of your database system by taking all the elements of the database and their relationship into account. You can now get a precise big picture of how your database is structured. Only with Lattix for Oracle can you can formalize, communicate and control the architecture of your Oracle database so that it remains robust and modular.

This DSM of an Oracle database has over 80,000 elements and is highly coupled on multiple levels

Features

In addition to the standard Lattix key features, Lattix for Oracle has these unique features:

Discover and Analyze your Database System Architecture

Create a Dependency Model by examing the dependencies between all objects of the database including schemas, tables, constraints, indexes, sequences, stored procedures, packages, types, java classes, synonyms etc. Create what-if and should be architectures to improve modularity and increase coupling. You can:

• Identify and group schemas for specific applications and those which provide common services.
• Identify schemas which are independent of each other.
• Layer schemas so that modularity of schemas is preserved.
• Refactor schemas which have become intertwined as a result of evolution.
• Determine how to move stored procs and packages to enhance modularity and reduce unnecessary coupling.

Control your Architecture

Specify design rules to prevent undesirable couplings. Here are just a few things that you can do with design rules:

• Minimize or prevent the coupling between schemas for different applications.
• Maintain the layering of schemas to prevent application schemas from mixing with schemas which provide platform data and services.
• If desired, allow data in schemas to be accessed through well defined synonyms and strored procedures.

Understand the Impact of Change

Understanding the dependencies between various elements of the database will improve your ability to understand how change affects the rest of the system. For example, you can:

• Get a list of what is affected when you change an element of the database such as a table or stored procedure
• Determine what needs to be tested when a change is made.
• Estimate the risk and difficulty associated with a change request.

Specifications