I will extend the 4NF example from Wikipedia with a Cost attribute.
Define the relation from Wikipedia as R(Restaurant, Pizza, Area). By the original definition of R, there are multivalued dependencies Restaurant ->> Pizza and Restaurant ->> Area in R.
I have an arbitrary total function f: Restaurant × Pizza × Area -> Cost.
If we use our function f in a projection, we can define our new relationship by the projection R' := \Pi_{ Restaurant, Pizza, Area, f(Restaurant, Pizza, Area) }(R).
Alternatively, we could define the same relationship by natural joining R to itself (Call one set of the columns S, and one set of the columns T). Then, rename (S.Restaurant, S.Pizza, S.Area) -> Cost, renaming each tuple by our function f.
Or in SQL terms I would just say
ALTER TABLE R ADD COLUMN cost;
UPDATE R SET cost = f(restaurant, pizza, area);
In Wikipedia without Cost as a column we achieve 4NF by decomposing into two relations,
R1{ Restaurant, Pizza }
R2{ Restaurant, Area }
Why can't we decompose the R' further? I thought that, since projecting onto R{ Restaurant, Pizza, Area } yields the original Wikipedia data and constraints, that there would still be a matching multivalued dependency in my new relation.
Multivalued dependencies are defined with respect to a specific relation ( X ->> Y for R(X,Y,Z) iff R is the join of its projections R_1(X,Y) and R_2(X,Z) ). Extending the relation with an additional column does not imply the same multivalued dependencies remain, even if projecting onto the original three columns yields a table with the same constraints as the original Wikipedia example.