多対一のリレーション¶

多対一のリレーションを定義するには ForeignKey を使います。このフィールドは他 のフィールド型と同じように、モデルのクラス属性に含めて使えます。

ForeignKey には、固定引数が一つあり、リレー ションを張る対象のクラスを指定します。

例えば、 Car モデルに Manufacturer というフィールドを持たせたいとし ましょう。すなわち、ある Manufacturer には複数の Car が対応するが、 各 Car には一つだけ Manufacturer が対応するようにしたいとしましょう。 この場合、以下のように定義します:

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

class Car(models.Model):
    manufacturer = models.ForeignKey(Manufacturer)
    # ...

再帰的リレーション (自分自身に対する多対多 のリレーション) や、 未定義のモデルに対するリレーション も定義できます。 モデルフィールドのリファレンス を参照してください。

必須ではありませんが、 ForeignKey の名前 (上の例では manufacturer) には、モデル名を小文字にしたものを使うよう勧 めます。もちろん好きな名前を付けてもかまいません。例えば:

class Car(models.Model):
    company_that_makes_it = models.ForeignKey(Manufacturer)
    # ...

ForeignKey フィールドは、リレーションの動作を定 義するための引数をいくつかとれます。各引数は モデルフィールドのリファレンス で解説してい ます。そうした引数を使うと、リレーションのふるまいを定義する上で役に立ちま す。引数は全てオプションです。

多対多のリレーション¶

多対多の (many-to-many) リレーションを定義するには ManyToManyField を使います。このフィール ドは他のフィールド型と同じように、モデルのクラス属性に含めて使えます。

ManyToManyField には固定引数が一つあり、 リレーションを張る対象のクラスを指定します。

例えば、 Pizza には複数の Topping オブジェクトを持たせられます。 すなわち、ある Topping は複数のピザの上に置けて、逆にそれぞれのピザには 複数のトッピングを置けるというわけです。このリレーションを表すには次のように します:

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

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

ForeignKey と同様、 再帰的リレーション (自分自身に対する多対一のリレーション) や、 未定義のモデルに対するリレーション も定義できま す。 モデルフィールドのリファレンス を参照してくだ さい。

必須ではありませんが、 ManyToManyField の 名前 (上の例では toppings)は、リレーション先のモデル名の複数形にするよ う勧めます。

どちらのモデルで ManyToManyField を定義し てもかまいませんが、どちらか片方のモデルにしか必要ありません -- 両方には指 定できません。

一般的に、 Django の admin を使っている場合、 ManyToManyField インスタンスを入れておく のは、 admin インタフェースで編集される側のオブジェクトにしておきます。上の 例では、 topping は (Topping に ManyToManyField の pizzas をもたせる のではなく) Pizza に入れておきます。というのも、「トッピングを乗せるピ ザ」と考えるよりも「ピザの上に乗せるトッピング」を考える方が自然だからです。 こうして上の例では、 Pizza の admin フォームでユーザにトッピングを選ば せることになります。

ManyToManyField フィールドは、リレーションの動作 を定義するための引数をいくつかとれます。各引数は モデルフィールドのリ ファレンス で解説しています。引数は全てオプション です。

多対多を定義するためのエクストラフィールド¶

ピザとトッピングを組み合わせたり照合したりするだけのような多対多のリレーショ ンを扱いたいのなら、標準の ManyToManyField で事 足ります。しかし、時として、二つのモデルのリレーションそのものにデータを関 連づけたい場合があります。

例えば、ミュージシャンのグループと、在籍しているミュージシャンを追跡するア プリケーションのケースを考えてみましょう。これは個人 (person) とグループの 関係なので、 ManyToManyField でリレーションを表 現できるはずです。しかし、ミュージシャンとグループの関係には、あるミュージ シャンがあるグループにいつ合流したか、のような細かい情報がたくさんあります。

こうした状況を解決するために、 Django では、多対多のリレーションを定義する ときに、あらかじめリレーションを管理するためのモデル(中間モデル)を定義して おき、その中間モデルに向けてエクストラフィールド (extra field) を組み込めま す。中間モデルは ManyToManyField の through 引数に指定します。ミュージシャン の例では、コードは以下のように表されます:

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

    def __unicode__(self):
        return self.name

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

    def __unicode__(self):
        return self.name

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

中間モデルでは、多対多のリレーションの両側にあたるモデルに対して明示的に外 部キーを張らねばなりません。この明示的な定義によってはじめて、モデルのリレー ションが宣言されます:

中間モデルには、いくつか制約があります:

• 中間モデルは、多対多リレーションのターゲットモデル (リレーションを張 られる側のモデル) に対する外部キーを 一つだけ しか定義できません (上の例では Person ですね)。同じモデルに複数の外部キーを定義する と、モデルのバリデーション時にエラーを送出します。
• 中間モデルは、多対多リレーションのソースモデル (リレーションを張る側 のモデル) に対する外部キーを 一つだけ しか定義できません (上の例で は Group ですね)。同じモデルに複数の外部キーを定義すると、モデル のバリデーション時にエラーを送出します。
• 自分自身に対する多対多のリレーションを定義するのに中間モデルを使う場 合にのみ、例外的に同じモデルに対するリレーションを二つ定義できます。 ただし、多対多リレーションの中では、二つの外部キーは別々、すなわちソー スとターゲットを区別して扱います。
• 中間モデルを使って、あるモデルから自分自身に多対対のリレーションを定 義する場合、 symmetrical=False を指定せねばなりません ( モデルフィールドのリファレンス を参照してください) 。

さて、これで中間モデル (例でいうところの Membership) を使った ManyToManyField を設定したので、多対多のリレーショ ンを生成できます。リレーションの生成は、中間モデルのインスタンス生成によっ て実現します:

>>> 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>]

通常の ManyToManyField と違い、 add や create, (beatles.members = [...] のような) 代入によるリレーションの定義 は行えません:

# 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]

なぜでしょうか。中間モデルでリレーションを作成すると、単に Person と Group の間のリレーションを生成するだけではなく、 Membership テーブ ルに必要な全ての情報が必要です。単に add や create を呼び出したり 代入を行うだけでは、リレーション以外の情報を埋められません。その結果、中間 モデルを使う場合は、 add や create は無効化されるのです。中間モデル を使った多対多のリレーションを定義するには、中間モデルのインスタンスを生成 するしかない、ということを覚えておいてください。

同じ理由で、 remove メソッドも無効化されています。ただし、 clear() メソッドを使えば、以下のように多対多のリレーションを一括して消去できます:

# Beatles have broken up
>>> beatles.members.clear()

中間のモデルを使って多対多のリレーションを確立したら、リレーションをまたい だクエリを実行できます。通常の多対多リレーションと同じく、リレーション先の モデルの属性を使ってクエリを実行します:

# 'Paul' で始まる名前の人がメンバにいるグループを探す
>>> Groups.objects.filter(person__name__startswith='Paul')
[<Group: The Beatles>]

中間テーブルを使っているので、中間のモデルの属性を使ったクエリも実行できま す:

# 1961年1月1日以降に合流した Beatles のメンバを探す
>>> Person.objects.filter(
...     group__name='The Beatles',
...     membership__date_joined__gt=date(1961,1,1))
[<Person: Ringo Starr]

一対一のリレーション¶

一対一のリレーションを定義するには、 OneToOneField を使います。このフィールド は他のフィールド型と同じように、モデルのクラス属性に含めて使えます。

このリレーションがもっとも有用なのは、あるオブジェクトが別のオブジェクトを 何らかの形で「拡張」している場合の主キーとして使う場合です。

OneToOneField には固定引数が一つあり、リ レーションを張る対象のクラスを指定します。

例えば、「場所 (place)」のデータベースを作るときには、アドレス、電話番号、 といった標準的なものを作成します。その上で、レストランデータベースを作成 するときに、 Restaurant モデルの中に同じフィールドをつくるような 繰り返し作業 (repeat yourself) をする代わりに、場所データベースを基盤にして レストランのデータベースを作成したいとしましょう。このとき、 Restaurant には Place への OneToOneField をもた せられます (レストランは場所に対して "is-a" の関係だからです。実際には、こ のような状況を扱うのに モデルの継承 を使いますが、 モデル継承は OneToOneField で実現されてい ます)。

ForeignKey と同様、 再帰的リレーション や 未定義のモデルに対するリレーション も定義できま す。詳しくは モデルフィールドのリファレンス を参照してください。

OneToOneField フィールドは、オプションの引数を一 つとります。引数は モデルフィールドリファレンス で解 説しています。

以前は、モデル中で OneToOneField を使うと、 そのフィールドは自動的にモデルの主キーになっていました。この仕様はもうなく なりましたが、主キーにしたければ手動で primary_key に指定できます。この 変更により、一つのモデル中で複数の OneToOneField を使えるようになりました。

Meta の継承¶

抽象ベースクラスを作成するとき、 Django は抽象ベースクラスの内部クラス Meta をクラス属性として参照できるようにします。子クラ スで Meta クラスを定義しない場合、親クラスの Meta がそのまま継承されます。子クラスで Meta を拡張したければ、親クラスをサブクラス化できます。 以下に例を示しましょう:

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

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

Django は抽象ベースクラスの Meta クラスを生成するとき に一つだけ手を加えます。すなわち、 Meta の属性を組み 込む前に、 abstract=False を設定するのです。これにより、抽象ベースクラ スの子クラスが自動的に非抽象ベースクラスになります。もちろん、他の抽象ベー スクラスを継承した新たな抽象ベースクラスも定義できます。継承するには、明示 的に abstract=True をセットしてください。

Meta クラスの属性の中には、抽象ベースクラスで定義して も意味のないものもあります。例えば、 db_table を抽象ベースクラスの Meta で定義すると、その子クラス全て (で、独自に Meta を定義しないもの) が、同じデータベーステーブルを 使おうとしてしまいます。

related_name に注意¶

ForeignKey や ManyToManyField に related_name 属性 を使っている場合には、フィールドの 一意な 逆リレーション名を指定してくだ さい。抽象ベースクラスのフィールドは (related_name の設定値を含み) 子クラス にそのまま組み込まれるので、 子クラスで同じ related_name のフィールドができてしま うため、問題を引き起こします。

この問題を回避するには、抽象ベースクラスで related_name を使うときに(かつその時に 限り)、文字列の一部に '%(class)s' を付加してください。そうすると、 '%(class)s' は子クラスでクラスの小文字名に置き換えられます。各クラスは 個別の名前をもっているので、結果的にリレーション名は個別の名前に なります。例えば:

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

    class Meta:
        abstract = True

class ChildA(Base):
    pass

class ChildB(Base):
    pass

この例で、 ChildA.m2m フィールドの逆リレーション名は childa_related になり、 ChildB.m2m フィールドの逆リレーション名は childb_related になります。逆リレーション名の定義で '%(class)s' をどう使うかはユーザ次 第ですが、 '%(class)s' を使いわすれると、モデルの検証時 (または syncdb 時) に例外を送出します。

抽象ベースクラスのフィールドに related_name 属性を指定しない場合、子クラスの名前に '_set' をつけた名前をデフォルト の逆リレーション名として使います。これは子クラスで直接リレーションフィール ドを定義した場合と同じ挙動です。例えば、上のコードで related_name 属性を省略すると、 m2m フィールドの逆リレーション名は ChildA では childa_set 、 ChildB では childb_set です。

Meta とマルチテーブル継承¶

マルチテーブル継承では、子クラスが親クラスの Meta ク ラスを継承する意味がありません。 Meta オプションは全 て親クラスだけに適用されるべきもので、他のクラスに同じ内容を適用しても、矛 盾した振る舞いを引き起こすだけです(これは、独自のテーブルを持たない抽象ベー スクラスと対照的な部分です)。

従って、マルチテーブル継承の子クラスは親クラスの Meta クラスにアクセスする方法を持ちません。ただし、限られたケースで、子クラスが 親クラスの挙動を継承する場合があります。それは、子クラスで django.db.models.Options.ordering または django.db.models.Options.get_latest_by 属性を指定していない場合に、 親クラスの属性を継承するというものです。

親クラスで整列カラムが指定されていて、子クラス側で整列カラムを指定したくな い場合は、明示的に空の整列カラムを指定してください:

class ChildModel(ParentModel):
    ...
    class Meta:
        # 親クラスの整列カラム設定の効果を除去する
        ordering = []

継承と逆リレーション¶

マルチテーブル継承は親クラスと子クラスを暗黙の OneToOneField でリンクするので、前述の例 のように、親クラスから子クラスをたどれます。しかし、子クラスをたどるときに 使う名前は、 ForeignKey や ManyToManyField リレーションを定義したと きのデフォルトの related_name と同じ値 を使っています。従って、子クラスで ForeignKey や ManyToManyField を別のクラスに向けて張る ときには、 必ず related_name をフィー ルドに指定せねばなりません。指定し忘れると、 Django は manage.py validate や syncdb 時にエラーを 送出します。

例えば、上の Place クラスに対して、 ManyToManyField を持った別のサブクラスを 定義するには、以下のように書きます:

class Supplier(Place):
    # Must specify related_name on all relations.
    customers = models.ManyToManyField(Restaurant,
            related_name='provider')

親クラスのリンクフィールドを定義する¶

すでに触れたように、 Django は子クラスと抽象クラスでない親クラスにリンクし た OneToOneField を自動的に生成します。親 クラスへのリンク名を操作したければ、自分で OneToOneField を作成し、パラメタに parent_link=True を渡してください。