How can a field with multiple values be used with SQL Server? For example, I have a field in MongoDB like this:

"SignedDocs" : [

    { 
     "_id" : "blablabla"
     "title": " bla bla bla"
     },

    { 
     "_id" : "blablabla2"
     "title": " bla bla bla2"
     },

    { 
     "_id" : "blablabla3"
     "title": " bla bla bla3"
     }
]


For you to understand, inside this field there are 3 values. What would be the best way to achieve this with SQL Server? What is the best practice to save 3 values inside a column?

I don't want to do something like this:

NAME    | DOCSSIGNED 
abduh   |      1
abduh   |      2
abduh   |      3


Having lots of rows with the same values only changing this DOCSSIGNED field as a FK pointing to the DOCS table. 

EDIT: Ohh maybe a 3rd table between these 2 linking them?
On newer versions of SQL Server, you might consider bringing over the JSON data as-is, storing it in an nvarchar(max) column, and using the built-in JSON related functions for parsing and querying JSON data.  This is available in SQL Server 2016+ (compatibility level 130).  You can read more about it here: JSON data in SQL Server



If you plan to "convert" the MongoDB documents into a more relational pattern, the mapping table you mentioned would be a good way to prevent the "Name" of the signer being repeated in each row.  

It looks like what you're modeling in the MongoDB document is a collection of documents that have been signed by a given Person.  So the relational structure would be something like this:

A table for documents:

CREATE TABLE dbo.Docs
(
    ID int IDENTITY PRIMARY KEY NOT NULL,
    [Title] varchar(100) NOT NULL
);


A table for the people signing these documents:

CREATE TABLE dbo.Person
(
    Id int IDENTITY PRIMARY KEY NOT NULL,
    [Name] varchar(100) NOT NULL
);


And then the table that brings together all of the documents a person has signed:

CREATE TABLE dbo.SignedDocs
(
    PersonId int NOT NULL,
    DocId int NOT NULL,

    CONSTRAINT FK_SignedDocs_Person FOREIGN KEY (PersonId) 
        REFERENCES dbo.Person (Id),

    CONSTRAINT FK_SignedDocs_Docs FOREIGN KEY (DocId) 
        REFERENCES dbo.Docs (Id)
);


You could add more constraints to the table if there are other rules that need to be enforced (a document can only be signed by one person, for example).



Note that performing this sort of "ETL" process to convert NoSQL data to relational data can have a lot of maintenance overhead.  One of the advantages of a document database like MongoDB is that the structure of documents can easily be changed.  This has great potential to break the ETL.  Of course, every environment is different, so it might not be a problem for you.  I just thought it was worth mentioning.