Q:

How do we implement an IS-A Relationship?

We implement an One-to-Many relationship by adding one Table's PK, as FK to the other Table.
We implement a Many-to-Many relationship by adding 2 Table's PKs to a third Table.
How do we implement an IS-A Relationship ?
The Entities are TECHNICIAN and ADMINISTRATIVE which both are EMPLOYEE.
I could just use an extra field in the Table 
EMPLOYEE(id, name, surname, role, ...AdminFields..., ...TechFields...)
but i would like to explore the IS-A option.  
EDIT: I did as Donnie suggested, but without the role field.

A:

I did as Donnie suggested, but without the role field, because it complicates things. This is 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:

In this model there are no Employees of Generic Type. Here, an Employee can only be Administrative or Technical.

A:

The IS-A relationship is also known as the gen-spec design pattern.  Gen-spec is short for "generalization specialization".
Relational modeling of gen-spec is different from object modeling of gen-spec because the relational model doesn't have inheritance built in.
Here is a good article that shows how to implement gen-spec as a collection of tables.  
http://www.javaguicodexample.com/erdrelationalmodelnotes1.html
Pay particular attention to the way primary keys are set up in the specialized tables.  That's what makes using these tables so easy.  
You can find lots of other articles by googlin "generalization specialization relational modeling".

A:

I've always done this with a role field, and then optional relationships.
I.e., table EMPLOYEE (id, ...generic fields... , role)
And then, for each role:
table ROLE1 (employeeid, ...specific fields...)
This allows you to get general employee information with a single query, and requires joins to get at the role-specific information.  The one (bigish) downside to this is if you need one super-report with all of the role information on it you get stuck with a bunch of outer joins.

