Easy explanation of Normalization Relational Database Design for Beginners - 1NF, 2NF, 3NF
ฝัง
- เผยแพร่เมื่อ 9 ก.ค. 2024
- How to design a relational database using Normalization - With example
Explanation of tables, primary keys, foreign keys, relationship types, 1 to many (1:M), many to many (M:N) and one to one (1:1).
Design a database to 3NF (3rd normal form) using a normalization diagram. Desirable dependency, Partial dependency, and transitive dependency explained.
![[LIVE] : ONE ลุมพินี 69 | คู่เอก "กุหลาบดำ vs นาบิล"](http://i.ytimg.com/vi/PNM6U8e_HMo/mqdefault.jpg)
Took me 4 years to find this, but what an absolute gem. The man has nailed it.
This is so useful to get the steps through in DB design. Very helpful. Thank you.
Thanks a lot for this amazing tutorial! I'm going to watch and practice this a least a hundred times.
Thank you! Excellent explanation, extremely clear
Bravo! Everything connects! Thank you for making this.
Excellent! Thank you so so much!
Professor Im gonna see you at exam in just 4 hours and this video is the only thing that's gonna save me. Love you a lot man thanks for a wonderful semester I wish more professors were like you 💓💓
EXCELLENT video ! Thanks!!
This video tutorial definitely helps me learn more about how databases are structured in its normalization forms. Now that I'm gaining clarity of the rules of 1-3NF's it makes sense how the databases are structured on the backend. Awesome!!
Glad it helped. Keep learning.
Thanks a lot to teach us such a nice way, appreciated !!
Best explanation to be honest. You explained it very clearly.
Best video on this topic, hands down!
Great job! Thanks!
Glad it was helpful!
Thank you so much for your help. I’ve been staring at a school project for days because I did not know where to start.
Glad it helped.
This video really helped me!
Thank you so much! Very well explained 💯
Excellent explanation, thank you very much.
Bookmark For Me
40:01 - TEMP
21:46 - Naming Convention
26:09 - Normalization (Brief look into 1NF, 2NF, 3NF)
Magic ! Saved for future references
Thank you so much. You made my life a lot easier.
Thanks a lot for this excellent tutorial. One of the 3 best videos on normalization. Perfectly clear and no mistake. Hats off ! Thanks!
Which are the other 2?
Today I learned something important to do my job. Thank you so much for the time and effort you put into creating this video.
I am glad it was helpful.
This right here, is the best video I have watched in a decade
Thanks for the kind words. I am glad you found it useful.
my brain was itching on how to start my college project because first step of it was normalization and then i found this gold. thx a lot sir.
You're welcome. Good luck with your project.
This is the best video I have watched on normalisation. I now understand the process. Thank you very much.
Thanks and I am glad it helped.
It's a fantastic review....
helped me alot in my database designing much appreciated and also cleared the topic of normalization.
Glad it was helpful.
The best video ever about the normalization process ! Thank you so much !
I am glad it was of help to you.
Fully agree with you. Excellent!!!
Well explained. Thanks a lot
This is amazing. Well explained... Great job and thank you for this.
Glad it was helpful!
Super clear detailed explanation
Thank you sir. It really helped me a lot on my assignment.
Excellent. Thank you.
Thank you, good and thorough explanation and it was easy to follow.
Glad it was helpful!
Thank you so much, i really enjoyed it and was very helpful you just kill it
Thank you a lot. That's a very helpful video I watched ever.
Glad it could help.
Thank you very much for the excellent video, Really I couldn't sleep before completing the watching . I already started designing my first access database for week ago. and I discovered many mistakes that I have made based on what I see here. really this video is enough for me to start follow, recommend & subscribe your channel. rarely I comment on any video, but now I have to say what I said before. thank you
You are welcome and good luck with your project.
Thank you so much! best video on the internet :D
Thanks. Glad it was helpful
This video is very helpful... You walked us through the steps of normalization in a more practical manner. Thanks man more your efforts🙏
Glad it was helpful!
Great explanation .
Thank you for this explanation it was clear it all cuz you told us how we think for separating the table 🖤
I am glad it could help you.
Thanks for making this video. Finally something that's not recited from books.
Glad it was helpful.
I have, very much, enjoyed learning about database normalization from Jeff Goldblum. Thank you very much for the video!
LOL. I will take that as a compliment. :)
@@odintree5704 You should. Haha. Thank you so much for the easy to understand and in-depth tutorial. I greatly appreciate it.
Thank you for taking the time to do this.
My pleasure!
great work keep it up !
This is one of the best videos i have seen on many to many examples. My only concern is the sound.For a minute i thought my laptop sound is low, other than this this is just amazing
Thank you, and I am sorry about the audio level as this was my first video with my new microphone and I had yet to get the settings correct.
Super elegant thank you for making this video
you're welcome. glad it was useful
I wouldn't pass my module without these vids🙌 Thankyou!!
glad it was helpful
@@odintree5704 Sir if I had a table with data like First name, alternate First name , middle name alt middle name, last name alt last name , suffixes ect.. do you think I could reach 3NF?
@@danrielly4716 The names are OK for 3nf but by suffixes do you mean salutations such as Mr. Mrs. Miss, Mz.. If that is the case then technically the salutations should be put into their own table as a 1:M link. Depending on how picky you want to be. Some people would just leave the salutation column in the table with the names and allow the end user to type what they want (breaks the rules of normalization) or even create a combo box with preset values. again that technically breaks the rules of normalization but people do it all the time. The problem with a pre populated combo box is that if the client wants another option then you must do a slight reprogram to the front end to accommodate their request. A new table like I mentioned earlier allows the end user to add unlimited types of salutations.
Thanks, awesome video to prepare for my Database Support interview.
You're welcome and good luck with your interview.
Hats off to you sir. World class content.
Thank you.
Great!
This was fantastic. So much better than the books my school is trying to put on us. Why can't they ever explain things this simply in books? I don't get it.
Glad it helped.
Thank you sir.
BEST EVER
Excellent tutorial. The explanation of the tables setting process is the best I have seen on the internet but I have 2 questions: taken into account renovation of rooms and card expiration would mean that 2 tables should have to be created? One for renovations or no renovations and one for the expiring dates? Thanks in advance
Hello Alfredo, For the expiring date I assume you are talking about the date at which time a room was a certain type. We therefore would only need 1 new table to handle a room being changed to a certain type (ie: renovated).
We would have a Many to Many relation between room and roomtype. Because each room can have many types (not at the same time) and each type can be applied to many rooms. We therefore put a bridge table between RoomType and Room (we will call this RoomDetail). We need 4 columns in this table. roomtypeID and roomID column (as you know we need that as a minimum) and we now add a RoomDate column (this date column represents when a room was a certain type of room - a room can revert back to a previous type also) and also roomRate. RoomtypeID, roomID, and roomDate now become the composite primary key (of course you could use a surrogate key and just create a unique index on the three columns mentioned combined). We also remove the roomTypeID from the existing Room table and rromRate from the existing RoomType table.
To check what type of room a guest had on a specific date we can JOIN the Reservation, reservationdetail, room, roomdetail, and roomType tables together and use the proper primary and foreign keys along with the reservationchekin and roomdate columns.
Excellent explanation ❤️
Glad you liked it!
In the class that I'm taking, the professor likes to use composite keys of 3 or more. I'd love to see a video like this one, but with a composite key of 3 or more.
thank you
Excellent tutorial, maybe you should start teaching :)
perrrrrrrfect
For normalization, you mentioned that a column has to be the same type. If it is not, do you remove the row or how do you fix that? Thank you. Your video is so far the only one that is strait forward and easy to understand.
I believe you are asking about a column having the same type of data. For instance if you had a column for a company name and somebody entered a contact name in the column instead of the company name. In this case it would be allowed and unless you can come up with some kind of rules or constraints to stop this (I cannot think of any) then it would be allowed. What you would need to do is train the end users to enter the proper data. Garbage-in-garbage-out. In this scenario a company name could sometimes be the same name as the contact if a company is named after the owner who happens to be the contact.
You can get all sorts of anomalies for instance you may have a column for postal/zip code. You can put in code or constraints that enforce the number of characters and even the order of characters entered (for instance a postal code is always a letter/number/letter number/letter/number combination and 6 characters long not counting a space). You could enforce that but how do you enforce that the postal code matches the street, city, province combination without lookup tables.
Some things you just have to live with.
Thank you for your response. I'll see if I can apply it to my assignment. Thanks again!
Amazing Video! Thank you so much...
Can you also provide me this presentation??
Great video!
A question: What's the benefit for creating RoomID and ReservationID even though the "business IDs" are already of numeric type? As a data analysts I don't like that as it means extra lookups :) I can see that CardID does save space (16 digits for a card vs maybe 4 or 5 depending on a business success). But then I see no actual benefit for a room number. What I am missing? Thank you!
Hello Sensi,
There is no need to use what are known as Surrogate Keys for the primary key like I did at the end. You can keep the primary key values as they were but I do not like to use business data as the values for keys. In this example obviously like you stated they were already integer types so the bits will not change.
There are advantages though such as when you combine data from 2 or more sources it is easier to conform the data, if you wish to rename the room numbers or any other business data values and it is not the primary key then you do not have to worry about ensuring what is known as Cascade Update to be activated. I am a strong advocate that once a primary key value is set then there is never a need to change it.
I have seen developers use business data as the primary key that is completely inappropriate. Such as using Social Security Numbers or Serial Numbers for instance as the values for primary keys.
Based on your question you are obviously aware that you should never use character fields as primary keys as character fields impact performance compared to integer.
Thanks for your insightful question and I hope I answered it to your satisfaction.
soooo, what are the repeating columns?
I have a question
when we normalize tables to a third normal form shouldn't we check if the non key attributes determine the primary key?
The email attribute seem to determine the reservation number in this case.
Hello Kidist,
Good question. I have not looked at the sample database I used for this video in awhile but I will guess that the email does not determine the reservation number since the same person could have multiple reservations with the same email.
As to whether a non key attribute could determine the PK it is possible. For instance if a table is in 3NF but has 2 candidate keys then the alternate key could determine the PK.
For instance assume an employee table:
EmplID --> EmpFname, EmpLname, SSN
As you can see we have 2 candidate keys. EmpID and SSN. SSN is the alternate and will also be unique.
Hope that helps.
was 0:00-0:03 the "Fata Morgana Requiem for Innocence OST - between worlds - smiling cynic"?
I swear it sounds the exact same lol
Excellent video.please provide any document for this explanation
thank you so much for this amazing explanation, just one thing with cardType, i guess it's better to put it in a new table, [id, cardType] and put the id in cardType, because imaging The "MC" has a new name "AB" for example, in this case you will go to every row in the card table and change "MC" to "AB", if it's in a separate table, it will update just one time, correct me if i'm wrong, thank you.
You are correct. Sorry for the late response but youtube sometimes does not show comments. So the only way I find some comments is to scroll through them.
Does a bridge table always have a composite key since it's linking two tables each with their own primary key?
No. You can make a surrogate primary key if you wish. ie: Just an auto generated number column. But make sure you make a UNIQUE composite constraint on the two FK columns
@@odintree5704 "make sure you make a UNIQUE composite constraint on the two FK columns"-- Does this mean that all non-key attributes in the bridge table depend on the combination of the FKs and that the combination of the FKs are only repeated once in the bridge table?
This was an excellent video btw. Once I went back to other normalization videos I had watched, they all made more sense. Thank you.
@@shawnshahpari8681 Yes, all non-key attributes will depend on the combination of the foreign keys and sometimes also you need to add another column to the key such as a date. It depends on the role of the table.
This is awesome!!! Why did you stop making videos ?😊??
Maybe I will do some more. Thanks for the positive feedback. Glad it was helpful.
i need a detailed explanation of how a relational database is designed taking into consideration normalisation , relationships and primary keys
Can't we just create column as Id and auto increment it and make it as primary key?
Yes you can and that is what I always do.
That is what I do at the end with the surrogate keys. I make all my primary keys a surrogate key with auto numbers or sequences.
I also never call my surrogate PK's just "ID" because that gets confusing when you start creating the queries and any code. I use my naming convention so I would call it something like EmployeeID, CustomerID, etc. rather than just id for all the tables.
Thank you, i suggest you make a video for 4nf 5nf .
i will consider it
was the name not supposed to be displayed as atomic value for 1NF?
Yes. But as indicated in the video I did say I would do it at the end because a lack of screen space. I wanted all the columns to show on the screen. I indicated that I would just have to remember to do it in the last step. But you are correct that it is supposed to be done in the 1st step.
So in order for me to do this I am going to have to imagine that there is data in the table
Hello Chris,
You do not have to design with actual data. As you get better or get the idea of normalization you can design without any data and you will immediately see the tables and relationships.
I have shown it with data so a person just starting out gets the idea of why and how the data relates to each other and to the tables and the columns.
okay so I just did your exercise prior to watching how you solved it , not sure if i did it right. But I used the entity approach and created 4 tables below. I then used foreign keys to connect them together
Room
Payment
Guest
Reservation
Almost. You are missing the bridge table. Card table - based on my rules. Honestly you could get away without the card table if you wish. Should also have a room type.
i captured the card info under the Payment table and the room type under Room table . I wish if there is a way I could send you what I created
@@moabbas5525 It is actually very easy to represent your design by using a dependency notation. It goes like this.
Assume you have a table called product and a table called supplier. This is how you would represent the design using dependency notation:
Product : productID --> productName, productCost, productSell, supplierID
Supplier: supplierID --> supplierName, supplierPhone
As you can see we have indicated the name of the table. The primary key for the product table is productID (usually we would underline it but I cannot here). But that is not important because the arrow ( -->) after it means that the column productID DETERMINES all the other columns. That is a definition of a PK.
In the product table I have a column called supplierID and in the supplier table we have the PK as supplierID so I can infer that supplierID in the product table is a foreign key to the supplier table and is related to the supplierID column in said table.
So you can represent your design like this.
@@odintree5704 I’ll try that thank you so much for taking the time to reply back to me .
Of course, the problem with your hotel reservation DB is that some people have no e-mail address 😛
Obviously, you have missed the point of the video. It was a primer on normalization and the example has limited rules to keep it as simple as possible but still show the concept of normalization. The example also does not take into account renovations to existing rooms and many other things. Where do we end and how complicated would you recommend making it for beginners? But if you point me to your video on normalization I may learn something.
Remove the partial dependency by ensuring that no columns can be a primary key for another.
@OdinTree, many thanks for a great video explaining normalisation. I love it that you have many attributes in your hotel room booking data to show all the different aspects of normalisation.
I have one confusion after watching so many online resources and I hope you wouldn't mind helping me out . Some other videos (e.g. th-cam.com/video/UDFRhj_K508/w-d-xo.html) and lecture slides ,although correctly claiming that "repeating groups are not allowed", but then proceeded to split the unNormalised data into 2 different tables, with the repeating groups as a separate 2nd table, during the 1NF, and each with table having a simple primary key. One set of university slides I have seen even proceeded to assign a foreign key (in addition to assigning a simple primary key) after they split the unNormalised data with repeating groups as a separate table.
I wonder if this is correct? Is such a way a permitted and an alternative way to normalise data?
Personally, I love the way you have assigned a composite key during the 1NF stage, I personally would prefer to do it your way as I can see partial dependencies in the data from a table with a composite key.
Which method, your method or the method I mentioned above a more conventional to normalisation? I just want to make sure that knowledge that I am passing on to my to my team members is the correct method when I am coaching my team members.
P.S. It is also good that the final design becomes truly atomic with the customers' names being split into first-name and last-name! Did you do so at the end so that youtube viewers would not get confused? Although, I probably would have done so during 1NF instead of during 3NF. Am I correct to think the rules are attributes have to be in atomic form while in 1NF?
P.P.S. Would you have a textbook at you could recommend? I have read a few textbooks but they aren't to understand.
Many thanks.
Hello thesparkles4,
Thank you for your question. I will answer the last question first. You asked about me atomizing the name into a first and last name in the final step. As I mentioned in the video this atomization would normally be done in 1NF but if I did it in 1NF I would have too many columns across my screen, so I said that I would just remember and do it at the end. I just wanted all the columns across the screen so viewers could see all columns without me shrinking the font.
Now as to his method of breaking out the repeating group in 1NF, yes that is a way to do it. I just do not like this method for a beginner as they would need to understand about immediately adding a primary key and taking the necessary columns out of the UNF table into the new table. Notice he added some more columns that were not mentioned in his UNF. But pretend those extra columns were in the UNF, a beginner would have to recognize that those columns would have to be moved into the new table.
The 2NF he described is also confusing (in my opinion of course) for beginners to understand why he created new tables and where he got the primary keys from and all the other columns, etc.
Obviously looking at his UNF a person who has done design would immediately see the tables that are needed and have the design done in about 5 seconds. But I have always found the way he is showing it and how a lot of people show it assumes people already recognize what tables are needed.
When you look at the UNF the tables that are going to be needed are always subjects or nouns if you prefer. For instance all tables are either a person, place, thing, or event. His example you can quickly see all the subjects of the database - We have agents, we have agencies, and we have customers. All are related to each other but now you have to figure out which table is related to each other manually. Some people who are beginning design cannot do this step. And to confuse it more what if an agency had different contact numbers for each agent (obviously we would need a table for that), and what if an agency had multiple locations (obviously we would need another table for locations). See how a beginner might not see that.
So his way is correct and like I said a lot of people explain it that way but I do prefer the way I explained it for people just starting out. You can choose your poison (lol).
As to the text book. I have never seen a very good one but I think there is one called Database Systems - Design Implementation and Management (Rob Coronel) that has the method I show. I think this is the book but I saw it over a decade ago so I may be wrong.
Edit: I would also like to point out that the way I show it you will never have to worry about BCNF because it will be eliminated automatically where the way he has shown it you may still need to normalize BCNF.
@@odintree5704 Thank you so much for taking the time to answer my question. I must agree I prefer your method of normalisation (let me name it Method 1) but I Was exasperated by the vast amount of online resources performing the normalisation in the other way (i.e. by splitting tables in 1NF, and let me name it Method 2) and also presenting it without enough data to show the concept.
I need to transfer my knowledge of normalisation to my team and I just want to make sure that the method that I adopt is easy to understand and that I have a book to back me up (as most other resources I come across are either unclear or are pointing to Method 2). Many thanks as I googled and I found the book on amazon! Hopefully, I will get hold of it soon to read up further on Method 1.
The one thing that I am still unclear, and I hope you wouldn't mind clearing my doubt, is to do with the lecture slides that I have been given where in it Method 2 is adopted and in 1NF a foreign key is assigned to the the 2nd table (in addition to the primary key). As far as I know, 1NF only requires every relational table to have just a primary key. I thought this would further confuse beginners.
P.S. It is entirely my fault for missing out on your reason to only splitting names in 3NF (instead of in 1NF). I revisited the motel examples several times by clicking on different time stamps of your video, but I mustn't have clicked on the timing when you mentioned it.
Once again, many thanks for the very information video and your time taken to answer my query.
@@thesparkles4 Foreign keys can be added at anytime when you are using Method 2 as you call it. You just must be aware of what table and column is referenced. This is hard for beginners to grasp. They have to be aware that the table that is split off must be dependent on another table and column.
I will also say that there are specific rules for each normal form as indicated in my video but you can go about designing anyway you like as long as each rule for each normal form is taken into account. The final design is the critical one and how you get there in my opinion is irrelevant as long as you get there.
Based on experience the way I show it has been the most successful when I need to explain the process. The other way (method 2) is always confusing to beginners and they just seem to try and guess along the way rather than understand what is going on.
@@odintree5704 Very well said, there is a lot of guessing work by using Method 2 and this is the reason why I would like to avoid it. Many thanks for your reply on foreign key!
I also love it that you turned the normalisation example into an ER diagram towards the end of your video! This makes your video unique and useful for understanding quite a few topics in databases!
48:33 not normalized, 1:05:00 normalized
You cannot recommend using 0-9 and a-z only and to use "_".
Why not?
Taka razlaga bi lahko postala vzor
What happens when you have 3 fields as a composite primary key and 2 of those fields can determine something but not the third...seriously
scratching my head
Hello MrME,
That is possible. You may just not have all your columns defined yet and they would go with the remaining column from the PK (ie: partial dependency), or there actually are none and it would remain part of the bridge table. A date column would act like that for instance. Also a possibility of 4NF which I think I should do a video. But I do not think that at this point.
If you want me to look it over you could post your 1NF.
@@odintree5704 its a gazillion fields. I played with it a little bit and it seems to be weird because I have fields with null values
the composite primary key I came up with is order id, product id, cust serv inquiry timestamp
when I tried normalizing though, its a bit tricky because a customer may or may not have a customer serv inquiry
Also, now that I think about it, it's possible for a customer to not have a sales rep if its an online order.
Why on earth do you like those artificial primary keys? A DB with artificial keys is no longer a relational DB.
Since when is a DB with surrogate keys not considered a relational database? That is one of the most ridiculous statements I have ever heard. Now if you said it violates 3NF I would 100% agree. But that is perfectly acceptable and is common practice. As a matter of fact a lot of databases violate 3NF. Depending on the use of the DB most DBs would be violating 3NF by not breaking out tables for city, state, country, zip/postal. But who is going to create a table with every know city in say just the USA in every state and create a table for the many ZIP codes. You would only see that for an application for the P.O.. I honestly would not want to ever work on one of your DBs since I can picture the complete mess they would be in.
Why don't you use the productNumber as primary key for the product master?
With productID as primary key you can create two "different" products with the same productNumber. Have fun...
You seem to be a fan of artificial keys - I am not. An invoice table that allows duplicate invoice number is ridiculous.
I have never seen an invoice (or order) table with the product number as part of the primary key. The customer might - for example - order the same product for two different shipping dates. The second key filed should be a line number.
Of course, the InvoiceDetail table should NOT have a productCost or a productSell columns - unless you have - as is common - price tables with a date in the key. Then matters get much more complicated.
As mentioned throughtout the video - You could use the productNumber as the PK if you wish. I use surrogate keys as most people who actually design Transactional databases do. Some use the natural keys but in my opinion they are not aware of the problems. Such as the inefficiency of creating a PK on a character column since the default for most RDBMS is to index the PK automatically. In MS SQL the default operation is to apply a Clustered index which MS recommends should be integer type. Although Oracle does not have Clustered indexes they still recommend integer data type also.
Have you ever heard of a UNIQUE index? Obviously you would apply a UNIQUE index on the productNumber column to avoid having a product with duplicate productNumbers. But any person who has actually designed a database would know that.
Of course you need to save the price and cost in the invoicedetail table. How else do you reprint an existing invoice after the default pricing has been changed in the product table. And yes I would add a line number column to the invoicedetail table but the table I used was to just demonstrate the meaning of a composite primary key. The reason for a line number column would be to reprint the original invoice in the proper order. Other than that you do not need the line number. It was not meant to show a complete design.
Please understand what you are actually commenting on and not just make comments to try and pat yourself on the back.
To help you better teach about tables and for everyone else whom may read this - RDBMS tables have Fields, Records & Attributes - While spreadsheet programs such as Excel have Columns, Rows & Cells (or Cell Addresses) - You NEVER refer to a RDBMS table as having Columns or Rows or Values, Cells, etc. Those names are reserved for Spreadsheet programs. In a spreadsheet program at the he intersection of a Column & Row you have a Cell (or Cell Address). In a RDBMS at the intersection of a Field & Record you have an Attribute - RDBMS 'Fields' are NEVER referred to as 'Attributes'. Please for the Love of God stop teaching folks that RDBMS tables have columns & Rows & Values Learning these rules and thus teaching these rules will become crystal clear when you begin programming in these completely different systems.
Hello Rhythm515,
Thanks for your comment but if you actually took the time to listen to the complete video I did mention that people use different terminology and that I usually use the terms fields and records. I also mentioned the term attributes etc. Currently it is common practice to refer to records as rows and fields as columns (it is heavily represented in almost all documentation from the major RDBMS suppliers - the terms records and fields are actually losing significance
:( ).
As to the term value what would you call the specific name of the data in the intersection of the column-row?
If you are going to make comments please back them up with facts and not just your conjectures or misguided beliefs. I have been programming applications and working with databases for over 25 years (going onto 30 years if I really want to admit my age) so I like to think I know a few things about databases.
I mention all terms that a beginner might experience because if I just mention the term record and field and then they hear or start reading about other terms they might not see the correlation.
I do hope you now see your errors and the fact that not everyone who is starting out with databases has your vast knowledge when it comes to databases and other software.
And to clarify even more, the term Attribute is more often used in Data Warehousing and not in OLTP systems.
I do look forward to your video on designing databases to 3NF as I am sure I will gain new insight and knowledge that I am lacking.
@@odintree5704 I appreciate you taking the time to respond - I did watch your videos in it's entirety. You have a good video, and while you do caveat the incorrect usage of these terms you fail to assert distinction and correctness from the correlation. Yes, the terms row and record just as field and column are (way too) often used synonymously. So while it is good you mention this, you failed to clarify that while they are used synonymously they are in fact NOT synonymous. But, as someone who has been doing this for 30+ years you know this - You simply neglected to clarify it for your viewers (students)..
As someone who makes a living working with Excel, Access & SQL communicating correctly makes a big difference. Thanks...