Hibernate Books

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: Commenting on the item "1.2) Disparity Paradigm"
PostPosted: Wed Mar 31, 2010 3:11 pm 
Newbie

Joined: Wed Mar 31, 2010 8:45 am
Posts: 3
- This is the original text...
The relacinamento between the two entities is represented by the foreign key table USERNAME BILLING_DETAILS.

- This is the text of Proposed...
The relacinamento between the two entities is represented by foreign key mounted on the USERNAME column of the table BILLING_DETAILS.


Top
 Profile  
 
 Post subject: Re: Commenting on the item "1.2) Disparity Paradigm"
PostPosted: Wed Mar 31, 2010 3:13 pm 
Newbie

Joined: Wed Mar 31, 2010 8:45 am
Posts: 3
Instead of the term "granularity problem", I propose the term "problem of standardization (Normal Form)".


Top
 Profile  
 
 Post subject: Re: Commenting on the item "1.2) Disparity Paradigm"
PostPosted: Wed Mar 31, 2010 3:24 pm 
Newbie

Joined: Wed Mar 31, 2010 8:45 am
Posts: 3
Along with the term "superclass", I propose the term "Generalization (not every superclass is a generalization - OK)", and the term "subclass", I propose the term "Specialization (the same form)".

Data Modeling (on the Theory Entity-Relationship), for the 4th NF (Normal Form), the identity of the entity (ie the Primary Key - in terms of relational theory), both from the standpoint of Generalization (Generalized Entity), as the point of view of Specialization (Specialized Entity) shall have the same identity - in structural terms.

In other words, in both - Generalization and Specialization, the same columns form the primary key.

The difference is that in the specialties, Data Items Identity Entity (or columns of the table's primary key) responsible for transitivity to be caught (or constrained) to a given value, so allow Data Items transient (ie, not part of identity - or Primary Key, but they are "dragged" by the same) are placed on specialization.

For example:
Given the table "invoices" with columns "Invoice ID", "Payment Type", "Provider ID Credit Card", "Number of Credit Cards", "Card Payment Credit Card", "ID Bank" "Banking Agency ID", "Bank Account ID" and "Cheque Number".

Clearly, despite all data items are related to "Invoice ID", there are two groups of items transient data on the value of "Payment Type" ...

In this case, if when the "Invoice" is paid on a "Credit Card" (where the "Payment Type" = 1) Items "ID Bank", "ID Banking Agency", "Bank Account ID" and "Number Check the "are not there to make more sense. Likewise, when the "Invoice" is paid with a "check" (where the "Payment Type" = 2) Items "ID Provider Credit Card", "Number of Credit Cards", "Ticket Payment Card Credit "no longer make sense.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.