Editing WinFS (section)

===Data model===
WinFS models data using the data items, along with their [[RDBMS|relationships]], extensions and rules governing its usage.<ref name="WinFSFiles" /> WinFS needs to understand the type and structure of the data items, so that the information stored in the data item can be made available to any application that requests it. This is done by the use of schemas. For every type of data item that is to be stored in WinFS, a corresponding schema needs to be provided to define the type, structure and associations of the data. These schemas are defined using [[XML]].<ref name="Dev1a" />

Predefined WinFS schemas include schemas for documents, e-mail, appointments, tasks, media, audio, video, and also includes system schemas that include configuration, programs, and other system-related data.<ref name="WinFSFiles" /> Custom schemas can be defined on a per-application basis, in situations where an application wants to store its data in WinFS, but not share the structure of that data with other applications, or they can be made available across the system.<ref name="WinFSFiles" />

====Type system====
[[Image:WinFS1.svg|thumb|WinFS Type Hierarchy]]

The most important difference between a file system and WinFS is that WinFS knows the type of each data item that it stores. And the type specifies the properties of the data item. The WinFS type system is closely associated with the .NET framework's concept of [[Object-oriented programming|classes and inheritance]]. A new type can be created by [[Object-oriented programming|extending]] and nesting any predefined types.<ref name="Dev1a" />

WinFS provides four predefined base types &ndash; ''Items'', ''Relationships'', ''ScalarTypes'' and ''NestedTypes''.<ref name="Dev1a" /> An Item is the fundamental data object which can be stored, and a Relationship is the relation or link between two data items. Since all WinFS items must have a type, the type of item stored defines its properties. The properties of an Item may be a ScalarType, which defines the smallest unit of information a property can have, or a NestedType, which is a collection of more than one ScalarTypes and/or NestedTypes. All WinFS types are made available as .NET CLR [[Class (computer science)|classes]].<ref name="MSDNMag" />

Any object represented as a data unit, such as contact, image, video, document etc., can be stored in a WinFS store as a specialization of the Item type.<ref name="MSDNMag" /> By default, WinFS provides Item types for Files, Contact, Documents, Pictures, Audio, Video, Calendar, and Messages. The File Item can store any generic data, which is stored in file systems as files. But unless an advanced schema is provided for the file, by defining it to be a specialized Item, WinFS will not be able to access its data. Such a file Item can only support being related to other Items.<ref name="Dev1a" />

[[Image:WinFS2.svg|thumb|Defining a new Type]]

A developer can extend any of these types, or the base type Item, to provide a type for their custom data. The data contained in an Item is defined in terms of properties, or fields that hold the actual data. For example, an Item ''Contact'' may have a field ''Name'' that is a ScalarType, and one field ''Address'', a NestedType, which is further composed of two ScalarTypes. To define this type, the base class Item is extended and the necessary fields are added to the class.<ref name="Dev1a" /> A NestedType field can be defined as another class that contains the two ScalarType fields. Once the type is defined, a schema has to be defined, which denotes the primitive type of each field, for example, the Name field is a String, the Address field is a custom defined Address class, both the fields of which are Strings. Other primitive types that WinFS supports are [[Integer]], [[Byte]], [[Decimal#Decimal fractions|Decimal]], [[IEEE 754|Float]], [[Double precision|Double]], [[Boolean data type|Boolean]] and DateTime, among others.<ref name="Dev1a" /> The schema will also define which fields are mandatory and which are optional.<ref name="Dev2">{{cite web | url = http://msdn2.microsoft.com/en-us/library/ms996631.aspx | title = A Developer's Perspective on WinFS: Part 2 |date=July 2004 | access-date = 2007-06-30 | author = Shawn Wildermuth | work = MSDN | publisher = Microsoft }}</ref> The Contact Item defined in this way will be used to store information regarding the Contact, by populating the properties field and storing it. Only those fields marked as mandatory needs to be filled up during initial save.<ref name="MSDNMag" /> Other fields may be populated later by the user, or not populated at all. If more properties fields, such as ''last conversed date'', need to be added, this type can be extended to accommodate them. Item types for other data can be defined similarly.

[[Image:WinFS3.svg|thumb|Relationships]]

WinFS creates [[RDBMS|tables]] for all defined Items.<ref name="Dev2" /> All the fields defined for the Item form the columns of the table and all instances of the Item are stored as rows in the table for the respective Items. Whenever some field in the table refers to data in some other table, it is considered a relationship. The schema of the relationship specifies which tables are involved and what the kind and name of the relationship is. The WinFS runtime manages the relationship schemas.<ref name="MSDNMag" /> All Items are exposed as .NET CLR [[Object-oriented programming|objects]], with a uniform interface providing access to the data stored in the fields. Thus any application can retrieve object of any Item type and can use the data in the object, without being aware of the physical structure the data was stored in.<ref name="Dev1a" />

WinFS types are exposed as .NET classes, which can be instantiated as .NET objects. Data are stored in these type instances by setting their properties. Once done, they are persisted into the WinFS store. A WinFS store is accessed using an ''ItemContext'' class (see [[#Data retrieval|Data retrieval]] section for details). ItemContext allows transactional access to the WinFS store; i.e. all the operations since binding an ItemContext object to a store till it is closed either all succeed or are all rolled back. As changes are made to the data, they are not written to the disc; rather they are written to an in-memory log. Only when the connection is closed are the changes written to the disc in a batch. This helps to optimize disc I/O.<ref name="DotNetShow" /> The following code snippet, written in [[C Sharp (programming language)|C#]], creates a contact and stores it in a WinFS store.

<syntaxhighlight lang="csharp">
// Connect to the default WinFS store
using (ItemContext ic = ItemContext.Open())
{
    // Create the contact and set the data in appropriate properties
    ContactEAddress contact = new ContactEAddress {
        Name = new PersonName {                      // Name is a ComplexType
            Displayname = "Doe, John",
            FirstName = "John",
            LastName = "Doe"
        },
        TelephoneNumber = new TelephoneNumber {     // Telephone number is a ComplexType
            Country = CountryCode.Antarctica,
            Areacode = 4567,
            Number = 9876543210
        },
        Age = 111                                     // Age is a SimpleType
   };

   // Add the object to the user's personal folder.
   // This relates the item with the folder pseudo-type, for backward
   // compatibility, as this lets the item to be accessed in a folder 
   // hierarchy for apps which are not WinFS native.
   Folder containingFolder = UserDataFolder.FindMyPersonalFolder();
   containingFolder.OutFolderMemberRelationship.AddItem(ic, contact);

   // Find a document and relate with the document. Searching begins by creating an
   // ItemSearcher object. Each WinFS type object contains a GetSearcher() method
   // that generates an ItemSearcher object which searches documents of that type.
   using (ItemSearcher searcher = Document.GetSearcher(ic))
   {
        Document d = searcher.Find(@"Title = 'Some Particular Document'");
        d.OutAuthoringRelationship.AddItem(ic, contact);
   }
   // Since only one document is to be found, the ItemContext.FindOne() method
   // could be used as well.

   // Find a picture and relate with it
   using (ItemSearcher searcher = Picture.GetSearcher(ic))
   {
        Picture p = searcher.Find(@"Occasion = 'Graduation' and Sequence = '3'");
        p.OutSubjectRelationship.AddItem(ic, contact);
   }

   // Persist to the store and close the reference to the store
   ic.Update();
}
</syntaxhighlight>

====Relationships====
A datum can be [[Relational model|related]] to one more item, giving rise to a one-to-one relationship, or with more than one items, resulting in a one-to-many relationship.<ref name="Dev1a" /> The related items, in turn, may be related to other data items as well, resulting in a network of relationships, which is called a many-to-many relationship. Creating a relationship between two Items creates another field in the data of the Items concerned which refer the row in the other Item's table where the related object is stored.<ref name="MSDNMag" />
[[Image:WinFS4.svg|thumb|WinFS Relationships]]
In WinFS, a Relationship is an instance of the base type Relationship, which is extended to signify a specialization of a relation. A Relationship is a mapping between two items, a Source and a Target. The source has an Outgoing Relationship, whereas the target gets an Incoming Relationship.<ref name="Dev2" /> WinFS provides three types of primitive relationships – ''Holding Relationship'', ''Reference Relationship'' and ''Embedding Relationship''.<ref name="Dev1a" /> Any custom relationship between two data types are instances of these relationship types.

* '''Holding Relationships''' specify ownership and lifetime (which defines how long the relationship is valid) of the Target Item. For example, the Relationship between a folder and a file, and between an Employee and his Salary record, is a Holding Relationship – the latter is to be removed when the former is removed. A Target Item can be a part of more than one Holding Relationships. In such a case, it is to be removed when all the Source Items are removed.
* '''Reference Relationships''' provide linkage between two Items, but do not have any lifetime associated, i.e., each Item will continue to be stored even without the other.
* '''Embedding Relationships''' give order to the two Items that are linked by the Relationship, such as the Relationship between a Parent Item and a Child Item.

Relationships between two Items can either be set programmatically by the application creating the data, or the user can use the WinFS Item Browser to manually relate the Items.<ref name="Dev2" /> A WinFS item browser can also graphically display the items and how they are related, to enable the user to know how their data are organized.<ref name="MSDNMag" />

====Rules====
WinFS includes ''Rules'',<ref name="Rules">{{cite web |url=http://blogs.msdn.com/winfs/archive/2005/10/10/479416.aspx |title=About WinFS Rules |author=Kati Dimitrova |publisher=[[Microsoft]] |work=[[MSDN]] |access-date=March 2, 2018 |archive-url=https://web.archive.org/web/20081226193655/http://blogs.msdn.com/winfs/archive/2005/10/10/479416.aspx |archive-date=2008-12-26 |url-status=dead }}</ref> which are executed when a certain condition is met. WinFS rules work on data and data relationships. For example, a rule can be created that states that whenever an Item is created which contains field ''"Name"'' and if the value of that field is some particular name, a relationship should be created that relates the Item with some other Item. WinFS rules can also access any external application. For example, a rule can be built which launches a ''Notify'' application whenever a mail is received from a particular contact.<ref name="Rules" /> WinFS rules can also be used to add new properties fields to existing data Items.<ref name="Rules" />

WinFS rules are also exposed as .NET CLR objects. As such any rule can be used for any purpose. A rule can even be extended by inheriting from it to form a new rule that consists of the condition and action of the parent rule plus something more.<ref name="Rules" />