では、has_aを設定したらMakerインスタンスの中身はどう変わるのか、ビューテンプレートを修正して確認しましょう。「views」内の「makers」内にある「index.html.erb」を開き、その中のメーカーを一覧表示しているテーブルの部分を下のリスト欄にあるように修正してください。修正したら、 http://localhost:3000/makers にアクセスして表示を確認しましょう。各メーカーのところに、そのメーカーの製品情報（製品名とメモ）が１点だけ追加表示されるようになっています。

この情報は、makersテーブルにはありませんgoodsテーブルにあるものです。つまりここでは、makersのテーブルを取り出し、各レコードのメーカーの製品情報を１つだけgoodsから取り出してきて表示する――といったことをRailsがやってくれているわけですね。（実際には、データベースにあるJOINという機能でまとめて取り出しているのですが……）

index.html.erbで、この部分を見てみると、以下のように値を取り出していることがわかります。

    <td><% if maker.good != nil %>
        <b><%= maker.good.name %></b><br>
        <%= maker.good.memo %>
    <% end %></td>

if maker.good != nil で、makerのgoodというプロパティがカラかどうかをチェックしています。そしてカラでなければ、maker.good.nameと、maker.good.memoの値を書き出しています。これらからだいたい想像がつくとおり、このmaker.goodには、関連するGoodインスタンスが保管されているのです。

アソシエーションでは、このように関連するレコードの情報が、そのモデル名のプロパティに保管されます。has_aは「対応する１つだけ」が関連付けられますから、ここではgoodプロパティに関連するGoodインスタンスが割り当てられていたのです。そのインスタンスから、nameやmemoの値を取り出していたのですね。

ここでは、メーカーと製品というように、必ずしも１対１ではないものから１つだけを取り出していますが、こういう「１対１で対応する」という関係はけっこうあるものです。例えば、今の例の逆から考えると、「商品とメーカー」は１対１の関係ですね（メーカーと商品ではなくて）。本と作者、社員と所属部署などもそうでしょう。こうした１対１で対応するものを扱うのにhas_aは役立ちます。

※views/makers/index.html.erbのテーブル部分の修正

<table>
  <tr>
    <th>Name</th>
    <th>Site</th>
    <th>Memo</th>
    <th>Goods</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @makers.each do |maker| %>
  <tr>
    <td><%= maker.name %></td>
    <td><%= maker.site %></td>
    <td><%= maker.memo %></td>
    <td><% if maker.good != nil %>
        <b><%= maker.good.name %></b><br>
        <%= maker.good.memo %>
    <% end %></td>
    <td><%= link_to 'Show', maker %></td>
    <td><%= link_to 'Edit', edit_maker_path(maker) %></td>
    <td><%= link_to 'Destroy', maker, method: :delete, data: { confirm: 'Are you sure?' } %></td>
  </tr>
<% end %>
</table>