Entity Relationship Modeling (ER modeling) is by far the most common way to express the analytical result of an early stage in the construction of a new database. In this ebook, Alf Pedersen describes the principles for ER modeling, as well as the most important terms used in modeling a new database.
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 she has studied before, and knows about. She 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 her, in her experience.
Main point: 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.
Important Analyst Ethics - Reminders You have done the job, and a complete Entity Relationship model, with Function Hierarchies, Events, and Business Constraints are all in place. And, when conditions change, the customer needs to order a rewrite, is he happy? No. If he knows he can just create a new customer type in the CUSTOMER_TYPE table and then go on, without calling you, will he be happy then? I think so.
This is the responsibility of the system analyst: giving the customer flexibility for future growth and change, without those costly rewrites. As a consultant you may disagree, you may just love those rewrites as an income-generating tool! But I assure you in the long run, you will win by building flexibility and room for change for your customer.
I just read somewhere on the Internet that in the good old days, a dissatisfied customer would tell his frustration to 6 others. In the days of the Internet, he will tell it to 6,000 others.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.