Is this a good database design in 3NF?

Question

I'm trying to understand how databases work by creating a movie theater database in MySQL. I created the following requirements and attempted to sketch out my ER diagram based on 3NF. A lot of resources said I should use associative tables, so I attempted to, but I am not sure if I am understanding the relationships between them correctly. Is this a good database design for the requirements? Are the associations correct? enter image description here

Requirements:

• A person can be an employee or a customer.
• An employee can also be a customer.
• Employees can work at multiple theaters.
• Theaters have many screen rooms (number of rooms is different for each theater).
• Screen rooms can have different seating arrangements / capacities / configurations.

Example:
Table: Screen_Rooms

| room_id (PK)   | theater_id (PK, FK) | capacity | rows | seats |
|----------------|---------------------|----------|------|-------|    
|1               |0001                 |10        | 2    |5      | 
|2               |0001                 |15        |5     |3      | 
|1               |0002                 |10        |5     |2      |
|2               |0002                 |20        |4     |5      |  


Table: Seat
| theater_id (PK, FK)   | room_id (PK, FK) | seat_id (PK) | seat_row | seat_number |
|-----------------------|------------------|--------------|----------|-------------|    
|0001                   |1                 |A1            |A         |1     
|0001                   |1                 |A2            |A         |2 
|...                    |                  |              |          | 
|0001                   |2                 |E5            |E         |5  

• Screen rooms have showtimes. They can only screen one movie at a time, but can screen multiple movies throughout the day (ie Spider Man at 8am and then Robinhood at 12pm).
• Movies can have many showtimes.
• Movies can have many genres.
• Movies can only have one director, but can have many cast members. • A director can be a cast member.
• Customers can make many sales.
• Customers can have many payments for the sale, but can only pay one way (ie. Cash or card not both).
• Employees can make many sales (ie selling tickets).
• Sales can be for many tickets.
• There are different ticket types (children, adult, senior, military).
• Each ticket is assigned a seat for a movie, in a room, in a theater.

Answer 1

Although I will not do a full, I will try to give SOME of an example to normalize. Some of what you have is close. You may have many theaters, start with that.

Theater
TheaterID (PK, ex integer, auto-increment)
TheaterName
Location, address, phone, etc

Within each theater, you have many Screens... Each screen is a single room. But having multiple theaters, you need to tie each screen to its specific theater. Ex: Theater A may have 5 screens, Theater B may have 11, etc

Screen
ScreenID (PK, ex integer, auto-increment)
TheaterID (FK, link to which theater it is)
Capacity, Seats, Rows

Now, based on your seat table

Seat
SeatID (PK, integer, auto-increment)
ScreenID (FK, link to screen.  From Screen, you know the Theater)
SeatRow    (constraint on Seat Row + Number for uniqueness to prevent duplicates)
SeatNumber

So at this point, with just a single SeatID, you know which screen showing AND the theater which it showed

Now on to the movies that will be available for showings

Movie
MovieID (PK, integer, auto-increment)
MovieName

Now you have all your screens and what movies are available. Now you need to know what showings are available.

ShowTimes
ShowTimeID (PK, integer, auto-increment)
ScreenID (FK to screens, which also then gives you the specific theater)
MovieID (FK to Movie)
BeginTime
EndTime

And now for people to buy tickets

Ticket
TicketID (PK, integer, auto-increment)
ShowTimeID (FK to ShowTimes, which gives you the screen, theater )
SeatID (FK to Seat which also gets you to screen, theater )
TicketType (for the age groups)

So, as you can see here, having a single primary key for each respective table, THAT ties you to everything else. Not dealing with composite keys (multiple columns) that represent a primary key, but a specific unique ID which simplifies the join. The table's "ID" key has its table context as above

Table    PK
Theater  TheaterID
Screen   ScreenID
Seat     SeatID
etc

So, if you see an ID in a table NOT of that purpose, you know its the foreign key, but it also indicates which table it originates

Foreign Key        To Primary Table
Screen.TheaterID   Theater.TheaterID
Seat.ScreenID      Screen.ScreenID