Store data information model

Store data is the information that is loaded into the WebSphere Commerce Server database, which allows your store to function. The URL Registry Entries and View Registry Entries packages are included in the diagram, but they are not database assets. These entries are presentation configuration (that is, struts actions and forwards) that must be deployed. URL registry entries are shown in the diagram to illustrate the entire store data information model. To operate properly, a store must have the data in place to support all customer activities. For example, in order for a customer to make a purchase, your store must contain a catalog of goods for sale (catalog data), the data associated with processing orders (tax and shipping data), and the inventory to fulfill the request (inventory and fulfillment data).

An information model illustrates how store data is structured in the WebSphere Commerce Server. The WebSphere Commerce Server information model is a high-level abstraction of the information that is contained in the WebSphere Commerce Server data models. The information model highlights the most important features of the data models, but does not include the lower-level details that are specific to the schema and object implementations.

For example, certain tables and objects in the data model that contain entity-relationship data (such as foreign key pairs) are not represented in the information model as entities. Instead, these entity relationships are implied by the relationship lines between entities in the information models. The information model also differs from the data model. In the data model, each entity represents a table. In the information model, any of the objects depicted can be mapped to the same database table, or a single object can map to several database tables. The information model also does not illustrate detail extensions (data attributes of an entity that are stored in a separate table as a result of implementation concerns: for example, the product description is a separately stored extension of the product entity). Finally, unlike the data model, the information model can also illustrate concepts of inheritance.

The following diagram illustrates the data assets of a WebSphere Commerce store.

Store data information model

In the UML notation, a dotted line with an arrow that extends from an object and pointing to another object indicates that the first object has a dependency on the second object. In this diagram, the objects that are shown are as packages. Data in some packages, such as lists of Supported Currencies, are specific to a particular Store, and these packages are shown as dependent on the Store package. Other packages, such as Catalogs, are not specific to any particular Store. Each Store can use Catalogs, and thus the Store object is shown as dependent on the Catalogs package. As a result, the lists of Supported Currencies form part of a Store, while a Store uses Catalogs.

Stores
A package of stores. This is shown in the center of the diagram. In WebSphere Commerce an online store is the place where all transactions for your online business occur. WebSphere Commerce supports several different types of entities that are defined as stores. These store types include customer-facing store, asset store, and proxy store.
Prices
A package of prices. Prices are not specific to any particular store. Each store can use Prices, and thus the store object is shown as dependent on the Prices package.
Catalogs
A package of catalogs. Catalogs are not specific to any particular store. Each store can use Catalogs, and thus the store object is shown as dependent on the Catalogs package.
Site Level Information
A package of Site Level Information. A site can contain information such as organizations, member attributes, language, roles, and other information that pertains to the site. Site information is not particular to any store. Each store can use Site Level Information, and thus the store object is shown as dependent on the Site Level Information package.
Business Policies
A package of Business Policies. A business policy is a set of rules followed by a store or group of stores that define the business processes, industry practices, or the scope and characteristics of business offerings. Business Policies are not particular to any store. Each store can use Business Policies, and thus the store object is shown as dependent on the Business Policies package.
Trading Agreements for RFQs and Auctions
A package of Trading Agreements. WebSphere Commerce provides a number of trading mechanisms that govern the interactions between buyers and sellers. A trading agreement represents an instance of a trading mechanism and records the properties of that instance of a trading mechanism. Each contract, business account, and RFQ in WebSphere Commerce is represented by a trading agreement. There is a single trading agreement in a store that governs all auctions in that store. WebSphere Commerce supports several trading agreement types, including account, contract, RFQs, exchange, and auctions. Trading Agreements are specific to a particular Store, and thus the Trading Agreements package is shown as dependent on the Store.
Contracts and Accounts
A package of Contracts and Accounts. In WebSphere Commerce a contract is an agreement that represents the terms and conditions that apply to a transaction. An account is a relationship between the merchant and the financial institution which processes transactions for that merchant. Contracts and Accounts are not particular to any store. Each store can use Contracts and Accounts, and thus the store object is shown as dependent on the Contracts and Accounts package.
Members
A package of Members. A member is a person, group, or organization that is known to the system. A member can be a user, an organization, an organization unit, or a member group. A member can act as a customer or an administrator, or can own entities. WebSphere Commerce Enterprise A member must first become a member of the marketplace before the member can become a user. Members are not particular to any store. Each store can use Members, and thus the store object is shown as dependent on the Members package.
Payment
A Payment package. In WebSphere Commerce Payments, a payment is a request of a financial institution to approve all or part of an order. In many cases, all the money that is authorized for collection by an order is collected in a single payment. Some payment systems can allow the money authorized in one order (that is, one set of payment instructions) to be collected in multiple payments, depending on the business model. Payments are not particular to any store. Each store can use Payments, and thus the store object is shown as dependent on the Payments package.
Fulfillment
A Fulfillment package. In WebSphere Commerce, fulfillment is the process of filling an order for a client. A fulfillment center serves as a storage warehouse where products are packaged and shipped to customers. Fulfillment centers, stores, and shipping carriers are treated as separate entities. Fulfillment is not particular to any store. Each store can use Fulfillment and the store object is shown as dependent on the Fulfillments package.
Vendors
A Vendors package. A vendor represents a source for merchandise that is received at a fulfillment center, or expected to be received at a fulfillment center. Vendors are not particular to any store, but rather each store can work with vendors. Since each store can work with Vendors, the store object is shown as dependent on the Vendor package.
Inventory
An Inventory package. In WebSphere Commerce, inventory is the products at a fulfillment center. Inventory is specific to a particular Store, and thus the Inventory package is shown as dependent on the Store package.
Orders
An Orders package. One or more items, products, prebuilt kits, bundles, or SKUs, or a combination thereof, selected for purchase. An order contains quantities, prices, shipping information, and tax and shipping charges, which are compiled and displayed to customers after they initiate the ordering process. Depending on the store policy, orders can be returned, if customers are unhappy with their purchase. Orders are specific to a particular Store, and thus the Orders package is shown as dependent on the Store package.
Jurisdictions
A Jurisdictions package. A jurisdiction is a geographical region for tax or shipping purposes that represent a country or region, province or territory, postal code range, or an application-specific geo-code. In WebSphere Commerce, a geo-code is an application-specific code that represents a geographical region. Jurisdictions are specific to a particular Store, and thus the Jurisdictions package is shown as dependent on the Store.
Taxes
A Taxes package. Taxes are specific to a particular Store and its location, and thus the Taxes package is shown as dependent on the Store.
Customer Segments and Collaboration
A Customer Segments and Collaboration package. Customer Segments are specific to a particular Store, and thus the Customer Segments package is shown as dependent on the Store.
Experiments
An Experiments package. Experimentation enables Marketing Managers to run alternative web activities concurrently with existing activities. Experiments are similar to web activities, in that they deliver an alternative marketing message. Experiments are specific to a particular Store, and thus the Experiments package is shown as dependent on the Store.
Email Activities
An email Activities package. Email activities provide Marketing Managers with a method by which they can perform direct marketing to customers by using email. Email activities are specific to a particular Store, and thus the email Activities package is shown as dependent on the Store.
Campaigns
A Campaigns package. A campaign is a planned series of operations that include advertisements and suggestive selling techniques, that are pursued to achieve a defined set of business objectives. Campaigns are specific to a particular Store, and thus the Campaigns package is shown as dependent on the Store.
Coupons
A Coupons package. Coupons are specific to a particular Store, and thus the Coupons package is shown as dependent on the Store.
Promotions
A Promotions package. Promotions are specific to a particular Store, and thus the Promotions package is shown as dependent on the Store.
Shipping
A Shipping package. Shipping is specific to a particular Store, and thus the Shipping package is shown as dependent on the Store.
Store Relationships
A Store Relationships package. A store relationship (captured in the STOREREL table) is the relationship between two stores. All store relationships are directional, that is in each store relationship one store provides the services and the second store in the relationship uses those services. For example, store A uses the catalogs that are provided by store B. Store relationships are specific to a particular Store, and thus the Store Relationships package is shown as dependent on the Store.
Supported Currencies
A Supported Currencies package. A supported currency is a currency that an online store can display and handle. Supported currencies are specific to a particular Store, and thus the Supported Currencies package is shown as dependent on the Store.
Supported Languages
A Supported Languages package. Supported languages are specific to a particular Store, and thus the Supported Languages package is shown as dependent on the Store.
Supported Units of Measure
A Supported Units of Measure package. Supported units of measure are specific to a particular Store, and thus the Supported Units of Measure package is shown as dependent on the Store.
Command Registry Entries
A Command Registry Entries package. Every command, whether it is a controller or task command, can be defined in the command registry. A command that is being executed is specific to a request for its execution by a particular Store. Since executed commands are specific to a store, the Command Registry Entries package is shown as dependent on the Store.
View Registry Entries
A View Registry Entries package. The URL registry entries are not database assets, but presentation configuration (that is, struts actions and forwards) that need to be deployed. View registry entries are shown in the diagram to illustrate the entire store data information model. After a command is executed, in most cases, the requester of the command requires a response to be returned. Every view that returns a response must be defined in the view registry, either per store, or by default, by site. Each store defines the view for each possible device format of the incoming request. A view command that is being executed is specific to a request for its execution by a particular Store. Since executed view commands are specific to a store, the View Registry Entries package is shown as dependent on the Store.
URL Registry Entries
A URL Registry Entries package. A URL Registry Entries package. The URL registry entries are not database assets, but presentation configuration (that is, struts actions and forwards) that need to be deployed. URL registry entries are shown in the diagram to illustrate the entire store data information model. The URL registry maps a command name to the actual interface of the command to be executed. Each URL registry entry is store sensitive, that is, each store can define a different interface for the same URL value. Since each URL registry entry is store sensitive, the URL Registry Entries package is shown as dependent on the Store.

The data in the information model can be categorized in the following ways: