i have a parent class Person, with children Employee, Member. at some point i will need an Employee to become an employee and a member at same time, holding all the attributes available for both employee and member. how could this be achieved while maintaining only one database record for that person who has moved from being Employee to being both Employee and a Member? i guess multiple inheritance could solve the problem by creating a new class that inherits from those two children, but i am using c#.
For some things, inheritance is just not the best choice.
If someone who is an Employee can become a Member or vice versa, and especially if someone can be both at once, this should probably just not be an inheritance relation in the first place.
I would change the Employee and Member classes into subclasses of a new component called something like Role, and change the Person class to have a field that is a set of Role objects.
With this representation, someone can have both Employee and Member roles.
Related
I have the following scenario where a Product can ONLY be a SaleProduct or a LoanProduct.
Is the relationship between Supplier and Product valid? Or should the relationship be between Supplier and SaleProduct and Supplier and LoanProduct individually?
Thanks.
First of all your diagram is not a UML one. I don't recognise this notation at all.
I'll ignore your diagram and focus on the question itself. Yes, it's perfectly valid to have a relationship on the parent (generic) class and of course it will be inherited by it's children (specialised classes). That's pretty much one of the goals of having those common elements (relationship in this case) on the parent level rather than doubled on the child level.
Here is the explanation. I have two entities: House, Person. In my system one person may own multiple houses and one house may have multiple owners. So I create a table (aka entity) called HouseOwnership. I want to be able to make two different kinds of queries against HouseOwnership:
Given a houseId, get all it's owners
Given a personId, get all the houses owned
So for HouseOwnership, I do
#Entity
class HouseOwnership{
#Load
private Ref<House> houseRef;
#Load
private Ref<Person> personRef;
}
How do I make my queries with OfyService.ofy()?
I am tempted to do
owners =OfyService.ofy().load().type(HouseOwnership.class).ancestor(house).list()
and
houses =OfyService.ofy().load().type(HouseOwnership.class).ancestor(person).list()
but for this I would have to make both References into #Parent. So am I allowed to do that? How do I make the queries?
Also I only have the ids not the actual objects so I would have to create the objects from the ids, which I can do. But I am wondering if there is an easier way?
An entity can have only one parent.
You don't need to make your HouseOwnership entity a child of any entity.
You make a simple query to get all HouseOwnership entities where houseRef property equals a given House key, or personRef property equals a given Person key, or both.
You can always make a Key from an ID for entities that have no parents.
You almost certainly want to model this as a #Index Set<Ref<Person>> owners; property on House. Creating an extra relationship entity creates a significant amount of overhead.
Don't try to map schemas literally from relational models - use the document structure to your advantage.
(I apologies in advance for my English)
I need to make a model of relation.
Normally it a thing we should do in team, but I am stuck to be alone, so I am kind of overwhelm by this
It about a school and it information concerning The Student, The Parents and the Class he want to enroll. Also they keep academic results.
I just can't get an ideal of how I could link them all and avoiding relations problems
http://i.imgur.com/fdwxH8g.jpg
First, I suggest you add a Person table to supertype Parent and Student, and move all the personal and contact information attributes to Person. You're sure to want to add additional information later, and having to duplicate everything for parents, students (and later, teachers and other school staff) gets to be a nuisance.
person (person_id PK, last_name, first_name, sex, birthday, email, address, city, phone_number, cellphone_number)
Next, do you want to record biological parents or caregivers? In schools we normally care about caregivers and their relationship to the student. To record that, you could create a relationship type table:
relationship (relationship_id PK, description)
with entries for father, mother, aunt, grandfather, fostermother, etc. You can then record the relationship between 2 persons like so:
parent (parent_id PK/FK, child_id PK/FK, relationship FK)
If you wanted to record biological parents, you could use:
bioparents (child_id PK/FK, father_id FK, mother_id FK)
with father and mother ids nullable (or decompose into separate tables for father and mother) since we're unlikely to know both parents for all students.
Finally, we get to the business at hand, students. Historical information and alumni are important in schools, so take care to model students over time, not just current students. You need to consider the time resolution for student registrations - are registrations annual, quarterly, or something else? For annual registrations, you could start with:
student (person_id PK/FK, year)
Now, what is a class? Is it something that recurs over time, or are classes with the same name in different years/quarters separate things? Can classes contain learners of different forms/grades/levels, or are they partitions of those? Is a class a grouping of students that attend multiple subjects, or a subject-specific grouping? I'm familiar with two types of classes, which could be called form classes and academic classes, but things may be different in your region of the world.
Using your class table:
class (class_number PK, name, prerequisite, formation_time)
We need to link students to it. If class membership is an annual thing, we can add to the student relation above, e.g.
student (person_id PK/FK, year, class_number FK)
Now, I just made up tables as I went along, but if you want to do this properly, you really should list/model your functional dependencies before you start making up tables. You could look into a formal modeling discipline like Object-Role Modeling, or at least write out simple logical relations in both directions:
a Student has one or more Parents
a Parent has one or more Students
a Class has a Year
a Year has zero or more Classes
a Student has a Class per Year
For non-binary relations, you don't need to write it out in every direction, but you do need to decide which combinations of attributes uniquely determine the others. For example, the combination of Student and Year uniquely determines the Class.
Anyway, that should give you a start.
I'm really confused on the difference between disjoint and overlapping design constraints in relational databases. I've looked around, but have had a hard time finding an understandable example. Could someone please explain this to me via an example?
Thanks!
Say you have a super class 'musician' then two sub classes 'singer' and 'guitar player'.
In a disjoint constraint you would have to put the musician in either one or the other sub classes. In an overlapping constraint the musician can be put in both.
Let's say you have a super class 'account' with sub classes 'Savings Account' and 'Current Account'. This is a disjoint constraint situation because a bank account can either be Savings or Current. It cant be both at the same time.
For an overlapping constraint situation, let's say we have a super class 'Person' and subclasses 'Customer' and 'Employee'. In this case, a person can be Customer and Employee both. Therefore, overlapping.
The disjoint rule states an entity instance of a supertype can only be a member of one subtype. The overlap rule states an entity instance of a supertype can be a member of multiple subtypes.
Example of disjoint rule:
Instance of Super-type Animal can only be member of exactly one of these Sub-types being Panda, Cheetah and Dog
Disjoint Union , (An animal can either be Panda or be Dog or be Cheetah but can't be any two or more at the same time)
Example of overlap rule: Instance of Super-type Person can be member of multiple Sub-types being Woman, Driver and Engineer
Overlapping Union , (A person can be a Woman and that same Woman can be Driver and that same Woman can be Engineer at the same time)
Let's simplify this confusing concept. First of all, understand that there is a discriminator between subtype and supertype. If the value of a discriminator is not null and appears in supertype entity instance then that must be linked with the only one subtype. This is called disjoint constraint.
For example, you say in school a person can be teacher and student but a teacher can't be a student and vice versa. Then in person supertype and (student, teacher) subtype exists a discriminator called person_type. If person_type in person entity is 't' then it is linked with teacher subtype only not with a student. Similarly, we can write it for the student.
Now, in overlapping constraint, the supertype entity instance can appear in many subtype instance.
In overlapping example consider a teacher can be a student also. Then 't' can be linked with student and teacher subtype entity.
suppose Member is super class and its two sub-classes one is student and 2nd one is faculty,if(Member) of subclass(student or faculty)not both then it is disjoint.
if member both of its subclass then it non-disjoint or overlapping.
.
I want to run over this plan I have for achieving strong consistency with my GAE structure. Currently, here's what I have (it's really simple, I promise):
You have a Class (Class meaning Classroom not a programming "class") model and an Assignment model and also a User model. Now, a Class has an integer list property called memberIds, which is an indexed list of User ids. A class also has a string list of Assignment ids.
Anytime a new Assignment is created, its respective Class entity is also updated and adds the new Assignment id to its list.
What I want to do is get new Assignments for a user. What I do is query for all Classes where memberId = currentUserId. Each Class I get back has a list of assignment ids. I use those ids to get their respective Assignments by key. After months with this data model, I just realized that I might not get strong consistency with this (for the Class query part).
If user A posts an assignment (which consequently updates ClassA), user B who checks in for new assignments a fraction of a second later might not yet see the updated changes to ClassA (right?).
This is undesired. One solution would be to user ancestor queries, but that is not possible in my case, and entity groups are limited to 1 write per second, and I'm not sure if that's enough for my case.
So here's what I figured: anytime a new assignment is posted, we do this:
Get the respective Class entity
add the assignment id to the Class
get the ids of all this Class's members
fetch all users who are members, by keys
a User entity has a list of Classes that the user is a member of. (A LocalStructuredProperty, sort of like a dictionary:{"classId" : "242", "hasNewAssignment" : "Yes"} ). We flag that class as hasNewAssignment =
YES
Now when a user wants to get new assignments, instead of querying for groups that have a new assignment and which I am a member of, I
check the User objects list of Classes and check which classes have
new assignments.
I retrieve those classes by key (strongly consistent so far, right?)
I check the assignments list of the classes and I retrieve all assignments by key.
So throughout this process, I've never queried. All results should be strongly consistent, right? Is this a good solution? Am I overcomplicating things? Are my read/write costs skyrocketing with this? What do you think?
Queries are not strongly consistent. Gets are strongly consistent.
I think you did the right thing:
Your access is strongly consistent.
Your reads will be cheaper: one get is half cheaper as then query that returns one entity.
You writes will be more expensive: you also need to update all User entities.
So the cost depends on your usage pattern: how many assignment reads do you have vs new assignment creation.
I think using ancestor queries is a better solution.
Set the ancestor of the Assignment entities as the Class to which the assignment is allotted
Set the ancestor of a Student entity as the Class to which the student belongs.
This way all the assignments and students in a particular class belong to the same entity group. So Strong consistency is guaranteed w.r.t a query that has to deal with only a single class.
N.B. I am assuming that not too many people won't be posting assignments into a class at the same time. (but any number of people can post assignments into different classes, as they belong to different entity groups)