What Are the Principles Behind, and Benefits Of, the "Party Model"

What are the principles behind, and benefits of, the party model?

1. What are the core principles and motivating forces behind the party
   model?

To the extent that I've used it, it's mostly about code reuse and flexibility. We've used it before in the guest / user / admin model and it certainly proves its value when you need to move a user from one group to another. Extend this to having organizations and companies represented with users under them, and it's really providing a form of abstraction that isn't particularly inherent in SQL.

2. What does it prescribe you do to your data model? (My bit above is
   pretty high level and quite possibly
   incorrect in some ways. I've been on a
   project that used it, but I was
   working with a separate team focused
   on other issues).

You're pretty correct in your bit above, though it needs some more detail. You can imagine a situation where an entity in the database (call it a Party) contracts out to another Party, which may in turn subcontract work out. A party might be an Employee, a Contractor, or a Company, all subclasses of Party. From my understanding, you would have a Party table and then more specific tables for each subclass, which could then be further subclassed (Party -> Person -> Contractor).

3. What has your experience led you to feel about it? Did you use it, and if
   so, would you do so again? What were
   the pros and cons?

It has its benefits if you need flexibly to add new types to your system and create relationships between types that you didn't expect at the beginning and architect in (users moving to a new level, companies hiring other companies, etc). It also gives you the benefit of running a single query and retrieving data for multiple types of parties (Companies,Employees,Contractors). On the flip side, you're adding additional layers of abstraction to get to the data you actually need and are increasing load (or at least the number of joins) on the database when you're querying for a specific type. If your abstraction goes too far, you'll likely need to run multiple queries to retrieve the data as the complexity would start to become detrimental to readability and database load.

4. Did the party model limit your choice of ORMs? For example, did you
   have to eliminate certain ORMs because
   they didn't allow for enough of an
   "abstraction layer" between your
   domain objects and your physical data
   model?

This is an area that I'm admittedly a bit weak in, but I've found that using views and mirrored abstraction in the application layer haven't made this too much of a problem. The real problem for me has always been a "where is piece of data X living" when I want to read the data source directly (it's not always intuitive for new developers on the system either).

Relational Model - DBMS

The symbol "⊆" means "is a subset of".
In Album, mID is a foreign key to Musician's primary key mID.
For each and every given Album (aID)primary key there can only be one value for mID (not two or more), which points to a single row of Musician (mID) primary key. A primary key value should always be unique, else its not the 4th database normal form.

What is the formal model behind Sense/Net ECM?

It's curious that no one from SenseNet has answered, but I'll give it a shot even though I don't know a lot of the history. I've been working with SenseNet for the last 4+ years, developed the pysensenet extension, communicate with the developers, and am familiar with the source code, so I know a bit about the framework.

The framework has evolved over that last 15+ years and is pretty remarkable. Here are a few facts and highlights:

• The data model is at it's core an XML Tree where each tree node has an internal representation as a C# class and can hold any number of properties/Fields. This is referred to as Content, and the database as the Content Repository.
• The XML Tree is persisted in a SQL Database and uses Lucene.NET for indexing.
• Content / data queries are made in Lucene and not SQL.
• At one time the database was arbitrary (SQL), then stored procedures in MS SQL Server locked it into MS SQL, although recently (SenseNet 7) supports blob storage in MongoDB.
• Fields can be one of 9 built-in field types, or a custom type that you define.
• A node in the XML Tree, aka "Content", can hold a field that references another node somewhere else in the tree, like a linked list inside a tree! OK, a doubly linked list since both nodes can refer to each other. Very cool.
• There is no "external model", or as SenseNet says, "Everything is Content".
• The permission system is node based and is incredibly granular. For example, you can define permissions such that one role, group or person, can only see the Content at a particular node. And it integrates with Active Directory.
• All Content can be versioned and tracked. For example, a Content Type of "Contact" (person) could have versioning on for the person's name. This way if someone changed their name, the Content Repository would have a history of the all name changes.

Hopefully this doesn't come off as a SenseNet marketing piece -- I don't work for them and don't benefit if you purchase a license -- but may help you compare it to other technologies such as SharePoint and Alfresco.

Graph database design principles, general principles and granularity issue

There isn't anything I've seen that is taken as truth quite like normalization in relational databases. However, I'd advocate two things:

1) Model your entities (nodes) as you normally would. The attributes of those entities are things that belong specifically to those entities and exist outside of relations (connections).

2) Model your relationships (edges) as you normally would. Those attributes should not exist except where two entities (nodes) are related (connected).

Who has to do the Data Model design

Depends on how the responsibilities on your team are broken out. Normally, I would say the Technical Lead (Application Architect) would do the data model design. The DBA could then implement and tune the database to provide the best performance.

That could always changed based on the skills of the Technical Lead and the DBA though...

naming question - non programmatic question

Agreed with the other responders. More information about the domain is needed before getting really useful answers.

But I'd suggest ThirdParty or ExternalParty, since I'm assuming Customers and Subcontractors are external to your business. Internal parties could be User, InternalParty, etc.

I think you've tagged this question properly.

Hope this helps.

The logical model and the domain model

Here are the Wikipedia articles on the logical model and the domain model.

Based on what I read, the logical model is concerned with modeling the data objects and the relationships between the data objects, without any database considerations.

The domain model is concerned with modeling the processes and the relationships between the processes, without any computer language considerations.

I typically use a single logical/domain model for two purposes. The first is to establish a starting point for my physical data model. The other is to map out my classes in my business layer.

Your business object classes don't have to match your data model. As an example, you might have a Person class that on a relational database maps to several different tables; Person, Address, Phone Number, etc.

What to explain about a Data Model

First, you must start to appreciate that there is a difference between a CONCEPTUAL model and a LOGICAL one.

CONCEPTUAL models can be drawn in the form of an ERD, UML class diagram, or various other modeling/drawing techniques. Such models are almost always incomplete, and that's deliberate, as such models are used for the specific purpose of highlighting only certain aspects of a system.

LOGICAL models are the complete enumeration of :

(a) the full logical structure of all the tables in your database, PLUS

(b) a formal definition of all the constraints that govern this logical data structure.

"full logical structure" includes : name of the table, plus all the attribute definitions (name + data type).

"all the constraints" includes : the key constraints on the tables, the foreign key constraints between tables, PLUS all the other business rules that do apply to the model, but do not fit the first two categories.

Logical models as per this definition are hardly ever spelled out anywhere, so I think I'm safe assuming that you are actually not really talking of LOGICAL models, but CONCEPTUAL models instead.

And there the answer is : include or exclude stuff depending on what exactly the message is that you want to convey to your audience. If that includes data types of the attributes, then include the data types. If it doesn't, leave them out. If a certain table has no role to play in the story you want to tell the audience, leave it out (and of course also its relationships). If relationship cardinalities are important in your story/for your audience, include them. Otherwise, leave them out. etc. etc. etc.

---

Related Topics