One-to-many, many-to-one

One-to-many relationships are used in general for parent-children or whole-elements relations. Classic examples are: bus and passengers, document and elements etc.

One-to-many relationship means that the one-end entity knows about its children and many-end entity has a reference (foreign key) to its parent (but not necessarily knows about it).

On the other hand, the opposite relationship to one-to-many is many-to-one. In that case, many-end entity has a reference to its parent and knows about it, but the one-end entity doesn’t necessarily know about its children (at least not directly).

I used a verb to know several times – so it’s time to explain it 🙂 By “knowing” about the other end of a relationship I understand having a reference to it. It means that, for instance, in many-to-one relationship, the one-end of it doesn’t have a reference to its children.

However in most cases what we’d like to have is a hybrid of one-to-many and many-to-one relationships. I will call it one-to-many with inversion. We want both parent to know about its children, and each children to know about its parent.

In this post we’ll cover one-to-many with no reversion and one-to-many with reversion, as it also includes many-to-one relationship so you can have a comprehensive overview. We are going to see it on the example of Employee and Duty* entities. Each employee has a list of his duties, whilst each single duty is assigned to only one employee.

* “Task” would probably be a better name, but I didn’t want to make it confused with .NET Tasks 🙂

One-to-many with no inversion

Firstly, let’s model this kind of relationship:

Now we can transform it into C# classes:

In the Employee class (parent, one-end of the relationship) we define the collection of children, decorated with OneToManyAttribute. Collections types supported as for the time of writing this post by SQLite-Net Extensions are List and Array and can be used as you prefer.

Let’s now see how the child entity (Duty) looks like:

In the Duty class (child, many-end of the relationship) we need to have a foreign key to parent entity defined. For that purpose, we create a property representing it (EmployeeId), decorating it with ForeignKeyAttribute, additionally specifying the type of parent referenced (Employee).

That’s it. We can already use it in our code:

No rocket-science here. What’s interesting for us it how employeeStored looks in the end:

As you can see, GetWithChildren method returned object of type Employee with its Duties collection properly retrieved (containing two duties assigned to the employee before). Moreover, each children has its foreign key (EmployeeId) automatically retrieved from the DB – there is no overhead here, this is simply foreign key field stored in the same SQLite database table (Duties).

One-to-many with inversion (one-to-many + many-to-one)

As previously, let’s first see how the class diagram changes after adding inversion:

What changed is that now each Duty has a property of type Employee.

To realize the above class diagram and make each children (each Duty in our case) knowing about its parent (having a reference to responsible Employee), the only thing we need to do is to add the following property to Duty model class:

[ManyToOne]
public Employee Employee { get; set; }
so the model class finally looks as follows:








  





  [Table("Duties")]



  public class Duty



  {



      [PrimaryKey, AutoIncrement]



      public int Id { get; set; }








      public string Description { get; set; }








      public DateTime Deadline { get; set; }








      [ForeignKey(typeof(Employee))]



      public int EmployeeId { get; set; }








      [ManyToOne]



      public Employee Employee { get; set; }



  }






        view raw

        

          Employee_withInv.cs

        

        hosted with ❤ by GitHub
      


As you can see, we have just created many-to-one relationship by using ManyToOneAttribute. So currently we have the hybrid of both types of relationships within out two models.
The usage in our code doesn’t need to be changed at all. Now, employeeStored entity after being initialized by the same GetWithChildren method as previously, for each Duty in addition to EmployeeId field also contains Employee property properly retrieved by SQLite-Net Extensions:

Again, there is no db overhead here, because when retrieving Employee entity from the database we already have it, so the operation of initializing the Employee entity in each Duty contained within Duties collection doesn’t require any more database querying.
Summary
Today we’ve seen how to model and use one-to-many (with and without inversion) relationships in SQLite database with the usage of SQLite-Net Extensions. The automatic initialization of one-end or many-end entities by the ORM is extremely helpful when dealing with such kind of objects in our app. The amount of code to be written is also minimal.
We’ve covered one-to-many and a hybrid of one-to-many + many-to-one relationships, but of course you can also define just many-to-one relationship – the models would then look as in this Gist. For me, it makes very limited sense, but maybe can be useful in some specific situations.
I invite you to read my other posts about SQLite-Net Extensions ORM, where we also covered the other types of relationships that can be modeled using this library.
As this is already the third post from this series, I’d like to ask you: what do you think about SQLite-Net Extensions ORM? Do you find it useful? Do you use it in your apps? Can you can recommend some other libraries/ORMs to use with SQLite database that allow to model different kind of relationships?
The post SQLite-Net Extensions – one-to-many relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-many-relationships/feed/
			2
		
		
		2251	
		
		
		https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/#comments
		
		
		Sun, 21 May 2017 10:18:15 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2238

					In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM. One-To-One This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated…

The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
										In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM.


One-To-One
This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated with one and only one vehicle (excluding some extraordinary law rules in other countries that I don’t know  ).
We can model it in two ways:

as a one-way relationship – in this case only one of the relationship’s ends knows about the other one
as a both-ways (with inversion) relationship – both relationship’s ends know about each other.

One-To-One with no inversion (one-way)
This kind of relationship looks as follows:

We use it when we assume it’s enough that Vehicle knows about RegistrationCertificate, but the document doesn’t necessarily need to know which car/motor it’s associated with (at least directly).
In the code, we then create two model classes using SQLite-Net Extensions:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }



    }






        view raw

        

          RegistrationCertificate.cs

        

        hosted with ❤ by GitHub
      










  





    [Table("Vehicles")]



    public class Vehicle



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Brand { get; set; }








        public DateTime ProductionDate { get; set; }








        public decimal EngineCapacity { get; set; }








        [ForeignKey(typeof(RegistrationCertificate))]



        public int RegistrationCertificateId { get; set; }








        [OneToOne]



        public RegistrationCertificate RegistrationCertificate { get; set; }



    }






        view raw

        

          Vehicle.cs

        

        hosted with ❤ by GitHub
      


What’s interesting here is the ForeignKeyAttribute defined on RegistrationCertificateId property. It is – as its name says – the foreign key to the primary key of related entity (of type RegistrationCertificate).
The related entity property itself is decorated with OneToOneAttribute.
There’s nothing more we need to do to have this relationship modeled. We can already use it:








  





    var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



    db.CreateTable<Vehicle>();



    db.CreateTable<RegistrationCertificate>();








    var vehicle = new Vehicle



    {



        Brand = "Renault",



        EngineCapacity = 1.9m,



        ProductionDate = new DateTime(2001, 01, 01)



    };








    var certificate = new RegistrationCertificate



    {



        RegistrationNumber = "AB 12345",



        OwnerData = "Dawid Sibiński",



        VIN = "1312BS1312ASDSSVVW"



    };








    db.Insert(vehicle);



    db.Insert(certificate);








    vehicle.RegistrationCertificate = certificate;



    db.UpdateWithChildren(vehicle);








    var vehicleStored = db.GetWithChildren<Vehicle>(vehicle.Id);






        view raw

        

          OneToOne_noInv.cs

        

        hosted with ❤ by GitHub
      


Nothing special here, right? It looks very similar to what we’ve seen in the previous post about many-to-many relationships. What’s interesting for us it that in the end, when Vehicle object is retrieved from the database using GetWithChildren method, its RegistrationCertificate property is filled as well:

One-To-One with inversion (both-ways)
This kind of relationship models itself as below:

What actually changed on the diagram compared to the relationship with no inversion is that now RegistrationCertificate has a property of type Vehicle (in the code – a reference to Vehicle related object and a foreign key).
In our case, this is even more “real” – it would be nice if a Vehicle knows about its RegistrationCertificate, but also when we look at the certificate we’d like to see to which car it belongs.
We can now model it in the code. The only thing that changes in the model classes is addition of a reference and foreign key to Vehicle in RegistrationCertificate model, so I’m presenting only this class’s updated code:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }








        // added to have Inversion relationship



        [ForeignKey(typeof(Vehicle))]



        public int VehicleId { get; set; }








        [OneToOne]



        public Vehicle Vehicle { get; set; }



    }






        view raw

        

          RegistrationCertificate_withInv.cs

        

        hosted with ❤ by GitHub
      


What’s cool here is that we don’t need to modify our code for saving entities with relationships into SQLite database. We can simply add the following line at the end:
var certificateStored = db.GetWithChildren&lt;RegistrationCertificate&gt;(certificate.Id);
and notice that certificateStored already contains its associated Vehicle object:

Summary
In today’s short post we’ve seen how to create one-to-one relationship between two entities in SQLite database, using SQLite-Net Extensions ORM. It’s very easy and doesn’t require using Entity Framework  or writing SQL queries directly in our code.
We’ve covered two types of one-to-one relationships: one-way and both-ways. The choice between those two depends on the usage and purpose of the relationship we model.
I hope you’ll find it useful one day 
The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/feed/
			2
		
		
		2238	
		
		
		https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/
					https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/#comments
		
		
		Thu, 18 May 2017 21:23:31 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2218

					In today’s post we’re going to see what is SQLite-Net Extensions ORM and how to use it to create many-to-many relationship in SQLite database. The other types of relationships will be described in separate posts. What is SQLite-Net Extensions ? As you develop any mobile app, sooner than later you need to keep your app’s data…

The post SQLite-Net Extensions – many-to-many relationships appeared first on CodeJourney.net.
]]>
										In today’s post we’re going to see what is SQLite-Net Extensions ORM and how to use it to create many-to-many relationship in SQLite database. The other types of relationships will be described in separate posts.


What is SQLite-Net Extensions ?
As you develop any mobile app, sooner than later you need to keep your app’s data in some persistent storage. In my MoneyBack project I’ve chosen SQLite database using SQLite.NET library for performing operations on it. This is actually very simple and easy-to-use database framework, but I recently realized I need to model some relations in my database.  SQLite.NET doesn’t offer any nice utilities to model such relations.
However, if you need to model any relations in your SQLite database, there is a wrapper on SQLite.NET which allows to do that – it is SQLite-Net Extensions. It basically extends the core functionalities of SQLite.NET by adding elements that allow to easily handle relationships, including one-to-one, one-to-many, many-to-one and many-to-many.
In this post we are going to see how to create many-to-many relationship using this library. I needed this kind of relationship to model the connection between Person and Event entities in my app.
Many-to-many relationship
Let’s see many-to-many relationship on an example of two entities: Person and Event. An event (entity of type Event) may contain zero or more participants (entities of type Person) whilst a person may be assigned to zero or more events. This is a typical many-to-many relationship which we are going to set up in our database now.
Install SQLite-Net Extensions
If you’ve previously been using SQLite.NET in your project – uninstall it first. I didn’t do it before starting to use SQLite-Net Extensions and I have many troubles with Visual Studio resolving my references incorrectly. SQLite-Net Extensions is a wrapper for SQLite.NET, so it already contains this library and additionally extends it by adding some extra functionalities for handling relationships.
SQLite-Net Extensions can be installed as a Nuget package into your solution. According to the version you’d like to use, execute appropriate command in Package Manager Console in Visual Studio:

synchronous:
Install-Package SQLiteNetExtensions -Version 1.3.0

asynchronous:
Install-Package SQLiteNetExtensions.Async -Version 1.3.0


Define model classes
Next we need to define our Person and Event model classes and establish the relationships between them. Below, you can find the code of both classes:








  





// Person class modelling People table



[Table("People")]



public class Person



{



    [PrimaryKey, AutoIncrement]



    public int Id { get; set; }








    public string Name { get; set; }








    public string LastName { get; set; }








    public string PhoneNumber { get; set; }








    public string Email { get; set; }








    [ManyToMany(typeof(PersonEvent))]



    public List<Event> Events { get; set; }



}













// Event class modelling Events table



[Table("Events")]



public class Event



{



    [PrimaryKey, AutoIncrement]



    public int Id { get; set; }








    public string Name { get; set; }



    public DateTime Date { get; set; }



    public string Place { get; set; }








    [ManyToMany(typeof(PersonEvent))]



    public List<Person> Participants { get; set; }



}






        view raw

        

          Person_Event.cs

        

        hosted with ❤ by GitHub
      


As you can see, the models look almost the same as SQLite.NET db entities, with the following exceptions:

ManyToManyAttribute – on both entities you can notice this attribute defined. On Person model class I decorate Events collection with it whereas on Event model class I decorate Participants collection with it. Simple as that.
PersonEvent – you may have noticed that as an argument to ManyToManyAttribute on both models I passed PersonEvent type. As you may know, in modelling many-to-many relationships we need an intermediate entity in order to store such kind of relationship in the database tables. The classic example is Student-Course relationship:


We also need to define such intermediate entity in our code.


The implementation of PersonEvent intermediate model class looks as follows:








  





public class PersonEvent



{



    [ForeignKey(typeof(Person))]



    public int PersonId { get; set; }








    [ForeignKey(typeof(Event))]



    public int EventId { get; set; }



}






        view raw

        

          PersonEvent.cs

        

        hosted with ❤ by GitHub
      


Thanks to PrimaryKey attributes defined on Person and Event entities the ORM will be able to determine to which primary keys the foreign keys in this intermediate table relate.
In the ManyToManyAttribute, except the type of intermediate entity, you can set CascadeOperations, which specifies how the cascading should be handled when working with the entities (e.g. if cascade delete operation should be performed when one of the relationship’s sides is removed).
Inserting and reading data
As soon as our model classes are defined, we can write and read the data with many-to-many relationships. The following code presents a simple way to create a new person and assign it to an event:








  





var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



db.CreateTable<Person>();



db.CreateTable<Event>();



db.CreateTable<PersonEvent>();








var event1 = new Event



{



    Name = "Volleyball",



    Date = new DateTime(2017, 06, 18),



    Place = "Sports hall"



};








var person1 = new Person



{



    Name = "A",



    LastName = "B",



    PhoneNumber = "123456789"



};













db.Insert(person1);



db.Insert(event1);








person1.Events = new List<Event> { event1 };



db.UpdateWithChildren(person1);








var personStored = db.GetWithChildren<Person>(person1.Id);



var eventStored = db.GetWithChildren<Event>(event1.Id);






        view raw

        

          SavingPersonEvent.cs

        

        hosted with ❤ by GitHub
      


Lines 1-4 contain the database initialization (Constants.DbFilePath just returns an Android path of SQLite database file) and creation of all 3 tables in the database.
Lines 6-18 are simply the creation of Person and Event objects, filled with most basic details.
In lines 21 and 22 we firstly save our person1 and event1 entities separately, because in order to establish the relationships we need the primary keys of those entities, that are assigned by the database while saving. This can be also simplified by using recursive operations – more details in the official documentation of the ORM.
After that, we assign just created person to the event (line 24) and then the most rocket-science part comes:
db.UpdateWithChildren(person1);
This method does the write magic – it updates the person with all its children – so in our case, the Events collection. It will make the relationship established.
In order to prove it, in lines 27 and 28 we can check if the relationship collections are populated with children in both entities by calling GetWithChildren extension methods:
 

That’s how SQLite-Net Extensions ORM works. It doesn’t provide any lazy-loading of related entities – it just adds/retrieves to/from the database exactly what you tell it to. The limitation here is that if you access Person.Events collection you can see the events this person is in relation with, but if you access Person.Events[0] you will not see all people registered for this event.
Summary
SQLite-Net Extensions is an ORM, which is a wrapper for classic SQLite.NET library. It adds the extension methods/attributes to handle relationships in SQLite database. It doesn’t provide any lazy-loading mechanism, instead exposing methods for getting/saving entities along with their children (related entities). It’s lightweight and rather easy to implement, so for small solutions like mobile apps I totally prefer it to writing and maintaining SQL queries directly in C# in order to handle relationships.
In the next posts from the series about SQLite-Net Extensions ORM, I will present to you the other types of relationships this ORM offers. Stay tuned 
 
The post SQLite-Net Extensions – many-to-many relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/feed/
			8
		
		
		2218