I worked at an educational institution where we ran an academic-focused Enterprise Resource Planning (ERP) system that was fairly large. Not quite 40k tables, but it had over 4k. To give you an idea of how this was organized:

    * Most simple things like a "Person" were multiple tables because you had to include audits and historical changes for each field
    * A "Person" wasn't even all that useful because it included guests or other fairly transient entities like vendor contacts so you had an explosion of more tables as you classified roles into "Student", "Faculty", "Employee", etc... (many with histories as above).
    * Addresses and other non-core demographic information were usually sharded into all sorts of categories like "primary", "parent's", "last known good", "good for mailing", etc... (more histories, etc...)
    * All coded information like label types such as "STUDENT", or "MAILING" were always handled as separate validation tables with strict FK constraints and usually included extra meta information like descriptions and usage notes within parts of the system.
    * Each functional sub-system (HR, Payroll, AR, AP, etc.) had its own dedicated schema.
    * All external jobs, processes, and external integrations were configured separately.
    * All enterprise integrations usually had a whole a dedicated schema for configuration.
    * Most parts of the interactive web UI were database driven (Oracle's Apache mod PL/SQL) with many templates and other components stored in large collections of tables.

I'll stop there, but basically just imagine a very large application that tries to be 100% database-driven. That's how you get a lot of tables.