"The input screens and/or update ordering may not match the table divisions"
That's where controller layers comes in. Having a naked CRUD UI to direct DB modification may be stupid simple, but it usually means there's no business logic to the application. Sometimes you need direct write access to some tables, but only really naive systems need direct access write to all tables. Use the controller backends / ORM in most languages these days to do the heavy lifting bridging the two.
I issue two IP's to the customer and I could code my table:
Customer Name, UID, IP1, IP2
Super simple and will meet my business needs until.. I decide that I need to add a third IP, but only for business customers that pay be more. Now I need a few tables to model the problem. On the UI when I'm editing, I could still model 4 fields when I choose to edit the regular old consumer class customer, but in the middleware, you're adapting the customer records from a few tables to throw on the screen properly.
If you're simply representing data for data entry / raw query speed / egress performance, etc.. you're probably not caring much about the greater system, or you're making it very brittle for any new enhancements.