Planning is paramount when it comes to designing a solution. In the case of the learning center, there are a number of interconnected pieces, so the order of implementation is important. There are also multiple ways to fulfill the same goal.
In this solution you need to store classes, documents, discussion threads, and links. SharePoint provides a number of out-of-the-box features that map to these components. Classes, for example, can be stored on a calendar.
Storing documents deserves a little additional consideration. Most SharePoint list items can have a column for attachments, which could fulfill the need for associated documents. However, as described in the business problems, the existing system has duplicates of documents, which has led to a waste of server disk space. To avoid this duplication, it is best to split documents into a separate document library that can be shared across multiple classes.
Because of the number of connected pieces that are required, it is helpful to remove user error from as much of the process as possible. To facilitate this goal, the solution will implement a few simple workflows to automate many rote tasks. These include creating an announcement for new classes.
If you happen to be using SharePoint Server (Standard or Enterprise) you will have access to a new feature called document sets. Document sets allow you to group multiple related documents into a single entity for easier usage and management. If your class documents consist of a standard template (for example, a syllabus, survey, homework, and so on), you might want to look into using document sets. Since this chapter is focused on SharePoint Foundation, document sets will not be covered in detail.
See Also
Read the following TechNet article for additional information on document sets: technet.microsoft.com/en-us/library/ff603637.aspx.
Users make up one portion of the solution. Another portion relates to the data that is to be captured. Here are the data types that will be required:
Class calendars
Class documents
Class links
Class discussions
Class announcements
Your organization might require additional data to be captured. These data types should serve as a basis to build upon if necessary. You will be building these data types into a SharePoint site infrastructure using out-of-the-box components.
Associating classes to their related components can be done in one of two ways: with a class as the parent in a relationship or with a class as a child in a relationship. The first of the following illustrations shows the logical architecture of class as parent, and the second chart shows the logical architecture of class as child.
If the class is the parent in the relationship, the class can have zero to many child components (documents, links, and so on). This may be ideal if child components are always unique (if each class has a separate set of documents, discussions, links, and so on that are not shared with any other classes.) This model is implemented by lookup columns pointing from the child entities to the parent class.
One benefit of this approach is that you can relate content to a single class and enforce a cascading deletion (more on this shortly.) This means that when you delete a class item, any associated items are also deleted. This could be useful in speeding up the process of removing content.
There is, however, a significant downside to this approach that needs to be considered. The user who is adding or editing content has to define the relationship from each child item to its parent. In SharePoint, this means navigating to each document, discussion, or other item and assigning the associated class ID. This can be a very time-consuming process. In addition, when you view a class, you won’t have a clear view of which content is associated with the class.
If the class is the child in the relationship, the class can have zero to many parent components. This may be favorable if associated components are reused among multiple classes (in other words, if multiple classes use a single document, discussion, link, or so on). This model is implemented by lookup columns pointing from the class to the parent entities. You might notice that this model involves a class having multiple types of parent entities.
There are two major benefits of this approach. First, when you view a class you can instantly see the associated content because the lookup columns are located on one item. This is helpful in addressing the first business issue: unifying content in one location. The second benefit is that multiple classes can be associated with the same content. This fulfills the desire to reduce disk usage.
The downsides to this approach are mostly conditional. If a class presenter modifies the content of an associated document, those changes are also applied to any other classes that are associated with that document. This could cause issues unintentionally if the changes are not meant for the other classes.
See Also
To read additional information about lookup column software boundaries and limits, go to technet.microsoft.com/en-us/library/cc262787.aspx#Column.
Now that you have read about the advantages and disadvantages of both relationship patterns, it is time to make a decision. In this scenario, content is reused frequently and ease of administration is important. Based on these priorities, you should implement your associations using the class as child pattern.
At this point it will be good to cover a feature new to SharePoint 2010: lookup columns with enforced relationships. Linked lists are not a new concept. In previous versions of SharePoint (and still with SharePoint 2010) you are able to use lookup columns that allow you to relate records from one list to a record in another list. In SharePoint 2010, a Relationship attribute has been added with an option to enforce relationship behavior.
The two options for the Relationship attribute are restrict delete and cascade delete. In simplified terms, restrict delete means a parent record cannot be deleted if a child record exists. Cascade delete means deleting the parent record will also delete any child records. The following screenshot illustrates an example of creating a new lookup column with cascading deletion configured. After providing a column name and selecting the column type Lookup (Information Already On This Site), look to the bottom of the form and select Enforce Relationship Behavior. Then select the Cascade Delete option.
The one exception to this relationship behavior is if you select Allow Multiple Values under In This Column. If this option is selected, the current item can have multiple parent records in the target list. In that scenario, the Enforce Relationship Behavior check box is disabled so that you cannot have cascading or restricted deletion. Logically this makes sense because it is impossible to enforce a relationship when multiple dependencies are involved.
See Also
Read the following MSDN article for additional information about list relationships in SharePoint 2010: msdn.microsoft.com/en-us/library/ff798514.aspx.