Logical data models would contain a more complete list of attributes since they are created at the design stage. "Pure" conceptual models are not supposed to have any attributes, however, I find including 2-3 key attributes is helpful to the audience. Business stakeholders understand conceptual models better when they examples of the attributes that "belong" to each entity. So I would always support adding to the model anything that helps improve understanding and communication - this is the ultimate goal, isn't it?
@@RomanRaspopov If I was your client and you gave me a conceptual model without any attributes or cardinality and it was just 20 entity names with lines drawn between them - I'd probably say something like, "You may as well have used crayons on a piece of paper". Then I'd hire someone else.
You don't have to exhaustively list all the fields. However, if adding a couple of attributes helps the stakeholders to understand the model better, there is no harm in it. If this model is used as a communication tool, then we should be comfortable adding something extra to support the communication goals. this is very helpful with abstract concepts such as Account, Order, or ResortStatistics. What do you think?
@@shilashm5691 I am stretching the conceptual model just a bit as it will be more effective if it also highlights one-to-many relationships. This is the most frequent and painful requirements gap when analyzing business data.
This presentation is completely wrong. It is NOT Conceptual Modelling, it is Logical Modelling. Conceptual Modelling is based on business concepts and its fundamental feature is to reveal the essence of how a business works. There is NO SIGNIFICATION here of the numerosity of entities. The goal was to model any Ski Resort, a business that provides winter recreational opportunities. To avoid unnecessary "discussion" below, here is a list of the logical elements of the above model that are not part of the Conceptual Model: SkiResort : it is the object of the model, it is described by the model, so it is not a business entity per se. Instead, it should have been the LOCATION entity. ResortStatistics : what "concept" is represented by "statistics"... ? None. LiftTicket : ...and what about the rope of the elevator ... ? That is part of the ascent, isn't it ? :-) No, it's not an Entity in its own right, but at most it's just a tool or part of the TRANSPORTATION entity ( which is very much missing from the model ! ). Here is the real model elements, the list of (business) entities, without their relationships ( this interface is not suitable to display them ) : LOCATION ( ...Ski Resort... ) STATION (...Summit... ) RUN TRANSPORTATION ( ...Lift...) USAGE POLICY (...Statistics, etc. ) SERVICE (...Lift ticket, etc. ... )
![ARGENTINA vs. CHILE [3-0] | RESUMEN | ELIMINATORIAS SUDAMERICANAS | FECHA 7](http://i.ytimg.com/vi/De3AWmXzhuA/mqdefault.jpg)
I think this is a logical data model. Conceptual, would be the same but without attributes. Not sure though, depends on how it is defined.
Logical data models would contain a more complete list of attributes since they are created at the design stage. "Pure" conceptual models are not supposed to have any attributes, however, I find including 2-3 key attributes is helpful to the audience. Business stakeholders understand conceptual models better when they examples of the attributes that "belong" to each entity. So I would always support adding to the model anything that helps improve understanding and communication - this is the ultimate goal, isn't it?
Absoluetely right. Conceptual model is much simpler. This is logical model in the video.
@@RomanRaspopov If I was your client and you gave me a conceptual model without any attributes or cardinality and it was just 20 entity names with lines drawn between them - I'd probably say something like, "You may as well have used crayons on a piece of paper". Then I'd hire someone else.
@@AnnoyingUT3Player That is exactly what the conceptual model is designed for. A sketch on a paper is nice comparison.
@@AnnoyingUT3Player You should have asked for a logical model if you wanted something with lots of detail on then.
Great example! Thank you.
You are welcome!
Nicely explained. Thanks for the video.
Thank you!
For more in-depth practice and BA skills, check out my courses: courses.why-change.com/
In the conceptual model, you don't state the fields, columns.
You don't have to exhaustively list all the fields. However, if adding a couple of attributes helps the stakeholders to understand the model better, there is no harm in it. If this model is used as a communication tool, then we should be comfortable adding something extra to support the communication goals. this is very helpful with abstract concepts such as Account, Order, or ResortStatistics. What do you think?
@@WhyChangebut why do you add a cross foot notation, it is not needed in conceptual model
@@shilashm5691 I am stretching the conceptual model just a bit as it will be more effective if it also highlights one-to-many relationships. This is the most frequent and painful requirements gap when analyzing business data.
@@WhyChange thanks for the reply, do we actually create all 3 data models while developing the project
This presentation is completely wrong. It is NOT Conceptual Modelling, it is Logical Modelling. Conceptual Modelling is based on business concepts and its fundamental feature is to reveal the essence of how a business works. There is NO SIGNIFICATION here of the numerosity of entities.
The goal was to model any Ski Resort, a business that provides winter recreational opportunities.
To avoid unnecessary "discussion" below, here is a list of the logical elements of the above model that are not part of the Conceptual Model:
SkiResort : it is the object of the model, it is described by the model, so it is not a business entity per se. Instead, it should have been the LOCATION entity.
ResortStatistics : what "concept" is represented by "statistics"... ? None.
LiftTicket : ...and what about the rope of the elevator ... ? That is part of the ascent, isn't it ? :-) No, it's not an Entity in its own right, but at most it's just a tool or part of the TRANSPORTATION entity ( which is very much missing from the model ! ).
Here is the real model elements, the list of (business) entities, without their relationships ( this interface is not suitable to display them ) :
LOCATION ( ...Ski Resort... )
STATION (...Summit... )
RUN
TRANSPORTATION ( ...Lift...)
USAGE POLICY (...Statistics, etc. )
SERVICE (...Lift ticket, etc. ... )
Excellent clarification. While these videos have good intentions, they are very harmful to people who are in the process of learning the concepts.