Hacker News Reader

Comment by bob1029 | Hacker News Reader

> What’s important to recognize is that these same attributes apply across all levels of math.

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.

View on HN

Is there some high-level mathematical way to interpret these normal forms?

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.

My guess is that stuff is kinda iffy from a math standpoint. Relational databases are good but I've long suspected the theory needs to be overhauled a bit as we've gotten a lot better at connecting CS to math foundations than in the 1970s. (And indeed math foundations is itself getting better from that process.)

I want to learn these. How do I start learning good modelling techniques? Are the NFs you’re referring to is same as in DB design? If so, how does that translate to general code/system design. Any pointers you can provide for learning material, concepts, or books will be greatly appreciated. Thanks!

> Are the NFs you’re referring to is same as in DB design?

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.

Thanks for the suggestions!

The Codd 1971 stuff on Wikipedia looks like a mess, and I think the original is propbably a bit crufty too (though I don't want to disrespect the old masters, SQL was a high water mark of business thinking about computing in many ways).

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.

There is a book by c.j date that goes into these . It is very theory based and heavily criticises people for confusing relation and table . Book is Database Design and Relational Theory: Normal Forms and All That Jazz

Thanks for these!

I feel bad as this stuff is certainly much harder. But yes I do think it's important to try to understand databases in a modern setting and not some old set theoretic cludge that's hard to relate to anything else.

Good luck!

Reply on news.ycombinator.com