- Видео 7
- Просмотров 2 177 315
Decomplexify
Великобритания
Добавлен 10 апр 2020
Learn SQL Joins
An easy-to-follow SQL joins tutorial, with lots of examples. Covers the main types of SQL joins, namely:
- INNER JOIN
- LEFT OUTER JOIN
- RIGHT OUTER JOIN
- FULL OUTER JOIN
- CROSS JOIN
0:00 Introduction
0:40 INNER JOINs
9:08 LEFT OUTER JOINs
13:04 RIGHT OUTER JOINs
15:36 FULL OUTER JOINs
17:10 Tailoring the matching criteria
18:40 CROSS JOINs
19:24 Joining a table to itself
21:06 Conclusion
- INNER JOIN
- LEFT OUTER JOIN
- RIGHT OUTER JOIN
- FULL OUTER JOIN
- CROSS JOIN
0:00 Introduction
0:40 INNER JOINs
9:08 LEFT OUTER JOINs
13:04 RIGHT OUTER JOINs
15:36 FULL OUTER JOINs
17:10 Tailoring the matching criteria
18:40 CROSS JOINs
19:24 Joining a table to itself
21:06 Conclusion
Просмотров: 44 861
Видео
Learn Database Denormalization
Просмотров 39 тыс.Год назад
What is RDBMS denormalization all about? This video will help you to recognize situations in which it is appropriate to denormalize a relational database table - or avoid normalizing it in the first place. Featuring lots of examples and a focus on the design process.
Database Keys Made Easy - Primary, Foreign, Candidate, Surrogate, & Many More
Просмотров 142 тыс.2 года назад
An easy-to-follow tutorial covering the whole gamut of RDBMS keys: primary keys, candidate keys, superkeys, alternate keys, foreign keys, surrogate keys, natural keys, simple keys, composite keys, compound keys, and intelligent keys. Featuring lots of examples and a focus on the design process. 0:00 Introduction 0:53 Primary Keys 3:29 Candidate Keys 6:09 Superkeys 7:57 Alternate Keys 8:49 Forei...
Learn Boyce-Codd Normal Form (BCNF)
Просмотров 95 тыс.2 года назад
An easy-to-follow & comprehensive explanation of Boyce-Codd Normal Form (BCNF), with examples. After watching this video, you'll understand BCNF and the key concepts that enter into the BCNF definition, for example "prime attribute", "non-prime attribute", "candidate key". And you'll understand exactly how BCNF improves upon Third Normal Form (3NF). See also Decomplexify's full step-by-step dat...
The Surprise Exam Paradox, Part 2
Просмотров 4,5 тыс.2 года назад
The Surprise Exam Paradox (which is equivalent to the Unexpected Hanging Paradox) is a mind-boggling logical conundrum. In Part 1, we ran through our own variation of this paradox. Here in Part 2, we give an in-depth analysis of the paradox - and attempt to resolve it.
The Surprise Exam Paradox, Part 1
Просмотров 8 тыс.2 года назад
The Surprise Exam Paradox (which is equivalent to the Unexpected Hanging Paradox) is a mind-boggling logical conundrum. In this video ("Part 1"), we run through our own variation of this paradox. Have a go at solving the mystery of the Surprise Exam Paradox yourself... and stay tuned for Part 2, where we analyze the paradox in detail and present our own resolution to it!
Learn Database Normalization - 1NF, 2NF, 3NF, 4NF, 5NF
Просмотров 1,8 млн2 года назад
An easy-to-follow database normalization tutorial, with lots of examples and a focus on the design process. Explains the "why" and "how" of normalization, and takes you step-by-step through: - First Normal Form (1NF) - Second Normal Form (2NF) - Third Normal Form (3NF), with a side note on Boyce-Codd Normal Form (BCNF) - Fourth Normal Form (4NF) - Fifth Normal Form (5NF) 0:00 What is database n...
I didn't get the concept of it. I think it's the way that you've explained it because you gave an example of an engineer assessing a bridge and he performed all these evaluations and stuff on the same bridge so was expecting you to explain it similarly like using the same table/database throughout your explanation. For example, use 1NF but that table/database can be further normalized to 2NF and after that to 3NF using the same table. Not from The Beatles Table to Gaming tables, it kinder went off rails for me there, and became hard to grasp the concept. Let's hope you get what I'm saying my grammar is pretty bad.
thanks!! your explanation was really easy to understand
this is fucking good bro '
It's insane how much knowledge is condensed in this video. I legit sat down for 40 minutes with pen and paper and after going through the entire video, I feel so satisfied with everything.
Really good stuff. Subbed on the spot.
This is so concise and precise. Absolute goldmine!
i would say this is the masterpiece of 21st century in SQL!
Came for the basic example, stayed for the quadcopters and sentient teddy bears
CompoundComplexity
Thanks for the clearest explanation.
Thanks!! Finally someone made it clear!!
Awesome content!
what a fucking banger of a video, so good
Fantastic
Honestly buddy this is such a fantastic video! Explained so clearly! Well done!
Why you stopped doing videos. It is very useful for us. The way of explaining is awesome. Please continue the videos.
more please, thank you!
you did a wonderful job!!!
Exceptionally well made content from a naturally gifted instructor. You are helping people like me make it to the end of school in one piece and what you're doing is so valuable. Thank you.
imagine yapping for 8 hours about this just to be outplayed by a random guy on youtube in 28 minutes
Noice explanation! Really helpful :)
i think this is the best explanation of database normalization. especially for the beginners like me. i saw so many tutorials and read a chapter of this topic but couldn't be able to get this steps so easily. but this tutorial helped me to understand those steps so smoothly.
Apparently there are 6 normal forms. Which means the seventh normal form breaks reality itself and could show us how reality works by showing it’s a database, allowing us to bend it to our will Or maybe it’s late and my imagination is going wild
23:30 After the decomposition, the primary keys for tables are not just model it is {model, color} for first and {model, style} for second table
See the Corrections section in the pinned comment.
the last result table is wrong as there is not match for 3 ,4,5 in approver_emp_number so the result should contain only 3 rows where they match please tell i am wrong i am looking at for hour trying to know why
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
thank you for the video! it's very well explained
I am not sure how primary key showed in 23:30 is correct. How can Model be the only primary key?
See the Corrections section in the pinned comment.
Super
we need window function on sql
In the example even category data type column is considered a Primary key, we can do this way? it should be Unique, no null value and numeric? since rule says that they should be atleast one Primary key, what if I only have category data type columns, cnot numeric, what is the solution ?
Primary key attributes don't have to be numeric.
Maybe it's my inexperience talking but what are the benefits for any of these approaches over having every table have an "id" column that is either an autoincrementing integer or a UUID (dealer's choice). These other primary key implementations seem like a large amount of mental overhead and complexity to achieve what I am interpreting as the same thing. Are there any drawbacks to this "simple" approach? The only ones I can think of are: 1. Indexing UUIDs takes more space than integers 2. Integers are easily guessable so UUIDs are better for authorization and security use cases. For me at least, it creates a significantly simpler mental model. Every table, without exception, has a primary key column named "id" and you are free to add constraints to the additional columns to achieve desired outcomes.
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!
great vid tnx
Great explanation 😃
Nice, i was going crazy reading these textbooks that take way too long to get a point across its ridiculously bad. This video allowed me to finish my 2nd week assignment for database concepts class. And it all makes much more sense now.
On Most Popular MOvies of The Year table there is no way all the atributes are candidate keys, because they all repeat on the table, except for movie name.
As mentioned at 8:00, {Release_Year, Popularity_Ranking} is a candidate key, and so is {Release_Year_And_Month, Popularity_Ranking}.
This video is a whole better than the 9 hour lecture we had on this same topic
My brain blown up when reading these definitions, like "What?". Thanks for simplifying it in a way I can understand!
Amazing video
Thank you! This is the best and clearest explanation for this topic that I have encountered.
Heroes don't need to have some magic superpower, explaining to others this topic and other topics clearly is a great superpower to have. I don't know how to reward you enough for the explanations!
OMG I was about to post a comment on 23:27...and I just saw your corrections ;). Your content is amazing and you explain it so well!
I know my comment is a little irrelevant, but can you please tell me what are the fonts you are using? these are amazing.? Please share the name or the link if possible.
So much better than the explanation given in my Database Systems class. They explained everything with alpha's and beta's in set notation. Thank you for this!
dam my db already failing 1NF
At least you’ve got a schema, I can’t keep changing schema every day
😂
you monkey !
Bro u a real one 😂
🤣🤣🤣🤣🤣🤣
I might be wrong but for the example Most_Popular_Movies_Of_The_Year, shouldnt only Movie Name be the candidate key? As candidate keys are a minimal set of keys that uniquely identify a tuple
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
I scoured so many database normalization videos in my undergraduate 4yr ago and none of them come near this one. My college self is finally happy
it is so great to finally understand what and why I was doing what I was doing, while following youtubers who don't explain anything.
hi, the video was very helpful. Btw, i'm not sure if i understood well the difference between superkeys and composite keys. Superkeys are a type of composite keys that can consist also of one attribute while the other must be 2+?
Database breathing 5th form
This video is so good, it's officially labeled as "bad-ass", and is 3NF compliant.