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.
Related
I have a course entity that can be online or offline and has lessons. Depending on the type, the lesson can have two sets of fields. Datetimes for online courses and sections for offline courses that contain video files and some extra attributes such as 'is_watched' and etc. If we create a Fields table that has keys and values for each lesson, if the course is online those extra attributes for offline courses would have to be null. And if we create both tables for each type of course, we have to define two relations that one of them does not exist, and also we have to check for the type every time we are accessing the fields.
What is the best way to implement these tables and their relations? And how to access those fields based on the type?
you might need to check polymorphic relations in laravel
https://laravel.com/docs/8.x/eloquent-relationships
you could create two tables online/offline courses
the lesson model will have one method "call it courses"
the polymorphic relation will create two columns in lessons table
courseable_id --->id of either table
courseable_id --> name space of either model ex App\Models\OnlineCources or App\Models\OfflineCources
I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
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 two type of user in my master table Doctor and Hospital both user has common fields like Name,Address,Contacts etc.
But there are some different fields which is connected by foreign key to this table
Like for Doctor it has
one to one relation with specialization and department table
and for Hospital
has one to one with service and one to many with facilities table
Now my question is What should be the database schema for this type of relation, At present I made separate table for both Doctor and Hospital but the fields like Name,Contact and Adreess repeating in both table.
It sounds like Doctor and Hospital are both subclasses of some superclass, and the fields that repeat in both of them are attributes of that superclass. Do some google searches with either of these two search terms: "Generalization/Specialization" or "Class Table Inheritance". That second term will show you some specific designs for implementing subtypes or subclasses in relational tables.
You might want to ask the question of in the Database Administrators area. There is a tag called "subtypes" over there with one question in it. It's asking the same thing you are, in a different case.
im new to mysql, and my first project would be to create a database of students-classes scenario.
i have decided to make a table "students" then thought each student could possibly be a member of one or more classes, so in my mind there would be a column in the students table that says "classes" now what data type would be appropriate for that? a class would consist of a string for name, then schedule (MTh, 10:30-11:30). Or should i instead just make a "classes" table then one of the columns would contain all the names of the students that belong to that class, then what data type should be used for a long "list"-like strings?
Each class can have many students, and each student can have many classes. Therefore your dilemma is whether to record the students in the classes table, or the classes in the students table.
In a relational database, you should have three tables:
one table for students;
one table for classes;
one table that has the pairings: one row each for one student being a member of one class.
It's far more flexible and general-purpose to do it this way.
See also my answer to Is storing a delimited list in a database column really that bad?