Lattix for SQL Server

Architectural Governance for SQL Server 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.

This is the DSM of the Adventureworks SQL Server Database

Only with Lattix for SQL Server can you can formalize, communicate and control the architecture of your SQL Server database so that it remains robust and modular.

Features

In addition to the standard Lattixkey features, Lattix LDM for SQL Server has these unique features:

Discover and Analyze your Database System Architecture
Create a DSM by examing the dependencies between all objects of the database including schemas, tables, stored procedures, triggers, etc. Create what-if and should be architectures to improve modularity and increase coupling. You can:

• Identify dependencies between databases
• 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.
• Determine how users and roles relate to database elements

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