I am currently working on entity relationship diagram for a database and in that, there's an account and that account A and that can be of types say A1, A2, A3, A4, A5. Initially all of them are of type A and can be converted to A1 or A2 or A3 or A4 or A5 depending on the user's choice after verification.
I know about ternary relationships but here, I have more than 3 entities. How should I create a relationship among the 6 entities: A, A1, A2, A3, A4, A5?
Suggest me some ideas or provide me some reference I can refer to. I read a few articles but couldn't find any leads. Thanks.
In short
Yes you can, but not in all notations and it's not a good idea for your needs.
More arguments
It's possible
Peter Pin-Shan Chen, the inventor of E/R modelling has defined in one of his foundational papers that relationships can relate more than two entities:
Entities are related to each other. Different types of relationships may exist between different types of entities. A relationship set is a set of relationships of the same type. For example, PROJLEMP, which describes the assignment of employees to projects, is a relationship set defined on two entity sets, EMP and PROJ. A relationship set can also be defined on more than two entity sets. For example, PROJ_SUPP_PART is a relationship set defined on three entity sets PROJ, SUPP , and PART. In the entity-relationship diagram, a relationship set is rep- resented by a diamond-shaped box with lines connecting to the related entity sets.
But not without complications
However this comes with two practical constraints:
Not all notations support it: The Chen notation uses a special symbol for relationship and supports this theory. Unfortunately, the more frequent Crow's foot notation for ERD doe not support n-ary relationships, since each relationship is represented by a line that has only two ends.
It's ambiguous in your case: Chen notation allows to distinguish for the entities on total (must) or partial (can) participation to a relationship. Unfortunately, this becomes ambiguous with more than one partial participation in a relationship. Moreover, there would be no way to say that an A has a relationship with only one of the A1...A5 and not several at the same time
A simpler solution
A simpler solution, would be to put all the common attributes into A, and leave in A1.. A5 only the additional attributes. You would then represent the relation ship between A and An as a weak one, with a partial participation of An.
The advantatge is that you can represent this in every notation and that it's simple and unambiguous to read. It wouldn't prevent multiple relationships, so you would have to add a comment to clarify.
A sophisticated solution
Another approach is to reach out for EERD notation, and realise that A1..An are specialisations of A. You would represent this with an IsA relationship. The advantage is that it is loyal to your design and clearly explains what you mean in your narrative.
There are however several inconveniences:
Not all modelling tools support EERD.
EERD is not standardized, and there are in fact several variations. A more robust choice would be to opt for UML class-diagrams that are standardized and support unambiguously the different solutions exposed here.
Finally, RDBMS do not support IsA. So you would have your conceptual model fine but still have to map it to database tables outside of the model using one of the typical three patterns (single table, class table, and concrete class table).
Related
I'm currently studying software engineering patterns and one that we've been given to study is the "historical association pattern" It refers to the historical mapping pattern given in Fowler's "Analysis patterns" book. The example we've been given is as follows:
I've tried looking for information online on how this structure would be implemented but I've found nothing regarding historical mapping associations. What would be a code/pseudo-code example of this structure?
Short answer
This pattern consist simply of using some dates for an association, by the means of an association class.
Full explanation
The diamond in the middle is a ternary association between Employee, Date and Money. The dotted line says that the Salary is the association class and it is also associated with a Date.
The association class would be typically be implemented with tuples/composed classes of Employee, Date, Money and the Salary attributes. The way it is done can be very different: in Java you’d directly refer to the associated objects, whereas in a db you’d have a mix of ids and salary attributes. Much simpler than this impressive diagram.
There are simpler models for that!
This diagram is difficult to read (ternary association), difficult to understand (multiplicity in ternary associations are not obvious to grasp), ambiguous (i.e. is Salary associated with two dates, from the ternary association it represents and from the direct association? or is it just a graphical redundancy?).
It would be much simpler to understand if it would be refactored into a binary association, and if value objects such as Dare would be shown as attributes.
I have short question about class diagrams. In my book we have class Person and class Gender and agregation arrow between them(with diamond pointing to person). Now, in general when I want to decide whether we have agregation or not I am using one of these two rules:
1.When you destroy class that is whole, than part can exist without it;
2.Class that is part in agregation relation, can be mutual to one or more wholes.
Now if we look at this example and rule number 2, it is OK, because one gender is mutual to one or more persons. But for the first one, if there is not person, than we can't talk about gender right?So I would set composition here. Probably I am missing main difference between these two. Any help is appriciated.
In general
Your rule about when using aggregation is not wrong. But it's unnecessarily complex. There is a simpler much simpler rule about when you'd better use aggregation: never.
This may sound provocative, but the hard truth is that the meaning of aggregation is not defined in the UML specifications, which makes it ambiguous and subject to a lot of unnecessary time-consuming debates:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. (...) Precise semantics of shared aggregation varies by application area and modeler.- UML specifications 2.5.1, page 112.
I know, it comes as a shock. For years in my career, I have myself selected very carefully aggregation whenever there was a part-whole relation with non-exclusive ownership. But when I came accross James Rumbaugh famous quote, I challenged my own assumptions and realized how vain and subjective this quest was:
Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.- James Rumbaugh in Unified Modeling Language Reference Manual, chapter 14.
So, whenever you have aggregation in a model, you could simply replace it with an association without real loss of information.
In your specific example
The association: Person ----- Gender expresses perfectly that a person has a gender, and that several persons can share the same gender.
If you want to be super-accurate, you could use the dot notation (with a small dot on Gender side). This would convey the information that Person owns the end of the association.
Composition would definitely be wrong here, because it's an exclusive ownership and no two persons could share the same gender.
Aggregation is ambigous: what is the whole, what is the part? If gender is a part, wouldn't character be a part as well. And what with the name, then ?
A final remark: if you want to implement this with Person having a gender:Gender property (an OOP mechanism called "object composition") the, you don't need aggregation (even if it's a popular practice).
I'm taking the Stanford edx course (Databases: Modeling and theory) and the lecturer mentioned this piece of information about association classes and what they imply in a diagram (in reference to an example of two classes "student" and "college" associated by a "applies to" association with the association class "appInfo" containing college application info):
Now what we're saying is that association is going to have affiliated with it a date and a decision. What we cannot describe in UML is the possibility of having more than one relationship or association between the same student and the same college.
So when we have an association, that assumes at most one relationship between two objects. So, for example, if we wanted to add the possibility that students could apply to the same college multiple times so maybe, you know, they wanted to apply for different majors, that would actually have to be captured quite differently. We'd have to add a separate class for the application information with separate relationships to the students and colleges.
but I didn't really get what she meant here, does having an association class create an automatic 1-1 coupling between two classes? or is it prohibited for two classes to have more than one relationship? or what exactly is being said here because it's a bit vague and I'm not experienced in UML data modeling.
The statement is either wrong or it’s taken out of a specific context that was not mentioned here. The reasons are:
there is no implicit one-to-one in an association; the multiplicities at both end of an association specifies if it’s a one to one, a one to many, a many to many association or anything in between.
the same applies to an association class, which is both: an association and a class at the same time.
in a many to many association, there can very well be several times a link between the same objects. In fact, in a one-to-many or many-to-many association, you need to add an explicit constraint if you want to avoid this.
More information:
in this other answer, there are some more explanation about the semantic of association classes
an here a question related to uniqueness. as you will see, it is not that obvious to avoid multiple occurrences
I want to model an airport and a city and would like to choose the appropriate decomposition relationship between the two but I cant seem to make up my mind which one to choose as they both have different relationships.
A City can exist on its own and does not require an airport hence I would say that City-Airport link is an aggregation however...
An Airport requires a City and will not exists without one making it a Composition relationship.
Is it possible to have two relationships? One which is City -> Airport and the other being Airport -> City it does feel strange however since a Composition to me feels like a relationship which should be honoured by two people and not just one.
It's a widespread misunderstanding that the relationships between classes are primarily either "aggregations" or "compositions". I think this unfortunate tradition has been extablished in the C++ community.
Rather, the most important kind of relationships between classes are "associations", as they are called in UML class models/diagrams. So, if you want to model the relationship between Cityand Airport, you probably want to choose a one-to-many association (since a city may have more than one airport, but any airport is assigned to a city).
In UML, both aggregations and compositions are special cases of associations, used for expressing a part-whole relationship between the instances of both classes. Since an airport is not really a part of a city, but just related to it, there is neither a Composition nor an Aggregation between Cityand Airport, but just a plain Association.
In many cases, where we may wonder if an association is a composition, it is safer to model it as a plain association.
The only good reason for modeling an association as a composition is when the instances of the component type are "weak entities" not having their own identity (object ID). But airports do have their own ID, so there is no need, and no gain, to model them as components of a city.
I found a definition for association in UML as below.
An "association" in UML is defined as a kind of relationship between
classes,which represents the semantic relationship between two or more classes that
involves connections (links) among their instances .
I am not clear what is semantic relationship. Can anyone explain it with example with comparing it with non semantic relationship?
Associations in plain text
An association is a semantic relationship. The UML clause means that there is a structural relationship between instances of the associated classes independently of any specific implementation. "Semantic" underlines that the relationship is between the instances themselves, and not just "accidentally" for an operation:
Use associations primarily where there are structural relationships among objects. Do not use them to show transient relationships such as parameters or local variables of procedures.- Booch, Rumbaugh & Jacobson in Unified Modeling Language User Guide, 2nd edition
More arguments
What is "semantic"?
The term "semantic" is borrowed from linguistics and refers to the meanings behind the words. Linguists and map words (e.g. "Car", "Driver") to their meaning (e.g. a real car, a real person), and analyze the relation between words with a view of this mapping:
So, applying this to UML (modelling language) if you'd have the classes Car and Driver, you CAN model the semantic relationship as an association between the two classes.
What is not semantic?
Not all relationships are of semantic nature. You can have dependencies, which can express a technical relationship:
a transient relationship during an operation: with a factory pattern for example, a DriverFactory would «create» a Driver instance. Both instances the factory and the driver are related only at the exact moment of the creation operation. But the two instances are completely independent the nanosecond after.The same applies if the implementation of an operation needs to create a local instance of another class. Both classes are not associated, since we could imagine another implementation that works without such an instance.
a structural dependency: Maybe an operation require some other classes as parameter. Since the parameters themselves are transient, there is no association. But nevertheless, teh class needs to know about the other class.
For the records, I'm grateful to this public domain contributor for the nice car and driver and to 18f for advice on inclusive communication.
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
A model says something about the things being modeled. This is its semantics. Almost all elements of UML have semantics, defined in the sections titled "semantics". One exception is the comment. Adding a comment to a model doesn't influence its meaning.
Then why does the UML say this explicitely about associations? The reason is, that an association may or may not say something about the structure. If it doesn't, it is purely semantic.
For example it could tell us, that a Car can have at most one Driver. It doesn't necessarily mean that the car has an attribute of type Driver.
If we want to model that the two associated classes own attributes typed by the other end of the association, the notation will show this by small dots on its ends. Many people are not familiar with this notation and interpret associations without a dot in the same way. However, without the dots attributes are owned by the association itself and the structure of the classes is not influenced.
By the way, a class being the type of a parameter of an operation or having a dependency also means a semantic relationship.