Best approach for database architecture heavily focused on storing data of different fields by year and by months at the same time

I need to nail this approach as I think the architecture of the database could age badly if the project becomes big enough.

My problem is that with the current architecture that I have designed, the database would grow exponentially as it lays like this:

entity Project {
    projectId Long required
}

entity ProjectData {
    yearId Long required
}

entity ProjectMetaData {
    projectManager String,
    company String,
    agency String
}

entity FinancialData {
    monthId Long required
}

entity KpiInfo {
    otd Long,
    oqd Long,
    cumulatedOqd Long,
    cumulatedOtd Long
}

entity ProductionInfo {
    averageDailyCost Long,
    averageDailyRevenue Long,
    managementWorkload Long,
    internalWorkload Long,
    offshoreWorkload Long
}

relationship OneToOne {
    Project to ProjectMetaData
    ProjectData to FinancialData
}

relationship OneToMany {
    Project to ProjectData
    FinancialData to KpiInfo
    FinancialData to ProductionInfo
}

The diagram looks like this:
diagram

Basically a Project has a unique project ID and each Project has its ProjectMetaData and its ProjectData, after that for each year that the project has been going on the project has FinancialData, and for each month of that year, there is KpiInfo and ProductionInfo. Therefore if I am getting data from the past 4 years until now it means I am creating around 120+ tables for a single project and this is where I'm concerned, if the app. becomes big enough as I mentioned before this will mean it will not be very scalable afterwards.

Is there any common approach for this kind of data-bases where there are many versions of the same fields?

Thanks in advance and sorry if I haven't made myself very clear, I will be glad to respond to any doubts regarding my question

I once was on a team that had to build a database for an enterprise that had a strange company calendar. They had a fiscal year, divided into fiscal quarters, divided into fiscal months, divided into fiscal weeks. They wanted historical reports grouped by any one of these date groupings.
what we ended up doing was creating a table called Almanac that had one row per day, and the primary key was the date in some suitable format. The table had columns for Fiscal year, fiscal month, etc.
We then created a generator program that populated this table with about ten years worth of data, applying all of the company's rules for fiscal date groupings.
When we needed to produce historical summaries based on these groupings, we simply joined the transaction data to the Almanac table on date, and then used the Almanac columns for Group By purposes.

You might be able to adapt this concept to your case. The database will grow, but the join may be reasonable for some time to come.

It's hard to tell with the limited information you're providing, but I'm going to use one table as an example.

Add the year and month as columns in the table. Better yet, add a date column. You could set the day as the 1st or the maximum for that month.

entity KpiInfo {
    year
    month
    otd Long,
    oqd Long,
    cumulatedOqd Long,
    cumulatedOtd Long
}

This one table will now suffice for all time into the future. Yes, you will insert 12 rows every year.