Generic or specific models ?In this keynote, we will look into the use of generic or specific database models.
There are many analysts who advocate for using generic ER models to build a system, while others favor building it costumer-specific.
Actually, I slightly disagree with both directions.
I have studied many generic models. One common denominator is that generic models try to capture everything imaginable in a certain field of business, like financials, production, etc. If you need to cover everything imaginable, you are probably already a customer of Oracle Financials, Peoplesoft, or some other high-end ERP system.
The reason for starting a project involving ER modeling, design, development and deployment of an application, is that the business wants to build something unique; a new way of treating customers, new supply logistics, or anything else that gives it a competitive edge. A generic model will involve many entities, relationships, and probably business rules that are not relevant to the business.
It means developing functions that will never be used, an extended database with tables that are never accessed, triggers that fire and execute nothing; Even this code;
will have some impact on performance if it is executed often enough each day. A model specifically designed for the business sounds good. However, you have a chance of narrowing your scope too much, so that you build inflexible limitations into the system. Refer to the keynote on Analysis Trap 2.
An experienced analyst brings with him into the project a perspective based on earlier experience: He is able to recognize patterns in different areas of the business domain.
The customer is an area for which a pattern can be given. There are many common questions regarding customers, which can be reflected in a recognizable pattern.
How we build a sales order is also a common pattern: At some point there is a customer involved, the order is about one or more products, it should be effectuated and delivered, someone’s has to pay, etc.
Patterns are studies of small, specific domains of a larger ER model, with one (or a few) in- and outgoing links to surrounding domains of the ER model. An experienced analyst will immediately recognize a given domain in the model as something he has studied before, and knows about. He can therefore bring added value into the ER model by discussing the domain with the business, and ask ‘difficult’ questions, based on limitations that are obvious with regards to the patterns of that domain, and which the analyst brings with him, in his experience.
If you go through a development cycle for a new application, it is because you want something others do not have. You do it in order to gain some competitive edge, or you are realizing a very new business idea. Either way, copying something old is not too smart. However, keeping patterns, that cover separate smaller domains of the model, at work, may build you a system that is not only something unique, but also contains flexibility based on earlier, hard-earned experience.
Free eBookSubscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:
What visitors say...
"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.Read more Testimonials
I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."
Theory & Practice
SQL Server DBA
Install SQL Server
Database Normalization eBook:
Copyright © www.databasedesign-resource.com / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.
Return to top
The name Oracle is a trademark of Oracle Corporation.