Definition
A schema is the official blueprint of your data, drawn up before any information goes into a database. Just as a sign-up form has set fields for "name," "date of birth," and "phone number," a schema is the agreement that sets the frame: what structure and rules a computer must follow when storing data.
Why we need a sign-up form
What would happen if a theme park gave you a blank sheet of paper to sign up for a membership, with no fields at all? Someone would write their name in Korean, someone would give only an email instead of a phone number, and someone would spread their address over three lines. Information gathered in such a jumble is nearly impossible for a computer to search or sort later.
So we draw boxes in advance and set rules. "Name field: 10 characters or fewer," "date of birth field: 8 digits," "phone number field: required." Databases work the same way. To keep huge amounts of information in order, you need to set the format and rules for incoming data ahead of time, and this collection of agreements is the schema.
When a schema is well designed, it can stop the wrong data at the door. If someone accidentally tries to put the text "Seoul" into an age field, the database rejects it right away and prevents a system error.
To be more precise: three levels of blueprint
To be more precise, just as experts draw an aerial view and a floor plan separately when building a house, a schema is handled at three levels. This is called the "three-level schema architecture." It's a way to manage three things separately: the screens users see, the overall data structure, and how data is actually stored on the hard disk.
At the outermost level is the external schema, which is what users see. Even in the same online store, a buyer's order history screen and a seller's settlement screen need different information. The external schema is a separate blueprint tailored to each user's point of view.
In the middle is the conceptual schema, the skeleton of all the data, and at the bottom is the internal schema, which deals with how data is physically written to disk. With layers split this way, an internal change such as swapping a hard disk doesn't force you to rebuild the program screens users see.
A rigid blueprint and a flexible box
In a traditional relational database, the schema is very strict. It's like pouring concrete walls solid when you build a house: data that breaks the rules set at the start is never allowed in. For places like banks and hospitals, where there can't be a single error, this strict schema is a reliable shield that protects the trustworthiness of the data.
On the other hand, in environments where data formats change all the time, like today's internet services, some use NoSQL, where the schema is flexible. It's like using a big box where you can toss things in freely instead of a standardized chest of drawers. Today you put in only text, and tomorrow you can add photos and location data, and the system won't stop you.
In the end, which schema to choose depends on what the data is for. Financial transactions, where rules and accuracy come first, mostly use a firm schema, while services flooded with new kinds of posts sometimes use the flexible approach alongside it. Even large social media services often keep their core data in relational databases, so mixing both approaches within one service is common.
Common misconceptions
Once a schema is set, it can never be changed.
As a service grows, the schema can be modified too (this is called a migration). But the change is made through careful steps so that the large amount of data already stored isn't damaged.
Where you meet it
In a shopping mall database, a rule that limits the "price" field to numbers only, not text.
In a student roster, a frame that prevents the "student ID" from being duplicated and the "name" from being left blank.
In one sentence
A data schema is a blueprint that defines a database's rules and structure in advance, a skeleton that keeps data from getting tangled up in the wrong way.