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.

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.

In this example, the Adventureworks sample database, the tables in the Sales schema are nicely layered but are highly coupled to the DBO procedures

Features

In addition to the standard Lattix key 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