Whether or not to use an artificial key or a natural key is a very contentious, largely philosophical debate. However, you must ALWAYS enforce the natural key (using a UNIQUE constraint) even if you decide to use a surrogate key as your primary key. I tend to use surrogate keys for tables that hold user-entered data. Also, if a table has a non-transferable relationship with another table (i.e., the table represents a weak entity), I will include the foreign key to the other table in the primary key, resulting in a "composite surrogate key".
For example, as it stands, your Room table does not appear to prevent someone from entering an infinite number of "room 1"s for a venue. You must enforce the natural key, which would be a composite key consisting of the venue and room name/number. If you choose to keep RoomId as a surrogate key, I would also include VenueID in the primary key, since we cannot have a room without a venue, and we also wouldn't expect a room to move from venue to venue. So I'd end up with two keys on the table: a primary key consisting of VenueId and Roomid, and a UNIQUE NOT NULL constraint consisting of VenueId and RoomName.
Your Event table also has problems. It is essentially an intersection table between a Show and a Room (not a Venue, which can be derived based on the room) and a time period. However, there are several other keys here as well, one which consists of a Room and a time period, since we cannot double-book a room, and another which consists of a Show and a time period, since presumably the performers cannot be in multiple places at once. AvailableSeats and RegisteredAttendees are not needed, since they can be derived from the room capacity and number of sold tickets.
It's debatable if you need a separate ticket table; you can simply add a column to the Order table indicating the number of tickets sold.