ASIX-M2 Institut Poblenou

Ginés Plazas

Modelo Relacional
Vision INFORMAL: “un conjunto de Tablas” Visión FORMAL: “un conjunto de Tablas” + “ALGO MÁS”

RELACION:
Vision INFORMAL: RELACION ~ TABLA

Visión FORMAL: RELACION = TABLA + “algo más” Ejemplo: En nuestra bbdd de Empleados, tenemos la siguiente tabla (entre otras): Tabla EMPLOYEES:

¿Qué ALGO MÁS le falta a esa tabla para ser considerada una RELACIÓN? “Mirando” esa tabla podemos ver muchas cosas: -La Relación 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

1

debemos ir con ese valor a la tabla DEPARTMENTS. y de alli podremos saber cómo se llama el departamento. 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. pero . debemos ir con ese valor a la tabla JOBS. que apunta a Employees (es recursiva!!). decimos que manager_id es una FK de Employees. -no podemos saber los tipos de valores de los diferentes atributos (podemos imaginarlos..) employee_id NUMBER(6) first_name VARCHAR2(20) last_name VARCHAR2(25) 2 . que apunta a Departments. 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. y de alli podremos saber cómo se llama el tipo de trabajo que desempeña. decimos que job_id es una FK de Employees. que mail tiene el jefe.. -department_id es una columna cuyos datos REFERENCIAN a otra columna de otra Relacion de nuestra BBDD.. Si queremos saber MÁS del trabajo de un empleado. -manager_id es una columna cuyos datos REFERENCIAN a otra columna de LA MISMA Relacion de nuestra BBDD. y el salario maximo y minimo de ese trabajo. que apunta a Jobs. y de esta forma podremos saber cómo se llama el jefe de ese empleado. Si queremos saber MÁS sobre el jefe de un empleado. debemos ir con ese valor y buscar en la misma tabla EMPLOYEES de qué empleado se trata. . 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.. cuando fue contratado el jefe.ASIX-M2 Institut Poblenou Ginés Plazas -Podemos observar los datos (valores) de cualquier atributo de cualquier empleado. cual es el jefe del departamento. Tenemos los datos de los empleados!! PERO HAY OTRAS COSAS QUE NOS PASAN DESAPERCIBIDAS: -employee_id es PK (Clave Primaria. Si queremos saber MÁS sobre el departamento en el que trabaja un empleado. o Primary Key) de la Relación -job_id es una columna cuyos datos REFERENCIAN a otra columna de otra Relacion de nuestra BBDD. decimos que department_id es una FK de Employees.

2) commission_pct NUMBER(2. . -Los valores de un email. FOREIGN KEY(MANAGER_ID) REFERENCES EMPLOYEES(EMPLOYEE_ID). O los posibles valores de phone_number. FOREIGN KEY(JOB_ID) REFERENCES JOBS(JOB_ID).ASIX-M2 Institut Poblenou Ginés Plazas email VARCHAR2(25) phone_number VARCHAR2(20) hire_date DATE job_id VARCHAR2(10) salary NUMBER(8. COMMISSION_PCT NUMBER(2. JOB_ID VARCHAR2(10) NOT NULL. deben ser únicos (no pueden haber 2 emails repetidos. HIRE_DATE DATE NOT NULL. FOREIGN KEY(DEPARTMENT_ID) REFERENCES DEPARTMENTS(DEPARTMENT_ID). hire_date. Todo ello queda de manifiesto en el Script de Creación de esa “Tabla” (Relación).2). 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í sería aceptable añadir un empleado que no tuviera teléfono. PRIMARY KEY(EMPLOYEE_ID). PHONE_NUMBER VARCHAR2(20). LAST_NAME VARCHAR2(25) NOT NULL. MANAGER_ID NUMBER(6). sólo pueden ser posibles valores de teléfonos. pero no puede serlo porque eso obligaría a todo el mundo a tener un mail (no podría ser null).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. y como todos sabemos.. DEPARTMENT_ID NUMBER(4).2).. CONSTRAINT EMP_EMAIL_UK UNIQUE(EMAIL)). email. FIRST_NAME VARCHAR2(20). SALARY NUMBER(8. o del que no sabemos su nombre de pila. o sin un jefe asignado. los posibles valores de manager_id sólo pueden ser códigos de empleados válidos y existentes. Eso llevarnos a pensar que email pueda ser considerado una clave candidata. cuando la creamos para un SGBD determinado mediante sentencias SQL: CREATE TABLE EMPLOYEES( EMPLOYEE_ID NUMBER(6). EMAIL VARCHAR2(25) NOT NULL. 3 . no todo el mundo tiene una direccion de correo electrónico) -tampoco vemos que en nuestra bbdd queremos considerar que los siguientes atributos: last_name.

ASIX-M2 Institut Poblenou Ginés 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) 4 .

para ser una Relación. ES DECIR. los valores de los atributos deben ser ATOMICOS (como en nuestro ejemplo ocurre!) Además. filas). TENEMOS 1 SOLA RELACIÓN!!! Además. en una Relación NO SE PUEDEN REPETIR TUPLAS (registros. No pueden existir 2 tuplas exactamente iguales.ASIX-M2 Institut Poblenou Ginés Plazas PERO VISTAS COMO RELACION SON EXACTAMENTE IGUALES. que guardan la misma información. 5 . Lo que importa es que tiene los mismos datos visto como conjuntos!! Los mismos registros.

Sign up to vote on this title
UsefulNot useful