We can certainly help you, but the intent of EE is for you to learn, while we assist in that learning. If you have no basis in the understanding of relational databases, it will be nearly impossible for you to understand how to properly structure your database. While many at EE tend to treat it like a cheap version of "rent-a-coder" (both members and Experts) that is most definitely not what it's all about. We'll certainly help you to learn, but most here won't just do it for you.
As an example, in your Programme table, you have a "Channel" field. In the supplied database, each row in the table contains the value "THC". This violates "normalization" rules, since it duplicates identical values for each row, and the "Channel" is not really a "property" of a Programme. The proper way to do this would be to build a second table (perhaps named tblChannels), and then add the value "THC" to that table. Then, you'd store the ID value from tblChannels in the Programme table, and NOT the acutal text value "THC". This "related" the value in tblChannels with the specific record in the Programme table, and starts you on your way to a properly normalized database.
The same would hold true for the Series Title, AstroID, ClientID, etc etc.
The intent of building a relational database is for you to store data in such a way that each table contains only that data which is specifically relevant to THAT unique record. I assume that your "Programme" table contains details of a specific broadcast programm. If so, then while the Channel and SeriesTitle are somewhat relevant, they are not "properties" of that program. Properties of that program would be BroadcastDate, Duration, etc etc - in other words, data that is specifically related to that specific program. The Channel is itself a unique bit of data, as is the Series and Client. Those would be stored in different tables.
There are very specific reasons for "normalizing" your data, not the least of which is Access is designed around the concept of normalized data. Working with de-normalized (or "flat") data in Access can be very, very difficult, which is why we encourage novice designers to adopt the concepts of normalization.
