Thanks! Regarding 4NF, please see the Corrections section in the pinned comment.

See the Corrections section in the pinned comment.

Take each row in the table, look at its Approver Employee Number (call it n), then find a row in the Employee table whose Employee Number is n. That's the matching that this join is doing.

@@decomplexify thanks so much but would I be right if we mixed it to be E.employee = AP.aprovel right

​@@YoussefAdelZinIf you did that, the query would still return 6 rows, and the headings in the query output would become misleading because "e" is now the approver and "ap" is now a person who gets days off approved by the approver. So the query wouldn't really make sense any more. But it would return 6 rows.

@@decomplexify I understand but it would not contain 2,3,5 it will contain two 1s and three 6s and btw thank you very much for carrying and answering me

See the Corrections section in the pinned comment.

Primary key attributes don't have to be numeric.

Excellent question. There are lots of advantages to using single-column surrogate keys (which is what you're talking about) as primary keys. Should you do this on every table without exception? Personally I would say no. Some tables don't benefit from this approach, in my opinion, and it's important to know what these are: 1) "Linking" or "resolver" tables. Example: we've got a table called Player with primary key Player_ID (an auto-incrementing integer). We've got a table called Item with primary key Item_ID (an auto-incrementing integer). So far, so good. We've also got a table called Player_Item in which each row represents that a given Player presently owns a certain quantity of a given Item. The primary key of Player_Item, a table which is a sort of linking or resolver table, should be the composite key {Player_ID, Item_ID}. 2) Certain types of reference data tables. Example: we have an application which is all about handling complaints. A complaint can have a status of Pending, Active, Resolved, or Cancelled. The application has a workflow that lets you (as a user) do different things with a complaint depending on what its status is. Now, suppose we have a Status_Ref table with 4 rows in it, one for each status. I personally would create the table with an attribute Status_Code (which has values like 'PND', 'ACT', 'RES', and 'CAN') and an attribute Status_Description (which has values like 'Pending', 'Active', etc.); and I would designate Status_Code as the primary key of the Status_Ref table. Imagine now another table: Complaint. One of the attributes of Complaint is Status_Code, which is a foreign key to Status_Ref. This works perfectly well and it's very convenient to be able to get the Status_Code (like 'PND') straight off the Complaint table. In contrast, having a Complaint table with a Status_ID (like 123e4567-e89b-12d3-a456-426614174000) referencing Status_Ref.Status_ID, which forces you to go to the Status_Ref table to ascertain that the status in question is 'PND', is a needless overcomplication in my opinion and sacrifices simplicity/transparency for no real gain. Finally, when using surrogate keys, your point about "you are free to add constraints to the additional columns to achieve desired outcomes" is very important. Most people who make use of surrogate keys, I find, don't bother to do this bit!

As mentioned at 8:00, {Release_Year, Popularity_Ranking} is a candidate key, and so is {Release_Year_And_Month, Popularity_Ranking}.

At least you’ve got a schema, I can’t keep changing schema every day

😂

you monkey !

Bro u a real one 😂

🤣🤣🤣🤣🤣🤣

When we say that a candidate key is a "minimal superkey", what we mean is that it is a superkey that contains only attributes that (in combination) ensure uniqueness. It does not contain any attributes additional to those. On this basis, there might be several candidate keys for a given table. For example, {Release_Year, Popularity_Ranking} is a candidate key, but if you add "extra" attribute Movie_Name to it, you get {Release_Year, Popularity_Ranking, Movie_Name} - which is a superkey that is not a candidate key. Another way of thinking about this superkey {Release_Year, Popularity_Ranking, Movie_Name} is that it's what you get when you add "extra" attributes Release_Year and Popularity_Ranking to the candidate key {Movie_Name}. Whichever way you look at it, this superkey consists of some candidate key plus some extra attribute or attributes.

@@decomplexify aah got it thanks for the quick explanation

Database theorists like Chris Date and Hugh Darwen nowadays consider "atomicity" to be a fairly meaningless concept. They say the notion of being "non-atomic" would be either so sweeping that it includes everything, or so subjective that we can't usefully apply it. For example, suppose there's a table that has a column called Number_Of_Members. This column has values like, for example, 27. But 27, if you think about it, really means 2 tens and 7 ones. So 27 isn't an atomic value; it is decomposable into parts. On this basis, any table with an integer column would violate First Normal Form. The same would likewise be true of any string column, because a string can be decomposed into individual characters. The same would likewise be true of any date column (which decomposes into year, month, day of month). And so on. And yet this would be absurd. This is why people like Chris Date no longer regard atomicity as a 1NF criterion, and neither do I.

To make Locker ID the primary key is to declare that each Locker can only ever have one reservation. It means once this single reservation is made, no one can reserve that particular Locker ever again (because doing so would be a primary key violation). Focus not on the rows that happen to be in the table right now, but rather on the rules we want to enforce for what rows are and aren't allowed in the table.

@@decomplexify Thanks a lot!

Kalam

I think you've misunderstood what a "primary key" is. A primary key doesn't have to consist of just a single column. A primary key can consist of multiple columns: for example, ALTER TABLE Customer_Address ADD PRIMARY KEY (Customer_ID, Address_Sequence_Number). In SQL, the only way you can prevent duplicate rows in a table is by adding a primary key constraint or unique key constraint to the table.

@@decomplexify @decomplexify Primary key is not mandatory in 1 NF. Candidate key should work based on the requirement. However, primary key is desirable... i should've been specific...