When normalising, if you have entities with the same primary key, does it mean it should be the same entity? Crrently I have this check in data where each check in has check-in details, activities and total extra items charge(extra items are required for some activities).

In UNF, I separated them into 3 repeating groups:

CHECKIN( (customer_id, customer_name, check_in_d&amp;t, main_tour_guide),  

(activity_code, activity_name, prescribing_tour_guide, completing_tour_guide, activity_d&amp;t,activity_cost), 

(item_code, description, quantity, total_item_charge, quantity, total_extra_item_charges))

If I group total_extra_item_charges under item, I will get 3NF:

TOTALITEMCHARGES( customer_id, activity_d&amp;t, total_extra_item_charges)

ACTIVITYSCHEDULE( customer_id, activity_d&amp;t , activity_code, prescribing_tour_guide, completing_tour_guide)

Both of these share the same primary key, so should I group total_extra_item_charges under activity schedule instead since 1 activity only has 1 total extra charge?But something seems off?

*d&amp;t means date and time
Place total_extra_item_charges into the same table as the activities. You are unnecessarily duplicating customer_id and activity_d&amp;t for a single column that you indicate will not have more than one row. Try to avoid over-normalizing. 

I would also recommend a primary key on a unique identity column (e.g. activity_schedule_id). Based on your bolding of customer_id and activity_d&amp;t, it appears you're using a composite primary key. A datetime column is not typically suitable as a primary key and is going to add significant physical overhead. I would instead add a nonclustered index and foreign key on customer_id with an include on activity_d&amp;t.

Depending on the transactional volume of this database, you may also want to split the date and time portions of activity_d&amp;t for quicker join lookups. E.g. activity_date and activity_time. Be mindful of the precision level you use for your time - do you need seconds and milliseconds? If you just need to be precise to the minute, be sure you aren't storing this data as you can save a significant amount of space.