I just had a quiz and one of the questions was to pick the correct description of the following ER diagram (with A and B instead of E1 and E2):
The correct answer was:
Every instance of data type A is related to many instances of data type B, and every instance of data type B is related to many instances of data type A.
My answer was:
An instance of data type A is related to many instances of data type B and an instance of data type B is related to many instances of data type A.
Isn't this absolutely the same from a linguistics standpoint?
I have researched the topic thoroughly but I cannot come to a conclusion what is the correct answer here. Is one more correct than the other or both are correct?
This is indeed tricky and subtle, and the quizz wording is moreover ambiguous. However there is a difference and the quizz is right.
What you described is a normal N:M relationship with partial relationship. The correct wording would be:
An instance of data type A can be related to many instances of data type B and an instance of data type B can be related to many instances of data type A.
The key difference in your answer is that there could be some A and and some B that do not participate in the relationship. But this would be the correct answer if the diagram would have used simple lines with the relation.
But the quizz diagram uses a double line. This is not graphical fancyness, but expresses total participation. This means that every A and every B must participate to the relation. In other words, there can be no A that isn’t related to at least a B, and vice-versa. This is why the correct answer is not what you expected.
However the correct answer is ambiguously worded because participating in the relation doesn’t require to necessarily be related to many entities on the other side; one is sufficient. A better wording could therefore be:
Every instance of data type A is related to one or more instances of data type B, and every instance of data type B is related to one or more instances of data type A.
By the way, ERD doesn’t use “data types” but “entities”. More information on Chen’s ERD notation here.
Related
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 am new in DB design,need advice to design correct number of tables and columns from excel sheet with this columns:
If multiple locations available or Foil is Y for a cardname then you see multiple rows for that cardname.
Identify the entities that your data model needs to represent.
An entity is briefly defined as: a person, place, thing, concept or event that can be uniquely identified, is important to the business, and we can store information about.
Also, identify the relationships between the entities.
The usual approach is consultation with the data owner/system owner; asking appropriate questions, throwing some ideas down in an entity relationship model, and asking further questions reviewing what is right about the model, and what isn't... altering and refining the model.
From the very brief description in the question, we would likely propose, as a starting point, some proposed entities: card and location.
Identify candidate keys:
What uniquely identifies a card?
What uniquely identifies a location?
Identify the cardinality of relationships (how many on each side of the relationship?
Can a location be related to more than one card?
Can a card have more than one location?
Must a card be related to a location (can we have a card that doesn't have a location?
etc.
Then, then assign the non-key attributes to the appropriate entities. Aim for third normal form.
"Each attribute is dependent on the key, the whole key, and nothing but the key. So help me Codd."
Lets say there are warehouses each storing items of a specific type.
So there are tables with fields
Warehouse - ID,Name,Type
Item - ID,Name,Type
WarehouseItem - Warehouse, Item
Type - ID, Name
The question is - given that a Warehouse only holds Items with of specific Type, what database normalization rule is this breaking?
Is this database normalized?
(The problem's example is made up, but I basically have this problem in real life.)
I'm making some assumptions from just looking at your metadata without any data examples, but on first glance it appears that your schema for the most part is normalized. Technically speaking your table is 3NF (which should be your target) if it meets all of the following standards:
It is also 1NF - Each entry only contains atomic data (or a single piece of info)
It is also 2NF - No candidate key dependency meaning that when you have have a composite primary key (a key made up of more than one column) that all data is dependent on the entire key
It is 3NF - No transitive dependency meaning all data is only dependent on the primary key and not some other column in the table
Note that there are also higher normalized forms but they are mostly academic as you begin experiencing performance degradation the more you normalize
Given this definition:
Warehouse appears 3NF assuming that each warehouse can only have one Type. If not then you would be failing the transitive dependency and would need to move Type information to a new table.
Item too appears 3NF assuming only one Type can be assigned
Type appears to contain redundant data and should be removed unless of course you have a many-to-many relationship between Type and Warehouse and/or Item. In that case, you would want to introduce a bridge-entity (aka composite entry) between Type and Warehouse or Item to create two 1-to-many relationships.
Lastly, if I'm reading this correctly, WarehouseItem appears to be a bridge-entity between Warehouse and Item to break up the many-to-many relationship between them. If this is correct, you should be able to argue that this table is 3NF assuming the combination of Warehouse and Item represent a composite key.
So assuming I interpreted your schema correctly, once you eliminate the redundant Type table, then yes I would say this setup technically meets 3NF. Note that your requirement that
given that a Warehouse only holds Items with of specific Type
may require you introduce a new type field which will mean you need to reevaluate your normalization of that table. If you have two distinct types (a WarehouseType and an ItemType) then you may need to keep that Type table after all and turn it into a mapping table between those two new fields. But I'd need to see data examples to better evaluate.
I am creating a database containing books that I own and have read. I want to track both the book (or "title") that I own and read, and the edition (or "physical bound paper") of that book that I own and read.
Book and Edition are many-to-many. I own multiple editions of the book Democracy in America. I also own an edition called "Hemingway" that contains several books (or "titles"), including one called "For Whom the Bell Tolls".
Thus, I need a bridge between book and edition. My tables are:
Book (book_pk*,title)
Edition (edition_pk*,ISBN,year)
Book_Edition (book_fk,edition_fk)
I believe it is correct to say that the Book_Edition table contains a composite primary key.
Now, I am working on my Read table, which will contain the books that I have read and the date on which I read them. My read table so far contains:
Read (read_pk,date,note)
However, I now need to tie my Read table to my books and editions. It appears to me that book_fk and edition_fk are transitively dependent in this case. So how do I comply with the third normal form?
Option 1:
Modify the Read table to: Read (read_pk,date,note,book_fk,edition_fk)
Option 2:
Modify the Book_Edition table to: Book_Edition (book_edition_pk,book_fk,edition_fk)
Modify the Read table to: Read (read_pk,date,note,book_edition_fk)
Option 3:
???
Any insight would be appreciated. Apologies if this has been treated elsewhere; I saw a couple posts that looked promising but as a relative n00b I was not able to decipher them and apply them to my situation.
EDIT per sqlvogel:
Let me take a stab at identifying dependencies -- that is, I am trying to identify places where if Field A is changed, then Field B must or may change. I think I am finding this difficult because books (both "titles" and "collections of bound paper") are inherently permanent. The only time I would expect to edit the title, ISBN, or year fields would be if there is a data entry error. If the ISBN for a particular edition_pk is entered incorrectly, it's probably slightly more likely that the year for the same edition_pk was also entered incorrectly, but is that a dependency?
With respect to the read table, I believe the situation is similar. Records would be created each time a book is read, and theoretically never edited. I want to identify the book and edition that were read on a particular date. If there is a data entry error, it might affect one or more of the fields. In particular, if the wrong book_fk is entered, it's probably more likely that the wrong edition_fk was entered too. Again, is that a dependency I should be worried about?
Is there anything else I need to consider when thinking about dependencies?
Option 1: Read (read_pk,date,note,book_fk,edition_fk)
Assumptions:
{read_pk}->{date,note,book_fk,edition_fk}
{read_pk} is the primary key of Read.
For the sake of example just suppose that {book_fk,edition_fk}->{date}, meaning that each book is read only once (only a single date per book/edition). If you didn't make {book_fk,edition_fk} a candidate key in Read then {book_fk,edition_fk}->{date} would be an example of a non-key dependency in violation of 3NF because the determinant is not a key. The same would be true even if you substituted {book_edition_fk} in place of {book_fk,edition_fk}. i.e. your Option 2 is apparently the same as Option 1 as far as 3NF is concerned.
Since you haven't specified any dependencies I have just given this as an example. I can't say whether those dependencies would be a correct description of your situation. You yourself need to determine what dependencies actually should be in force here.
Transitive dependencies require the dependent attribute to be a non-key attribute. Since the two attributes you're concerned about are foreign keys, you do not have a transitive dependency problem in your structure.
You do not need to alter the original design.
Let's say that I have a MySQL table that I wish to use to use to model a relationship between two entities (A and B, for example). There are three columns: Person1, Person2, and Relationship. Let's further say that A and B are persons in this table and could have one of several relationship types, such as being friends, one requesting the other to be a friend, and so forth.
Is it possible (and preferable?) to use one row to do this? It seems like having one row that represents the A->B part of the relationship and another for the B->A part of the relationship would be a somewhat fragile setup, since if either of the two ever neglects to be updated the model could be in a rather odd state (A thinks B is a friend, B thinks A is something else).
The other part of my question is: how would efficient look-ups work? If there was only one row to represent the relationship, wouldn't all queries need to do a SELECT to check whether it is in the Person1 field or the Person2 field? Is there a nicer way of modelling this type of data?
(I realize this explanation is a little rough; please let me know if you'd like any clarification.)
You could have a column for the person who requested the relationship, the "requestee", the type of relationship (friend, etc), and whether the relationship has been approved by the "requestee"