1. If you are a hard-line relational theorist, you may feel that none of the mainstream database engines is strictly relational. In which case, Access is not relational.
2. If you are consider the likes of Oracle, SQL Server, DB2 etc. to be relational then you are accepting a more ‘real world’ definition of relational and you now have to decide whether Access falls within that set.
3. If you decide it doesn’t, then you have to be able to show that Access supports significantly less of the model.

One trap worth avoiding is the use of arguments such as “Access isn’t relational because:

• “it doesn’t support transactions;
• “it can’t handle enough data;
• “it isn’t robust enough;
• “it is too slow;
• “when it crashes the data can become corrupt because it doesn’t log the transactions;
• “it comes from Microsoft and those guys don’t know anything about robust systems;
• “it can’t handle more than about five concurrent users without running like a dog.”

The problem here is that these characteristics have nothing whatsoever to do with the relational model. It is perfectly true that stability, speed, high concurrency and the ability to handle large data sets are all eminently desirable features of a relational database system. But to associate them with the underlying data model is to misunderstand, at a very fundamental level, what the relational model is about.

According to Date, “the relational model is concerned with three aspects of data: data structure, data integrity and data manipulation.” - An Introduction to Database Systems, Addison-Wesley. The model says nothing about performance, data volume, numbers of concurrent users etc.

Indeed, to use these arguments to support the view that Access is not relational is like saying "Penguins aren’t birds because they can’t fly.” Whilst it is true that many birds can fly, aerial navigation is not part of the formal spec. for Class Aves.