Loading ...
Sorry, an error occurred while loading the content.
 

O/R mapping implementation oversight?

Expand Messages
  • ppngiap
    Hi, This is my first post on O/R mapping in this group. I did a quick search but haven t seen anyone posted on this issue. The section How Relational
    Message 1 of 10 , Dec 6, 2005
      Hi,

      This is my first post on O/R mapping in this group. I did a quick
      search but haven't seen anyone posted on this issue.

      The section "How Relational Database Relationships Are Implemented" of
      article "O/R Mapping in Detail",
      http://www.agiledata.org/essays/mappingObjects.html#ImplementingObjectRelationships,
      describes the database mapping for the relationship between Postion
      and Employee in which the EmployeePOID column in Postion table is a
      foreign key to Employee table. The reason is very simple, if use the
      current mapping, duplicated data is introduced to the database. For
      example, if there are 5 employees holding the Software Engineer
      postion, then there are 5 "distinct" Software Engineer row in the
      Position table.

      The point is that we need to be vigilant in relationship mapping.

      Br,
      Tom
    • Curt Sampson
      ... If you look at the diagram, the relationship between Position and Employee in the example is 1 0..1. So it s not possible for more than one Employee to
      Message 2 of 10 , Dec 6, 2005
        On Wed, 7 Dec 2005, ppngiap wrote:

        > The section "How Relational Database Relationships Are Implemented" of
        > article "O/R Mapping in Detail",
        > http://www.agiledata.org/essays/mappingObjects.html#ImplementingObjectRelationships ,
        > describes the database mapping for the relationship between Postion
        > and Employee in which the EmployeePOID column in Postion table is a
        > foreign key to Employee table. The reason is very simple, if use the
        > current mapping, duplicated data is introduced to the database. For
        > example, if there are 5 employees holding the Software Engineer
        > postion, then there are 5 "distinct" Software Engineer row in the
        > Position table.

        If you look at the diagram, the relationship between Position and
        Employee in the example is 1 <-> 0..1. So it's not possible for more
        than one Employee to be in any particular Position.

        As for the duplication, yes, you have to be a bit careful if you fall
        into the OO "network" design of linking data, because you then need to
        undo the effects of using that deleterious model when you try to move
        things back into an RDBMS. The best solution is just to continue using
        the relational model for data access within your OO language; you can
        then avoid chasing pointers, mucking about with hash tables, and so on,
        as well.

        > The point is that we need to be vigilant in relationship mapping.

        Only if you do the mapping in the first place. :-)

        cjs
        --
        Curt Sampson <cjs@...> +81 90 7737 2974
        The power of accurate observation is commonly called cynicism
        by those who have not got it. --George Bernard Shaw
      • Willem Bogaerts
        I didn t read the article, but there is no reason why there should be more than one instance of the record. Look at the section called laziness for an
        Message 3 of 10 , Dec 6, 2005
          I didn't read the article, but there is no reason why there should be
          more than one instance of the record. Look at the section called
          "laziness" for an example of how to prevent this in
          http://www.w-p.dds.nl/article/wtrframe.htm

          Best regards,
          Willem Bogaerts

          ppngiap wrote:
          > Hi,
          >
          > This is my first post on O/R mapping in this group. I did a quick
          > search but haven't seen anyone posted on this issue.
          >
          > The section "How Relational Database Relationships Are Implemented" of
          > article "O/R Mapping in Detail",
          > http://www.agiledata.org/essays/mappingObjects.html#ImplementingObjectRelationships,
          > describes the database mapping for the relationship between Postion
          > and Employee in which the EmployeePOID column in Postion table is a
          > foreign key to Employee table. The reason is very simple, if use the
          > current mapping, duplicated data is introduced to the database. For
          > example, if there are 5 employees holding the Software Engineer
          > postion, then there are 5 "distinct" Software Engineer row in the
          > Position table.
          >
          > The point is that we need to be vigilant in relationship mapping.
          >
          > Br,
          > Tom
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        • jgo456
          ... mappingObjects.html#ImplementingObjectRelationships, ... A big part of such problems is that the diagramming methodologies and tools are too coarse. This
          Message 4 of 10 , Jan 11, 2006
            > In agileDatabases@yahoogroups.com, "ppngiap" <ppngiap@y...> wrote:
            > The section "How Relational Database Relationships Are
            > Implemented" of article "O/R Mapping in Detail",
            > http://www.agiledata.org/essays/
            mappingObjects.html#ImplementingObjectRelationships,
            > describes the database mapping for the relationship
            > between Postion and Employee...

            A big part of such problems is that the diagramming methodologies and
            tools are too coarse. This is illustrated by the Chen diagrams in the
            referenced article, itself.

            A first name is an object type. A last name (nachname) is an object
            type. A year is an object type...

            With Nijssen's methodology, and more detailed diagramming, the
            relational table structures fall out more naturally rather than being
            imposed prematurely (i.e. shoving them into big boxes where they may
            or may not belong in the Chen diagrams).

            We used this for the Military Airlift Command and it served to
            clarify and untangle a rat's nest of data-bases and files and show
            the way to re-structure it all into a data warehouse in reasonable
            steps.
          • Scott Ambler
            ... From: jgo456 Reply-To: agileDatabases@yahoogroups.com Date: Thu, 12 Jan 2006 00:00:01 -0000 ... What article are you actually
            Message 5 of 10 , Jan 12, 2006
              ---------- Original Message ----------------------------------
              From: "jgo456" <jgo456@...>
              Reply-To: agileDatabases@yahoogroups.com
              Date: Thu, 12 Jan 2006 00:00:01 -0000

              >> In agileDatabases@yahoogroups.com, "ppngiap" <ppngiap@y...> wrote:
              >> The section "How Relational Database Relationships Are
              >> Implemented" of article "O/R Mapping in Detail",
              >> http://www.agiledata.org/essays/
              >mappingObjects.html#ImplementingObjectRelationships,
              >> describes the database mapping for the relationship
              >> between Postion and Employee...
              >
              >A big part of such problems is that the diagramming methodologies and
              >tools are too coarse. This is illustrated by the Chen diagrams in the
              >referenced article, itself.

              What article are you actually reading? There aren't any Chen diagrams referenced in the one referenced above, instead I use the typical style of physical data modeling which are quite common (although I do use a form of UML-based notation).

              >
              >A first name is an object type. A last name (nachname) is an object
              >type. A year is an object type...

              Yes, in Chen you do goofy things like this at the logical level. It helps people to explore the domain I suppose. However, the Chen notation seems to be rarely used in practice, and I don't think that I've ever seen it used for physical data modeling. You map classes to physical data models, not to logical data models (LDMs). Anyone who is mapping classes to LDM is truly wasting their time IMHO.

              - Scott
            • Logan, Patrick D
              You map classes to physical data models, not to logical data models (LDMs). Anyone who is mapping classes to LDM is truly wasting their time IMHO. I think
              Message 6 of 10 , Jan 12, 2006
                "You map classes to physical data models, not to logical data models
                (LDMs). Anyone who is mapping classes to LDM is truly wasting their
                time IMHO."

                I think this is true in isolated systems, but the reverse becomes more
                true when the system is put into a larger enterprise context and more
                "traditional" integration and decision support is required.

                This approach is fine for using a relational database as just another
                back-end storage mechanism. I have found a business-driven approach
                starts with a business process (what needs to be done) and business
                intelligence (how is success measured) perspective leads to what could
                be called a "value-cost chain" or in Ralph Kimball's terms a "data bus
                architecture".

                The outcome of this is a matrix view of these chains of information and
                processes at the high level and a set of related star schema models at
                the more detailed level.

                Objects and processes fall out of this and the O/R mapping is less of a
                technical problem than the (un-)pickling of an object model only
                concerned with an in-memory transaction processor.

                This approach is more appropriate for an overall service-oriented
                architecture than an isolated one-off application. Within an overall IT
                strategy we have taken significant strides to move away from these kinds
                of apps and move toward a more enterprise wide planning and
                architecture.

                -Patrick
              • Scott W. Ambler
                ... Then shouldn t you be mapping your data sources (some of which would be described by PDMs) to a LDM (or similar) so that you can then map to whatever data
                Message 7 of 10 , Jan 13, 2006
                  At 01:47 PM 1/12/2006, Patrick wrote:
                  >"You map classes to physical data models, not to logical data models
                  >(LDMs). Anyone who is mapping classes to LDM is truly wasting their
                  >time IMHO."
                  >
                  >I think this is true in isolated systems, but the reverse becomes more
                  >true when the system is put into a larger enterprise context and more
                  >"traditional" integration and decision support is required.

                  Then shouldn't you be mapping your data sources (some of which would
                  be described by PDMs) to a LDM (or similar) so that you can then map
                  to whatever data consolidation strategy (e.g. data marts, data
                  warehouses, ...) that you may have?


                  >This approach is fine for using a relational database as just another
                  >back-end storage mechanism. I have found a business-driven approach
                  >starts with a business process (what needs to be done) and business
                  >intelligence (how is success measured) perspective leads to what could
                  >be called a "value-cost chain" or in Ralph Kimball's terms a "data bus
                  >architecture".

                  Yes, but when you're working with object technology you're better off
                  to map the classes to your table schema. When you're using non-OO
                  technology, then perhaps you might want to consider using an
                  LDM. Isn't Kimball's advice presented within the scope of building
                  data warehouses, not object apps? Use the right techniques for the job.


                  >The outcome of this is a matrix view of these chains of information and
                  >processes at the high level and a set of related star schema models at
                  >the more detailed level.
                  >
                  >Objects and processes fall out of this and the O/R mapping is less of a
                  >technical problem than the (un-)pickling of an object model only
                  >concerned with an in-memory transaction processor.

                  Perhaps from the point of view of a data warehouse, but several
                  million object developers would tell you different.


                  >This approach is more appropriate for an overall service-oriented
                  >architecture than an isolated one-off application. Within an overall IT
                  >strategy we have taken significant strides to move away from these kinds
                  >of apps and move toward a more enterprise wide planning and
                  >architecture.

                  The agile community generally doesn't work like that. Instead our
                  approach to enterprise issues is a fair bit more robust (data is only
                  one of many issues that we take into consideration). See
                  http://www.agiledata.org/essays/enterpriseArchitecture.html ,
                  http://www.agilemodeling.com/essays/amdd.htm , and
                  http://www.agilemodeling.com/essays/agileArchitecture.htm for starters.

                  - Scott

                  ====================================================
                  Scott W. Ambler
                  Senior Consultant, Ambysoft Inc.
                  www.ambysoft.com/scottAmbler.html

                  www.agiledata.org -:- www.agilemodeling.com -:- www.ambysoft.com
                  -:- www.databaserefactoring.com -:- www.enterpriseunifiedprocess.com
                • jgo456
                  ... Harrumph! Most of what I ve seen data-bases abused for is massive privacy violation... by both governments and businesses. They demand more information
                  Message 8 of 10 , Jan 13, 2006
                    > In agileDatabases@yahoogroups.com, "Logan, Patrick D" <
                    patrick.d.logan@i...> wrote:
                    > ...This approach is fine for using a relational database
                    > as just another back-end storage mechanism. I have
                    > found a business-driven approach starts with a business
                    > process (what needs to be done) and business
                    > intelligence...

                    Harrumph! Most of what I've seen data-bases abused for is massive
                    privacy violation... by both governments and businesses. They demand
                    more information than is necessary to accomplish the customer's
                    purpose in engaging in the transaction, and keep it far beyond the
                    reasonable time needed to bring the transaction to closure without
                    the customer's explicit permission, then abuse the information for
                    purposes explicitly opposed by the customer who loaned the
                    information. So, stifle the blather about business idiocy and
                    business purposes.

                    Some people just dump objects into globs.

                    It's been my (admittedly long-term but limited) experience that using
                    objects, which are abstractions, to map into abstract attributes
                    works best.

                    The real difficulties, regardless of approach, arise when
                    refactoring, but we're just now beginning to see effective tools.
                  • Logan, Patrick D
                    Isn t Kimball s advice presented within the scope of building data warehouses, not object apps? Use the right techniques for the job. Many ideas are useful
                    Message 9 of 10 , Jan 14, 2006
                      "Isn't Kimball's advice presented within the scope of building
                      data warehouses, not object apps? Use the right techniques for the
                      job."

                      Many ideas are useful beyond their domain of origin. What evidence do
                      you have that this is not the right technique? Or is your mind already
                      made up a priori?

                      -Patrick
                    • Scott Ambler
                      ... From: Logan, Patrick D Reply-To: agileDatabases@yahoogroups.com Date: Sat, 14 Jan 2006 23:48:15 -0800 ... Actually, it s
                      Message 10 of 10 , Jan 19, 2006
                        ---------- Original Message ----------------------------------
                        From: "Logan, Patrick D" <patrick.d.logan@...>
                        Reply-To: agileDatabases@yahoogroups.com
                        Date: Sat, 14 Jan 2006 23:48:15 -0800

                        >"Isn't Kimball's advice presented within the scope of building
                        >data warehouses, not object apps? Use the right techniques for the
                        >job."
                        >
                        >Many ideas are useful beyond their domain of origin. What evidence do
                        >you have that this is not the right technique? Or is your mind already
                        >made up a priori?

                        Actually, it's based on years of experience doing this stuff. I've seen this approach taken before in the past and frankly it didn't work out too well. The data folks liked it, but the overall picture proved less than perfect.

                        - Scott

                        >
                        >-Patrick
                        >
                        >
                        >
                        >
                        >Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.