Requirements to ERD Entities, Attributes and Relationships

[DanaMaxwell]

I am creating a conceptual data model using the ERD Diagram and would like to relate the ERD model elements back to the requirements. For entities and attributes I have simply dragged a copy of the object into the requirements diagram and then created an "Implements" relationship from the object to the requirement.

I would also like to do this where the relationship between to entities will implement the requirement but I do not know how/where to have a relationship to a relationship in this manner. I could create the foreign key attribute that will eventually represent this relationship but I do not feel this is appropriate in my conceptual data model.

This is an effort to make sure I have complete coverage of my requirements with my data model.

Any advice is greatly appreciated.

[qwerty]

Phew. Going directly from requirements to a data model is like having the cake from the flour on the table. Requirements -> Use Cases -> Conecptional Class Model -> Concrete Class Model/Data Model would be the way to go.

q.

[Paolo F Cantoni]

Hi Dana,

In later versions of EA, you can create relationships between relationships and objects and between relationships.  That should allow you to relate the inter-entity relationship to the requirement object.

As qwerty said, it's best to have the conceptual backing for the relationship, but you can mark the relationship as derived (implying the backing).

HTH,
Paolo

[DanaMaxwell]

Phew. Going directly from requirements to a data model is like having the cake from the flour on the table. Requirements -> Use Cases -> Conecptional Class Model -> Concrete Class Model/Data Model would be the way to go.

q.

In this case, the customer has provided a specification of what data is to be in the database. This task is to simply produce a conceptual data model representation of that specification and the tracing to requirements (specification) is to make sure I have full coverage.

I am curious about "Conceptual Class Model" versus ERD Diagrams in EA. In the past, I have done my data modelling in Class Models but coming back to the tool after about 5 years I discover the ERD Diagram feature. To be honest, I am not quite sold on the ERD Diagram yet. Is there a good resource on the pros and cons of each approach and when/why to choose one over the other?

[Geert Bellekens]

ERD is not part of UML and mainly focused on data modelling.
I suppose mostly with the intent to be implemented as a relational database.

UML Class diagrams have a much wider scope and are used for all kinds of different things, including data modelling.

I prefer class diagrams.

Geert

[DanaMaxwell]

ERD is not part of UML and mainly focused on data modelling.
I suppose mostly with the intent to be implemented as a relational database.

UML Class diagrams have a much wider scope and are used for all kinds of different things, including data modelling.

I prefer class diagrams.

Geert

Understood and I think I agree. I had assumed that the ERD Diagramming was a simple extension/specialization of the Class Diagram that would use a more traditional "crow's foot" ERD notation. Making the diagram easier to read for traditional data modelers. I was surprised to see ERD Attributes as a separate object.

[Geert Bellekens]

If you want the crows foot notation you can simply switch that on on the diagram properties | Connector | Connector Notation
Set it to Information Engineering for crows foot.

It doesn't change anything to the model, only to the way it is displayed on this diagram.

Geert

[DanaMaxwell]

Thanks!

 

[Richard Freggi]

Hello Dana

A ERD is simply a class diagram with a specific profile (Crow's foot notation, stereotypes for primary/foreign keys, triggers and constraints are represented as operations etc.)  Anything you can do with a ERD you can also do with a class diagram (there's whole books on this subject on Amazon).

I remember years back the OMG looking into requests to adopt ERDs and concluding that UML already has full capability to do what ERDs do, so nothing to be gained.  The main issue is programmers proficient in UML not liking data modelers proficient in ERD and very much vice versa (look up "object impedance").

Anyways a data model (in whatever notation, class diagram or ERD) is an excellent way to capture requirements because you can efficiently and precisely rationalize key concepts (entities and attributes), business rules (relationships and cardinality; also datatypes and domain checks) and other qualities into one simple model that can summarize hundreds of different requirements from dozens of business processes and IT systems. 

The best way to learn how to do it is to pick a methodology and practice, practice practice.  Most methodologies recommend PLAIN TEXT to capture requirements, then transfer the text to comments on said entities, attributes and relationships.  Sparx tagged values and CSV import/export make this very convenient. 

Good luck!

Phew. Going directly from requirements to a data model is like having the cake from the flour on the table. Requirements -> Use Cases -> Conecptional Class Model -> Concrete Class Model/Data Model would be the way to go.

q.

In this case, the customer has provided a specification of what data is to be in the database. This task is to simply produce a conceptual data model representation of that specification and the tracing to requirements (specification) is to make sure I have full coverage.

I am curious about "Conceptual Class Model" versus ERD Diagrams in EA. In the past, I have done my data modelling in Class Models but coming back to the tool after about 5 years I discover the ERD Diagram feature. To be honest, I am not quite sold on the ERD Diagram yet. Is there a good resource on the pros and cons of each approach and when/why to choose one over the other?

[qwerty]

A ERD is simply a class diagram with a specific profile (Crow's foot notation, stereotypes for primary/foreign keys, triggers and constraints are represented as operations etc.)  Anything you can do with a ERD you can also do with a class diagram (there's whole books on this subject on Amazon).

That's not quite true. ERD is elder than UML (at least the UML we use now). But UML can mimic ERD by means of a profile.

q.

[philchudley]

There is an ERD MDG in EA which can be a bit confusing since this is not the "Crows Feet" notation closely related to UML class diagrams

Rather this is Chen ERD, whereby Entities Attributes and even Relationships are represented by elements. In Chen ERD you can model attributes as candidate keys, multi-valued attributes and structural attributes. Attributes are related to an Entity via a connector.

Relationships, represented as a diamond are used together with connectors to relate Entities in binary or n-ary relationships. You even define so called "weak entities" where a candidate key can not be identified.

As elements are used for Entities, Attributes and Relationships it is very easy via the relationship matrix to maintain traceability to requirements and other model elements.

EA has MDA from Chen ERD to Physical Model and vice versa

So what's the downside, well with all these elements a conceptual data model modelled in Chen ERD does take a vast amount of space, but I suppose this model could be spread over a number of "views"

Chen ERD does not appear to be well known, or indeed used very much.

This link will provide more details

https://www.conceptdraw.com/examples/what-is-chen-notation

Ignore the fact that this link is for a drawing tool, but it does provide a good overview of Chen ERD

Phil

[Richard Freggi]

A ERD is simply a class diagram with a specific profile (Crow's foot notation, stereotypes for primary/foreign keys, triggers and constraints are represented as operations etc.)  Anything you can do with a ERD you can also do with a class diagram (there's whole books on this subject on Amazon).

That's not quite true. ERD is elder than UML (at least the UML we use now). But UML can mimic ERD by means of a profile.

q.

Hi qwerty, so seems like you agree with what I posted, and do I sense a bit of impedance today?

[qwerty]

Yes, I agree. It's just dating those two instruments where you use the wrong order.

q.

[Erlenmeyer]

diagram properties | Connector | Connector Notation

I don't see this option in "Diagram Properties."  I am using R14.
My data modeler refuses to use Sparx due to the way relationships are represented. He wants crows feet. He downloaded Oracle data modeler and is happy.
Doesn't make me feel good about the $2K we spent on Sparx licenses.

[qwerty]

EA is not a database modeling tool. It's just a "me too" functionality of an UML modeling tool. If you need a hammer don't buy a pair of pliers.

q.