UPDATED: Relational (or NoSQL) Database Design
Which of the two options is the best?


The relational design is clearly superior to the hierarchical design used in the NoSQL example.  A database schema designed using relational principles does not favor one access path over another.  Each table represents a real world entity type and through the use of relational algebra queries of arbitrary complexity can be constructed to answer not only current questions of the data but any future questions you think of that haven't yet been conceived.  A hierarchical schema imposes a single structure upon the data - in this case work packages contain other work packages, the worker, and the parts, and the files.  If you want to ask questions of the data not aligned with this single view it will be much more difficult if not impossible.  Furthermore, the relational model includes a data integrity component to ensure data is consistent with respect to rules declared to it approximating the real world, whereas systems, like a NoSQL system, using a hierarchical or network model do not provide these.


  Should a Work Package reference the above Work Packages, or the contrary is better?


The best way to implement this is to create a new table that represents the links between the parent and dependent work packages while leaving the work package table to represent the work packages themselves regardless of dependency.  This design does not mix work packages dependent on other work packages with work packages that are not dependent on others.  A key advantage of the relational approach is that a single structure with a single set of operators - relational tables and relational algebra - can easily represent a hierarchy or a network.  Network DBMS's require two types - a node and a link - with two distinct sets of operators, and thus twice the complexity.  A hierarchical DBMS can't represent a network correctly at all.  This is a key reason why the NoSQL systems available today can only address a narrow set of use cases.  Fabian Pascal's book Practical Issues in Database Management, Chapter 7, gives an excellent overview of data hierarchies using SQL and I highly recommend it.


  There will be a substantial of reads, however the writes will be considerable less.


Another benefit of the relational approach is that the performance of the system can be managed to a great extent at the physical level without impacting the logical database schema used by applications to work with the data.  With the relational approach you can focus on the correct logical schema first and then in most cases let the DBA implement a correct physical design and infrastructure to best support the read heavy workload.  This is not the case in navigational systems where the programmer must specify the access paths directly in programs.