Non core database tables are a must if your data is more complex than WordPress post model, it is going to be huge, and it has a lot of meta details which will be searched.
EAV format WordPress uses for its post meta does not lend itself well to multi-criterion search.
If you divide your meta into many entries, you will have numerous entries per post in the post meta table, and searching any post through metas will be much slower.
If you store all metas serialized in an array and have it as only one entry in post meta, this time you will be forced to do only text searches inside that meta, and you wont be able to use comparison operators directly in your sql query.
Not a big problem if your plugin is not going to have thousands of entries and associated meta.
But a major problem if your plugin is going to do anything large.
Your situation, a file name as independent entry and 3 meta data entries attached to that entry does not seem so big. You may use wordpress post table and meta table for it.
BUT, if people are going to search for these 3 metas a lot, ESPECIALLY in conjunction, then i'd recommend that you set up separate tables.
With that format just one table with just one entry, which also contains all the metas would be ok, and would query lightning fast.
Incidentally, if you use WordPress tables and also you are using query caching, the user searches for your data would get cached over time and incur less load. But that wouldnt be so prudent as doing separate tables.