 |
A Quick Guide to Data Modleing
by Mike Morris
Janaury 4, 2001
As computers have become more powerful and intelligent, they have been pushed to perform ever more intricate and complicated functions. Many new procedures have been developed to enhance computer productivity, and one of them is Data Modeling. The data modeler is a data analyst who uses modeling procedures.
History 101
In the old days, we had flat files, which were usually accessed in one way only. Information was duplicated in different files causing several problems, one of which was the synchronization of data. Relational databases such as DB2, Oracle and Informix were developed to get around these limitations, which became more serious as data processing tasks became more complex.
Not too long ago, analyzing data in a system was accomplished by drawing up a DFD (data flow diagram.) Though the data elements in a DFD are important, there are a couple of reasons why they might be incorrect or incomplete. One is that the DFD might have resulted from an analysis of an existing system, and there is no guarantee that the existing system was complete or efficient, or that it will work under new business rules.
Another problem is that the DFD only shows data items required by that particular functional area, and different functional areas may contain duplicate or unsynchronized information.
Basics
Data modeling is a structuring of information on a business-wide basis. It classifies and represents things, and is used to define what data is held in the system, and how groups of data relate to each other. It is also used to check that the required processing can be supported. It should not necessarily be forced to conform to the corporate model, since that may not be the best model available.
Some benefits of data modeling are:
- It simplifies the creation of a well-designed database.
- Its principles are now well established, and can be used for widely varying business rules.
- Modeling is about patterns in the data. We don’t have to re-invent the wheel every time we create a new model.
- Creating generic data models and data relationships makes for more generic code, which in turn makes for simpler processes. Object-oriented programming systems (OOPS), table-driven procedures, and data modeling all work well together.
In data modeling, we look upon our data as ‘entities,’ and the business rules as ‘relationships.’ For example, an entity might be a supplier, or an invoice. A simple relationship would be, a supplier sends an invoice, or an invoice is sent by a supplier.
We should be prepared to reverse a relationship in this way to gain insight as to how the process works. A slightly more complete model would be:
- A supplier is sent an order
- A supplier sends an invoice
- An order relates to an invoice
- An invoice updates inventory
X Degrees of Separation
- One to one
- One to many
- Many to one
For instance, an order (usually) relates to one invoice. Many invoices (over time) update inventory. There is another relationship, which is not handled very well in relational databases and, by extension, data modeling, and that is many to many.
We get around this by creating ghost or dummy entities. For instance, a customer can place many orders, and these orders can each have many line items, and many invoices will be required for each order. So we interpose an order/line item entity between orders and Invoices. Now, each single order has many line items, and these many line items within each order require one invoice.
Another type of relationship can be described as a mandatory/optional requirement. Going back to our order / supplier / invoice / inventory relationship, it might be supposed that all four entity types were mandatory. However, there may be occasions where inventory needs to be adjusted (after a physical audit for example), without the intervention of an order, a supplier, or even an invoice. Of course, the model might describe special types for these three entities in an adjustment situation, but an analyst has to consider which way will work best.
Attributes
All entities (supplier, inventory items, etc.) have characteristics, which allow us to differentiate between items of the same kind. We can distinguish between suppliers because they might have attributes such as:
- Name: ABC Company
- Address: 10 ABC St.
- Delivery characteristics
- Billing rules
- And other relevant information
These classes of characteristics, which are shared by all entities of the same kind (e.g. supplier), are called attribute types.
When we design a model for a business, we’re not concerned with all attribute types. We probably don’t care, for example, how many employees work for a supplier, or the name of the chief buyer. We may invent attribute types for a supplier, such as promptness of delivery, or reliability of merchandise supplied. These are important to our business.
Identifiers
It is important for us to uniquely identify one occurrence of an entity type from another. The entity type will eventually become a database group, the attribute types will become fields, and occurrences of the entity type will become records.
We must be sure that our identifier, or key, is unique for every occurrence of the entity type. If a single attribute type will not ensure a unique identifier, we must designate a set of identifiers as a key.
Domains
As a business, we don’t deal with all the suppliers in the world. In our database, we only record data about our own suppliers. This subset of our personal suppliers is known as the domain of the entity type of supplier. When we add a supplier, it becomes part of the domain.
Data Modeling Steps
What follows is one possible sequence of actions that an analyst might take to build a data model.
- Draw up DFDs to identify relevant processes and data items. There will be processes and data items for each functional area of a business.
For each functional area:
- List the entity types and the relationships between them. Produce a draft data model based on this.
- For each entity type think of the way that relevant data will be manipulated. From this, you can then get an idea of the attribute types (fields) for each entity type (database group).
- Some DFD processes may suggest new entity types. Add these to the draft model (step 1), and repeat steps 2 and 3.
- Repeat the above three steps for each functional area
- When all functional areas have been modeled, look for common or similar entry types, which might be combined.
- Clean up and rationalize.
You have your model.
Let Me Count the Ways
There’s no single ‘right’ way to produce a data model. It’s a creative endeavor, and not just a question of following a set of learned rules. A thorough knowledge of, and affinity with, the organization that that you work in is required to produce an elegant and efficient data model that will serve your company long and well.
The beauty of data modeling is that it allows us to look at the information flow within our organization, its content, and its significance. It allows us to visualize these things in a fresh way. It allows us to use our mind to create something new and better than what existed before.
This is what is known as progress.
|
