I think the top answer for the term "relation" is great, especially when talking about databases in theory. But I think isn't as fitting when talking about an actual database system implementation, in practice. The reasoning being is there's a lot of constructs that exist in an actual database system implementation and which vary across implementations that aren't discussed or covered in database theory. Examples of this may include Stored Procedures, Table Variables, Table-Valued Functions,
OPENQUERY() (in the Microsoft SQL Server implementation), CTEs, Subqueries, etc.
As evident in the many discussions throughout this Post, it seems different people have different interpretations of what additional physical constructs they consider to be a relation, but database theory isn't aware of those constructs. I think OP's question is quite broad, which elicits the wide array of responses displayed here, but I think most of them are fair dependent on the context in which you want to speak in.
That being said, this is why I believe the following to also be correct answers when talking about those constructs in a physical form. When a Table exists in a database system, it is concrete, considerably it's an instance of an object like a collection object of data in a running application, here the database system being the running application. Other physically implemented constructs that can return "tabular data" (as worded by the OP), e.g. Table-Valued Functions or Table Variables can also be considered objects, when referring to them in the context of an actual database system implementation. I can talk about these constructs disjoined from the set of data (relations) they can hold / return and focus on their own existence as physical objects, if that's the context I choose to speak about them.
This is why I like Brendan's answer for the term "Database Object". I also wouldn't rule the word "entity" out either.
ORMs, such as Microsoft's Entity Framework, consider all database objects (Tables, Views, Stored Procedures, etc) as entities, I believe. This is in the context of the models that structurally represent the object (typically as a class) before it's actually instantiated.
So personally, I like to use the term entity when I'm speaking of a logical concept before instantiation of sed model, or further upstream, when a logical schema is being defined such as through a database diagram. I think entity is a good term to describe the structure of a thing without it needing to be physically realized.
But when talking about a concrete representation, such as an instance of a Table object in the application, or the concretely compiled Table in the database layer, then I think database object is a good term to use just as well.