Introduction.
This video introduces data modelling. Data modelling is fundamental to creating a business level data architecture.
Duration: 8 minutes. See also, ‘Summary of the video content’, below.
Summary of the video content.
The video is based on a scenario concerning insurance policies and the customers who buy them.
The business view is of course highly simplified; we are trying to explain data modelling, not the business of insurance.
Two classes are identified, Customer and Policy. These represent actual customers and policies.
A class is a sort of blue print that defines the company’s concept of customer and policy. The concept identifies the attributes, or data items, for each concept.
The concept of a customer includes attributes such as:
- Customer name.
- Status.
- Post code.
The concept of a policy includes attributes such as:
- Policy number.
- Policy type.
- Purchase date.
- Price.
Data modelling at the business level is sometimes described as concept modelling. The model itself is described as a conceptual model.
There is an association between the two classes which is labelled, ‘owns’. I.E., ‘One customer owns or more policies’.
The associations capture business rules, such as the rule that to be a customer of this company, it is necessary to have purchased at least one policy.
Another business rule states that a policy must be owned by at least one customer but may be owned by many customers.
Notes on the model.
These notes refer to terms in the Zachman framework such as the distinction between the conceptual and the logical views.
As mentioned, the video describes a conceptual business level model, not a ‘normalised’ logical model. A logical level data model shows such adornments such as ‘foreign keys’.
This introductory video does not describe how to resolve the so called ‘many to many’ associations. This is often more relevant to the logical level view. Arguably the logical level is more relevant to the solution architect than the business analyst or architect, although of course the same person may take on all of these roles.
The notation used in the video is a simple form of UML.
Many analysts consider that UML is too technical and complex to be used for business modelling. This is not correct if UML is used appropriately.
In common with most modelling notations, UML comprises mainly rectangles and lines. It also has other ‘adornments‘.
UML refers to artefacts such as attributes and various graphic devices as ‘adornments’. It provides a range of adornments relevant to different stages of a projects, e.g. requirements discovery, design, implementation, etc.
Use only adornments that are relevant to a particular stage. And obviously, only use adornments that you and your stakeholders understand. Just because something is available in the UML, it does have to be used.
We provide an overview of data modelling in our e-training course, ‘Introduction to business change’.
