The concepts behind Data-Oriented programming

For example, that you can specify that a reference to a component of a compound value enforces that that component cannot be removed. Or, that you can specify (the other way around) that whenever the referenced component is removed, the component the reference is part of, should also be removed. The latter often happens if you have some kind of relationship. In some database, these kind of dependencies can be implemented by means of cascade delete triggers. (I prefer to talk about components rather than objects, because the word object suggest that the thing in itself exists independently of other objects, while in data this is often not the case.) I find it a little sad, that in many object oriented methods (including UML) the substype relation plays a more significant role than the existence relationships. I do not know of programming languages where existence relationship can be explicitly declared. Of course, there are a lot of programming languages that allow you to implement these kind of relationships, but it is often easy to make mistakes. And, in my experience, these kind of mistakes are a source of obscure and hard to find bugs.