@W3bbo: I'm not convinced you could meaningfully explain the properties of security groups using a venn diagram anyway, it'd just get too complex. And trying to do it hierarchically is pointless, because security groups don't follow a strict hierarchy in their behaviours.
I still don't understand what the OP is trying to accomplish. If someone asked me to describe Windows security in an AD environment I'd just use simple bullet-points:
A "User" is an identity that exists within the system that provides a context for doing something. You run Winword under the "Chris" User account so it has access to Chris' files. Windows services run under the "SYSTEM" identity and has root access.
Actions happen under a User's credentials after it has been authenticated - which happens either locally on your machine, or against a central server, which is why you can log-on to any computer in the office (because they share the the same central authentication server) but you can't use your home computer's login details on our computers.
"Objects" - such as your files and folders in the filesystem, or protected company services (CertSrv?) have an "Access Control List" which simply say "this user A can do x, and this user B can do y, but not z" and so on. If an object exists in a hierarchy (folders, registry keys, OUs, etc) then often that object's ACL is inherited by its children, unless a child explicitly defines a new ACL.
Users themselves can be organised into Groups, which are collections of users and groups (it's type-recursive) - this simplifies Access Control Lists, so rather than adding every 'Employee' User to a shared folder's ACL, instead there would be a group called "Employees" and that entire group is added to the ACL.
Trust relationships are for when different organisations want to allow other users access to their systems (and vice-versa).
That's pretty much it - I don't understand how this could be modelled as a "chain" or how security "flows" at all.