Model Driven Database Schema Evolution

Gastón Milano

gmilano@genexus.com

Twitter: @gmilano

Artech

Agenda: Model Driven Database Evolution• Background

• Database Evolution for Business Applications

• Model Driven for Database Evolution

• Current Market Solutions

• Study Case: Our Model

• Q & A

Background

• Founders: Nicolás Jodal , Breogán Gonda

• Research• Databases, Artificial Intelligence, Code Generation

• GeneXus

• Offices: Uruguay, USA, Mexico, Brazil, Japan.

World Wide Partners

Me

Database Evolution for Business Applications

Why Database Evolution

Refactoring Evolution

2003

More than just code

Build a database VI: Create reports for a new Access database

Why Database Evolution

Multipurpose Columns

Name Type

Daniel User

Pedro User

Artech Company

Code Generation Event

Redundant Data

Opportunity for Inconsistency

Smart Columns

Address

Libertador 1448 1102

Michigan Av. 832 , CA | 099348792

…

And more…

• Tables with many columns

• Deprecated tables

• Performance Problems

Why Database Evolution

And at the end…

Fear of Change

Complexity grows over time!

But why?

Just Say Yes

But…

A database refactoring

• Change the database schema

• Migrate the data in the database

• Change the database access code

• Change data base schema implies:

• Rewriting at least DB Access Code

• Writing data migration code

• Wondering if you have already deployed your application• How to handle DB Versions?

• How to know what is the impact on existing versions?

Problems

No DB Evolution

With DB Evolution

Model Driven for Database Evolution

• Incremental Development

• Multiple Platforms (DBMS / Languages)

• Platform Independent but not Platform Ignorant

• Versioning

• Automatic Change Management

Model Driven for Database Evolution

Current Market Solutions

Some existing solutions

• Liquibase

• Eclipse for Database Professionals

• Active Record (Scaffolding Technologies)

• Visual Studio for Database Professionals

• Dbdeploy & DbDeploy.NET

Why Model Driven

Apply

Impact Analysis

Changes

Model Version 1

Application Version 1

Model Version 2

Application Version 2

What instead of How

Our Approach: The External Model

The External Model Approach

• External Model Conceptual Model & Physical Model

• Conceptual Model Physical Model

Study Case: Invoicing Application

Real-World Invoice

Database Invoice

UML Invoice

Normalization

Real world objects are not normalized.

An User View of the Invoice

User ViewsModel

The External Model

User Views User Views

External Model

Reality

The External Model

See in actionAdd Nullable AttributeAdd Non-Nullable AttributeAdd Non-Nullable Secondary Attribute Add Non-Nullable Foreign Key AttributeAttribute Type ChangeSet Attribute as NullableSet Column as AutonumberedRename AttributeAdd / Remove Attribute to Primary KeyRemove ForeignKey AttributeDelete Secondary AttributeAdd Duplicated indexAdd unique IndexRename IndexAdd TableRename TableDelete TableAdd RedundancyDelete RedundancyMove Attribute to/from 1-N TablesupertypesAdd Surrogate Keyetc

The External Model

Key Features

• Understandable and Manageable

• Consistent

• Orthogonal

Basic Semantic Elements

• Attribute

• Domain

• Business Component (User Views)

The External Model

Attribute

• Name

• Meaning

• URA (Universal Relationship Assumption)

The External Model

Domains

Data Types

The External Model

Business Components

The External Model

Attributes Structure

Rules Formulas

Sometimes we need to jump to evolve our Database Design

Model Driven Schema Evolution allows us to focus on what matters and avoid technical complexity

“Fear of Change is a good indication that you have a serious technical risk on your hands, one that will only get worse over time”

Thank you!

Q & A