Das Modell enthält die vier Entitäten Employee, ToDo, Priority und Company. Die einzige 1:N-Beziehungen heißt hier eine 1:Q und hat keine eigene Attribute - deshalb verschwindet diese Relation has in einer anderen Tabelle. Es gibt weiterhin zwei M:N-Relationen works on und requires, die in zwei Tabellen gespeichert werden. Insgesamt muss eine vollständige Lösung also 6 Tabellen erstellen.

1) Einzelne Entitäten und 1:1-Relationen auflösen.

Es gibt weder einzelne Entitäten, noch 1:1-Relationen.

2) 1:N-Relationen und deren beteiligte Entitäten auflösen.

Die 1:N-Relation heißen hier 1:Q (has). Ein ToDo hat eine Priorität. Eine Priorität kann für mehrere ToDos gelten. Zuerst wird also der Entitätstyp (die Tabelle) die Priorität erzeugt. Dabei wird der Name der einzelnen Entität (Priority) für den Namen des Entitätstyps (der Tabelle) in den Plural Priorites geändert, weil die Tabelle später ja mehrere Prioritäten speichern wird.

CREATE TABLE Priorities(
    PId INT CONSTRAINT PK PRIMARY KEY,
    Description VARCHAR(80)
);

Es folgt die Tabelle für die ToDos (der Entitätstyp). Dabei wird wieder die Benennung einer Entität in den Plural ToDos geändert. Die ToDos enthalten den Fremdschlüssel zu ihren jeweiligen Prioritäten:

CREATE TABLE ToDos(
    TId INT CONSTRAINT PK PRIMARY KEY,
    Description VARCHAR(80),
    Priority INT CONSTRAINT FK2 REFERENCES Priorities(PId)
);

3) N:M-Relationen und deren beteiligte Entitäten auflösen.

Für die M:N-Relation works on sind zwar die ToDos vorhanden, es fehlt aber noch die Entität Employee. Deren Tabelle (Entitätstyp) wird wieder mit der Benennung im Plural versehen:

CREATE TABLE Employees(
    EId INT CONSTRAINT PK PRIMARY KEY,
    First_name VARCHAR(80),
    Last_name VARCHAR(80)
);

Nun fehlt nur noch die Relationstabelle works on. Die Relation hat allerdings ein Attribut is contact for. Es gibt an, ob die betreffende Person für das jeweilige ToDo Ansprechpartner*in ist. Das kann der Fall sein, oder auch nicht und ist deshalb sicher ein Attribut vom Typ BOOL.

CREATE TABLE works_on(
    EId INT CONSTRAINT FK1 REFERENCES Employees(EId),
    TId INT CONSTRAINT FK2 REFERENCES ToDos(TId),
    is_contact_for BOOL,
    CONSTRAINT PK PRIMARY KEY(EId, TId)
);

Für die R:S-Relation requires fehlt noch die Entität Company. Deren Tabelle (Entitätstyp) wird wieder im Plural benannt und folgendermaßen erstellt:

CREATE TABLE Companies(
    CId INT CONSTRAINT PK PRIMARY KEY,
    Name VARCHAR(80),
    Road VARCHAR(80),
    Post_code INT,
    City VARCHAR(80),
    Trustlevel Float
);

Schließlich und endlich müssen beide Entitätstypen Companies und ToDos noch über eine Relationen-Tabelle verbunden werden. Diese Tabelle speichert auch das Attribut Fälligkeit:

CREATE TABLE requires(
    CId INT CONSTRAINT FK1 REFERENCES Companies(CId),
    TId INT CONSTRAINT FK2 REFERENCES ToDos(TId),
    Due_date Date,
    CONSTRAINT PK PRIMARY KEY(CId, TId)
);