You created a relationship between two tables.  There is data on both sides of that relationship.  One CD on the left has many tracks on the right.  Incidentally in databases many means anything from 0 to infinity.

There is no track on the right which has a cdReference which does not exist on the left.  This is known as referential integrity.  Without the relationship you created you could enter a track on right for a CD which did not exist.  You could also break the existing referential integrity.  You could delete a CD leaving tracks with no matching CD.  When you created the relationship you saw something like this:

The cascade dialogThis is where you chose how to handle a CD being deleted or changed to prevent breaking the referential integrity.

Go to firsttable in PHPMyAdmin, click on Browse and Delete the third CD.  Now go back to secondtable.  In Browse you should see that the tracks for CD 3 have gone.  This is because you chose to CASCADE any deletion on the left to the table on the right.  Rather than left and right the correct terms are the parent table and the child.  Deleting the parent CD also deletes the child tracks.  Believe it or not if you deleted the parent and the children were left behind that is technically known as leaving orphans and is a breach of referential integrity.

The UPDATE drop down is where you choose what happens when the data in the parent table is changed.  Our primary keys are auto-incremented numbers which you would not normally change even if you could.  However, imagine you had deleted CD 2 instead of 3.  You would now have CD 1 and CD 3.  You might change 3 to 2 to make it neater.  If you did there would now be orphaned tracks in secondtable because they still have a cdReference of 3 but that no longer exists in the parent.

Choosing CASCADE for this as well means that any change to the primary key will automatically be applied to the child records as well and so they will become cdReference 2 instead of 3.  If that did not make sense re-create CD 3 and it's tracks and then delete CD 2. Change the primary key for the third CD to 2 and Browse secondtable to check the cdReference.

The other useful choice is RESTRICT.  This means that if anyone tries to delete (or change) a parent they are not allowed to if children exist.  In many (maybe most) databases RESTRICT would be the right choice as you rarely delete data from a database (although you might archive it to another server and that means deleting the originals).