I would like to know if it's mandatory for my database to have the same tables as my ERD diagram?
In my ERD I have 5 tables...:
I have a database that only has 2 tables:
Booking (C_Name, C_Phone, B_Date, S_Time, Ach,)
C_NAME: customer name
C_Phone: customer phone number
B_Date date of booking
S_Time: booking start time
Ach: achieved
Food(Meal_Name, Meal_Cost)
The customer information is already in the booking table. Is it necessary to create an order table? For the employee table, there is a relationship between other tables, however, this information is not required in my database...
Any ideas? Thanks
Definitely not. An ERD diagram is usually for the logical data model. The most obvious situation is when it contains a many-to-many relationship. Such a relationship would generally be represented using a junction/association table.
Under other circumstances, you might want to combine different but similar entities into a single table (for instance, to handle one-of relationships). Or, you may decide to represent some relationships using nested tables or similar mechanisms. There may be more arcane requirements that call for splitting tables as well.
For your particular model, I would expect one table per entity. You need additional junction/association tables to handle the employee relationships to order and meal.
Related
Are there any drawbacks to storing addition data in my join table
/ junction table.
For example, I am working on a database of trucking companies and I have 3 tables:
Table 1 - company,
Table 2 - trailer_type,
Table 3 - junction_table,
Each company can have more than one trailer type, but I also need a trailer count of each trailer type per company. The most logical place to put the trailer count would seem to be in the junction table with the company.id and trailer_type.id.
Are there any drawbacks to doing it this way, and, if so, is there a better way?
From the way you phrased the question, I think your intuition is mostly correct. You identified the junction table as the place to keep your counts. But you're hesitating, apparently because it's a "junction table".
All tables are created equal. From the point of view of SQL, there are no fact tables, no dimension tables, no junction tables. There are only tables.
A normalized design denotes a minimal key to identify each row. In your case, the natural key of the junction table is something like {company_id, trailer_type_id}. Is there information that's functionally dependent on that key? Why, yes, there is: ntrailers. Thus a column is born.
So don't worry about what kind of table it is. Think about what the row means, and how it's identified. That will keep you on the fairway.
First, it is fine to store additional information in the junction table. For instance, the date created is often very interesting. And, there are many examples of entities that you can think of as junction tables -- say a billing record that connects a customer to an invoice -- and the records naturally have additional fields.
However, the count is not something that you would store under ordinary circumstances. This type of information should go in the Company table, particularly if it is fixed over time.
If it is not fixed, two options come to mind. The first is a slowly changing dimension where you store the number of trailers for a company along with effective and end dates for the value. A viable alternative is to store the value in the junction table. It is not the first choice, but it might be a good solution under many circumstances.
You may wish to think of your schema a little differently than as a many-to-many relationship between companies and trailers: that's the reason you have a junction table.
How about thinking of it this way:
Companies have a one-to-many relationship with Trailers
Trailers have a many-to-one relationship with TrailerDescriptions.
So, your Trailer table will have these columns:
company_id
trailer_description_id
count
etc.
You might even choose to enumerate the individual trailers, by adding columns and setting "count" to 1.
trailer_id
company_id
trailer_description_id
count = 1
date_placed_in_service
license_plate_number
etc.
Are there any hard and fast rules against creating a junction table out of a table's primary key? Say I have a table with a structure similar to:
In this instance there are a list of items that can be sold together, but should be marked as dangerous. Any one item can have multiple other items with which it is dangerous. All of the items are uniquely identified using their itemId. Is it OK to refer a table to itself in a many-to-many relationship? I've seen other examples on SO, but they weren't SQL specific really.
This is the correct design for your problem, as long as your combinations can only be two-item combos.
In database design a conceptual design that renders a relation in many-to-many form is converted into 2 one-to-many in physical design. Say for example a Student could take one or many courses and a course could have many students, so that's many to many. So, in actual design it would be a Student table, Course table then CourseTaken table that has both the primary key of Student and Course table thus creating 2 one to many relayionship. In your case altough the two tables are one and the same but you have the virtual third table to facilitate the 2 one to many relationship so that to me is still very viable approach.
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 have a trip (primary: idTrip), where I can link more packages (primary: idPackage), so, I got a relationship table to link trips with packages (primary: idRelTripPackage). (relationship n-to-n)
And next I got a registrations table (primary: idRegistration). How do I best link those (1-to-1 relationship)?
I add two columns in the registrations table (idTrip, idPackage)?
I add a relationship table where i link idRegistration, idTrip, idPackage?
I add a relationship table where i link idRegistration, idRelTripPackage?
Am I right in thinking the relation from Registrations is to RelTripPackage, and its definitely one-to-one. There are a couple of options:
1: As it really is a one-to-one there's not really anything to stop you putting the Registrations data directly onto RelTripPackage, or doing the vice-versa and putting idPackage and idTrip straight onto Registrations as FKs, with a unique key across the two FK columns to ensure there aren't duplicates.
2: If do want the two separate tables then just add idRetTripPackage to Registrations as an FK, and then add a unique constraint on it - again to ensure uniqueness.
There's no need for a separate relationship table as its a 1-1 relationship - They only really become relevant when you are using an n-n. The rest of the time FKs should be placed directly on the child table.
If you follow that logic, you will
add tables and Relations every time you need to add Relations
end up with confusing or duplicate Relations (multiple paths between any two tables)
However the problem (limiting factor) is that the tables you are starting with are not actually normalised. Since the starting position does not have a good basis, you will end up with far more Relations (in tables) than there actually are between the Entities. So the best advice is, the Best practice is, before you attempt this current extension, step back and normalise the data, the existing tables. Then the extension will be much easier, and you will end up with less tables.
if you provide info re the tables (Person, Trip, Package, etc); what exactly is a Registration, etc ... I can provide more explicit answers.
Generally any attribute that is 1::1 with the PK of an Entity should be an attribute in that entity. Any attribute that is 1::0-1 with the PK of an Entity should be in a separate table.
ER Diagram
Based on the information provided, this is your ▶Entity Relation Diagram◀. As long as you use Relational Identifiers, all the Relations you have identified thus far are supported directly (otherwise, if you use IDs, you will need more Relations and tables).
Readers who are unfamiliar with the Relational Database Modelling standard may find ▶IDEF1X Notation◀ useful.
Coming from question “Relation” versus “relationship”
What are definitions of "relation" vs. "relationship" in RDBMS (or database theory)?
Update:
I was somewhat perplexed by comment to my question:
"relation is a synonym for table, and
thus has a very precise meaning in
terms of the schema stored in the
computer"
Update2:
Had I answered incorrectly that question , in terms of RDBMS, having written that relation is one-side direction singular connection-dependence-link,
i.e. from one table to another while relationship implies (not necessarily explicitly) more than one link connection in one direction (from one table to another)?
A RELATION is a subset of the cartesian product of a set of domains (http://mathworld.wolfram.com/Relation.html). In everyday terms a relation (or more specifically a relation variable) is the data structure that most people refer to as a table (although tables in SQL do not necessarily qualify as relations).
Relations are the basis of the relational database model.
Relationships are something different. A relationship is a semantic "association among things".
Relation is a mathematical term referring to a concept from set theory. Basically, in RDBMS world, the "relational" aspect is that data is organized into tables which reflect the fact that each row (tuple) is related to all the others. They are all the same type of info.
But then, your have ER (Entity Relationship) which is a modeling methodology in which you identify objects and their relationships in the real world. Then each object is modelled as a table, and each relationship is modelled as a table that contains only foreign keys.
For instance, if you have 3 entities: Teacher, Student, Class; then you might also create a couple of tables to record these 2 relationships: TaughtBy and StudyingIn. The TaughtBy table would have a record with a Teacher ID and a Class ID to record that this class is taught by this teacher. And the StudyingIn table would have a Student ID and a Class ID to reflect that the student is taking this class.
That way, each student can be in many Classes, and each Teacher can be in many classes without needing to have a field which contains a list of class ids in any records. SQL cannot deal with field containing a list of things.
A relation is a table with columns and rows.
and
relationship is association between relations/tables
for example employee table has relation in branch its called relationship between employee table and branch table