Your case is an instance of class/subclass modeling. Or, as you have diagrammed it in ER, generalization/specialization.

There are three techniques that will help you design mysql tables to cover this case. They are called Single Table Inheritance, Class Table Inheritance, and Shared Primary key. You can read up on them in the info tab from the corresponding tag over in SO.

http://stackoverflow.com/tags/single-table-inheritance/info

http://stackoverflow.com/tags/class-table-inheritance/info

http://stackoverflow.com/tags/shared-primary-key/info

Single table inheritance is useful for simple cases where the presence of NULLs doesn't cause problems. Class table inheritance is better for more complicated cases. Shared primary key is a good way to enforce one-to-one relationships, and to speed up joins.

Since I made the diagram, I better answer ;)

Current relational databases unfortunately don't support the inheritance directly, therefore you need to transform it into "plain" tables. There are generally 3 strategies for doing so:

1. All classes¹ in a single table with NULL-able non-common fields.
2. Concrete classes² in separate tables. Abstract classes don't have the tables of their own.
3. All classes in separate tables.

For more on what this actually means and some pros and cons, please see the links provided in my original post, but in a nutshell the (3) should probably be your default unless you have a specific reason for one of the other two. You can represent the (3) in the database simply like this:

CREATE TABLE person (
    person_id int PRIMARY KEY
    -- Other fields...
);

CREATE TABLE civil (
    civil_id int PRIMARY KEY REFERENCES person (person_id)
    -- Other fields...
);

CREATE TABLE worker (
    worker_id int PRIMARY KEY REFERENCES person (person_id)
    -- Other fields...
);

CREATE TABLE event (
    event_id int PRIMARY KEY,
    person_id int REFERENCES person (person_id)
    -- Other fields...
);

Unfortunately, this structure will let you have a person that is neither civil nor worker (i.e. you can instantiate the abstract class), and will also let you create a person that is both civil and worker. There are ways to enforce the former at the database level, and in a DBMS that supports deferred constraints³ even the latter can be enforced in-database, but this is one of the few cases where using the application-level integrity might actually be preferable.

¹ person, civil and worker in this case.

² civil and worker in this case (person is "abstract").

³ Which MySQL doesn't.

I rather redesign the schema.

First, by adding ID on table tbl_person which will then be used as foreign key on the other table,

CREATE TABLE `tbl_person`
(
    type_ID INT AUTO_INCREMENT,
    type_person VARCHAR(50) NOT NULL ,        
    CONSTRAINT `pk_Info_person` PRIMARY KEY (`type_ID`),  
    CONSTRAINT `uc_Info_person` UNIQUE (`type_person`),    
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Second, combine the two tables tbl_worker and tbl_civil make make some columns nullable. Add a column which reference on tbl_person.type_ID so you will know the type of the person,

CREATE TABLE `tbl_workercivil`
(
    id INTEGER  NOT NULL PRIMARY KEY,
    name VARCHAR(50) NOT NULL ,    
    address VARCHAR(40) ,     
    delegation VARCHAR(40) ,
    name_civil VARCHAR(50)  ,
    procedence_civil VARCHAR(40), 
    person_type INT,
    CONSTRAINT `uc_Info_worker` UNIQUE (name),
    CONSTRAINT `fk_worker` FOREIGN KEY (person_type) 
               REFERENCES tbl_person(type_ID)    
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Third, in the event table, add a column which reference on table tbl_workercivil.

CREATE TABLE `tbl_event` 
(
    id_event INTEGER NOT NULL,
    id_animal INTEGER NOT NULL,
    PersonID INT NOT NULL, 
    date_reception DATE DEFAULT '2000-01-01 01:01:01',
    FOREIGN KEY (id_animal)   REFERENCES `tbl_animal`    (id_animal),
    FOREIGN KEY (PersonID )  REFERENCES `tbl_workercivil`   (id ),
    CONSTRAINT `uc_Info_ficha_primer_ingreso` UNIQUE (`id_animal`,`id_event`)     
)ENGINE=InnoDB  DEFAULT CHARSET=utf8;

and you can be able to know the person know by doing such design,

SELECT  b.name,
        b.specie,
        c.name PersonName,
        d.type_person,
        a.date_reception
FROM    tbl_event a
        INNER JOIN tbl_animal b
            ON a.id_animal = b.id_animal
        INNER JOIN tbl_workercivil c
            ON a.PersonID = c.id
        INNER JOIN tbl_person d
            ON c.person_type = d.type_ID

• SQLFiddle Demo

There is no need for distinct Civil_ID and Worker_ID; just continue to ues Person-ID as the key for all three tables: Person, Civil, and Worker. Add a field PersonTYpe to Person with the two values "Civil" and "Worker".

This now represents the two sub-classes CivilClass and WorkerClass of the abstract base class PersonClass as sub-entities Civil and Worker of the base entity Person. You get a nice correspondence between the data model in the DB with the object model in the application.