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.
@edwardduda42223 күн бұрын
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-xr8lq5 күн бұрын
dam my db already failing 1NF
@rajnikant_roy5 күн бұрын
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
@decomplexify5 күн бұрын
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_roy4 күн бұрын
@@decomplexify aah got it thanks for the quick explanation
@gingeas6 күн бұрын
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
@LeetStack6 күн бұрын
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.
@lucaliberato8 күн бұрын
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+?
@wizlif1449 күн бұрын
Database breathing 5th form
@jakemeyer81889 күн бұрын
This video is so good, it's officially labeled as "bad-ass", and is 3NF compliant.
@MrLanorian10 күн бұрын
Show demais!!!!😆
@josefkaras751910 күн бұрын
wouldnt the year and month also break atomicity rule of 1nf?
@decomplexify9 күн бұрын
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.
@zaferemrekilinc413810 күн бұрын
you are amazing
@huthaifamuayyad349110 күн бұрын
Thanks!
@huthaifamuayyad349110 күн бұрын
Very nice explanation and delivery of thoughts. Looking forward to more videos like this, explaining basic but important software principles.
@nintishia11 күн бұрын
Thanks a ton. You made it all so simple and easy.
@FrankKritzman11 күн бұрын
Great video, thank you!
@maria-rv7fk12 күн бұрын
THANK YOU! You explain this in a way that is practical and easy to follow. I much prefer this method of learning (visually and with examples) to memorizing a bunch of formal definitions. I understand learning about theory is good, but to really GET it I think you need someone to explain concepts like you do.
@mikemixsosa426414 күн бұрын
Great Video!
@piotrlezanski515617 күн бұрын
Hi, why in the second table Locker_id is cannot be primary key? It identifies every row, there are no duplicates.
@decomplexify13 күн бұрын
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.
@schwifty378517 күн бұрын
Great video dude Lots of loves and prayers
@Chris-tq1jy18 күн бұрын
Funny how Chat GPT recommended this video.
@Salalkhan20 күн бұрын
can you please tell me the Font name you are using in the video? Will be thankful
@decomplexify19 күн бұрын
Kalam
@thomaspotterdotexe23 күн бұрын
The PM and the owner : "F it, we will deploy it in 5 hour, we'll think about it later"
@adiporsh24 күн бұрын
It is not mandatory to have a primary key in 1NF. Every row should be unique which can be enforced by a single or multiple columns using a candidate key .
@decomplexify23 күн бұрын
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.
@adiporsh23 күн бұрын
@@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...
@usingThaForce25 күн бұрын
I see why the frost machine be broken😅😅
@user-tb8xm1cb3s27 күн бұрын
Thanks for putting your time and energy in putting together this amazingly effective tutorial.
@NattixOMG27 күн бұрын
SELECT c.compund_name, c.compund_id FROM compund c JOIN compund_element_detail ced USING compound_id --Or (ON c.compund_id = ced.compound_id) WHERE ced.element_symbol = 'H'
@NattixOMG27 күн бұрын
would this not work? This is what I came up with before the video showed its answer. I guess I don't understand why the 3rd table 'Element' needs to be joined. Trying to get better at thinking through this so any help is appreciated
@NattixOMG27 күн бұрын
It's probably because the question asks for "Hydrogen", should work on reading questions fully lol
@orenzeshani29 күн бұрын
Every time a military surprise attack succeeds, this is what happened
@anudeepk739029 күн бұрын
Problem? Create a new table
@anudeepk739029 күн бұрын
Informative
@barrysarthak6990Ай бұрын
Thank you man One of the best explanations ever
@ScaleScarborough-jq8zxАй бұрын
Lots of mediocre shops out there are threatened by such sensible standards. “Our software, our system is strong because I said so!”
@SixToughАй бұрын
2NF and 3NF strive to create more tables where inconsitencies can happen in between tables and in case of error good data is overwritten irretrievably
@SixToughАй бұрын
An update anomaly preserves data and without it an error would simply get a wrong value
@pietrogazzera5733Ай бұрын
Thank you a lot!
@pietrogazzera5733Ай бұрын
INSERT INTO comments a VERY WELL DONE;
@itsandyagainАй бұрын
Awesome content. I understand this topic much better now. I'm having difficulty understanding a scenario where a partial update might happen. Could you possibly elaborate on that please?
@decomplexifyАй бұрын
Good question! If a table structure permits inconsistency, then the update that we're required to do is more subtle and involved than it would otherwise be, therefore we're more likely to make a mistake. We may in fact not even realize that such updates are necessary. I've seen the following sort of example many times in real life. We have a table that holds transactions relating to an insurance policy, like premium transactions and claim transactions. Each such transaction is for a particular policy, occurs on a particular date, is of a particular type and for a particular amount, etc. Let's say a policy has certain properties, and one of these properties is "Policy Country". The designer has decided to include Policy Country on the transaction table, and therefore the transaction table is not in 3NF. It may simply never occur to the designer that Policy Country might change, e.g. Policy Country might be entered on the policy as Spain initially, and then some weeks later it might be corrected to Italy. Since the process for writing out a transaction involves copying the Policy Country from a policy table and stamping it on the transaction being generated, what will naturally happen in this case is that the first few transactions will show a Policy Country of Spain, and subsequent transactions will show a Policy Country of Italy. This will probably come to light only when somebody tries to report transaction amounts broken down by country and gets odd results.
@dus10dndАй бұрын
Normalization isn't always sunshine and roses. If we go all the to 5NF and we're managing sales transactions, you would lose information regarding the cost a customer paid at the time, like if you're running a sale, or you adjust pricing, since you would be referencing the current price. So, denormalization does have value, sometimes.
@decomplexifyАй бұрын
I think you're talking about a transaction table whose attributes are along the lines of: TRANSACTION_ID, TRANSACTION_DATE, CUSTOMER_ID, PRODUCT_ID, NUMBER_OF_UNITS_BOUGHT, UNIT_PRICE_THAT_THE_CUSTOMER_PAID. It's important to understand, however, that this table actually IS in 5NF - it's not denormalized. This is because UNIT_PRICE_THAT_THE_CUSTOMER_PAID doesn't have a functional dependency on PRODUCT_ID. If on the other hand there was an attribute called CURRENT_UNIT_PRICE, this attribute would have a functional dependency on PRODUCT_ID. The table would in this case not be normalized.
@yangfantan2247Ай бұрын
beautiful explanation! very clear and elegant, cut to the point
@agnesrahayu8500Ай бұрын
Many Thanks, sangat membantu saya untuk mengerjakan tugas kuliah.. Sukses terus kak :)
@muhammadtahasarwar2110Ай бұрын
Very clearly, unambiguously explained that is pleasing to the mind and feels like soothing to soul even when it is a pure technical topic rather than literature ❤
@zobzn1Ай бұрын
I don't get the example for the 4NF at all. Why do we need to add 2 rows, where is the rule wich says to do this way? Is this an artificial example? In real life green color just for one style is normal thing. I'm frustrated, why can't I comprehend it. Well, I also didn’t understand the fifth form even more. Even the problem itself, not to mention the solution.
@lilianchauvel3694Ай бұрын
What a boss, trully simple to understand, thx a lot
@doniaelfouly4142Ай бұрын
thanks
@zelousfoxtrot3390Ай бұрын
Well that was two weeks of lectures summed up nicely. THANK YOU!
@anupbhowmik8505Ай бұрын
Very nicely explained. Thank you
@whatami605Ай бұрын
bro is literally inconceivably awesome
@NA245thАй бұрын
Thank you, very well explained. Now I have to go back and examine my db. Thanks again
Пікірлер
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
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.
Show demais!!!!😆
wouldnt the year and month also break atomicity rule of 1nf?
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.
you are amazing
Thanks!
Very nice explanation and delivery of thoughts. Looking forward to more videos like this, explaining basic but important software principles.
Thanks a ton. You made it all so simple and easy.
Great video, thank you!
THANK YOU! You explain this in a way that is practical and easy to follow. I much prefer this method of learning (visually and with examples) to memorizing a bunch of formal definitions. I understand learning about theory is good, but to really GET it I think you need someone to explain concepts like you do.
Great Video!
Hi, why in the second table Locker_id is cannot be primary key? It identifies every row, there are no duplicates.
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.
Great video dude Lots of loves and prayers
Funny how Chat GPT recommended this video.
can you please tell me the Font name you are using in the video? Will be thankful
Kalam
The PM and the owner : "F it, we will deploy it in 5 hour, we'll think about it later"
It is not mandatory to have a primary key in 1NF. Every row should be unique which can be enforced by a single or multiple columns using a candidate key .
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...
I see why the frost machine be broken😅😅
Thanks for putting your time and energy in putting together this amazingly effective tutorial.
SELECT c.compund_name, c.compund_id FROM compund c JOIN compund_element_detail ced USING compound_id --Or (ON c.compund_id = ced.compound_id) WHERE ced.element_symbol = 'H'
would this not work? This is what I came up with before the video showed its answer. I guess I don't understand why the 3rd table 'Element' needs to be joined. Trying to get better at thinking through this so any help is appreciated
It's probably because the question asks for "Hydrogen", should work on reading questions fully lol
Every time a military surprise attack succeeds, this is what happened
Problem? Create a new table
Informative
Thank you man One of the best explanations ever
Lots of mediocre shops out there are threatened by such sensible standards. “Our software, our system is strong because I said so!”
2NF and 3NF strive to create more tables where inconsitencies can happen in between tables and in case of error good data is overwritten irretrievably
An update anomaly preserves data and without it an error would simply get a wrong value
Thank you a lot!
INSERT INTO comments a VERY WELL DONE;
Awesome content. I understand this topic much better now. I'm having difficulty understanding a scenario where a partial update might happen. Could you possibly elaborate on that please?
Good question! If a table structure permits inconsistency, then the update that we're required to do is more subtle and involved than it would otherwise be, therefore we're more likely to make a mistake. We may in fact not even realize that such updates are necessary. I've seen the following sort of example many times in real life. We have a table that holds transactions relating to an insurance policy, like premium transactions and claim transactions. Each such transaction is for a particular policy, occurs on a particular date, is of a particular type and for a particular amount, etc. Let's say a policy has certain properties, and one of these properties is "Policy Country". The designer has decided to include Policy Country on the transaction table, and therefore the transaction table is not in 3NF. It may simply never occur to the designer that Policy Country might change, e.g. Policy Country might be entered on the policy as Spain initially, and then some weeks later it might be corrected to Italy. Since the process for writing out a transaction involves copying the Policy Country from a policy table and stamping it on the transaction being generated, what will naturally happen in this case is that the first few transactions will show a Policy Country of Spain, and subsequent transactions will show a Policy Country of Italy. This will probably come to light only when somebody tries to report transaction amounts broken down by country and gets odd results.
Normalization isn't always sunshine and roses. If we go all the to 5NF and we're managing sales transactions, you would lose information regarding the cost a customer paid at the time, like if you're running a sale, or you adjust pricing, since you would be referencing the current price. So, denormalization does have value, sometimes.
I think you're talking about a transaction table whose attributes are along the lines of: TRANSACTION_ID, TRANSACTION_DATE, CUSTOMER_ID, PRODUCT_ID, NUMBER_OF_UNITS_BOUGHT, UNIT_PRICE_THAT_THE_CUSTOMER_PAID. It's important to understand, however, that this table actually IS in 5NF - it's not denormalized. This is because UNIT_PRICE_THAT_THE_CUSTOMER_PAID doesn't have a functional dependency on PRODUCT_ID. If on the other hand there was an attribute called CURRENT_UNIT_PRICE, this attribute would have a functional dependency on PRODUCT_ID. The table would in this case not be normalized.
beautiful explanation! very clear and elegant, cut to the point
Many Thanks, sangat membantu saya untuk mengerjakan tugas kuliah.. Sukses terus kak :)
Very clearly, unambiguously explained that is pleasing to the mind and feels like soothing to soul even when it is a pure technical topic rather than literature ❤
I don't get the example for the 4NF at all. Why do we need to add 2 rows, where is the rule wich says to do this way? Is this an artificial example? In real life green color just for one style is normal thing. I'm frustrated, why can't I comprehend it. Well, I also didn’t understand the fifth form even more. Even the problem itself, not to mention the solution.
What a boss, trully simple to understand, thx a lot
thanks
Well that was two weeks of lectures summed up nicely. THANK YOU!
Very nicely explained. Thank you
bro is literally inconceivably awesome
Thank you, very well explained. Now I have to go back and examine my db. Thanks again
great explanation. thanks <3
these videos are great. please start again...