There is a mismatch between the two models, but it can make sense to think of the entities at hand as objects at times, and relational data at other times. That’s why ORMs are a thing, and also why most popular programming language nowadays are multi-paradigm, so they can also support a more data-oriented approach.
You can't outdate math (you can outdate math notation though, finding better ways to express the same information). To be fair SQL is not 100% relational algebra compatible, but it is close enough
Starting with modeling data will immediately cripple software engineers from building what the business needs.
Starting with business models and then deciding what data storage is appropriate is a more practical way of designing software. Operational data very often fits in schema-less document storage.
Relational databases are excellent tools for analytics and reporting.
I stopped architecting software with relational databases “first” 7 years ago and will never go back.
Document databases are highly adaptive and denormalized data is inherently faster.
I’ve since found very rare cases where a boundary requires a relational database.
Welcome to my Domain-Driven Design rant.
Facts and the relationships between facts is a deeper foundational principle than the concept mashup of modularity, hidden [mutable] state, dynamic dispatch and interface subtyping that object orientation is formed from. Databases are more long-lived than applications, so applications tend towards adapting to the form of the data rather than the other way around.