i have an erd for a school assignment that contains a many to many relationship that as far as i can tell is un-expandable. I have a class that can be taught by many teachers (as in many teachers in the same room at the same time teaching the same people) and one teacher is assigned as the head teacher, so as far as i can see, one class can be taught by many teachers and many teachers can teach the same class (at the same time). Has anyone got any idea how i could expand this?
I have tried making a week entity eg group. so one class is taugt by one group and one group can teach many classes but i still end up with the issue of one group can have many teachers and many teachers can be in a group.
Every way i look at i end up with a many to many relationship between teacher and either class or the weak entity, any help would be greatly appreciated.
thanks
The usual (and best) approach to modeling m:n relationships is to create an intermediate association.
In this case you would have a 1:m relationship between Class and the association (since each class can be associated with many teachers) and also a 1:m relationship between Teacher and the associtaion (since each teacher can be associated many classes).
When it comes to creating tables, the association becomes a table in its own right, with foreign keys to both Class and Teacher, thus linking them together.
Related
We've been given an assignment in which we are to create a conceptual model, described by a text document. There are a number of constraints given in the document, but we have also been instructed not to use constraints in the model.
We have been able to work around a few constraints, but there is one that we've been unable to tackle. I've made up a scenario that is somewhat similar to the part of the assignment that we're having issues with.
You've been tasked to create a model of the structure of a game studio. The company consists of a number of departments, and each department has at least one employee. Each employee works at a single department. There are three different types of employees: developers, designers and engineers.
In addition to this, there are a number of leadership roles that employees can have: Head of Department, Deputy Head of Department, CTO or CEO (Yes, CTO and CEO are roles that regular employees have). Each department must have 1 Head of Department and at least one Deputy Head of Department.
In addition to this, there can only be one CTO and one CEO, and these roles can only be held by engineers. Each employee can only have a single leadership role.
To solve this, we've made up an additional, abstract entity: BasicRole. This entity is a specialisation of LeadershipRole, and is a generalisation of the three roles that any employee can hold. That solves one of the problems, and now we can simply create appropriate associations between Designer/Developer and BasicRole
However, we also want Engineer to have an association with BasicRole in addition to associations to CEO and CTO. Adding those associations results in a conceptual model that looks as such:
However, this is problematic because now we're saying that an engineer can have anywhere between 0 and 3 roles.
We've considered including Company as an entity and adding associations between Company and CTO/CEO, to specify that way that the company can only have one of each, but we've been told over and over during this course not to include the thing that we're modeling as an entity in the model.
Now, it seems as if all our problems could be solved with constraints (if we were to go ahead and read up on those), with some sort of xor for the three associations. However, seeing as we've been instructed not to use constraints in the conceptual model, we're at a loss.
If you associate your Engineer to LeadershipRole (with multiplicity 0..1) removing your two relationships from Engineer to CTO, CEO and LowerRole you will get the expected result:
Each employee can only have a single leadership role.
Since LeadershipRole is abstract it has to be either CEO, CTO, HeadOfDepartment or DeputyHOD) but due to the multiplicity can't be more than one at the same time.
The "we've been told over and over during this course not to include the thing that we're modelling as an entity in the model" statement is correct if you're designing the code-level documentation but it is normal to put the entity representing the whole organisation you're modelling. In other words - don't put System (or however you call your system) in your system's model. But Company is something you model within your system.
2 options for "Each department must have 1 Head of Department and at least one Deputy Head of Department."
Redefinition
Nested notation
2 options for "these roles can only be held by engineers"
Redefinition
Generalization
Total 4=2*2 options
Im making an ERD now for medicine care.
I have an issue with 2 entities:
Patient and caregiver.
The caregiver is a person that helps for the patient and can do features on the application for the patient.
For now I choose that the patient is a separate user from the caregiver.
If its like that,I need to do a seperate entities for the caregiver and for the patient. When I do this , there is an overload on the ERD because the 2 entities can do the same thing on the system so they have the same connections to other entities.
In addition , they have just one attribute that is different between them and this is the diagnosis of the patient.
What to do?
I would suggest looking into adding the caregiver as a sub class if all the rows are the same apart from one. But having them both as separate entities wouldnt be an overload on the database as long as you add primary/foreign keys correctly. Have you got a current ERD i can look at?
I am about to develop a solution for a customer where the basic entity is a member and members can have different multiple social relationships with other members. For instance Lets say we have four types of members Doctors, Specialist, Nurses and Patients. So one or more Doctors can consult one or more Specialists, One or more Doctors can treat one or more Patients. One or more Doctor is in Charge of one or more Nurses. So if I were to use a Relational DB a high degree of recursion would be necessary (as All entities must be members). Whereas recursion is not necessary in a Graph data model.
Is it then safe to say it is better to use a Graph database for a social type application where members may have different or overlapping roles.
A graph database would be good at modelling these kinds of relationships. There's a few ways that you might model it. You could think of a vertex as being a Member with different edges from Member to other Members representing the types of relationships:
Member --consults--> Member (physician to specialist)
Member --reportsTo--> Member (nurse to physician)
Member --diagnoses--> Member (physician to patient)
Obviously a Member may have as many of any edge type (e.g. multiple "consults" with specialists). In a more complex model, you might also see a Member as being an "identity" for a person such that your model looks like:
Member --actsAsPhysician--> Physician
Member --actsAsSpecialist--> Specialist
Physician --consults--> Specialist
In this approach the "consults" edge can only exist on a "Physician" vertex, thus you provide some constraints as to what vertex types can be expected to have what kind of edges.
Graphs provide you a lot of flexibility in being able to model data such as it exists in the real-world as you are really just describing entities and the relationships among them. I'd encourage you to look at http://tinkerpop.com for a collection of tools that are helpful in building graph applications independent of the graph database you choose.
If every one is a member then member is central to the data model in a relational perspective. There is no need for recursive SQL select statements:
Member ->---<- Doctor ->---<- Patients
One or More Members is One or More Doctors One or More Doctors treats One or More Patients
Your model will have a lot of Many to Many relationships and alot of Relationship tables. For instance the Treats relation could contain attributes such as Treatment Period
Ailment
etc.
Your solution could be implemented in any topology. While the network/graph topology is faster than the Set topology the graph data model once implemented is almost impossible to change. History tells us it is unwise to build rigid business applications. So research the pros and cons of each and make a decision.
I have two content types in my application:-
Student
Teacher
Teacher-Student has parent child relationship.
Inside Student there is a node reference field to Teacher which means that when creating a student user needs to provide one or more Teacher's before saving content type.
So one student is related to multiple Teacher here.
Suppose X is a student. Y and Z are teachers of X. Now when I opened the student(X) page then I want to see all the related students in a block who belongs to either (Y or Z) or Both.
Can it be possible using Views UI?Please let me know your suggestion on this.
The problem is solved. Views UI did the magic with the help of relationship. In this case there will be two relations involved. One from student to Teacher and other relation with teacher to student involving the previous relations. I was searching blindly unless I got the article in Internet about turning on the SQL query in Views which helped me to work more logically. This link helped me:-
https://drupal.stackexchange.com/questions/11997/use-of-relationships-joins-in-views
Thanks to all.
In my OLTP database I have a layout consisting of instructors and students. Each student can be a student of any number of instructors. A student can also sign up for an instructor, but not necessarily book any tuition (lesson).
In a data warehouse, how best would this be modelled? If I create a dimension table for Lessons, Instructors and Students and a fact table for the lessons students have taken then this will work when an instructor wants to see what lessons a student has taken.
However, how will an instructor see how many students are REGISTERED with the instructor but has not yet taken a lesson?
In my OLTP, I have a many to many table (InstructorStudents) that links each student with one more more instructors. In an OLAP database, this isn't appropriate.
What would be the best schema in this case? Would a many to many be appropriate in this instance? I can't store a list of which students are registered to which instructors in the student table, so I feel another dimension table is necessary but cannot work out what should be contained in it.
If a fact represents a transaction, you seem to have two different facts here: Sign ups & Lessons. There are always a lot of ways to go but, perhaps, you need two fact tables. They may have similar dimensionality except the sign-up table will have a Class dimension (class name, instructor name, etc.). The Lessons table will tie to the class dimension but, also, to a Lesson dimension (date, classroom used, etc.).
There are a few other ways to do this but they will be more difficult from a programming & reporting perspective.
You need a many to many dimensional model.
You need a factless fact table. Look at the following resource that refers to an example close to your need
http://www.kimballgroup.com/1996/09/02/factless-fact-tables/