In a multiplex, movies are screened in different auditoriums. One movie can be shown in more than one auditori

Exercises · Q11

Q. In a multiplex, movies are screened in different auditoriums. One movie can be shown in more than one auditorium. In order to maintain the record of movies, the multiplex maintains a relational database consisting of two relations viz. MOVIE and AUDI respectively as shown below: Movie(Movie_ID, MovieName, ReleaseDate) Audi(AudiNo, Movie_ID, Seats, ScreenType, TicketPrice)

(a) Is it correct to assign Movie_ID as the primary key in the MOVIE relation? If no, then suggest an appropriate primary key.

(b) Is it correct to assign AudiNo as the primary key in the AUDI relation? If no, then suggest appropriate primary key.

Uttar Pradesh UpmspTextbookSubjective· 4mImportance★★★★★

41% · 12/29 Questions

🔒 Locked · start free trial →

You're viewing a preview — the full solution, concept, methods & PYQ mapping are locked.

Start your 14-day free trial to unlock the full solution →

Concept understanding — Database Schema

Database Schema: The Blueprint of a Database

Imagine you are organising a large library. You don't just pile books randomly. First, you decide: What information will we keep about each book? Title, author, ISBN, shelf number. Then you decide: How are these pieces of information related? A book has one shelf, but a shelf holds many books. You also decide rules: Every book must have an ISBN; no two books can share the same ISBN.

That plan — the structure you design before you put a single book on the shelf — is the schema.

The Precise Meaning

A database schema is the formal, logical description of how data is organised in a database. It defines:

What tables exist (like "Books", "Members", "Loans")
What columns each table has (e.g., BookID, Title, Author, YearPublished)
What type of data each column holds (text, number, date, etc.)
What rules or constraints apply (e.g., "Every loan must refer to an existing member")
How tables relate to one another (e.g., "A member can borrow many books, but each loan record belongs to one member")

Think of the schema as the skeleton of the database. The actual data — the rows you fill in later — is the flesh and blood. The schema stays mostly unchanged; the data changes constantly.

Note

A common confusion: people say "the database" when they mean the data inside it. But the schema is the structure, not the data. Two databases can have the same schema but completely different data — like two schools using the same student record form but with different students' names.

Why the Schema Matters

Without a schema, data becomes a mess. You might store a customer's phone number in the "Name" column, or lose track of which orders belong to which customer. The schema prevents this by enforcing consistency and integrity.

Consider a bank. The schema says: "Every transaction must have an amount, a date, and a valid account number." If someone tries to enter a transaction without an account number, the database refuses — because the schema says so. This is not a software bug; it is a deliberate design choice built into the structure.

Key Components of a Schema

Tables – The main containers. Each table represents one kind of thing (Students, Products, Invoices).
Columns (Fields) – The attributes or properties of that thing (StudentName, DateOfBirth, Email).
Data Types – What kind of value each column holds (text, whole number, decimal, date).
Constraints – Rules that data must obey:
- Primary Key – A unique identifier for each row (like a roll number). No two rows can share it.
- Foreign Key – A column that links to another table's primary key, creating a relationship.
- Not Null – A column that must always have a value.
- Unique – A column where every value must be different.
Relationships – How tables connect: one-to-one, one-to-many, many-to-many. …

Start your 14-day free trial to unlock the full solution →

This is a plain theory question — it asks you to evaluate primary-key choices and identify foreign keys in a given relational schema.

Movie_ID as primary key in MOVIE Yes, it is correct. Movie_ID is a unique identifier for each movie — no two movies share the same ID, and every movie must have one. No other attribute in MOVIE (MovieName could repeat, ReleaseDate could repeat) guarantees uniqueness. So Movie_ID is the natural primary key.
AudiNo as primary key in AUDI No, it is not correct. The question states that one movie can be shown in more than one auditorium, but it does not say that one auditorium shows only one movie. In fact, a multiplex typically screens different movies in the same auditorium at different times. AudiNo alone cannot uniquely identify a row because the same auditorium number will appear for every movie screened in it. The correct primary key for AUDI is a composite key: (AudiNo, Movie_ID). Together, these two attributes uniquely identify which movie is playing in which auditorium. …

Start your 14-day free trial to unlock the full solution →

Movie_ID is the correct primary key for MOVIE; AudiNo alone is not sufficient as the primary key for AUDI because one movie can play in multiple auditoriums — the correct key is a composite (AudiNo, Movie_ID); Movie_ID in AUDI is a foreign key referencing MOVIE.

This is a database schema design question — it tests your understanding of primary keys, composite keys, and foreign keys in the context of a real-world relationship. The key insight is that the problem statement tells you "one movie can be shown in more than one auditorium." That single sentence dictates everything about the keys.

Let's examine each relation carefully.

Primary key for MOVIE The MOVIE relation has three attributes: Movie_ID, MovieName, ReleaseDate. Movie_ID is a unique identifier assigned to each movie — no two movies share the same ID. It is minimal (one attribute is enough) and stable (it won't change). That satisfies every property of a primary key. So yes, Movie_ID is the correct choice.
Watch out

Never confuse "natural key" with "primary key." MovieName might seem like a candidate, but two movies could have the same name (remakes, different languages), and names can change. Movie_ID is artificial but reliable — that's exactly what primary keys are for.
Primary key for AUDI The AUDI relation has: AudiNo, Movie_ID, Seats, ScreenType, TicketPrice. AudiNo alone is not a valid primary key. Why? Because the same auditorium (say AudiNo = 3) can show multiple movies at different times — and the problem explicitly says one movie can be shown in more than one auditorium. So the same AudiNo will appear with different Movie_ID values. AudiNo alone cannot uniquely identify a row. The correct primary key is a composite key: (AudiNo, Movie_ID). Together, these two attributes uniquely identify which movie is playing in which auditorium. No two rows will have the same pair. …

Start your 14-day free trial to unlock the full solution →

←Previous questionQ10 — School uniform is available at M/s Sheetal Private Limited. They have …→Next questionQ12 — For the above given database STUDENT-PROJECT, answer the following: St…

🎓Unlock everything free for 14 days

Unlock everything free for 14 days