Well, Access is not a particularly great skill to have, but SQL is. Access, as an RDBMS, blows goats. Learning basic SQL will allow you to effectively use most any relational database product. The key of relational database design is primary and foreign keys. To design complicated databases, you also need to learn about normal forms and atomization and functional dependencies..
Here’s an EXTREMELY brief rundown, which I am offering as a reference for this and future threads since we’ve been getting a lot of this type of question recently.
SQL: SQL (which is NOT pronounced “sequel”) is the Standard Query Language. It is an ANSI standard for sending queries to database servers. Every database product supports SQL, in addition to other nonstandard SQL extensions. Microsoft products also support their proprietary query language, ODBC.
Primary and foreign keys. A primary key is a data field whose value is guaranteed to be unique for every record. In an employee database, you might make this, say the last name of the employee. But, there might come a time when two employees have the same last name. Better to just create an employee ID number for each person. A foreign key is a data field whose value refers to the primary key of another table. For instance, suppose we have two tables, an employee list, and a list of departments and information about each department. Each employee has an ID, and each department has an ID. You might relate the employee table to the department table by putting the department ID of an employee’s department in the employee database. For example:
Employee DB:
ID Last First Office Favorite Color Dept
1 Jones Bob 23-D Blue 6
Looking at this entry, we see that Mr. Jones belongs to department six. We can then look at the department table to get all the information about department six.
There are ways to do more complicated relationships, such as one-to-many relationships, but I won’t go into those here, unless you want me to.
Normal forms: The normal forms are standards for dealing with the functional dependencies in your data. I’m not going to go into the details here unless you want me to.
Atomization: This is the process of defining the discrete points in your data set. Having one field for the model and color of a car would lead to redundancy, since one model of car can come in several colors.
Functional Dependencies: These are the dependencies you have to figure out in order to design your database correctly. For example, in our employee database, the department ID is functionally dependent on the employee ID, because there must be one department for every employee. The inverse is not true, because several employees can belong to one department.
This stuff, if your name happens to be friedo, is extremely fascinating. Yep, I figure out functional dependencies between six progressively related tables for fun on Sunday mornings. 
For a fantastic introduction to relational database theory (and vastly more detail on the things I’ve mentioned above) read the first five chapters of this book.