Hi Charli
This is a great place to come for "guidance, advice, and a few tips."
If you really want to do this project yourself and learn from the
experience, you are best to post questions here (or perhaps in one of the
other newsgroups such as tablesdbdesign or formscoding) as they arise. That
way, there will always be a willing expert on hand to help and others might
benefit from the exchange.
To get started, you must first design your "data model". IMO, this is the
most important step in building any database application. If you start with
a good model, everything will fall into place, but a bad one will result in
eternal wailing and gnashing of teeth
You need to define the "entities" or "things" that you want your database to
represent. Each entity will be a table in your database. In your case,
these might include:
Guests (the people who come to stay)
Locations (the different camp grounds)
Units (the different rentable entities - cabins and camp sites)
Facilities (cookers, TV, etc)
Bookings (which guests are booked into which units for which nights)
Now, for each entity, you need to decide what "attributes" you need to
store - for example, Guests would include names and contact details, perhaps
also other details such as passport number or gender. These are the fields
in your table. Each entity should also have a "primary key" which is a
unique way of identifying a record in your table. Often there is no easy
"natural" way to specify uniqueness, without joining together a lot of
different fields, so in Access tables it is common to use an "AutoNumber"
field as the primary key.
Now you need to decide how your entities are related to one another. For
example, each location may comprise several units (a "one-to-many"
relationship) so your Units table will include a field for the primary key
value of the Locations table (LocationID). This field is called a "foreign
key". Relations are nearly always between primary keys and foreign keys.
Your Bookings table will have foreign keys for relations to both Guests and
Units.
The relationship between Units and Facilities is "many-to-many", because one
unit can have several facilities and one facility can be offered by several
units. To model a many-to-many relationship, you need a third table called
a "junction table". This table (let's call it "UnitFacilities") has two
foreign keys, one for a UnitID and one for a FacilityID.
Some of your tables will be "reference tables". These are simple tables
whose contents are fairly static, and their purpose is to list possible
options for the values in a foreign key field. Often they will have only
two fields - a "code" or ID number, and a name or description. Your
Facilities table is a reference table. Other possible reference tables are
UnitType (cabin or camp site) and BookingStatus (tentative, confirmed,
cancelled, taken, paid).
This will probably give you enough to chew on for the moment. Don't
hesitate to come back soon!