I've seen it done two ways.
The first way is to do everything using CRUD methods. That's essentially the way you are describing: Create, Read, Update and Delete. Most Object-Relational Mappers (ORM's) support these four operations.
The second way to do it is to provide a Service Layer. The Service Layer exposes methods that embody business operations. In turn, it translates those business operations into the appropriate CRUD methods.
At this point, it might be useful to discuss architecture a bit.
First, note that MVC and MVP are primarily about UI. That is, they don't particularly care about what happens in the business domain. While UI can, and often does, reflect the nature of the business domain in the data that it displays and the interactions that it makes with the user, the heavy lifting is done in the Model portion of MVC or MVP.
In a web page, MVC typically looks like this:
Model <--> Controller <--> View
The Model is the "everything else" part of these patterns, the part that doesn't concern itself with UI or routing or any of those mechanics. You may have heard the phrase "thin controller, fat model." That means that business logic doesn't go into the controller. In turn, the View doesn't concern itself with data, for the most part. It's just a surface; the task of filling it with data typically falls on a ViewModel object, which is typically assembled in the Controller with data derived from the Model.
Model <--> Controller <--> ViewModel <--> View
The View displays data and accepts typed-in data from the user. It might have some interactive and validation capabilities, but even validation is not wholly performed in the client (because data from a client can't be trusted). Validation is relegated to the server, where the Controller (who acts mostly as a switchyard) typically delegates such validation to the Model.
In other words, most of the application logic that actually does anything useful is pushed as far back as it can be towards the Model.
It is for all of these reasons that MV* applications typically have some sort of Service Layer, even if it's just an internal one.
Database <--> ORM <--> Service Layer <--> Controller <--> View Model <--> View
|-------------- Model -------------|
The Service Layer relieves the Controller from having to think about Business Logic, and allows your Database Communicator (i.e. your ORM) to only have to think about CRUD.
P of EAA: Service Layer
Fowler on UI Architectures