if you have 2 entities (teacher) and (student) both of them has a common attribute so I don't want to repeat the attributes on each table eg (name, age, address, mobile etc..)
so can I make supper class called human with two subclasses one for teacher and second for the student ?
if that valid -> how to connect the two subclasses with the super class? should I use flag of foreign key?
and for retrievingdata, how to do so as per half of the data on subclass and another have is on the supper class ?
thank you
Related
I have the below UML class diagram with Abstract Class, and sub-Classes that extends from it. and i want to make an ER diagram using this class diagram.
My question is how can i represent the Abstract class in ER diagram ? as a Table ? or should i just ignore it ?
Thank you.
There are basically three choices to translate generalization into a database model
1. One table per concrete class
Create tables Admin, Teacher and Student. Each of these table contain columns for all of the attributes and relations of User
Pro
All fields of a concrete subclass are in the same table, so no join needed to get all Student data
Easy data validation constraints (such as mandatory fields for Student)
Con
All fields of User are duplicated in each subclass table
Foreign keys to User have to be split into three FK fields. One for Admin, one for Teacher and one for Student.
2. On table for whole generalization set
In this case you just have one table call User that contains all fields of User + all fields of all sub-classes of User
Pro
All fields are in the same table, so no join needed to get all User data
No splitting of FK's to User
Con
There are a bunch of fields that are never used. All fields specific for Student and Teacher are never filled in for Admins and vice versa
Data validation such as mandatory fields for a concrete class such as Student become rather complex as it is no longer a simple Not Null constraint.
3. One table per concrete class, and one for the superclass
In this case you create tables for each of the concrete sub-classes and you create a table for the class User. Each of the concrete sub-class tables has a mandatory FK to User
Pro
Most normalized schema: No repeated fields for the attributes of user, and no unused fields.
No splitting of FK's to User
Easy data validation constraints (such as mandatory fields for Student)
Con
You have to query two tables if you want all data of a Student
Complex validation rules to make sure each User record has exactly one Admin, Teacher or Student record.
Which one of these options you choose depends on a number of things such as the number of sub-classes, the number of attributes in either subclass or superclass, the number of FK's to the superclass, and probably a few other things I didn't think about.
Using Laravel and MySQL Database
I'm developing a system intended for a doctor-patient management, where there is a parent table 'people' that includes all the general info of a person such as (name, ssn, phone, .......). then there is two tables that inherit this table ('Patient', 'Doctor') each one of them has different additional attributes.
Each person can be either doctor, patient or both.
but will have a different id as doctor and as patient.
What i'm trying to do is
Making Person model that extends eloquent and both
Patient & Doctor Model extends Person.
The output i'm hoping for should be like this
the Patient and all the attributes related to him in patient table and the attributes related to him from person table.
I can't find a way to call for example the patient with ssn = 1 Patient::find('ssn')->Person::find('ssn')to show all the attributes of patient with the related attributes from the parent table 'person' as well such as name, ssn and phone ......etc.
In a simple way i want a way to access the attributes of a person for specific patient.
I tried calling the person first then using the ssn to call the patient with the same ssn. but it felt like a relationship and not inheritance as i put the ssn as foreign key in the patient and doctor table.
Is there a way to do it with class inheritance or am i better using relationships and which type "polymorphic or normal" ? and how to call the person model in the patient model?.
Hope you understand what i'm asking.
Thanks.
I'm currently working on a project, the admin of the application must be able to add/edit these information.
Class(className)
Teacher(teacherName,teacherInfo,teacherPicture,teacherEmail)
Practice(practiceName,practiceDate,practiceDescription,practiceDocs)
I tried making 3 tables of which the class would be the relational table containing the keys of teacher and practice, but that way I can't add only the subject without teachers and practices or add a Teacher and then afterwards assign him a class, or remove him from a class. So my question is how would I go about doing this or if you could point me to some good read for this problem.
If I understood it right, you have a practices table, a teachers table and a classes table, with relation fields put directly on those tables.
For you to be able to create teachers, classes and practices individually, you must take that relationship fields out and put the relations into separate tables.
So, instead of having, for example, a classes table with a teacher field, have a classes table without any field related to the teacher and another separate table classes_teachers where you'd have a unique identifier for the association, the id of the teacher and the id of the class.
The type of relationship your current schema provides is called a 1 by n relationship.
The kind of relationship you need is a n by n relationship.
I have different kind of actors:
Parents;
Subsidiaries;
Insurers;
Brokers;
for each of the actors, there will be users with a personal account and user role.
I need to register the address and other (entity specific, including foreign keys) info into a table, which could be done by defining one "actor_tbl" and specifying the type of actor with an id.
However, the four types of actor have interrelations, which means that one parent can have multiple subsidiaries, one insurer can have multiple subsidiaries, one broker can have multiple parents, etc...
From this point of view, it would make more sense for me to create a separate table for each of the actor types, and create many-to-many relationships to make the right combinations. It think that it may also increase general readability and reduce the possibility for errors (all entities would be clearly separated from one another).
However, doing so takes away the principle of storing all entities with similar characteristics into a single table.
How would you take on this problem? What is the most recommended way to implement this structure?
You can see a superclass/subclass relationship between Actor and the four kinds of actors. The first point here is to clarify the constraints on this relationship. From your description, I'm assuming the participation is mandatory (every Actor will be also a member of a subclass) and the subclasses are disjoint (e.g. a Parent cannot be a Broker, and so on).
In this case, you'll need four relations, one for each subclass.
If instead the participation is optional (some Actor may not be a member of any subclass), you'll need a relation Actor(ActorID, ...) to store all the attributes in common between the subclasses (e.g. address), then one relation for each subclass, which will look like:
Parent(ActorID, ...)
Subsidiary(ActorID, ...)
Insurer(ActorID, ...)
Broker(ActorID, ...)
For these four relations, ActorID will be both primary key and foreign key referencing Actor(ActorID). The dots represent the attributes which are peculiar to the specific entity (as mentioned before, the common attributes will be in the Actor relation).
For Actors which are not member of any subclass, you just store the record in the Actor relation. For Actors which are instead member of a subclass, you'll store the record in Actor and in the specific subclass relation.
In all cases, relationships between the subclasses will be modelled depending on their cardinality.
If the disjointness between subclasses is different, i.e. non-disjoint subclasses, then the story is different.
I want to know what really is the difference between EntitySet and EntityRef in LINQ-to-SQL. As per what I a seem to have understood, EntitySet is one-many or many-many relation and EntityRef is one-one. Correct me if I am wrong.
If the associated class is the many (child) side of a one-to-many relationship, the many class will be stored in a collection of the many classes, where the type of the collection is EntitySet , and T is the type of the many entity class. This collection will be a member variable of the one class.
If the associated class is the one (parent) side of a one-to-many relationship, a reference to the one class will be stored in a variable of type EntityRef , where T is the type of the one class. This reference to the one class will be a member variable of the many class.
therefore, EntityRef & EntitySet act one-to-Many relationship,EntitySet act the many in parent and EntityRef act as One in Child.
recently caught myself in the same doubts, so according to this answer you are right