I am looking for the best term to use to describe a child that inherits an ancestor.
For example, a 'Car' object may derive from its ancestor 'Vehicle'. However, is there a better/more suitable word to use than derivative for the inverse?
Ancestor/Descendant are a more common pairing when there can be intermediate layers between the items under discussion.
E.g. if we have Vehicle -> Wheeled Vehicle -> Car (and assuming other possible classes also exist), both Vehicle and Wheeled Vehicle are ancestors of Car and both Wheeled Vehicle and Car are descendants of Vehicle. We would describe Vehicle as the parent of Wheeled Vehicle and Car as a child of Wheeled Vehicle but we wouldn't generally use parent or child to describe the relationship between Vehicle and Car.
"Inherited class" and "derived class" work well. At times instances of objects have parent/child relationships that have nothing to do with inheritance, like parent nodes and child nodes. In those cases referring to "parent" and "child" classes in the same context could be confusing.
Also, using the parent/child metaphor, every child is a parent, not every parent is a child, and some classes are infertile (sealed.)
Parent and child
So a car derives from it's parent vehicle; and a vehicle has multiple children such as car, boat and plane.
Related
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
Closed 6 months ago.
I am designing a database for a kindergarten and I got stuck trying to design a relationship between three entities.
In this school parents can authorize certain people to pick up their kids when they can't do so. So there should be three entities: child, parent and AP (authorized person). A child should have at least one parent, two at maximum. A parent should have at least one child, but they can have many. So I designed this as a many to many relationship.
The parent can authorize zero or many people to pick up their child(ren), and the same person can be authorized by many parents to do so. Hence a many to many relationship exists in my design between PA and Parent.
What is a design for a table to keep track of who has picked up a child? The table should be related with the child table and save the date, but a parent or a AP can pick up the child, so how is that relationship modeled? I have never seen this design pattern before, but if there were a way to design inheritance in SQL this should be easy; an AP is just a specialized form of parent, so both entities can be treated as the same when picking up the child from school.
Maybe there should be two tables, one to model when a parent picks up a child and one where the AP picks up a child. Maybe an AP should be related directly to the child.
Get rid of the AP entity and rename Parent with Adult which will contain parents + authorized persons.
Your design could look like this:
child (1, n) (0, n) adult
[adult] parent (0, n) (1, n) [adult] authorized person
A child has at least 1 parent. An adult can have 0 child (authorized person) or many (parent).
A parent (adult entity) can authorized 0 or more AP and an AP (adult entity too) is authorized by at least 1 parent.
Then for pickups you only need relationships with the adult entity and the child entity.
Note that this design will allow a parent to be the AP for other children.
In OOP when a class forms a HAS-A relationship with another class, it's called an Aggregation, a simple example of that is below where a Car has an Engine but an engine can exist without a car:
class Engine {
start() {
console.log('Engine started');
}
}
class Car {
engine: Engine;
constructor(engine: Engine) {
this.engine = engine;
}
}
Question:
If i had to do the inverse of Aggregation such that i could answer a query Give me all the cars associated with this Engine, what is that called in OOP?
The aggregation (or composition, or association) is a concept: it allows to say that A has a B. You can invert the composition (B has an A) but the concept itself has no "inverse". Or it would be: A does not have B !
has-a as a static relationship gets translated to Aggregation. In a typical Object oriented modeling, after identifying the static relationship between two entities, next question we ask is which is more frequent direction in which we will be raising the queries.
In your example it is one-to-one relationship between objects (vehicle has only one engine and engine is mounted on only one vehicle at given moment).
If most of the time the query is getMeThisVehiclesEngine() (container to contained), then Vehicle holds the reference of engine, if the query is opposite (I think this is kind of your inverse) like getMeTheVehicleWhichIsHoldingThisEngine() (content to container. Here container and content terms are from the domain perspective), then engine will hold the reference of vehicle, and I would call it association. If we need bidirectional navigation, both objects keep each others reference. (In general we avoid bidirectional relationship). with one to one relationship, its not that obvious, but imagine an example of shared aggregation with has-a relationship between Athletics Team and member-student. member-students can be part of different teams simultaneously. From team to student-member I would call it as aggregation and Team will hold collection of Students. From Student-member to Team I would call it association (Student is associated with Athletics Team) and Student will hold either simple reference of Athletics team, or collection of Teams, if Student can be member of multiple teams simultaneously.
SQL Query
select * from zchildren where zparent = 3586 OR zparent in (Select zid from zchildren where zparent = 3586)
I have tried few cases with $SUBQUERY but Still i am not getting any success. So how can i achieve this ?
Update
I have Table Name which is Children which has Parent which contains the ID of the same table ID , Its a Inverse Relationship now i want All the children which parent is '3586' and its all sub children
Update2
I am Attaching the screen shot
Now Few more points
Table Group has One-To-Many Relationship with Children
Table Children has Two Relationship
First which is Inverse to Group One-To-One
Second children relation which is Inverse to itself which is called Reflexive
Updated Question
Now suppose i have one Query i want to search from Children table where title is 'Medical' AND Parent is '3586'
Now This '3586' is parent id which is coming from Table Group And i can easily predicate this .
Problem
It Gives me children whose parent '3586' but i also want to search in the title of sub-children which are Reflexive of this parent ID , Means sub-children of children which came from parent '3586'.
I really need this solution. I can still update my question if any one is not clear in this question.
When tackling somewhat complicated Core Data issues, you really have to be a bit more accurate. Your code and your variable names are sloppy and wrought with mistakes.
In your SQL query you have an attribute parent (or "zparent"), but in the Core Data model it becomes an attribute rather than a relationship. (Were you perhaps thinking of modeling ids? That would indicate that you are still trapped in relational database thinking and have not fully grasped the concept of the object graph yet. Forget about ids and think in relationships instead.)
You need a reverse relationship to children, so this cannot be the same relationship. Calling the entity "Children" is confusing because 1) you are using the plural for a singular object and 2) you are calling both parent and children "Children". You also misspell "Children" as "Childran", potentially leading to all sorts of errors.
Instead, let me suggest the entity name Person. A person can have one or more parents (or is it only one?) and one or more children both of which are also of type Person, resulting in a many-to-many relationship:
Person - parents <<----------------->> children - Person
If a person can only have one parent it if of course a many-to-one relationship.
Person - parent <------------------->> children - Person
You can then fetch a Person with idNumber 3586 (notice that using id is perhaps also a bad idea as it is a reserved word in some contexts). You can then access that person's children very succinctly:
person.children
That's really all there is to it.
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.
What is the parent and what is the child in a sql relationship?
In my case, I have a part (Say screw), and product material. For argument's sake, a product material (eg steel) can only belong to one part (but not in the real world). So this is 1:n. The part will have its pk as a fk in the ProductMaterial table.
Which is parent and which is child in this case?
Relational databases such as SQL actually have no concept of parent/child relationships - that is an interpretation that you as a programmer put on the data. There are architectures that explicitly state and use such relationships, such as heirarchical (and to a certain extent OO) databases.
You can interpret a 1:n relationship in database this way: A child is always that model which holds the foreign key as this indicates where it belongs to.
Of course if you have self referencing models/tables you have to look at it in a different way.
In this case, Part is parent and ProductMaterial is child.
A parent can have unlimited numbers of children (scary thought - 2 is enough for me!), whereas a child can have only a limited number of parents - and in DB terms, only 1!
Usually in a one-to-many relationship, it's the "one" record that is the parent, and the "many" records that are the children.
Of course, in some cases it doesn't make any sense to talk about a parent-child relationship. In your example it makes some kind of sense at least. In other examples you may even find the opposite, where a child has many parents, but then it's not very useful to describe it that way.
Another way to look at this, in addition to what David M. said, is in terms of an ORM implementation (such as Linq to SQL). You have two entities, Part and ProductMaterial. Each part entity has a set of ProductMaterial entities (children entities or an EntitySet). Each ProductMaterial entity has zero or one Part entity (parent entity or an EntityRef).
Randy
I would say that any table which has a one to many relationship with one or more other tables can be considered a parent to those other tables. Self joining? An ambiguous term which I don't think anyone understands.
'Product' is parent and 'Product material' is child in Product_ProductMaterial relationship or association.
If you delete a child, parent can live and continue life. If you delete parent, child become orphan or identityless which is not good. If A can not not be deleted before B is deleted, then A is parent and B is child.
If I guess right, in your case in Product_ProductMaterial relationship, if you delete Product, ProductMaterial will be assigned to no one, become orphan, identity crisis. But if you delete ProductMaterial, Product can still be there, no need identity support.
Sorry if my wordings are not good.