Does data modeling differ for a data-driven DSS?
by Daniel J. Power
Editor, DSSResources.COM
Creating a data model is usually the beginning of a process to develop an information system linked to a data store. A conceptual data model shows the overall logical structure of a database. A conceptual data model should be independent of any software or data storage structure. In general, any type of data model is a method for visualizing the data and information needs of a system (check http://www.datamodel.org). The purpose of the system impacts what is modeled and hence may create different modeling processes for data-driven DSS.
Much of the discussion of data modeling uses examples from transaction processing systems. This makes sense because much of the formalism of data modeling was developed to reduce data redundancies and to avoid anomalies or errors from add, update and delete actions in a Database Management System. These issues of redundancies and anomalies are not generally relevant when building Data-Driven DSS with historical data.
So is data modeling still important when building data-driven DSS? The big picture answer is YES. Data modeling organizes a database designer's thinking about the appropriate structure for the decision support data store. It is still useful to think about entities and relationships in a data model to help identify data that should be extracted from transaction processing systems for decision support.
For example, if we want to monitor and improve decision-making about product sales we need to look at key entities like the Customer (a person with attributes), Salesperson (a type of employee with attributes), Product (Inventory SKU's), and Order/Sale (a transaction with attributes like date, time, quantity).
A number of relations help understand the data in the sales transaction process. For example,
· A specific customer may have zero or many sales transactions.
· A particular order or sale belongs to 1 and only 1 customer.
· A particular order or sales invoice is prepared by no more than 1 salesperson.
· A specific salesperson may have zero or many sales transactions.
· A particular sale can have 1 or more products sold.
· A specific product can be sold in 0, 1, or many sales transactions.
The above relations can help a decision support data modeler understand what data may be useful to aggregate, what data may benefit from redundant entries and what data may not be needed for decision support. Note the possible synonyms that a data modeler might encounter: Invoice, Order, Sale, Sales Transactions. Order may have a related Order Item entity.
The objective of data modeling is somewhat different when a decision support data store is being designed, but the modeler is still trying to gain a rigorous understanding of how data should be stored in a database before building and implementing a specific system.
The job title "Data Modeler" is used differently depending on the company and task environment. A search for "Data Modeler" positions in the
The above response is revised from Power, D., Does data modeling differ for a data-driven DSS? DSS News, Vol. 2, No. 17,
Last update: 2015-08-29 06:04
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
