Why is my SQL table not in 3 normal form

Question

I have made this database. It looks like it is working fine, except that I was told that my table "event" is not in third normal form. I do not see why it is not in the third normal form. I thought it is maybe because of the city and the zip code, which should be always the same, but large cities can have multiple zip codes and I do not see the point in creating another table just for the cities and their zip codes, related to the event table.

Also sorry if some of the names or attributes are named incorrectly by using some of the names reserved by the system. I had to translate the code to english, because I wrote it in my home language :). Thanks for your help.

Create table [article]
(
    [id_article] Integer Identity(1,1) NOT NULL,
    [id_author] Integer NOT NULL,
    [id_category] Integer NOT NULL,
    [title] Nvarchar(50) NOT NULL,
    [content] Text NOT NULL,
    [date] Datetime NOT NULL,
Primary Key ([id_article])
) 
go

Create table [author]
(
    [id_author] Integer Identity(1,1) NOT NULL,
    [name] Nvarchar(25) NOT NULL,
    [lastname] Nvarchar(25) NOT NULL,
    [email] Nvarchar(50) NOT NULL, UNIQUE ([email]),
    [phone] Integer NOT NULL, UNIQUE ([phone]),
    [nick] Nvarchar(20) NOT NULL, UNIQUE ([nick]),
    [passwd] Nvarchar(50) NOT NULL,
    [acc_number] Integer NOT NULL, UNIQUE ([acc_number]),
Primary Key ([id_author])
) 
go

Create table [event]
(
    [id_event] Integer Identity(1,1) NOT NULL,
    [id_author] Integer NOT NULL,
    [name] Nvarchar(50) NOT NULL,
    [date] Datetime NOT NULL, UNIQUE ([date]),
    [city] Nvarchar(50) NOT NULL,
    [street] Nvarchar(50) NOT NULL,
    [zip] Integer NOT NULL,
    [house_number] Integer NOT NULL,
    [number_registered] Integer Default 0 NOT NULL Constraint [number_registered] Check (number_registered <= 20),
Primary Key ([id_event])
) 
go

Create table [user]
(
    [id_user] Integer Identity(1,1) NOT NULL,
    [name] Nvarchar(15) NOT NULL,
    [lastname] Nvarchar(25) NOT NULL,
    [email] Nvarchar(50) NOT NULL, UNIQUE ([email]),
    [phone] Integer NOT NULL, UNIQUE ([phone]),
    [passwd] Nvarchar(50) NOT NULL,
    [nick] Nvarchar(20) NOT NULL, UNIQUE ([nick]),
Primary Key ([id_user])
) 
go

Create table [commentary]
(
    [id_commentary] Integer Identity(1,1) NOT NULL,
    [content] Text NOT NULL,
    [id_article] Integer NOT NULL,
    [id_author] Integer NULL,
    [id_user] Integer NULL,
Primary Key ([id_commentary])
) 
go

Create table [category]
(
    [id_category] Integer Identity(1,1) NOT NULL,
    [name] Nvarchar(30) NOT NULL,
Primary Key ([id_category])
) 
go

Create table [registration]
(
    [id_user] Integer NOT NULL,
    [id_event] Integer NOT NULL,
Primary Key ([id_user],[id_event])
) 
go


Alter table [commentary] add  foreign key([id_article]) references [article] ([id_article])  on update no action on delete no action 
go
Alter table [article] add  foreign key([id_author]) references [author] ([id_author])  on update no action on delete no action 
go
Alter table [event] add  foreign key([id_author]) references [author] ([id_author])  on update no action on delete no action 
go
Alter table [commentary] add  foreign key([id_author]) references [author] ([id_author])  on update no action on delete no action 
go
Alter table [registration] add  foreign key([id_event]) references [event] ([id_event])  on update no action on delete no action 
go
Alter table [commentary] add  foreign key([id_user]) references [user] ([id_user])  on update no action on delete no action 
go
Alter table [registration] add  foreign key([id_user]) references [user] ([id_user])  on update no action on delete no action 
go
Alter table [article] add  foreign key([id_category]) references [category] ([id_category])  on update no action on delete no action 
go

EDIT: Do you think it could work like this? I made another table called location with all the address infos which were previously in event table and made the id_event PFK.

Create table [event]
(
    [id_event] Integer Identity(1,1) NOT NULL,
    [id_author] Integer NOT NULL,
    [name] Nvarchar(50) NOT NULL,
    [datr] Datetime NOT NULL,
    [number_registered] Integer Default 0 NOT NULL Constraint [number_registered] Check (number_registered <= 20),
Primary Key ([id_event])
) 
go


Create table [location]
(
    [city] Char(1) NOT NULL,
    [id_event] Integer NOT NULL,
    [street] Char(1) NOT NULL,
    [house_number] Char(1) NOT NULL,
    [zip] Char(1) NOT NULL,
Primary Key ([id_event])
) 
go


Alter table [event] add  foreign key([id_auhtor]) references [author] ([id_author])  on update no action on delete no action 
go

Alter table [location] add  foreign key([id_event]) references [event] ([id_event])  on update no action on delete no action 
go

Answer 1

To answer the question.

You are correct, the database is not in 3rd normal form. As you've identified there is an opportunity to normalise out the various postcodes, cities and streets. This would result in a row for each postcode (etc.) and you would have FKs for each.

Personally, I don't do this. It obviously depends on the application but in my systems I'm more interested in getting the address of the user rather than all the users who have a particular postcode.

Depending on how you intend to use your data 3rd normal may not be the most efficient way to store your data.

Answer 2

Based on your edit - close, but I'd turn it around. I'd give location a location_id column (PK), remove its event_id column, and then make event be:

Create table [event]
(
    [id_event] Integer Identity(1,1) NOT NULL,
    [id_author] Integer NOT NULL,
    id_location Integer NOT NULL, /* Or null? does every event have to have a location */
    [name] Nvarchar(50) NOT NULL,
    [datr] Datetime NOT NULL,
    [number_registered] Integer Default 0 NOT NULL Constraint [number_registered] Check (number_registered <= 20),
Primary Key ([id_event])
) 

And then reverse the foreign key as well.

That way if an address requires correction it only needs to be corrected in one row - which is after all the point of normalization - making corrections only have to be applied once.