# Creating models

Now we’ll define your models – essentially, your database layout, with additional metadata.

> Philosophy
> 
> A model is the single, definitive source of information about your data. It contains the essential fields and behaviors of the data you’re storing. Django follows the [<span class="std std-ref">DRY Principle</span>](https://docs.djangoproject.com/en/4.1/misc/design-philosophies/#dry). The goal is to define your data model in one place and automatically derive things from it.
> 
> This includes the migrations - unlike in Ruby On Rails, for example, migrations are entirely derived from your models file, and are essentially a history that Django can roll through to update your database schema to match your current models.

In our poll app, we’ll create two models: `<span class="pre">Question</span>` and `<span class="pre">Choice</span>`. A `<span class="pre">Question</span>` has a question and a publication date. A `<span class="pre">Choice</span>` has two fields: the text of the choice and a vote tally. Each `<span class="pre">Choice</span>` is associated with a `<span class="pre">Question</span>`.

These concepts are represented by Python classes. Edit the `<span class="pre">polls/models.py</span>` file so it looks like this:

<div class="literal-block-wrapper docutils container" id="bkmrk-polls%2Fmodels.py%C2%B6"><div class="literal-block-wrapper docutils container"><div class="code-block-caption"><span class="caption-text">`<span class="pre">polls/models.py</span>`</span>[¶](https://docs.djangoproject.com/en/4.1/intro/tutorial02/#id2 "Permalink to this code")</div><div class="highlight-python notranslate"><div class="highlight"></div></div></div></div>```
from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)
```

Here, each model is represented by a class that subclasses [`<span class="pre">django.db.models.Model</span>`](https://docs.djangoproject.com/en/4.1/ref/models/instances/#django.db.models.Model "django.db.models.Model"). Each model has a number of class variables, each of which represents a database field in the model.

Each field is represented by an instance of a [`<span class="pre">Field</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field "django.db.models.Field") class – e.g., [`<span class="pre">CharField</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.CharField "django.db.models.CharField") for character fields and [`<span class="pre">DateTimeField</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.DateTimeField "django.db.models.DateTimeField") for datetimes. This tells Django what type of data each field holds.

The name of each [`<span class="pre">Field</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field "django.db.models.Field") instance (e.g. `<span class="pre">question_text</span>` or `<span class="pre">pub_date</span>`) is the field’s name, in machine-friendly format. You’ll use this value in your Python code, and your database will use it as the column name.

You can use an optional first positional argument to a [`<span class="pre">Field</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field "django.db.models.Field") to designate a human-readable name. That’s used in a couple of introspective parts of Django, and it doubles as documentation. If this field isn’t provided, Django will use the machine-readable name. In this example, we’ve only defined a human-readable name for `<span class="pre">Question.pub_date</span>`. For all other fields in this model, the field’s machine-readable name will suffice as its human-readable name.

Some [`<span class="pre">Field</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field "django.db.models.Field") classes have required arguments. [`<span class="pre">CharField</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.CharField "django.db.models.CharField"), for example, requires that you give it a [`<span class="pre">max_length</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.CharField.max_length "django.db.models.CharField.max_length"). That’s used not only in the database schema, but in validation, as we’ll soon see.

A [`<span class="pre">Field</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field "django.db.models.Field") can also have various optional arguments; in this case, we’ve set the [`<span class="pre">default</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.default "django.db.models.Field.default") value of `<span class="pre">votes</span>` to 0.

Finally, note a relationship is defined, using [`<span class="pre">ForeignKey</span>`](https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.ForeignKey "django.db.models.ForeignKey"). That tells Django each `<span class="pre">Choice</span>` is related to a single `<span class="pre">Question</span>`. Django supports all the common database relationships: many-to-one, many-to-many, and one-to-one.