Mapping return types when calling Stored Procedures from Entity Framework 7

I have basic tables mapped using EF 7 and this is working well.

Now I want to call a stored procedure and return a list of a customised model. This model consists of data extracted from several tables.

In my context I map my model 'ReportSummary':

public class MyDbContext : DbContext
{
	:
	public DbSet<ReportSummary> ReportSummary { get; set; }
	:
}

I call the stored procedure like so:

 	public async Task<IEnumerable<ReportSummary>> GetUserReportSummaries(Guid userId, bool showDeleted)
	{
	    return await _context
	    	.ReportSummary
	        .FromSql($"EXECUTE dbo.GetReportSummaries {userId}, {showDeleted}")
	        .ToListAsync();
	}

Mapping my model this way works fine and the call returns expected results.

But my issue is that by mapping to a DbSet, when I generate the SQL to update my database, I now have a table created for my 'ReportSummary' model - which I don't want.

Am I mapping this correctly? How can I use my model and not create a table?
If I don't add the DBSet, then the call to the stored procedure does not work.

Can entity framework use models that are not tables? There must be a way to return non trivial types from a stored procedure.

I want to be able to use a model for the stored procedure return type, but not have to create a table for this model.

I can edit the migration code to delete the generated table definition for 'ReportSummary', but this seems a bit hacky...

Thank you ErikEJ

As suggested ExcludeFromMigrations will do this.

In the db context object I now have:

    :

    public DbSet<ReportSummary> ReportSummary { get; set; }

    :

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfigurationsFromAssembly(Assembly.GetExecutingAssembly());

        modelBuilder.Entity<ReportSummary>().ToTable(nameof(ReportSummary), t => t.ExcludeFromMigrations());
    }

The migration and generated SQL will now not include a definition for a 'ReportSummary' table,
but the DBSet is still available to be used in a FromSql() call.

Another alternative is to use Dapper for stored procedure calls. This can be used alongside Entity Framework

The code is slightly simpler as you don't need to remember to exclude the model from the migration.
For Dapper the only code needed to call the stored procedure would be:

    using (var connection = new SqlConnection( dbConnectionString ))
    {
        var sql = "EXECUTE dbo.GetReportSummaries @userId, @showDeleted";
        return await connection.QueryAsync<ReportSummary>(sql, new { userId, showDeleted });
    }

The disadvantage is you need to include another package, but this may be worthwhile if you have lots of stored proc calls.

Create your custom model in your codebase(e.g. GetCustomersSP) and inside you context
configure that class in the following way =>
modelBuilder.Entity<GetCustomersSP>().HasNoKey()

Inside the GetCustomersSP class you will need to have the return columns from the Stored Procedure.