How do I design a DAL when I have to deal with relationships?

Question

Say I'm developing a bug tracker, where a ticket belongs to at most one milestone, and a milestone can have many tickets. When a milestone is deleted (from the database), all tickets associated with that milestone must have their relationship unset (i.e. set to null). This is a simple relationship.

The classes are fairly simple, and map directly to a database:

public class Ticket {
    public ObjectId Id { get; set; }
    public string Title { get; set; }
    public ObjectId MilestoneId { get; set; }
}

public class Milestone {
    public ObjectId Id { get; set; }
    public string Title { get; set; }
}

Now comes the tricky part: where and how do I reset the MilestoneId fields? One possible solution is to write a data access layer by creating one giant class with all data accessing methods for all kinds of objects, in this case tickets and milestones. Another possible solution is to write several classes (e.g. TicketProvider and MilestoneProvider), one for each kind of object, that provide data accessing methods such as Find, Save and Destroy.

The latter appeals more to me since I don't like monsterous classes, but there is one caveat: the method that deletes milestones has to reset the MilestoneIds of all associated tickets to null. This means that MilestoneProvider, which is responsible for manipulating milestones, suddenly deals with tickets!

How are relationships commonly dealt with in data access layers, and how can I prevent violation of SRP? Should I put the entire DAL in one class, or should I separate it and if so, how can I best do that?