Seriously, we live in a universe where everything is composed of lots of smaller things that exist in relation to each other. Relational Data isn't so much a database technology as it is fundamental information theory.
That being said - let's take a field which changes fairly rapidly, all things considered - medicine. You have two forms of changes which can occur within your data model -- (a) definition changes where your schema stays the same effectively and (b) paradigm changes. Let's say you're with a patient and need to code in a ICD[1] value for whatever malady he has. A crude analogy would be a comparison between the Dewey decimal system and the ICD. As the ICD evolves, new codes might be added but the fundamental structure remains the same. So, a new database paradigm TotallyAwesomeRuleBasedImmutableDB pops up, and you just use the pre-existing code for "Databases" (say 20) and appropriate the next available integer in that set for TARBIdb(lets say, 73). No problems there. Essentially, we just inserting a new value (73, or added a new "smaller thing") into the set of Databases to universe U_1 by without violating any invariant properties. Consider (a) a non-issue.
The problem occurs when you need to address the issue of your patient being an alcoholic. Previously, this was referred to as trunksucht (loosely translated as: "dipsomania"). This would fall under the 305, 303, 291, or 980 codes depending on if you were say, a non-drinker with no psychological cravings for alcohol who pledged for a frat, drank too much and developed alcohol poisoning as a result of that. If you were a daily drinker exhibiting physical withdrawal symptoms, you would be coded from an entirely separate section. From the ICD-9 to ICD-10, the WHO reclassified this entirely (such that either patient would be coded in to an entirely new category 'F10').
This breaks a lot of things, from the front-end GUI which would do validation with a regexp [0-9]{,3}\.[0-9]* or some such which is trivial enough I suppose, to the stored procedures which then have to get vendor approved schema changes, all of which will be rolled up and sent to your IT guys who have to go through tedious QA to make sure everything works. (And I mean literally every modal dialog, every validation, every external XML-RPC call to bill out your patients insurance company, Universe U_2).
I've read Codd's paper, the entire ANSI SQL11 standard, and have a fair grasp of both major vendors. There is nothing in there about gracefully dealing with these situations. I suppose one could argue that an RDBMS' purpose is solely to act as a data-store while retaining availability and data integrity -- that is, U_1 is all your Oracle instance cares about (manage your tablespace's set of schema objects and the interaction between U_1 <--> U_2 is completely out of the scope of it's set of responsibilities). Maybe so, but when Oracle added the XMLType with full XPath selector capabilities in 9i (give or take?) they certainly co-opted the responsibility to deal with changes of a structural (that is, "of type 'b'") nature. Dynamically typing, weakening of type systems, writing to an 'duck typing'), serializing via the Protobufs methodology, etc are all just band-aids; we need a surgeon to go in there with some surgical sutures.
