The model in an ideal world should only contain business logic, it models some real object such as a House. However in nearly all circumstances the model needs to persist its data to some storage.
Interactions between the model and the stored data can either happen on a separate data layer or directly in the model, which is the case when using an ORM (Object Relational Mapper). In other words either the model connects directly to the database or its passes its data to some other "data access" object which connects to the database.
An ORM (Object Relation Mapper) maps fields in the database table to the attributes of your model object, providing getters and setters. In this case there is no separate data layer and the model is directly responsible for persisting its data.
Here is an a Ruby example using
ActiveRecord a popular ORM:
class House < ActiveRecord::Base
house = House.new
house.price = 120000
Price is a field in the
houses table which is automatically detected by
ActiveRecord which adds a getter and setter to the object. When
save is called the value of the price attribute is persisted to the database.
From my point of view the pro of having a data layer is that you get a point in which you can manipulate the data before it gets to the model, the model has less it worry about, it has less responsibilities. For example you may need to combine data from several none compatible data sources, this is something an ORM can not easily handle.
The main con is its another layer of abstraction to manage, if you don't need it, don't bother, keep it simple. Less moving parts, less to go wrong.