Any application has two perspectives. They are the Data Model and the Object Model. While the Data Model defines the way the data is defined and stored, the Object Model defines how the same data will be represented to the user in the presentation layer or, is exposed to the other layers of the application. The Data Model of the application usually deals with the storage and retrieval of the application's data to and from the relational store.

The relational store is used for data persistence, consistency, concurrency, and security. It contains the application's data and typically comprises of a set of tables, views, functions, procedures, and the relationships. You typically use T-SQL to query against the relational store which returns result sets that contains columns and rows of data.

However, the data returned doesn't necessarily match with the application's object oriented programming model. Usually, we don't use the data returned in the same form in which it is returned from the relational store. We write the necessary code to transform the data returned from the relational store to business objects in the data access layer of the application. Similarly, you need into write code to transform your application's business objects into a form that can be persisted into your relational store. But, what if the schema of the underlying relational store changes?

To bridge this apparent mismatch between the data and the object models, ORM tools have evolved. They are used to reduce the code required to transform your application's business objects into a form that can be persisted into the relational store and vice-versa.