We'll look at the problems of table creation in much more depth in a little while. Right now, let's quickly review what you've done. You first created a mission statement for the Classic TV database. You followed up by developing mission objectiveswhat you want the database to accomplish. You used those mission objectives to come up with a list of data needs. From those data needs, you developed a preliminary list of columns you could use to store data.
None of these steps is peculiar to relational databases. Creating a mission statement and defining mission objectives aren't bad ideas for any information projectindeed, for achieving any goal. Even when you use a simple spreadsheet to store data, you still have to decide what columns you need and what data to put in them. And my diagnosis of the problems of "one table fits all" could just as easily be used to launch a discussion of the benefits of database models besides relational databases.
I'm going to forgo an extended discussion of earlier alternatives to relational databases, including various spreadsheet designs and hierarchical databases. Suffice it to say that each of these choices has serious structural flaws that a well-designed relational database overcomes. Instead of setting them up as straw men only to knock them down (as I've done with the "one table fits all" flat file), let's move specifically to the task of creating a relational database for classic TV shows.