Document Types are one of the building blocks of umbraco very flexible, but sometimes over used for creating models where it just isn't appropriate, say for one field. That said I think in this case a document type of of author makes sense as each author could well have a page which shows a biography , a list of their books. Sometimes relationships are made through a parent, child association i.e with a repository and its children.

In other cases the relationships feature of umbraco offers one way or bi-directional associations between objects. These do need to have content node ids on the objects being related and therefore your entities would need to be document types.

Once you have created a relation type, one picker to form these relations automatically is nuPickers. The default umbraco multinode content picker does not do this automatically, though you can use the content save events to look at the picked items on your property and form the relationships yourself using the relationservice. nuPickers can derive the options available to editors from you content structure using xpath, static options, or external code using one of their DotNet pickers.

If you think will do a reasonable amount of many to many querying from different points across the site and it doesn't create a bloated node structure i would say use relationships.

Otherwise the model relationship will be defined by the property editor you use. A picker will give you a model with a list of ids for you to gather underlying data.

Nested content will give you a list of 'virtual' content nodes taking advantage of the properties available on real content nodes. (the data for this is only stored in the property editor model)

Archetype will store a set of fieldsets in json format (again on the property model) which contain the properties you create when configuring the datatype.

You create and edit 'relation types' in the developer section of umbraco.

You then use the relationservice to get the relations you require associated with a particular relation type.

This is the documentation for the relationservice. As you can see you can use this service to not only retrieve relations but to also create the associations from code.

As I say nuPickers saves the hassle of forming the associations leaving you to gather them in your razor templates using the most appropriate method from the relationservice.

In my case I had articles related to particular services. A bi-directional relationtype was created with document set a both and parent and child

Then when i was on an article and wanted to get other articles related by the same set of services i did this.

IEnumerable<IRelation> relations = rs.GetByChildId(CurrentPage.Id).Where(r => r.RelationType.Alias == "service");

then

foreach (IRelation relation in relations)
        {
            int relationId = relation.ParentId;
            IEnumerable<IRelation> siblingRelations = rs.GetByParentId(relationId).Where(r => r.RelationType.Alias == relationType && r.ChildId != relatedNodeId);

            siblingRelations = siblingRelations.Where(r => Umbraco.TypedContent(r.ChildId) != null).Where(r => Umbraco.TypedContent(r.ChildId).DocumentTypeAlias == CurrentPage.DocumentTypeAlias).OrderByDescending(r => Umbraco.TypedContent(r.ChildId).CreateDate);

            if (siblingRelations.Any())
            {
                @Html.Partial(partialViewAlias, siblingRelations,new ViewDataDictionary(this.ViewData) {
                          { "relatedNodeId", relationId }, { "repositoryNodeId", repositoryNode }});
                break;
            }
        }

One of the reasons I chose relations was for their 1 to many qualities and because I also wanted to relate my entities by other criteria too.

is working on a reply...