Converting relations into classes 
Author Message
 Converting relations into classes

Hi,

I am having a hard time turning relations from my database design into
actual usable classes.   I have two
relations: SalesOrder and LineItems.  The definition is SalesOrder (OrderID,
CustomerID, Subtotal, salesTax, TotalCost)
and LineItems(SalesOrderID, itemID, quantity, cost).  Each SalesOrder is
going to have MANY LineItems.  So its a one to many relationship.

Does it mean my Salesorder class HAS-A LineItem class(es) contained in it?
Should I use an array of lineitems objects in my class? How does the concept
of foreign keys come into play when converting relations into classes?

Any pointers and/or examples would be great.

Thanks,

Mike



Tue, 27 Aug 2002 03:00:00 GMT  
 Converting relations into classes
There's no right answer to this.  But I can offer some pointers.

Decide if you really need classes to represent the data.  If you are just
selecting an entry, displaying it on a dialog using text boxes, etc, and
filing it, maybe you don't need classes.  Think about this, the relationship
is already defined in the database.  You are just "displaying" the
relationship.  You don't need classes to enforce the relationships.

However, if you are passing "objects" around, it's easier to have all
logical data contained in a single object.  That is, 1 CSalesOrder object
would contain within it all the CLineItem objects associated with it.  Note
that relational tables do not use things like inheritence or polymorphism.
In short, they are not "object" oriented (hence the word "relational").
I've found not fighting this limitation works best for me.

As for foreign keys,  1) enforce these through list/combo boxes during
selection, or 2) duing validation (e.g. OnOK()).  For example, when setting
m_CustomerID below, I've found it's not very easy/efficient to verify that
m_CustomerID is valid after the fact (e.g., while calling SetCustomerID(int
customerID)).  I also setup rules in the database (depends on what kind of
database you are using) to enforce the relationship.  This way, even if I
make a programming mistake, the database won't become corrupt.  Also, if you
file the data in OnOK() for example, and it fails, the user doesn't have to
reenter all the data all over again.  They just have to fix the piece that's
a problem.

class CLineItem
{
    int m_SalesOrderID;
    int m_itemID;
    int m_quantity;
    int m_cost

Quote:
}

class CSalesOrder
{
    int m_OrderID;
    int m_CustomerID;
    int m_Subtotal;
    int m_salesTex;
    int m_TotalCost;
    CList<CLineItem, CLineItem&> m_LineItems;

Quote:
}



Quote:
> Hi,

> I am having a hard time turning relations from my database design into
> actual usable classes.   I have two
> relations: SalesOrder and LineItems.  The definition is SalesOrder
(OrderID,
> CustomerID, Subtotal, salesTax, TotalCost)
> and LineItems(SalesOrderID, itemID, quantity, cost).  Each SalesOrder is
> going to have MANY LineItems.  So its a one to many relationship.

> Does it mean my Salesorder class HAS-A LineItem class(es) contained in it?
> Should I use an array of lineitems objects in my class? How does the
concept
> of foreign keys come into play when converting relations into classes?

> Any pointers and/or examples would be great.

> Thanks,

> Mike



Thu, 29 Aug 2002 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Q: warnings in relation to pure virtual functions in template classes

2. Converting from Base Class to Sub-Class

3. how to convert base class pointer to sub class pointer

4. Multi-column data relation (one to many)

5. Question about relation in ADO.NET

6. Floating point relations

7. Dataset relations ("Lookup field?")

8. relation between sizeof(void*), sizeof(int)

9. DataRelation for one to many relations

10. relations between two arrays of structures

11. M2 history - relations to Ada

12. Tables/Relations

 

 
Powered by phpBB® Forum Software