We implement an One-to-Many relationship with the addition of one Table's PK, as FK towards the other Table. We implement a Many-to-Many relationship with the addition of 2 Table's PKs to some third Table.

How can we implement an IS-Rapport ?

The Organizations are Specialist and ADMINISTRATIVE which both of them are Worker. I possibly could only use an additional area within the Table Worker(id, title, surname, role, ...AdminFields..., ...TechFields...)

but i must explore the IS-A option.

EDIT: Used to do as Donnie recommended, but with no role area.

Used to do as Donnie recommended, but with no role area, since it reduces things. This is actually the final implementation:

DDL:

CREATE TABLE Employee (
ast VARCHAR(20) not null,
firstname VARCHAR(200) not null,
surname VARCHAR(200) not null,
...
PRIMARY KEY(ast)
);

CREATE TABLE Administrative (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
PRIMARY KEY(employee_ast)
);

CREATE TABLE Technical (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
...
PRIMARY KEY(employee_ast)
);

ER Diagram:

ERD

Within this model you will find no Employees of Generic Type. Here, an Worker are only able to be Administrative or Technical.

I have always carried this out having a role area, after which optional associations.

I.e., table EMPLOYEE (id, ...generic fields... , role)

After which, for every role:

table ROLE1 (employeeid, ...specific fields...)

This enables you to definitely get general worker information having a single query, as well as joins to access the role-specific information. The main one (bigish) disadvantage to this really is if you want one super-report with all the role info on it you find yourself in trouble with a lot of outer joins.

Why don't you implement this like a one-to-zero/one table relationship? Let us if you have a table representing basics class known as Vehicle, having a primary key of VehicleID. Then, you could have a variety of satellite tables representing all of the subclasses of Vehicle, and individuals tables also provide VehicleID his or her primary key, getting single->0/1 relationship from Vehicle->Subclass.

Or, if you wish to allow it to be simpler and also you know without a doubt that you will only have a couple of sub classes and there is very little possibility of that altering, you can just represent the entire structure in one table having a discriminator type area.

This paper describes some methods for mapping simplification to into schema design.

http://www.sztaki.hu/conferences/ADBIS/3-Eder.pdf

A duplicate from the abstract:

The more potent data types of object relational databases opens many more choices for the logical style of a database schema growing the complexity of logical database design enormously. Concentrating on generalization constructs of conceptual models we explore the performance implications of the several design options for mapping simplification in to the schema of the object-relational database system.

The IS-Rapport is also called the gen-spec design pattern. Gen-spec is short for "generalization specialty area".

Relational modeling of gen-spec differs from object modeling of gen-spec since the relational model does not have inheritance built-in.

This is a piece of content that shows how you can implement gen-spec as an accumulation of tables.

http://www.javaguicodexample.com/erdrelationalmodelnotes1.html

Pay particular focus on the way in which primary secrets are placed in the specialized tables. That is what makes with such tables very easy.

You'll find all articles by googlin "generalization specialty area relational modeling".