domingo, 15 de mayo de 2011

HERENCIA


El concepto de herencia constituye, la principal innovación del desarrollo orientado a objetos. Se trata de un concepto bastante simple e intuitivo que, de una manera informal, puede definirse como:
"el mecanismo que permite definir una clase de objetos tomando como base la definición de otra clase"
Una clase se define en términos de atributos y de métodos (u operaciones). Por tanto, otra forma de expresar la definición anterior seria la siguiente:
"herencia es el mecanismo que permite a una clase de objetos incorporar atributos y métodos de otra clase, añadiéndolos a los que ya posee".
En la terminología habitual, la clase que hereda las características de otra y la clase de partida reciben los calificativos de "subclase" y "superclase", respectivamente. De ahí que, en numerosas ocasiones, la relación de herencia aparezca también referenciada como "superclase/subclase".
Por otro lado, también suele ser muy habitual hablar en términos de "clase padre" y "clase hija", dado lo intuitivo de ambos términos.
Herencia simple contra múltiple
Hay dos grandes clases de la herencia de tipo: simple y múltiple. En términos generales, la herencia simple significa que cada subtipo tiene solamente un supertipo y sólo hereda propiedades de ese tipo; herencia múltiple significa que un subtipo puede tener cualquier cantidad de supertipos y hereda propiedades de todos ellos. Obviamente, el primero es un caso especial del segundo.

Herencia escalar, de tupia y de relación
De manera clara, la herencia tiene implicaciones para los valores que no son escalares y también para los escalares, ya que a final de cuentas, esos valores que no son escalares están construidos con valores escalares. Por supuesto, tiene implicaciones en particular para los valores de tupia y de relación. Sin embargo, aun la herencia escalar es bastante complicada (de nuevo, de manera sorprendente.



Herencia estructural contra la herencia de comportamiento
Recuerde que los valores escalares pueden tener una estructura o representación interna (física) de una complejidad cualquiera; por ejemplo, las elipses y los círculos pueden ser legítimamente considerados como valores escalares en circunstancias adecuadas (como ya sabemos), aunque su estructura interna pueda ser bastante compleja. Sin embargo, esa estructura
interna siempre está oculta ante el usuario. De esto se deduce que cuando hablamos de herencia (al menos en lo que se refiere a nuestro modelo) no queremos decir herencia de estructura, ¡ya que desde el punto de vista del usuario no hay estructura a heredar! En otras palabras, estamos interesados en lo que a veces se llama herencia de comportamiento y no en la herencia estructural (donde "comportamiento" se refiere a los operadores; aunque le
recordamos que al menos en nuestro modelo también se heredan las restricciones).

Un ejemplo de Herencia de tipos:

Supóngase que se dispone de la siguiente definición de tipos para las personas:

create type Persona (nombre varchar(20), direccion varchar(20))

Puede que se desee guardar en la base de datos más información sobre las personas que son estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores también son personas, se puede utilizar la herencia para definir los tipos de estudiante y profesor.

create type Estudiante under Persona (curso varchar(20), departamento varchar(20)) create type Profesor under Persona (sueldo integer, departamento varchar(20))

Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y dirección. Estudiante y Profesor se denominan subtipos de Persona y ésta, a su vez, es un supertipo de Estudiante y de Profesor.

Ejemplo de Herencia en Tablas:

Las subtablas se corresponden con la noción del modelo E-R de la especialización y la generalización. Por ejemplo, supóngase que se define la tabla personas de la manera siguiente:

create table persona of Persona

Se pueden definir entonces las tablas estudiantes y profesores como subtablas de persona:

create table estudiantes of Estudiante under persona create table profesores of Profesor under persona

Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre.
Por tanto, cada atributo presente en persona debe estar también presente en las subtablas. Además, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla presente es estudiantes o profesores también están presentes implícitamente en persona. Así, si una consulta usa la tabla persona, encontrará no sólo las tuplas insertadas directamente en la tabla, sino también en las tuplas insertadas en sus subtablas estudiantes y profesores. Sin embargo, sólo se puede acceder a los atributos que están presentes en persona.

POLIMORFISMO
Otro concepto interesante, con importantes aportaciones en áreas tales como la flexibilidad o la legibilidad del software, es el de polimorfismo. Tras este término, un tanto oscuro, subyace una idea bastante simple. En su más amplia expresión, el polimorfismo puede definirse como:
"el mecanismo que permite definir e Invocar funciones idénticas en denominación e interfaz, pero con implementaron diferente".
Esta definición introduce un aspecto muy importante del polimorfismo: la asociación, o vínculo, entre cada llamada a una de estas funciones polimorfismo y la implementación concreta finalmente invocada. Cuando este vinculo puede establecerse en tiempo de compilación, se suele hablar de vinculación estática (static binding). Por contra, cuando la implementación a emplear, puede determinarse en tiempo de ejecución, el término empleado es el de vinculación dinámica (dynamic binding).





domingo, 10 de abril de 2011

OTRAS FORMAS DE NORMALIZACION


Forma Normal Boyce-Codd
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En terminos menos formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.



Cuarta Forma Normal
La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.



Quinta Forma Normal o Forma Normal de Proyección-Unión
La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF), es un nivel de normalización de bases de datos designado para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5NF si y sólo si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas.



Forma Normal de Proyección-Unión Fuerte, Extra Fuerte Y Clave de Dominio

Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.

viernes, 8 de abril de 2011

TAREA DE NORMALIZACION FACTURACION

EJEMPLO DE NORMALIZACION CON FACTURACION:


Factura
Num_Factura
Fecha
Nom_Cliente
Dir_Cliente
Nit_Cliente
4545
11/07/11
Juan Perez
Zona 11
417823-8
8456
08/08/11
Ana Amado
Zona 12
454586-9
4585
06/02/11
Soila Sanchez
Zona 13
825968-2

Factura
Nom_Vendedor
Cant_Prod
Desc_Prod
Precio_Unitario
Precio_Total
Total de Factura
Jose Paz
2
Brochas
15
30
755
Mario Coj
5
Laminas
95
475
755
Ana Solis
5
Sacos de Cal
50
250
755

1FN

Factura
Num_Fact
Fecha
Nom_Cliente
Dir_Cliente
Nit_Cliente
Nom_Vend
Total_Fact
4545
11/07/11
Juan Perez
Zona 11
417823-8
Jose Paz
755
8456
08/08/11
Ana Amado
Zona 12
454586-9
Mario Coj
755
4585
06/02/11
Soila Sanchez
Zona 13
825968-2
Ana Solis
755

DetalleFactura
Num_Fact
Cod_Prod
Cant_Prod
Desc_Prod
Precio_Uni
Precio_Total
4545
GLX
15
Brochas
15
30
8456
HSM
95
Laminas
95
475
4585
ADR
50
Sacos de Cal
50
250






2FN

Factura
Num_Fact
Fecha
Nom_Cliente
Dir_Cliente
Nit_Cliente
Nom_Vend
Total de Factura
4545
11/07/11
Juan Perez
Zona 11
417823-8
Jose Paz
755
8456
08/08/11
Ana Amado
Zona 12
454586-9
Mario Coj
755
4585
06/02/11
Soila Sanchez
Zona 13
825968-2
Ana Solis
755

DetalleFactura
Num_Fact
Cod_Producto
Cant_Prod
Precio Total
4545
GLX
15
30
8456
HSM
95
475
4585
ADR
50
250

Producto
Cod_Producto
Descripcion_Producto
Precio Unitario
GLX
Brochas
15
HSM
Laminas
95
ADR
Sacos de Cal
50

3FN

Factura
Num_Fact
Fecha
Cod_Cliente
Cod_Vendedor
Total Factura
4545
11/07/11
M5
J8G
755
8456
08/08/11
G7
D5D
755
4585
06/02/11
B8
S6R
755






Vendedor
CodigoVendedor
NombreVendedor
J8G
Jose Paz
D5D
Mario Coj
S6R
Ana Solis

Cliente
Cod_Cliente
Nom_Cliente
Dir_Cliente
Nit_Cliente
M5
Juan Perez
Zona 11
417823-8
G7
Ana Amado
Zona 12
454586-9
B8
Soila Sanchez
Zona 13
825968-2

DetalleFactura
Num_Factura
Cod_Factura
CantidadProducto
PrecioTotal
4545
JMS
15
30
8456
ASE
95
475
4585
ESR
50
250

Producto
CodigoProducto
DescripcionProducto
PrecioTotal
GLX
Brochas
30
HSM
Laminas
475
ADR
Sacos de Cal
250

domingo, 3 de abril de 2011

2do Ejemplo

Supongamos que nos plantean desarrollar una B.D. para una empresa de transporte que quiere
gestionar los envíos de pedidos a los clientes. Podemos plantearnos un diseño inicial de una tabla
para esta base de datos que  contenga la información del código del envío, el camión que lo
transporta, los datos del cliente al que va  dirigido así como cada uno de los artículos que
componen el envío incluyendo sus características, tal y como se muestra en la figura siguiente:


ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion
Cliente_1
Direccion_cliente_1
Pedido_cliente_1
Articulo_1_pedido_cliente_1
Volumen_articulo_1_pedido_cliente_1
 …
Articulo_I_pedido_cliente_1
Volumen_articulo_I_pedido_cliente_1
 …
Cliente_N
Direccion_cliente_N
Pedido_cliente_N
Articulo_1_pedido_cliente_N
Volumen_articulo_1_pedido_cliente_N
 …
Articulo_J_pedido_cliente_N
Volumen articulo J pedido cliente N





Es evidente que este diseño inicial no es bueno, por lo que habrá
que aplicar las tres primeras formas normales y llevar el diseño a
3FN.


La 1FN debemos aplicarla a la tabla ENVIO, obteniendo una nueva tabla PEDIDO, sobre la cual
debemos volver a aplicar la 1FN, obteniendo una nueva tabla PEDIDO_ARTICULO, para poder
tener valores atómicos. Después de esto, el esquema queda como sigue:
ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Direccion_cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo
Volumen

Apliquemos ahora la 2FN; observamos que en la tabla PEDIDO_ARTICULO el campo volumen
solo depende del  codigo_articulo, no dependiendo para nada del  pedido_cliente, por lo cual
obtenemos una nueva tabla, que llamaremos ARTICULO:

ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Direccion_cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo

ARTICULO
Codigo articulo
Volumen

Aplicando la 3FN, vemos que en la tabla ENVIO los datos modelo_camion y capacidad_camion
dependen de matricula_camion, que no es clave primaria, por lo cual debemos sacarlos en una
nueva tabla. Esto mismo sucede con el dato  direccion_cliente respecto a  cliente en la tabla
PEDIDO_CLIENTE. Teniendo esto en cuenta, el diseño final queda como:


CLIENTE
Cliente
Direccion_cliente


ENVIO
Codigo_envio
Matricula_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo


CAMION
Matricula_camion
Modelo_camion
Capacidad_camion


ARTICULO
Codigo articulo
Volumen

Normalizacion de Base de Datos (las 3 formas normales)

Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar optimamente y no perjudicar las Performance por mala arquitectura.Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES.

La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalizaciòn.Si tenemos una tabla clientes, en la tabla ventas, solo deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.
La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo
 VentaIDItemID FechaVenta ClienteVenta ProductoId Cantidad 
1 01/12/20072334 10 
 01/12/200723333
 01/12/2007266643 34 
 01/12/200721 
 1 02/12/20073566 
Ahi tenemos un claro problema !!!Acaso no se busca NO REPETIR DATOS?Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha…Por que no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es evidente que la columna ClienteVenta yFechaVenta se repetirán por cada venta realizada.Es por ello que proponemos el siguiente esquema 
 VentaIDItemID ProductoId Cantidad 
12334 10 
3333
66643 34 
21 
 13566 
Y ahora nuestra nueva tabla maestra
VentaId FechaVenta ClienteVenta 
101/12/2007 2
02/12/2007 
Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender de toda la clave y no constituir un dato unico para cada grupo de registros.
La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :
  1. Ninguna Columna puede depender de una columna que no tenga una clave
  2. No puede haber datos derivados
En el 2do ejemplo hemos descubierto campos que dependian de la clave principal (VentaID) y que podrian incluirse en una tabla maestra.Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna de nuestra tabla.
 VentaIDItemID ProductoID Cantidad Descripcion Medida Proveedor 
 13455 12 Impresora HP LJ8000 122cm 
 12455 34 Scanner HP A3555 33cm 
 215444 21 Mouse HP Wireless 
Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.
ConclusiónFinalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance.