Thanks for putting your time and energy in putting together this amazingly effective tutorial.

Absolutely magnificent. SO clear, concise, with great examples, raising and answering all questions, and also very technical. Take my like, sir.

As I was struggling to understand this topic through my university lectures and book, I found this gem on KZread and now I finally understand database normalization. Crystal clear explanation and with real examples. THANK YOU VERY MUCH! It would be nice to see an explanation on transactions!

@tsunamio7750

Жыл бұрын

After 3 years at work, I came back to finalize my studies with a Msc. I now realize how powerful multi-media is compared to the grey-old research papers. The quantity of information we can pack and the clarity images and movement provides. next generation research documents will be partially if not totally in video. All we need is for ctrl+f(search by keyword) to work on voice tracks. But the amount of work to make those videos is massive. Thanks again, Decomplexify!

@TravisHi_YT

10 ай бұрын

@@tsunamio7750 AI is listening and watching everything, it's only a matter of time until everything on YT is transcribed or stored away as a dataset for ML.

The key to understanding this explanation is to understand candidate keys, prime attributes and non-prime attributes are clearly. This is wonderful job by the creator. Amazing and super clear content

was having problems doing an an assignment but came across your videos, and my problems was truly decomplexified... nice tutorials. Hoping you'll create more videos. Thank you.

@decomplexify

2 жыл бұрын

That's great to hear, always pleased when the videos help people to grasp concepts that might at first seem complicated or obscure. Thanks!

This is the best tutorial about database normalisation I have had. You have made such a complex concept so easy to understand. Many thanks 🙏

At lease spent a few days searching different resources to know what is additional benefit BCNF has over 3rd NF. Some made me even more confused. I saw this one and should say hats off! Great explanation and was covering many of the edge cases I had in mind. Thanks a ton!

Great videos. The pacing and structure of all of these make it really accessible.

Amazing video, I have spent over a hour reading and watching other videos and was left confused. This 10 min video did more than all others combined, Thank you!

Thank you I especially appreciate how you described why the definition of 3NF necessitates BCNF!

Your videos are amazing! Your explanations are so clear to me. Thank you!

Keep this quality up and you’re going to be real popular real fast.

I've been searching so much the answer to the question that why would we need bcnf over 3nf. And you can try googling it, none of the website or blogs are properly answering it. But finally got it here and it is well put, so thanks.

This is by far the best explanation ever!

Incredibly clear and super helpful! Thank you so much!

Thank you for also providing good quality subtitles!

I find it crazy this channel is under 1000 subs. Top-tier content that is easy to follow. Great stuff looking forward to seeing more .

@decomplexify

Жыл бұрын

Much appreciated! Hopefully I'll get around to doing a video on denormalization before too long.

Thanks for this video. I hope you can make more videos on DBMS. You can also make a playlist where you explain concepts which are majorly asked in interviews.

Now I can return to my project feeling like I am in normal form

Your vid on normal form appeared in my feed because I've been learning SQL online. Despite not having a clue what it meant, I watched and found it to be very interesting. It led to this video which I've been spending the afternoon with. I will certainly be watching all of your videos now because they seem to be very relevant, and as a self learner, I am extremely grateful to find such a high quality resource. Thank you!

@decomplexify

Жыл бұрын

Thank you, that means a lot to me - I'm glad you've found my stuff to be a useful resource, and it's comments like this one that give me a reason to keep making videos! I'll be releasing an SQL joins video in a little while so stay tuned for that.

i was so struggling to get the idea. thank you so much sir, you ARE really better than my professor.

Excellent video, helped me out on my database course

your video is magnificent, good explanation even language is the barrier but can fully understand what you trying to explain

Perfectly explained! Thanks a ton!

Holy moly, this is an amazing video

Love your explanation ❤

Incredible explanation.

Great video dude Lots of loves and prayers

Excellent explanation!

my gosh, you are so good at explaining this. A Salute for you, you clear all question in my mind about BCNF.

Thank You, sir this helped me a lot.

Brillant! Thank you!

This type of videos is absoultely amazing... So if I understood correctly, if I had a table with no functional dependencies, would it automatically be considered to be in BCNF?

Awesome content!

Great explanation, thanks c:

thank u so much! my finale is tomorrow and this is exactly what i was looking for

@decomplexify

11 ай бұрын

Glad to hear it, good luck with your final!

Awesome explanation 👍🏻

Really good explanation

Awesome 👍🏻 please make more and more videos

Tomorrow is my exam and this saved me a lot of my time. Great Explanation.

@decomplexify

2 жыл бұрын

Always good to hear - glad it helped you with your exam preparation.

This video is an example of how to simplify a complicated topic, without oversimplifying it to the point of making it obscure. If you believe it is an easy thing to do, look up other videos that (try to) explain relational DB normal forms, and cry :)

@decomplexify

Жыл бұрын

You've hit the nail on the head there. I can confirm that it's not easy! But very satisfying when I feel I've managed to do it.

I have a question, in the example of popular movies do we even have first normal form? As i understood the attributes should be atomic and "Release Year AND Month" looks quite non atomic since we can have release year AND release month as seperate attributes (which is also the solution proposed for BCNF). Am I loosing something?

Thank you so much

Epic vid 🎉

Thankyou very much✌️

@decomplexify

2 жыл бұрын

No problem 👍

Show demais!!!!😆

How does one determine if some column actually has functional dependency on some other column

@decomplexify

2 жыл бұрын

I talk about this to some extent here: kzread.info/dash/bejne/eXqFw6eSdcaej5s.html ... One useful exercise would be to ask yourself: what is the relationship between a customer and a first name? a) Is there one customer for each first name? The answer is no, clearly not, because you can imagine a first name "John" that is possessed by multiple customers. b) Is there one first name for each customer? The answer is yes, because a customer only has one first name. Therefore first name depends on customer, and if you ever see a table with columns CUSTOMER_ID and CUSTOMER_FIRST_NAME, you can be confident that CUSTOMER_FIRST_NAME is functionally dependent on CUSTOMER_ID.

Please make videos on correlated queries

do you do all of database?

can you do Axioms and the math side of this??? it is on exams and HW i think it would be AWESOME!!!

Hey, keep making videos, you’re good. That’s all. :)

@decomplexify

2 жыл бұрын

Thanks! Will do. I've got another video coming out soon, hopefully in just a few days.

@AmexL

2 жыл бұрын

@@decomplexify awesome. I just saw you dropped the video and I love the topic, definitely going to check it out. Keep up the great work!

Thanks. Can you tell me which font is used in this video?

@decomplexify

2 жыл бұрын

Yes, the font is called "Kalam".

I've always used sequential integers for primary keys, in order to simplify linking to foreign keys in other tables. Is this ever not a recommended practice?

@decomplexify

Жыл бұрын

Hi Kevin, it's fine to use sequential integers as primary keys: these would be an example of what we call "surrogate keys". Surrogate keys and other types of relational database keys are covered in my video kzread.info/dash/bejne/aquJt6-Ie6SxXcY.html

Would having a release year and month column not violate 1NF as the column isn’t atomic by containing year and month in a single column (which isn’t a valid date)?

@decomplexify

Жыл бұрын

Thanks for the question! I haven't included "everything must be atomic" as a 1NF criterion in my video. 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.

@iShaymus

Жыл бұрын

@@decomplexify very interesting reply and I do agree with your position. I have had debates with colleagues on exactly where does one draw the line on what is atomic and what isn’t. Good to know that the debate has resulted in some common sense outcomes

Nice video and real simple examples. Awesome job !!. Can you give me the name of your font please?

@decomplexify

11 ай бұрын

Thanks! The font is called Kalam.

Your tutorials have cleared a lot of my confusions. There is one more question I like to ask you for help. I have asked many database people without a satisfactory answer. Say I like to have a online coaching system to allow teachers to specify their availabilities. They can set a specific time period which is easy. But how I can allow them to specify a pattern? Say 8-9 am , every Monday for the next 6weeks. Or 3:15-4:15pm every weekday. Those patterns will be arbitrary. How can I have a database to support this feature. Your help will much appreciated

@decomplexify

11 ай бұрын

Interesting question, thanks for asking. One idea that springs to mind is something like: CREATE TABLE AVAILABILITY_SPEC ( AVAILABILITY_SPEC_ID integer NOT NULL, PERSON_ID_PERSON integer, START_TIME time NOT NULL, END_TIME time NOT NULL, RANGE_START_DATE date NOT NULL, RANGE_END_DATE date NOT NULL, REPEAT_INTERVAL_NUM integer NOT NULL, INTERVAL_UNIT_TYPE_CODE varchar(2) NOT NULL, START_DAY_NAME varchar(20) NOT NULL, INCLUDE_SUNDAY_YN varchar(1) NOT NULL, INCLUDE_MONDAY_YN varchar(1) NOT NULL, INCLUDE_TUESDAY_YN varchar(1) NOT NULL, INCLUDE_WEDNESDAY_YN varchar(1) NOT NULL, INCLUDE_THURSDAY_YN varchar(1) NOT NULL, INCLUDE_FRIDAY_YN varchar(1) NOT NULL, INCLUDE_SATURDAY_YN varchar(1) NOT NULL, CONSTRAINT AVAILABILITY_SPEC_pk PRIMARY KEY (AVAILABILITY_SPEC_ID) ); The START_TIME and END_TIME are self-explanatory. Also capture a RANGE_START_DATE and RANGE_END_DATE: this is the date range over which the pattern applies. INTERVAL_UNIT_TYPE_CODE would be something like 'D' for day, 'W' for week, 'WD' for weekday... START_DAY_NAME is the name of the day the pattern starts on: for example, 'TUESDAY'. REPEAT_INTERVAL_NUM is the number of [days / weeks / weekdays, depending on INTERVAL_UNIT_TYPE_CODE] to jump ahead, so for example a REPEAT_INTERVAL_NUM of 1 with an INTERVAL_UNIT_TYPE_CODE of 'W' means every 1 week. Finally, for the INTERVAL_UNIT_TYPE_CODE 'W' specifically, people might want to specify a certain set of days that they're available in each week - like Mondays and Thursdays. In this case INCLUDE_MONDAY_YN and INCLUDE_THURSDAY_YN would both be set to 'Y' but all the other YNs would be set to 'N'.

11:50 "Release_year is dependent on Release_year_and_month" The opposite is true, either. Not to mention, you say it so at 8:13. So we could remove the release year column and leave release_year_and_month, either.

wouldnt the year and month also break atomicity rule of 1nf?

@decomplexify

2 күн бұрын

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.

Hi, why in the second table Locker_id is cannot be primary key? It identifies every row, there are no duplicates.

@decomplexify

6 күн бұрын

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.

Hey i have a question, why is that on most_popular_movie_of_the_table there are a lot of candidate key not only the name of the movie, i thought candidate key is a superkey that has the less attribute combined. So with the definition of candidate key that i know, supposed the moview name is the only candidate key. Help me pls

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

@zappieYT

Жыл бұрын

@@decomplexify thank you

I would argue that the release_month column is not in 1NF because the value is not atomic. i.e. you have year and month in the same column which is technically two values and not one atomic value. Also, why didn't you show us how to put the storage_locaker_reservations table in BCNF?

@decomplexify

2 жыл бұрын

Hi Eric, both good questions. While it's true that Codd's definition of First Normal Form had a requirement about values needing to be atomic, database theorists who followed in his footsteps - like Chris Date and Hugh Darwen - argued that it makes no sense to incorporate "atomicity" into a definition of First Normal Form because the concept of non-atomicity is 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. For this reason, people like Chris Date no longer regard atomicity as a 1NF criterion, and neither do I. Re your second question, an example of a table that violates BCNF but meets the requirements of the lower normal forms (1NF, 2NF, 3NF) is Most_Popular_Movies_Of_The_Year, which appears at around the 7-minute mark in the video. The video explains how this table can be changed to meet the requirements of BCNF. But Storage_Locker_Reservations is a different story: it's a table that doesn't even meet 2NF. The reason for this as presented in the video is the part-key dependency of Reservation_End_Day on Reservation_End_Date. Normalizing Storage_Locker_Reservations would mean getting rid of this offending dependency. The easiest way to do this is simply to remove the Reservation_End_Day column entirely. No useful information is lost by doing this, because the day of the week can always be calculated on the fly from Reservation_End_Date.

@ericsperling9724

2 жыл бұрын

@@decomplexify - Thanks for your prompt and concise response. You're right that some values may be atomic in some circumstances and non-atomic in other circumstances and that any value could be rationalized as non-atomic. You could even make the argument that an address (street/city/state/zip) is in 2NF because a city can be in different states (e.g. Springfield) and a zip code code have multiple cities but normalizing it would be absurd. If you're up to it, I'd appreciate if you made a followup video with more examples of BCNF solutions that you've experienced in your professional career or that most readers would commonly encounter in their careers. The more examples, the better the understanding.

I am confused here, why is release_year_and_month not a super key? if a super key is a combo of candidate key and all other attribs

Hello, I am confused about one case. In your 'Most_Popular_Movies_of_the_year', why 2-{release_year,popularity_ranking} and 3-{Release_year_and_month,popularity_ranking} can also be candidate keys when we already have 1-{Movie_name} as the candidate key since the definition of candidate key is the shortest key which could uniquely identify rows in a table. Probably I have misunderstanding on candidate keys. It should be the minimal of the super keys. I think the 1-'Movie_name' is one column but the 2 or 3 have 2 columns(which is greater than 1 so it is not 'minimal'?)

@decomplexify

7 ай бұрын

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. So 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.

@albo23-mo1ej

7 ай бұрын

@@decomplexify Thank you very much! My previous understanding is more like that a candidate key is a superkey with the minimum number of attributes among all superkeys. so I mistakely thought 'Movie_name'(only 1 attribute) is less than 2 {release_year,popularity_ranking} (2 attributes) and 3-{Release_year_and_month,popularity_ranking}(2 attributes). Now I know what the problem is.🙂

bro, could you make a video on complex SQL queries ?

@decomplexify

2 жыл бұрын

I was thinking of maybe doing an SQL video at some point. When you say "complex SQL queries", do you have any particular types of queries in mind? Is it about particular SQL keywords like window-function keywords - as in things like RANK() OVER (PARTITION BY x ORDER BY y)? Or is it about building up complex logic from simpler building blocks, as with subqueries and common table expressions (CTEs)? Or something else entirely?

@parvavlogs3722

2 жыл бұрын

@@decomplexify Everything about the SQL part like subqueries, How to build the query to get the Information what we what from tables, and I hope you heard about stored procedures functions, triggers, data dictionary, optimization like explain keyword and so on so furth .... Thank you

@KeshariPiyush24

2 жыл бұрын

@@decomplexify I am also interested

@user-vh3lm3qo4t

2 жыл бұрын

Me too, in fact I would like all the knowledge please

@AmexL

2 жыл бұрын

@@decomplexify I agree, I’ll order everything on your menu.

why can't Locker_ID be a candidate key by itself, as you can get everything with just the locker_ID?? :)

@decomplexify

Жыл бұрын

The Storage_Locker_Reservations table is for keeping track of reservations of storage lockers. Someone has reserved Storage Locker 221 for the period from 14 May 2019 to 12 June 2019. But what happens when someone then reserves Storage Locker 221 for the period from 13 June 2019 to 10 July 2019? Both these reservation rows will have Locker_ID = 221. Locker_ID isn't a unique identifier for a reservation. The combination of Locker_ID and Reservation_Start_Date, however, succeeds in uniquely identifying a reservation. {221, 14-MAY-2019} designates one of the reservations; {221, 13-JUN-2019} designates the other.

Can somebody please tell me why LockerID by itself cannot be selected as the Primary Key? Isn't Locker ID unique by itself already? Why does it have to be combined with Reservation_start_date to be unique?

@decomplexify

2 жыл бұрын

If we were asking what should be the primary key of a "Storage_Locker" table (containing one row per locker), then the answer would be Locker_ID. But the table in the video isn't a "Storage_Locker" table, it's a "Storage_Locker_Reservations" table. This table must contain one row per reservation, not one row per locker. So it wouldn't make sense for the primary key of "Storage_Locker_Reservations" to be Locker_ID.

8:00

what is bcnf?

In the wise words of Jim Carrey, B-E-A-UTIFUL

05:09 why is {id, reservation_end_day} not a candidate key?

@decomplexify

Жыл бұрын

Because it's not unique. You can imagine, for example, Locker ID 652 being reserved from 2 Feb 2023 to 7 Feb 2023, and also from 18 Feb 2023 to 21 Feb 2023. Both those end dates (7 Feb 2023 and 21 Feb 2023) are Tuesdays, so if someone were to designate a reservation by {652, 'Tuesday'}, you wouldn't know which reservation they were talking about.

I don't get it with this example. It clearly fails the 3rd NF. Simply by the fact that changing the value in one column can invalidate another column. Cleary change 2009 in the 4th column will cause a mismatch if the year has changed. ie you cannot have 2009 in column 1 and 2008-12 in column 4. If you remove the year from column 4 and leave only the month it will make sense, of just remove the 1st column and the 4th column already indicates the year, so changing the year in the 4th column will not require changing anything else in that row.

@decomplexify

2 жыл бұрын

You have to look at the actual definition of 3NF. Formally, 3NF says "“Each non-prime attribute in a table should depend on every candidate key; it should never depend on part of a candidate key; and it should never depend on other non-prime attributes.” The Most_Popular_Movies_Of_The_Year table doesn't have any non-prime attributes that violate these requirements ... in fact, the Most_Popular_Movies_Of_The_Year table doesn't have any non-prime attributes at all. Therefore, even though it might seem strange, the Most_Popular_Movies_Of_The_Year table is in 3NF. Examples like this are the reason why a stronger normal form (BCNF) had to be introduced.

The BCNF version is the popular movie example is still problematic as it violates both 2NF and 3NF. Changing the release_year_and_month to just release_month doesn't help. Each movie has-a release_month. Change the movie_name, the release_month must be updated to match. So, we have a non-key attribute (release_month) that is depend on movie_name, which may or may not be part of the key, but is either not depend on the whole key or it is dependent on a non-key attribute. There are other issues with the example too, in that the same move could be listed for the same year and different rank regardless if movie_name is part/all of the key or not. (e.g. "2008, 1, Dark Knight", "2008, 2, Dark Knight", etc,) Then, while I'm not disagreeing with the formal or informal explanations, which I find quite helpful and clear, I think the example itself does not follow those definitions very well.

@decomplexify

Жыл бұрын

The version of the table that I'm saying is in BCNF most certainly doesn't violate 2NF and 3NF. The table's candidate keys are {Movie_Name} and {Release_Year, Popularity_Ranking}. Therefore Release_Month is the only non-prime attribute in the table. This non-prime attribute isn't dependent on a "part of a candidate key" (it's not dependent on Release_Year, and it's not dependent on Popularity_Ranking) - therefore the table doesn't violate 2NF. In addition, this non-prime attribute isn't dependent on another non-prime attribute, as there isn't any other non-prime attribute: Release_Month is the only non-prime attribute. Therefore the table doesn't violate 3NF. Secondly, the combination of rows you're saying could exist - [ "2008, 1, Dark Knight" ], [ "2008, 2, Dark Knight" ] - cannot exist, as {Movie_Name} is a candidate key.

@Personal-M.I.S.

Жыл бұрын

@@decomplexify You have a good point. I didn't consider movie_name by itself as THE only key attribute. If you do that, then the issues I raised are non-issues. But consider, if you did use movie name alone, then you certainly can have several "different" movie_names with the "same" rank and "same" release_year. That doesn't seem to be an improvement for the purpose of ranking movies by release year. You will have constraint violations or just the potential for garbage data. Not an issue of normal forms in this case, I'll concede that. But certainly there are some issues of practicality and purpose. Anyway, I do find your videos helpful and I'm sure coming up with simple examples isn't the easiest thing. Thanks for the hard work =)

@decomplexify

Жыл бұрын

@@Personal-M.I.S. Glad that you're finding the videos helpful! I can see that you're engaging with them at a very detailed level, which is great to see. Regarding the BCNF table and its two candidate keys - #1 {Movie_Name} and #2 {Release_Year, Popularity_Ranking} - it seems like you're worried about what will happen in a real database if you designate one of these candidate keys as the primary key while leaving the other candidate key unenforced. However, there is no need to worry about this. You can enforce them both! If for example you designate {Movie_Name} as the primary key, you can enforce the uniqueness of the other candidate key as well by doing: ALTER TABLE Most_Popular_Movies_Of_The_Year ADD UNIQUE (Release_Year, Popularity_Ranking).

@Personal-M.I.S.

Жыл бұрын

@@decomplexify Absolutely! And I think that was fouling me up from focusing on what you're trying to say with the example. I guess I had my engineer hat on instead of my student hat, have to work on that =)

i dont get why it doesnt depend on the whole key (3:48)

@decomplexify

Жыл бұрын

The Reservation End Day (e.g. "Wednesday") is determined by the Reservation End Date (e.g. 12 June 2019). You don't need to (additionally) know the Locker ID in order to know the Reservation End Day.

The "Most popular movies of the year" table can not be in FN3. Becuase it is not even in FN1. The attribute "release_year_and_month" has non atomic values.

@decomplexify

Жыл бұрын

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.

Kung fu panda should have been ranked 1 imo 😔😔

'Release_year_and_month' never passed 1NF to begin with.

@decomplexify

2 жыл бұрын

You're referring to the "atomic values" criterion in Codd's definition of First Normal Form. See my earlier response to a comment by Eric Sperling on this. Database theorists who followed in Codd's footsteps came around to the view that requiring values to be "atomic" isn't appropriate because "atomicity" has no absolute meaning (all strings are non-atomic if you consider that they're decomposable into individual characters, for example). For this reason, theorists like Chris Date and Hugh Darwen no longer regard atomicity as a 1NF criterion, and neither do I.

1337

there's no such thing as a table in the relational model fyi

it took you 10 minutes to get to BCNF...WTF

I'm sorry for bringing this up, but why does the informal guy have darker skin color and the formal one lighter? Couldn't this be seen as stereotypes?

Merci !