Markus: As per the private email I sent you over the weekend, which you can most certainly send to the list if you like, I believe that you are confusing things that occur in nature (Organizations, People and Addresses) with the "Roles" that they play in your (or any) environment and implementation.
Have an Entity Object/Table that can contain two types of objects, People and Organizations. A variable in the object will tell you which type "this" object happens to be. Have an object/table that defines the role that any Entity is "playing" in any given situation. You can therefore have in infinite number of Role Types. Than have an "EntityAggregate" object/table if you need it. This would be used to relate multiple Entities together into any type of group you may need. Include an AggregateType variable and you can have an infinite number of aggregate types. This allows you to handle Departments, Offices, Spouses, Families or any other type of combination of people you may need. It also allows you to aggregate organizations should you need to do that, like all Vendors of a given type, or all Clients that are serviced by a given employee, or whatever. Then you have an Address Object/Table. Addresses can then be associated with any member of the Entity Table, or any number of members of the Entity Table, and you're all set. When an employee or Vendor or Client moves, you don't delete or change the existing (now old/obsolete) address from the table, you add the new one and flag it as "current" if you want. This way, old data will still display and associate to the correct old address that was valid at the time the invoice, or purchase order, or whatever was processed. It also allows you to use the "old" address on another Entity when some other Client or Vendor happens to rent the same space that had previously been occupied by the first one. We work in the Insurance Industry. This approach has stood the test of time (three decades) quite well. For instance, a person can be a Client, and also a spouse of another Client, and also the Parent of another Client, and therefor a member of a Family Aggregate. That same person can be a Driver on an Auto Policy, an Insured on various policies, an officer of a Client that is an Organization Entity, etc. These are all Roles that this Person Entity is playing. The person appears once in the Entity Table, but can be used for an unlimited number of Roles. Hope this helps, Joel ------------------------------------------------------------------------------------------ Joel M. Benisch CPCU, President 973-992-6300 x303 PaperFree Corporation 973-992-6666 FAX 909 Regal Boulevard [email protected] Livingston, NJ 07039-8249 WE CREATE PRODUCTS WE WOULD WANT TO USE! On Sep 16, 2013, at 8:59 AM, Markus Ruggiero wrote: > > On 15.09.2013, at 06:28, Theodore Petrosky <[email protected]> wrote: > >> Except Clients tend to be businesses with EINs instead of SSNs. So there >> really are Clients. But sometimes in accounting an employee is a vendor >> because you need to draw a check outside of the normal employee employer >> relationship. >> >> I am trying to normalize this structure. Maybe I shouldn't. I would love to >> hear other people's solutions. but to reiterate, Clients need addresses, >> People need addresses. if I create a table Address, I could relate it back >> to Client, and relate it to Person. >> >> So maybe I should change the name to: >> >> Business >> Person >> >> Person will have two booleans 'isEmployee', and 'isClient', with a SSN >> Business will have two booleans 'isClient', and 'isVendor' with an EIN >> >> both will have a to-many to Address and each address will have a type (i >> guess a business address will not be a 'love-nest'). >> >> I just never created an Entity that related back to two other Entities. So >> does that mean >> >> Business <=>> Addresses >> Person <=>> Addresses >> >> and because of the structure, the relations have to be optional. although an >> address will always be related to either a Business or a Person. >> >> >> Or how about an Entity Address and a subclass PersonAddress and another >> subclass BusinessAddress? >> >> Opinions? >> > > > I would model this like so: > > Entity "LegalEntity" with "Client" extending "LegalEntity" and "Business" > extending "LegalEntity". Both, Client and Business share many common > attributes like name etc, Both can have individual attributes like SSN for > Clients and EIN for Businesses. > Now the addresses: How to model these depends on the answer to the following > question: Can the same address be used for different purposes? > If no: > Create an entity "Address" and have one attribute called "addressType" or > some such. AddressType is one out of "home", "work", "love nest" etc. and > model "LegalEntity" <-->> "Address" > if yes: > Create an entity "Address" without a type specifier. Create an intermediate > entity like "LegalEntityAddress" with an attribute to specify the type. Model > the following relationships: > "LegalEntity" <-->> "LegalEntityAddress" <<-> "Address" > > Hope this helps. > Have fun > ---markus--- > > >> >> On Sep 14, 2013, at 10:29 PM, Ramsey Gurley <[email protected]> >> wrote: >> >>> Personally, I would look more closely at your person class. Is a client >>> actually a person too? It sounds like it. If so, I would not have a client >>> entity. I would simply make a person entity and assign each person one or >>> more roles. A person might have a client role, a vendor role, and a >>> customer role. Then you simply have a relationship between person and >>> address. >>> >>> >>> On Fri, Sep 13, 2013 at 9:29 PM, Theodore Petrosky <[email protected]> >>> wrote: >>> I need an opinion about relationships. >>> >>> I want to have an entity Person with a to-many to address. a Person could >>> have many addresses (home, second home, weekend place, love nest). >>> >>> And I have clients. a Client needs addresses too (billing, main office, act >>> rep, etc) >>> >>> how would you model this? >>> >>> a person entity with a to-many relationship to address >>> a client entity with a to-many relationship to address >>> >>> or would you create a subclass of address and map that to the clients. >>> >>> is it 'bad' to have two to-many relations to an entity, (both person, and >>> client mapped to entity address). >>> >>> Ted >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >>> >>> This email sent to [email protected] >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/mailinglists%40kataputt.com >> >> This email sent to [email protected] > > Markus Ruggiero > [email protected] > Check out the new book about Project Wonder and WebObjects on > http://learningthewonders.com/ > > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/joelb%40paperfree.net > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
