CREATE TABLE Album (
name VARCHAR(50),
lenght FLOAT,
genre VARCHAR(30),
nrSongs INT,
PRIMARY KEY (name, writer),
FOREIGN KEY (writer) REFERENCES Musician(name) OR Band(name),
FOREIGN KEY (Studio) REFERENCES Studio(name)
);
Ok this is what I'm trying to do, I have two tables called Musician and Band, and in the foreign key called writer I want to use the name of a Musician or a Band, but this gives me an error in the OR statement, do you know the correct way to implement this? I can't find it.
Thanks :)
Not possible. A foreign key is a direct link between one field in one table, and another field in another table. It is 1:1. You cannot have n:1, 1:n, or n:n mappings in a foreign key definition.
Plus, your overall table definition is invalid. You have no writer field, so your primary key and the writer FK will fail anyways.
For this particular purpose, why not just making everyone a "band". A solo artist is simply a band that happens to have one member.
Related
I have a table that I want to make which is a bridge table for teacher and class table. This is the ERD
I initially thought I'm going to create this table by
CREATE TABLE class_teacher
(
teacher_id number(3),
class_id number(2),
CONSTRAINT class_teacher_pk
PRIMARY KEY(teacher_id, class_id),
CONSTRAINT class_teacher_teacher_fk
FOREIGN KEY(teacher_id) REFERENCES teacher(teacher_id),
CONSTRAINT class_teacher_class_fk
FOREIGN KEY(class_id) REFERENCES class(class_id)
);
But on the web I see people just having two foreign keys and no primary key, or table with no foreign key and having a primary key for two columns.
Am I doing it incorrectly?
Am I doing it incorrectly?
No, it looks correct.
Although I would question the size of the numeric data types as you are restricted to only have 1999 teachers and 199 classes (including negative numbers); this may be enough for immediate use but after several years when classes get re-organised or when the syllabus is re-written and new classes are created then you may run out of primary keys.
Does create statement returns any error? Otherwise you should be good.
Try to insert some data in all 3 tables and run some delete statements to see how it goes.
I've been trying to create this table in my database. We were told to use Oracle-Apex for creating the database. So I keep getting this error that I cant solve:
If I remove the last line of the code, it creates the table fine without any errors.
Here are screenshots of the other tables being referenced here:
Company Table
Branch Table
IDK if this is a rookie mistake, I only learnt apex/sql in like an hour and went off to make the database. Thank you for helping me! :)
The column(s) referenced by a foreign key must have a unique index in the source table (or they must be the primary key of that table). Your code fails because of the following foreign key declaration, where the target is not unique:
foreign key (BranchNo) references Branch(BranchNo)
Here, I think that you want a compound foreign key that references the primary key of Branch rather than two different keys. Branch(CCode) references Company(CCode) already so there is no need to put that relationship in the Equipment table.
create table Equipment(
CCode int,
BranchNo int,
EquipNo it,
Description varchar2(50),
NumberOfEquip int,
primary key(CCode, BranchNo, EquipNo),
foreign key (CCode, BranchNo) references Branch(CCode, BranchNo)
);
I'm trying to create a procedure that inserts data into a table of registers but i don't want to repeat the second parameter, this is the table
CREATE TABLE Inscription
(
idClass INT references tb_class,
idStudent INT references tb_student,
)
The idea is that a student (idStudent) can register in various classes but not in the same class (idClass), I tried to add a unique constraint in the idStudent column but that only allows a student to register in one single class.
I always suggest that all tables have a numeric primary key. In addition, your foreign key references are not correct. And what you want to do is add a unique constraint.
The exact syntax depends on the database. The following is for SQL Server:
CREATE TABLE Inscriptions (
idInscription int identity(1, 1) primary key
idClass int references tb_classes(idClass),
idStudent int references tb_students(idStudnt)
unique (idClass, idStudent)
);
Notice that I name the tables as the plural of the entity, but the id using the singular.
The Inscriptions table probably wants other columns as well, such as the date/time of the inscription, the method, and other related information.
You are looking to create a constraint on your table that includes both columns idClass and idStudent.
Once that constraint is created, an attempt to insert duplicate class/student will result in an error being raised.
As your table does not seem to include a primary key, you would better make that constraint your primary key.
NB : you did not tell which RDBMS you are using hence cannot give you the exact syntax to use...
Your unique key needs to encompass both idClass and idStudent, so any particular combination cannot repeat itself.
I want to define a foreign key constraint between the table Speler and the table Wedstrijd. I want the key on the Wedstrijd table, but when I use this code in my SQL console:
ALTER TABLE Speler
ADD FOREIGN KEY (idSpeler) REFERENCES Wedstrijd(idWedstrijd);
It puts a key on the table Speler and on the table Wedstrijd
Thanks for your time!
ALTER TABLE Wedstrijd
ADD FOREIGN KEY (idWedstrijd) REFERENCES Speler(idSpeler);
Instead of "solving" what you perceive as your problem, I think you have a different problem:
By mapping idSpeler to idWedstrijd, you are basically saying that a Speler (Player) is equal to a Wedstrijd (Match). That becomes a 1:1 relation which is then shown as a line with two yellow 'key'-endings (assuming you are using SQL Server).
It is very likely to me that instead you need to create a linking table WedstrijdSpeler that sits between the other two tables.
Then the new table WedstrijdSpeler needs to be given 2 Foreign Keys:
WedstrijdSpeler.idWedstrijd -> Wedstrijd.idWedstrijd
WedstrijdSpeler.idSpeler -> Speler.idSpeler.
Then you can give WedstrijdSpeler either a combined Primary Key (containing both fields idWedstrijd and idSpeler), or you can add a third field idWedstrijdSpeler and make that the Primary Key. Either approach will do, it is up to you.
I'm using Microsoft SQL Server Management Studio and while creating a junction table should I create an ID column for the junction table, if so should I also make it the primary key and identity column? Or just keep 2 columns for the tables I'm joining in the many-to-many relation?
For example if this would be the many-to many tables:
MOVIE
Movie_ID
Name
etc...
CATEGORY
Category_ID
Name
etc...
Should I make the junction table:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
Movie_Category_Junction_ID
[and make the Movie_Category_Junction_ID my Primary Key and use it as the Identity Column] ?
Or:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
[and just leave it at that with no primary key or identity table] ?
I would use the second junction table:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
The primary key would be the combination of both columns. You would also have a foreign key from each column to the Movie and Category table.
The junction table would look similar to this:
create table movie_category_junction
(
movie_id int,
category_id int,
CONSTRAINT movie_cat_pk PRIMARY KEY (movie_id, category_id),
CONSTRAINT FK_movie
FOREIGN KEY (movie_id) REFERENCES movie (movie_id),
CONSTRAINT FK_category
FOREIGN KEY (category_id) REFERENCES category (category_id)
);
See SQL Fiddle with Demo.
Using these two fields as the PRIMARY KEY will prevent duplicate movie/category combinations from being added to the table.
There are different schools of thought on this. One school prefers including a primary key and naming the linking table something more significant than just the two tables it is linking. The reasoning is that although the table may start out seeming like just a linking table, it may become its own table with significant data.
An example is a many-to-many between magazines and subscribers. Really that link is a subscription with its own attributes, like expiration date, payment status, etc.
However, I think sometimes a linking table is just a linking table. The many to many relationship with categories is a good example of this.
So in this case, a separate one field primary key is not necessary. You could have a auto-assign key, which wouldn't hurt anything, and would make deleting specific records easier. It might be good as a general practice, so if the table later develops into a significant table with its own significant data (as subscriptions) it will already have an auto-assign primary key.
You can put a unique index on the two fields to avoid duplicates. This will even prevent duplicates if you have a separate auto-assign key. You could use both fields as your primary key (which is also a unique index).
So, the one school of thought can stick with integer auto-assign primary keys, and avoids compound primary keys. This is not the only way to do it, and maybe not the best, but it won't lead you wrong, into a problem where you really regret it.
But, for something like what you are doing, you will probably be fine with just the two fields. I'd still recommend either making the two fields a compound primary key, or at least putting a unique index on the two fields.
I would go with the 2nd junction table. But make those two fields as Primary key. That will restrict duplicate entries.