Normalization of a table (BCNF)

Question

I'm trying to understand how to normalize a database, and one of the exercise given by our teacher was to normalize in BCNF this table:

Flight(**CityDeparture,CityArrival,Day**,NationDeparture,NationArrival)

where (CityDeparture,CityArrival,Day) is the primary key. So I assumed that:

1)The city name is unique independently from the nation (there can not be two nation with the same city, even if that is not true in reality), otherwise the primary key would be wrong.

2)The functional depencies are CityDeparture->NationDeparture CityArrival->NationArrival Meaning the table was not even in 2NF, so I decomposed it like so: Flight(CityDeparture,CityArrival,Day) there are no non-banal FD so it is in BNCF, right?

CityD(**CityDeparture**,NationDeparture) CityDeparture->NationDeparture

is in BNCF because CityDeparture is key

CityA(**CityArrival**,NationArrival) CityArrival->NationArrival

is in BNCF because CityArrival is key.

I also considered the fact that CityA and CityD could be identical unless every city has a different code of departure/arrival(i.e. NewYork has code 'AAA' if a flight leaves from there and code 'BBB' if a flight lands there) so one could just have a single City(Name,Nation) table and both CityDeparture,CityArrival would reference it.

The decomposition should also be lossless because City.Name is a common attribute for both tables and is key for City (I'm quite unsure about this)

When I showed this to my teacher it just scored 0 and told me to go read the book without further explanation. Now I did read the book, and the articles I found linked around here but I'm honestly clueless, so I'm asking for your advice! Any help would be appreciated

Answer 1

Your decomposition of

Flight(CityDeparture,CityArrival,Day,NationDeparture,NationArrival)

into

Flight(CityDeparture,CityArrival,Day) 
CityD(CityDeparture,NationDeparture)
CityA(CityArrival,NationArrival)

gives you indeed BCNF.

Regarding the last step, the unification of CityD and CityA: This is not justified by your functional dependencies, and thus incorrect from a formal database perspective. It would be justified by further context knowledge. In practice, it would of course make sense in most settings.

Keep in mind that database normalization is a formal discipline, and so are its algorithms. Substitute artificial names for your relation, e.g., R(A,B,C,D,E) with the same keys and functional dependencies - the result must be same up to renaming.

EDIT This assumes that the primary key and the two functional dependencies CityDeparture->NationDeparture and CityArrival->NationArrival were given as part of the exercise - otherwise see Mike's answer.

Answer 2

1)The city name is unique independently from the nation (there can not be two nation with the same city, even if that is not true in reality), otherwise the primary key would be wrong.

On the one hand, your reasoning here is correct. On the other hand, many (most?) textbook normalization exercises don't include keys at all. You're usually expected to derive all possible keys from the dependencies. Maybe your teacher expects you to ignore the existing key.

Another possibility is that your teacher wanted you to include the FD {CityDeparture, CityArrival, Day} -> {NationDeparture, NationArrival}.

Another possibility is that your teacher wanted you to explore the dependencies within the primary key. Are there any multi-value dependencies?

If your book includes an algorithm that you can do with pencil and paper--most of them do--try working through it that way. See what you get.