Du kannst das aus Perspektive eines Interface betrachten. Das Interface, also public Funktionen einer API, ist für alle Nutzer zugreifbar und liefern ein „offizielles“ Set an Funktionen, die zur Nutzung der API notwendig und sinnvoll sind. Dabei gibt es oft auch unterschiedliche Perspektiven.
Lagerhaltung als Beispiel
Es gibt vielleicht nur ein paar Funktionen für bestimmte Benutzer:
Einlagern(LagerID, ProduktID, Menge)
Auslagern(LagerID, ProduktID, Menge)
BestandsMenge(LagerID, ProduktID)
Kapazität(LagerID)
Andere Benutzer, die mit Kommissionierung beschäftigt sind, brauchen Zugriff auf Lagerplätze, Inventurfunktionen, Pickfunktionen ..
Und es gibt Funktionen, die kein Mensch braucht, außer der Entwickler. (Und die auch niemand benutzen soll, nicht öffentliche Funktionen halt.) Hierzu zählen vielleicht auch die wirklichen Tabellen, auf die nur mit internen Funktionen / Rechten zugegriffen werden kann. Öffentlicher Zugriff zur Datenabfrage existiert evtl. nur über Views. Funktionen und Views, die nur eine Fassade auf eine Kernfunktion sind, erleichtern auch Änderungen und Umbau. Eine bestimmte Tabellenerweiterung muss in vielen Views vielleicht gar nicht eingefügt werden, weil sie für die API keine Relevanz hat. Oder eine grundlegende Umstrukturierung wird von den API Views schlicht verborgen.
Das alles sollte immer recht nah am Bedarf entlang gemacht werden, damit man sich nicht verzettelt.
Es ist nicht unbedingt trivial, so etwas brauchbar zu entwerfen. Es sollte aber nicht ein Kriterium sein, wie sehr die eine oder andere Funktion nervt, weil sie alphabetisch ganz vorne steht, obwohl sie selten verwendet wird oder irgendsowas.
Man könnte es auch so machen. Datenmodell und alle Funktionen entwerfen, die benötigt werden ohne Rücksicht auf Nutzergruppen usw.. Am Ende daraus ein Set (Teilmenge) von getesteten und notwendigen Funktionen und Views für bestimmte Anwendungsfälle in einem neuen Schema bereitstellen.