Relax, you've already solved the problem. Any "child" table always contains the key of its "parent" table(s) in each row - the customer and items in this case - because that is how the relationship between different tables is implemented.
So your ItemPurchaseTable has the right structure. This approach is sometimes called an "intersection table", and the idea is to allow you to link data from two other tables (which have a "many-to-many" relationship) via their primary keys, which is exactly what you've done here. The customer ID is the foreign key to your customers table, and the item is the foreign key to your items table, and you need both of these in order to match a customer to the items the customer purchased in the current month.
You should probably define
foreign key constraints, which will ensure that you can't add items to the Item Purchase table if they have a non-existent customer ID/item ID, and the FK constraint can also stop you deleting customers/items while they still have records in this table.
Make sure you name your columns properly e.g. in your Item Purchases table, you should make it clear that the "ITEM" column contains the ITEMID.
You should also name your tables properly. Don't call a table "ItemPurchase
Table", because we already know it's a table. And don't call a table "customer
db", because tables live
inside a database. Different places use different conventions for table names, but it's common just to use the plural of whatever they contain e.g. CUSTOMERS, ITEM_PURCHASES etc.
As you've solved the problem of creating your intersection table, I suggest you take a little time to review the basics of relational data modelling, how to derive the 3rd normal form entities (tables) for your data model, how relationships are implemented via foreign keys etc.
PS: Some relational databases do in fact allow you to store multiple items inside a single column, but this is generally a PITA because sooner or later you discover lots of extra attributes you'd like to add to this "nested table", and it's much easier to do this if they're in a proper relational table e.g. suppose you wanted to record the date_purchased against your ItemPurchases.