Your problem is related to the concept of the cardinality of relations. All relations have some power, which expresses the potential number of instances on each side of the relations that are its members, or can participate in one instance of the relationship. For example, for humans (for most living things, I think, with rare exceptions), the Parent-Child relationship has a power of 2 to zero or many , which means that two parents are required on the parent side, and there can be zero or many children (maybe it should be 2 to 1 or many )
In database design, as a rule, everything that has one (one), (or zero or one), on the one hand, can easily be represented by only two tables, one for each object (sometimes only one table is required; see note **) and the foreign key column in the table representing the "many" side, which points to another table containing the object on the "one" side.
In your case, you have a many to many relationship. (A task can have several predecessors, and each of the predecessors can certainly be a predecessor for several tasks). In this case, a third table is needed, where each row effectively represents the relationship between the two tasks, representing it as the predecessor of Others. Typically, this table is intended to contain only all the primary key columns of the two parent tables, and the own primary key is the collection of all columns in both parent primary keys. In your case, these are just two columns: taskId and PredecessorTaskId, and this pair of identifiers should be unique in the table, so together they form a composite PK.
When prompted to avoid double counts of data columns in parent tables when there are multiple joins, simply enter the query into the parent table ... for example, to find the duration of the longest parent, assuming your association table is called TaskPredecessor
Select TaskId, Max(P.Duration) From Task T Join Task P On P.TaskId In (Select PredecessorId From TaskPredecessor Where TaskId = T.TaskId)
** NOTE: In cases where both objects in the relationship have the same entity type, they can be in the same table. The canonical (luv is a word) example is a table of employees with many employee relations to the Supervisor ... Since the supervisor is also an employee, both employees and managers can be in the same table [Employee], and reality can be modeled using a foreign key (called SupervisorId) that points to another row in the same table and contains the employee record identifier for that employee.