Your example converted to DO4 must look as follows:

// I'd add this type - adding an abstract base makes design more clean + allows you to share
// the behavior among all the descendants
[Serializable]
[HierarchyRoot]
public abstract class EventBase : Entity 
{
  [Key]
  Guid Id { get; private set; } // Or some other type
}

[Serializable]
public class Event<T> : EventBase
    where T : IEntity, new() // IEntity indicates DO4 must try  to map its descendants automatically
    // Although I'd put some stronger requirement, e.g. by using IEventData instead of IEntity here
{
    public T Data { get; set; }

    public Event(T data)
    {
        Data = data;
    }
}

[Serializable]
[HierarchyRoot]
public class FootballEvent
{
    // You need [Key]  here
    public Team CompetitorA { get; set; }  
    public Team CompetitorB { get; set; }    
}

[Serializable]
[HierarchyRoot]
public class TennisEvent
{
    // You need [Key]  here
    public Player CompetitorA { get; set; }
    public Player CompetitorB { get; set; }
}

[Serializable]
[HierarchyRoot]
public class F1RacingEvent
{
    // You need [Key]  here
    public EntitySet<Player> Drivers { get; private set; }
    public EntitySet<Team> Teams { get; private set; }
}

[Serializable]
[HierarchyRoot]
public class Team
{
    // You need [Key]  here
    public EntitySet<Player> Squad { get; set; }
}

[Serializable]
[HierarchyRoot]
public class Player
{
    public string Name { get; set; }
    public DateTime DOB { get; set; }
}

In this case Event<t> instances will be available (= mapped automatically) for all suitable Ts from model. E.g. in this case they'll be:

• EventBase // Yes, even it, coz it's suitable

• FootballEvent

• TennisEvent

• F1RacingEvent

• Team

• Player

If you'd like to restrict this to just certain types, you must do the following:

• Add an interface inherited from IEntity all these types will support, e.g. IEventData.

• Use it as generic parameter constraint for generic parameter T in Event<t>.

One more note: if you'll add a descendant of e.g. FootballEvent called SpecialFootballEvent, you won't get Event<specialfootballevent> available: DO4 maps only the most generic types in each hierarchy (so if it's possible to map just a root, only it will be mapped). In hierarchy of FootballEvent such a generic type is FootballEvent, so DO4 will map a generic instance of Event<t> just for it.

This is logical, because:

• Each hierarchy share the same Key structure

• So any reference of type FootballEvent is allowed to point to SpecialFootballEvent instance as well (i.e. there is a default OO logic without any restrictions)

• Thus it's enough to map just Event<footballevent> : its Data member will be able to point to SpecialFootballEvent as well, although to deal with SpecialFootballEvent, you must cast it.

• We actually can map Event<specialfootballevent> as well, but this isn't good from another point: you're getting an alternative allowing you to use both Event<footballevent> and Event<specialfootballevent> to reference to the same SpecialFootballEvent object. Such options are generally not good.

• One more important reason for not having Event<specialfootballevent> is that this type will allocate an additional table (or an additional column(s) in table mapped to Event<footballevent>). But imagine inheritance hierarchy is deep: in fact, we're wasting the space for each of such, although there are no real necessity for this.