... C-zar need help ...
First, I want to say that, this problem was given for the
benefit of the students. Students would get extra-value in their Database System and also have experience for analyzing real case. Based on this case, we could knew that: "
sometimes theory is not the same as reality, but theory become our basis for determining decision".
C-zar's problem was one of the cases that happen in the real world. In terms of database design, this case was the bad one. And as a candidate DB designer or system analyst, you should be more sensitive about each part of DB (tables, columns, rows, data types, constraints and etc).
Did you still remember about the requirement?....It's only migrate from DB MySQL to DB Oracle, it means that we can't Create, Update, Delete data, because data is the most important thing for the company. Imagine if we could insert or delete data freely, the company would get BIG problem. We have no right to manipulate the data itself carelessly. So, DML is not our focus in this problem.
Hmmmmmm, how about the System? Until now, there was nothing wrong with the Information System, because the company running fine. Managers still use Information System properly.
Then, what is the real problem in here?C-zar can't migrate well because she didn't understand about the old DB design. The old designer not consider in terms of
data structure, normalization and conventional design. Consequently, the next developer like C-zar would have difficulty. These are the problems ::
- Identifier naming is not clear. What is ileb table? What about val or olet column? Is the naming according to their functionality??
- Ordering data types irregularly and inappropriate. Is tgl in varchar(6) or date?
- The minimal key is Primary Key, because we could create references from this key.
- Constraints are applied to enforce business rules and to enforce data integrity.
- C-zar couldn't predict the new table or new column, like gd4n6 table.
- Many to many detected in ileb table.
You'll get more points, if you give these normalization's solutions ::
- Split olet column into supplier.ileb and staff.ileb. Redundancy still detected in here.
- Split ileb table into Purchase table for receiving note and Product_Purchase table for recording of products purchased. Note that, a note consists of many products.
Do you have another arguments? Just make your comment in here..(nb :: don't forget to check my comments)You can see your's grade in this link....--- thanks to the candidates of DB designer or system analyst ---