Table creation - move common fields to separate table - sql-server

Question

I have a scenario that, there are three types of functionalities has same set of fields (except their primary key).
The below is the sample. I would like know, whether it is a better idea to group the common fields in a single table? If we create a common table, how can we give the FK reference to the corresponding primary key table? What would be the better approach?
tblCountry
tblState
tblCity
countryid
StateId
CityId
Name
CountryId
StateId
officiallanguage
officiallanguage
officiallanguage
officialFlag
officialFlag
officialFlag
officialFlower
officialFlower
officialFlower
officialAnimal
officialAnimal
officialAnimal
officialBird
officialBird
officialBird
...
...
...
...
...
...
...
...
...
etc
etc
etc

Answer 1

Your intended third normal form (3NF) is good as it is.
From a simplicity point of view (affecting joins) it is as good as it can be. And foreign keys between country, state and city are obivous and trivial.
Now to save you from copying some column names you could put all three elements country, state and city into a single table - effectively making it second normal form. With this the meaning of your column names start to roleplay. With this I mean the officialLanguage can either be country, state or city related. From the stored table design this is no longer obvious. Only by interpretation of the multi column key.
So in short by saving on some typing / copying you will complicate any further work using a single table with convoluted meaning instead of using three tables with clear meanings.
Now towards data selection this is an issue only if there are no aliases.
Consider selecting officialLanguage of a city in a country.
SELECT
name,
officialLanguage,
name,
officialLanguage
FROM city
INNER JOIN state
ON state.stateid = city.stateid
INNER JOIN country
ON country.countryid = state.countryid
;
This will fail as the columns chosen are ambigiuous.
Now consider this query (where the aliases are shorted just to demonstrate the aliases - personally I try to use up-to-10-letters aliases):
SELECT
cit.name AS city_name,
cit.officialLanguage AS city_language,
cou.name AS country_name,
cou.officialLanguage aS country_language
FROM city AS cit
INNER JOIN state AS sta
ON sta.stateid = cit.stateid
INNER JOIN country AS cou
ON cou.countryid = sta.countryid
;
It is very clear and concise. I can use country table in different queries without having to pre-select those countries from a table with intermingled objects like country, state and city.
The only downside to this approach is the multi join of properly indexed tables.
Also as there are quite a few countries, states and cities across the world this single table approach can be a performance issue down the line.
4NF (or at least BCNF or 3.5NF as it is otherwise known) is best for fast performance in joins with the trade off that joins can become complex (to write) when properly indexed. However for database engines these are easiest to read.
2NF (or Excel tables as I call those) are easiest to read for humans. Which require complicated join and/or conditions (WHERE clause) to properly identify just a subset.
For the database design best use at minimum 3NF or better, then prepare views to turn the data back to 2NF to make your data human-readable.

Answer 2

You're asking for advice around when you should consider further normalisation on a schema.
This answer from #KnutBoehnert is quite detailed, my answer is really a supplement to that.
The goal of normalizing the database structure is NOT to reduce the duplication names of fields to a single reference, but to reduce the duplication of the data that is stored within those fields. To provide a definitive answer for a given schema would normally require you to provide a set of records, however your dataset is simple enough to correlate to real world norms that we can talk about some hypotheticals.
This is different to inheritance or composition in OO programming, where I would strongly encourage you to encapsulate these fields either as properties on a common base class between the objects that represent records from these tables, or as an interface that they all compose into their structure.
Only when Country/State/City commonly have the same values for the duplicated field names is there is a strong argument to refactor this structure to introduce a separate table to hold the values of Language,Flag,Flower,Animal,Bird.
If you did create a separate table for this information, how often would the records in it be re-used? For instance, how many different countries are going to reference the same record? most likely none as the flag is usually unique for each country, but certainly the combination of all those fields will be uinique per country. For state the same statement is usually true. If there is no re-use of the records in this new table, if the relationship is always 1:1 then the database and the queries are optimised by leaving them within the table the way you have it now.
1:1 relationships do have a place, especially if for a given cenceptual record there are distinct use cases where one set of fields is updated or queried in isolation from another set and that these two sets have very different query rates, however on its own without any further supportive reasons, 1:1 relationships in a schema can be simplified by merging the two tables in the one record.
If for instance all states within a country, and all cities within a state are expeceted to have the same Language, then you would not need the field at the lower levels at all and you could use joins to access the Language field from the Country record. But in the physical world there are many countries that have states that have different local languages or dialects to that of the country as a whole, so I don't think this applies to this particular schema.
In fact I see no reason for your current schema to change, the structure as it is now even allows you use null values to indicate that the value should be coalesced from the parent level.
In Australia for instance, all of the records for State and City are more than likely to have a Language value of English, we can use null coalescing statements to prevent the need to enter and maintain this value in each State and City record, so in Australia, of all states and cities left a value of null in the officialLanguage field, we could still coalesce it from the parent related country:
SELECT
country.Name AS country_name,
country.officialLanguage AS country_language
state.name AS state_name,
IsNull(state.officialLanguage,country.officialLanguage) AS state_language
city.name AS city_name,
COALESCE(city.officialLanguage, state.officialLanguage, country.officialLanguage) AS city_language,
FROM tblCity AS city
INNER JOIN tblState AS state
ON state.Stateid = city.Stateid
INNER JOIN tblCountry AS country
ON country.Countryid = state.Countryid
To query the records for just the city table in this way could look like this:
I'm not sure it makes sense to coalesce the other fields, but it could be done
SELECT
CityId,
city.StateId,
state.CountryId,
...
COALESCE(city.officialLanguage, state.officialLanguage, country.officialLanguage) AS officialLanguage,
COALESCE(city.officialFlag, state.officialFlag, country.officialFlag) AS officialFlag,
COALESCE(city.officialFlower, state.officialFlower, country.officialFlower) AS officialFlower,
COALESCE(city.officialAnimal, state.officialAnimal, country.officialAnimal) AS officialAnimal,
COALESCE(city.officialBird, state.officialBird, country.officialBird) AS officialBird,
FROM tblCity AS city
INNER JOIN tblState AS state
ON state.Stateid = city.Stateid
INNER JOIN tblCountry AS country
ON country.Countryid = state.Countryid
In many real world applications of this null coalescing concept the application layer would handle the display of these fields differently, but the storage is what we are most concerned about for this question today.