BITEC BD I

La tecnologa Cliente Servidor

Est tecnologa bsicamente esta compuesta por tres elementos claramente

identificados.

Front Client : Que es el programa cliente que se conecta a la base

de datos mediante un proveedor de datos, haciendo uso de una
cadena de conexin a fin de poder seleccionar el proveedor, algunos
proveedores excluyen algunas partes de la cadena de conexin
cuando este es de propsito especifico como el sqlclient.
Proveedor: Es el encarga de enlazarse y solicitar al servidor de
datos las peticiones hechas por el cliente frontal.
Motor de Datos: Es el encargado de gestionar los datos, asimismo
como de procesar las peticiones T-SQL, que le han sido enviadas por
el proveedor de datos.

Universidad Cesar Vallejo

Tecnologa Cliente/Servidor
Front
Front Proveedor
Proveedor
Client
Client Back End
((Proveedor
Proveedor (Motor de
((Cliente
Cliente De
De Datos
Datos)) Datos)
Frontal)
Frontal)

Lenguajes .Net SQLClient. SQL Server.

Java. Oracle Client. Oracle.
VFP Oledb. Informix.
Power Builder ODBC. VFP.
VB 6.0 Oledb/Odbc. Exchange.
Excel. Net Library. Excel.


Power Point, Word.

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

NORMALIZACION

La normalizacin de datos se refiera a la aplicacin de un conjunto de reglas

bien definidas sobre aquellas entidades que representa anomalas en los
atributos que las describen. El objetivo principal apunta a la eliminacin o
disminucin al mximo de la redundancia de datos y de datos innecesarios

Para tener un mejor idea de las reglas de la normalizacin y su aplicacin

en las entidades y sus atributos, desarrollaremos un ejemplo, veamos:

Relacin No normalizada

Supongamos que deseamos modelar los datos relacionados a un sistema de

ventas. Una de las entidades que forma fuerza es la FACTURA DE VENTA, ya
que con este documento llevaremos la cuenta de las ventas efectuados.
Entonces describiremos la entidad FACTURA con una lista de todos los
atributos que contiene es decir aquellos que estn en el mismo documento
factura, tal como se muestra a continuacin.

La entidad FACTURA sera identificada por el atributo numerodefactura por lo

tanto este atributo no deber estar en blanco ni tener valores repetidos en
dos facturas diferentes.
El proceso de normalizacin de datos lo haremos identificando las anomalas
mas importantes veamos

Primera Anomala

En una misma factura hay un grupo de productos distintos que conforman

la lnea de venta. Esta situacin genera problemas de almacenamiento de

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

datos ya que por cada producto distinto nos veramos obligados a guardar
los datos de la misma factura a la que dichos productos pertenecen.
Entonces aplicaremos la siguiente regla para reducir esta anomala

PRIMERA FORMA NORMAL

El primer paso para la normalizaron de una entidad es eliminar los grupos
repetidos en el ejemplo que estamos normalizando dividiremos la entidad
en dos entidades de la siguiente manera.

Ahora no existen grupos de datos repetidos en la entidad FACTURA pues

ellos pasaron a la nueva entidad LINEADEVENTA en la cual el
numerodefactura es una clave. Seguiremos buscando anomalas

Segunda anomala

No todos los atributos en la entidad LINEADEVENTA dependen de la clave

conectada, pues hay algunos atributos que solo dependen de una parte de
ella. Eso nos lleva a la duplicacin forzosa de los datos del producto en
varias LINEADEVENTA de facturas diferentes que se refiere al mismo
producto
Para expresar mejor la afirmacin analicemos el siguiente caso:

1. Una persona A compra 50 unidades del producto X mas 20 unidades

del producto Y mas 15 unidades del producto Z.
2. Otra persona B compra 25 unidades del producto Z mas 2 unidades
del producto.

Cual es el problema?

En la primera FACTURA almacenaremos los datos del cliente A y en su

respectiva lnea de ventas almacenaremos los datos del producto X con su
cantidad de compra igual a 50 mas los datos del producto Y con su cantidad
de compra igual a 20 mas los datos del producto Z con su cantidad de
compra igual a 15.

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

En la segunda factura necesitaremos almacenar los datos del cliente B y en

su respectiva LINEADEVENTA almacenaremos los datos del producto Z
(Cmo otra vez?) con su cantidad de compra igual a 25 mas los datos del
producto Y (Qu ya no lo almacenamos antes?) con su cantidad de compra
igual a 2.
En el problema se presenta precisamente en las observaciones hechas en
las interrogantes ya que los datos de los productos se estan almacenando
cada vez que aparecen en las LINEADEVENTA.
Absurdo Verdad?.

Apliquemos entonces la siguiente regla para resolver el problema

presentado

SEGUNDA FORMA NORMAL

En la segunda forma normal todos los atributos de una entidad sern
funcionalmente dependientes de la clave primaria. Esta regla se aplica a
aquellas entidades que se identifican a travs de atributos de claves
conectadas

OK. Ahora podemos afirmar que todos los datos de la entidad LINEDEVENTA
se pueden identificar con el atributo concatenado numerodefactura mas
codigodelproducto ya que los datos de los productos fueron separados en
una nueva entidad. Ahora analicemos las anomalas.

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

Tercera Anomala

En la identidad FACTURA existen atributos dependientes de otros atributos

no claves. Si analizamos los datos almacenados de la entidad FACTURA
encontraremos que estn repitiendo los datos de os clientes en forma
innecesaria, lo cual origina que cada vez que se produzca una FACTURA
debern registrarse los datos del cliente, pero nos preguntamos Y si es el
mismo cliente que esta efectuando un nueva compra?
Ah, en este caso tendramos que registrar los datos del mismo cliente otra
vez. Qu absurdo, verdad?

En este mismo escenario podremos encontrar que hay datos que sern
obtenidos con operaciones de calculo, de ser as podremos elegir su
almacenamiento segn sea el nivel de relevancia de dichos datos, Por
ejemplo, tenemos el caso de datos: totalbruto, descuento,
impuestodeventa, totalneto. Para estos atributos puedo elegir entre
almacenarlos o calcularlos al momento de recuperar una factura
determinada.

De repente nos interesa almacenar los datos del descuento (Dado en

porcentaje) ya que puede ser de naturaleza cambiante, as mismo,
podremos estar interesados en registrar el valor de los impuestos por las
mismas razones. No olvidar que estas desiciones las tomaremos segn sea
el caso.

Apliquemos la siguiente regla para resolver los casos.

Tercera Forma Normal

Una entidad esta en tercera forma normal si todos sus atributos no claves
son funcionalmente dependientes de su atributo de clave principal. Adems
se debe eliminar los atributos calculables para el caso de estudio.
Finalmente las entidades quedaran de la siguiente manera:

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

Existen otras reglas de normalizacin para entidades ms complejas, pero

la recomendacin del caso es llegar siempre a la tercera forma normal.

Nota:

Importante antes de finalizar el tema de la normalizacin de datos y su

representacin en el modelado, permtame la observacin acerca de mas
convenciones de notacin que se estudiaron en el acpite anterior, pues
bien, teniendo en cuenta estas convenciones, el modelado de datos
quedara de la siguiente manera.

EJMPLOS

Cdigo Nombre Cursos

1 Marcos Ingls

2 Lucas Contabilidad, Informtica

3 Marta Ingls, Contabilidad

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez

BITEC BD I

PRIMERA FORMA NORMAL

TABLA A TABLA B

Cdigo Nombre Cdigo Curso

1 Marcos 1 Ingls

2 Lucas 2 Contabilidad

3 Marta 2 Informtica

3 Ingls

3 Informtica

SEGUNDA FORMA NORMAL

Cdigo Empleado Cdigo Dpto. Nombre Departamento Aos

1 6 Juan Contabilidad 6

2 3 Pedro Sistemas 3

3 2 Sonia I+D 1
4 3 Vernica Sistemas 10

2 6 Pedro Contabilidad 5

Cdigo Nombre Curso Aula

1 Marcos Informtica Aula A

2 Lucas Ingls Aula B

3 Marta Contabilidad Aula C

TERCERA FORMA NORMAL

Tabla A Tabla B

Cdigo Nombre Curso Curso Aula

1 Marcos Informtica Informtica Aula A

2 Lucas Ingls Ingls Aula B

3 Marta Contabilidad Contabilidad Aula C

ECPMSD.NET CPDBA CPNA Ing Miguel Arturo Valle Pelaez