Can anyone explain to me(beginner) in plain english what "Schema" means?

Question

I need a plain english explanation of "schema" as in Database schema & Xml schema.

EDIT: When someone says to create a database schema, does it mean creating constraints for the fields in the tables?

Answer 1

From Wikipedia:

[XML Schema is] a way to define the structure, content and, to some extent, the semantics of XML documents.

The statement holds true for database schemas as well.

Answer 2

Schemas describe entities and their inter-relationships.

A Schema is a Model.

An entity is a way of representing some object (in the Domain, which is the situation you are modelling).

Answer 3

A schema is the description of the representation of data. It's the data structure - fields and types. Nothing more involved than that really.

Answer 4

A schema is the framework or model of whatever it is you are trying to describe.

The database schema will show each table, and its fields and its relationships to other tables in the database, but it will not include any actual data.

The same goes for an XML schema, it will show you the framework of the XML document but not any data.

Answer 5

A database schema is radically different than an XML schema. A schema is a language for defining a structural grammar. A database schema would define a structure using the database's own meta data. So that the schema can form a data storage document using the database's own descriptors.

XML, however, is not a data storage device. XML is a meta language, which is a syntax for creating languages. XML schema is an XML defined language for creating a formal language grammar. The difference between an XML schema and a database schema is that the database schema exists to represent the data while an XML schema exists to represent a markup language structure without regard for any data it may or may not contain.

Answer 6

Definition

A schema defines the structure of the data, whether you store it in a database or an XML file or elsewhere.

Example
Suppose you use a relational database server to store your company's data, and you have a "Customers" table, to track information for each customer. The schema for the Customer table might dictate that each customer entry should have a firstname, lastname, and phone number. When you create a customer entry you can store only those fields.

Constraints

Schema can specify whether a field is optional or required. In this example, you might require that ALL of those fields be present. If the schema were enforced by some mechanism, it would not be possible to enter a customer entry into the database without specifying a phone number. Or, your schema might specify a mobile phone number, as optional.

In this example, the schema doesn't have a slot for "size" as an element within the customer structure, so you cannot insert that element into any customer entry. On the other hand, a T-shirt company might use a customer schema that includes a "size" field. Schemas vary by the thing they are describing, and by the people or parties that use the schema.

As Applied to XML

XML schema just defines the structure of a conformant XML document. There's a W3C standard for formally describing the schema, XML Schema Definition, aka XSD. (See the primer for an informal description of it) There are also other ways to formally describe the structure, or schema of an XML doc, which are not dejure standard but serve the same purpose. Relax-NG is one.

Informal Schema

There are also informal - or at least, less formal - ways of describing schema, particularly around XML files or other formats. Providing am example XML file and a text description is one common, informal way of specifying the schema. I call this "informal" because a sample doc cannot possibly describe everything about the schema. But, a sample doc coupled with a few lines of english text describing what's intended, is often a good enough, or even the best, way to describe an XML schema. This is basically the way the majority of the web works.

Consider the case of JSON. It is now being used to store and transmit information, in some cases as a alternative to XML. As far as I know, there is no formal mechanism for describing a schema for JSON. There's no way to specify what an acceptable or "compliant" JSON document looks like. What people do instead is provide an example or template, and that's good enough. There's no enforcement. If you provide a JSON packet that conforms to the expected format, then it works as expected. If you don't, then it won't work.

Informal schema is also the way most old-school paper-based businesses work. They hand out a form and give some examples - "if you want to place an order, fill out the form in this way".

Enforcement or Validation

Schema may or may not be "enforced" automatically. A relational database server typically provides a strict schema enforcement. You MUST define the schema in order to create a table, and any database clients MUST conform to the schema. Some XML-based systems perform document validation against an XSD to enforce schema. Many do not. As I said, most of the web is much less formal.

---

In answer to the second part of your question,
creating a database schema for a Customer means defining those fields that belong to the customer entity (in an entity sense), or columns that can be stored in the customer table (in a database), or the attributes and child elements of a Customer element (in an xml document), as well as the constraints on same (is the field required, optional, etc)..

A constraint places a limit on the type or format of the data in a particular field. One example constraint is whether the field is required or optional. Another constraint might be: "a customer name cannot be solely comprised of numeric characters." A more strict constraint might say: "a customer name may not have any numeric characters at all." For the T-shirt company, a constraint might be: the "size" element must be one of {S,M,L,XL}. Formal schema languages allow you to specify these constraints explicitly, in a way that a computer program could verify compliance. In informal schema specifications, you would just write or say, "the size must be one of S,M,L,XL" and that covers it.

Answer 7

A database schema is a distinct namespace that is separate from a database user. You can think of a schema as a container of objects. Schemas can be created and altered in a database, and users can be granted access to a schema. A schema can be owned by any user, and schema ownership is transferable.

Importance of Database Schemas in SQL Server

Answer 8

"A Schema is a Model."

"problem is, for a beginner, this explanation does not clarify."

A schema is indeed a model. And a model is anything that allows any viewer of the model to form him/herself an image of what reality will look like when the thing modeled has effectively been built. A scale model of a bridge that has to be built, and how it integrates in its environment, for example. Or the paper plans of a house to be built.

A database schema is a model of a database that will allow any viewer of the model to form him/herself an image of what kind of information the database registers (and therefore what kind of information can be retrieved from it), what constraints apply to the information registered (i.e. what rules the information registered must satisfy), what kind of transformations (if any) are needed when porting the information from the database to a program written in some host language, etc. etc.

A physical database schema tells the viewer which chunks of information are physically located close to one another (and are therefore interesting to query "in one go"), which indexes exist on the registered information (and therefore which selection criteria are very interesting to apply if we want to get fast responses), etc etc.

All of that without the database actually having to be built, or without it having to be available to the one viewing the model.

Answer 9

A schema is just another name for type definition where you can restrict what values an object would have. For the most part there are frameworks/tools that parse blobs of binary data into a structure that you can access (rather than you building the parser yourself).

In the database context, you can think of table names, field names, field types, relationships as a way of limiting what kind of data to expect.

In the XML context, you specify what kind of types each element would have and other things.

In OO languages you can think of it as the class definition.

In C you can think of it as typedef struct.