Store data information model
Store data is the information loaded into the WebSphere Commerce Server database, which allows your store to function. In order 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 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 that in the data model each entity represents a table while in the information model any of the objects depicted may be mapped to the same database table, or a single object may map to several database tables. The information model also does not illustrate detail extensions (additional 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 may also illustrate concepts of inheritance.
The following diagram illustrates the data assets of a WebSphere Commerce store.
In the UML notation, a dotted line with an arrow extending 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 shown are referred to as packages. Notice that data in some packages, such as lists of Supported Currencies, are specific to a particular Store, and thus that package is shown as dependent on the Store package. Other packages, such as Catalogs, are not specific to any particular Store, but rather each Store may 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, but rather each store may use Prices, and thus the store object is shown as dependant on the Prices package.
- Catalogs
- A package of catalogs. Catalogs are not specific to any particular store, but rather each store may use Catalogs, and thus the store object is shown as dependant 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 as well as other information pertaining to the site. Site information is not particular to any store, but rather each store may use Site Level Information, and thus the store object is shown as dependant 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 defining business processes, industry practices, or the scope and characteristics of business offerings. Business Policies are not particular to any store, but rather each store may use Business Policies, and thus the store object is shown as dependant on the Business Policies package.
- Contracts and Accounts
- A package of Contracts and Accounts. In WebSphere Commerce a contract is an agreement representing 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, but rather each store may use Contracts and Accounts, and thus the store object is shown as dependant on the Contracts and Accounts package.
- Members
- A package of Members. A member is a person, group, or organization known to the system. A member can be a user, an organization, an organization unit, or a member group. A member may act as a customer or an administrator, or may own entities.
A member must first become a member of the marketplace before becoming a user. Members are not particular to any store, but rather each store may use Members, and thus the store object is shown as dependant on the Members package.
- Payment
- A Payment package. In WebSphere Commerce Payments, a payment is a merchant's request of a financial institution to approve all or part of an order. In many cases, all the money authorized for collection by an order will be collected in a single payment. Some payment systems may 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, but rather each store may use Payments, and thus the store object is shown as dependant 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, but rather each store may use Fulfillment, and thus the store object is shown as dependant on the Fulfillments 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. 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 representing a country or region, province or territory, zip code range, or an application-specific geo-code. In WebSphere Commerce, a geo-code is an application-specific code representing a geographical region. Jurisdictions are specific to a particular Store, and thus the Jurisdictions package is shown as dependent on the Store. package.
- 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
- A Customer Segments package. Customer Segments are specific to a particular Store, and thus the Customer Segments package is shown as dependent on the Store.
- Campaigns
- A Campaigns package. A campaign is a planned series of operations including 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.
- Discounts
- A Discounts package. Discounts are specific to a particular Store, and thus the Discounts 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 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 is capable of displaying and handling. 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 being executed is specific to a request for its execution by a particular Store, and thus the Command Registry Entries package is shown as dependant on the Store.
- View Registry Entries
- A View Registry Entries package. 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 will normally define the view for each possible device format of the incoming request. A view command being executed is specific to a request for its execution by a particular Store, and thus the View Registry Entries package is shown as dependant on the Store.
- URL Registry Entries
- A URL Registry Entries package. 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 dependant on the Store.
The data in the information model can be categorized in the following ways: