Three levels of model

The Guide specifies three levels of model for data: Information, Domain and Physical. The Information Model describes the data referred to in the process model. This may include data external to the system domain. This is a holistic view of data and concerns itself with how data is used by processes. The information model may record attributes of information that become apparent during process analysis. An example of this would be the stock status in our example which will have at least three statuses including ‘ In Stock’,’Out of Stock’,’Insufficient Stock’. Information models should also capture information about volume, frequency of change, security and privacy issues and information sources.

Business Entities and Attributes

Business Entities will be the initial components of the information model. The model will elaborate the on the Entities by describing the attributes. Business Entities do not exist in isolation and will be one of the common reference points for the process model.

Attributes may relate to high level business entities, these are attributes such as volume and security. These attributes will not directly map onto succeeding data models and will then be retained as requirements for use in the logical design stage.

Attributes relating to data instances which describe and instance of information and its relationship to other instances of information. Group of common instances will be described as entities, at this stage of modeling entities that behave differently should be described separately or arranged into behavioral hierarchies.

To separate these entities into initial behavioral groupings they can be typed as master, transactional, interfaces and reference. There may be other ways of grouping entities for specific problems and these should be explored.

Master Entities

Master entities are a the most easily identified and also the most commonly used entity in a system, master entities will always have attributes and will have properties that describe how they are used. An master entity may describe a real world object, a customer would be an example of a real world object; however a master may also describe an abstract object such as a book. Whether a master instance refers to a real object or an abstraction is a property of the instance. One of the most import properties on a master entity is its uniqueness, the information model should describe what makes an instance unique. Uniqueness can be problematic if it is described in terms of an attribute, for analysis describing uniqueness as a number is inadequate; as in “Each Customer/Person/Product is made unique by its Customer/Person/Product number”. The rule for a person should be fairly simple with one natural person per instance; however more complex entities such as Customers may be influenced by external factors such as the customers organizational structure. Master entities may have business rules relating to dependent data such as ‘Every customer must have a customer contact’, which will lead to business rules for the dependent data. Identification of a master entity is also important, real world entities may not be readily identifiable and may require method to identify the correct instance.

Transactions

Transactional Entities generally describe the properties and attributes of relationships between Master entities; some may describe specific items and others abstract items. Some transactions may purely log changes to master entities and be present to satisfy requirements of business process. Transactions that will also have a life cycle not only within processes but there should be a policy for retaining and archiving transactions. Transactions are useful in the long term to record compliance with external regulations and also to provide information for business intelligence.

Data Structure Diagrams (DSD’s)

Data Structure Diagrams (DSD’s) are a great way to summarize information, be informal, use arrows for relationships, draw it on the whiteboard as part of visualizing your data. You don’t have to draw all of your information model, but make sure you visualize the important parts. This is not a formal diagramming technique so feel free to be creative; although try and be consistent in usage for your project. In this diagram the ‘Orders’ transaction entity could be visually differentiated with a border or color if it was the subject of discussion.

Interfaces

Interfaces form one of the most important parts of the data model, they are intimately connected to the process model and can be of several types including internal interfaces, the interactions between processes, external interfaces where the same interface may be used with multiple external systems and intra-system interfaces that are used within the business. Again a specific problem may require a special type of interface. Interfaces a typically hierarchical structures and may be one-way or two-way interactions. In web applications these will be the most important part of the information model. An interface can be quite complex and contain a number of other entities such as masters and transactions.

Reference data

Reference data is in its most simple form a list, but may encompass quite complex types that will have their own business rules; an example of this would be locations and postcodes relating to transport costs. This is again where process and data can interact to produce new information. Frequency of change is quite important for reference data as are the business rules that govern changes. It may be convenient to note where reference data is assumed invariant if it rarely changes and it may not be worthwhile to implement complex business rules. Some reference data may be sourced externally, for example postcodes and countries.

Information Attributes

Attributes may either refer to another entity, describe something about an instance, which may be text or number. If the text comes from a list, this is reference data. Other properties of information may not be stored as attributes, these properties may include access rules and data retention rules.