0

I have the following database table :

BookingReferenceNumber

TotalNights

BillingAddress

FinalAmount

CellPhone

State

Country

ZipCode

CheckInDate,

CheckOutDate

NumberOfGuests

[ForeignKey("Camp")] CampId { get; set; }

[ForeignKey("Account")] UserId

where UserId and campId are foreign key in this table. Is this table in 3NF or not?

philipxy
  • 14,867
  • 6
  • 39
  • 83
Shivam Gupta
  • 11
  • 1
  • Is there any repeating groups? If not then the table is in first normal form. Does the table have a composite primary key? If not, then the table is automatically in second normal form. Does each column depend on the primary key and only the primary key? Then the table is in third normal form. – Honeyboy Wilson Apr 25 '20 at 15:17
  • Right now you are just asking for us to rewrite your textbook with a bespoke tutorial & do your (home)work & you have shown no research or other effort. Please see [ask], hits googling 'stackexchange homework' & the voting arrow mouseover texts. Show the steps of your work following your textbook with justification & ask 1 specific researched non-duplicate question re the first place you are stuck. PS Please before you post look at the formatted version of your post below the edit box. Read the edit help re inline & block formats for code & quotations. Also re line breaks. – philipxy Apr 25 '20 at 21:17
  • @HoneyboyWilson "No composite key implies 2NF" is a [common](https://stackoverflow.com/a/16617091/3404097) [misconception](https://stackoverflow.com/a/25827210/3404097). Also aphorisms like "each column depends on the primary key and only the primary key" are not clear & if made clear are wrong. They are no more than mnemonics for a clear correct statement so are not helpful for informing, only reminding, and are poor at that. Also PKs per se do not matter, CKs do. Also ["1NF" has no single meaning](https://stackoverflow.com/a/40640962/3404097). – philipxy Apr 25 '20 at 21:40
  • @philipxy A table in first normal form that has a single-column primary key is automatically in second normal form. If the table has a composite primary key you have to continue to examine it to determine if it is in second normal form. I find the rest of your comment pretty unintelligible. – Honeyboy Wilson Apr 26 '20 at 20:37
  • @HoneyboyWilson The 1st link I gave already contradicts your 1st sentence. To repeat: FD {}->{Pi} holds in it, and {} is a proper subset of a CK determining a non-prime attribute, so it is not in 2NF, **you need only apply (correct) definitions and/or algorithms for FD, CK & a NF>1 to see that it is not in that NF**, & clearly it can & should be losslessly decomposed into (Diameter, Circumference) join (Pi) for 5NF. (Some poor textbooks even get this wrong.) The 2nd link gives another example. My comment is clear. You could ask about any part that is not clear to you. – philipxy Apr 27 '20 at 04:35
  • 1
    Normalization requires a good understanding of the data, which isn't really provided here. We could probably take some guesses at what determines what based on the attribute names, but we would almost certainly make a mistake, leading to us giving you a wrong answer. – mypetlion Apr 29 '20 at 01:01
  • Normalization isn't hard, some people want to make it hard. It's not an academic exercise. It's a straightforward way to be sure you have a usable database design that meets the everyday needs of business and industry. – Honeyboy Wilson Apr 30 '20 at 21:16

0 Answers0