You can reverse engineer an existing database into an MDriven Designer model, inspect its structure and live data, and then refine the model so it describes the legacy system accurately.

What database reverse engineering does

Database reverse engineering reads a database schema and creates a UML model from the information declared in that schema. In MDriven Designer, the result includes:

• A class for each discovered table.
• Attributes for table fields.
• Associations for declared primary-key and foreign-key pairs.

For example, a database table named Album becomes an Album class. A declared foreign key from Album.ArtistId to Artist becomes an association between Album and Artist.

The generated model gives you a diagram-level view of a database that may otherwise only be understood through table definitions and SQL queries. You can draw the generated classes on diagrams, use AutoDiagrams for an overview, and run the model against the same database to inspect the existing data.

Start safely

Before you reverse engineer a database, work from a copy or backup of the production database where possible. You need a valid connection string and permission to access the database.

Important: choosing Go! in the reverse operation clears the existing content of the package you selected and fills it with the reverse-engineered content. Do not run it against a package that contains model work you need to keep.

If your goal is to understand a production system, a practical approach is:

1. Restore or obtain a copy of the production database.
2. Create and save a new MDriven Designer model for the reverse-engineered result.
3. Reverse the copied database into an otherwise empty package.
4. Review and refine the generated model before making model or database changes.

For the complete procedure, including connection setup and the reverse dialog, follow Reverse Engineer a Database. You can also watch the AdventureWorks walkthrough.

Reverse a database into a model

In MDriven Designer, start the reverse operation from the package you want to populate:

1. Right-click the package.
2. Choose Functions, then Reverse Database.
3. Enter a valid connection string for the database.
4. Select Analyze db to inspect the schema that MDriven can read.
5. Confirm that the package is safe to replace, then select Go!.
6. Drag the generated classes from the model tree onto a diagram to review the result.

The initial diagram is often the fastest way to identify the main entities and the declared relationships. For example, when you see Album linked to Artist and Genre, you can understand that each album is stored with references to an artist and a genre.

Inspect legacy data with the model

After reversal, run the model against the same database. MDriven can then use AutoForms and the EcoSpace debugger to display and edit the data represented by the model.

This is useful when you need to answer questions such as:

• Which records exist for a particular class?
• Which objects are connected through a foreign key?
• Which required relationships must be assigned before a new record can be saved?
• Does the model's type or nullability match the database?

For example, if the database defines Album.ArtistId and Album.GenreId as foreign keys that do not allow NULL, a new Album must be linked to both an Artist and a Genre before it can be inserted. In an AutoForm, assign those links by drag and drop before saving.

Review database-assigned primary keys

A legacy database may use integer identity columns rather than MDriven's standard ECO_ID key strategy. Reverse engineering creates integer attributes for such identifiers, but you must verify the persistence mapping before creating new records.

For a database identity key, the relevant mapping is:

Mapping item	Purpose	Example
Primary key	Identifies the class attribute that maps to the table's primary key.	RecordId identifies a record.
Primary key mapper	Specifies how the database generates the key.	Set the mapper to AutoInc for normal database auto-increment behavior.
DbAssigned on the key attribute	Tells ECO that the database, rather than ECO, assigns the key when a new row is saved.	An AlbumId identity value is read back after the insert and can then be used in related objects.

With DbAssigned, ECO omits the primary-key value on the first save and reads the saved row back to obtain the database-assigned value. This is necessary when that value will be used as a foreign key by related objects.

Treat the generated model as a starting point

Reverse engineering can only infer what the database schema declares. A database may contain relationships used by application SQL that are not defined with explicit primary-key and foreign-key constraints. In that case, those relationships cannot be inferred reliably from the schema.

Review the generated classes, attributes, and associations against the database and the application's known behavior. Add missing model elements and persistence mapping where the schema is incomplete.

For example, if two tables are regularly joined by application code but have no declared foreign key, the reverse process will not create an association. Add the association manually and define the required persistence mapping, or use the schema-assisted Reverse worker described in Reverse Engineer a Database.

The Reverse worker is intended for this refinement scenario: it lets you inspect tables and columns, mark columns as primary-key attributes or foreign keys, and then review proposed actions in the model. Use it instead of Go! when you are largely satisfied with an existing model and need to add missing details rather than replace the package.

Add meaning that the schema cannot express

A database field type does not always communicate its business meaning. Refine the reversed model with information needed by the user interface and by people reading the model.

For example, a byte[] field that stores a product photograph can be changed to a Blob and marked as an image. When you run the model, debugger forms can then treat the value as a photo rather than as an undifferentiated byte array.

Apply the same review to names, types, nullability, and relationships. The goal is not only to reproduce tables, but to create a model that accurately explains how the data is used.

Evolve a reversed database carefully

Once the model describes the database, you may want to add a class, attribute, or association and use database evolution to apply the corresponding database change.

For database evolution to compare the current database state with the current model, ECO needs an existing database script as its baseline. Reversed databases do not have that baseline automatically. Before the first evolution, run the model once and allow ECO to write the current script to the database. This is a one-time initialization required only when you intend to use database evolution on a reversed database.

After that baseline exists:

1. Change the model. For example, add a ReleaseDate attribute to Album.
2. Run the model.
3. Choose Evolve.
4. Review the generated SQL script before applying it.

A typical generated change for the example above adds a non-null ReleaseDate column with a default value. Review every proposed change against the legacy database's existing indexes, constraints, integrations, and data rules.

A reversed database can contain indexes or other database details that are not fully represented in the model. An evolution can therefore fail on an existing database object, such as an index that the generated operation cannot remove. Investigate the reported object in the database and resolve it under your database change-control process before retrying.

Validate after mapping or schema changes

After refining mappings or evolving the database, check that the model and database remain compatible. In MDrivenServer, Validate data in the database includes a column and field consistency check for type, nullability, and string-length differences. Resolve reported differences before they become runtime errors.

Do not confuse database reverse engineering with Reverse Derivation. Reverse engineering creates a model from a database schema; reverse derivation uses EAL to split a composite value into separate values during an update.

See also

• HowTos:Reverse Engineer a Database
• Documentation:Validate data in the database
• Documentation:MDriven Backup & Restore Guide
• Documentation:Reverse Derivation