EventCategory

EventCategoryId PK Name

Event

EventId PK EventCategoryId FK Name

This is what I've got now. However, events of some event category type need extra data fields. So where do these fields go? This is what I'm thinking...

EventCategory

EventCategoryId PK Name

Event

EventId PK EventCategoryId FK Name

SpecialEvent

EventId PK Extrafield

So there's a 1-1 relationship between Event and Special Event (this structure will map to a single SpecialEvent class in C#) and all events and only those events that reference the pertinent category will have a row in this new table.

Is this a fair design? My qualm is that an event will have a a corresponding row in the SpecialEvent table and yet won't reference the required event category or vica versa.

It looks ok for me. You could make a TargetPerEntityHierarchy on Event with EventCategoryId as the discriminator but that is not recommended for inheritance. So your setup looks ok, because it normalize Event table so they won't have NULLs on those special fields. The problem about having rows on SpecialEvent table that doesn't have correct category should be addressed at your business logic or validator classes, IMHO.