MySQL Many to Many with additional data in intermediary table

I will be using MS SQL terms below but you can translate them into the DBMS that you will be using. I also made some assumptions that seemed logical, so you can drop those if they do not fit your model. I would setup the tables in the following manner:

Person Table
PersonID int PK
FName Varchar(50)
LName varchar(50)
DoB Date FK

Name Table
Name varchar(50) PK
Meaning varchar(MAX)
Origin int FK

DOB Table
DoB date PK
AstrologicalSign int FK

Wedding Table
WeddingID int PK
HusbandPersonID int FK
WifePersonID int FK

Origin Table
OriginID int PK
OriginDescription varchar(50)

Astrological Sign Table
AstrologicalSignID int PK
AstrologicalSignDescription varchar(50)

I am a visual person and it helps me to see things laid out graphically, so I am attaching a diagram as well.

The personID, astrologicalsignID, weddingID and originID are all setup as identity fields that auto increment. I can provide a SQL backup of the database if that would help you.

I don't know what your professor has really said I am not sure if I understand your model. But maybe the following is interesting.

In the article A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model by T.J Teory, D. Yang and J.P. Fry is described how entity relationship diagrams can be transformed to relations (and tables). In Fig.8f (on the p 13 of the pdf) there is the following example for an 1:n relationship:

Each engineer can have at most one secretary. One secretary could work for several engineers.

There is a relationship "works-for" between the entities "secreatry" and "engineer".

• A "secretary" "works-for" an "engineer".
• Each "engineer" has at most one "secretary" that "works-for" her. It may be that an "engineer" has not "secretary" that "works-for" her.
• A "secretary" can "work-for" one, more or no "engeneer"

In the article the authors propose to represent this as

ENGINEER(*EMP-NO,...,SEC-EMP-NO)
SECRETAY(*EMP-NO,...)

the fields marked by * are keys. The field SEC-EMP-NO referenes a EMP-NO from SECRETARY and is nullabel.

But there are authors that have the opinon that null values should not be allowed in relations. If one wants to avoid null values one needs a third relation to create the following model:

ENGINEER(*EMP-NO,...)
SECRETAY(*EMP-NO,...)
WORKS-FOR(*ENG-EMP-NO,SEC-EMP-NO)

ENG-EMP-NO references an EMP-NO in ENGINEER and SEC-EMP-NO references an EMP-NO in SECRETARY.

If an "engineer" always has a "secretary" that "works-for" her then the first representation with two relations does not contain null values.

Edit: I now found the comment in your post that links to the diagrams (http://i.imgur.com/gIG2D3h.jpg) of your professor: Actually he introduces a third table to avoid null values as described here.