That's a little complicated. On most database platforms, you'll need to write "triggers", for example a trigger to ensure that if an attempt is made to put through a transaction that deletes the only remaining person associated with a given address, this attempt is detected and the transaction is automatically rolled back. If you are designing your database using a sophisticated data modelling tool like ERwin, the tool will be able to see (from the cardinalities you specified on the relationship in your diagram) that these triggers are needed, and will script them for you automatically.

Congratulations! That's amazing, and you are welcome - it's really gratifying to learn that my videos have played some part in this.

There isn't a repeating group because there's no repetition of anything. And regarding the idea of non-atomic values, see my reply to LucasGuerrero-t6x below.

@@decomplexify Thank you for clarifying.

Yes, that's correct.

@@decomplexify Sweet. Appreciate the fast replies.

You're referring to the idea that everything has to be "atomic" in 1NF. However, I haven't included "everything must be atomic" as a 1NF criterion in my Database Normalization video. Database theorists like Chris Date and Hugh Darwen nowadays consider "atomicity" to be a fairly meaningless concept. They say the notion of being "non-atomic" would be either so sweeping that it includes everything, or so subjective that we can't usefully apply it. For example, suppose there's a table that has a column called Number_Of_Members. This column has values like, for example, 27. But 27, if you think about it, really means 2 tens and 7 ones. So 27 isn't an atomic value; it is decomposable into parts. On this basis, any table with an integer column would violate First Normal Form. The same would likewise be true of any string column, because a string can be decomposed into individual characters. The same would likewise be true of any date column (which decomposes into year, month, day of month). And so on. And yet this would be absurd. This is why people like Chris Date no longer regard atomicity as a 1NF criterion, and neither do I.

@@decomplexify Interesting. Yeah, definitely. Now that you mentioned, that Release-Year-And-Month could be "atomic" if we consider it as a string. Thank you for the heads up on the newest discussion on this topic.

That's a very good and perceptive question! The answer is that "make up all the attributes in the table" is correct. We can use our Model_Colors_Available table as an example. The key is {Model, Color}, and lets say that in addition to those two attributes, the table has a third attribute called Model_Color_Introduced_Timestamp. This is the housekeeping attribute. You're worried that the multivalued dependency Model ->> Color still exists but has become non-trivial - thus violating 4NF. However, this is not the case. The true situation is: now that we've added the housekeeping attribute, there isn't any multivalued dependency Model ->> Color anymore. With all three attributes present, the only way you could say there was a multivalued dependency Model ->> Color would be if the following condition is met: We can pick out a given Model value (let's say "Tweety") and be confident that the set of Colors associated with it ("Yellow", "Blue") will always be the same regardless of which value of the housekeeping attribute (like "2024-11-29-09:49") we choose. But this condition DOESN'T hold. So there isn't a non-trivial dependency Model ->> Color; in fact there isn't a dependency Model ->> Color at all. And therefore there is no violation of 4NF.

@decomplexify thanks for this in-depth answer

An "allowed configurations" table featuring Model, Color, and Style violates 4NF when the business rules and conventions that apply are the ones I described in the video. However, if different business rules and conventions apply, then such an "allowed configurations" table IS in 4NF. What I described in the video was a company called DesignMyBirdhouse that does custom-made birdhouses based on a selection made by the customer from a menu of choices. There is no inventory kept in stock; every birdhouse is custom-made on demand. And so there's no prospect of a particular combination being out of stock, because there is no stock. So, when you say "maybe you have too many configurations and it's too costly to keep them in stock", you're describing a different type of business, with different constraints - in particular, the notion that Color and Style are independent of each other for a given model doesn't apply in the type of business you're describing. Under THOSE conditions, an available-combinations table featuring Model, Color, and Style is in 4NF. The key thing here is that you can never know whether a table is normalized unless you know the dependencies that apply. A given table might be normalized given one set of dependencies, but not normalized given a different set of dependencies. This is what your comment brings out.

@decomplexify irl It's an executives decision what's allowed. The table you broke up to get 4nf is what I call an executive normal form table. Those are the available options. For the haters you don't understand how this is used in business.