Anda di halaman 1dari 2

Infomation Modeling and Database Design

Normal Forms

Representing information in software is generally done by designing the representation of the information
in a (relational) database. The ideas are relatively simple: a relational database consists of data stored in the
form of tables (each row is referred to as a "tuple").

There are a few rules for good database design. These are referred to as normal forms:
First Normal Form: this translates to saying that all rows of the table have the same number of
fields. This form is violated when a single field is used to store multiple phone nos, for example.
Second Normal Form: this is applicable to records having composite keys. It says that no field
should contain information about a subset of the key.
Third Normal Form: this is violated when a non-key field contains a fact about another non-key
field.
However, most reasonable design of database tables would result in table structures that meets the 3 normal
form rules.

Information Modeling

The more important dimension to database design is related to modeling information from the real world
into the database. Which information is important, which is central, what are the important relationships
between the information, what is the information that will be generated when the system is used in one way
or another?

There is no defined way to doing this. It requires deep involvement from the database designer in the
problem domain and trying to imagine the system when it is being used over a period of time.

One way to start with the design is to imagine the situation in terms of what would be required if the
transactions in question were to be carried out over the telephone. Take the case of modeling a buy - sell
situation - from the store-owner's point of view:

One example situation would be to take an order from a customer over the phone and make the delivery.
The central piece of information would be the list of products stocked and their availability (and price).
This will allow the store owner to decide whether he can fulfill the order of not. Another piece of
information that would be really helpful would be substitute products (if the one asked for is not in stock).

Another example situation from the same example would be concerned with the information is produced in
the first exchange. There would be a list of items that have been ordered. It would also contain the name
and information of the customer who placed the order. After all there may be many such orders placed and
they all need to be kept track of. There would be information about the value of the order, the status of the
order - whether delivered or not. Also the time of the order - so as to find out if there has been a delay in
the delivery.

So, we have identified the product inventory information, order information and customer information as
the central pieces of information. Are there any more? Let's try to visualize other scenarios: products are
delivered by the supplier: this action would update product inventory information. How much profit was
made on sales? a combination of profit on each order item (calculated by difference in value between
product information and order information) would answer this question.

And if we find questions that cannot be answered in terms of the available information, more information
needs to be added. Where will the goods be deliverer? The customer info should contain the address. Better
still, the order info should contain the address - since the customer could order goods to be delivered
elsewhere.