How the Data tier is conceptually represented and analyzed by the Visual Mapping Studio?

The power of Visual Mapping Studio is ease of generation, maintainability and tuning of data services. An architect, a developer and a DBA can use this tool to satisfy architectural, coding and database requirements in one place.  Each mapping (database access projection) is made up of SQL, an Object graph and the ADO.Net code (database access code) that brings them all together.

To look into this in detail:
A system, in this case a data tier [DT] is made up of multiple data services [Data Service]. Orasis Software strictly enforces [DT] to be isolated as an independent tier and thus enforcing separation between data access and business logic. Operations on data can be performed at the SQL level through the powerful SQL functions provided by the database vendors or they can be performed in code. This is a choice of the architect and most of the time is controversial and open. Orasis Software focuses on performance and we do not enforce any architectural decision on operations of data.
 

A [Data Service] is made up with multiple data projections to the database that target a business requirement [RDBMS Data Interaction] or a group of related business requirements. An open XML format Visual Mapping Studio project [XMP] is the collection of all of these Data Services and each project can conceptualize different aspects of the [Data Tier]. For each [XMP], the studio allows the creation of a database connection with the selection of a middleware provider from available providers and is stored in the project and can be edited and changed at all times.

An [RDBMS Data Interaction] is a mapping and a mapping is made up of an SQL statement [SQL], an object graph [Object Graph] and the code [Code]. The [Code] is consisted of database access code [Data Access Code] and a Data Model Object Graph [Object Graph]. A Data Model Object Graph [Object Graph] is the data contract that is known across different application services. The [Mapping] comes in three flavors:
 

A [SQL] is parsed into data columns [SQL Data Column] and parameters [SQL Parameter].

The SQL can be of different types.
 

The SQL parser determines the SQL type and assigns the data columns and parameters.
The data contract [Object Graph] may be auto constructed by the Visual Studio Code generation engine itself where it semantically mirrors the SQL parameters and data column types [Managed Object Graph] or an object graph that the engineer has constructed in some library [Imported Object Graph]. The mapping control allows true ‘n level’ nested mappings into the [Imported Object Graph] at any child level as long as the child has a default constructor so it can be instantiated. Visual Mapping Studio maintains a library for the auto generated object graphs and its runtime credentials are maintained in the settings for Object library settings. [Managed Object Graph](s) are auto mapped in the mapping control. When the [Object Graph] is mapped the engineer has the liberty to remove any field mappings at any time and rebuild the code.

Visual Mapping Studio Type Selector and Managed Type creator expose all of the public properties of the [Object Graph]. These are the fields that can be mapped [Object Mappable Field].

Essentially,

.

Mappings are defined in the following flavors:

Since an [RDBMS Data Interaction] is a [Mapping], a data service can also be defined to be:
 

The construction of the [Data Access Code] is the output of the code generation engine and the [Data Access Code] is the outcome of the field mapping definitions.  A field mapping [Field Mapping] is a one to one mapping assignment relationship of [Data Column] or [Parameter] to an [Object Graph Mappable Field] as well as in the opposite direction in a persist mapping.
 

Or

The data access generation engine has the knowledge to apply automatic conversions [Conversion] on a [Field Mapping] that is semantically allowed by the .Net runtime. If such a conversion is required it will be applied.

The Visual Mapping Studio treats the [Mapping] as an individual compilation unit. There are two parts that need grammar verification here which is the [SQL] and the [Code].  The Visual Mapping Studio SQL parser verifies the [SQL] grammar and the .Net compiler verifies and compiles the [Code] grammar.
The [Data Access Code] is contained in a .Net Class as a Class method. So essentially
.

A [Data Service] is translated as a .Net class with the methods [.Net Class Method] being the database access methods to be invoked by the other tiers.

A [.Net Class Method] based on the type of Mapping can take the following formats:
In a [Select Mapping] the [SQL Parameters] are mapped to method parameters and the class type of the [Object Graph] is always the return type as a generic argument in an IList collection.

In a [Delete Mapping], [Update Mapping], [Insert Mapping] and [Stored Proc Mapping ] the return parameter is an int that defines the number of affected rows and the method parameter is a generic list of [Object Graph] whose [Object Graph Mappable Field](s) are mapped to the [SQL Parameter](s).

All [Mapping] constructs translate to .Net code inside .Net Classes that can be exported as Microsoft Visual Studio projects and be used in the business projects in the enterprise.