Conceptual ERD Multi-table many to many, or possibly recursive?

I'm creating a conceptual diagram [yes, I know I've included attributes and keys - but this is just for me to consolidate what I'm doing whilst learning] -- so please treat it as Conceptual with the focus on Relationships and tables and not how to diagram ;)

My mind hurdle is: I'm trying to ascertain the best way to model the Profile, Location and Organization relationships.

First of all,
RULES:

• One or more Profile's can be a Member/Friend of one or more Organizations; and vice versa.

• One or more Profile's can be a Member/Friend of other Profiles.

• One or more Organization's can be a Member/Friend of other Organizations.

Friend and Member differ, in that, Friends are like read-only and Members [depending on level] have full access to amend things.

To complicate things further, Locations have their own set of "further" refinable rules e.g. An Organization owns two Locations, but depending on Location rules, a Member [Profile] of that Organization may have full access at one Location, but restricted access at the other. [Sorry: you'll most likely have to open the image in another window for better viewing size.]

So as you can see, the concept of Profiles and Organizations are much the same, as well as this yet to be modelled concept of Friends and Members [...which I imagine will be handled much like the current intermediary tables with setting Owner / Admin / Member / Friend etc. in the record]. Hence, why I’m thinking of the following concept:

See Option.2 in the above image: which would remove the current Organization and Organization_Locations Tables and their relationships, replacing it with the Option.2 Organization Table as a somewhat recursive relationship with Profile.

I suppose the crux of the matter is whether or not I'm being too programmatically minded with Polymorphism to the detriment of simplicity and flexibility, confusing myself entirely in the process ;)

Thanks for your thoughts in advance, much appreciated - M :).

Revised Diagra

It is great that you are taking the time to understand, classify and model the data you are dealing with since, from my personal experiencie, all this makes the whole development process easier and very flexible for future changes. And I am quite sure that you are also aware of this already.
Preliminary data model and assumed business rules

I defined a list of business rules that I have assumed after reading your question and examining closely your diagrams, in order to describe my understanging of your specifications. After defining such list, I derived an IDEF1X[1] data model that I decided to upload as a .PDF document in an external platform (Dropbox), since due to its format this data model does not fit well in an embedded image. These two instruments are going to be useful as references for some important points that I enumerate below in the section entitled Aspects to resolve in order to keep moving forward.

First, here is the…

• Organizations and Profiles Preliminary Data Model.

Since it is only that, preliminary, consider it as an means helping us to acomplish the desired final data model.
Assumed business rules

Said preliminary data model was derived from a collection of business rules (inferred from your question) that I will enumerate as follows:

Organizations and profiles

Note that Profile is currently understood as a synonym for Person.

• An Organization is a friend of one-to-many Profiles.

• An Organization is a friend of one-to-many Organizations.

• An Organization is a member of one-to-many Organizations.

• A Profile is a member of one-to-manyOrganizations.

• A Profile is a friend of one-to-many Profiles.

• A Profile is a member of one-to-many Profiles.

Locations and addresses

-
An Organization owns one-to-many Locations.

-
A Location is classified by one-to-many LocationTypes (only one at a given point in time).

-
A Location may have one-to-many Addresses (one Physical, one for Shipping, one for Billing, or one that serves all said purposes, or one that combines two purposes and another that serves only one of them).

-
An Address may be kept by one-to-many Profiles or, put another way, a Profile keeps one-to-many Addresses.

-
A specific Address may be used by one-to-many Profiles (serving as Physical for one Profile, being used for Billing by a different one, etc.). So, an Address works in a similar way for Locations and Profiles.

• Thus, an individual Address may be, at the same time, of type Physical, Shipping and Billing.

Locations and roles

• A Location opens one-to-many Roles.

• A Role may be carried out in one-to-many Locations.

• A Profile (once it has been set as Member of an Organization) may carry out one-to-many Roles, in one-to-many Locations (but only one specific Role in each Location at a particular point in time, i.e., never two or more Roles at the same time).

Aspects to resolve in order to keep moving forward

In order to keep advancing in the resolution of your data model, here is a list of relevant points that, once we work them out, are going to help us to reach this goal:

-
I have assumed that the term Profile in your context has a similar (or the same) meaning as that of Person, but it could be a bit different. In this way, would you say that, in your scenario, the entities Organization and Person are subtypes of Profile?

-
Can a Profile (or Person) own one-to-many EmailAddresses, or is a Profile (or Person) fixed to exactly one EmailAddress?

-
Would you like to provide the possibility for an Organization to be contacted via Telephone and Email, or you want to restrict that to be possible only for a Profile (or Person)?

-
I assume that a Location is fixed to exactly one Address of the type Physical, is this correct?

-
Is it possible for a Location to be shared by one-to-many different Organizations or, otherwise, a Location can be owned by only one Organization?

-
You have stated via comments that the fact of being a Member and a Friend is the same. As you can see in my proposed preliminary data model, I followed you original specifications and depicted all the possible combinations of membership and friendship between Organization and Profile (or Person) in different entities since I think that it can be helpful in the effort of defining the best possible structure for that part of your scenario. In this sense:

• I assume that the the statement an Organization is a Member of another Organization has different effects than the statement a Profile (or Person) is a Member of an Organization regards the entity called Location.

• As you can see in the data model, I think that the Role of Owner is only valid for an Organization and, to me, the valid Roles for a Profile (or Person), inside a Location are Admin and Member. What do you think about all th

StackExchange Database Administrators Q#105195, answer score: 14