First, great job on the beta release of the store module.  The templating method should be used as a model for all other modules.

I have some concerns on the data object model that I think may limit the store in some future scenarios. 

In general, my main concern is the use of PortalID as a foriegn key on most of the tables.  This implies a portal can only have one store.  I can easily see use cases where someone might want multiple stores on the same portal.  I can also see use cases where someone would want to implement the same store (with same products) on multiple portals. 

"Store" is the business object.  Therefore, StoreID should be the primary/foreign key. 

You could still impose the 1 portal/1store concept if you want to by creating a 1-1 relation table of Portal<->Store.  However, by structuring the DB to reflect the real business objects, you at least open up the possibility for someone else to implement the store differently, ie. 1 store / many portals.  I personally have a use case where I need to implement the exact same store on about 60 different portals.  Yes, I know I could set up one portal to contain the store and direct everyone there, but there are business reasons the same storefront needs to be embedded in each of the various portals.  If the DB were structured properly, I could create an alternative admin module control that allowed the portal admin to connect to an existing Store or create a brand new Store.  Perhaps a web.config setting to turn this ability on/off per DNN installation.

1) Store_Address -- I assume this is meant to track customer addresses (bill to, ship to, etc).  Address is specific to User and there is already a UserID field. 

2) Store_Administration  -- PortalID should be StoreID

3) Store_Cart -- PortalID should be StoreID

4) Store_Categories - PortalID should be StoreID

5) Store_Order -- PortalID should be StoreID

6) Store_Products --PortalID should be StoreID

7) Store_Reviews -- PortalID should be StoreID