Marketing Mailing List Database

Marketing databases for mailing marketing materials can have many possible forms. When designing a database like this, consider the questions you want to answer and let it guide you.

Many businesses rely on mailing lists to identify potential new customers or existing customers for marketing campaigns. Frequently an application might use a zip code to narrow down a national search for customers. Which zip codes are most likely to have customers for our products or service? Also which addresses have the ideal number of occupants for our campaign? If a marketing firm uses census figures or other marketing intelligence to correlate demographic data to zip codes, the following database design can be used. There should be some flexibility in how data is entered for example, allow for address data entry before knowing the names of the occupants. State address can be either is 2 character state codes or fully spelled out.

Figure 1 Occupants, addresses and zip code demographic data (ms access)

In the above design, note that an OccupantsAddresses linking table is used to identify occupants located at an address. One address may have one or more occupants. This is reflected in the database design above. But, it is possible that an address may be temporarily vacated due to fire, construction or renovation. It is possible no occupants can be registered in an address for a time period. In the above design, ms-access describes a one-to-many relationship. However, if an address has zero occupants this database design will allow it as well.

Additionally, note how the ZipID field in address links to the Zipcodes table. In that case a single code can have many addresses. A benefit of this design is that if the zip code numbers ever change we don’t have to update the address table, we can instead just update the zip fields of the Zipcodes table.

Likewise, having a separate State table allows us to change the State field however we want without updating the address table. For example, we can use a two digit state or just spell it out fully. This allows us better maintenance and flexibility.

In the above diagram, a demographic data point showing Household Income is described as a left outer join from Zipcodes to the Householdincome table. The type of join is as follows: “Include ALL records from ‘Zipcodes’ and only those records from ‘Householdincome’ where the joined fields are equal.” This outer join exists because, in our design, we can imagine that it is possible some income data may not exist for certain zip codes. For each zip code there may be zero or one householdincome records.