Lets suppose there's a database schema defined like this:

    Person.mail_address_key ----- Address.address_key
    Person.billing_address_key ----- Address.address_key

A `Person` has a mailing address and a billing address.  As a denormalization technique, we create a separate `Address` table.  Most of the time the `mail_address_key` and the `billing_address_key` of a single `Person` will be the same value (ie: their mailing and billing address key will be the same).  

In my *database* the `Address` has an identity (the address key).  But, *in my domain model*, I don't see a compelling reason for the `Address` to be an Entity, I'd like it to be a Value Object.  

1. In DDD, is this an option? Or are Value Objects usually a group of columns (as opposed to a table)?  I'm kind of playing the devil's advocate here, because I don't think the database should dictate the domain model structure, but just making sure.
1. If so, where/when/how does the address lose its database identity so it can be used as a Value Object in the Domain Layer?  Or, am I supposed to keep the database identifier in the Value Object?
1. When the model needs to be persisted in the database, what's the process?  Am I supposed to go through a process of a) Find an address by these fields, b) if it doesn't exist, create a new one c) if it does, update the fields?