Total Marks
|
5
|
Starting Date
|
Wednesday, January 18, 2012
|
Closing Date
|
Thursday, January 19, 2012
|
Status
|
Open
|
Dear Students
GDB will be open for 2 days on 18th January 2012.
The topic of discussion is given below
“Normalization Process removes the anomalies from the data
but ultimately it affects the Query Performance of DML operations:” why..? Justify the statement.
Guidelines
·
Discuss both “Positive and negative effects” (if any)
·
Your answer should be precise and should not be greater
than 6 lines
·
Do not post the answer of GDB topic in MDB
Solution
Application of normal forms beyond third
normal
form can tend to produce too many entities, resulting in too many
entities in SQL query joins. Too many entities in SQL query joins can
reduce system performance for any type of database. The more entities in a
join, the more difficult queries are to tune. Also, more query complexity
makes it more difficult for a database query optimizer to make a best guess
at the fastest execution path for a query. The result is poor performance.
From a purely commercial perspective, good performance is much more
important than granular perfection in relational database design. It’s not
about the design but more about satisfied customers and end users. Poor
response time from a computer system will upset people. In fact, poor
response time can be much more than simply upsetting because it can
impact business and the bottom line for a company.
Over normalization using third normal forms and beyond can lead to
poor performance in both OLTP and data warehouse type databases. Overnormalization
is more commercially in top-down designed Java object
applications. In this situation, an object structure is imposed onto a relational
database. Object and relational data structures are completely different
methodologies, because the fine details of granularity are inherent in
object modeling. The same is true of extreme application of normal forms,
but that creates too many entities, too much processing built into a database
model, and ultimately highly complex SQL coding and poor performance
as a result.
form can tend to produce too many entities, resulting in too many
entities in SQL query joins. Too many entities in SQL query joins can
reduce system performance for any type of database. The more entities in a
join, the more difficult queries are to tune. Also, more query complexity
makes it more difficult for a database query optimizer to make a best guess
at the fastest execution path for a query. The result is poor performance.
From a purely commercial perspective, good performance is much more
important than granular perfection in relational database design. It’s not
about the design but more about satisfied customers and end users. Poor
response time from a computer system will upset people. In fact, poor
response time can be much more than simply upsetting because it can
impact business and the bottom line for a company.
Over normalization using third normal forms and beyond can lead to
poor performance in both OLTP and data warehouse type databases. Overnormalization
is more commercially in top-down designed Java object
applications. In this situation, an object structure is imposed onto a relational
database. Object and relational data structures are completely different
methodologies, because the fine details of granularity are inherent in
object modeling. The same is true of extreme application of normal forms,
but that creates too many entities, too much processing built into a database
model, and ultimately highly complex SQL coding and poor performance
as a result.
--------------------------------------------------------------------------------------------------------------
Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database via the defined relationships.
No comments:
Post a Comment