A data model is a CONTRACT between a query and every template that will ever read it. That sentence is the whole lesson, and it is why its shape matters more than its content.
Concretely, a data model is one or more data sets — usually SQL — arranged into a structure with names. The template does not see your query. It sees the STRUCTURE the query produced: a group called G_INVOICE containing an element called INVOICE_NUMBER. Every field placed in every template binds to those names.
SO CHANGING THE MODEL LATER BREAKS THINGS YOU HAVE FORGOTTEN ABOUT. Rename an element and every template referencing it renders blank — not an error, a blank space where a supplier's invoice number used to be. Move an element between groups and the loops stop finding it. The report still runs and still produces a document, which is what makes this the most expensive kind of change in BI Publisher.
Design the structure before you write the SQL. Ask what the document repeats over — one section per invoice, one row per line — because that hierarchy IS the group structure, and getting it right first time is much cheaper than getting it right later.
ADD RATHER THAN RENAME, ALWAYS. A new element costs nothing and breaks nothing; a rename is a change to a published interface. Treat your own data models with the same caution this course applies to Oracle's: somebody else's work is bound to those names, including your own from six months ago.