---
title: "Models"
version: 1.9
locale: pt-br
source: https://docs.djangoproject.com/pt-br/1.9/topics/db/models/
canonical: https://djangodocs.dev/pt-br/1.9/topics/db/models/
---
# Models

Um modelo é um único e definitiva fonte de dados sobre os seus dados, Ele contém os campos e comportamentos essenciais dos dados que você está armazenando. Em geral, cada modelo mapeia  para uam única tabela no seu banco de dados.

O básico

- Cada modelo é uma classe Python que herda [`django.db.models.Model`](/pt-br/1.9/ref/models/instances/#django.db.models.Model).
- Cada atributo de um modelo representa um campo no banco de dados.
- Com tudo isso, Django lhe dá uma API de acesso ao banco de dados gerada automaticamente; veja [Fazendo consultas](/pt-br/1.9/topics/db/queries/).

## Exemplo rápido

Neste exemplo o modelo define um `Person`, o qual tem um ```first_name``e ``last_name```:

```
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
```

`first_name` e `last_name` são “[fields](#fields)” do modelo. Cada campo é especificado como um atributo de classe, e cada atributo mapeia uma coluna do banco de dados.

O modelo `Person` criaria uma tabela de banco de dados como esta:

```sql
CREATE TABLE myapp_person (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL
);
```

Algumas notas técnicas:

- O nome da tabela, `myapp_person`, é automaticamente derivado de alguns metadados do modelo mas pode ser sibrescrito. Veja [Table names](/pt-br/1.9/ref/models/options/#table-names) para mais detalhes.
- Um campo `id` é adicionado automaticamente, mas este comportamento pode ser sobrescrito. Veja [Campos chave-primária automáticos.](#automatic-primary-key-fields).
- O SQL `CREATE TABLE` neste exemplo está formatado usando a syntax do PostgreSQL, mas vale a pena notar que o Django usa SQL de acordo com o “backend” do banco de dados especificado no seu  [arquivo de definições](/pt-br/1.9/topics/settings/).

## Usando Modelos

Uma vez que tenha definido seus modelos, você precisa dizer ao Django que irá *usar* aqueles modelos. Faça isso editando seu arquivo de definições e alterando a definição do [`INSTALLED_APPS`](/pt-br/1.9/ref/settings/#std-setting-INSTALLED_APPS) para adicionar o nome do módulo que contém seu `models.py`.

Por exemplo, se o modelo para sua aplicação está em um módulo `myapp.models` (a estrutura de pacote que foi criada para uma aplicação pelo script [`manage.py startapp`](/pt-br/1.9/ref/django-admin/#django-admin-startapp)), [`INSTALLED_APPS`](/pt-br/1.9/ref/settings/#std-setting-INSTALLED_APPS) deve ser lido, em parte:

```
INSTALLED_APPS = [
    #...
    'myapp',
    #...
]
```

Quando adicionar novas aplicações ao [`INSTALLED_APPS`](/pt-br/1.9/ref/settings/#std-setting-INSTALLED_APPS), tenha certeza de rodar [`manage.py migrate`](/pt-br/1.9/ref/django-admin/#django-admin-migrate), opcionalmente antes fazendo migrações para eles antes com [`manage.py makemigrations`](/pt-br/1.9/ref/django-admin/#django-admin-makemigrations).

## Campos

A parte mais importante de um modelo – e a única parte requerida de um modelo – é a lista de campos de banco de dados que ele define. Campos são especificados através de atributos de classe. Cuidado para não escolher nomes de campos que conflitem com a [API dos modelos](/pt-br/1.9/ref/models/instances/) like `clean`, `save`, ou `delete`.

Exemplo

```
from django.db import models

class Musician(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    instrument = models.CharField(max_length=100)

class Album(models.Model):
    artist = models.ForeignKey(Musician, on_delete=models.CASCADE)
    name = models.CharField(max_length=100)
    release_date = models.DateField()
    num_stars = models.IntegerField()
```

### Tipos de campos

Cada campo no seu modelo deve ser instanciado da classe [`Field`](/pt-br/1.9/ref/models/fields/#django.db.models.Field) apropriada. O Django usa o tipo de classe do campo para determinar algumas coisas:

- O tipo da coluna, o qual diz ao banco de dados que tipo de dado irá armazenar (e.g. `INTEGER`, `VARCHAR`, `TEXT`).
- O [widget](/pt-br/1.9/ref/forms/widgets/) HTML padrão para usar quando renderizar o campo de um form  (ex. `<input type="text">`, `<select>`).
- The minimal validation requirements, used in Django’s admin and in
  automatically-generated forms.

Django vem com dúzias de tipos de campos; você pode achar uma lista nas [refrências de campos de modelo](/pt-br/1.9/ref/models/fields/#model-field-types). Você pode facilmente escrever seus próprios campos se os que vêm definidos no Django não resolverem; veja [Escrevendo campos personalizados de modelos.](/pt-br/1.9/howto/custom-model-fields/).

### Opções de campos

Cada campo recebe um certo conjunto de argumentos específicos (documentados na [referência de campos de modelo](/pt-br/1.9/ref/models/fields/#model-field-types)). Por exemplo, a [`CharField`](/pt-br/1.9/ref/models/fields/#django.db.models.CharField) (e suas subclasses) requerem um argumento [`max_length`](/pt-br/1.9/ref/models/fields/#django.db.models.CharField.max_length) o qual especifica o comprimento usado para armazenar dados do campo `VARCHAR` do banco de dados.

Também há um conjunto de argumentos comuns disponíveis para todos os tipos de campos. Todos opcionais. Estes argumentos são explicados na  [referência](/pt-br/1.9/ref/models/fields/#common-model-field-options), mas aqui um sumário dos argumentos mais usados:

**[`null`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.null)**

  Se `True`, o Django irá usar valores “vazios” como `NULL` no banco de dados. Padrão is `False`.

**[`blank`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.blank)**

  Se `True`, é permitido o campo estar em “branco”. O padrão é  `False`.

  Note que isso é diferente de [`null`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.null). [`null`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.null) é puramente relacionado ao banco de dados, enquanto que o [`blank`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.blank) é relacionado a validação. Se um campo tiver [`blank=True`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.blank), a validação do “form” permitirá entrada de ym valor vazio. Se o campo tiver [`blank=False`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.blank), o campo será requerido.

**[`choices`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.choices)**

  Um iterável (ex.: lista de tuplas) de tuplas de 2 apra usar como opções  para este campo. Assim sendo, o “widget” padrão será um “select box” no lugar de um campo de texto padrão e o campo se limitará às opções dadas.

  Uma lista de opções se parece com isso:

  ```
  YEAR_IN_SCHOOL_CHOICES = (
      ('FR', 'Freshman'),
      ('SO', 'Sophomore'),
      ('JR', 'Junior'),
      ('SR', 'Senior'),
      ('GR', 'Graduate'),
  )
  ```

  O primeiro elemento em cada tupla é o valor que será armazenado no banco de dados. O segundo elemento será mostrado pelo “widget” de formulário padrão ou na [`ModelChoiceField`](/pt-br/1.9/ref/forms/fields/#django.forms.ModelChoiceField). Dada uma instância de modelo, o valor a ser mostrado por campo “choice” pode ser acessado usando o método `get_FOO_display()`. Por exemplo:

  ```
  from django.db import models

  class Person(models.Model):
      SHIRT_SIZES = (
          ('S', 'Small'),
          ('M', 'Medium'),
          ('L', 'Large'),
      )
      name = models.CharField(max_length=60)
      shirt_size = models.CharField(max_length=1, choices=SHIRT_SIZES)
  ```

  ```
  >>> p = Person(name="Fred Flintstone", shirt_size="L")
  >>> p.save()
  >>> p.shirt_size
  'L'
  >>> p.get_shirt_size_display()
  'Large'
  ```

**[`default`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.default)**

  O valor padrão para o campo. Este pode ser um valor ou um objeto “callable”. Se “callable” ele será chamado cada vez que um novo objeto for criado.

**[`help_text`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.help_text)**

  Texto extra de ajuda para ser mostrado com o “widget” do formulário. É útil para documentar mesmo que seu campo não seja usado em um formulário.

**[`primary_key`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key)**

  Se `True`, este campo será a chave-primária do seu modelo.

  Se você não especificar o [`primary_key=True`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key) para qualquer campo no seu modelo, o Django irá automaticamente adicionar uma [`IntegerField`](/pt-br/1.9/ref/models/fields/#django.db.models.IntegerField) para ser a chave-primária, e você não precisa definir [`primary_key=True`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key) em nenhum dos seus campos a menos que queria sobrescrever o comportamento padrão da chave-primária. Para mais, veja [Campos chave-primária automáticos.](#automatic-primary-key-fields).

  O campo chave-primária é somente para leitura. Se você alterar o valor de uma chave-primária em um objeto existente e salvá-lo, um novo objeto será criado além do antigo. Por exemplo:

  ```
  from django.db import models

  class Fruit(models.Model):
      name = models.CharField(max_length=100, primary_key=True)
  ```

  ```pycon
  >>> fruit = Fruit.objects.create(name='Apple')
  >>> fruit.name = 'Pear'
  >>> fruit.save()
  >>> Fruit.objects.values_list('name', flat=True)
  ['Apple', 'Pear']
  ```

**[`unique`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.unique)**

  Se `True`, este campo deve ser único dentro da tabela

Novamente, estas são apenas descrições curtas das opções mais comuns dos campos.  Detalhes completos podem ser encontrados na ref:referência de opções de campos de modelos comuns \<common-model-field-options\>.

### Campos chave-primária automáticos.

Por padrão, o DJango dá a cada modelo o seguinte campo:

```
id = models.AutoField(primary_key=True)
```

Este é um campo chave-primária de incremento automático.

Se quiser implementar uma chave-primária personalizada, apenas especifique [`primary_key=True`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key) em um de seus campos. Se o Django vir que você explicitamente definiu [`Field.primary_key`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key), ele não adicionará uma coluna id\`\`automaticamente.

Cada modelo requere exatamente um campo que tenha [`primary_key=True`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.primary_key) (declarado explicitamente ou adicionado automaticamente).

### Nomes de campo detalhados

Cada tipo de campo, exceto para [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey), [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) e [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField), recebe um argumento opcional como primeiro argumento – um nome detalhado. Se o nome detalhado não for informado, o Django irá automaticamente criar ele usando o atributo nome do campos, convertendo “underscores” para espaços.

Neste exemplo, o nome detalhada é `"person's first name"`:

```
first_name = models.CharField("person's first name", max_length=30)
```

Neste exemplo, o nome detalhado é `"first name"`:

```
first_name = models.CharField(max_length=30)
```

[`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey), [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) and [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) requerem que o primeiro argumento seja uma classe de modelo, então use o argumento nomeado [`verbose_name`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.verbose_name):

```
poll = models.ForeignKey(
    Poll,
    on_delete=models.CASCADE,
    verbose_name="the related poll",
)
sites = models.ManyToManyField(Site, verbose_name="list of sites")
place = models.OneToOneField(
    Place,
    on_delete=models.CASCADE,
    verbose_name="related place",
)
```

A convenção é não usar caixa-alta na primeira letra do [`verbose_name`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.verbose_name). O Django irá automaticamente captalizar a primeira letra quando for necessário.

### Relacionamentos

Claramente, o poder dos bancos de dados relacionais está em relacionar as tabelas entre elas. O Django oferece maneiras de definir os três tipos de relacionamentos mais comuns: muitos-para-muitos, muitos-para-um e um-para-um.

#### Many-to-one relationships

Para definir um relacionamento de muitos-para-um, use [`django.db.models.ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey). Você o usar como qualquer outro tipo de [`Field`](/pt-br/1.9/ref/models/fields/#django.db.models.Field): incluindo-o como um atributo do seu modelo.

A [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey) requer um argumento posicional: a classe com a qual o modelo está relacionado.

Por exemplo, se um modelo `Car` tem um fabricante `Manufacturer` – quer dizer, um `Manufacturer` faz múltiplos carros mas cada `Car` somente tem um `Manufacturer` – use as seguintes definições:

```
from django.db import models

class Manufacturer(models.Model):
    # ...
    pass

class Car(models.Model):
    manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)
    # ...
```

Você também pode criar [relacionamentos recursivos](/pt-br/1.9/ref/models/fields/#recursive-relationships) (um objeto com relacionamento muitos-para-um comsigo mesmo) e [relacionamentos para modelos que ainda não foram definidos](/pt-br/1.9/ref/models/fields/#lazy-relationships); veja [a referência para campos de modelo](/pt-br/1.9/ref/models/fields/#ref-foreignkey) para detalhes.

É sugerído, mas não requerido, que o nomde de um campo [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey) (manufacturer\`\`no nosso exemplo acima) seja o nome do modelo, em caixa baixa. Você pode, claro, chamar o campo como quiser. Por exemplo:

```
class Car(models.Model):
    company_that_makes_it = models.ForeignKey(
        Manufacturer,
        on_delete=models.CASCADE,
    )
    # ...
```

> **See also**
>
> Campos [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey) aceitam um número extra de argumentos os quais são explicados na [referência de campos de modelo](/pt-br/1.9/ref/models/fields/#foreign-key-arguments). Estas opções ajudam a definir como o relacionamento deve funcionar; todos são opcionais.
>
> Para detalhes sobre como acessar de meneira inversa os objetos relacionados, veja o ref:Exemplo de como seguir relacionamentos ao inverso \<backwards-related-objects\>.
>
> Para um ódigo de exemplo, veja o [modelo exemplo de relacionamentos  muitos-para-um](/pt-br/1.9/topics/db/examples/many_to_one/).

#### Many-to-many relationships

Para definir relacionamentos muitos-para-muitos, use [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField). Você o usa tal como qualquer outro tipo de [`Field`](/pt-br/1.9/ref/models/fields/#django.db.models.Field): incluindo-o como um atributo de classe no seu modelo

O [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) requer um argumento posicional: a classe com a qual o modelo está relacionado.

Por exemplo, se a `Pizza` tem muitos objetos `Topping` – quer dizer, um `Topping` pode ter em multiplas pizzas e cada `Pizza` tem muitos recheios – aqui está como você deveria representá-los:

```
from django.db import models

class Topping(models.Model):
    # ...
    pass

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)
```

Tal como [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey), você também pode criar  [relacionamentos recursivos](/pt-br/1.9/ref/models/fields/#recursive-relationships) (um objeto com relacionamento muitos-para-muitos com ele mesmo) e [relacionamentos com modelos ainda não definidos](/pt-br/1.9/ref/models/fields/#lazy-relationships).

É sugerido, mas não requerido que o nome de um [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) (`toppings` no nosso exemplo acima) seja um plural descrevendo o conjunto dos objetos relacionados do modelo.

Não importa quais dos modelos tem a [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField), mas você deve colocá-la somente em um dos modelos – não em ambos.

Geralmente, instancias de [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) devem ir no objeto que serão editados em um formulário. No exemplo acima, `toppings` está na  `Pizza` (ao invés de `Topping` ter `pizzas` como [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) ) porque é mais natural pensar sobre pizza tendo recheio do que recheios estando em múltiplas pizzas. A maneira com está definido acima, o formulário de `Pizza` deveria deixar usuários selecionar os recheios.

> **See also**
>
> Veja o [Exemplo de relacionamento de modelo muitos-para-muitos](/pt-br/1.9/topics/db/examples/many_to_many/) par um exemplo completo.

[`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) os campos também aceitam vários argumentos extras como explicado na [referência de campos de modelo](/pt-br/1.9/ref/models/fields/#manytomany-arguments). Estas opções ajudam a definir como o relacionamento deve funcionar; todos são opcionais.

#### Campos extras no relacionamento muitos-para-muitos

Quando você está lidando com relacionamentos muitos-para-muitos simples tal como combinar pizzas e recheios, tudo o que você precisa é um [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField)  padrão. Porém, algumas vezes você quer associar dados com o relacionamento entre dois modelos.

Por exemplo, considere o caso de uma aplicação que rastreia grupos musicais aos quais pertencem músicos. Existe um relacionamento muitos-para-muitos entre pessoas e grupos aos quais eles são membros, então você poderia usar uma [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) para representar este relacionamento. Porém, existem váriios detalhes sobre este relacionamento que você talvez queria coletar, tal como a data na qual a pessoa se juntou ao grupo.

Para estas situações, o Django permite que você especifique o modelo que será usado para “governar” o relacionamento muitos-para-muitos. Você pode então colocar campos extras no modelo intermediário. O modelo intermediário está associado a [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField) usando o argumento [`through`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField.through) para apontar para o modelo que atuará como um intermediário. Para nosso exemplo de músicos, o código poderia parecer como algo como:

```
from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=128)

    def __str__(self):              # __unicode__ on Python 2
        return self.name

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through='Membership')

    def __str__(self):              # __unicode__ on Python 2
        return self.name

class Membership(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)
```

Quando você define um modelo intermediário, você especifica explicitamente chaves-estrangeiras para os modelos que estão envolvidos no relacionamento muitos-para-muitos. Esta declaração explícita define como os dois modelos estão relacionados.

Existem algumas poucas restrições sobre os modelos intermediários.

- Seu modelo intermediário deve ter uma - e \* somente\* uma - chave estrangeira para o modelo fonte (no nosso exemplo, este deve ser o `Group`), ou você deverá especificar explicitamente as chaves-estrangeiras que o Django deve usar para o relacionamento usando o [`ManyToManyField.through_fields`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField.through_fields). Se você tiver mais de uma chave-estrangeira e `through_fields` não estiver especificado, um erro de validação será emitido. Uma restrição similar se aplica para a chave-estrangeira para o modelo alvo (no nosso exemplo, este deve ser o `Person`).
- Para um modelo que tenha um relacionamento muitos-para-muitos para ele mesmo através de um modelo intermediário, é permitido duas chaves-estrangeiras para o mesmo modelo, mas elas serão tratadas como os dois lados (diferentes) do relacionamento muitos-para-muitos. Se houver *mais* de duas chaves-estrangeiras, você também deve especificar o `through_fields` como acima, ou um erro de validação será emitido.
- Quando definir uma relaçao muito-para-muitos de um modelo para ele mesmo, usando um modelo intermediário, você *deve* usar o [`symmetrical=False`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField.symmetrical) (veja [referência de campos de modelos](/pt-br/1.9/ref/models/fields/#manytomany-arguments)).

Agora que você definiu sua [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField)  para usar seu modelo intermediário (neste caso, `Membership`), você está pronto para começar a criar alguns relacionamentos muitos-para-muitos. Você faz isso criando instâncias do modelo intermediário.

```
>>> ringo = Person.objects.create(name="Ringo Starr")
>>> paul = Person.objects.create(name="Paul McCartney")
>>> beatles = Group.objects.create(name="The Beatles")
>>> m1 = Membership(person=ringo, group=beatles,
...     date_joined=date(1962, 8, 16),
...     invite_reason="Needed a new drummer.")
>>> m1.save()
>>> beatles.members.all()
[<Person: Ringo Starr>]
>>> ringo.group_set.all()
[<Group: The Beatles>]
>>> m2 = Membership.objects.create(person=paul, group=beatles,
...     date_joined=date(1960, 8, 1),
...     invite_reason="Wanted to form a band.")
>>> beatles.members.all()
[<Person: Ringo Starr>, <Person: Paul McCartney>]
```

Diferente dos campos muitos-para-muitos normais, você *não pode* usar `add`, `create` ou atribuições (isto é,  `beatles.members = [...]`) para criar relacionamentos:

```
# THIS WILL NOT WORK
>>> beatles.members.add(john)
# NEITHER WILL THIS
>>> beatles.members.create(name="George Harrison")
# AND NEITHER WILL THIS
>>> beatles.members = [john, paul, ringo, george]
```

Porque ? Você nã pode criar simplesmente um relacionamento entre um ```Person``e um ``Group``` \- você precisa especificar todos os detalhes requeridos para o relacionamento através do modelo `Membership`. O `add`, `create` e a chamadas para atribuições simples não fornecem um meio de especificar os detalhes extras. Como resultado, eles não estão habilitados para um relacionamento muitos-para-muitos que usam um modelo intermediário. A única maneira de criar este tipo de relacioanmento é criar instâncias do modelo intermediário.

O método [`remove()`](/pt-br/1.9/ref/models/relations/#django.db.models.fields.related.RelatedManager.remove) não está habilitado por razões similares. Contudo, o método [`clear()`](/pt-br/1.9/ref/models/relations/#django.db.models.fields.related.RelatedManager.clear) pode ser usado para remover todas os relacionamentos muitos-para-muitos de uma instância.

```
>>> # Beatles have broken up
>>> beatles.members.clear()
>>> # Note that this deletes the intermediate model instances
>>> Membership.objects.all()
[]
```

Uma vez que tenha estabelecido o relacionamento muitos-para-muitos através da criação do seu modelo intermediário, você pode fazer consultas. Tal como um relacionamento muitos-para-muitos normal, você pode fazer consultas usando os atributos do modelo muitos-para-muitos relacionado.

```
# Find all the groups with a member whose name starts with 'Paul'
>>> Group.objects.filter(members__name__startswith='Paul')
[<Group: The Beatles>]
```

Como está usando um modelo intemerdiário, você pode também fazer consultas em seus atributos:

```
# Find all the members of the Beatles that joined after 1 Jan 1961
>>> Person.objects.filter(
...     group__name='The Beatles',
...     membership__date_joined__gt=date(1961,1,1))
[<Person: Ringo Starr]
```

Se você precisa de acessar informações do membro você pode fazê-lo diretamente consultando o modelo `Membership`:

```
>>> ringos_membership = Membership.objects.get(group=beatles, person=ringo)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'
```

Outra maneira de acessa a mesma informação é através da consulta do [relacionamento muitos-para-muitos reverse](/pt-br/1.9/topics/db/queries/#m2m-reverse-relationships) de um objeto `Person`:

```
>>> ringos_membership = ringo.membership_set.get(group=beatles)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'
```

#### One-to-one relationships

Para definir um relacionamento um-para-um, use a [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField). Você pode usar como qualquer outro tipo `Field`: incluindo-o como um atributo de classe do seu modelo.

Isso é mais útil na chave-primária de um objeto quando este objeto “estende” um outro objeto de alguma maneira.

A [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) requer um argumento posicional: a classe com a qual o modelo é relacionado.

Por exemplo, se você estiver construindo um banco  de dados de “places”, você pode construir coisas bem padrão tal como endereços, número de telefone, etc. no banco de dados. Então se quiser construir um banco de dados de restaurantes  baseado nos lugares, ao invés de repetir a si mesmo e replicar aqueles campos no modelo `Restaurant`, você pode fazer `Restaurant` ter um [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) para `Place` ( porque um restaurante “é um” lugar; de fato, para lidar com isso você poderia tipicamente usar [herança](#model-inheritance), a qual envolve uma relação um-para-um implícita).

Assim como a [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey), um [relacionamento recursivo](/pt-br/1.9/ref/models/fields/#recursive-relationships) pode ser definido e [referencia a modelos ainda não definidos](/pt-br/1.9/ref/models/fields/#lazy-relationships) pode ser feita.

> **See also**
>
> Veja [exemplo de modelo com relacionamento um-para-um](/pt-br/1.9/topics/db/examples/one_to_one/) para um exemplo completo.

Os campos [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) também aceitam um argumento opcional [`parent_link`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField.parent_link).

Classes [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) usados para automaticamente se tornar a chave-primária de um modelo. Isso não e mais verdade (embora você possa passar manualmente no argumento attr:~django.db.models.Field.primary\_key se quiser). Então, agora é possível ter múltiplos campos de tipos [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) em um único modelo.

### Modelos através de arquivos

É perfeitamente OK relacionar um modelo de uma aplicação com outro. Para fazer isso, importe o modelo relacionado baseado no início do arquivo onde seu modelo está definido. Então, apenas referencie ao outra classe de modelo onde precisar. Por exemplo:

```
from django.db import models
from geography.models import ZipCode

class Restaurant(models.Model):
    # ...
    zip_code = models.ForeignKey(
        ZipCode,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )
```

### Restrições de nomes de campos

O Django coloca somente duas restrições sobre os nomes dos campos de modelo:

1. Um nome de campo não pode ser uma palavra-reservada do Python, porque isso poderia resultar em um erro de syntax Python. Por exemplo:

   ```
   class Example(models.Model):
       pass = models.IntegerField() # 'pass' is a reserved word!
   ```
2. Um nome de campo não pode conter mais de um “underscore” em uma linha, devido a maneira como a sintaxe dos filtros de pesquisa do Django funcionam.

   ```
   class Example(models.Model):
       foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
   ```

Essas limitações podem ser contornadas, embora, porque seu nome de campo não tem que combinar necessariamente com os nomes de colunas dos banco de dados. Veja a opção  [`db_column`](/pt-br/1.9/ref/models/fields/#django.db.models.Field.db_column).

Palavras-reservadas SQL, tal como `join`, `where` ou `select`, *são* permitidas como um nome de campos de modelo, porque o Django escapa todos os nomes de colunas e tabelas do banco de dados em cada consulta SQL. Ele usa a sintaxe citada do “engine” do seu banco de dados em particular.

### Tipos de campo personalizados

Se um dos campos de modelo existentes não pode ser usado para atender seus propósitos, ou se você deseja tirar vantagem de algum tipo de coluna de banco de dados menos comum, você pode criar sua própria classe de campo. Uma cobertura completa de criar seus próprios campos é fornecido em [Escrevendo campos personalizados de modelos.](/pt-br/1.9/howto/custom-model-fields/).

## Opções `Meta`

Dê ao seu modelo meta-dados usando uma `class Meta` interna, como segue:

```
from django.db import models

class Ox(models.Model):
    horn_length = models.IntegerField()

    class Meta:
        ordering = ["horn_length"]
        verbose_name_plural = "oxen"
```

Meta-dado de modelo é “qualquer coisa que não é um campo”, assim como opções de ordenamento ([`ordering`](/pt-br/1.9/ref/models/options/#django.db.models.Options.ordering)), nome da tabela do banco de dados  ([`db_table`](/pt-br/1.9/ref/models/options/#django.db.models.Options.db_table)), ou nomes legíveis plural e singular ([`verbose_name`](/pt-br/1.9/ref/models/options/#django.db.models.Options.verbose_name) and [`verbose_name_plural`](/pt-br/1.9/ref/models/options/#django.db.models.Options.verbose_name_plural)). Nenhum é requierido, e adicionar `class Meta` ao seu modelo é completamente opcional.

Uma lista completa de todos as opções `Meta` possíveis pode ser encontrada na [referência de opções de modelo](/pt-br/1.9/ref/models/options/).

## Atributos de modelo

**`objetos`**

  O atributo mais importante de uma classe de modelo é o [`Manager`](/pt-br/1.9/topics/db/managers/#django.db.models.Manager). Ele é a interface através da qual o operações de consultas no banco de dados são fornecidas aos modelos do Django e usadas para [retornar instâncias de modelos](/pt-br/1.9/topics/db/queries/#retrieving-objects) do banco de dados. Se nenhum `Manager` personalizado é definido, o nome padrão é [`objects`](/pt-br/1.9/ref/models/class/#django.db.models.Model.objects). Os “managers” somente são acessíveis através de classes de modelos, não por instâncias de de modelos.

## Métodos de Modelos

Defina métodos personalizados em um modelo para adicionar funcionalidade de “nível de linha” personalizado a seus objetos. Enquanto que os métodos [`Manager`](/pt-br/1.9/topics/db/managers/#django.db.models.Manager) são para coisas para “toda a tabela”, métodos de modelos devem agir sobre uma intância de modelo em particular.

Esta é uma técnica valiosa para manter a lógica de negócios em um único lugar – o modelo.

Por exemplo, este modelo tem alguns poucos métodos personalizados:

```
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    birth_date = models.DateField()

    def baby_boomer_status(self):
        "Returns the person's baby-boomer status."
        import datetime
        if self.birth_date < datetime.date(1945, 8, 1):
            return "Pre-boomer"
        elif self.birth_date < datetime.date(1965, 1, 1):
            return "Baby boomer"
        else:
            return "Post-boomer"

    def _get_full_name(self):
        "Returns the person's full name."
        return '%s %s' % (self.first_name, self.last_name)
    full_name = property(_get_full_name)
```

O último métodos neste exemplo é uma [propriedade](/pt-br/1.9/glossary/#term-property).

A [refrência de instância de modelo](/pt-br/1.9/ref/models/instances/) tem um lista completa de [métodos automaticamente dados a cada modelos](/pt-br/1.9/ref/models/instances/#model-instance-methods). Você pode sobrescrever a maioria deles – veja [sobrescrevendo métodos pré-definidos de modelo](#overriding-predefined-model-methods), abaixo – mas existem alguns que você irá quase sempre querer definir:

**[`__str__()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.__str__) (Python 3)**

  Um “método mágico” que retorna a “representação” em unicode de qualquer objeto. Este é o que o Python e o Django irão usar onde uma instância de modelo precisar ser mostrada como uma string. Mais notávelmente, isso acontece quando você mostra umobjeto em um console interativo ou no “admin”.

  Você sempre irá querer definir este método; o padrão em geral não ajuda muito.

**`__unicode__()` (Python 2)**

  O equivalente para Python 2 de `__str__()`.

**[`get_absolute_url()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.get_absolute_url)**

  Este dia ao Django como calcular a URL de um objeto. O Django usa isso na sua interface do “admin” e a qualquer momento que ele precisa descobrir a URL de um objeto.

  Qualquer objeto que tem um URL que o identifica unicamente deve definir este método.

### Sobrescrevendo métodos pré-definidos de modelo.

Existe um outro conjunto de [métodos de modelos](/pt-br/1.9/ref/models/instances/#model-instance-methods) que encapsulam vários comportamentos ligados ao banco de dados que você irá querer personalizar. EM particu;ar você irá querer muitas vezes alterar a maneira que o [`save()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.save) e [`delete()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.delete) funcionam.

Você é livre para sobrescrever estes métodos (e qualquer outro método de modelo) para alterar o comportamento.

Um caso de uso clássico para sobrescrever métodos embutidos é se você quiser que algo aconteça quando salvar um objeto. Por exemplo (veja [`save()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.save) para a documentaçao dos parâmetros que ele aceita):

```
from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, *args, **kwargs):
        do_something()
        super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.
        do_something_else()
```

Você pode também evitar salvar:

```
from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, *args, **kwargs):
        if self.name == "Yoko Ono's blog":
            return # Yoko shall never have her own blog!
        else:
            super(Blog, self).save(*args, **kwargs) # Call the "real" save() method.
```

É importante lembrar de chamar o método da super-classe – que é o porque do super(Blog, self).save(args, kwargs)\` – para ter certeza que o objeto ainda será persistido no banco de dados. Se você esquecer de chamar o método da super-classe, o comportamento padrão não acontecerá e nunca chegará ao banco de dados.

É importante também que você passe os argumentos que podem ser passados para o método do modelo que é o que as partes \*args, \*\*kwargs fazem. O Django irá, de vez enquando, estender as capacidades dos métodos embutidos de modelo, adicionando novos argumento. Se você usar `*args, **kwargs` nas definições de seus métodos, você está garantido que seu código ira automaticamente da suporte a estes argumentos quando forem adicionados.

> **Métodos de modelos sobrescritos não são chamados em operações em massa.**
>
> Note que o métodos [`delete()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.delete)  não é necessariamente chamado quando [deletar objetos em massa usando QUerySet](/pt-br/1.9/topics/db/queries/#topics-db-queries-delete) ou como resultado de uma [`deleção em cascata`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.on_delete). Para se assegurar que a lógica de um “delete” personalizado será executada, você pode usar os sinais  [`pre_delete`](/pt-br/1.9/ref/signals/#django.db.models.signals.pre_delete) e/ou [`post_delete`](/pt-br/1.9/ref/signals/#django.db.models.signals.post_delete) signals.
>
> Infelizmente não tem uma solução alternativa quando o [`creating`](/pt-br/1.9/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create) ou [`updating`](/pt-br/1.9/ref/models/querysets/#django.db.models.query.QuerySet.update) objetos em massa, já que nenhum dos [`save()`](/pt-br/1.9/ref/models/instances/#django.db.models.Model.save), [`pre_save`](/pt-br/1.9/ref/signals/#django.db.models.signals.pre_save), e [`post_save`](/pt-br/1.9/ref/signals/#django.db.models.signals.post_save) são chamados.

### Executando SQL personalizado

Um outro padrão comum é escrever comandos SQL personalizados em métodos de modelos e métodos no nível do módulo. Para mais detalhes sobre usar SQL puro, veja a documentação no [usando SQL puro](/pt-br/1.9/topics/db/sql/).

## Herança de modelo

A herança de modelo no Django funciona quase idêntico a maneira que herança de classes normais no Python, mas o básico do início da página ainda deve ser seguido. Isso significa que c classe base deve ser uma subclasse de [`django.db.models.Model`](/pt-br/1.9/ref/models/instances/#django.db.models.Model).

A única decisão que você tem tomar é se você quer que os modelos pais sejam modelos por eles mesmos (com suas próprias tabelas de banco de dados), ou se os modelos parentes são somente para manter informações comuns que somente serão vistas através de seus modelos filhos.

Existem três estilos de herança que possíveis em Django.

1. Muitas vezes, você quer somente usar uma classe pai para manter informação que você não quer ter que escrever para cada modelo filho. Essa classe nunca será usada isoladamente, então o que você quer é uma [Classes abstratas base](#abstract-base-classes)
2. Se você estiver herdando um modelo existente (talvez algo de uma outra aplicação inteira) e quer que cada modelo tenha sua própria tabela de banco de dados, o [Herança de múltiplas tabelas](#multi-table-inheritance) é o caminho.
3. Finalmente, se você quer modificar o comportamento no nível do Python de um modelo, sem mudar os campos do modelo de nenhuma maneira, você pode usar os [Modelos Proxy](#proxy-models).

### Classes abstratas base

Classes abstratas base são úteis quando você quer colocar alguma informação comum em vários outros modelos. Você escreve sua classe base e coloca `abstract=True` na classe in the [Meta](#meta-options). Este modelo não será então usado para criar nenhuma tabela de banco de dados. Ao invés disso, quando é usado como classe base para outros modelos, seus campos serão adicionados àqueles das classes filhas. É um erro ter campos de classes abstratas base com o mesmo nome daqueles da classe filha (e o Django irá emitir uma exceção).

Um exemplo:

```
from django.db import models

class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True

class Student(CommonInfo):
    home_group = models.CharField(max_length=5)
```

O modelo `Student` terá três campos: `name`, `age` e `home_group`. O modelo `CommonInfo`   não pode ser usado como um modelo normal do Django, já que é uma classe abstrata base. Ele não gera uma tabela de banco de dados nem tem um “manager”, e não pode ser instânciado ou salvo diretamente.

Em muitos casos, este tipo de herança de modelo será exatamente o que quer.  Isso lhe fornece uma maneira de fatorar informações comuns ao nível do Python, enquanto cainda cria somente uma tabela de banco de dados para cada modelo filho no nível banco de dados.

#### Herança `Meta`

QUando um modelo abstrato básico é criado, o Django com que qualquer classe [Meta](#meta-options) interna que você declare na classe base fique disponível como um atributo. Se a classe filha não declare sua própria classe [Meta](#meta-options) , ela irá herdar as  [Meta](#meta-options) da pai. Se a filho quer estender a classe  [Meta](#meta-options)  da pai, ele pode herdá-la. Por exemplo:

```
from django.db import models

class CommonInfo(models.Model):
    # ...
    class Meta:
        abstract = True
        ordering = ['name']

class Student(CommonInfo):
    # ...
    class Meta(CommonInfo.Meta):
        db_table = 'student_info'
```

O Django faz um ajuste a classe [Meta](#meta-options) de uma classe abstrata base: antes de instalar o atributo [Meta](#meta-options), ele definie abstract=False\`. Isso significa que filhos de uma classe abstrata base não se tornam automaticamente uma classe abstrata. Claro, você pode fazer uma classe abstrata que herda de outra abstrata. Você só precisa se lembrar a cada vez de explicitamente definir `abstract=True`.

Alguns atributos não farão sentido incluir na classe [Meta](#meta-options) de uma classe abstrata base. Por exemplo, incluir `db_table` poderia siginificar que todas as classes filhos (aquelas que não especificarem seus próprios [Meta](#meta-options)) poderiam usar a mesma tabela, o que é quase certo que não é o que você quer.

#### Tenha cuidado com o `related_name`

Se estiver usando o atributo [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name) em uma `ForeignKey` ou `ManyToManyField`, você deve sempre especificar um nome reverso *único*   para o campo. Isso normalmente poderia causar um problema na classe abstrata base, já que os campos desta classe são incluídos em cada classe filho, com exatamente os mesmos valores para os atributos (incluindo o [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name)) cada vez.

Para contornar este problema, quando você estiver usando um [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name) em uma classe abstrata base (somente), parte do nome deve conter o `'%(app_label)s'` e a `'%(class)s'`.

- A `'%(class)s'` é substituída pelo nome em minúsculas da classe filha onde o campo é usado.
- `'%(app_label)s'` é substituída pelo nome em minúsculas da aplicação onde a classe está contida. Cada nome de aplicação instalada deve ser único e os nomes das classes de modelo dentro de cada aplicação deve ser único também, desta maneira o nome resultante acabará sendo diferente.

Por exemplo, dado uma aplicação `common/models.py`:

```
from django.db import models

class Base(models.Model):
    m2m = models.ManyToManyField(OtherModel, related_name="%(app_label)s_%(class)s_related")

    class Meta:
        abstract = True

class ChildA(Base):
    pass

class ChildB(Base):
    pass
```

Junta com uma outra aplicação `rare/models.py`:

```
from common.models import Base

class ChildB(Base):
    pass
```

O nome reverso do campo `common.ChildA.m2m` será `common_childa_related`, enquanto que o nome reverso do campo `common.ChildB.m2m` será `common_childb_related`, e finalmente o nome reverso do campo `rare.ChildB.m2m` será `rare_childb_related`. Você decide como usar as partes `'%(class)s'` e `'%(app_label)s` para construir seus nomes relacionados, mas se esquecer de usá-los, o Django irá emitir erros quando você executar verificações de sistema (ou executar [`migrate`](/pt-br/1.9/ref/django-admin/#django-admin-migrate)).

Se você não especificar um atributo [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name) para um campo campo na classe abstrata, o nome reverso padrão será o nomde da classe filha seguido por `'_set'`, tal como seria normalmente se o campo fosse declarado diratamente na classe filha. Por exemplo, no código acima, se o atributo [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name) fosse omitido, o nome reverso para o campo `m2m` seriaa `childa_set` no caso `ChildA` e `childb_set` para o campo `ChildB`.

### Herança de múltiplas tabelas

O segundo tipo de heraná de modelo que o Django suporta é quando cada modelo na hierarquia é um modelo completo. Cada modelo corresponder a sua própria tabele de banco de dados e pode ser consultado e criado individualmente. A herança de relacionamento introduz conexões entre a classe filho e cada um de seus parentes (através de um [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) criado automaticamente). Por exemplo:

```
from django.db import models

class Place(models.Model):
    name = models.CharField(max_length=50)
    address = models.CharField(max_length=80)

class Restaurant(Place):
    serves_hot_dogs = models.BooleanField(default=False)
    serves_pizza = models.BooleanField(default=False)
```

Todos os campos de ```Place``estarão disponíveis no ``Restaurant```, embora os dados residirão em tabelas diferentes dos banco de dados. Então estes são ambos possíveis.

```
>>> Place.objects.filter(name="Bob's Cafe")
>>> Restaurant.objects.filter(name="Bob's Cafe")
```

Se você tive um `Place` que é também um `Restaurant`, você pode ir do objeto `Place` ao objeto `Restaurant` usando a versão em minúsculo do nome do modelo:

```
>>> p = Place.objects.get(id=12)
# If p is a Restaurant object, this will give the child class:
>>> p.restaurant
<Restaurant: ...>
```

Todavia, se `p` no exemplo acima *não* é um `Restaurant` (ele foi criado diretamente como um objeto `Place` ou era um pai de uma alguma outra classe), referenciar `p.restaurant` poderia emitir uma exceção `Restaurante.DoeNotExist`.

#### `Meta` e herança de tabelas múltiplas

Na situação de herança de multi-tabelas , faz sentido para uma classe filho herdar de seu pai a classe [Meta](#meta-options). Todas as opções [Meta](#meta-options) já foram aplicadas a  classe pai aplicar novamente poderia normalmente levar a um comprtamento contraditório (isso em contrate com o caso da classe abstrata base, onde a classe base não existe por sí só).

Então um modelo filho não tem acesso a classe [Meta](#meta-options) do seu pai. Porém, existem alguns poucos casos onde o filho herda comportamento do pai: se o filho não especifica um atributo [`ordering`](/pt-br/1.9/ref/models/options/#django.db.models.Options.ordering) ou um atributo [`get_latest_by`](/pt-br/1.9/ref/models/options/#django.db.models.Options.get_latest_by), ele herdará isso dos seu pai.

Se o pai tem um ordenação e você não quer que o filho tenha qualquer ordem natural, você pode explicitamente desabilitar isso:

```
class ChildModel(ParentModel):
    # ...
    class Meta:
        # Remove parent's ordering effect
        ordering = []
```

#### Herança e relações reversas

Porque herança de multi-tabelas usa um [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField)  implícita para  relacionar o filho com o pai, é possível mover do pai para o filho, como no exemplo acima. Porém,   usa-se o nome que é padrão value do [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name)   para [`ForeignKey`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey) e relções [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField). Se você está colocando estes tipos de relações em uma subclasse do modelo pai, você **deve** especificar o atributo  [`related_name`](/pt-br/1.9/ref/models/fields/#django.db.models.ForeignKey.related_name) em cada campo deste. Se você esquecer, o Django irá emitir um erro de validação.

Por exemplo, usando novamente a classe `Place` acima, vamos criar outra subclasse com um [`ManyToManyField`](/pt-br/1.9/ref/models/fields/#django.db.models.ManyToManyField):

```
class Supplier(Place):
    customers = models.ManyToManyField(Place)
```

Isso resulta no erro:

```
Reverse query name for 'Supplier.customers' clashes with reverse query
name for 'Supplier.place_ptr'.

HINT: Add or change a related_name argument to the definition for
'Supplier.customers' or 'Supplier.place_ptr'.
```

Adicionando `related_name` ao campo `customers` como segue poderia resolver o erro: `models.ManyToManyField(Place, related_name='provider')`.

#### Especificando o campo de relacão do pai

Como mencionado, o Django criará automaicamente uma relação [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) para sua classe filho devolta para quaisquer modelos não abstratos. Se quiser controlar o nome do atributo de relacionamento devolta para o pai, você pode criar seu próprio [`OneToOneField`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField) e definir [`parent_link=True`](/pt-br/1.9/ref/models/fields/#django.db.models.OneToOneField.parent_link) para indicar que seu campo é a conexão de reotorno com a classe pai.

### Modelos Proxy

Quando se usa [herança de tabelas multiplas](#multi-table-inheritance), uma nova tabela de banco de dados é criada para cada subclasse do modelo. Este é o comportamento desejável, já que a subclasse precisa de um lugar para armazenar qualquer campo de dado adicional que não esteja presente na classe base. As vezes, entretanto, você quer somente mudar o comportamento Python do modelo – talvez para alterar o “manager” padrão do modelo, ou adicionar um método novo.

É para isso que serve o modelo “proxy”: criar um *proxy* para o modelo original. Você pode criar, deletar e editar instâncias do modelo “proxy” e todas os dados serão salvos como se você estivesse usando o modelo original (não “proxy”). A diferença, é que você pode alterar coisas como a ordenação padrão do modelo ou o “manager” padrão no “proxy”, sem ter que alterar o original.

Modelos “Proxy” são declarados como os modelos normais. Você diz ao Django que este é um modelo “proxy” definindo o atributo [`proxy`](/pt-br/1.9/ref/models/options/#django.db.models.Options.proxy) na classe `Meta` como `True`.

Por exemplo, suponha que queira adicionar um método ao modelo `Person`. Você pode fazê-lo assim:

```
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

class MyPerson(Person):
    class Meta:
        proxy = True

    def do_something(self):
        # ...
        pass
```

A classe `MyPerson` opera na mesma tabela que sua classe pai `Person`. Em particular, qualquer nova instância de `Person` irá também ser acessível através de `MyPerson`, e vice-versa:

```
>>> p = Person.objects.create(first_name="foobar")
>>> MyPerson.objects.get(first_name="foobar")
<MyPerson: foobar>
```

Você pode também usar um modelo “proxy” para definir um ordenação padrão diferente em um modelo. Talvez você não queira sempre ordenar o modelo ```Person`, mas regularmente ordenar pelo atributo ``last_name``` quando usar o “proxy”. Isso é fácil:

```
class OrderedPerson(Person):
    class Meta:
        ordering = ["last_name"]
        proxy = True
```

Agora consultas normais ao `Person` serão não ordenadas e consultas ao `OrderedPerson` serão ordenadas pelo `last_name`.

#### `QuerySet`s  ainda retornam o modelo que foi requisitado

Não te uma maneira do Django retornar, vamos dizer, um objeto `MyPerson` quando consultar por objetos `Person`. Uma consulta em objetos `Person` irá retornar aquele tipo de objetos. O ponto de objetos “proxy” é que o código que está no `Person` original irá usar este código e seu próprio código pode usar as estensões que foram incluídas (que nenhum outro código depende de nenhuma forma). Esta não é uma maneira de substituir o modelo `Person` (ou nenhum outro) em nenhum lugar com alguma coisa criada por você mesmo.

#### Restições de classes base

Um modelo “proxy” deve herdar de exatamente um modelo não abstrato. Você não pode herdae de múltimplos modelos não abstratos já que o modelo “proxy” não fornece qualquer conexão entre os registros de diferentes tabelas do banco de dados. Um modelo “proxy” pode herdar de qualquer número de classes abstratas de  modelos, desde que *não* definam nenhum campo de modelo.

#### “Managers” de modelos “proxy”

Se você não especificar um “manager” do modelo no modelo “proxy”, ele herda o “manager” de seu modelo pai. Se você definir um “manager” no modelo “proxy”, este será o padrão, embora qualquer “manager” definido nas classes pai ainda estarão disponíveis.

Continuando nosso exemplo acima, você pode mudar o “manager” padrão usado quando você fizer uma consulta ao modelo `Person` assim:

```
from django.db import models

class NewManager(models.Manager):
    # ...
    pass

class MyPerson(Person):
    objects = NewManager()

    class Meta:
        proxy = True
```

Se você quiser adicionar um novo “manager” ao “Proxy”, sem substituir o padrão existente, você pode usar as técnicas descritas na documentação [“manager” personalizado](/pt-br/1.9/topics/db/managers/#custom-managers-and-inheritance) : crie uma classe base contendo os novos “managers” e herde esta depois da classe base primária:

```
# Create an abstract class for the new manager.
class ExtraManagers(models.Model):
    secondary = NewManager()

    class Meta:
        abstract = True

class MyPerson(Person, ExtraManagers):
    class Meta:
        proxy = True
```

Você provavelmente não precisa fazer isso muitas vezes, mas, quando precisar, é possível.

#### Differences between proxy inheritance and unmanaged models

Herança de modelo “proxy” talvez se pareça com criar um modelo não gerenciado, usando o atributo [`managed`](/pt-br/1.9/ref/models/options/#django.db.models.Options.managed) na classe `Meta` do modelo. As duas alternativas não são necessariamente a mesma coisa e vale a pena considerar qual delas você deveria usar.

Uma diferença é que você pode (e, de fato deve, a menos que você queira um modelo vazio) especificar campos de modelos no modelo com `Meta.managed=False`. Você poderia, definir com cuidado o [`Meta.db_table`](/pt-br/1.9/ref/models/options/#django.db.models.Options.db_table) para que crie um modelo não gerenciado que seja similar ao modelo existente e adicionar métodos Python nele. Porém, isso seria muito repetitivo e frágil já que precisaria manter ambas as cópias sincronizadas se fizer alguma mudança.

A outra diferença que é ainda mais importante para modelos “proxy”, é como os “managers” do modelo são manipulados. Modelos do tipo “proxy” tendem a se comportar exatamente como o modelo do qual é “proxy”. QUer dizer que herdam o “manager” do modelo pai, incluindo o “manager” padrão. Em um caso normal de herança de de modelos de tabelas múltiplas, filhos não herdam os “managers” dos seus pais já que “managers” personalizados nem sempre são apropriados quando envolve campos extras. A  documentação de [referência de “manager”](/pt-br/1.9/topics/db/managers/#custom-managers-and-inheritance) tem mais detalhes sobre este último caso.

Quando estas duas características foram implementadas, houveram tentativas de se unificá-las em uma única opção. Descobriu-se que a interações com herança, em geral, e particularmente com “managers”, fazem a API muito complexa e potencialmente difícil de entender e usar. Descobriu-se que duas opções eram necessárias emqualquer caso, então a separação corrente veio a tona.

Então, as regras gerais são:

1. Se você esta espelhando um modelo existente ou uma tabela de banco de dados e nao quer todas as colunas originarias do banco de dados, use `Meta.managed=False`. Esta opção é normalmente útil para modelos “views” e tabelas de bancos de dados que não estão sob o controle do Django.
2. Se voc^está querendo alterar o modelo somente quanto seu comportamento Python, más manter todos os mesmos campos como no original, use  `Meta.proxy=True`. Estas defini as coisas tal que o modelo “proxy” é uma cópia exata da estrutura de armazenamento do modelo original quando o dado são salvos.

### Herança Múltimpla

Tal como é fazer uma subclasse em Python, é possível para um modelo Django herdar múltiplos modelos pai. Tenha em mente que as regras de resolução de nomes Python se aplicam. A primeira classe base que um nome em particular  (e.g. [Meta](#meta-options))  aparece será a classe usada; por exemplo, isso significa que se múltimplos pais contém uma classe [Meta](#meta-options), somente a primeira é que será usada, e todas as outras ignoradas.

Geralmente, você não vai precisar herdar de múltiplos pais. O principal caso onde isso é útil é para classes “mix-in”: adicionar um campo extra em particular ou método para ada classe que herda o “mix-in”. Tente manter sua hierarquia de herança tão simples e direta quanto possível, assim você não tem que lutar para descobrir de onde está vindo uma parte particuar da informação.

Perceba que herdar de múltimplos modelos que tem em comum um campo ìd\` como chave-primária irá emitir um erro. Para usar heraná múltipla de maneira correta, você pode usar explicitamente a [`AutoField`](/pt-br/1.9/ref/models/fields/#django.db.models.AutoField) no modelo base:

```
class Article(models.Model):
    article_id = models.AutoField(primary_key=True)
    ...

class Book(models.Model):
    book_id = models.AutoField(primary_key=True)
    ...

class BookReview(Book, Article):
    pass
```

Ou use um acestral comum para manter a [`AutoField`](/pt-br/1.9/ref/models/fields/#django.db.models.AutoField):

```
class Piece(models.Model):
    pass

class Article(Piece):
    ...

class Book(Piece):
    ...

class BookReview(Book, Article):
    pass
```

### O nome de campo “hiding” não é permitido.

Em uma herança de classe normal em Python, é permitido a um filho que sobrescreva qualquer atributo de uma classe pai. No Django, isso não é permitido fazer para atributos que são instâncias da [`Field`](/pt-br/1.9/ref/models/fields/#django.db.models.Field) (pelo menos, não no momento). Se uma classe base tem um campo chamado `author`, você não pode criar outro campo de modelo chamado `author` em qualquer classe que herde a classe base.

Sobrescrever campos em um modelo pai leva a dificuldades em áreas como a inicialização de novas instâncias (especificar qual campo está sendo inicializado no `Model.__init__`) e serialização. Estas são características que classes Python normais não tem que lidar do mesmo modo, isso quer dizer que a diferença entre herança de modelos Django e herança de classes Python não são arbitrárias.

A restrição somente se aplica a atributos os quais são instâncias de [`Field`](/pt-br/1.9/ref/models/fields/#django.db.models.Field). Atributos normais de Python podem ser sobrescritos se quiser. Isos também só se aplica para os nomes de atributos com o Python os vê. Se você está manualmente especificando o nome da coluna do banco de dados, você pode ter o mesmo nome de coluna aparecendo em ambos, um filho e em um modelo ancestral para heraná de múltiplas tabelas (elas são solunas em duas diferentes tabelas de banco de dados).

O Django irá emitir uma [`FieldError`](/pt-br/1.9/ref/exceptions/#django.core.exceptions.FieldError) se você sobrescrever qualquer campo de modelo de qualquer modelo ancestral.

## Organizing models in a package

The [`manage.py startapp`](/pt-br/1.9/ref/django-admin/#django-admin-startapp) command creates an application
structure that includes a `models.py` file. If you have many models,
organizing them in separate files may be useful.

To do so, create a `models` package. Remove `models.py` and create a
`myapp/models/` directory with an `__init__.py` file and the files to
store your models. You must import the models in the `__init__.py` file.

For example, if you had `organic.py` and `synthetic.py` in the `models`
directory:

*myapp/models/__init__.py*

```
from .organic import Person
from .synthetic import Robot
```

Explicitly importing each model rather than using `from .models import *`
has the advantages of not cluttering the namespace, making code more readable,
and keeping code analysis tools useful.

> **See also**
>
> **[Referência sobre Modelos](/pt-br/1.9/ref/models/)**
>
>   Cobre toda a API relacionada com modelo incluindo campos de modelo, objetos relacionais, e `QuerySet`.