Improved Readability - The use of submodels in Semantic data modeling

Within Semantic modeling we have so called Scenarios. They are there simply because of readability. It is proven in practice that people are better able to read and understand a semantic model firstly due to its hierarchical notation and secondly because of the use of Scenarios. Scenarios typically zoom into logical submodels and show the links to the relevant objects in other submodels.

Let's have a look at the Microsoft example database AdventureWorks.

AdventureWorks is a bicycle manufacturing company . It's employees produce these bicycles themselves but since 2000 they also purchase sub components. They sell to customers all over the world.

The overall Semantic model looks like this:

 

Logically there are 4 main submodels: HR, Production, Purchasing and Sales. Let's zoom into each of these concepts.

HR

 

 

A central concept Person is used to support the concept of Employees (used in Purchasing, Production and Sales) and Customer Persons. Per Person phone nrs and creditcard information is stored. Employees are modelled in a hierarchical way keeping track of each employees manager. Furthermore the Departments of the company and their employees are stored. History is kept of Payments and Job Candidates.

Production

 

 

The central data object is Product along with its Bill of Materials using different Units of Measure. Products are (sub)categorized and there are different models with illustrations and descriptions per culture. Products are produced according to WorkOrders which are routed accros Locations. The system keeps track of the Inventory. Photos and Documents are stored for each product. A history is logged of Product Costprices, Reviews, Transactions and Listprices. Product prices are listed as so called Special Offers with a certain validity period.

 

Purchasing

 

Vendors supply product components which link into the bill of materials of the end product. The system contains all the purchase order details. The employees and products involved in the Purchasing process are also shown in this picture.

 

Sales

 

 

 

The central data object here is Customer and all of its Sales order details (quantities, prices and reasons). Customers are found in different territories grouped in Countries/Regions. The system is able to handle multiple currencies, exchange rates and tax rates. The employees and products involved in the Sales proces are also shown in this picture.

 

Entity Relationship modeling

Just to compare both methods a picture of the ER model of AdventureWorks.