Last month, I touched on the issue of data modelling and why it is such an important discipline, and I introduced the eight non-negotiable steps to take. This month, I'll look at each in greater detail:
Identify entity types
An entity type has much in common conceptually with object-oriented definitions. Entity types can depict a collection of people, places, things, events or concepts. Some typical examples are customer, address, order, item, and tax. In class modelling, classes can be found with the same names. The essential distinction between a class and an entity type is classes have data and behaviour while entity types only have data. An entity should be normal, depicting one concept: for instance, customer and address are distinct concepts and as such need to be modelled as separate entities.
Identify attributes
Each entity type has one or more data attributes. These attributes must be cohesive in the context of the domain. If companies get this right, or wrong, it will have an impact in terms of maintenance and performance.
Every IT professional should have at least a nodding acquaintance with data modelling.
Michael de Andrade is MD of EnterpriseWorx
Apply naming conventions
The company must have data modelling standards and guidelines: if there aren't any, they need to be created. These guidelines must embrace naming conventions for logical and physical modelling. Logical conventions must be predicated on human comprehension, while physical conventions fulfil technical requirements.
Identify relationships
Entities have relationships with each other. These need to be reflected in the data models that are developed. Some entity relationships have unidrectional relationships (a customer resides at an address), while others are multidirectional (I place an order and the order is placed).
Apply data model patterns
Some data modellers like to apply data model patterns, just as object-oriented developers apply analysis patterns and design patterns. These are standard data models that can be applied to a variety of standard business situations: at their heart lies the concept of re-use based on repetition of circumstances and events.
Assign keys
Data modellers can adopt one of two basic approaches for assigning keys to tables. First, a natural key can be assigned: this is one or more data attributes unique to a business concept, such as a customer number or ID number. The second is to create a surrogate key, one that has no business meaning. Depending on the particular requirement, companies will choose one or the other approach. Do note, though, that this is an area of hot, if sometimes irrelevant debate, and whichever approach is taken, a company could be criticised, but neither is all-embracing or perfect and each will be indicated for a different requirement.
Normalise to reduce data redundancy
Data normalisation is applied to minimise - even totally eradicate - data redundancy and to stop inconsistent data at source. This is important for developers as it is hard to store objects in a relational database, which stores the same information in a number of locations. Effectively, data normalisation is the process whereby data attributes in a data model are organised so as to enhance entity type cohesion.
Denormalise to improve performance
Once deployed, normalised data schemes can experience performance issues. This is not surprising: data normalisation aims to minimise data redundancy, whereas an application might need top performance - such as an online shopping service where customers who wait long periods for a response will go somewhere else. This could necessitate changes to some of the aspects of the data schema, but ideally with as little impact as possible. Indeed, denormalisation should only commence when performance testing highlights a performance problem. There should be no need to fix what ain't broke.
Every IT professional should have at least a nodding acquaintance with data modelling. It is an important, if not vital, discipline and the fact that the database impacts every part of IT systems makes it imperative that either IT professionals know their way around the database, or have the appropriate consultants on hand to do it for them.
Share