It moves to the interface..

Once you have established as much information as possible in your data design, you need an ability to convert that into usable presentation and CRUD activity (Create,Retrieve,Update,Delete).
For me, this means establishing abstract functions that can take any table and retrieve information, insert new records, update existing records, or delete invalid data (although I NEVER delete data, just use status flags to render it inert).
I used to create utilities that created code for each table in the database (e.g., events_insert, events_update,events_get, etc.), Automated code is easy to standardize, but can take up a lot of space. It also requires custom coding the front-end interface to cover the correct function.
I created simple utilities that extract, insert, and update based upon the schema. So one function, with different parameters (the name of the table, the JSON-encoded values) serves the purpose for all tables. A little more work up front, but immediately adaptable to any future database with no custom coding.
There are certain custom functions that I created for specific purposes, such as selecting schema data for any table to the front end (used in the next phase, dynamic rendering of forms), cloning of a given record in a given table (a challenge with nested tables, since the clone of an event requires cloning of all its children records like event_roles, event_role_volunteers, etc), and report writing (for any table, produce a flat-file spreadsheet with all related foreign-key fields like event name, event role name, event role volunteer name etc. rather than those computer-friendly id numbers that mean nothing to mere mortals). But once completed, all that needs to be done is change the database/user id/password combination in the header, and it’s ready to use for any application!
Now we have to tackle interaction, in a one-page web app that could be useful in any situation.. which leads to the front-end..