I am not familiar with relational databases and just googled database normalization to get a kind of crude idea of what you are saying, but all the examples I find don't seem to give some high-level mathematical interpretation of database normalization. And it seems like there should be one (I could be way off here) based on how you are talking about forms here.
Yes
> If so, how does that translate to general code/system design.
SQL is capable of evaluating any logical outcome you would need to know about. It can be extended with application-defined functions to add convenience and a domain-specific dialect that aids in implementation speed.
Best way to learn is to start experimenting with practical problem domains. Pick a problem you care about and start modeling it over and over. 6NF followed to the extreme is actually pretty hard to get wrong. Just find the things that you need to uniquely refer to by some identity, then relate all the knowledge to them by way of single-fact tables (which can be further related and extended to add dimensions like change-over-time).
Understanding how abstract dimensions fit together is 99% of the battle. You just have to hurt yourself on some sharp edges a few times to really grasp it in my experience.
I would follow the citations of https://ncatlab.org/nlab/show/lens+%28in+computer+science%29 instead. Whatever Spivack can say about this stuff I think is going to be much more worth your while.
Looking at https://arxiv.org/pdf/1602.03501.pdf now.
Good luck!
Functional/Relational programming models are just a trivial layer on top of math. Everything is pattern recognition at the end of the day.
Domain modeling is the logical extension of building standardized "patterns" that can be leveraged for rapidly building & replicating similar ideas.
Using good modeling techniques is the most important thing for managing complex systems. If you aren't sure, you can always start modeling at 6th normal form, then walk it back to 3NF as the various pieces start to make sense together. If you have your domain in 6NF and are using purely functional/relational programming, there are mountains of mathematical guarantees you can make about the correctness of your software. For instance, 6NF gets rid of null. It forces you to deal with the notion of optional facts using 0..1-1 relations and applicable query constraints.