You've got things the wrong way around.
The model is not a poor replica of the data base. No programmer cares about the data base. The data base exists only so that in a future invocation, we can easily reconstruct the same state of our business objects as before. Data bases are strictly a means to an end. They allow some processing and offer some tricks to speed up the inefficiency caused by mass storage access, but then they are also the sole cause of these inefficiency problems. If we could get by entirely without data bases and instead persist our business objects magically in the memory of tamed unicorns instead, we'd do it in a heartbeat.
The model isn't like that. The model supports all operations that we can do in our preferred programming language, which is why we chose it. The model is what we'd like to program. It is so central to the system that it is very important not to pollute it with concerns of other levels. This is why indices, table scans etc. should be kept out of the model, but also why combo boxes, HTTPRequests etc. should be kept out.
Not having a model would mean that the same code that deals with reading and writing widgets also deals with SQL INSERTs and connection parameters. That would be very bad, because thinking about two entirely different things all the time halves your efficiency as a developer. This s why it makes sense to separate those concerns and have layers dealing with the UI, with business logic, and with data storage. It leads to an increased amount of code, but since each of the resulting classes has a clearer focus of what it's supposed to do, general efficiency increases.
This result has been hard-won over several generations of programmers, and since it's non-obvious, every new generation has to be convinced anew that they will be better off not trying to do everything at once. But the majority of professionals will confirm that in this respect, having more and simpler classes is better, even if you end up with more code lines in total.