path: root/files/ja/learn/server-side/django/models/index.html

---
title: 'Django チュートリアル Part 3: モデルの使用'
slug: Learn/Server-side/Django/Models
translation_of: Learn/Server-side/Django/Models
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Server-side/Django/skeleton_website", "Learn/Server-side/Django/Admin_site", "Learn/Server-side/Django")}}</div>

<p class="summary">この記事では、LocalLibrary Web サイトのモデルを定義する方法を説明します。モデルとは何か、その宣言方法、および主要なフィールドタイプについて説明します。また、モデルデータにアクセスするための主な方法のいくつかについても簡単に説明します。</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">前提条件:</th>
   <td><a href="/ja/docs/Learn/Server-side/Django/skeleton_website">Django チュートリアル Part 2: Web サイトの骨組み作成</a>.</td>
  </tr>
  <tr>
   <th scope="row">目標:</th>
   <td>適切なフィールドを選択しながら、独自のモデルを設計および作成できるようになる。</td>
  </tr>
 </tbody>
</table>

<h2 id="概要">概要</h2>

<p>Django web applications access and manage data through Python objects referred to as models. Models define the <em>structure</em> of stored data, including the field <em>types</em> and possibly also their maximum size, default values, selection list options, help text for documentation, label text for forms, etc. The definition of the model is independent of the underlying database — you can choose one of several as part of your project settings. Once you've chosen what database you want to use, you don't need to talk to it directly at all — you just write your model structure and other code, and Django handles all the dirty work of communicating with the database for you.</p>

<p>This tutorial shows how to define and access the models for the <a href="/ja/docs/Learn/Server-side/Django/Tutorial_local_library_website">LocalLibrary website</a> example.</p>

<h2 id="Designing_the_LocalLibrary_models">Designing the LocalLibrary models</h2>

<p>Before you jump in and start coding the models, it's worth taking a few minutes to think about what data we need to store and the relationships between the different objects.</p>

<p>We know that we need to store information about books (title, summary, author, written language, category, ISBN) and that we might have multiple copies available (with globally unique id, availability status, etc.). We might need to store more information about the author than just their name, and there might be multiple authors with the same or similar names. We want to be able to sort information based on book title, author, written language, and category.</p>

<p>When designing your models it makes sense to have separate models for every "object" (a group of related information). In this case, the obvious objects are books, book instances, and authors.</p>

<p>You might also want to use models to represent selection-list options (e.g. like a drop down list of choices), rather than hard coding the choices into the website itself — this is recommended when all the options aren't known up front or may change. Obvious candidates for models, in this case, include the book genre (e.g. Science Fiction, French Poetry, etc.) and language (English, French, Japanese).</p>

<p>Once we've decided on our models and field, we need to think about the relationships. Django allows you to define relationships that are one to one (<code>OneToOneField</code>), one to many (<code>ForeignKey</code>) and many to many (<code>ManyToManyField</code>).</p>

<p>With that in mind, the UML association diagram below shows the models we'll define in this case (as boxes).</p>

<p><img alt="LocalLibrary Model UML" src="https://mdn.mozillademos.org/files/16479/local_library_model_uml.png" style="height: 660px; width: 977px;"></p>

<p>We've created models for the book (the generic details of the book), book instance (status of specific physical copies of the book available in the system), and author. We have also decided to have a model for the genre so that values can be created/selected through the admin interface. We've decided not to have a model for the <code>BookInstance:status</code> — we've hardcoded the values (<code>LOAN_STATUS</code>) because we don't expect these to change. Within each of the boxes, you can see the model name, the field names, and types, and also the methods and their return types.</p>

<p>The diagram also shows the relationships between the models, including their <em>multiplicities</em>. The multiplicities are the numbers on the diagram showing the numbers (maximum and minimum) of each model that may be present in the relationship. For example, the connecting line between the boxes shows that Book and a Genre are related. The numbers close to the Genre model show that a book must have one or more Genres (as many as you like), while the numbers on the other end of the line next to the Book model show that a Genre can have zero or many associated books.</p>

<div class="note">
<p><strong>Note</strong>: The next section provides a basic primer explaining how models are defined and used. As you read it, consider how we will construct each of the models in the diagram above.</p>
</div>

<h2 id="Model_primer">Model primer</h2>

<p>This section provides a brief overview of how a model is defined and some of the more important fields and field arguments.</p>

<h3 id="Model_definition">Model definition</h3>

<p>Models are usually defined in an application's <strong>models.py</strong> file. They are implemented as subclasses of <code>django.db.models.Model</code>, and can include fields, methods and metadata. The code fragment below shows a "typical" model, named <code>MyModelName</code>:</p>

<pre>from django.db import models

class MyModelName(models.Model):
    """A typical class defining a model, derived from the Model class."""

    # Fields
    my_field_name = models.CharField(max_length=20, help_text='Enter field documentation')
    ...

    # Metadata
    class Meta:
        ordering = ['-my_field_name']

    # Methods
    def get_absolute_url(self):
        """Returns the url to access a particular instance of MyModelName."""
        return reverse('model-detail-view', args=[str(self.id)])

    def __str__(self):
        """String for representing the MyModelName object (in Admin site etc.)."""
        return self.my_field_name</pre>

<p>In the below sections we'll explore each of the features inside the model in detail:</p>

<h4 id="Fields">Fields</h4>

<p>A model can have an arbitrary number of fields, of any type — each one represents a column of data that we want to store in one of our database tables. Each database record (row) will consist of one of each field value. Let's look at the example seen below:</p>

<pre class="brush: js">my_field_name = models.CharField(max_length=20, help_text='Enter field documentation')</pre>

<p>Our above example has a single field called <code>my_field_name</code>, of type <code>models.CharField</code> — which means that this field will contain strings of alphanumeric characters. The field types are assigned using specific classes, which determine the type of record that is used to store the data in the database, along with validation criteria to be used when values are received from an HTML form (i.e. what constitutes a valid value). The field types can also take arguments that further specify how the field is stored or can be used. In this case we are giving our field two arguments:</p>

<ul>
 <li><code>max_length=20</code> — States that the maximum length of a value in this field is 20 characters.</li>
 <li><code>help_text='Enter field documentation'</code> — provides a text label to display to help users know what value to provide when this value is to be entered by a user via an HTML form.</li>
</ul>

<p>The field name is used to refer to it in queries and templates. Fields also have a label, which is either specified as an argument (<code>verbose_name</code>) or inferred by capitalising the first letter of the field's variable name and replacing any underscores with a space (for example <code>my_field_name</code> would have a default label of <em>My field name</em>).</p>

<p>The order that fields are declared will affect their default order if a model is rendered in a form (e.g. in the Admin site), though this may be overridden.</p>

<h5 id="Common_field_arguments">Common field arguments</h5>

<p>The following common arguments can be used when declaring many/most of the different field types:</p>

<ul>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#help-text">help_text</a>: Provides a text label for HTML forms (e.g. in the admin site), as described above.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#verbose-name">verbose_name</a>: A human-readable name for the field used in field labels. If not specified, Django will infer the default verbose name from the field name.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#default">default</a>: The default value for the field. This can be a value or a callable object, in which case the object will be called every time a new record is created.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#null">null</a>: If <code>True</code>, Django will store blank values as <code>NULL</code> in the database for fields where this is appropriate (a <code>CharField</code> will instead store an empty string). The default is <code>False</code>.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#blank">blank</a>: If <code>True</code>, the field is allowed to be blank in your forms. The default is <code>False</code>, which means that Django's form validation will force you to enter a value. This is often used with <code>null=True</code> , because if you're going to allow blank values, you also want the database to be able to represent them appropriately.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#choices">choices</a>: A group of choices for this field. If this is provided, the default corresponding form widget will be a select box with these choices instead of the standard text field.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#primary-key">primary_key</a>: If <code>True</code>, sets the current field as the primary key for the model (A primary key is a special database column designated to uniquely identify all the different table records). If no field is specified as the primary key then Django will automatically add a field for this purpose.</li>
</ul>

<p>There are many other options — you can view the <a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#field-options">full list of field options here</a>.</p>

<h5 id="Common_field_types">Common field types</h5>

<p>The following list describes some of the more commonly used types of fields. </p>

<ul>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#django.db.models.CharField">CharField</a> is used to define short-to-mid sized fixed-length strings. You must specify the <code>max_length</code> of the data to be stored.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#django.db.models.TextField">TextField</a> is used for large arbitrary-length strings. You may specify a <code>max_length</code> for the field, but this is used only when the field is displayed in forms (it is not enforced at the database level).</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#django.db.models.IntegerField" title="django.db.models.IntegerField">IntegerField</a> is a field for storing integer (whole number) values, and for validating entered values as integers in forms.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#datefield">DateField</a> and <a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#datetimefield">DateTimeField</a> are used for storing/representing dates and date/time information (as Python <code>datetime.date</code> in and <code>datetime.datetime</code> objects, respectively). These fields can additionally declare the (mutually exclusive) parameters <code>auto_now=True</code> (to set the field to the current date every time the model is saved), <code>auto_now_add</code> (to only set the date when the model is first created) , and <code>default</code> (to set a default date that can be overridden by the user).</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#emailfield">EmailField</a> is used to store and validate email addresses.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#filefield">FileField</a> and <a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#imagefield">ImageField</a> are used to upload files and images respectively (the <code>ImageField</code> simply adds additional validation that the uploaded file is an image). These have parameters to define how and where the uploaded files are stored.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#autofield">AutoField</a> is a special type of <code>IntegerField</code> that automatically increments. A primary key of this type is automatically added to your model if you don’t explicitly specify one.</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#foreignkey">ForeignKey</a> is used to specify a one-to-many relationship to another database model (e.g. a car has one manufacturer, but a manufacturer can make many cars). The "one" side of the relationship is the model that contains the "key" (models containing a "foreign key" referring to that "key", are on the "many" side of such a relationship).</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#manytomanyfield">ManyToManyField</a> is used to specify a many-to-many relationship (e.g. a book can have several genres, and each genre can contain several books). In our library app we will use these very similarly to <code>ForeignKeys</code>, but they can be used in more complicated ways to describe the relationships between groups. These have the parameter <code>on_delete</code> to define what happens when the associated record is deleted (e.g. a value of <code>models.SET_NULL</code> would simply set the value to <code>NULL</code>).</li>
</ul>

<p>There are many other types of fields, including fields for different types of numbers (big integers, small integers, floats), booleans, URLs, slugs, unique ids, and other "time-related" information (duration, time, etc.). You can view the <a href="https://docs.djangoproject.com/en/2.1/ref/models/fields/#field-types">full list here</a>.</p>

<h4 id="Metadata">Metadata</h4>

<p>You can declare model-level metadata for your Model by declaring <code>class Meta</code>, as shown.</p>

<pre class="brush: python">class Meta:
    ordering = ['-my_field_name']
</pre>

<p>One of the most useful features of this metadata is to control the <em>default ordering</em> of records returned when you query the model type. You do this by specifying the match order in a list of field names to the <code>ordering</code> attribute, as shown above. The ordering will depend on the type of field (character fields are sorted alphabetically, while date fields are sorted in chronological order). As shown above, you can prefix the field name with a minus symbol (-) to reverse the sorting order.</p>

<p>So as an example, if we chose to sort books like this by default:</p>

<pre class="brush: python">ordering = ['title', '-pubdate']</pre>

<p>the books would be sorted alphabetically by title, from A-Z, and then by publication date inside each title, from newest to oldest.</p>

<p>Another common attribute is <code>verbose_name</code>, a verbose name for the class in singular and plural form:</p>

<pre class="brush: python">verbose_name = 'BetterName'</pre>

<p>Other useful attributes allow you to create and apply new "access permissions" for the model (default permissions are applied automatically), allow ordering based on another field, or to declare that the class is "abstract" (a base class that you cannot create records for, and will instead be derived from to create other models).</p>

<p>Many of the other metadata options control what database must be used for the model and how the data is stored (these are really only useful if you need to map a model to an existing database).</p>

<p>The full list of metadata options are available here: <a href="https://docs.djangoproject.com/en/2.1/ref/models/options/">Model metadata options</a> (Django docs).</p>

<h4 id="Methods">Methods</h4>

<p>A model can also have methods.</p>

<p><strong>Minimally, in every model you should define the standard Python class method <code>__str__()</code> to return a human-readable string for each object.</strong> This string is used to represent individual records in the administration site (and anywhere else you need to refer to a model instance). Often this will return a title or name field from the model.</p>

<pre class="brush: python">def __str__(self):
    return self.field_name</pre>

<p>Another common method to include in Django models is <code>get_absolute_url()</code>, which returns a URL for displaying individual model records on the website (if you define this method then Django will automatically add a "View on Site" button to the model's record editing screens in the Admin site). A typical pattern for <code>get_absolute_url()</code> is shown below.</p>

<pre class="brush: python">def get_absolute_url(self):
    """Returns the url to access a particular instance of the model."""
    return reverse('model-detail-view', args=[str(self.id)])
</pre>

<div class="note">
<p><strong>Note</strong>: Assuming you will use URLs like <code>/myapplication/mymodelname/2</code> to display individual records for your model (where "2" is the <code>id</code> for a particular record), you will need to create a URL mapper to pass the response and id to a "model detail view" (which will do the work required to display the record). The <code>reverse()</code> function above is able to "reverse" your url mapper (in the above case named <em>'model-detail-view'</em>) in order to create a URL of the right format.</p>

<p>Of course to make this work you still have to write the URL mapping, view, and template!</p>
</div>

<p>You can also define any other methods you like, and call them from your code or templates (provided that they don't take any parameters).</p>

<h3 id="Model_management">Model management</h3>

<p>Once you've defined your model classes you can use them to create, update, or delete records, and to run queries to get all records or particular subsets of records. We'll show you how to do that in the tutorial when we define our views, but here is a brief summary.</p>

<h4 id="Creating_and_modifying_records">Creating and modifying records</h4>

<p>To create a record you can define an instance of the model and then call <code>save()</code>.</p>

<pre class="brush: python"># Create a new record using the model's constructor.
record = MyModelName(my_field_name="Instance #1")

# Save the object into the database.
record.save()
</pre>

<div class="note">
<p><strong>Note</strong>: If you haven't declared any field as a <code>primary_key</code>, the new record will be given one automatically, with the field name <code>id</code>. You could query this field after saving the above record, and it would have a value of 1.</p>
</div>

<p>You can access the fields in this new record using the dot syntax, and change the values. You have to call <code>save()</code> to store modified values to the database.</p>

<pre class="brush: python"># Access model field values using Python attributes.
print(record.id) # should return 1 for the first record.
print(record.my_field_name) # should print 'Instance #1'

# Change record by modifying the fields, then calling save().
record.my_field_name = "New Instance Name"
record.save()</pre>

<h4 id="Searching_for_records">Searching for records</h4>

<p>You can search for records that match certain criteria using the model's <code>objects</code> attribute (provided by the base class).</p>

<div class="note">
<p><strong>Note</strong>: Explaining how to search for records using "abstract" model and field names can be a little confusing. In the discussion below we'll refer to a <code>Book</code> model with <code>title</code> and <code>genre</code> fields, where genre is also a model with a single field <code>name</code>.</p>
</div>

<p>We can get all records for a model as a <code>QuerySet</code>, using <code>objects.all()</code>. The <code>QuerySet</code> is an iterable object, meaning that it contains a number of objects that we can iterate/loop through.</p>

<pre class="brush: python">all_books = Book.objects.all()
</pre>

<p>Django's <code>filter()</code> method allows us to filter the returned <code>QuerySet</code> to match a specified <strong>text</strong> or <strong>numeric</strong> field against particular criteria. For example, to filter for books that contain "wild" in the title and then count them, we could do the following.</p>

<pre class="brush: python">wild_books = Book.objects.filter(title__contains='wild')
number_wild_books = wild_books.count()
</pre>

<p>The fields to match and the type of match are defined in the filter parameter name, using the format: <code>field_name__match_type</code> (note the <em>double underscore</em> between <code>title</code> and <code>contains</code> above). Above we're filtering <code>title</code> with a case-sensitive match. There are many other types of matches you can do: <code>icontains</code> (case insensitive), <code>iexact</code> (case-insensitive exact match), <code>exact</code> (case-sensitive exact match) and <code>in</code>, <code>gt</code> (greater than), <code>startswith</code>, etc. The <a href="https://docs.djangoproject.com/en/2.1/ref/models/querysets/#field-lookups">full list is here</a>.</p>

<p>In some cases you'll need to filter on a field that defines a one-to-many relationship to another model (e.g. a <code>ForeignKey</code>). In this case you can "index" to fields within the related model with additional double underscores. So for example to filter for books with a specific genre pattern, you will have to index to the <code>name</code> through the <code>genre</code> field, as shown below:</p>

<pre class="brush: python"># Will match on: Fiction, Science fiction, non-fiction etc.
books_containing_genre = Book.objects.filter(genre<strong>__</strong>name<strong>__</strong>icontains='fiction')
</pre>

<div class="note">
<p><strong>Note</strong>: You can use underscores (__) to navigate as many levels of relationships (<code>ForeignKey</code>/<code>ManyToManyField</code>) as you like. For example, a <code>Book</code> that had different types, defined using a further "cover" relationship might have a parameter name: <code>type__cover__name__exact='hard'.</code></p>
</div>

<p>There is a lot more you can do with queries, including backwards searches from related models, chaining filters, returning a smaller set of values etc. For more information see <a href="https://docs.djangoproject.com/en/2.1/topics/db/queries/">Making queries</a> (Django Docs).</p>

<h2 id="Defining_the_LocalLibrary_Models">Defining the LocalLibrary Models</h2>

<p>In this section we will start defining the models for the library. Open <em>models.py (in /locallibrary/catalog/)</em>. The boilerplate at the top of the page imports the <em>models</em> module, which contains the model base class <code>models.Model</code> that our models will inherit from.</p>

<pre class="brush: python">from django.db import models

# Create your models here.</pre>

<h3 id="Genre_model">Genre model</h3>

<p>Copy the <code>Genre</code> model code shown below and paste it into the bottom of your <code>models.py</code> file. This model is used to store information about the book category — for example whether it is fiction or non-fiction, romance or military history, etc. As mentioned above, we've created the Genre as a model rather than as free text or a selection list so that the possible values can be managed through the database rather than being hard coded.</p>

<pre class="brush: python">class Genre(models.Model):
    """Model representing a book genre."""
    name = models.CharField(max_length=200, help_text='Enter a book genre (e.g. Science Fiction)')

    def __str__(self):
        """String for representing the Model object."""
        return self.name</pre>

<p>The model has a single <code>CharField</code> field (<code>name</code>), which is used to describe the genre (this is limited to 200 characters and has some <code>help_text</code>. At the end of the model we declare a <code>__str__()</code> method, which simply returns the name of the genre defined by a particular record. No verbose name has been defined, so the field will be called <code>Name</code> in forms.</p>

<h3 id="Book_model">Book model</h3>

<p>Copy the Book model below and again paste it into the bottom of your file. The book model represents all information about an available book in a general sense, but not a particular physical "instance" or "copy" available for loan. The model uses a <code>CharField</code> to represent the book's <code>title</code> and <code>isbn</code> (note how the <code>isbn</code> specifies its label as "ISBN" using the first unnamed parameter because the default label would otherwise be "Isbn"). The model uses <code>TextField</code> for the <code>summary</code>, because this text may need to be quite long.</p>

<pre class="brush: python">from django.urls import reverse # Used to generate URLs by reversing the URL patterns

class Book(models.Model):
    """Model representing a book (but not a specific copy of a book)."""
    title = models.CharField(max_length=200)

    # Foreign Key used because book can only have one author, but authors can have multiple books
    # Author as a string rather than object because it hasn't been declared yet in the file
    author = models.ForeignKey('Author', on_delete=models.SET_NULL, null=True)

    summary = models.TextField(max_length=1000, help_text='Enter a brief description of the book')
    isbn = models.CharField('ISBN', max_length=13, help_text='13 Character &lt;a href="https://www.isbn-international.org/content/what-isbn"&gt;ISBN number&lt;/a&gt;')

    # ManyToManyField used because genre can contain many books. Books can cover many genres.
    # Genre class has already been defined so we can specify the object above.
    genre = models.ManyToManyField(Genre, help_text='Select a genre for this book')

    def __str__(self):
        """String for representing the Model object."""
        return self.title

    def get_absolute_url(self):
        """Returns the url to access a detail record for this book."""
        return reverse('book-detail', args=[str(self.id)])
</pre>

<p>The genre is a <code>ManyToManyField</code>, so that a book can have multiple genres and a genre can have many books. The author is declared as <code>ForeignKey</code>, so each book will only have one author, but an author may have many books (in practice a book might have multiple authors, but not in this implementation!)</p>

<p>In both field types the related model class is declared as the first unnamed parameter using either the model class or a string containing the name of the related model. You must use the name of the model as a string if the associated class has not yet been defined in this file before it is referenced! The other parameters of interest in the <code>author</code> field are <code>null=True</code>, which allows the database to store a <code>Null</code> value if no author is selected, and <code>on_delete=models.SET_NULL</code>, which will set the value of the author to <code>Null</code> if the associated author record is deleted.</p>

<p>The model also defines <code>__str__()</code> , using the book's <code>title</code> field to represent a <code>Book</code> record. The final method, <code>get_absolute_url()</code> returns a URL that can be used to access a detail record for this model (for this to work we will have to define a URL mapping that has the name <code>book-detail</code>, and define an associated view and template).</p>

<h3 id="BookInstance_model">BookInstance model</h3>

<p>Next, copy the <code>BookInstance</code> model (shown below) under the other models. The <code>BookInstance</code> represents a specific copy of a book that someone might borrow, and includes information about whether the copy is available or on what date it is expected back, "imprint" or version details, and a unique id for the book in the library.</p>

<p>Some of the fields and methods will now be familiar. The model uses</p>

<ul>
 <li><code>ForeignKey</code> to identify the associated <code>Book</code> (each book can have many copies, but a copy can only have one <code>Book</code>).</li>
 <li><code>CharField</code> to represent the imprint (specific release) of the book.</li>
</ul>

<pre class="brush: python">import uuid # Required for unique book instances

class BookInstance(models.Model):
    """Model representing a specific copy of a book (i.e. that can be borrowed from the library)."""
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, help_text='Unique ID for this particular book across whole library')
    book = models.ForeignKey('Book', on_delete=models.SET_NULL, null=True)
    imprint = models.CharField(max_length=200)
    due_back = models.DateField(null=True, blank=True)

    LOAN_STATUS = (
        ('m', 'Maintenance'),
        ('o', 'On loan'),
        ('a', 'Available'),
        ('r', 'Reserved'),
    )

    status = models.CharField(
        max_length=1,
        choices=LOAN_STATUS,
        blank=True,
        default='m',
        help_text='Book availability',
    )

    class Meta:
        ordering = ['due_back']

    def __str__(self):
        """String for representing the Model object."""
        return f'{self.id} ({self.book.title})'</pre>

<p>We additionally declare a few new types of field:</p>

<ul>
 <li><code>UUIDField</code> is used for the <code>id</code> field to set it as the <code>primary_key</code> for this model. This type of field allocates a globally unique value for each instance (one for every book you can find in the library).</li>
 <li><code>DateField</code> is used for the <code>due_back</code> date (at which the book is expected to come available after being borrowed or in maintenance). This value can be <code>blank</code> or <code>null</code> (needed for when the book is available). The model metadata (<code>Class Meta</code>) uses this field to order records when they are returned in a query.</li>
 <li><code>status</code> is a <code>CharField</code> that defines a choice/selection list. As you can see, we define a tuple containing tuples of key-value pairs and pass it to the choices argument. The value in a key/value pair is a display value that a user can select, while the keys are the values that are actually saved if the option is selected. We've also set a default value of 'm' (maintenance) as books will initially be created unavailable before they are stocked on the shelves.</li>
</ul>

<p>The model <code>__str__()</code> represents the <code>BookInstance</code> object using a combination of its unique id and the associated <code>Book</code>'s title.</p>

<div class="note">
<p><strong>Note</strong>: A little Python:</p>

<ul>
 <li>Starting with Python 3.6, you can use the string interpolation syntax (also known as f-strings): <code>f'{self.id} ({self.book.title})'</code>.</li>
 <li>In older versions of this tutorial, we were using a <a href="https://www.python.org/dev/peps/pep-3101/">formatted string</a> syntax, which is also a valid way of formatting strings in Python (e.g. <code>'{0} ({1})'.format(self.id,self.book.title)</code>).</li>
</ul>
</div>

<h3 id="Author_model">Author model</h3>

<p>Copy the <code>Author</code> model (shown below) underneath the existing code in <strong>models.py</strong>.</p>

<pre class="brush: python">class Author(models.Model):
    """Model representing an author."""
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)
    date_of_birth = models.DateField(null=True, blank=True)
    date_of_death = models.DateField('Died', null=True, blank=True)

    class Meta:
        ordering = ['last_name', 'first_name']

    def get_absolute_url(self):
        """Returns the url to access a particular author instance."""
        return reverse('author-detail', args=[str(self.id)])

    def __str__(self):
        """String for representing the Model object."""
        return f'{self.last_name}, {self.first_name}'
</pre>

<p>All of the fields/methods should now be familiar. The model defines an author as having a first name, last name, and dates of birth and death (both optional). It specifies that by default the <code>__str__()</code> returns the name in <em>last name</em>, <em>firstname </em>order. The <code>get_absolute_url()</code> method reverses the <code>author-detail</code> URL mapping to get the URL for displaying an individual author.</p>

<h2 id="Re-run_the_database_migrations">Re-run the database migrations</h2>

<p>All your models have now been created. Now re-run your database migrations to add them to your database.</p>

<pre><code>python3 manage.py makemigrations
python3 manage.py migrate</code></pre>

<h2 id="Language_model_—_challenge">Language model — challenge</h2>

<p>Imagine a local benefactor donates a number of new books written in another language (say, Farsi). The challenge is to work out how these would be best represented in our library website, and then to add them to the models.</p>

<p>Some things to consider:</p>

<ul>
 <li>Should "language" be associated with a <code>Book</code>, <code>BookInstance</code>, or some other object?</li>
 <li>Should the different languages be represented using model, a free text field, or a hard-coded selection list?</li>
</ul>

<p>After you've decided, add the field. You can see what we decided on Github <a href="https://github.com/mdn/django-locallibrary-tutorial/blob/master/catalog/models.py">here</a>.</p>

<p>Don't forget that after a change to your model, you should again re-run your database migrations to add the changes.</p>

<pre><code>python3 manage.py makemigrations</code><code>
python3 manage.py migrate</code></pre>

<ul>
</ul>

<ul>
</ul>

<h2 id="Summary">Summary</h2>

<p>In this article we've learned how models are defined, and then used this information to design and implement appropriate models for the <em>LocalLibrary</em> website.</p>

<p>At this point we'll divert briefly from creating the site, and check out the <em>Django Administration site</em>. This site will allow us to add some data to the library, which we can then display using our (yet to be created) views and templates.</p>

<h2 id="See_also">See also</h2>

<ul>
 <li><a href="https://docs.djangoproject.com/en/2.1/intro/tutorial02/">Writing your first Django app, part 2</a> (Django docs)</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/topics/db/queries/">Making queries</a> (Django Docs)</li>
 <li><a href="https://docs.djangoproject.com/en/2.1/ref/models/querysets/">QuerySet API Reference</a> (Django Docs)</li>
</ul>

<p>{{PreviousMenuNext("Learn/Server-side/Django/skeleton_website", "Learn/Server-side/Django/Admin_site", "Learn/Server-side/Django")}}</p>



<h2 id="In_this_module">In this module</h2>

<ul>
 <li><a href="/ja/docs/Learn/Server-side/Django/Introduction">Django introduction</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/development_environment">Setting up a Django development environment</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Tutorial_local_library_website">Django Tutorial: The Local Library website</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/skeleton_website">Django Tutorial Part 2: Creating a skeleton website</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Models">Django Tutorial Part 3: Using models</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Admin_site">Django Tutorial Part 4: Django admin site</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Home_page">Django Tutorial Part 5: Creating our home page</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Generic_views">Django Tutorial Part 6: Generic list and detail views</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Sessions">Django Tutorial Part 7: Sessions framework</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Authentication">Django Tutorial Part 8: User authentication and permissions</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Forms">Django Tutorial Part 9: Working with forms</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Testing">Django Tutorial Part 10: Testing a Django web application</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/Deployment">Django Tutorial Part 11: Deploying Django to production</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/web_application_security">Django web application security</a></li>
 <li><a href="/ja/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
</ul>