Can a junction table (join table) also be used for a one-to-many relationship?

Question

According to the definition, a Junction Table (bridge table/link table) is used for many-to-many relationships, when used like this:

CREATE TABLE Users
(
UserLogin varchar(50) PRIMARY KEY,
UserPassword varchar(50) NOT NULL,
UserName varchar(50) NOT NULL
)


CREATE TABLE Permissions
(
PermissionKey varchar(50) PRIMARY KEY,
PermissionDescription varchar(500) NOT NULL
)


--This is the junction table.
CREATE TABLE UserPermissions
(
UserLogin varchar(50) REFERENCES Users (UserLogin),
PermissionKey varchar(50) REFERENCES Permissions (PermissionKey),
PRIMARY KEY (UserLogin, PermissionKey)
)

But couldn't it also be used just as easily for a one-to-many relationships, as in this example in which one user is associated with many orders:

(I don't understand databases well so please correct me if I have misunderstood something.)

CREATE TABLE Users
(
UserLogin varchar(50) PRIMARY KEY,
UserPassword varchar(50) NOT NULL,
UserName varchar(50) NOT NULL
)


CREATE TABLE Orders
(
OrderKey varchar(50) PRIMARY KEY,
OrderDescription varchar(500) NOT NULL
)


--This is the junction table.
CREATE TABLE UserOrders
(
UserLogin varchar(50) REFERENCES Users (UserLogin),
OrderKey varchar(50) REFERENCES Orders (OrderKey),
PRIMARY KEY (UserLogin, OrderKey)
)

Answer 1

Yes, it is still possible to store and enforce one-to-many relationship in a junction table.

In your example you are not enforcing any constraints on the UserOrders junction table, so a single order can belong to two users (assuming that's incorrect). To enforce that you could make OrderKey be the primary key of the UserOrders junction table (or have a unique constraint on that column). Technically that will just become a many-to-one relationship between UserOrders and Users, while having one-to-one relationship between Orders and UserOrders.

I can only think about one reason for designing the many-to-one relationship using junction table - if you plan to allow the many-to-many relationship in future and don't want to deal with data migration. But in the mean time you will pay the cost of storing and joining with additional table.