The meaning of the itemid is entirely dependent on how you want to use it within your code (and you should never be using DB queries to access the 'files' table - the Files API covers everything you should be doing with files).
Why do you need the itemid? What does it represent in your code? How are you going to distinguish between the different file areas within your code - that is what you should be using for the itemid (and if there aren't different file areas within your code, then you shouldn't be using the itemid).
Some more examples, to help:
each assignment has multiple students submitting, to the itemid is (likely to be, I haven't checked) the submission id for each student's submission - this is needed as you don't want all students to be submitting to one big file area
each 'page' resource only has a single file area, as there is only one page per activity instance, so the itemid is not needed
each core activity has a 'intro' field which has a file area (to hold any embedded images, etc.), this doesn't have an itemid as there is only one intro for each instance of each activity.
So, back to my earlier question - what do the different file areas in your block actually *mean*? I see that the 'component' is 'block_groupreg' and the filearea is 'excel' and you have a context for your block. That is enough information to hold multiple (differently-named) files with a single file area for each instance of your block. If you are going to need multiple file areas for each instance of the block, then the meaning of these different file areas will give you the value for the itemid.