For Access, you can have several kinds of constraints.
1. In Table Design view, if you select a field, then at the bottom of the table design panel is a list of properties including a field constraint such as ">0" or some other simple math. Math in this level of constraint ONLY applies to the one field that is selected. You cannot have a cross-field constraint easily in that property. (Not impossible, just not easy.) There is also the "Required" constraint (can't be left blank) and the "Indexed" constraint that can include "Unique."
2. In Table Design view, you can see indexes. It is possible to have index constraints such as "Unique" and you can have compound constraints that require a combination of fields in the table to be unique even though individually the fields are not unique. This most often occurs when you have compound keys.
3. In the Relationships window you can have cross-table constraints via Relational Integrity such that a value has to exist in Table X before you can store a dependent entry in table Y; essentially, parent/child requirements where a parent must exist in order to have a child. (Kind of like in real life...)
4. In Table Design view you can define table-level data macros that are used to enforce a constraint. They look like macros but are not managed from the Macro collection. Since RunCode is a possible Macro action, you might be able to put complex VBA constraints there. Look up Data Macro to see more. They can be event based or not, depending on how they are set up.
5. The trickiest constraints come from data entry forms where VBA code in the form's Class Module accepts or rejects a given entry attempt.
Of these, the hardest to find is the VBA code in a class module because it is not easily seen from Table Design view. It only applies if your database is secured in a way that does not allow end users to see tables directly but rather they can only access the tables through appropriate (non-datasheet) forms.