CREATE TABLE TASK_SKILL (TASK_ID INT REFERENCES PROJECT_SCHEDULE_TASK(TASK_ID),
SKILL_ID INT REFERENCES PROJECT(PROJECT_ID),
NUMBER_OF_EMPLOYEES INT,
PRIMARY KEY (TASK_ID, PROJECT_ID, SKILL_ID));
Good day, I know my questions seem to be quite newbie-ish and is common sense for most of you here, but I am still trying to learn SQL
I encountered "ORA-00904: "PROJECT_ID": invalid identifier".
I have already checked and it looks like I have a Project_ID column but still, I can't seem to run it.
You are creating a table TASK_SKILL with 3 fiels: TASK_ID, SKILL_ID and NUMBER_OF_EMPLOYEES. Also you want to create a Primary Key by TASK_ID, PROJECT_ID, SKILL_ID. Oracle is right, you do not have a PROJECT_ID field in your table.
Your field is called SKILL_ID, so the Primary key should be created using it, like this:
CREATE TABLE TASK_SKILL (TASK_ID INT REFERENCES PROJECT_SCHEDULE_TASK(TASK_ID),
SKILL_ID INT REFERENCES PROJECT(PROJECT_ID),
NUMBER_OF_EMPLOYEES INT,
PRIMARY KEY (TASK_ID, SKILL_ID));
In the PK of a table you ony include fields from the table and not field from the related table. So, no need to include te referenced PROJECT_ID.
This happens because you are trying to create a table with a column that doesn't exist, in this case, PROJECT_ID. In the TASK_SKILL Table you only have 3 Columns defined:
TASK_ID, which is a foreign key of the PROJECT_SCHEDULE_TASK table
SKILL_ID, which is a foreign key of the PROJECT table.
NUMBER_OF_EMPLOYEES which is an integer.
Try to create the table like this:
CREATE TABLE TASK_SKILL (TASK_ID INT REFERENCES PROJECT_SCHEDULE_TASK(TASK_ID),
SKILL_ID INT REFERENCES PROJECT(PROJECT_ID),
NUMBER_OF_EMPLOYEES INT,
PRIMARY KEY (TASK_ID, SKILL_ID));
Lastly, if you're just starting out learning SQL, you can first lay the foundations of database design before going hands-on.
oracle documentation of foreign keys
Related
I am learning postgresql and I have created 2 tables: goals and results. Each table has a primary key which is formed by 3 columns:
id
valid_date_from
vald_until_from
I did this so that each row must be unique not only by its id but also depending on when the goal or result is still valid. Here is my sql code:
CREATE TABLE goals (
goal_id INT,
goal_title VARCHAR(80),
goal_description VARCHAR(300),
goal_valid_from_date TIMESTAMP,
goal_valid_until_date TIMESTAMP,
goal_deleted_flag BOOLEAN,
PRIMARY KEY (goal_id, goal_valid_from_date, goal_valid_until_date)
);
CREATE TABLE results (
result_id INT,
goal_id INT,
result_description VARCHAR(300),
result_target FLOAT,
result_timestamp DATE,
result_valid_from_date TIMESTAMP,
result_valid_until_date TIMESTAMP,
result_deleted_flag BOOLEAN,
PRIMARY KEY (result_id, result_valid_from_date, result_valid_until_date)
);
My goal now is to create a foreign key so that I am able to connect the 2 tables based on the goal_id column only and not the valid_from/until_date columns otherwise they would never match.
I tried to achieve this by using the following lines of code:
ALTER TABLE results
ADD FOREIGN KEY(goal_id)
REFERENCES goals(goal_id) on delete set null;
However I get an error:
SQL Error [42830]: ERROR: there is no unique constraint matching given
keys for referenced table "goal"
Would you be able to propose a smart and elegant way to achieve my goal?
it is very clear in the documentation
FOREIGN KEY ( column_name [, ... ] ) REFERENCES reftable [ ( refcolumn [, ... ] ) ]
you need to put the list of column_name
... so that I am able to connect the 2 tables based on the goal_id column only ...
As the error message already suggests, you need to add a matching UNIQUE CONSTRAINT:
ALTER TABLE goals
ADD CONSTRAINT u_goals_goal_id
UNIQUE (goal_id)
However, this constraint is more restrictive than your actual primary key, which might not be what you want, if your current design is on purpose and not by accident (see the comments of #MikeOrganek and #ErwinBrandstetter).
If it is what you want then you should consider making this your primary key instead.
For your exclusion problem (no two goals may have overlapping time periods) take a look at the example in the manual, it literally describes your case.
I need to create a table explaining how one representative reports to another but dont know quite how?
Create table Representative (RID int , TOID int, Rname varchar(10), Rphone varchar(15), PRIMARY KEY (RID), FOREIGN KEY (TOID) REFERENCES TourOperator);
The code above is my attempt but dont know how to introduce the reports to
do I create another variable called super_ID? and add it to table or how can i relate one representative to another in the table
Yes, you'd add another column (SUPER_ID) into the table which will be a foreign key, pointing to RID.
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 have these relationships:
User(uid:integer,uname:varchar), key is uid
Recipe(rid:integer,content:text), key is rid
Rating(rid:integer, uid:integer, rating:integer) , key is (uid,rid).
I built the table in the following way:
CREATE TABLE User(
uid INTEGER PRIMARY KEY ,
uname VARCHAR NOT NULL
);
CREATE TABLE Recipes(
rid INTEGER PRIMARY KEY,
content VARCHAR NOT NULL
);
Now for the Rating table: I want it to be impossible to insert a uid\rid that does not exist in User\Recipe.
My question is: which of the following is the correct way to do it? Or please suggest the correct way if none of them are correct. Moreover, I would really appreciate if someone could explain to me what is the difference between the two.
First:
CREATE TABLE Rating(
rid INTEGER,
uid INTEGER,
rating INTEGER CHECK (0<=rating and rating<=5) NOT NULL,
PRIMARY KEY(rid,uid),
FOREIGN KEY (rid) REFERENCES Recipes,
FOREIGN KEY (uid) REFERENCES User
);
Second:
CREATE TABLE Rating(
rid INTEGER REFERENCES Recipes,
uid INTEGER REFERENCES User,
rating INTEGER CHECK (0<=rating and rating<=5) NOT NULL,
PRIMARY KEY(rid,uid)
);
EDIT:
I think User is problematic as a name for a table so ignore the name.
Technically both versions are the same in Postgres. The docs for CREATE TABLE say so quite clearly:
There are two ways to define constraints: table constraints and column constraints. A column constraint is defined as part of a column definition. A table constraint definition is not tied to a particular column, and it can encompass more than one column. Every column constraint can also be written as a table constraint; a column constraint is only a notational convenience for use when the constraint only affects one column.
So when you have to reference a compound key a table constraint is the only way to go.
But for every other case I prefer the shortest and most concise form where I don't need to give names to stuff I'm not really interested in. So my version would be like this:
CREATE TABLE usr(
uid SERIAL PRIMARY KEY ,
uname TEXT NOT NULL
);
CREATE TABLE recipes(
rid SERIAL PRIMARY KEY,
content TEXT NOT NULL
);
CREATE TABLE rating(
rid INTEGER REFERENCES recipes,
uid INTEGER REFERENCES usr,
rating INTEGER NOT NULL CHECK (rating between 0 and 5),
PRIMARY KEY(rid,uid)
);
This is a SQL Server based solution, but the concept applies to most any RDBMS.
Like so:
CREATE TABLE Rating (
rid int NOT NULL,
uid int NOT NULL,
CONSTRAINT PK_Rating PRIMARY KEY (rid, uid)
);
ALTER TABLE Rating ADD CONSTRAINT FK_Rating_Recipies FOREIGN KEY(rid)
REFERENCES Recipies (rid);
ALTER TABLE Rating ADD CONSTRAINT FK_Rating_User FOREIGN KEY(uid)
REFERENCES User (uid);
This ensures that the values inside of Rating are only valid values inside of both the Users table and the Recipes table. Please note, in the Rating table I didn't include the other fields you had, just add those.
Assume in the users table you have 3 users: Joe, Bob and Bill respective ID's 1,2,3. And in the recipes table you had cookies, chicken pot pie, and pumpkin pie respective ID's are 1,2,3. Then inserting into Rating table will only allow for these values, the minute you enter 4 for a RID or a UID SQL throws an error and does not commit the transaction.
Try it yourself, its a good learning experience.
In Postgresql a correct way to implement these tables are:
CREATE SEQUENCE uid_seq;
CREATE SEQUENCE rid_seq;
CREATE TABLE User(
uid INTEGER PRIMARY KEY DEFAULT nextval('uid_seq'),
uname VARCHAR NOT NULL
);
CREATE TABLE Recipes(
rid INTEGER PRIMARY KEY DEFAULT nextval('rid_seq'),
content VARCHAR NOT NULL
);
CREATE TABLE Rating(
rid INTEGER NOT NULL REFERENCES Recipes(rid),
uid INTEGER NOT NULL REFERENCES User(uid),
rating INTEGER CHECK (0<=rating and rating<=5) NOT NULL,
PRIMARY KEY(rid,uid)
);
There is no real difference between the two options that you have written.
A simple (i.e. single-column) foreign key may be declared in-line with the column declaration or not. It's merely a question of style. A third way should be to omit foreign key declarations from the CREATE TABLE entirely and later add them using ALTER TABLE statements; done in a transaction (presumable along with all the other tables, constraints, etc) the table would never exist without its required constraints. Choose whichever you think is easiest fora human coder to read and understand i.e. is easiest to maintain.
EDIT: I overlooked the REFERENCES clause in the second version when I wrote my original answer. The two versions are identical in terms of referential integrity, there are just two ways of syntax to do this.
Hoping someone can shed some light on this: Do lookup tables need their own ID?
For example, say I have:
Table users: user_id, username
Table categories: category_id, category_name
Table users_categories: user_id, category_id
Would each row in "users_categories" need an additional ID field? What would the primary key of said table be? Thanks.
You have a choice. The primary key can be either:
A new, otherwise meaningless INTEGER column.
A key made up of both user_id and category_id.
I prefer the first solution but I think you'll find a majority of programmers here prefer the second.
You could create a composite key that uses the both keys
Normally if there is no suitable key to be found in a table you want to create a either a composite key, made up of 2 or more fields,
ex:
Code below found here
CREATE TABLE topic_replies (
topic_id int unsigned not null,
id int unsigned not null auto_increment,
user_id int unsigned not null,
message text not null,
PRIMARY KEY(topic_id, id));
therefor in your case you could add code that does the following:
ALTER TABLE users_categories ADD PRIMARY KEY (user_id, category_id);
therefor once you want to reference a certain field all you would need is to pass the two PKs from your other table, however to link them they need to each be coded as a foreign key.
ALTER TABLE users_categories ADD CONSTRAINT fk_1 FOREIGN KEY (category_id) REFERENCES categories (category_id);
but if you want to create a new primary key in your users_categories table that is an option. Just know that its not always neccessary.
If your users_categories table has a unique primary key over (user_id, category_id), then - no, not necessarily.
Only if you
want to refer to single rows of that table from someplace else easily
have more than one equal user_id, category_id combination
you could benefit from a separate ID field.
Every table needs a primary key and unique ID in SQL no matter what. Just make it users_categories_id, you technically never have to use it but it has to be there.