Should I define a FOREIGN KEY column as NULLable? I've been developing some database structure to cover the following business rules:

An invoice has many invoice_items.
An invoice may have many refunds
A refund has many invoice_items.
All items should be from the same invoice.
A refund should always have items.

So I came up with the entity-relationship diagram (ERD) shown bellow:

I'd like to see which invoice_items are included in the refund.
However, in this case, it would not be possible to add a FOREIGN KEY (FK) (InvoiceItems =&gt; refunds). The reason is that an invoice may or may not have refunds.
So I modified the diagram as follows:

Here I could add the FK (refund_invoice_items =&gt; invoice_items)
Questions
I think this can work around the FK problem, so: Do you think this is an appropriate approach or have any ideas about it?
The main question is that if I could store NULL marks in the FK column, the first example would be better? (In my case I always add NOT NULL constraint to columns defined as FKs)
Yes.  Relationships (in ER modeling) can be optional.  There is no better way to represent a non-existent relationship in a foreign key than by putting in a NULL.  When you do a join, exactly the right thing happens.  When you do  a count, exactly the right thing happens.  

The only reason to make a foreign key not NULLable is to make the relationship mandatory.  This rule might come from the subject matter, as captured by an ER model.  It depends on the situation.

In the question you posed, you already had a case of an optional relationship.  Not all invoices have any refunds.