The following are examples used to convey the point, there are multiple instances of each of these examples within your ERD.
Consistency is key. Some table names are pluralised (
Seats) some are not (
Ticket). Your table contains data about many tickets so I normally prefer pluralised table names.
You're prefixing every column with the name of the table. This makes for column names like
staff_staff_id, which isn't instantly understandable to readers. If I named the primary key of
ID then you store
staff.id and you might access
tickets.staff_id, which makes everything more understandable.
There's a couple of relations that don't exist, for example you've got
Ticket (makes sense if you have preassigned seating) but no relation to
Seats.seats_id? Why not? If your cinema/theatre doesn't have preassigned seating then you don't need this data.
There are some duplicates within tables. Why does
Ticket contain both
There are some unnecessary (unenforced) relations that are allowing for data inconsistencies. If a
MovieTime must happen within a
Hall an a ticket must be at a
MovieTime then there's no need for
Ticket to contain any information about the hall in which the movie is going to be shown.
It's unclear what the difference between the
screening_time is. Maybe one of them is the number of minutes the screening runs for? This information is already within
Movie and so is another duplication.
There's no need to persist the age as you've already got the date of birth. I've written about this on Stack Overflow a few times.
It's quite an assumption that all staff and movie names will be 45 characters or less.
I find the inclusion of
sex in the staff table a little off-putting. What's the purpose of storing this information? Are the chromosomes of the person selling you a movie ticket that important in this cinema/theatre. I also don't understand why it's 10 characters long.
How to start
Think about exactly what information is required to go within each table. If you're not sure it's required then don't add it in. If you need to add something later then so be it, but you haven't included a lot of unnecessary data. I'd set-up some test tables with dummy data to see if what you're creating will actually work.
Every relation to another table should be enforced. If you've got some unenforced relations then either add a foreign key constraint or remove the column.
Your cinema probably has tickets, so removing the data will prevent you selling tickets.