You could set up an actual database for this, but the use case is so simple that it's probably easier to just have a single file, that'd look something like this:
tag1, tag2, tag3, tag4, ...
path/to/file1: tag1, tag2, ...
path/to/file2: tag3, tag4, ...
Your program would load the file, read the first line to get the list of valid tags, then read the following lines to learn which files have which associated tags. In the program you'd build a map of tags to lists of files that have those tags. The user selects the tags they want to filter by, you extract the lists, and then you go through and find all files that are in all of the lists; that's your result.
Alternately, if your language supports a Set datatype, then the tags should map to sets of files instead of lists, and you just intersect all the sets to get the set of files that have all tags.
This is a very simple and limited approach to the problem. If you want to do something more complicated with a GUI and all that, then you certainly can. I'm just trying to point out that the underlying functionality is not that complicated and certainly doesn't require a full-blown database.
