One could just store the document itself in the database and not bother with any other tables around types etc. Most popular document systems have properties and meta data associated with it, so use that instead of a predefined system of tables.
You question is kind of broad, but let's assume that all the documents will be stored in the database as PDFs. Even if they weren't the process would work the same. One could have a standard set properties/meta data to the document and then read that data from the document itself (PDF) instead of the table(s).
If one needed to search or query, then extracting that information and putting it into a table so that one can write queries against it would be useful as mentioned by @Bent and others.
You could even go a step further and as the document is uploaded into the database your process examines the document meta data, stores important pieces of that data in a table for future reference, and saves the document and data. You wouldn't need any sort of reference tables because as users are uploading documents the meta data for the document is being used to classify and tag the document. That way new types are automatically added without the need for maintaining any of that reference data.
So, one table for Contract. One table for Documents. A many to many Contract/Document if documents can be shared across contracts. if not just go with the FK as mentioned by @Bent.
The document table could have the important properties as well or they could be separated out into separate reference tables.