MySQL workbench doesn't show the correct relationship between tables

Question

I have setup a database on MySQL with two tables that related to each other as the following :

create table employee (
    -> employeeID int not null auto_increment primary key,
    -> emFirstName varchar(50) not null,
    -> emLastName varchar(50) not null)
engine=innodb;

create table address (
    -> employeeID int not null primary key,
    -> emAddress varchar(50) not null,
    -> foreign key `emid` (employeeID) references employee(employeeID)
    -> on delete cascade on update cascade)
engine=innodb;

Notice on the address table, I set the employeeID , which references to the employeeID on the employee table, to be the primary key, making the two tables are in one-to-one relationship. I add a record to each as the following :

MariaDB [dummy]> select * from employee;
+------------+-------------+--------------+
| employeeID | emFirstName | emLastName   |
+------------+-------------+--------------+
|          1 | January     | Ananda Putra |
+------------+-------------+--------------+

MariaDB [sampoerna]> select * from address;
+------------+-----------+
| employeeID | emAddress |
+------------+-----------+
|          1 | Sidomulyo |
+------------+-----------+

I tried to add a record to the address table with the employeeID of 1 and failed, indicating that one-to-one relationship worked. But, why did I get the opposite result when I tried to reverse engineer these tables on MySQL workbench? It gave me this :

this schema defines a one-to-many relationship, doesn't it?

Have I set up my table incorrectly or what? thanks for the answer.

Answer 1

Your test tests the PK & FK, not the 1:1. In this code there can be an employee id that is not in the address table. For 1:1 you need another FK the other way plus another CK (candidate key).

Your are confusing "relationship" meaning FK with "relationship" meaning relation/association. In the relational model tables represent relation(ship)s/associations on/among values. Similarly in the original ERM (entity-relationship model), lines from relation(ship)s/association diamonds to entity boxes represent FKs between their tables. Those are the "relationships" that have a cardinality.

A FK constraint says that values for a list of columns must be values for another list of columns.

In pseudo-ER methods & some bad presentions of true ER all relation(ship)s/associations are reified to associative entities and FKs get called relationships. But every FK has an associated binary relation(ship)/association on its referencing entity & its referenced entity. It is represented by a table that is just the two corresponding columns from the referenced table. That's what the cardinality refers to when we attribute one to a FK.

You are saying that the binary relationship "employee eid has address id", which here is the (eid,id) projection of the address table, is 1:1. That would be enforced by eid & id each being a CK (PK or UNIQUE NOT NULL). Then to enforce those two particular tables being consistent you need FKs both ways. If you intend there to be employees without addresses, that's 1:0-or-1, with a FK one way, the current code. Nullable FKs introduce more 0-ors.