ASIX-M2 Institut Poblenou

Gins Plazas

Modelo Relacional
Vision INFORMAL: un conjunto de Tablas Visin FORMAL: un conjunto de Tablas + ALGO MS

RELACION:
Vision INFORMAL: RELACION ~ TABLA

Visin FORMAL: RELACION = TABLA + algo ms Ejemplo: En nuestra bbdd de Empleados, tenemos la siguiente tabla (entre otras): Tabla EMPLOYEES:

Qu ALGO MS le falta a esa tabla para ser considerada una RELACIN? Mirando esa tabla podemos ver muchas cosas: -La Relacin se llama EMPLOYEES -Tiene una serie de atributos (11 columnas, es decir tiene grado 11): employee_id, first_name, last_name, email, phone_number, hire_date, job_id, salary, commission_pct, manager_id, department_id -Tiene 20 empleados (representados en 20 filas, registros o tuplas). Es decir, su cardinalidad es 20

ASIX-M2 Institut Poblenou

Gins Plazas

-Podemos observar los datos (valores) de cualquier atributo de cualquier empleado. Tenemos los datos de los empleados!!

PERO HAY OTRAS COSAS QUE NOS PASAN DESAPERCIBIDAS: -employee_id es PK (Clave Primaria, o Primary Key) de la Relacin -job_id es una columna cuyos datos REFERENCIAN a otra columna de otra Relacion de nuestra BBDD. Si queremos saber MS del trabajo de un empleado, debemos ir con ese valor a la tabla JOBS, y de alli podremos saber cmo se llama el tipo de trabajo que desempea, y el salario maximo y minimo de ese trabajo. JOBS Decimos que EMPLOYEES job_id (o que job_id de Employees referencia a la PK (job_id tambien se llama) de JOBS! O mejor, decimos que job_id es una FK de Employees, que apunta a Jobs.

-department_id es una columna cuyos datos REFERENCIAN a otra columna de otra Relacion de nuestra BBDD. Si queremos saber MS sobre el departamento en el que trabaja un empleado, debemos ir con ese valor a la tabla DEPARTMENTS, y de alli podremos saber cmo se llama el departamento, cual es el jefe del departamento, y donde est localizado el departamento Decimos que EMPLOYEES department_id DEPARTMENTS (o que department_id de Employees referencia a la PK (department_id tambien se llama) de DEPARTMENTS! O mejor, decimos que department_id es una FK de Employees, que apunta a Departments.

-manager_id es una columna cuyos datos REFERENCIAN a otra columna de LA MISMA Relacion de nuestra BBDD. Si queremos saber MS sobre el jefe de un empleado, debemos ir con ese valor y buscar en la misma tabla EMPLOYEES de qu empleado se trata, y de esta forma podremos saber cmo se llama el jefe de ese empleado, que mail tiene el jefe, cuando fue contratado el jefe, ... Todos los atributos del JEFE visto como empleado que es!! EMPLOYEES Decimos que EMPLOYEES manager_id (o que manager_id de Employees referencia a la PK (employee_id ! OBSERVA QUE EN ESTE CASO NO SE LLAMAN IGUAL LAS COLUMNAS) de EMPLOYEES! O mejor, decimos que manager_id es una FK de Employees, que apunta a Employees (es recursiva!!). -no podemos saber los tipos de valores de los diferentes atributos (podemos imaginarlos, pero ...) employee_id NUMBER(6) first_name VARCHAR2(20) last_name VARCHAR2(25)

ASIX-M2 Institut Poblenou

Gins Plazas

email VARCHAR2(25) phone_number VARCHAR2(20) hire_date DATE job_id VARCHAR2(10) salary NUMBER(8,2) commission_pct NUMBER(2,2) manager_id NUMBER(6) department_id NUMBER(4) -Tampoco tenemos explicitados los posibles valores que puede tener un determinado atributo (lo que se llama el DOMINIO de un atributo): por ejemplo, los posibles valores de manager_id slo pueden ser cdigos de empleados vlidos y existentes. O los posibles valores de phone_number, slo pueden ser posibles valores de telfonos. -Los valores de un email, deben ser nicos (no pueden haber 2 emails repetidos. Eso llevarnos a pensar que email pueda ser considerado una clave candidata, pero no puede serlo porque eso obligara a todo el mundo a tener un mail (no podra ser null), y como todos sabemos, no todo el mundo tiene una direccion de correo electrnico) -tampoco vemos que en nuestra bbdd queremos considerar que los siguientes atributos: last_name, email, hire_date, job_id NO PUEDEN CONTENER VALORES NULOS (simplemente porque en nuestra empresa se decidi que entrar empleados con algunos de esos valores a NULL no es aceptable!) Pero s sera aceptable aadir un empleado que no tuviera telfono, o del que no sabemos su nombre de pila, o sin un jefe asignado, ...

Todo ello queda de manifiesto en el Script de Creacin de esa Tabla (Relacin), cuando la creamos para un SGBD determinado mediante sentencias SQL:
CREATE TABLE EMPLOYEES( EMPLOYEE_ID NUMBER(6), FIRST_NAME VARCHAR2(20), LAST_NAME VARCHAR2(25) NOT NULL, EMAIL VARCHAR2(25) NOT NULL, PHONE_NUMBER VARCHAR2(20), HIRE_DATE DATE NOT NULL, JOB_ID VARCHAR2(10) NOT NULL, SALARY NUMBER(8,2), COMMISSION_PCT NUMBER(2,2), MANAGER_ID NUMBER(6), DEPARTMENT_ID NUMBER(4), PRIMARY KEY(EMPLOYEE_ID), FOREIGN KEY(JOB_ID) REFERENCES JOBS(JOB_ID), FOREIGN KEY(DEPARTMENT_ID) REFERENCES DEPARTMENTS(DEPARTMENT_ID), FOREIGN KEY(MANAGER_ID) REFERENCES EMPLOYEES(EMPLOYEE_ID), CONSTRAINT EMP_EMAIL_UK UNIQUE(EMAIL));

ASIX-M2 Institut Poblenou

Gins Plazas

TAMPOCO QUEDA DE MANIFIESTO al observar la tabla, el siguiente concepto que es importante en el modelo RELACIONAL: Estas 4 TABLAS NO SON IGUALES (vistas como tablas):

(aqu he cambiado las filas de orden)

(aqui he cambiado las columnas de orden)

(aqui he cambiado las filas y las columnas de orden)

ASIX-M2 Institut Poblenou

Gins Plazas

PERO VISTAS COMO RELACION SON EXACTAMENTE IGUALES. Lo que importa es que tiene los mismos datos visto como conjuntos!! Los mismos registros, que guardan la misma informacin.

ES DECIR, TENEMOS 1 SOLA RELACIN!!!

Adems, para ser una Relacin, los valores de los atributos deben ser ATOMICOS (como en nuestro ejemplo ocurre!) Adems, en una Relacin NO SE PUEDEN REPETIR TUPLAS (registros, filas). No pueden existir 2 tuplas exactamente iguales.