-1

I'm new to data modeling. Currently working at creating a personal contact manager but I need some help with modeling the table relationships for a given view.

The final view columns I'm shooting for are:

  • orgName (that a PERSONAL_CONTACT belongs to)
  • contFirstName
  • contLastName
  • phnNumber where phnType = "Primary"
  • socHandle where socType = "Primary"
  • emailAddress where emailType = "Primary"
  • addrAddress where addrType = "Primary"

The current ER diagram is: enter image description here

This table setup doesn't look correct to me.

Both ORGANIZATIONS and PERSONAL_CONTACTS can have their own EMAIL, PHONE, SOCIAL and PHYSICAL_ADDRESSES, but a PERSONAL_CONTACT can only exist in a single ORGANIZATION.

Is this the correct way to organize these tables or am I approaching the relationships incorrectly?

EDIT 1: Based on @Akina 's input enter image description here

EDIT 2: enter image description here

EDIT 3:

  • This is where I ended up with the table schema enter image description here
SeaDude
  • 111
  • 5
  • 1
    but a PERSONAL_CONTACT can only exist in a single ORGANIZATION. This is easily provided by foreign key + NOT NULL condition. I do not see the incorrectness in this point. – Akina Apr 20 '21 at 08:04
  • 1
    But I see incorrectness in referencies to contact information. You must have independent tables for contacts and separate junction tables between objection (org., pers.) and contact tables. For example, the same address may be a contact for the organization (or even for 2 or more organizations) and for a lot of persons which belongs to this organization - current scheme does not provide this relation. – Akina Apr 20 '21 at 08:07
  • Thank you for the input. Do you mean I should break out the xOrgGUID and xPersContactGUID into bridge tables as shown in OP EDIT 1 ? – SeaDude Apr 20 '21 at 15:44
  • I mean, you need to delete everything and start from the beginning. But first perform a complete analysis of the subject area. PS. Maybe "subject area" is not correct term - but I don't know how to translate the term from Russian more correctly. – Akina Apr 20 '21 at 16:37
  • I'm trying to analyze the space. Being new to data modeling, I'm looking for insights on which scenarios need to be covered. I think EDIT 2 covers your scenario, right? I simplified the columns too to make things easier to communicate. – SeaDude Apr 21 '21 at 01:17
  • I believe now, an Org can have 1 or many Pers.Contacts. Also both Orgs and Pers.Contacts can have 1 or many individual contact types (Social, Email, Phone, Physical Address). – SeaDude Apr 21 '21 at 01:18
  • This looks like a way to EAV... – Akina Apr 21 '21 at 04:51
  • I'm not familiar with the term "EAV". Anyway, I found great guidance on this post on how to abstract the ORG and CONTACT away to a "PARTY". I think this in combination with the bridge tables should do fine. – SeaDude Apr 23 '21 at 05:21
  • 1
    I'm not familiar with the term "EAV". Entity-Attribute-Value pattern. – Akina Apr 23 '21 at 05:38

1 Answers1

1

Look at:

organization ( orgGUID PRIMARY KEY, 
               orgName, ... );

person ( personGUID PRIMARY KEY, orgGUID REFERENCES organization (orgGUID), personName, ... );

contact ( contactGUID PRIMARY KEY, contactValue, contactType ENUM ('address', 'phone', ...), additionalAttributes );

junction ( orgGUID REFERENCES organization (orgGUID), personGUID REFERENCES person (personGUID), contactGUID REFERENCES contact (contactGUID), additionalAttributes, CHECK (orgGUID IS NULL or personGUID IS NULL) );

Akina
  • 19,866
  • 2
  • 17
  • 21
  • Yours above is a good approach, but I'm not sure contactType is usable in this context. For example, if an address is selected, it will have countryName, countryCode, state, city, streetName, houseNumber, etc. If phone is selected, it will have completely different columns. A single contact table would have many nulls. I've broken each contact type into a unique table. Then using your concept of junction tables. Still need help on the view statement though. Please see EDIT 3 if you can! – SeaDude Apr 26 '21 at 05:37
  • 1
    @SeaDude For example, if an address is selected, it will have countryName, countryCode, state, city, streetName, houseNumber, etc. In this case the value of contactValue must be a reference to Address tables chain (unique address point code which allows to define all mentioned parameters). If phone is selected, it will have completely different columns. ?? why? contactValue in this case stores the phone number, and additionalAttributes may store, for example, the marks "this is additional phone contact" and "call from 09-00 till 18-00 workdays only"... – Akina Apr 26 '21 at 05:47
  • Understood, ok. Very similar to what I ended up with above and the way MDCCL structured things in the post linked to earlier. Looks like we're in accord. – SeaDude Apr 26 '21 at 06:01