Say I have this ER Diagram:
How should I proceed when creating the classes? Should I create a Species class with a list of Breeds, or a Breed class with a Species attribute?
I don't know yet how the business logic will unfold, but I assume that I'll have to deal with both situations: I may have to retrieve a list of all Breeds belonging to a Species, or the Species to which a Breed belongs.
I know there is not a single answer to this, but any pointer in the right direction would be appreciated.
Related
So I am new in designing databases and I'm trying to represent a db diagram for a system where students can rate professors and school. Also Students and Professors can have their account to login.
Is this a proper presentation and am I missing anything as of entity relations ?
And I wasn't sure if i need to use any inheritance as well ..
Enumerated columns are good indication for bad design.
You need an additional table for values.
Once that done, there is no need to separate school rating from professor rating -
use a general rating table containning the id of the rater (which is always a student in your case) and the id and type (school/professor) of the rated element.
I don't see any reason to put students and professors in different tables.
Think of it as a person table with a role attribute.
If a person can be both, than instead of the role attribute add 2 flags columns - is_student and is_professor.
It looks okay but are you sure the relatioship between SchoolRating and Student should be many to many? Wouldn't a rating just have one student (the student who did the rating)?
Also it's not clear to me why SchoolRating and ProfessorRating have so many value attributes.
Initial Review: Seems solid, may require another table or an expansion of SchoolRating.
When you are designing, focus on what your objects accomplish, the questions of facts they answer.
SchoolRating has values that represent the reviews or are they aggregates of a set amount of teachers? How are these reviews rectified with professor rating...or do they have no relation? (They clearly do in a school...so how does your design accomplish this?)
Why does a student have any direct relation with SchoolRating? Should not this table be a true FACT table for the values scored from the professors and/or some rating system?
Why can a student not have multiple teachers or multiple reviews? If a student fails a class but leaves a review...how does your structure rectify a new review from the same student?
Lastly, do not use the inheritance theory in your relational design. It is utterly incompatible with the relational set theory and the sooner you learn to purge that from your system, the better.
Think on terms of DIMENSIONS and FACTS. Think about cardinality, or how you plan to deal with slowly changing dimmensions, whether database columns will provide efficiency.
Concepts like Star-Schema, Snowflake design, of durable keys, natural keys probably should be consulted whenever you question your design.
At the end of the day, what questions your tables can answer and how the system will access these tables are as important, if not more, to the design methodology as it relates to normalization.
Example : Having a human that can own 1 or more pets of different types (cat, dog, elephant, seal etc) .
I would think of making an aggregate that would have Human as root (that holds petCollection as reference to Pet) and another aggregate that would have Pet as root (with cat, dog, elephant, eagle as children for this aggregate) .
The problem is that each pet type can have different behaviour (example : a seal can swin() but it won't fly() / an eagle can fly() but it won't swim() ) . So a state or strategy pattern does not seem right . How can a human tell a pet object to run() if it doesn't know it's type ? Using the state/strategy pattern, the objects need to have similar behaviour . Doing an if/else (for the case of polymorphism to check the object type) check again , doesn't seem a proper design .
How should i design this domain or what patterns can help me here ?
Generally speaking, if something (only/always) is something, you should use Inheritance.
If something does something, you should use an Interface.
If something plays the role of something (e.g. a Legal Party plays the role of a Customer and/or a Supplier) you should use Composition.
So Seal inherits Animal and implements Swim, Bark
and
Dog inherits Animal and implements Run, Bark
If you want your animals to swim, then either iterate them checking if they implement Swim and then call swim(), or filter the collection prior to iterating through it to get the animals that implement Swim.
Aggregate roots and inheritance is not a very good idea typically.
You probably want to avoid one Aggregate to have a collection of other Aggregates.
The idea of the Aggregate (well, one of them) is that it represents transaction boundary, therefore there, ideally, should be no need in this structure.
It is normal, however, when one Aggregate has a collection of other Aggregates IDs.
I'm not sure there's anything really architecture or DDD related here. It's just basic OO (polymorphism).
If your starting point is a single pet and you want to trigger a behavior particular to its species, no secret - the caller has to know which subtype the pet is and reference the object with its real subtype, not Pet.
If your starting point is a Human and you want to call some behavior across all or part of its pets, you need to reason about something more abstract. If I understand the domain well, something like "an action that a human can tell an animal to perform".
Once you've found the proper name for that, create an abstract method with that name on Pet and have every subclass of Pet implement it in its own way. Then, thanks to polymorphism, you can tell a collection of pets to do it regardless of whether they are cats, dogs, or elephants.
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.