I have searched everywhere and although there is plenty of information I only get more confused each time.
So, with that said, I want to ask you how important are relationships. I'm talking about diagram relationships. I've been told that if the querys are well done it works just fine. So, my question remains... How important is it?
That and, refering to table relationships and their primary/foreign keys, for two tables to be able to have a relationship between a primary and a foreign key does one of them have to have only one key? For instance, I have these two tables, in the image bellow, that I want to make a relationship between id_utilizador from Utilizadores and id_utilizador from Apostas. But I get an error, while trying to make it (also in an image bellow). I you could help undestand why I'd very much appreciate it.
Related
I'm creating an ERD and in this m:n relationship I'm trying to indicate that there is a composite key in the LOCATION entity (by combining Location_ID and Department_ID). I realise that this will involve a joining table when it comes to creating a table relationship diagram, but in the ERD, is this notation correct to indicate a composite key?
Your PK,FK demonstration is technically not wrong but for an ERD you ultimately want to remove all many to many relationships otherwise it will cause you more problems down the line. You especially want to remove relationships like this if you have a composite key.
Here's a quick example of how i would do it roughly. (i could do a better one if i understood more info on your scenario and other tables etc...)
You ideally want to create another entity which holds both primary keys from the other tables and therefore creates a composite key. Notice, this also removes the many to many relationships.
I hope this gives you more of an understanding :)
I recently started looking into Database design. I have worked with Oracle, but would now like to create logical or conceptual design relationships first, before I implement them into the database. Learning the basics you could say.
I would like to create a database for cars. I have some tables, but am having trouble with the relationships, and when to use a foreign key/extra table.
I have created a car table, and added attributes. Now it is very clear to me to use a manufacturer foreign key in the car table referencing the manufacturer table.
But for example I would like to show what type(SUV, sedan, etc.) the car is. Furthermore I would like to show What class(normal, Upperclass, etc.) the car is. Since I will only differentiate between a maximum of 5 car types, do I still need to add a foreign key? Same goes for the Class Situation as well.
I have heard to always use a foreign key, because it safeguards the integrity of the database, but at University my teacher always told us to use the Minimum amount of tables as possible, therefore putting me in an awkward spot.
What should I do?
I would greatly appreciate clarification in this matter.
Even in toy systems, you should use foreign keys and extra tables; learning this habit will serve you well when the database gets larger, or when you start designing real databases.
I imagine that the remark about "minimum amount of tables" (should be "minimum number") is to prevent you creating tables containing two values (e.g. "yes" and "no", "present" and "not present"), again a good habit to learn. It could also refer to queries, where you do not want to join unnecessary tables; this is liable to lead to the query retrieving duplicate rows.
Car type and car class are examples of what is called an enumerated domain. A domain is the set of values that an attribute may take on. In Oracle terms it's the set of values that may be placed in a given column. Oracle, unlike some other SQL dialects, does not have a CREATE DOMAIN statement. You may be able to use CREATE TYPE instead but I can't tell you how.
The simplest solution for you may be to just create a lookup table, as you suggest. Don't worry too much about added complexity here.
It is easier to manage 100 tables than 100,000 lines of code. That's an old slogan from the dba world, but it has some truth to it.
One of my team's big tasks this year is to overhaul and normalize our legacy database structure. Many columns used by the application as foreign keys don't actually have a foreign key relationship defined in the database, and we are in the process of fixing that.
I'm wondering if there is a nice, succinct way of describing such a situation where there's a column that's clearly supposed to be a FK but is not defined in the database. I've been using "unofficial foreign key" or "loose foreign key" but usually those terms aren't clear enough and I have to explain what I mean (which is of course doable but takes a little time).
I haven't found any answers on Google, most results just describe why defining a FK is better. I'm also relatively new to DB design so perhaps I'm just thinking about this the wrong way.
Is there such a term?
"Fake" might get the point across more clearly, or, since foreign keys are a type of constraint, calling it "unenforced" would be more idiomatic.
I'm not a DB design expert and have what I suspect is a newbie question. If it's better answered in another forum (or from a simple reference), please let me know.
Given a Table "Recordings" and a table "Artists". Both tables have primary keys suitably defined. There is a relationship that we want to express between these tables. Namely, An artist could have many recordings, or no recordings. A recording can only have 1 or 0 artists. (We could have some obscure recording with no known artist).
I thought the solution to this problem was to have a foreign key pointing to artist in the Recording Table. This field could be null (the recording has no artist). Additionally, we should define cascading deletes, such that if an artist is deleted, all recordings that have a foreign referring to that artist, now have a foreign key of null. [I really do want to leave the actual recording when you delete the artist. Our real tables are not "artists" and "recordings" and a recording can exist without an artist].
However, this is not how my colleagues have set things ups. There is no foreign key column in 'Recordings', but rather an extra table 'RecordingArtist_Mapping' with two columns,
RecordingKey ArtistKey
If an Artist (or Recording) is removed, the corresponding entry in this mapping table is removed. I'm not saying this is wrong, just different to what I expected. I have certainly seen a table like this when one has a many-many relationship, but not the relationship I described above.
So, my questions are:
Have you heard of this way of describing the relationship?
Is there a name for this type of table?
Is this a good way to model the relationship or would be be better off with the foreign key idea I explained? What are the pros/cons of each?
My colleagues pointed out that with the foreign key idea, you could have a lot of nulls in the Recordings Table, and that this violates (perhaps just in spirit?) one of the Five Normal Forms in Relational Database Theory. I'm way out of my league on this one :) Does it violate one of these forms? Which one? How? (bonus points for simple reference to "Five Normal Forms" :) ).
Thank you for your help and guidance.
Dave
On the face of it, this it simply an intersection table that allows a many-to-many relationship between two other tables.
When you find that you need one of these it is generally a good idea to consider "what does this table mean", and "have I included all the relevant attributes".
In this case the table tells you that the artist contributed to the recording in some way, and you might then consider "what was the nature of the contribution".
Possibly that they played a particular instrument, or instruments. Possibly they were a conductor.
You might then consider whether people other than artists made a contribution to the recording -- sound engineer? So that leads you to consider whether "artist" is a good table at all, because you might instead want a table that represents people in general, and then you can relate any of them to a recording. Maybe you even want to record the contribution of a non-person -- the London Symphony Orchestra, for example.
You can even have entities that contribute in multiple ways -- guitarist, vocalist, and producer? You might also consider whether there ought to be a ranking of the contributions so that they are listed in the correct order (which may be a contractual issue).
This is exactly the way that contributions to written works are generally modelled -- here is a list of the contributor codes used in the ONIX metadata schema for books, as an illustrative industry example: https://www.medra.org/stdoc/onix-codelist-17.htm
Your solution with a foreign key in Recording is absolutely correct from the Normalization Theory point of view, it does not violate any significant normal form (the most important one are Third Normal Form, and Boyce-Codd Normal Form, and neither of them is violated).
Moreover, a part being conceptually simpler and safe, from a practical point of view it is more efficient, since it in general reduces the number of joins that must be done. In may opinion, the pros are greater than the cons.
Yes, that's a viable setup, this is called vertical partitioning.
Basically, you move your artist field from recording to another table with the primary key referencing that on recording.
The benefit is you don't necessarily have to retrieve artists with doing lookups on recordings, the drawback is that if you still have to, if would be somewhat slower, because of an extra join.
Have you heard of this way of describing the relationship?
Yes, it's a many to many relationship. A recording can have more than one artist. An artist can have more than one recording.
Is there a name for this type of table?
I call them junction tables.
Is this a good way to model the relationship or would be be better off with the foreign key idea I explained? What are the pros/cons of each?
A junction table is required in a many to many relationship. When you have a one to many relationship, you would use a foreign key in the many table.
As far as 4th level and 5th level database normalization, this A Simple Guide to Five Normal Forms in Relational Database Theory article from 1982 explains the different levels.
Under fourth normal form, a record type should not contain two or more independent multi-valued facts about an entity.
Fifth normal form deals with cases where information can be reconstructed from smaller pieces of information that can be maintained with less redundancy.
I remember the first 3 levels of normalization with this sentence.
I solemnly swear that the columns rely on the key, the whole key, and nothing but the key, so help me Codd.
I'm in the process of creating a social network. It has several entities like news, photo, which can have comments. Since all comments have the same columns and behave the same way, and the only difference is their type — news, or photo, or something else to be added in the future — I decided to create one table for all comments with a column named type. It worked perfectly until I decided to add foreign keys to my database schema.
The comment table have a column parent, which refers to id of news or photo table, depending on the column type.
The problem is, I can't add a foreign key which refers to the unknown in advance table, and even more, which refers to several tables at once.
The whole database now uses foreign keys, except this one parent column in the comment table. It bothers me because it's the only place where I can't add a foreign key.
I'm sure I can't create such a foreign key; something in my database design needs to be changed. I decided to create one table for comments to be ready to add new comment types for new entities in the future — video, music, article, etc — and don't run into maintenance hell when I want to add one new column for all comments.
If I absolutely have to create a separate table for each comment type to be able to use foreign keys fully, I'll do that. But maybe another common solution to this problem already exists, and I'm just not aware of it?
Maybe I should create some sort of link table, which links the comment table with other entities' tables? But maybe this solution is even more complex than creating a separate table for each comment type?
Maybe I should have several columns in the comment table, like newsId, photoId, to which I can add foreign key?
These solutions just don't seem elegant to me, or I just misunderstand something. My whole perception of this issue might be plain wrong. That's why I'm here. Please share your ideas.
I think your problem is that you have several entities - news, photos. But these are all just types of (say) items. Like comments,items will probably have some attributes in common as well as some distinct attributes. One of those attributes will be the ability to be commented upon.
In this approach you have a table CommentableItems (1), with the common attributes. Then you have some sub-tables NewsItems, PhotoItems, etc. It is quite easy to set-up the keys for these tables to enforce the required one-to-one relationship. Obviously, Comments has a foreign key which references CommentableItems.
(1) Actually I would probably shoot myself rather than allow a table called something as ghastly as CommentableItems into my schema, but this is just for the sake of example.