basedatos: 2012

lunes, 18 de junio de 2012

ejercicio base dato oracle

-- Generado por Oracle SQL Developer Data Modeler 3.1.0.687
--   en:        2012-06-18 21:49:48 CLT
--   sitio:      Oracle Database 10g
--   tipo:      Oracle Database 10g

CREATE TABLE Cliente
    (
     ID_cliente INTEGER NOT NULL ,
     Nombre CHAR (20 CHAR) NOT NULL ,
     rut VARCHAR2 (10 CHAR) NOT NULL ,
     Id_seguro INTEGER NOT NULL
    )
;

ALTER TABLE Cliente
    ADD CONSTRAINT "Cliente PK" PRIMARY KEY ( ID_cliente ) ;

CREATE TABLE Empleado
    (
     Id_empleado INTEGER NOT NULL ,
     Nombre VARCHAR2 (20 CHAR) NOT NULL ,
     Direcciòn VARCHAR2 (30 CHAR) NOT NULL ,
     rut VARCHAR2 (10 CHAR) NOT NULL ,
     Id_seguro INTEGER NOT NULL
    )
;

ALTER TABLE Empleado
    ADD CONSTRAINT "Empleado PK" PRIMARY KEY ( Id_empleado ) ;

CREATE TABLE Seguro
    (
     Id_seguro INTEGER NOT NULL ,
     Monto INTEGER NOT NULL ,
     vehiculo VARCHAR2 (20 CHAR) NOT NULL ,
     Propietario VARCHAR2 (20 CHAR) NOT NULL
    )
;

ALTER TABLE Seguro
    ADD CONSTRAINT "Seguro PK" PRIMARY KEY ( Id_seguro ) ;

CREATE TABLE Vehìculo
    (
     Patente VARCHAR2 (8 CHAR) NOT NULL ,
     Marca VARCHAR2 (20 CHAR) NOT NULL ,
     Modelo VARCHAR2 (20 CHAR) NOT NULL ,
     color BLOB NOT NULL ,
     Id_seguro INTEGER NOT NULL
    )
;

CREATE UNIQUE INDEX Vehìculo__IDX ON Vehìculo
    (
     Id_seguro ASC
    )
;
ALTER TABLE Vehìculo
    ADD CONSTRAINT "Automovil PK" PRIMARY KEY ( Patente ) ;

ALTER TABLE Vehìculo
    ADD CONSTRAINT asigna FOREIGN KEY
    (
     Id_seguro
    )
    REFERENCES Seguro
    (
     Id_seguro
    )
;

ALTER TABLE Cliente
    ADD CONSTRAINT solicita FOREIGN KEY
    (
     Id_seguro
    )
    REFERENCES Seguro
    (
     Id_seguro
    )
;

ALTER TABLE Empleado
    ADD CONSTRAINT vender FOREIGN KEY
    (
     Id_seguro
    )
    REFERENCES Seguro
    (
     Id_seguro
    )
    ON DELETE CASCADE
;

-- Informe de Resumen de Oracle SQL Developer Data Modeler:
--
-- CREATE TABLE                             4
-- CREATE INDEX                             1
-- ALTER TABLE                              7
-- CREATE VIEW                              0
-- CREATE PACKAGE                           0
-- CREATE PACKAGE BODY                      0
-- CREATE PROCEDURE                         0
-- CREATE FUNCTION                          0
-- CREATE TRIGGER                           0
-- ALTER TRIGGER                            0
-- CREATE STRUCTURED TYPE                   0
-- CREATE COLLECTION TYPE                   0
-- CREATE CLUSTER                           0
-- CREATE CONTEXT                           0
-- CREATE DATABASE                          0
-- CREATE DIMENSION                         0
-- CREATE DIRECTORY                         0
-- CREATE DISK GROUP                        0
-- CREATE ROLE                              0
-- CREATE ROLLBACK SEGMENT                  0
-- CREATE SEQUENCE                          0
-- CREATE MATERIALIZED VIEW                 0
-- CREATE SYNONYM                           0
-- CREATE TABLESPACE                        0
-- CREATE USER                              0
--
-- DROP TABLESPACE                          0
-- DROP DATABASE                            0
--
-- ERRORS                                   0
-- WARNINGS                                 0

Taller 1 de Edison Vasquez Garcia

CREATE TABLE Automovil
    (
     Id_Automovil INTEGER NOT NULL ,
     Patente VARCHAR2 (40) ,
     Marca VARCHAR2 (40) ,
     Año INTEGER ,
     Id_Seguro INTEGER
    )
;

CREATE UNIQUE INDEX Automovil__IDX ON Automovil
    (
     Id_Seguro ASC
    )
;
ALTER TABLE Automovil
    ADD CONSTRAINT "Automovil PK" PRIMARY KEY ( Id_Automovil ) ;

CREATE TABLE Cliente
    (
     Id_cliente INTEGER NOT NULL ,
     Rut_cliente INTEGER ,
     Nombre_cliente VARCHAR2 (40) ,
     Apellido_cliente VARCHAR2 (40) ,
     Id_Seguro INTEGER
    )
;

CREATE UNIQUE INDEX Cliente__IDX ON Cliente
    (
     Id_Seguro ASC
    )
;
ALTER TABLE Cliente
    ADD CONSTRAINT "Cliente PK" PRIMARY KEY ( Id_cliente ) ;

CREATE TABLE Empleado
    (
     "ID Empleados" INTEGER NOT NULL ,
     Rut INTEGER ,
     Nombre VARCHAR2 (40) ,
     Apellido VARCHAR2 (40)
    )
;

ALTER TABLE Empleado
    ADD CONSTRAINT "Empleado PK" PRIMARY KEY ( "ID Empleados" ) ;

CREATE TABLE Seguro
    (
     Monto1 INTEGER ,
     Id_Seguro INTEGER NOT NULL ,
     Tipo_seguro VARCHAR2 (40) ,
     Metodo_pago VARCHAR2 (40) ,
     "ID Empleados" INTEGER ,
     Id_Automovil INTEGER ,
     Id_cliente INTEGER
    )
;

CREATE UNIQUE INDEX Seguro__IDX ON Seguro
    (
     Id_Automovil ASC
    )
;
ALTER TABLE Seguro
    ADD CONSTRAINT "Seguro PK" PRIMARY KEY ( Id_Seguro ) ;

ALTER TABLE Automovil
    ADD CONSTRAINT Asigna FOREIGN KEY
    (
     Id_Seguro
    )
    REFERENCES Seguro
    (
     Id_Seguro
    )
    ON DELETE SET NULL
;

ALTER TABLE Seguro
    ADD CONSTRAINT Asigna FOREIGN KEY
    (
     Id_Automovil
    )
    REFERENCES Automovil
    (
     Id_Automovil
    )
    ON DELETE SET NULL
;

ALTER TABLE Cliente
    ADD CONSTRAINT Solicita FOREIGN KEY
    (
     Id_Seguro
    )
    REFERENCES Seguro
    (
     Id_Seguro
    )
    ON DELETE SET NULL
;

ALTER TABLE Seguro
    ADD CONSTRAINT Solicita FOREIGN KEY
    (
     Id_cliente
    )
    REFERENCES Cliente
    (
     Id_cliente
    )
    ON DELETE SET NULL
;

ALTER TABLE Seguro
    ADD CONSTRAINT Vende FOREIGN KEY
    (
     "ID Empleados"
    )
    REFERENCES Empleado
    (
     "ID Empleados"
    )
    ON DELETE SET NULL
;

Tarea taller uno 1 francisco hormazabal

-- Generado por Oracle SQL Developer Data Modeler 3.1.0.687
--   en:        2012-06-18 20:19:09 CLT
--   sitio:      Oracle Database 10g
--   tipo:      Oracle Database 10g

CREATE TABLE Empleado
    (
     id_empleado INTEGER NOT NULL ,
     rut_e INTEGER ,
     apellido_e VARCHAR2 (40) ,
     nombre_e VARCHAR2 (40)
    )
;

ALTER TABLE Empleado
    ADD CONSTRAINT "Empleado PK" PRIMARY KEY ( id_empleado ) ;

CREATE TABLE automovil
    (
     id_automovil INTEGER NOT NULL ,
     patente VARCHAR2 (40) ,
     marca VARCHAR2 (40) ,
     año INTEGER ,
     id_seguro INTEGER
    )
;

CREATE UNIQUE INDEX automovil__IDX ON automovil
    (
     id_seguro ASC
    )
;
ALTER TABLE automovil
    ADD CONSTRAINT "automovil PK" PRIMARY KEY ( id_automovil ) ;

CREATE TABLE cliente
    (
     id_cliente INTEGER NOT NULL ,
     rut_cliente INTEGER ,
     nombre_cliente VARCHAR2 (40) ,
     apellido_cliente VARCHAR2 (40)
    )
;

ALTER TABLE cliente
    ADD CONSTRAINT "cliente PK" PRIMARY KEY ( id_cliente ) ;

CREATE TABLE seguro
    (
     monto INTEGER ,
     id_seguro INTEGER NOT NULL ,
     tipo_seguro VARCHAR2 (40) ,
     metodo_pago VARCHAR2 (40) ,
     id_empleado INTEGER ,
     id_automovil INTEGER ,
     id_cliente INTEGER
    )
;

CREATE UNIQUE INDEX seguro__IDX ON seguro
    (
     id_automovil ASC
    )
;
ALTER TABLE seguro
    ADD CONSTRAINT "seguro PK" PRIMARY KEY ( id_seguro ) ;

ALTER TABLE automovil
    ADD CONSTRAINT asigna FOREIGN KEY
    (
     id_seguro
    )
    REFERENCES seguro
    (
     id_seguro
    )
    ON DELETE SET NULL
;

ALTER TABLE seguro
    ADD CONSTRAINT asigna FOREIGN KEY
    (
     id_automovil
    )
    REFERENCES automovil
    (
     id_automovil
    )
    ON DELETE SET NULL
;

ALTER TABLE seguro
    ADD CONSTRAINT solicita FOREIGN KEY
    (
     id_cliente
    )
    REFERENCES cliente
    (
     id_cliente
    )
    ON DELETE SET NULL
;

ALTER TABLE seguro
    ADD CONSTRAINT vende FOREIGN KEY
    (
     id_empleado
    )
    REFERENCES Empleado
    (
     id_empleado
    )
    ON DELETE SET NULL
;

Codigo Taller 1 Alvaro Arce

Aqui está:

Codigo para el primer ejercicio, Aseguradora de Vehiculos

-- Generado por Oracle SQL Developer Data Modeler 3.1.0.687
-- en: 2012-06-18 20:19:11 CLT
-- sitio: Oracle Database 10g
-- tipo: Oracle Database 10g

DROP TABLE Automovil CASCADE CONSTRAINTS;
DROP TABLE Cliente CASCADE CONSTRAINTS;
DROP TABLE Empleado CASCADE CONSTRAINTS;
DROP TABLE Seguro CASCADE CONSTRAINTS;

CREATE TABLE Automovil
(
idAutomovil INTEGER NOT NULL ,
PatenteAutomovil VARCHAR2 (30) ,
MarcaAutomovil VARCHAR2 (30) ,
ModeloAutomovil VARCHAR2 (30) ,
AnnoAutomovil INTEGER ,
idSeguro INTEGER
)
;

CREATE UNIQUE INDEX Automovil__IDX ON Automovil
(
idSeguro ASC
)
;

ALTER TABLE Automovil
ADD CONSTRAINT "Automovil PK" PRIMARY KEY ( idAutomovil ) ;

CREATE TABLE Cliente
(
idCliente INTEGER NOT NULL ,
NombreCliente VARCHAR2 (30) ,
ApellidoCliente VARCHAR2 (30) ,
RutCliente INTEGER ,
RiesgoCliente VARCHAR2 (50)
)
;

ALTER TABLE Cliente
ADD CONSTRAINT "Cliente PK" PRIMARY KEY ( idCliente ) ;

CREATE TABLE Empleado
(
idEmpleado INTEGER NOT NULL ,
RutEmpleado INTEGER ,
NombreEmpleado VARCHAR2 (30) ,
ApellidoEmpleado VARCHAR2 (30) ,
EdadEmpleado INTEGER
)
;

ALTER TABLE Empleado
ADD CONSTRAINT "Empleado PK" PRIMARY KEY ( idEmpleado ) ;

CREATE TABLE Seguro
(
idSeguro INTEGER NOT NULL ,
MontoSeguro INTEGER ,
TipoSeguro VARCHAR2 (30) ,
MetodoPagoSeguro VARCHAR2 (30) ,
HoraVentaSeguro DATE ,
idEmpleado INTEGER ,
idAutomovil INTEGER ,
idCliente INTEGER
)
;

CREATE UNIQUE INDEX Seguro__IDX ON Seguro
(
idAutomovil ASC
)
;

ALTER TABLE Seguro
ADD CONSTRAINT "Seguro PK" PRIMARY KEY ( idSeguro ) ;

ALTER TABLE Automovil
ADD CONSTRAINT Asigna FOREIGN KEY
(
idSeguro
)
REFERENCES Seguro
(
idSeguro
)
ON DELETE SET NULL
;

ALTER TABLE Seguro
ADD CONSTRAINT Asigna FOREIGN KEY
(
idAutomovil
)
REFERENCES Automovil
(
idAutomovil
)
ON DELETE SET NULL
;

ALTER TABLE Seguro
ADD CONSTRAINT Solicita FOREIGN KEY
(
idCliente
)
REFERENCES Cliente
(
idCliente
)
ON DELETE SET NULL
;

ALTER TABLE Seguro
ADD CONSTRAINT Vende FOREIGN KEY
(
idEmpleado
)
REFERENCES Empleado
(
idEmpleado
)
ON DELETE SET NULL
;

INSERT INTO Automovil VALUES (101, 'CK-4236','Nissan Datsun','Bluebird 1.8 SSS',1981,1001);
INSERT INTO Automovil VALUES (102, 'AR-BJ25','Hyundai','H-1',2010,1002);

INSERT INTO Cliente VALUES (10001, 'Juan', 'Mendoza', 139157222, 'Alto');
INSERT INTO Cliente VALUES (10002, 'Pedro', 'Fuenzalida', 169321528, 'Bajo');

INSERT INTO Empleado VALUES (50001, 119567229, 'Esteban', 'Paredes', 42);
INSERT INTO Empleado VALUES (50002, 148321528, 'Julio', 'Soto', 26);

INSERT INTO Seguro VALUES (100001, 50000, 'Total', 'Cheque', '11:20', 50001, 101, 10001);
INSERT INTO Seguro VALUES (100002, 35000, 'Incendio', 'Efectivo', '14:25', 50002, 102, 10002);

DESC Automovil;
DESC Cliente;
DESC Empleado;
DESC Seguro;

SELECT * FROM Automovil;
SELECT * FROM Cliente;
SELECT * FROM Empleado;
SELECT * FROM Seguro;

Saludos.

lunes, 30 de abril de 2012

Tarea 3

El Proceso de Normalización

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. El objetivo de esto es evitar la redundancia de datos, evitar problemas asociados a la actualización de las tablas (relaciones) y ademas proteger la integridad de los datos. Para que una tabla sea considerada como una relación tiene que tener un nombre único, no pueden haber dos filas iguales ni duplicados y todos los datos en una columna deben ser del mismo tipo.

Dependencias Funcionales

Una dependencia funcional es una conexión entre uno o más atributos, por ej. fecha de nacimiento y edad. Escrito como dependencia funcional, esto sería FechaDeNacimiento ---> Edad.

Hay tres propiedades fundamentales:

-Reflexiva: El atributo tiene la suficiente información como para reconstruirse a si mismo.

-Aumentativa: Si de "X" construimos "Y" entonces de "XZ" construimos "YZ"

-Transitiva: Si de "X" construimos "Y", y de "Y" construimos "Z", entonces somos capaces de construir "Z" a partir de "X".

Formas Normales

Primera Forma Normal (1FN)

La primera forma normal (1FN o forma mínima) es una forma normal usada en normalizacion de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación y está libre de "grupos repetitivos".

Una tabla está en Primera Forma Normal si:

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.

• La tabla contiene una llave primaria única.

• La llave primaria no contiene atributos nulos.

• No debe existir variación en el número de columnas.

• Los Campos no llave deben identificarse por la llave (Dependencia Funcional)

• Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

• Una tabla no puede tener múltiples valores en cada columna.

• Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).

Esta forma normal elimina los valores repetidos dentro de una BD.

Ejemplo:

Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente
ID Cliente	Nombre	Apellido	Teléfono
123	Rachel	Ingram	555-861-2025
456	James	Wright	555-403-1659
789	Cesar	Dure	555-808-9633

En este punto, el diseñador se da cuenta de un requisito para guardar múltiples números teléfonicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado:

Cliente
ID Cliente	Nombre	Apellido	Teléfono
123	Rachel	Ingram	555-861-2025
456	James	Wright	555-403-1659 555-776-4100
789	Cesar	Dure	555-808-9633

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no está en 1FN. La 1FN prohíbe a un campo contener más de un valor de su dominio de columna.

Solución

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente.

Cliente
ID Cliente	Nombre	Apellido
123	Rachel	Ingram
456	James	Wright
789	Cesar	Dure

Teléfono del cliente
ID Cliente	Teléfono
123	555-861-2025
456	555-403-1659
456	555-776-4100
789	555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro. Es valioso notar que este diseño cumple los requerimientos adicionales para la segunda (2FN) y la tercera forma normal (3FN).

Segunda Forma Normal (2FN)

Una tabla 1FN está en 2FN si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria)

Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados
Empleado	Habilidad	Lugar actual de trabajo
Jones	Mecanografía	114 Main Street
Jones	Taquigrafía	114 Main Street
Jones	Tallado	114 Main Street
Bravo	Limpieza ligera	73 Industrial Way
Ellis	Alquimia	73 Industrial Way
Ellis	Malabarismo	73 Industrial Way
Harrison	Limpieza ligera	73 Industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2FN. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".

Un alternativa 2FN a este diseño representaría la misma información en dos tablas:

Empleados
Empleado	Lugar actual de trabajo
Jones	114 Main Street
Bravo	73 Industrial Way
Ellis	73 Industrial Way
Harrison	73 Industrial Way

Habilidades de los empleados
Empleado	Habilidad
Jones	Mecanografía
Jones	Taquigrafía
Jones	Tallado
Bravo	Limpieza ligera
Ellis	Alquimia
Ellis	Malabarismo
Harrison	Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Sin embargo, no todas las tablas 2FN están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:

Ganadores del torneo
Torneo	Año	Ganador	Fecha de nacimiento del ganador
Des Moines Masters	1998	Chip Masterson	14 de marzo de 1977
Indiana Invitational	1998	Al Fredrickson	21 de julio de 1975
Cleveland Open	1999	Bob Albertson	28 de septiembre de 1968
Des Moines Masters	1999	Al Fredrickson	21 de julio de 1975
Indiana Invitational	1999	Chip Masterson	14 de marzo de 1977

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3FN).

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente, pero no siempre, en 2FN. Además de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas.

Las múltiples claves candidatas ocurren en la siguiente tabla:

Modelos eléctricos de cepillo de dientes
Fabricante	Modelo	Nombre completo del modelo	País del fabricante
Forte	X-Prime	Forte X-Prime	Italia
Forte	Ultraclean	Forte Ultraclean	Italia
Dent-o-Fresh	EZBrush	Dent-o-Fresh EZBrush	USA
Kobayashi	ST-60	Kobayashi ST-60	Japón
Hoch	Toothmaster	Hoch Toothmaster	Alemania
Hoch	Contender	Hoch Contender	Alemania

Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no está en 2NF. {Fabricante, Modelo} es también una clave candidata, y País del fabricante es dependiente en un subconjunto apropiado de él: Fabricante.

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Un ejemplo de una tabla 2FN que falla en satisfacer los requerimientos de la 3FN es:

Ganadores del torneo
Torneo	Año	Ganador	Fecha de nacimiento del ganador
Indiana Invitational	1998	Al Fredrickson	21 de julio de 1975
Cleveland Open	1999	Bob Albertson	28 de septiembre de 1968
Des Moines Masters	1999	Al Fredrickson	21 de julio de 1975
Indiana Invitational	1999	Chip Masterson	14 de marzo de 1977

La única clave candidata es {Torneo, Año}.

La violación de la 3FN ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.

Para expresar los mismos hechos sin violar la 3FN, es necesario dividir la tabla en dos:

Ganadores del torneo
Torneo	Año	Ganador
Indiana Invitational	1998	Al Fredrickson
Cleveland Open	1999	Bob Albertson
Des Moines Masters	1999	Al Fredrickson
Indiana Invitational	1999	Chip Masterson

Fecha de nacimiento del jugador
Jugador	Fecha de nacimiento
Chip Masterson	14 de marzo de 1977
Al Fredrickson	21 de julio de 1975
Bob Albertson	28 de septiembre de 1968

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3FN.

Bibliografia:

http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

http://es.wikipedia.org/wiki/Primera_forma_normal

http://es.wikipedia.org/wiki/Segunda_forma_normal

http://es.wikipedia.org/wiki/Tercera_forma_normal