designing a star schema
A very basic star-schema for your situation might look like this:

The T-SQL statements to create the dimension tables for this schema look like:
CREATE TABLE dbo.problems
(
    problem_id int NOT NULL
        IDENTITY(1,1)
        CONSTRAINT problems_pk
        PRIMARY KEY
        CLUSTERED
    , problem_description nvarchar(400) NOT NULL
);

CREATE TABLE dbo.reasons
(
    reason_id int NOT NULL
        IDENTITY(1,1)
        CONSTRAINT reasons_pk
        PRIMARY KEY
        CLUSTERED
    , problem_id int NOT NULL
        CONSTRAINT reasons_problem_fk
        FOREIGN KEY
        REFERENCES dbo.problems(problem_id)
    , reason_text nvarchar(500) NOT NULL
);

CREATE TABLE dbo.fixes 
(
    fix_id int NOT NULL
        IDENTITY(1,1)
        CONSTRAINT fixes_pk
        PRIMARY KEY
        CLUSTERED
    , reason_id int NOT NULL
        CONSTRAINT fixes_reason_fk
        FOREIGN KEY
        REFERENCES dbo.reasons(reason_id)
    , fix_text nvarchar(525) NOT NULL
);

CREATE TABLE dbo.dates
(
    date_id int NOT NULL
        IDENTITY(1,1)
        CONSTRAINT dates_pk
        PRIMARY KEY
        CLUSTERED
    , starting_date datetime NOT NULL
    , ending_date datetime NOT NULL
    , CONSTRAINT dates_dates
        CHECK (ending_date &gt; starting_date)
);

The fact table, which you seem to have left out of your question, and I've named incidents, looks like:
CREATE TABLE dbo.incidents
(
    incident_id int NOT NULL
        CONSTRAINT incidents_pk
        PRIMARY KEY
        CLUSTERED
    , incident_date_id int NOT NULL
        CONSTRAINT incidents_incident_date
        FOREIGN KEY
        REFERENCES dbo.dates (date_id)
    , problem_id int NOT NULL
        CONSTRAINT incidents_problem_fk
        FOREIGN KEY
        REFERENCES dbo.problems(problem_id)
    , fix_id int NULL
        CONSTRAINT incidents_fix_fk
        FOREIGN KEY
        REFERENCES dbo.fixes(fix_id)
    , fix_date_id int NOT NULL
        CONSTRAINT incidents_fix_date
        FOREIGN KEY
        REFERENCES dbo.dates (date_id)
);

incidents references the dimension tables such that you are storing the bare minimum of information in the fact table.  The fix_id column is referenced in the incidents table to indicate which of the possibly many fixes was accepted as the actual fix used in this incident.  Since each fix is related to only a single reason, you can infer the reason from the fix.  I've included a discrete column to indicate the problem in this table to enable incidents that don't yet have a fix.
You could add a reason_id foreign-key column to the incidents table if desired.  For instance, maybe you identify a reason prior to determining the fix.