Having had a look at your rethink with just three tables (www.graphicsdesigned.co.uk/MuseumSchema4.gif) it still needs more tweaking. What if a museum is linked to more than one category? The way you have it set up at the moment you'll be adding another row to the museums table for each category that the museum is in. What you need is a "link table" which just contains three fields: MuseumCategoryLinkID (primary key), MuseumDetails_ID and Categories_ID. With this new table you can take the categories_id_fk field out of the museumdetails table.
Link tables are good for "many to many" relationships like this (each museum could be in many categories, each category could match many museums).
You might also need a separate calendar table because the way you have it at the moment you're assuming that every Monday is the same opening times, every Tuesday is the same etc. Large museums are probably open every day except Christmas, so you might be able to get away with this, but small museums might close on bank holidays (not a very good business practice but your database still needs to be able to deal with it).
With the location table, are you going to list the bus numbers as a comma separated list in one field (i.e. "23,49,146") or were you thinking of listing them individually? If you wanted to list them individually then you'd have to split the route numbers into a table of their own and then have another link table joining the location with the routes (bearing in mind that one museum is on several routes and one bus can pass several museums).
Although the location table does list location-related information, some of it could be moved back into the museums table because each museum only has one location (i.e. you're not going to get three museums at the same latitude/longitude, but you might get three all at the same tube stop). Some people will say that lat/long is a property of the location rather than of the museum but it's borderline, there's no right/wrong answer with something like that.
If this is just an academic exercise to teach yourself database design, have a think about how you might extend the design to store more information such as a count of visitors per day, or a list of exhibits with start/end dates and so on.
By the way, your initial design is actually very close to what a data warehouse design would be, with the main table (known as a fact table in data warehouse jargon) just containing a list of foreign keys to supporting tables (knows as dimension tables).