Related
So I am new in designing databases and I'm trying to represent a db diagram for a system where students can rate professors and school. Also Students and Professors can have their account to login.
Is this a proper presentation and am I missing anything as of entity relations ?
And I wasn't sure if i need to use any inheritance as well ..
Enumerated columns are good indication for bad design.
You need an additional table for values.
Once that done, there is no need to separate school rating from professor rating -
use a general rating table containning the id of the rater (which is always a student in your case) and the id and type (school/professor) of the rated element.
I don't see any reason to put students and professors in different tables.
Think of it as a person table with a role attribute.
If a person can be both, than instead of the role attribute add 2 flags columns - is_student and is_professor.
It looks okay but are you sure the relatioship between SchoolRating and Student should be many to many? Wouldn't a rating just have one student (the student who did the rating)?
Also it's not clear to me why SchoolRating and ProfessorRating have so many value attributes.
Initial Review: Seems solid, may require another table or an expansion of SchoolRating.
When you are designing, focus on what your objects accomplish, the questions of facts they answer.
SchoolRating has values that represent the reviews or are they aggregates of a set amount of teachers? How are these reviews rectified with professor rating...or do they have no relation? (They clearly do in a school...so how does your design accomplish this?)
Why does a student have any direct relation with SchoolRating? Should not this table be a true FACT table for the values scored from the professors and/or some rating system?
Why can a student not have multiple teachers or multiple reviews? If a student fails a class but leaves a review...how does your structure rectify a new review from the same student?
Lastly, do not use the inheritance theory in your relational design. It is utterly incompatible with the relational set theory and the sooner you learn to purge that from your system, the better.
Think on terms of DIMENSIONS and FACTS. Think about cardinality, or how you plan to deal with slowly changing dimmensions, whether database columns will provide efficiency.
Concepts like Star-Schema, Snowflake design, of durable keys, natural keys probably should be consulted whenever you question your design.
At the end of the day, what questions your tables can answer and how the system will access these tables are as important, if not more, to the design methodology as it relates to normalization.
I'm preparing a legacy Microsoft SQL Server database so that I can interface with in through an ORM such as Entity Framework, and my question revolves around handling the setup of some of my many-to-many associations that share a common type. Specifically, should a common type be shared among master types or should each master type have its own linked table?
For example, here is a simple example I concocted that shows how the tables of interest are currently setup:
Notice that of there are two types, Teachers and Students, and both can contain zero, one, or many PhoneNumbers. The two tables, Teachers and Students, actually share an association table (PeoplePhoneNumbers). The field FKID is either a TeacherId or a StudentId.
The way I think it ought to be setup is like this:
This way, both the Teachers table and the Students table get its own PhoneNumbers table.
My gut tells me the second way is the proper way. Is this true? What about even if the PhoneNumbers tables contains several fields? My object oriented programmer brain is telling me that it would be wrong to have several identical tables, each containing a dozen or so fields if the only difference between these tables is which master table they are linked to? For example:
Here we have two tables that contain the same information, yet the only difference is that one table is addresses for Teachers and the other is for Students. These feels redundant to me and that they should really be one table -- but then I lose the ability for the database to constrain them (right?) and also make it messier for myself when I try to apply an ORM to this.
Should this type of common type be merged or should it stay separated for each master type?
Update
The answers below have directed me to the following solution, which is based on subclassing tables in the database. One of my original problems was that I had a common table shared among multiple other tables because that entity type was common to both the other tables. The proper way to handle that is to subclass the shared tables and essentially descend them from a common parent AND link the common data type to this new parent. Here's an example (keep in mind my actual database has nothing to do with Teachers and Students, so this example is highly manufactured but the concepts are valid):
Since Teachers and Students both required PhoneNumbers, the solution is to create a superclass, Party, and FK PhoneNumbers to the Party table. Also note that you can still FK tables that only have to do with Teachers or only have to do with Students. In this example I also subclassed Students and PartTimeStudents one more level down and descended them from Learners.
Where this solution is very satisfactory is when I implement it in an ORM, such as Entity Framework.
The queries are easy. I can query all Teachers AND Students with a particular phone number:
var partiesWithPhoneNumber = from p in dbContext.Parties
where p.PhoneNumbers.Where(x => x.PhoneNumber1.Contains(phoneNumber)).Any()
select p;
And it's just as easy to do a similar query but only for PhoneNumbers belonging to only Teachers:
var teachersWithPhoneNumber = from t in dbContext.Teachers
where t.Party.PhoneNumbers.Where(x => x.PhoneNumber1.Contains(phoneNumber)).Any()
select t;
Teacher and Student are both subclasses of a more general concept (a Person). If you create a Person table that contains the general data that is shared for all people in your database and then create Student and Teacher tables that link to Person and contain any additional details you will find that you have an appropriate point to link in any other tables.
If there is data that is common for all people (such as zero to many phone numbers) then you can link to the Person table. When you have data that is only appropriate for a Student you link it to the Student ID. You gain the additional advantage that Student Instructors are simply a Person with both a Student and Teacher record.
Some ORMs support the concept of subclass tables directly. LLBLGen does so in the way I describe so you can make your data access code work with higher level concepts (Teacher and Student) and the Person table will be managed on your behalf in the low level data access code.
Edit
Some commentary on the current diagram (which may not be relevant in the source domain this was translated from, so a pinch of salt is advised).
Party, Teachers and Learners looks good. Salaries looks good if you add start and end dates for the rate so you can track salary history. Also keep in mind it may make sense to use PartyID (instead of TeacherID) if you end up with multiple entites that have a Salary.
PartyPhoneNumbers looks like you might be able to hang the phone number off of that directly. This would depend on if you expect to change the phone number for multiple people (n:m) at once or if a phone number is owned by each Party independently. (I would expect the latter because you might have a student who is a (real world) child of a teacher and thus they share a phone number. I wouldn't want an update to the student's phone number to impact the teacher, so the join table seems odd here.)
Learners to PaymentHistories seems right, but the Students vs PartTimeStudents difference seems artificial. (It seems like PartTimeStudents is more AttendenceDays which in turn would be a result of a LearnerClasses join).
I think you should look into the supertype/subtype pattern. Add a Party or Person table that has one row for every teacher or student. Then, use the PartyID in the Teacher and Student tables as both the PK and FK back to Party (but name them TeacherID and StudentID). This establishes a "one-to-zero-or-one" relationship between the supertype table and each of the subtype tables.
Note that if you have identity columns in the subtype tables they will need to be removed. When creating those entities going forward you will first have to insert to the supertype and then use that row's ID in either subtype.
To maintain consistency you will also have to renumber one of your subtype tables so its IDs do not conflict with the other's. You can use SET IDENTITY_INSERT ON to create the missing supertype rows after that.
The beauty of all this is that when you have a table that must allow only one type such as Student you can FK to that table, but when you need an FK that can be either--as with your Address table--you FK to the Party table instead.
A final point is to move all the common columns into the supertype table and put only columns in the subtypes that must be different between them.
Your single Phone table now is easily linked to PartyID as well.
For a much more detailed explanation, please see this answer to a similar question.
The problem that you have is an example of a "one-of" relationship. A person is a teacher or a student (or possibly both).
I think the existing structure captures this information best.
The person has a phone number. Then, some people are teachers and some are students. The additional information about each entity is stored in either the teacher or student table. Common information, such as name, is in the phone table.
Splitting the phone numbers into two separate tables is rather confusing. After all, a phone number does not know whether it is for a student or a teacher. In addition, you don't have space for other phone numbers, such as for administrative staff. You also have a challenge for students who may sometimes teach or help teach a class.
Reading your question, it looks like you are asking for a common database schema to your situation. I've seen several in the past, some easier to work with than others.
One option is having a Student_Address table and a Teacher_Address table that both use the same Address table. This way if you have entity specific fields to store, you have that capability. But this can be slightly (although not significantly) harder to query against.
Another option is how you suggested above -- I would probably just add a primary key on the table. However you'd want to add a PersonTypeId field to that table (PersonTypeId which links to a PersonType table). This way you'd know which entity was with each record.
I would not suggest having two PhoneNumber tables. I think you'll find it much easier to maintain with all in the same table. I prefer keeping same entities together, meaning Students are a single entity, Teachers are a single entity, and PhoneNumbers are the same thing.
Good luck.
I am learning about databases and SQL for the first time. In the text I'm reading (Oracle 11g: SQL by Joan Casteel), it says that "many-to-many relationships can't exist in a relational database." I understand that we are to avoid them, and I understand how to create a bridging entity to eliminate them, but I am trying to fully understand the statement "can't exist."
Is it actually physically impossible to have a many-to-many relationship represented?
Or is it just very inefficient since it leads to a lot of data duplication?
It seems to me to be the latter case, and the bridging entity minimizes the duplicated data. But maybe I'm missing something? I haven't found a concrete reason (or better yet an example) that explains why to avoid the many-to-many relationship, either in the text or anywhere else I've searched. I've been searching all day and only finding the same information repeated: "don't do it, and use a bridging entity instead." But I like to ask why. :-)
Thanks!
Think about a simple relationship like the one between Authors and Books. An author can write many books. A book could have many authors. Now, without a bridge table to resolve the many-to-many relationship, what would the alternative be? You'd have to add multiple Author_ID columns to the Books table, one for each author. But how many do you add? 2? 3? 10? However many you choose, you'll probably end up with a lot of sparse rows where many of the Author_ID values are NULL and there's a good chance that you'll run across a case where you need "just one more." So then you're either constantly modifying the schema to try to accommodate or you're imposing some artificial restriction ("no book can have more than 3 authors") to force things to fit.
A true many-to-many relationship involving two tables is impossible to create in a relational database. I believe that is what they refer to when they say that it can't exist. In order to implement a many to many you need an intermediary table with basically 3 fields, an ID, an id attached to the first table and an id atached to the second table.
The reason for not wanting many-to-many relationships, is like you said they are incredibly inefficient and managing all the records tied to each side of the relationship can be tough, for instance if you delete a record on one side what happens to the records in the relational table and the table on the other side? Cascading deletes is a slippery slope, at least in my opinion.
Normally (pun intended) you would use a link table to establish many-to-many
Like described by Joe Stefanelli, let's say you had Authors and Books
SELECT * from Author
SELECT * from Books
you would create a JOIN table called AuthorBooks
Then,
SELECT *
FROM Author a
JOIN AuthorBooks ab
on a.AuthorId = ab.AuthorId
JOIN Books b
on ab.BookId = b.BookId
hope that helps.
it says that "many-to-many relationships can't exist in a relational database."
I suspect the author is just being controversial. Technically, in the SQL language, there is no means to explicitly declare a M-M relationship. It is an emergent result of declaring multiple 1-M relations to the table. However, it is a common approach to achieve the result of a M-M relationship and it is absolutely used frequently in databases designed on relational database management systems.
I haven't found a concrete reason (or better yet an example) that explains why to avoid the many-to-many relationship,
They should be used where they are appropriate to be used would be a more accurate way of saying this. There are times, such as the books and authors example given by Joe Stafanelli, where any other solution would be inefficient and introduce other data integrity problems. However, M-M relationships are more complicated to use. They add more work on the part of the GUI designer. Thus, they should only be used where it makes sense to use them. If you are highly confident that one entity should never be associated with more than one of some other entity, then by all means restrict it to a 1-M. For example, if you were tracking the status of a shipment, each shipment can have only a single status at any given time. It would over complicate the design and not make logical sense to allow a shipment to have multiple statuses.
Of course they can (and do) exist. That sounds to me like a soapbox statement. They are required for a great many business applications.
Done properly, they are not inefficient and do not have duplicate data either.
Take a look at FaceBook. How many many-to-many relationships exist between friends and friends of friends? That is a well-defined business need.
The statement that "many-to-many relationships can't exist in a relational database." is patently false.
Many-to-many relationships are in fact very useful, and also common. For example, consider a contact management system which allows you to put people in groups. One person can be in many groups, and each group can have many members.
Representation of these relations requires an extra table--perhaps that's what your book is really saying? In the example I just gave, you'd have a Person table (id, name, address etc) and a Group table (id, group name, etc). Neither contains information about who's in which group; to do that you have a third table (call it PersonGroup) in which each record contains a Person ID and a Group ID--that record represents the relation between the person and the group.
Need to find the members of a group? Your query might look like this (for the group with ID=1):
SELECT Person.firstName, Person.lastName
FROM Person JOIN PersonGroup JOIN Group
ON (PersonGroup.GroupID = 1 AND PersonGroup.PersonID = Person.ID);
It is correct. The Many to Many relationship is broken down into several One to Many relationships. So essentially, NO many to many relationship exists!
Well, of course M-M relationship does exist in relational databases and they also have capability of handling at some level through bridging tables, however as the degree of M-M relationship increases it also increases complexity which results in slow R-W cycles and latency.
It is recommended to avoid such complex M-M relationships in a Relational Database. Graph Databases are the best alternative and good at handling Many to Many relationship between objects and that's why social networking sites uses Graph databases for handling M-M relationship between User and Friends, Users and Events etc.
Let's invent a fictional relationship (many to many relationship) between books and sales table. Suppose you are buying books and for each book you buy needs to generate an invoice number for that book. Suppose also that the invoice number for a book can represent multiple sales to the same customer (not in reality but let's assume). We have a many to many relationship between books and sales entities.
Now if that's the case, how can we get information about only 1 book given that we have purchased 3 books since all books would in theory have the same invoice number? That introduces the main problem of using a many to many relationship I guess. Now if we add a bridging entity between Books and sales such that each book sold have only 1 invoice number, no matter how many books are purchases we can still correctly identify each books.
In a many-to-many relationship there is obvious redundancy as well as insert, update and delete anomaly which should be eliminated by converting it to 2 one-to-many relationship via a bridge table.
M:N relationships should not exist in database design. They are extremely inefficient and do not make for functional databases. Two tables (entities) with a many-to-many relationship (aircraft, airport; teacher, student) cannot both be children of each other, there would be no where to put foreign keys without an intersecting table. aircraft-> flight <- airport; teacher <- class -> student.
An intersection table provides a place for an entity that is dependent on two other tables, for example, a grade needs both a class and a student, a flight needs both an aircraft and an airport. Many-to-many relationships conceal data. Intersection tables reveal this data and create one-to-many relationships that can be more easily understood and worked with. So, the question arises, what table should the flight be in--aircraft or airport. Neither, they should be foreign keys in the intersection table, Flight.
I've been learning database design and I'm confused about 1:1 relationships. From what I understand, you can simply add columns to the appropriate table. Can someone provide a real world example of where a 1:1 relationship was either necessary or provided some significant benefit? I.e., where would I use a 1:1 relationship and what would it look like?
I'll give you a real practical example.
In the medical billing world, doctors who want to get paid by medicare handle billing by creating a dictation report for each visit with a patient. This might actually be a recorded audio dictation transcribed by a secretary, but more often it's just a written description of what they did and talked about with the patient, along with history, impressions, and so forth. A licensed medical coder will then read this dictation and decide what the doctor is allowed to bill.
Separate from the dictation, there is demographic information about the patient involved: name, age, billing address, etc. This information must be strictly separate from information about the dictation, to prevent coders from allowing bias to cloud their billing judgements or violating patients' privacy.
This data is often kept well-normalized with a 1:many relationship in the data systems at the point of origin, and only the right parts are displayed to the right people at the right times. However, a significant number of offices out-source their billing function to a third party. This way a small clinic, for example, doesn't have to keep a licensed medical coder on staff; one coder at the billing office can handle the needs of many clinics. When the data is sent from the clinic to the billing office, the patient demographic information and the dictations need to come over as separate pieces, possibly at separate times. At this point, they'll likely be stored in completely separate tables with a 1:1 relationship and a shared ID field to match them up later.
In this case, the 1:1 relationship has very little to do with the data model. You could probably match up the records at the time of import, and as a bill moves through the system eventually the provincial patient information received in the clinic's demographic record will be matched to a real person so the 1:many relationship can be restored. Otherwise you'd get a separate statement on a separate account for each visit to the doctor.
Instead, it has almost everything to do with the systems design. There are likely entirely different people building and using the billing part verses the coding part at our imaginary billing service. This way, each side can each have full control of it's own fiefdom, and you are sure that no one, not even a developer, is breaking any privacy rules.
True one-to-one relationships seldom
occur in the real world. This type of
relationship is often created to get
around some limitation of the database
management software rather than to
model a real-world situation. In
Microsoft Access, one-to-one
relationships may be necessary in a
database when you have to split a
table into two or more tables because
of security or performance concerns or
because of the limit of 255 columns
per table. For example, you might keep
most patient information in
tblPatient, but put especially
sensitive information (e.g., patient
name, social security number and
address) in tblConfidential (see
Figure 3). Access to the information
in tblConfidential could be more
restricted than for tblPatient. As a
second example, perhaps you need to
transfer only a portion of a large
table to some other application on a
regular basis. You can split the table
into the transferred and the
non-transferred pieces, and join them
in a one-to-one relationship.
That's a quote from here: Fundamentals of Relational Database Design
And here's a similar question on SO.
Another reason I can see for using a 1:1 (where I have used it in the past) is if you have a table with a lot of columns, and only a few of them are involved in very intensive and frequent queries which need to be fast, I would break it into two tables that are related 1:1 where I could query the lightweight table and get good performance, but still have the other data related to it easily with a simple join.
I belief tables should be designed with the domain background. So if those columns form two different entities, they should not be mixed in one table. From my experience 1:1 relationships tend to evolve into 1:n relationships over time.
For example you may want to store the postal address of a person. But after some time, you are required to store more than one address per person. Refactoring programs from a 1:1 relationship into 1:n is usually a lot easier than extracting some columns from an old table into a new one.
Many database systems allow defining of access permissions per table in a very easy way. But defining permissions on individual columns is often quite painful.
It's useful if X has a 1:1 relationship with Y and Z also has a 1:1 relationship with Y. Y can be abstracted out into a shared table rather than duplicating in both X and Z.
EDIT: A real world example would be Customers, Companies, and Addresses. There can be a N:N relationship between Customer and Company. But both Customer and Company have 1:1 relationships with Address. Some Address rows could be related to both a Customer and a Person.
First, because they are talking about Access (Jet, Ace, whatever) -- credit to #Richard DesLonde for spotting this -- then they are probably talking about 1:0..1 relationships. I do not believe true 1:1 relationships are workable in Access because it has no mechanism for deferring constraints nor executing multiple statements in a SQL PROCEDURE. Most Access practitioners are satisfied to use a 1:0..1 relationship to model a true 1:1 relationship, so I guess the authors are satisfied to use the term "1:1" informally to refer to both.
Of course, 1:1 and 1:1..0 relationships are common enough in the real world. I rather think they are trying to convey the (valid) point that some 1:1 and 1:1..0 relationships are invented in a data model for business purposes.
Consider a "natural person" (i.e. human) and a "corporation". They have no attributes in common (sure, both have a "name" but their domains are different e.g. "natural person name" has sub atomic domains for "family name", "given name" and "title", etc).
However, in a given data model distinct entity types may play the same role. For example, both a "natural person" and a "corporation" can be the officer of a "corporation". In the data model, we could have two distinct entity types "natural person officers" and "corporate officers" that are likely to have many attributes in common and from the same domains e.g. appointment date, termination date, etc; further, they business rules would be the same e.g. appointment date must be before termination date. Also, both would participate in equivalent relationships e.g. "natural person representing", etc.
The data model could be 'split' at high level, resulting in pairs of very similar tables e.g. "natural person officer" and "corporate officer", "natural person officer natural person representing" and "corporate officer natural person representing", etc.
However, another approach is to model the common attributes and relationships using a fabricated entity type. For example, both a "natural person" and a "corporation" could be considered to be a "legal person" (aside: there is such a concept of "legal person" in law but does this mean the same as existing in the real world?!)
Therefore, we could have a superclass table for "legal persons" and subtype tables for "natural persons" and "corporations" respectively. The "officers" table would reference the "legal persons" table. All subsequent relationship tables could reference the "officers" table, which would half the number of tables from this point down.
There are practical problems to such a 'subclassing' approach. Because a "natural person" and a "corporation" has no attributes in common, they have no common key, therefore the "legal persons" table would need to have an artificial key, with all the problems that this entails, especially if it needs to be exposed in the application. Also, because the relationships between "legal persons", "natural persons" and "corporations" are truly 1:1 some DBMSs, as Access, will lack the necessary functionality to effectively implement them and many will have to settle for making them 1:0..1.
A 1:1 relationship is an abstract concept that you model in your data, but at the database level (assuming RDBMS) doesn't really exist. You always have a foreign key on one table pointing to another, so technically the parent table being pointed to by the FK could have multiple children. This is something you'll want to enforce in your business logic.
A good example of a 1:1 relationship in a modeling sense would be the relationship between employee and person. You have a person with certain data, then you have extra attributes on that same person that you put on an employee. A good way to think of this in OO programming terms is as inherited classes. The Employee class, inherits from Person. In fact may ORM systems will model the 1:1 relationship in the database with each table having a shared primary key.
I have to add functionality to an existing application and I've run into a data situation that I'm not sure how to model. I am being restricted to the creation of new tables and code. If I need to alter the existing structure I think my client may reject the proposal.. although if its the only way to get it right this is what I will have to do.
I have an Item table that can me link to any number of tables, and these tables may increase over time. The Item can only me linked to one other table, but the record in the other table may have many items linked to it.
Examples of the tables/entities being linked to are Person, Vehicle, Building, Office. These are all separate tables.
Example of Items are Pen, Stapler, Cushion, Tyre, A4 Paper, Plastic Bag, Poster, Decoration"
For instance a Poster may be allocated to a Person or Office or Building. In the future if they add a Conference Room table it may also be added to that.
My intital thoughts are:
Item
{
ID,
Name
}
LinkedItem
{
ItemID,
LinkedToTableName,
LinkedToID
}
The LinkedToTableName field will then allow me to identify the correct table to link to in my code.
I'm not overly happy with this solution, but I can't quite think of anything else. Please help! :)
Thanks!
It is not a good practice to store table names as column values. This is a bad hack.
There are two standard ways of doing what you are trying to do. The first is called single-table inheritance. This is easily understood by ORM tools but trades off some normalization. The idea is, that all of these entities - Person, Vehicle, whatever - are stored in the same table, often with several unused columns per entry, along with a discriminator field that identifies what type the entity is.
The discriminator field is usually an integer type, that is mapped to some enumeration in your code. It may also be a foreign key to some lookup table in your database, identifying which numbers correspond to which types (not table names, just descriptions).
The other way to do this is multiple-table inheritance, which is better for your database but not as easy to map in code. You do this by having a base table which defines some common properties of all the objects - perhaps just an ID and a name - and all of your "specific" tables (Person etc.) use the base ID as a unique foreign key (usually also the primary key).
In the first case, the exclusivity is implicit, since all entities are in one table. In the second case, the relationship is between the Item and the base entity ID, which also guarantees uniqueness.
Note that with multiple-table inheritance, you have a different problem - you can't guarantee that a base ID is used by exactly one inheritance table. It could be used by several, or not used at all. That is why multiple-table inheritance schemes usually also have a discriminator column, to identify which table is "expected." Again, this discriminator doesn't hold a table name, it holds a lookup value which the consumer may (or may not) use to determine which other table to join to.
Multiple-table inheritance is a closer match to your current schema, so I would recommend going with that unless you need to use this with Linq to SQL or a similar ORM.
See here for a good detailed tutorial: Implementing Table Inheritance in SQL Server.
Find something common to Person, Vehicle, Building, Office. For the lack of a better term I have used Entity. Then implement super-type/sub-type relationship between the Entity and its sub-types. Note that the EntityID is a PK and a FK in all sub-type tables. Now, you can link the Item table to the Entity (owner).
In this model, one item can belong to only one Entity; one Entity can have (own) many items.
your link table is ok.
the trouble you will have is that you will need to generate dynamic sql at runtime. parameterized sql does not typically allow the objects inthe FROM list to be parameters.
i fyou want to avoid this, you may be able to denormalize a little - say by creating a table to hold the id (assuming the ids are unique across the other tables) and the type_id representing which table is the source, and a generated description - e.g. the name value from the inital record.
you would trigger the creation of this denormalized list when the base info is modified, and you could use that for generalized queries - and then resort to your dynamic queries when needed at runtime.