• Bear in mind that ERDs may be created for different purposes. Sometimes the purpose of an ERD is A: to model the Universe of Discourse. Sometimes the purpose is B: to represent what should be or is being implemented in the database. People who use ERDs often refer to A as a conceptual or logical ERD and B as a physical ERD.

    The declarative constraints existing in Microsoft SQL Server are not capable of implementing every commonly occurring business rule (i.e. the rules intended to ensure the UoD is modelled accurately). Some of the constraints specified or implied by an ERD therefore might not be implemented. Some constraints might be implemented but only as procedural code (e.g. triggers) and some might be impossible or impractical to implement in the database at all. Implementing business rules in a DBMS (SQL ones generally, not just SQL Server) is always a compromise and quite often more integrity rules have to be left out than are put in.

    Oracle has more referential integrity options than SQL Server has (e.g. deferred constraints, full/parial matching). Also the semantics of nullable uniqueness constraints in Oracle are different to SQL Server, which also means the semantics of RI constraints referencing those uniqueness constraints can be different too. So someone with an Oracle background might think it worth putting certain constraints into his ERD and only later find that they cannot be implemented in SQL Server in the way the model described.