Does an ERD prescribe an implementation approach?

Question

One of the things that confuses me about ERDs is whether they make any prescriptions about how their relationships should be implemented technologically.

In the diagram below I'm not sure if the diagram requires these relationships to be implemented at the database level or at the application level.

Is it making any technological prescriptions or simply defining the relationship and leaving it up to me to decide how to implement it?

Would I need to have more information from the creator of the ERD before building something that is based upon it?

Answer 1

An ERD is not a "technological prescription" as you put it but simply a representation of logical relationships.

How you implement it - in the database or the application - is up to you.

But the database is the appropriate place to enforce these relationships.

Answer 2

It seems that you are turning the problem upside down.

The answer is of course: no, there is nothing that will force you to create relationships in the database. But why would you not do that?

That's why the database is called relational database - because it offers you a solution for this very question that is readily available, well integrated with tools and persistence layers, and it's consequences for application developers are well understood.

It would be crazy not to implement relationships at the database level.

Answer 3

An ERD diagram is a logical diagram that shows entity relationships and their cardinality although it can interpreted as a table relationship diagram or a class diagram at the same time yet it is neither of them and you will still need the other diagrams.

BTW,as far as I know it is always good to have enforced relationships in your database model to maintain database consistency.

Answer 4

I would say be as redundant as possible when it comes to validating data being put into your database.

Do checks on the app side to ensure that Uniquness/data type validity is all alright. And structure the database to have all the relationships it needs.

Don't just let the database/application assume that everything is correct.

This may save you several hours of fixing orphaned records and consistancy issues.

Answer 5

"Is it making any technological prescriptions ..."

It doesn't look like code. Perhaps I'm missing something.

"or simply defining the relationship and leaving it up to me to decide how to implement it?"

That depends on your customer.

If they think the diagram is isomorphic to code, then you'll have to understand the missing pieces from convention or context.

If they don't think the diagram is isomorphic to code, then you'll have to decide how to implement it.