The point of normalization is to avoid duplicating information, to save storage and so that things can't get out of sync. For example, the simplest implementation would be to store <actor_name,role_name>, but if an actor changed their name (say an actress got married, or you realized you misspelled an actor's name), you might have to update hundreds of records, and if you missed some you'd have inconsistency.

There's lots of different ways to normalize, with each one making tradeoffs between convenience, speed, and data duplication.

In your case, I would probably have a PEOPLE table, an EPISODES table, and a ROLES table. I'd create "pseudo-roles" for the various non-acting roles that somebody can play, such as "director" or "writer", perhaps using a special character to indicate that. For example:

PEOPLE
  id|name
  --+----
   1|Carrie Fisher
   2|John Smith

EPISODES
  year|ep#|name
  ----+---+----
  1999|  1|Attack of the Killer Tomatoes
  1999|  2|Attack of the Killer Clowns
  2002|  1|Attack of the Clones

ROLES
  id|name
  --+----
   1|Jake Jones
   2|Mycroft Jones
   3|@WRITER
   4|@DIRECTOR

DID
  person|role|epyr|ep#
  ------+----+----+---
       2|   1|1999|  1    -- Smith plays Jake in 99-1
       2|   2|2002|  1    -- Smith plays Mycroft in 02-1
       1|   1|2002|  1    -- Fisher plays Jake in 02-1
       1|   3|2002|  1    -- Fisher wrote 02-1

It seems like that avoids duplicating most information, keeps queries simple, and doesn't lose information.

One flaw is that if the same actor plays the same role in many episodes, the <person,role> pair will be repeated very frequently, and if you make a mistake with which person plays a role, you may have many records to update. You could normalize that out into a PLAYED_ROLE table, then use id's from that in DID, but I think the increased query complexity isn't worth it.

Updated: Minor formatting and wording changes.