+Steve Burns Haha ... so true lol I have a professor that makes me go to sleep every time he talks No hard feelings ofc but I learned more in this video then I ever did there
Because most employers aren't going to just take your word for it that you studied. They want a piece of paper from a place they can look up that shows you've been tested on the subject matter and passed.
3:00 - 1st Normal Form 6:21 - 2nd Normal Form 9:40 - 3rd Normal Form 13:37 - 4th Normal Form 18:07 - Table relationships and name How does something so simple can be super confusing in class? Thank you so much!
This is so much simpler and practical compared to the overly formalized logical relationships they use to try to teach this. You don't need to worry about terms like functional or transitive dependencies....The data speaks for itself and becomes intuitive with this approach. Thank you so much!
There are dozens of videos out there on TH-cam but this one is the best. It explains on real life kinda scenario and is easy to understand all these functional dependencies. Thank you sir very much.
Hands down the greatest normalization example and explanation I have ever watched. He used one example straight through unlike others who like to switch the example once they reach 2nf and he explain partial dependency in layman terms than just textbook.
On the first table at 5:51, Cust ID cannot be the primary key as the values in that column are not unique (e.g. wilson44). The correct way would have been to label that as a foreign key (it would be the primary key of a customer table) and then have a Sales ID which would be unique.
Aquí tienes un mensaje en español de alguien que te agradece profundamente está clase, tras 6 años nunca entendí la normalización y en tan solo 19 minutos, me ha quedado mas que claro. Estoy agradecido infinitamente.
Appreciate the video tutorial. This does bring some clarity to what normalization means in these databases. This is my first time studying databases (DBMS) and its a lot to take in, but I appreciate videos such as this one which brings more understanding to these database concepts. Thank You
Damn, you just made normalization easier. I was having trouble identifying dependencies but the way you explained it was as accurate and practical as hell. Thank you for this wonderful video!
Cust ID can't be a primary key unless you introduce a list of unique customers. There's a duplicate wilson44 Cust ID, which means it can't be a key. You'd have to introduce a column Order ID or similar. (In 4NF this problem simply moves from Customer Table to Subscription Table)
how would u fix the problem on the bridge table ? i was thinking about adding a quantity row for not preparing (ex: Wilson - xbox) srdy for 4 years later lol
+Milan Mijailovic Indeed, imo they all should have ID columns, especially invoice too. What if a customer buys another playstation or any item multiple times?
Can you please explain why there is a need of 3rd table in 2NF?? We could have added aother column in the frist table and entered the name of the products along with the newsletters.
Everything is good but at last i am bit confused.. In Subscription table you said Cust Id is a primary key.. But it is having multiple entries (one for xbox and other for playstation) for customer wilson44. Primary key will not allow multiple records belongs to same id. Iam confused at 4th normal form because a key attribute will never entertain same values to insert more than once so how we solve the problem on your given example particularly at (4nf) please elaborate the explanation. thankyou
how can you have duplicate values in Primary Key column ? If that is the case, don't we have to combine it with other columns to determine a candidate key?
its actually true, as it called as the composite key, that merges the primary key and candidate key(s) for a better specifications on determining its values
I think "Cust ID" is unique but not a primary key... or shall I say a candidate key and in first normal form one need to identify each row uniquely. The trouble he had before was identifying "Alan Smith". If "Cust ID " is same then all information belongs to the same person. And we are performing normalisation because the table is badly organised.
If I have watched this video before 3weeks by this time I will be working in an company which I have attended before 3weeks and they have asked to explain normal forms with tables as examples but I don't know this concepts at that time but I had answered other all queries now I was confident I can crack any interview after watching this video Thanks man good explanation keep going !
Everything is good but at last i am bit confused.. In Subscription table you said Cust Id is a primary key.. But it is having multiple entries (one for xbox and other for playstation) for customer wilson44. Primary key will not allow multiple records belongs to same id. Correct me if i say something wrong..
8:36 I think it indeed will be a "foreign key", not a "primary" Also, quoting a comment below: Primary key cannot repeat the same value and must be unique in relational database. Thus, it will require an extra "id column" to make each wilson44 unique.
I think he is talking about the subscription table at 18:33. In that case, I think the combination of Cust ID and Newsletter is the only valid candidate to be a primary key.
I think he made a little mistake as you were able to spot it easily, "Cust ID" column in the "Subscription Table" should be a FOREIGN KEY instead as a PRIMARY KEY is always UNIQUE and does not allow duplication. But it was a great video though it helped me a lot, I'm having trouble normalizing my database for a college case study :p
Awesome way to learn ... The way you teach is way much better than any other instructurs on youtube.. your example selection was the most important part of the video and it was bang on target. Thanks again!
+Aayam Oza I noticed this aswell. I think if he should have another table with the Newsletter and a primary key. The table he created could use the Customer ID and the Newsletter ID together to create the primary key. Then surely you could query the database and retrieve everything belonging to a Customer ID and retrieve all the newsletter IDs? thats how i would do it
this is just an example so think about it that you want to to be different and unique here...the compound key is unique. If in any situation you think it's not unique anymore then you need to fix it...
You cannot have same entity in primary key. That's the concept of primary key - it defines all attributes uniquely. For ex- you bank account number can be primary key because every person in world have unique bank account number. If you have 2 same bank account number it will be disastrous as other person can transact from your account.
I dont think it enforces primary key on the 1st NF. It says no two rows could have identical values which is not the case here. But as you move on the 2nd and 3rd NF the primary key will come into picture .
Hi.. i have a small question... The rule of primary key is that there should be NO DUPLICATE ENTRY for a column, but in your explanation i see CUST ID with duplicate entries "wilson44" which violates the rule of keys. Can you plz explain your logic behind this? Correct me if i am wrong. Thank you.
+Mohamed Fakhreddine i believe Tushar is refering to the subscription table, you have duplicate entries "wilson44" on your primary key column. this violates the rule of primary keys which states that each key should identify a single row
There are a lot of things wrong with this normalization: 1. Subscription table should have a auto increment ID as primary key, in the result it has wilson44 2 times in it. This is not possible in a real database because the primary key always has to be unique. 2. Invoices table, in the result one customer can only buy a playstation or xbox 1 time. This is because custID and Item are a compounded primarykey, so if a customer tries to buy another playstation it is not possible(primary key duplicate). 3. The shipping address would NEVER ever get stored like that in a database, a better way of doing it is splitting the data in to multiple fields.
@@CynicalOldDwarf AND they wont have any ping problems if they connect them via LAN cable , the only way to determine who is better .. it seems i have underestimated the intellect of this man .. *tips his hat*
Hello , You First Normal Form is not Good. This is wrong . because you are making the customer ID (Cust ID) as primary key and willson44 are two time in Primary column. you should yellow (make primary key ) item as well . then its satisify the first NF. Then I did not go further as I don't want to make my concepts wrong. Regards, Your well wisher
This man explained it logically. I can picture the database inside of my mind and how it works. My lecturer didnt do this. She just poured out theories and didnt explain it
This video is superficial ... First, it doesn't explain anything about how PK (Primary Key) is selected along the way from FDs (functional dependencies), selecting SuperKeys => Selecting Candidate Keys => Selecting a Primary Key. As well, it doesn't say anything about 2NF rule that a non-prime attribute should not depend on part of the Primary Key (and for that, we are looking for a minimal Primary Key which has to do with Candidate Key). In addition, the "conjunction table" primary key is wrong ... think of that a certain customer will return to purchase the same product again.... so we are going to have duplication on the primary key which is invalid. This entity (table) requires a surrogate attribute i.e. purchase ID which guarantees unique tuples (rows), and I think that some attributes are missing on that table like date of purchase, quantity, cost, etc.
The comments in this video are a bit disconcerting. I read that many people, and I quote "Learned more from this video than from thier professor" or "Have a test in less than x hours and this video helped them to understand the material". This video has a bunch of mistakes! This is not a good refrence.
Although a commentor pointed it out, channel5567 mad a mistake to call in the customer table the first col a Primary Key, since it PK must be unique, never NULL, and never change, that is a tremendous fantastic video about NF in databases. I have learned a ton with it. THANKS A LOT!
Hi, Your tutorial is the best of the best in term of explanation of normalization. I wouldn't have understood this concept if not for your tutorial and how clear your explanations are. Bravo. I really appreciate your understanding of this concept and for passing it onto a novice like me..
![ถ้าพี่วุ้นท้อง แป้งจะท้องไปด้วยกัน !!!! [ดูคลิปเต็มหน้าช่อง] #Short | PANG ORNHIRA](http://i.ytimg.com/vi/FeyEnVMwitA/mqdefault.jpg)
bless u, much better taught than my shitty lecturers
I feel u dolan, Keep those MLG montages coming though i enjoy your content
Wow Wasnt expecting you here
What brought you to this video Dolan?!
You taking database management at the moment?
Wow
is the legendary Dolan
Watching this 20 minutes before my database final. Thank god this is only 19 minutes.
lmao tomorrow morning I have DBMS exam and it's late night now.
+Amila Abeygunasekara good luck. I passed my class :)
+David Maiolo thanks mate!
same
same
This video was more helpful than the college classes I pay for. Thanks for creating this video.
+Steve Burns Haha ... so true lol
I have a professor that makes me go to sleep every time he talks
No hard feelings ofc but I learned more in this video then I ever did there
Lol....I think we have the same instructor
+Steve Burns so true.
+Steve Burns Agreed! They all keep using the same dry examples from the 80's. This was great!
Because most employers aren't going to just take your word for it that you studied. They want a piece of paper from a place they can look up that shows you've been tested on the subject matter and passed.
So are we all here before an exam?
yes😂
Yes o
@@JiaSkigood luck broski 🫡
Yeah bro
@@rupaldhurde5937 gl m8 🫡
I'm dumb, so the only thing I've learned in the past 4 minutes is that beautiful isn't a colour, it's an opinion.
I am dumber. I thought black is the new beautiful.
3:00 - 1st Normal Form
6:21 - 2nd Normal Form
9:40 - 3rd Normal Form
13:37 - 4th Normal Form
18:07 - Table relationships and name
How does something so simple can be super confusing in class?
Thank you so much!
Hi please help may code
18:07 is 5 n.f
5 classes, in 10 minutes (skipped through a bit). Final in 7 hours. You saved me a ton of sleep. Thanks!
+Troy Kachor Hahaha Ikr! All the best! Final here in 19 hours.
+Troy Kachor hope you both score great :)
+Troy Kachor 12 hours ayyy
+Troy Kachor hahaha final in 11 hours!
+Troy Kachor Last minute studies ftw
The most accurate and clear explanation for normalization you can ever find. Your work is amazing, my friend.
This is so much simpler and practical compared to the overly formalized logical relationships they use to try to teach this. You don't need to worry about terms like functional or transitive dependencies....The data speaks for itself and becomes intuitive with this approach. Thank you so much!
Thank you SO much for this video. Less is more (and just enough). This was perfect and SO organized and thank you for building on each example, too.
This man out here saving lives. Actual saint. Thank youuuuu for finally explaining this in human/real terms sir!
There are dozens of videos out there on TH-cam but this one is the best. It explains on real life kinda scenario and is easy to understand all these functional dependencies. Thank you sir very much.
Thank you so much. Now, my head is functioning Normal with your Normalization lecture. Definitely, better than what I learned in class.
Protip: Set video speed to 1.25x or 1.5x
I used 1.5x and feel he talks normally and at last minute I return it back to normal, I felt that he have taken some kind of drugs
i really want to thank you/ life pro tip
LOL
1.5 was good enough for me
2x even better
Hands down the greatest normalization example and explanation I have ever watched. He used one example straight through unlike others who like to switch the example once they reach 2nf and he explain partial dependency in layman terms than just textbook.
Love this tutorial. It's very precise, doesn't waste time, and gets to the point right away.
I just finished this chapter in my book and it was tough to read. Your breakdown really helped! Thank you!
On the first table at 5:51, Cust ID cannot be the primary key as the values in that column are not unique (e.g. wilson44). The correct way would have been to label that as a foreign key (it would be the primary key of a customer table) and then have a Sales ID which would be unique.
Exactly, I kept thinking that wilson44 is repeated even though it's a primary key. It needs to have all unique values. but he never addresses it.
I think because the table is not an "Employee" table and wilson44 purchased two different items and also subscribed to two different newsletters.
Yeah... video is incorrect. First table should have order ID or something, not customer ID.
Well the user ID's are unique because they're like usernames on social media - they can only be used if they're not already taken.
They are normalised, they're just secondary keys, not primary ones.
Aquí tienes un mensaje en español de alguien que te agradece profundamente está clase, tras 6 años nunca entendí la normalización y en tan solo 19 minutos, me ha quedado mas que claro. Estoy agradecido infinitamente.
Appreciate the video tutorial. This does bring some clarity to what normalization means in these databases. This is my first time studying databases (DBMS) and its a lot to take in, but I appreciate videos such as this one which brings more understanding to these database concepts. Thank You
more helpful than several weeks my professor spent on normalization. Thanks
That's true! Good explanation +channel5567 :)
I appreciate this video. I wish you would have addressed BCNF as well because the way you explained these four forms are clear and concise.
This is one of the best videos I have seen on this topic. Great example, and great explanation.
Damn, you just made normalization easier. I was having trouble identifying dependencies but the way you explained it was as accurate and practical as hell. Thank you for this wonderful video!
I've been learning SQL on my own and you explained this topic very well. Thank you.
slacked off all semester. final is in 30 mins, just finished this video and completely understand it. Phenomenal.
you deserve $123,000 dollars a year because you taught me what my professor couldn't in thirteen minutes, godspeed and good luck
You made this much more easier to understand than everyone else I've went to! Thank you!
Simple but understandable for beginners, way better than explanations in textbooks
Cust ID can't be a primary key unless you introduce a list of unique customers. There's a duplicate wilson44 Cust ID, which means it can't be a key. You'd have to introduce a column Order ID or similar. (In 4NF this problem simply moves from Customer Table to Subscription Table)
how would u fix the problem on the bridge table ? i was thinking about adding a quantity row for not preparing (ex: Wilson - xbox) srdy for 4 years later lol
fr
Excellent video! I sat through 2 hours of online classes and had no idea what the professor was saying, thanks for fixing me in 20min!
This was the best video I have seen to date on basic database structuring. Good job man!
Subscription table has error. You have to add ID column, because wilson44 appears twice...
+Milan Mijailovic Indeed, imo they all should have ID columns, especially invoice too. What if a customer buys another playstation or any item multiple times?
Can you please explain why there is a need of 3rd table in 2NF?? We could have added aother column in the frist table and entered the name of the products along with the newsletters.
This table should have compound key like sales invoice table. There is no possibility to one user has the same subscription twice.
you need to have a seperate table for cust_id and newsletter.
I totally agree with you and please find my reply to solve the issue..
love the real-world examples and little details (allan thomas smith), good job
Was going around in circles looking for an understandable explanation, now click! Thank you!!!
I struggled with this concept for a long time. This completely cleared everything up!
this helped a lot. when youtube is a better teacher than you pay for. :)
"There's still a question about this, Alan Smith....."
Thank you very much for this. I searched online for a couple of hours and no one explained it so clearly as you.
Your presentation was the icing on the cake, you solidified my understanding of the concept beyond my imagination. Thank you.
Everything is good but at last i am bit confused.. In Subscription table you said Cust Id is a primary key.. But it is having multiple entries (one for xbox and other for playstation) for customer wilson44. Primary key will not allow multiple records belongs to same id. Iam confused at 4th normal form because a key attribute will never entertain same values to insert more than once so how we solve the problem on your given example particularly at (4nf) please elaborate the explanation. thankyou
1NF is about 5:12 ... 2NF - 7:45 about... 3NF - 13:27
Great video. You broke down each level of normalization really well. Thanks for uploading.
You are an absolute legend. May god bless your soul.
how can you have duplicate values in Primary Key column ? If that is the case, don't we have to combine it with other columns to determine a candidate key?
its actually true, as it called as the composite key, that merges the primary key and candidate key(s) for a better specifications on determining its values
They are just identifiers and not primary key.
for the first normal form, "wilson44" shows up twice. So how can the key uniquely identify each row if the key value shows up twice??
I think "Cust ID" is unique but not a primary key... or shall I say a candidate key and in first normal form one need to identify each row uniquely. The trouble he had before was identifying "Alan Smith". If "Cust ID " is same then all information belongs to the same person.
And we are performing normalisation because the table is badly organised.
Thanks a million!!! I couldn't find anything better that this. Loved it!!
I can't explain how helpful this video was, thank you.
If I have watched this video before 3weeks by this time I will be working in an company which I have attended before 3weeks and they have asked to explain normal forms with tables as examples but I don't know this concepts at that time but I had answered other all queries now I was confident I can crack any interview after watching this video
Thanks man good explanation keep going !
Everything is good but at last i am bit confused.. In Subscription table you said Cust Id is a primary key.. But it is having multiple entries (one for xbox and other for playstation) for customer wilson44. Primary key will not allow multiple records belongs to same id. Correct me if i say something wrong..
8:36 I think it indeed will be a "foreign key", not a "primary"
Also, quoting a comment below:
Primary key cannot repeat the same value and must be unique in relational database. Thus, it will require an extra "id column" to make each wilson44 unique.
@Igor Aherne check my query pls..?
I think he is talking about the subscription table at 18:33. In that case, I think the combination of Cust ID and Newsletter is the only valid candidate to be a primary key.
I think he made a little mistake as you were able to spot it easily, "Cust ID" column in the "Subscription Table" should be a FOREIGN KEY instead as a PRIMARY KEY is always UNIQUE and does not allow duplication.
But it was a great video though it helped me a lot, I'm having trouble normalizing my database for a college case study :p
You should watch you fellow indians tutorials
7 years later & this is still gold!
Such a good video, man. Especially how it all came together at the end. Thank you.
very useful tutorial, just saved me a lot of time instead of understanding purely by reading notes
This was infinitely more helpful than the college class I'm taking going over databases -.-
much thanks to you, this 20 mins teaches more than what i've learnt in 1 month.
Awesome way to learn ... The way you teach is way much better than any other instructurs on youtube.. your example selection was the most important part of the video and it was bang on target. Thanks again!
This is the best lecture on normalization I have ever seen thank you
wouldn't the Shipping Adress not obey the 1NF? It has multiple values such as Number, Street, and City.
You get the idea
Fantastic explanation. Learned more from this easy to understand explanation than from several videos I have watched. Thank you.
I will remember this tutorial for a life time. Thanks a million times buddy.
Thank YOu
Thank you for literally saving my degree.
Yep. Great explanation. You uncomplicate what has been previously presented in a disjointed, convoluted manner. Thx ! What I needed, for sure.
I could've spent 100 hours trying to understand that from the teachers course, you saved me lots of time !!
Cust ID in the subscription table and sales invoice table must be a foreign key, not a primary key, am i right?
+Nishant Revur CUS_ID in Subscription and sales invoice table is Primary key as well as act as a foreign key
+Nishant Revur Yes it can not be a primary key on its own it must be a composite key with Newsletters as you can not have duplicates in primary key.
You repeated willson44 twice as a primary key, is that not redundancy? I learnt in 1st NF there should be no repetition!
+Aayam Oza
I noticed this aswell. I think if he should have another table with the Newsletter and a primary key.
The table he created could use the Customer ID and the Newsletter ID together to create the primary key.
Then surely you could query the database and retrieve everything belonging to a Customer ID and retrieve all the newsletter IDs?
thats how i would do it
That's fine if you are using two primary key!!
this is just an example so think about it that you want to to be different and unique here...the compound key is unique. If in any situation you think it's not unique anymore then you need to fix it...
You cannot have same entity in primary key.
That's the concept of primary key - it defines all attributes uniquely. For ex- you bank account number can be primary key because every person in world have unique bank account number.
If you have 2 same bank account number it will be disastrous as other person can transact from your account.
I dont think it enforces primary key on the 1st NF. It says no two rows could have identical values which is not the case here. But as you move on the 2nd and 3rd NF the primary key will come into picture .
OMG THANK YOU! I was having a hard time understanding the differences from1NF from 2NF and now I understand!! Fabulous!
Clearly explained throughout the entire TH-cam platform!
Hi.. i have a small question... The rule of primary key is that there should be NO DUPLICATE ENTRY for a column, but in your explanation i see CUST ID with duplicate entries "wilson44" which violates the rule of keys. Can you plz explain your logic behind this? Correct me if i am wrong. Thank you.
+Tushar S CUST ID is not a primary key in the Sales Invoice table, so it can be duplicated. It's a primary key in the Customer table only.
+Mohamed Fakhreddine i believe Tushar is refering to the subscription table, you have duplicate entries "wilson44" on your primary key column. this violates the rule of primary keys which states that each key should identify a single row
May be both the customer id and the shipping address should be the primary key here.
The Subscription table has what they call a composite key. The combination of Cust ID and Newsletter make the Primary Key.
There are a lot of things wrong with this normalization:
1. Subscription table should have a auto increment ID as primary key, in the result it has wilson44 2 times in it. This is not possible in a real database because the primary key always has to be unique.
2. Invoices table, in the result one customer can only buy a playstation or xbox 1 time. This is because custID and Item are a compounded primarykey, so if a customer tries to buy another playstation it is not possible(primary key duplicate).
3. The shipping address would NEVER ever get stored like that in a database, a better way of doing it is splitting the data in to multiple fields.
Well done. The pace is right on spot so we can follow everything. Thanks.
This is INCREDIBLY helpful. Thank you!
cust ID was a bad choice. transaction or invoice id would be a better choice. you cannot have primary keys repeated
you are my savior
A great thank! This video links the Fs to table. Much better than what I've been taught by lectures.
I'm new to normalization, and I think I already understand it. Thanks! Very well done.
why would they both buy a ps4 if they live in the same house ? these the real question we all should be asking here ..
They don't like sharing, and they want to play multiplayer without split screen cheating.
@@CynicalOldDwarf AND they wont have any ping problems if they connect them via LAN cable , the only way to determine who is better .. it seems i have underestimated the intellect of this man .. *tips his hat*
2nd normal form first relation is wrong. Cust ID does not determine Newsletter. There is a partial dependency on 9:42
You're right. What do you think should be the solution? Put newsletter column into the other table maybe?
This 19 mins is ,worthy than all the lecuture notes i had on dbms.
For the first time I've seen someone explain this clearly than my lecturers at school.
Hello ,
You First Normal Form is not Good. This is wrong . because you are making the customer ID (Cust ID) as primary key and willson44 are two time in Primary column. you should yellow (make primary key ) item as well . then its satisify the first NF. Then I did not go further as I don't want to make my concepts wrong.
Regards,
Your well wisher
That's why I left the video after seeing that the primary key is not even unique .
NOTE: wilson44 CANNOT BE TWICE IN 1NF!! THERE IS A FAILURE IN THE VIDEO!
1nf allows multiple tuples but not multiple valued attributes
This man explained it logically. I can picture the database inside of my mind and how it works. My lecturer didnt do this. She just poured out theories and didnt explain it
Mine posted hour and a half long videos expecting us to be able to pay attention that long
I barely comment on yt videos but my time and energy will be worthwhile for thanking you. Thank you.
This video is superficial ...
First, it doesn't explain anything about how PK (Primary Key) is selected along the way from FDs (functional dependencies), selecting SuperKeys => Selecting Candidate Keys => Selecting a Primary Key. As well, it doesn't say anything about 2NF rule that a non-prime attribute should not depend on part of the Primary Key (and for that, we are looking for a minimal Primary Key which has to do with Candidate Key). In addition, the "conjunction table" primary key is wrong ... think of that a certain customer will return to purchase the same product again.... so we are going to have duplication on the primary key which is invalid. This entity (table) requires a surrogate attribute i.e. purchase ID which guarantees unique tuples (rows), and I think that some attributes are missing on that table like date of purchase, quantity, cost, etc.
The comments in this video are a bit disconcerting. I read that many people, and I quote "Learned more from this video than from thier professor" or "Have a test in less than x hours and this video helped them to understand the material". This video has a bunch of mistakes! This is not a good refrence.
then make a video yourself if you think you can do better damn
This is fantastic! Thanks for explaining these with practical examples. Super helpful!
Although a commentor pointed it out, channel5567 mad a mistake to call in the customer table the first col a Primary Key, since it PK must be unique, never NULL, and never change, that is a tremendous fantastic video about NF in databases. I have learned a ton with it. THANKS A LOT!
Thanks for creating this video. Simple, crisp and to the point with proper example. Amazing video.
This is the best Normalization video... everything was clear and it was audio-able
Excellent explanation. Simple but covering the what, why and how perfectly. Thanks!
Thanks for posting this! My professor made it so confusing, but you simplified it so well!
Hi, Your tutorial is the best of the best in term of explanation of normalization. I wouldn't have understood this concept if not for your tutorial and how clear your explanations are. Bravo. I really appreciate your understanding of this concept and for passing it onto a novice like me..
Excellent video. Very clear and minimal example which illustrates the concepts effectively. Thanks!
3 weeks of class in 19 minutes. Good job
This video was outrageously helpful to me and I'm so grateful that it exists
This is the best normalization video to date. ty so much
I was having hard time understanding normalization but you explained it so clear! Thank you very much for your work, we appreciate it. :)
Laba Diena bratka
Thank you so much. After 8 years it is still helpful
Only 17 videos and 4.47k Subscribers. This is how quality works.... Thank you so much for the explanation.
Thanks for the great video! This video made all the pieces fall into place! :)