I recommend that you model this from an object oriented perspective. I would create the following content types:
- Event content type (composed of event, overview, agenda, live broadcast maybe)
The reason for embedding overview, agenda and live broadcast to the event is because they are closely related to to specific event and creating separate content type for them would be expensive (because there is a very less probability that two event have the same agenda or overview).
Whereas other content types such as Speakers, Resources, Venue, Sponsorship, Registration can be regarded as separate content types, because:
To allow referencing the same content type by multiple event nodes i.e. for example, you will have a speaker who would speak in several events, or a resource that would be useful in several events hence, you will be avoid loads of duplication/inconsistency etc.
The other reason to create separate content type is to achieve low coupling and high cohesion. Speakers are different than events, the best way would be to reference than to embed a a list of speaker into event content type. Fields of a Speaker content type, does not directly relate to an Event (i.e. Database normalization perspective)
This would give you a clean set of content types that are linked with each other using references and can be queries very easily using views, contextual filters and relationship.