Welcome to the WP community!
Working out a data schema from the start is absolutely the right approach, but it’s not exactly the WP approach. You should investigate available plugins first. They likely already use their own schema, so designing your own may be counterproductive. Install likely candidates on a test site and see if they meet your needs. To be clear, the following monologue includes many questions. They are all rhetorical to ask of yourself, I’m not asking anything from you.
If you know PHP, look through the plugin source code. If not, skip this paragraph. Is the plugin code well organized and neatly formatted? Is there any inline documentation? Look through WP core code to see what inline docs should look like. For example, /wp-includes/general-template.php There are more docs than code! We wouldn’t expect as much from plugins. While not a plugin, /wp-admin/includes/widgets.php might be more representative of neat, organized code. But when I first spoke of plugin organization, I meant file organization as much as code organization. Also, do function declarations provide hooks for applying third party extensions or custom work? Look for calls to add_filter() and add_action(), the standard WP hooks. A few plugins implement their own hooking scheme, review any documentation available.
Look at the plugin meta data. When was it last updated? Size of user base? Is it compatible with the latest version? Is it reasonably well rated? Look at the reviews and support forum. Are the devs actively involved? Unhappy users leaving bad reviews happens to all devs, what’s important is how the criticism is handled. Are dev responses polite and professional, or are they defensive and belligerent in return?
Once/if you’ve found suitable plugins, what needs are unmet? These may need to be custom coded. This is where you can decide on a data schema. Check out the WP DB with your target plugins installed and maybe with some sample data added. How can you use the existing structure? WP provides meta data capability for all major data objects: posts, taxonomy terms, and users. Plugins might add their own or use the default WP tables. Between custom post types and taxonomies along with their meta data capability, it’s very likely you can make use of the existing schema for your purposes.
Consider what kind of queries you will be making. What data will be used to qualify such queries? What is the volume of anticipated data? Joining various tables in a query is not a problem, but accessing data buried in serialized data is difficult. Qualifying data in queries should have their own records, be that in meta data, object tables, or your own custom tables. You should generally avoid custom tables, working with the provided schema to the extent possible. Some situations may call for custom tables. This is fine as long as the need is logical.
All WP objects are organized and related by various IDs. These IDs are usually the primary key in each table. Your schema should use a similar concept to ease integrating with WP. Keep in mind how tables would be related by query JOINs. Obviously there needs to be a relationship, be it one to one, one to many, etc.
Generally speaking you should try to manage your data as some sort of post object. These custom posts can be organized by various taxonomies by assigning terms to posts. Get over thinking of posts as blog posts. They are generic data containers.
It’s great you are planning ahead, even if not quite in the manner you anticipated. Too many sites come about by being reactionary instead of proactive. You ought to do well. From what little you’ve said, I think you will find a way to enjoy the process. I’m sincere when I bid you to have fun!
