DynamoDB M-M Adjacency List Design Pattern - many-to-many

Question

Referring to amazon. I was wondering if anyone could help me.
The first image is of the table, and the second is the GSI. Here is the table:
On the table, I don't understand how one is to create the sort-key? Is this one attribute that stores both Bill-ID and Invoice-ID? or two separate attributes? I have a feeling it's the one flexible attribute, and if so how do you differentiate one from the other? And how are we meant to construct the query on the sort-key?
Is it just by looking the prefix "Bill-" or "Invoice-"?
The practice of DynamoDB seems to make use of dashes ("-") to separate values in an attribute. If anyone can give me use cases of such things, I would be grateful as well, but I am going off tangent unless it's important in this case.
Now, this is very relatable and very interesting YouTube, where the presenter uses ONE product table to store various types of items: Books, Song Albums, and Movies; and each has their own attributes.
Again I have a problem understanding the sort-key used there. I understand that productID=1 is bookID, and productID=2 is an Album. Now where it gets confusing now is what I circled in red. These are the tracks of Album 2. However, the structure of the sort key is "albumID:trackID". Now, where is the "trackID"? Is it meant to substitute the word "trackID" with actual ID? or is this meant to be a text exactly as "albumID:trackID"?.
What if I wanted to query a specific trackID? what would be the syntax of my query?
Please see the image here from the youtube:
Thank you all in advance!!! :-)

Answer 1

In the first picture you posted the items in the base table (primary key) would look like this:
First_id(Partition key) Second_id(Sort Key) Dated
------------- ---------- ------
Invoice-92551 Invoice-92551 2018-02-07
Invoice-92551 Bill-4224663 2017-12-03
Invoice-92551 Bill-4224687 2018-01-09
Invoice-92552 Invoice-92552 2018-03-04
Invoice-92552 Bill-4224687 2018-01-09
Bill-4224663 Bill-4224663 2018-12-03
Bill-4224687 Bill-4224687 2018-01-09
And the same items in the GSI the items would look like this
Second_id(Partition Key) First_id
---------- ---------------
Invoice-92551 Invoice-92551
Bill-4224663 Invoice-92551
Bill-4224687 Invoice-92551
Invoice-92552 Invoice-92552
Bill-4224687 Invoice-92552
Bill-4224663 Bill-4224663
Bill-4224687 Bill-4224687
They have drawn it in quite a confusing way.
They have merged the partition keys into one box, but they are separate items.
They have also tried to show the GSI in the same picture. You can think of the base table and the GSI as two separate tables that are kept in sync, in many ways that's what they are.
They haven't actually provided a name to the key attributes. In my example I have named them First_id and Second_id.
When you do a query on the base table, you can use a query with the partition key Invoice-92551 and you get both the Invoice item plus all the bill items that belong to it.
Imagine you are viewing invoice Invoice-92551 in an application and you can see it has two associated bills (Bill-4224663 and Bill-4224687). If you clicked on the bill, the application would probably do a query on the GSI. The GSI query would have partition key Bill-4224687. If you look at the GSI table I have drawn above, you can see this will return two items, showing that Bill-4224687 is part of two invoices (Invoice-92551 and Invoice-92552)
In your second picture, the words 'bookID' and 'albumID' etc are supposed to represent actual IDs (lets say 293847 and 3340876).
I would draw his example like this:
ProductID(Partition Key) TypeID(Sort Key) Title Name
--------- ------ ------ ------
Album1 Album1 Dark Side
Album1 Album1:Track1 Speak to me
Album1 Album1:Track2 Breathe
Movie8 Movie8 Idiocracy
Movie8 Movie8:Actor1 Luke Wilson
Movie8 Movie8:Actor2 Maya Rudolph
Here are your queries:
Partition key: Album1
Gives you ALL the information (inc tracks) on Album 1 (Dark Side)
Partition key: Album1 and Sort Key: Album1:Track2
Gives you just the information on Breathe.
Partition key: Movie8
Gives you ALL the information (inc actors) on Movie8 (Idiocracy)
If I was building the table I would make it so the words Movie, Album etc were part of the actual ID (say Movie018274 and Album983745987) but that's not required, it just makes the IDs more human readable.

Answer 2

Stu's answer is not quite correct, the table actually looks as it is illustrated:
First_id(Partition key) Second_id(Sort Key) Dated
------------- ---------- ------
Invoice-92551 Invoice-92551 2018-02-07
Invoice-92551 Bill-4224663 2017-12-03
Invoice-92551 Bill-4224687 2018-01-09
Invoice-92552 Invoice-92552 2018-03-04
Invoice-92552 Bill-4224687 2018-01-09
Bill-4224663 Bill-4224663 2018-12-03
Bill-4224687 Bill-4224687 2018-01-09
In the table above, the Bill items (i.e. partition key = Bill-xxxxx) hold common information for the bill, where as the Invoice items with Bill items as sort key hold information for the bill that is specific to the given invoice.
In order to fully reconstruct a bill, a GSI is required that allows you to lookup the complete information for a bill (i.e. the common record + invoice specific records):
Second_id(Partition Key) First_id Data
---------- --------------- -----------
Bill-4224663 Bill-4224663 Common bill data
Bill-4224663 Invoice-92551 Bill data for Invoice-92551
Bill-4224687 Bill-4224687 Common bill data
Bill-4224687 Invoice-92551 Bill data for Invoice-92551
Bill-4224687 Invoice-92552 Bill data for Invoice-92552
Invoice-92551 Invoice-92551 Redundant data!
Invoice-92552 Invoice-92552 Redundant data!