Fnl/UDT doesn't work that way, it does not call any other SQL or Stored Procedures. As a good DNN citizen, it uses the DotNetNuke API.
One example: If you link to a local file using the datatype URL or Download, FNL/UDT stores "FiledID={Internal ID of the file}", and it retrieves that same value out of the database. In a later step the FileID gets resolved using the API and retrieves a DotNetNuke FileInfo object. The lookup datatype allows to query this FileInfo object and return properties like FileName, Extension, FileSize or the number how often the file was clicked.
Whether these information is retrieved from additional database calls or not, FnL/UDT doesn't care about that. It trusts that API that it does something senseful. In fact, these values are often (if not to say most time) cached internally, they don't cause additional calls to database.
We could have written the module in a different way and retrieve this kind of data directly from the database, maybe directly during the SP call which retrieves the UDT data. This would be a bad design, as we would rely on a structure which is not under our control. We would fear that each update of the underlaying framework can possible harm the module. Instead we trust in the public API.
Don't think SQL, think OO and use the rich function set of the platform.