Decomplexify
Decomplexify
  • Видео 7
  • Просмотров 2 177 315
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
Просмотров: 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...

Комментарии

  • @moyo_animations
    @moyo_animations 2 дня назад

    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.

  • @ahoahh
    @ahoahh 9 дней назад

    thanks!! your explanation was really easy to understand

  • @nimeshchandupa9136
    @nimeshchandupa9136 10 дней назад

    this is fucking good bro '

  • @imafraidjumitebeeinnagang3886
    @imafraidjumitebeeinnagang3886 12 дней назад

    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.

  • @vipeholmskolan6052
    @vipeholmskolan6052 12 дней назад

    Really good stuff. Subbed on the spot.

  • @torpedoe1936
    @torpedoe1936 12 дней назад

    This is so concise and precise. Absolute goldmine!

  • @ziiada.1802
    @ziiada.1802 12 дней назад

    i would say this is the masterpiece of 21st century in SQL!

  • @EmergencyChannel69420
    @EmergencyChannel69420 16 дней назад

    Came for the basic example, stayed for the quadcopters and sentient teddy bears

  • @mohammedsiraj6162
    @mohammedsiraj6162 16 дней назад

    CompoundComplexity

  • @user-pw6fz4qh5m
    @user-pw6fz4qh5m 16 дней назад

    Thanks for the clearest explanation.

  • @shipperification
    @shipperification 19 дней назад

    Thanks!! Finally someone made it clear!!

  • @AliJabbarXD
    @AliJabbarXD 20 дней назад

    Awesome content!

  • @diegobotto6245
    @diegobotto6245 21 день назад

    what a fucking banger of a video, so good

  • @MrFreakinSauce
    @MrFreakinSauce 21 день назад

    Fantastic

  • @danbenton-smith7723
    @danbenton-smith7723 21 день назад

    Honestly buddy this is such a fantastic video! Explained so clearly! Well done!

  • @rupireddyeswar4982
    @rupireddyeswar4982 22 дня назад

    Why you stopped doing videos. It is very useful for us. The way of explaining is awesome. Please continue the videos.

  • @justarandomname
    @justarandomname 22 дня назад

    more please, thank you!

  • @IssamZeinoun
    @IssamZeinoun 22 дня назад

    you did a wonderful job!!!

  • @MrTomfooligans
    @MrTomfooligans 24 дня назад

    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.

  • @ahnov6670
    @ahnov6670 25 дней назад

    imagine yapping for 8 hours about this just to be outplayed by a random guy on youtube in 28 minutes

  • @n4ff4h
    @n4ff4h 27 дней назад

    Noice explanation! Really helpful :)

  • @jannatulmahjabinfaiza6573
    @jannatulmahjabinfaiza6573 Месяц назад

    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.

  • @captainrelyk
    @captainrelyk Месяц назад

    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

  • @awakenbeast2944
    @awakenbeast2944 Месяц назад

    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

    • @decomplexify
      @decomplexify Месяц назад

      See the Corrections section in the pinned comment.

  • @YoussefAdelZin
    @YoussefAdelZin Месяц назад

    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

    • @decomplexify
      @decomplexify Месяц назад

      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.

    • @YoussefAdelZin
      @YoussefAdelZin Месяц назад

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

    • @decomplexify
      @decomplexify Месяц назад

      ​@@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.

    • @YoussefAdelZin
      @YoussefAdelZin Месяц назад

      @@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

  • @jiajinzhou5263
    @jiajinzhou5263 Месяц назад

    thank you for the video! it's very well explained

  • @jobink5
    @jobink5 Месяц назад

    I am not sure how primary key showed in 23:30 is correct. How can Model be the only primary key?

    • @decomplexify
      @decomplexify Месяц назад

      See the Corrections section in the pinned comment.

  • @muhammadsajidrazaansari8074
    @muhammadsajidrazaansari8074 Месяц назад

    Super

  • @manishsahu3557
    @manishsahu3557 Месяц назад

    we need window function on sql

  • @tarusheebhalla1196
    @tarusheebhalla1196 Месяц назад

    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 ?

    • @decomplexify
      @decomplexify Месяц назад

      Primary key attributes don't have to be numeric.

  • @damonguzman
    @damonguzman Месяц назад

    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.

    • @decomplexify
      @decomplexify Месяц назад

      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!

  • @jernejlobnik9419
    @jernejlobnik9419 Месяц назад

    great vid tnx

  • @bidiptadas1122
    @bidiptadas1122 Месяц назад

    Great explanation 😃

  • @thomaskaiser2475
    @thomaskaiser2475 Месяц назад

    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.

  • @CamaradaJoao
    @CamaradaJoao Месяц назад

    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.

    • @decomplexify
      @decomplexify Месяц назад

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

  • @santocyriac1458
    @santocyriac1458 Месяц назад

    This video is a whole better than the 9 hour lecture we had on this same topic

  • @luuu_na35
    @luuu_na35 Месяц назад

    My brain blown up when reading these definitions, like "What?". Thanks for simplifying it in a way I can understand!

  • @barakasfr5102
    @barakasfr5102 Месяц назад

    Amazing video

  • @dawnskinner1920
    @dawnskinner1920 Месяц назад

    Thank you! This is the best and clearest explanation for this topic that I have encountered.

  • @XhaxhiThoma
    @XhaxhiThoma Месяц назад

    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!

  • @julien957
    @julien957 Месяц назад

    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!

  • @masoodahmad2175
    @masoodahmad2175 Месяц назад

    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.

  • @edwardduda4222
    @edwardduda4222 Месяц назад

    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!

  • @RM-xr8lq
    @RM-xr8lq Месяц назад

    dam my db already failing 1NF

  • @rajnikant_roy
    @rajnikant_roy Месяц назад

    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

    • @decomplexify
      @decomplexify Месяц назад

      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.

    • @rajnikant_roy
      @rajnikant_roy Месяц назад

      @@decomplexify aah got it thanks for the quick explanation

  • @gingeas
    @gingeas Месяц назад

    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

  • @LeetStack
    @LeetStack Месяц назад

    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.

  • @lucaliberato
    @lucaliberato Месяц назад

    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+?

  • @wizlif144
    @wizlif144 Месяц назад

    Database breathing 5th form

  • @jakemeyer8188
    @jakemeyer8188 Месяц назад

    This video is so good, it's officially labeled as "bad-ass", and is 3NF compliant.