Here is how the Referential Integrity Constraints are defined and managed in the Entity Framework.
It is defined in the CSDL file (conceptual schema).
I really appreciate the fact associations are defined outside entities. That is probably the best way of doing it. I still don't understand why (most industrial) object languages don't have a real management of relationships.
One of the key new features of Java or C# would be to have a better relationship management in the future. Basically, a reference in Java is nothing more than a wrapper around a memory pointer. And a collection is just a set of references. Nothing more, there is no notion of what is at the other side, and no relationship management.
Even more dynamic languages like Smalltalk or Groovy still don't have that good relationship management.
That said, even in database engines the notion of relationship management is still limited. Yes, you can define FK and associate some behaviour, but all that is still limited. We need much more. We need to be able to fully qualify both sides of the association (cardinality, navigation...) and later use that information at runtime to optimize queries. We need to be able to distinguish between aggregations and compositions. And we must be able to define Referential Integrity Constraints to something which is not in the same database.
All this maybe means that relationship management should be covered by the Data Services Platform. And even like that we still need a better notion of relationship within programming languages.