I'm wondering if my textbook has a non-standard definition. I've red this question and it is not a duplicate. The book defines entities and entity sets as
An entity is an abstract object of some sort, and a collection of
similar entities forms an entity set. An entity is some ways resembles
an "object" in the sense of object-oriented programing. Likewise, an entity set bears some
resemblance to a class of objects.
When they say "class of objects" are they referring to a class as in the thing you instantiate to make new objects (I know this is just a loose comparison). It sounds like an entity set is more general than just an entity, but in this question a reply states "An entity set usually represents a slice of an entities data" which is the opposite.
I thought an entity is like a table in a database, then what's an entity set?
An entity is a real world object such as a person, a place or a thing or an abstract object such as a course, a flight reservation, etc. Here we use article 'a' or 'an' to indicate an instance of a specific person, a specific place or a specific thing as an entity. For example, I, by name 'Vidyasagar' is an entity and you are also an entity. All similar entities form entity set. Similar means each entity has the same (for simplicity) properties. All person entities will have same properties such as first name, middle name, last name, date of birth, etc. Entity and entity sets are analogous to relational database terms row/tuple and table/relation repectively. These are also analogous to OOPS terminology of objects and collection of objects respectively.
Obviously we can not store real world entities such as persons, toys, cities, etc., in a database! We can store only data about real world entities. The data consists of values for each property of entities. For example, data for city entities could be 'London' and 'UK' for London city entity, 'Paris' and 'France' for Paris city entity and 'Bangalore' and 'India' for Bangalore city entity. We use values of one or more properties (key) to refer to an entity for convenience. Hence when we say Paris entity, we mean the city Paris which is in France. That is we are referring to the pair of values Paris and France. The pair of values together is an entity. The three entities are ('London', 'UK'), ('Paris', 'France') and ('Bangalore', 'India'). There is no significance to parentheses used as such. These three entities will form an entity set, say, CITIES. Hope this is clear.
The definiton in your textbook in my opinion is not so clear. I find it very confusing.
I think you should stop at the first part of the definition:
An entity is an abstract object of some sort, and a collection of similar entities forms an entity set.
A set is simply a collection, a group of these entities. Usually the type of these entities is the same, so I suppose that saying:
an entity set bears some resemblance to a class of objects.
it means that objects in this collection/set are instance of the same class.
An entity is an abstract object of some sort, and a collection of similar entities forms an entity set. An entity is some ways resembles an "object" in the sense of object-oriented programing. Likewise, an entity set bears some resemblance to a class of objects
Related
Do people often use the word "entity" to refer to what will latter become a table? If yes, isn't this technically incorrect because it's the entity sets that typically become tables?
It seems to me that often times people say entity when they mean entity set. When I see a square on a diagram, that actually represents an entity set right? For example if there were a square that said movies that wouldn't be one particular movie (like an entity) but a collection of movies (entity set), right?
For example this is the first website that came up on Google when I typed in E/R diagram tutorial and it claims that squares represents entities, which is technically wrong.
The E/R diagram wording is in the singular - e.g. 'A teacher teaches a class'.
So there would be a rectangle for 'teacher', a rectangle for 'class' and a diamond for 'teaches'.
However strictly speaking, yes, the modelling is of the sets, and is translated to tables such that 'teacher' is the table (set) of 'teachers' and 'class' is the table (set) of 'classes' and depending on the cardinality, the 'teaches' would probably be a 'teacher-class' table
In the question I'm doing at the moment gave two confusing sentences:
1. A property can be either be a house or an apartment. For a house it records ..bula bula
For an apartment, it records .. bula bula
2. A property can be either for sale or rent, or for both. If a property is for sale, it
records .. bula bula. If the property is for rent, it records .. bula bula
These two are in the same question. Do I have to represent it by using subclasses or how?
Many thanks.
Yes, a entity can have multiple subclasses and multiple superclasses. Both faculty staff and student assistants may be subclasses of employees, and a student assistant may be a subclass of both employees and students.
You can create a Property entity with four subclasses, House, Appartment, PropertyForRent and PropertyForSale.
A property may not be both a house and an appartment. Therefore, use a circle with a d in it to indicate that it is disjoint. A property may be both for rent and for sale. Use a circle with an o in it to indicate that it may overlap.
This is described on page 443 in Advanced Data Modelling, and another example can be found on page 30 of this presentation.
Sjoerd's answer is correct.
ER modeling tells you how to diagram subclasses, but it doesn't tell you how to implement them. Nor should it.
If you are interested in designing SQL tables that implement subclasses, look up these topics, or their tags in SO:
Single Table Inheritance
Class Table Inheritance
Shared Primary Key
I understand the difference between aggregation and composition but I am struggling a bit with association. My current understanding is that an association exists between classes when ‘they use each other’, for example, one object is passed to the other during a method call. See also:
http://www.codeproject.com/Articles/330447/Understanding-Association-Aggregation-and-Composit
Both objects exist independently and, in contrast to aggregation, no object is a container class of the other. Does this mean that both objects MUST have a copy of the other(s) (e.g. 1:m relationship) or how else is the association ‘stored’. Any feedback would be very much appreciated.
From the UML Superstructure 2.4.1:
An association declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end. (UML Superstructure, Page 37)
Nothing more, nothing less. and very vague. Because of this, it is also very hard to understand. What I defined (In a course I teach) is a hierarchy of links from dependency to composition where:
Dependency from A to B means that A uses B but indirectly (say by receiving instances of it and forwarding them to other objects).
Association from A to B means that A uses B directly, (for example by calling methods)
Aggregation from A to B means that B is part of A (semantically) but B can be shared and if A is deleted, B is not deleted. Note that this says nothing about how the "is part" is implemented.
Composition from A to B is like Aggregation, where B cannot be shared and if A is deleted, all of its aggregates (Bs) are deleted also.
Aggregation is an Association relationship where the Association can be considered the containing class 'Owning' the contained class, and the lifetime of that relationship is not defined.
Association is an 'Has-A' relationship.
Example:-
public class Person
{
private final Name name;
private Address currentAddress;
//...
}
In this case, the Person Has-A name and Has-A Address, so there is an Association between Person and Name, and Person and Address.
An association describes a relationship between instances of one or more classes. In the words of the UML Reference Manual, "Associations are the glue that holds together a system."
Aggregation is a form of association in which there is a "whole-part" relationship. You may say that if a class Airplane has a class Engine then this forms a "whole-part" relationship.
Aggregation
Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. Too often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you meant you understand "shared aggregation and composition".
From UML standard:
Precise semantics of shared aggregation varies by application area and
modeler.
I haven't found a word about that aggregation supposed multiplicity, for example.
Association.
A definition from UML 3.4.1 standard:
An association describes a set of tuples whose values refer to typed
instances. An instance of an association is called a link. A link is a
tuple with one value for each end of the association, where each value
is an instance of the type of the end.
Aggregated relationship is a subclass of Association.
Association is based on relationship. IT is the glue for models.
But your feelings didn't lie - as the shared aggregation is not strictly defined, there is also NO any strictly defined boundary between Association and Aggregated association. Authors of tools and modellers have to set it themselves.
Association
It represents a relationship between two or more objects where all objects have their own lifecycle and there is no owner. The name of an association specifies the nature of relationship between objects. This is represented by a solid line.
Let’s take an example of relationship between Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers. But there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
Aggregation
It is a specialized form of Association where all object have their own lifecycle but there is ownership. This represents “whole-part or a-part-of” relationship. This is represented by a hollow diamond followed by a line.
Let’s take an example of relationship between Department and Teacher. A Teacher may belongs to multiple departments. Hence Teacher is a part of multiple departments. But if we delete a Department, Teacher Object will not destroy.
It depends on the context.
Association: A man drives a car, focus on the caller and callee relationship.
Aggregation: A man has a car, focus on the owner and member relationship.
Composition: A man has a mouth, focus on the owner & member but the owner consists of members, it means that they shared the same life cycle.
Feels like I'm speaking Chinglish.
Association
Association is a relationship where all objects have their own life-cycle and there is no owner. Let’s take the example of Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers but there is no ownership between the objects and both have their own life-cycle. Both can create and delete independently.
Aggregation
the objects in Aggregation have their own life-cycle but there is ownership. Child object can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about the “has-a” relationship.
Composition
It is a strong type of Aggregation. Child object does not have their life-cycle and if parent object deletes all child object will also be deleted. Let’s take again an example of the relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different houses if we delete the house room will automatically delete.
An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown below, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.
See also my alternative CodeProject article.
Let's say I have the typical entity Car
class Car : Entity
{
public double MaxSpeed { get; set; }
public Color Color { get; set; }
/* ... */
}
This entity, in my domain model, would be the root entity of an Aggregate.
Now let's say I specialize cars. I create a Ferrari, and the happy owners of Ferraris like to call them by a nickname:
class Ferrari : Car
{
public string Nickname { get; set; }
}
Let's say I have another entity, the Company entity. It would be the root entity of another Aggregate. There are many people working on a company, represented by the entity Person. Persons may have cars. But the President of a company is usually very rich and this kind of people, they have Ferraris:
class President : Person
{
public Ferrari Ferrari { get; set; }
}
In this situation, I have the entity President, who is inside the Company Aggregate, that is holding a reference to a Ferrari, an specialization of the root entity of another aggregate.
Is this correct in view of DDD? Can/should I consider the specialization of root entities themselves as root entities of the same aggregate? I mean, in the domain I described, is the entity Ferrari also the root entity of the Car Aggregate (since Ferrari is also a Car)?
Now let's say I have to persist this model to a Database. I think that my question does not depend on the OR/M framework I will use.
How should I build the table holding Cars? Should I build a single table Cars, with a "CarType" column (possible values: "Car", "Ferrari"), and a nullable Nickname column?
Or should I build a table for Cars and a table for Ferraris, the latter one having its PK a FK of Cars?
Thanks!
Generally when you cross root aggregate boundaries you only allow the reference to be of the ID of the other root aggregate. You then use that ID to look up the other aggregate in its repository.
So in your case you would want President to have a Car ID and if you ever needed to do something to the President's car you would use the Car ID to go to the repository to get the car. President would not have a reference to the Car itself.
Now about that Ferrari. It's kind of difficult to enforce that in standard DDD terminology. Normally you would put some validation on the assignment of a Car to a President. Or perhaps there is a CarBuyingService just for Presidents that makes sure you get it right. Normally in DDD specializations are not themselves root aggregates.
You shouldn't use inheritance to model your domain because you will soon run into trouble once model starts to get complex.
President is simply a role of the person and person can have multiple roles. Maybe president got just one role but that's simply accidental by choosing wrong example.
Ferrari shouldn't be inherited from car either. It's not obvious on Ferrari example, because they only do one type of cars but consider company making many types like vans, sedans, hatchbacks, trucks and so on. You will probably want to make classes for every type that will inherit from car class. And then what... are you going to make five Toyota classes that will inherit from each type? Such as...
Car -> Sedan -> ToyotaSedan
Car -> Truck -> ToyotaTruck
Car -> Hatchback -> ToyotaHatchback
That would be ridiculous.
Disclaimer: I know nothing about about cars. However...
Don't use inheritance to model your domain. Ever.
Try it without inheritance and it will also became obvious how to persist your domain.
I think you start losing a lot of the flexibility of the system by creating concrete types of these entities. The type of relationship that you are implying is something I generally hand with a "Type" entity. For example, you have a car. A Ferrari is a type of car. The two entities that are borne from that are a Car and a CarType.
The way that you are talking about doing it, you would have to add new entities every time a new type is introduced. If all that you are trying to capture is the "nickname" of the car, I would think that is just another piece of data, and not another entity. Unless you have different data (i.e. different property names) and/or behavior differences in Car entities for different types, you do not gain much with this approach. I would rather have repository methods like FindCarByType() and deal with one type of entity, to reduce risk.
I am by no means a DDD expert, and I am struggling with some concepts (or more like struggling with the multiple interpretations of some concepts). I am finding that there is not a 100% pure implementation, and that there are nuances to each implementation that I have seen.
Edit Follows
I see that I misread part of what you had written. I see that nickname is not for all vehicles, but just for Ferrari : Car. I think that the answer is really "it depends". How much domain specialization do you have in the rest of your model? Having a nickname might be prevalent amongst Ferrari entities, but is it exclusive? It isn't only about the actual data, but the requirements. Basically it comes down to how much specialization your are expecting in these entities.
I'm using an ORM (SQLAlchemy, but my question is quite implementation-agnostic) to model a many-to-many relationship between a parent class and its children.. I was wondering, what would be a simple way to express the concept "one of the children is the default/main one"?
For example, I'd need to persist the following:
This Person instance has Address X and Y, the main one is Y.
I saw this implemented using a "middle" class like "PersonAddressRelation" that would contain "Person", "Address" and the "main" flag, but I think it looks a bit cumbersome.. Is there a better way?
The simplest way would be to have a join table, PersonAddressRelation, and also a DefaultAddress column on the Person table that keys to the Address table.
A couple of remarks.
M:N relationships don't specify 'parent' and 'child', as there's no parent nor a child: there are simply two entities having an m:n relationship via a 3rd entity (the intermediate entity).
'Address' is in general not a valid entity type, as semantically it has no identity, similar to a 'name' has no identity (first name, last name). You'll see this when you look at re-using an entity instance of type Address: you won't do that in general. (though you will re-use a Customer entity instance for example, when the customer has multiple orders)
You want to specify an attribute on the M:N relationship (default), as it belongs there. This means that the relationship itself forms an entity (which is the intermediate entity, often it has just two FK fields forming the PK). This is called an 'objectified relationship', as the relationship itself is seen as an entity. Other examples of this are Employee m:n Department and you want to specify the StartDate an employee started for a department the employee works for.
So in general: create the intermediate entity, as it in general should be there, and add the attribute there. In this particular case with Address, be really sure you are re-using Address instances among related entities (Person). If not, merge Address with Person OR if a person can have multiple addresses, create a simple 1:n relationship between Person - Address, to normalize it out, though don't be afraid to merge address data into the entity it is related to, as often address data is really not re-used (so your m:n relationship is really not there: there's no Address instance which is related to multiple person instances.