Instituto Tecnolgico LEONARDO DA VINCI Ro Cuarto Carrera: ANALISTA DE SISTEMAS Ctedra: DISEO DE BASE DE DATOS Parte 1 Docente: Pedro

ro M. Lemo Analista de Sistemas Ciclo lectivo: 2010 www.pedrolemo.com.ar

DISEO DE APLICACIONES MODELO DE 3 CAPAS

Arquitectura Cliente/Servidor en tres capas (three-tier), tambin llamado Modelo de Tres Capas La arquitectura de una aplicacin es la vista conceptual de la estructura de esta. Toda aplicacin contiene cdigo de presentacin, cdigo de procesamiento de datos y cdigo de almacenamiento de datos. La arquitectura de las aplicaciones difiere segn como est distribuido este cdigo. Cliente-Servidor, definicin: Es un sistema donde el cliente es una mquina que solicita un determinado servicio y se denomina servidor a la mquina que lo proporciona. Los servicios pueden ser: Ejecucin de un determinado programa. Acceso a un determinado banco de informacin. Acceso a un dispositivo de hardware. Es un elemento primordial, la presencia de un medio fsico de comunicacin entre las mquinas, o sea, la RED. Los servidores ms comunes son: Servidores de archivos.- Proporciona archivos para clientes. Si los archivos no fueran tan grandes y los usuarios que comparten esos archivos no fueran muchos, esto sera una gran opcin de almacenamiento y procesamiento de archivos. El cliente solicita los archivos y el servidor los ubica y se los enva.

Servidores de Base de Datos.- Son los que almacenan gran cantidad de datos estructurados, se diferencian de los de archivos pues la informacin que se enva est ya resumida en la base de datos. Ejemplo: El Cliente hace una consulta, el servidor recibe esa consulta (SQL) y extrae solo la informacin pertinente y enva esa respuesta al cliente. Servidores de Software de Grupo.- El software de grupo es aquel, que permite organizar el trabajo de un grupo. El servidor gestiona los datos que dan soporte a estas tareas. Por ejemplo: almacenar las listas de correo electrnico. El Cliente puede indicarle, que se ha terminado una tarea y el servidor se lo enva al resto del grupo. Servidores WEB.- Son los que guardan y proporcionan Pginas HTML. El cliente desde un browser o link hace un llamado de la pgina y el servidor recibe el mensaje y enva la pgina correspondiente. Servidores de correo.- Gestiona el envo y recepcin de correo de un grupo de usuarios (el servidor no necesita ser muy potente). El servidor solo debe utilizar un protocolo de correo. Servidor de objetos.- Permite almacenar objetos que pueden ser activados a distancia. Los clientes pueden ser capaces de activar los objetos que se encuentran en el servidor. Servidores de impresin.- Gestionan las solicitudes de impresin de los clientes. El cliente enva la solicitud de impresin, el servidor recibe la solicitud y la ubica en la cola de impresin, ordena a la impresora que lleve a cabo las operaciones y luego avisa a la computadora cliente que ya acabo su respectiva impresin. Servidores de aplicacin.- Se dedica a una nica aplicacin. Es bsicamente una aplicacin a la que pueden acceder los clientes.

PROGRAMACION POR CAPAS

La programacin por capas es un estilo de programacin en el que el objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la capa de presentacin al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al nivel requerido sin tener que revisar entre cdigo mezclado. Un buen ejemplo de este mtodo de programacin sera el modelo de interconexin de sistemas abiertos.

Adems, permite distribuir el trabajo de creacin de una aplicacin por niveles; de este modo, cada grupo de trabajo est totalmente abstrado del resto de niveles. En el diseo de sistemas informticos actual se suele usar las arquitecturas multinivel o Programacin por capas. En dichas arquitecturas a cada nivel se le confa una misin simple, lo que permite el diseo de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). Capas y niveles 1.- Capa de presentacin: es la que ve el usuario (tambin se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la informacin y captura la informacin del usuario en un mnimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica nicamente con la capa de negocio. Tambin es conocida como interfaz grfica y debe tener la caracterstica de ser "amigable" (entendible y fcil de usar) para el usuario. 2.- Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lgica del negocio) porque es aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de l. Tambin se consideran aqu los programas de aplicacin. 3.- Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Est formada por uno o ms gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio. Todas estas capas pueden residir en un nico ordenador, si bien lo ms usual es que haya una multitud de ordenadores en donde reside la capa de presentacin (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o ms ordenadores. As, si el tamao o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirn las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separacin, esta capa de negocio podra residir en uno o ms ordenadores que realizaran solicitudes a una nica base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos. En una arquitectura de tres niveles, los trminos "capas" y "niveles" no significan lo mismo ni son similares. El trmino "capa" hace referencia a la forma como una solucin es segmentada desde el punto de vista lgico: Presentacin/ Lgica de Negocio/ Datos. En cambio, el trmino "nivel" corresponde a la forma en que las capas lgicas se encuentran distribuidas de forma fsica. Por ejemplo: Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en un solo ordenador (Presentacin+lgica+datos). Se dice que la arquitectura de la solucin es de tres capas y un nivel. Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en dos ordenadores (presentacin+lgica, lgica+datos). Se dice que la arquitectura de la solucin es de tres capas y dos niveles.

Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en tres ordenadores (presentacin, lgica, datos). La arquitectura que la define es: solucin de tres capas y tres niveles.

COMO DISTRIBUIR LAS CAPAS?

EL ANTIGUO MODELO CLIENTE-SERVIDOR DE 2 CAPAS, LAS REGLAS DE NEGOCIO Y COMO SE LLEGA AL MODELO DE TRES CAPAS
Toda aplicacin trata de reflejar parte del funcionamiento del mundo real, para automatizar tareas que de otro modo seran llevadas a cabo de modo ms ineficiente, o bien no podran realizarse. Para ello, es necesario que cada aplicacin refleje las restricciones que existen en el negocio dado, de modo que nunca sea posible llevar a cabo acciones no vlidas. A las reglas que debe seguir la aplicacin para garantizar esto se las llama reglas de negocio, o business rules. Ejemplos de tales reglas son: no permitir crear facturas pertenecientes a clientes inexistentes, controlar que el saldo negativo de un cliente nunca sobrepase cierta cantidad, etc. En realidad, la informacin puede ser manipulada por muchos programas distintos: as, una empresa puede tener un departamento de contabilidad que controle todo lo relacionado con compras, cobros, etc., y otro departamento tcnico, que est interesado en relacionar diversos parmetros de produccin con los costes. La visin que ambos departamentos tendrn de la informacin y sus necesidades sern distintas, pero en cualquier caso siempre se debern respetar las reglas de negocio. El hecho de que la informacin sea manipulada por diversos programas hace ms difcil garantizar que todos respetan las reglas, especialmente si las aplicaciones corren en diversas mquinas, bajo distintos sistemas operativos, y estn desarrolladas con distintos lenguajes y herramientas. Tipos de reglas de negocio Antes de seguir adelante con el estudio de la problemtica que presenta la implementacin de las reglas de negocio, vamos a establecer una clasificacin de las mismas en varios grupos. El primer grupo de reglas de negocio engloba todas aquellas reglas que se encargan de controlar que la informacin bsica almacenada para cada atributo o propiedad de una entidad u objeto es vlida: no hay precios de artculos negativos, el sexo de una persona solo puede ser masculino o femenino, una fecha siempre debe ser una fecha vlida (no existe el 30 de Febrero, cierto?), etc. A estas reglas las llamaremos reglas del modelo de datos. Otro grupo importante de reglas incluye todas aquellas reglas que controlan las relaciones entre los datos. Estas reglas especifican, por ejemplo, que todo pedido debe ser realizado por un cliente, y que el mismo debe estar dado de alta en nuestro sistema: adems, una vez que un cliente haya hecho algn pedido, se deber garantizar que no es posible eliminarlo, a menos que previamente se eliminen todos sus pedidos. Estas reglas constituyen las reglas de relacin. Es frecuente que a partir de cierta informacin se pueda derivar otra: por ejemplo, el total de un pedido se puede calcular a partir de las distintas lneas que lo componen, mientras que el total de cada lnea se puede calcular a partir del nmero de unidades vendidas y el precio por unidad. Al conjunto de reglas que especifican y controlan la obtencin de informacin que se puede calcular a partir de la ya existente se las llama reglas de derivacin. Otro grupo de reglas de negocio es el compuesto por las reglas de restriccin, que restringen los datos que el sistema puede contener. Ntese que este grupo de reglas se solapa en cierto modo con las reglas del modelo de datos, dado que aquellas tambin impiden la introduccin de datos errneos, como se vio anteriormente. La diferencia estriba en que las reglas de restriccin restringen el valor de los atributos o propiedades de una entidad ms all de las restricciones

bsicas que sobre las mismas existen: por ejemplo, para un saldo existe una regla bsica (regla del modelo de datos) que indica que ste debe ser un nmero (no por obvia es menos regla!), pero adems puede haber una regla que indique que el saldo nunca puede ser menor que cierta cantidad tope establecida para cierto tipo de clientes. Esta sera lo que aqu denominamos una regla de restriccin, y la diferencia fundamental estriba en el hecho de que este tipo de reglas requiere para su verificacin del acceso a otros fragmentos de informacin, algo que no sucede con las reglas del modelo de datos. Esto tiene ciertas consecuencias que se vern ms adelante. El ltimo grupo de reglas de negocio incluye aquellas reglas que determinan y limitan cmo fluye la informacin a travs de un sistema. Por ejemplo, un cliente puede hacer una peticin de anlisis a un laboratorio, que anota un encargado: hecho esto, se genera un parte para uno o ms analistas, estos realizan las mediciones correspondientes y devuelven los partes con la informacin pertinente, a partir de la cul se genera un informe de anlisis, que ser un anlisis vlido solo cuando sea firmado por los responsables de garantizar su correccin. A las reglas que indican qu camino recorre la informacin y obligan a que se sigan solo los caminos vlidos se las llama reglas de flujo. Capas en un sistema Cliente/Servidor clsico (2 capas) En un esquema Cliente/Servidor clsico existen dos capas, el cliente y el servidor: ste est ubicado normalmente en otra mquina, y suele ser un gestor de base de datos, como DB2, SQL Server, Oracle, aunque tambin puede ser una base de datos ms pequea, como Paradox, dBase, etc., que accedemos directamente desde nuestra aplicacin cliente. Los mejores gestores de base de datos relacionales proporcionan soporte para implementar en ellos bastantes reglas de negocio, mediante el uso de claves primarias, integridad referencial, triggers, etc., mientras que sistemas como dBase y otros apenas proporcionan soporte para reglas de negocio. Suponiendo que tengamos la informacin en un gestor de bases de datos potente, podremos despreocuparnos de llevar a cabo la codificacin de numerosas validaciones en nuestras aplicaciones: as, si en la base de datos creamos una regla de integridad referencial que indica que todo pedido pertenece a un cliente, el gestor de base de datos rechazar cualquier intento de almacenar un pedido en el que se nos haya olvidado indicar el mismo. Cualquier aplicacin que acceda a esta base de datos se beneficiar de esta y otras validaciones automticamente, sin tener que aadir ni una lnea de cdigo. Si estamos utilizando una base de datos menos potente, como dBase, no estamos de suerte. Casi todas las reglas de negocio debern implementarse dentro de los programas que accedan a la base de datos. Si los programas que acceden a la base de datos son varios, garantizar que en todos ellos se respetan todas las reglas puede llegar a ser muy difcil y engorroso, especialmente si se desarrollan con distintas herramientas. La necesidad de implementar reglas de negocio dentro de las aplicaciones cliente puede surgir tambin utilizando gestores de bases de datos ms potentes. En primer lugar, las bases de datos relacionales son cada vez ms potentes, pero no todas las reglas de negocio pueden reflejarse en ellas: por ejemplo, las reglas de flujo son bastante difciles de implementar dentro de la base de datos, y suelen ser las aplicaciones cliente las que controlan que la informacin sigue una ruta vlida a travs del sistema. Sin embargo, muchas de las reglas de negocio pueden reflejarse adecuadamente a nivel de la base de datos con estos gestores. El problema se agrava cuando la informacin del negocio se encuentra en distintas bases de datos, gestionadas por distintos gestores, digamos DB2 y Oracle: si, por ejemplo, en DB2 almacenamos la informacin sobre facturas, etc., y en la base de datos Oracle almacenamos informacin tcnica, como reparaciones llevadas a cabo en la maquinaria, cmo reflejamos que ciertas facturas corresponden a una reparacin, y garantizamos que no podamos relacionar una

reparacin con una factura inexistente? Evidentemente, aqu no hay manera de establecer una regla de integridad referencial entre tablas almacenadas en dos bases de datos distintas y correspondientes a distintos gestores de base de datos. De nuevo, la solucin al problema es implementar el chequeo en cada aplicacin cliente, comprobando que exista la factura en la tabla DB2 antes de referenciarla en la tabla de reparaciones Oracle. Ya que parece que de cualquier modo seremos nosotros mismos los encargados de obligar a que se cumplan algunas reglas de negocio, puede ser conveniente encontrar la manera de centralizar la gestin de estas reglas en un nico lugar, de modo que todo el cdigo necesario no se haya de duplicar en cada una de las aplicaciones. La solucin puede ser crear una aplicacin que se encargue de llevar a cabo estas tareas, de modo que todos los clientes pidan o enven informacin a la misma, no al gestor de base de datos en el servidor: a ste solo acceder la nueva aplicacin, que conforma una nueva capa dentro de un sistema Cliente/Servidor, la capa intermedia, con lo que nuestro sistema ha pasado de ser un sistema Cliente/Servidor convencional a ser un sistema con tres capas (three-tier). Conviene apuntar que pueden haber varias de estas aplicaciones, que llamaremos servidores de aplicacin, lo que permite distribuir la carga de trabajo. Ubicacin de las reglas de negocio La decisin de dnde ubicar una determinada regla de negocio dentro de una arquitectura C/S de tres capas puede simplificarse mucho si se atiende al tipo de regla de que se trata, utilizando la clasificacin introducida ms arriba. Las reglas del modelo de datos especifican los valores vlidos de cada atributo de las diversas entidades que se almacenan, lo que simplificando es lo mismo que decir los valores vlidos para cada campo de cada tabla. Estas reglas deben, a ser posible, reforzarse en el servidor: esto se hace en primer lugar escogiendo correctamente el tipo de los campos de cada tabla (no almacenar una fecha en un campo de tipo cadena si nuestra base de datos dispone de campos del tipo fecha), y donde el servidor lo soporte, mediante restricciones (por ejemplo, en MSSQL Server 2005 es posible especificar mediante CHECK diversas condiciones que debe verificar un dato para poder almacenarse en un campo), etc. El hacer esto as proporcionar mayor robustez a la base de datos. Como complemento de esto, sin embargo, se debe implementar estas validaciones tambin a nivel de cliente, por una simple razn: evitar trabajo y esperas innecesarias a los usuarios. Todos hemos rellenado algn formulario HTML varias veces hasta que por fin los datos introducidos son vlidos: esto es as porque en un formulario HTML raramente se lleva a cabo la validacin de los datos en el cliente, por lo que la informacin no se chequea hasta que llega al servidor, debiendo el usuario en el cliente esperar a cualquier mensaje de xito o error. Lo mejor sera no tener que llevar a cabo ningn tipo de programacin, y que las reglas del modelo de datos se pudieran importar del servidor al cliente, hacindose en el mismo gran parte de los controles necesarios para garantizar la validez de la informacin introducida por el usuario: esto no es muy difcil, dado que son chequeos relativamente sencillos, al afectar solo a un campo, y de hecho algunos productos, como OleEnterprise de Borland, incorporan la posibilidad de importar estas reglas del servidor. Por lo que respecta a las reglas de relacin, el lugar ms adecuado para implementarlas es, sin lugar a dudas, el servidor. La mayor parte de los gestores de base de datos proporcionan integridad referencial y los mecanismos necesarios para implementar fcilmente estas reglas, y esto proporciona una robustez enorme a la base de datos. Adems, el hecho de que los datos necesarios para verificar si se respetan las relaciones residan en la misma base de datos/mquina hace que estas verificaciones sean muy rpidas, mientras que si el chequeo se hace en el cliente se incrementar el trfico de red. El problema lo encontraremos si el negocio est distribuido en varias bases de datos: si ese es el caso, ser necesario implementar alguna de estas reglas en la capa intermedia, y que sta resida lo ms cerca posible de las bases de datos, a ser posible en la misma mquina o red local.

Las reglas de derivacin pueden variar mucho en complejidad: la informacin derivada ms simple, como calcular el total de una lnea de pedido, puede calcularse a partir de otros campos del mismo registro. Dado que no se requiere informacin adicional, y en general toda la informacin de un registro viaja a la vez al cliente, calcular esta informacin en el mismo es trivial, y no resulta gravoso. Ahora bien, si lo que se desea es calcular la suma de todos los pedidos de un cliente desde 1960, el volumen de informacin necesaria para calcular el total es enorme, y hacerla viajar a travs de la red no es recomendable. Lo ideal ser implementar el clculo de esta informacin de modo que se ejecute en el servidor, posiblemente mediante un procedimiento almacenado, o al menos mediante una sentencia SQL de agregacin, con lo que la nica informacin que viajar hasta el cliente ser el total, no todos los registros necesarios para calcularlo. Sin embargo, SQL, o las extensiones de SQL que proporcionan los distintos gestores de base de datos, no es un lenguaje de propsito general, por lo que puede ser difcil o imposible implementar ciertas reglas de derivacin. La solucin ideal puede pasar por implementar las reglas de derivacin en la capa intermedia: si sta reside en la misma mquina que el servidor, la informacin no deber viajar por la red, y aunque el clculo no ser tan rpido como si lo hace el gestor, puede ser suficiente. Si tenemos los datos distribuidos en diversas bases de datos, sta ser la nica solucin para implementar muchas de las reglas de derivacin. Las reglas de restriccin deben implementarse en el servidor, o en la capa intermedia. Dado que estas reglas contemplan restricciones en los datos que dependen casi siempre de informacin presente en varias tablas, llevar a cabo el control en el cliente puede implicar cierto trfico de red, por lo que es ms conveniente situar la implementacin de la regla ms cerca de los datos. El lugar ideal podra ser el servidor, pero aqu nos encontramos con las limitaciones del SQL de los gestores de base de datos, que dicho sea de paso, cada vez son menos, y con el posible problema del acceso a diversas bases de datos, por lo que ubicar estas reglas en la capa intermedia puede ser de nuevo una buena solucin. Por ltimo, quedan las reglas de flujo: estas reglas son excelentes candidatas a ser implementadas en la capa intermedia, dado que su complejidad suele ser bastante grande, lo que las hace inmanejables por un gestor de bases de datos.

DISEO DE BASES DE DATOS: REGLAS DE INTEGRIDAD - NORMALIZACION Reglas de integridad

La integridad referencial es un sistema de reglas que utilizan la mayora de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son vlidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos. Al definir cada atributo sobre un dominio se impone una restriccin sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios. Hay adems dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo. Nulos Cuando en un registro un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vaca, stos son valores que tienen significado. El nulo implica ausencia de informacin, bien porque al insertar el registro se desconoca el valor del atributo, o bien porque

para dicho registro el atributo no tiene sentido. Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas de implementacin. Regla de integridad de entidades La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los atributos que componen la clave primaria puede ser nulo. Por definicin, una clave primaria es un identificador irreductible que se utiliza para identificar de modo nico los registros. Que es irreductible? significa que ningn subconjunto de la clave primaria sirve para identificar los registros de modo nico. Si se permite que parte de la clave primaria sea nula, se est diciendo que no todos sus atributos son necesarios para distinguir los registros, con lo que se contradice la irreductibilidad. Ntese que esta regla slo se aplica a las relaciones base y a las claves primarias, no a las claves alternativas. Regla de integridad referencial La segunda regla de integridad se aplica a las claves externas: si en una relacin hay alguna clave externa, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos. La regla de integridad referencial se enmarca en trminos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cmo puede evitarse. La cuestin es qu hacer si estando en un estado legal, llega una peticin para realizar una operacin que conduce a un estado ilegal? Existen dos opciones: rechazar la operacin, o bien aceptar la operacin y realizar operaciones adicionales compensatorias que conduzcan a un estado legal. Por lo tanto, para cada clave externa de la base de datos habr que contestar a tres preguntas: Regla de los nulos: Tiene sentido que la clave externa acepte nulos? Regla de borrado: Qu ocurre si se intenta borrar el registro referenciado por la clave externa? o Restringir: no se permite borrar el registro referenciado. o Propagar: se borra el registro referenciado y se propaga el borrado a las registros que lo referencian mediante la clave externa. o Anular: se borra la el registro referenciado y los registros que lo referenciaban ponen a nulo la clave externa (slo si acepta nulos). Regla de modificacin: Qu ocurre si se intenta modificar el valor de la clave primaria del registro referenciado por la clave externa? o Restringir: no se permite modificar el valor de la clave primaria del registro referenciado. o Propagar: se modifica el valor de la clave primaria del registro referenciado y se propaga la modificacin a los registros que lo referencian mediante la clave externa. o Anular: se modifica el registro referenciado y los registros que lo referenciaban ponen a nulo la clave externa (slo si acepta nulos).

Qu es la normalizacin
Existen reglas para la construccin de Modelos de Datos Relacionales bien diseados. Estas reglas se conocen como FORMAS NORMALES, y el cumplimiento de estas formas es condicin necesaria para el buen diseo y funcionamiento montado sobre una base de datos relacional.

La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms fciles de mantener. Tambin se puede entender la normalizacin como una serie de reglas que sirven para ayudar a los diseadores de bases de datos a desarrollar un esquema que minimice los problemas de lgica. Cada regla est basada en la que le antecede. La normalizacin se adopt porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conduca a errores de lgica cuando se trataban de manipular los datos. Otra ventaja de la normalizacin de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repeticin de datos (redundancia), lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, as como las razones para hacerlo de esta manera. Grados de normalizacin Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalizacin. No siempre es una buena idea tener una base de datos conformada en el nivel ms alto de normalizacin, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin. En la tabla siguiente se describe brevemente en qu consiste cada una de las reglas, y posteriormente se explican con ms detalle. Primera Forma Normal (1FN) Segunda Forma Normal (2FN) Incluye la eliminacin de todos los grupos repetidos. Asegura que todas las columnas que no son llave sean completamente dependientes de la llave primaria (PK). Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son llave son dependientes de otras columnas que tampoco son llave.

Tercera Forma Normal (3FN)

Primera Forma Normal (1FN) Segn la definicin de Chris Date de la 1NF, una tabla est en 1NF si y solo si es "isomorfa a alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones: 1. No hay orden de arriba-a-abajo en las filas. 2. No hay orden de izquierda-a-derecha en las columnas. 3. No hay filas ni columnas duplicadas. 4. Cada interseccin de fila-columna contiene exactamente UN valor del dominio aplicable (y nada ms). 5. Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs de objeto, o timestamps ocultos]. La violacin de cualquiera de estas condiciones significara que la tabla no es estrictamente relacional, y por lo tanto no est en 1NF. Algunos ejemplos de tablas (o de vistas) que no satisface esta definicin de 1NF son: Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas duplicadas, en violacin de la condicin 3.

Una vista cuya definicin exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrnseco y significativo de la vista. Esto viola la condicin 1. Los registros en relaciones verdaderas no estn ordenados uno con respecto a otro. Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estara en violacin de la condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe ser observado que este aspecto de la condicin 4 es controvertido. Muchos autores consideran que una tabla est en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan stos para atributos (campos) que no sean clave, segn el modelo original de Codd sobre el modelo relacional, el cual hizo disposicin explcita para los nulos. Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna mltiples. Muy a menudo, los diseadores de bases de datos inexpertos harn algo similar a la tabla no normalizada. Una y otra vez, crearn columnas que representen los mismos datos. La normalizacin ayuda a clarificar la base de datos y a organizarla en partes ms pequeas y ms fciles de entender. En lugar de tener que entender una tabla gigantesca y monoltica que tiene muchos diferentes aspectos, slo tenemos que entender los objetos pequeos y ms tangibles, as como las relaciones que guardan con otros objetos tambin pequeos. Segunda Forma Normal La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un trmino que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos. Dicho de otra manera, cada tabla slo puede almacenar informacin de una nica entidad. Una vez alcanzado el nivel de la Segunda Forma Normal (es requisito que para que una tabla este en segunda forma normal, primero debe estar en primera forma normal), se controlan la mayora de los problemas de lgica. Podemos insertar un registro sin un exceso de datos en la mayora de las tablas. Tercera Forma Normal Una tabla est normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave. Cuando las tablas estn en la Tercera Forma Normal (es requisito que para que una tabla este en tercera forma normal, primero debe estar en segunda forma normal), se previenen errores de lgica cuando se insertan o borran registros. Cada columna en una tabla est identificada de manera nica por la llave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y expandir. Un dato sin normalizar no cumple con ninguna regla de normalizacin. Para explicar con un ejemplo en que consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla. ID_ORDEN 2301 2301 2301 2302 2303 2303 FECHA 2/23/03 2/23/03 2/23/03 2/25/03 2/27/03 2/27/03 ID_CLIE 101 101 101 107 110 110 NOM_CLIE MARTI MARTI MARTI HERMAN WE-SPORTS WE-SPORTS ESTADO CA CA CA WI MI MI NUM_ITEM 3786 4011 9132 5794 4011 3141 DESC_ITEM RED RAQUETA PAQ-3 PAQ-6 RAQUETA FUNDA CANT 3 6 8 4 2 2 PRECIO 35 65 4.75 5 65 10

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohbe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son: Tenemos que eliminar los grupos repetidos.

 Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido. Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y ARTICULOS_ORDENES ORDENES ID_ORDEN 2301 2302 2303 FECHA 2/23/03 2/25/03 2/27/03 ID_CLIE 101 107 110 NOM_CLIE MARTI HERMAN WE-SPORTS CANT 3 6 8 4 2 2 ESTADO CA WI MI

ARTICULOS_ORDENES ID_ORDEN NUM_ITEM DESC_ITEM 2301 3786 RED 2301 4011 RAQUETA 2301 9132 PAQ-3 2302 5794 PAQ-6 2303 4011 RAQUETA 2303 3141 FUNDA

PRECIO 35 65 4.75 5 65 10

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son: Determinar cules columnas que no son llave no dependen de la llave primaria de la tabla. Eliminar esas columnas de la tabla base. Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen. La tabla ORDENES est en 2FN. Cualquier valor nico de ID_ORDEN determina un slo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN. Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que haremos a continuacin es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen. Las tablas quedan ahora de la siguiente manera: ARTICULOS_ORDENES ID_ORDEN NUM_ITEM CANT 2301 3786 3 2301 4011 6 2301 9132 8 2302 5794 4 2303 4011 2 2303 3141 2 ARTICULOS NUM_ITEM DESC_ITEM 3786 RED 4011 RAQUETA 9132 PAQ-3 5794 PAQ-6 3141 FUNDA PRECIO 35 65 4.75 5 10

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra columna no llave. Los pasos a seguir son:

 Determinar las columnas que son dependientes de otra columna no llave. Eliminar esas columnas de la tabla base. Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes. Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo est, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria. Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se muestran a continuacin. ORDENES ID_ORDEN 2301 2302 2303 FECHA 2/23/03 2/25/03 2/27/03 ID_CLIE 101 107 110 ESTADO CA WI MI

CLIENTES ID_CLIE NOM_CLIE 101 MARTI 107 HERMAN 110 WE-SPORTS

DESNORMALIZACION
Qu tan lejos debe llevar la normalizacin? La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es una ciencia subjetiva. Determinar las necesidades de simplificacin depende de nosotros. Si nuestra base de datos va a proveer informacin a un solo usuario para un propsito simple y existen pocas posibilidades de expansin, normalizar los datos hasta la 3FN es ms que suficiente. Las reglas de normalizacin existen como guas para crear tablas que sean fciles de manejar, as como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel ms alto no tenga sentido. Se estn dividiendo tablas slo para seguir las reglas o estas divisiones son en verdad prcticas? stas son el tipo de cosas que nosotros como diseadores de la base de datos, necesitamos decidir, y la experiencia y el sentido comn nos pueden auxiliar para tomar la decisin correcta. La normalizacin no es una ciencia exacta, ms bien subjetiva. Es una tcnica que se utiliza para crear relaciones lgicas apropiadas entre tablas de una base de datos. Ayuda a prevenir errores lgicos en la manipulacin de datos. La normalizacin facilita tambin agregar nuevas columnas sin romper el esquema actual ni las relaciones. Las primeras tres formas proveen suficiente nivel de normalizacin para cumplir con las necesidades de la mayora de las bases de datos. Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de sentido comn y prctico puede ayudarnos a decidir hasta donde normalizar, pero debemos recordar que las 3 primeras formas normales son absolutamente necesarias.

CREACION DE TABLAS
Ya sabemos que una base de datos relacional est formada por uno o varios bloques de contenido llamados tablas que constituyen conjuntos conexos de informacin del mismo tipo. Las tablas son objetos de la base de datos que contienen todos sus datos. Una tabla se define mediante una

coleccin de columnas (campos). En las tablas, los datos se organizan con arreglo a un formato de filas y columnas, similar al de una hoja de clculo. Cada fila representa un registro nico, y cada columna representa un campo dentro de un registro. Cuando se disea una base de datos, es necesario decidir qu tablas se necesitan, qu tipo de datos van destinados a cada tabla, quin puede tener acceso a cada tabla, etc. El mtodo ms eficaz para crear una tabla consiste en definir todo lo que se necesita en la tabla al mismo tiempo, incluidas las restricciones para los datos y los componentes adicionales. No obstante, tambin se puede crear una tabla bsica, agregar algunos datos y trabajar con la tabla durante algn tiempo. As, se tendr ocasin de ver cules son los tipos de transacciones ms habituales y qu tipos de datos se utilizan con ms frecuencia antes de confirmar un diseo ms estable que incluya restricciones, ndices, valores predeterminados, reglas y otros objetos. Al disear una tabla, es fundamental tener en cuenta los tipos de datos que debe contener la tabla, qu columnas deben formar la tabla y los tipos de datos para cada columna (as como su longitud, si es preciso). Tambin es necesario tener presente qu columnas aceptan valores NULL y si deben utilizarse, y cundo, restricciones o valores predeterminados y reglas. Tambin es esencial tener en cuenta los tipos de ndices requeridos y qu columnas son claves principales y claves externas. Los tipos de datos definen los valores de datos permitidos para cada columna.

DBMS Data Base Management System

SGBD - Sistema de Gestin de Base de Datos. Definicin
El sistema de administracin de la base de datos es el conjunto de programas que maneja todo acceso a la base de datos. Las funciones del DBMS incluyen: Definicin de Datos: Debe ser capaz de aceptar definiciones de datos en versin fuente y convertirlas a la versin objeto apropiada. Es decir, el DBMS debe incluir componentes procesadores de lenguajes para cada uno de los diversos lenguajes de definicin de datos DDL. Manipulacin de Datos: El DBMS debe ser capaz de atender las solicitudes del usuario para extraer, y quiz poner al da, datos que ya existen en la base de datos o para agregar a ella datos nuevos. Dicho de otro modo, el DBMS debe incluir un componente procesador de lenguaje de manipulacin de datos (DML). En general, las solicitudes del DML pueden ser planeadas o no planeadas. Una solicitud planeada es aquella cuya necesidad se previ mucho tiempo antes de que tuviera que ejecutarse por primera vez. Una solicitud no planeada es la que surgi de improviso y para la cual el diseo de la base de datos no estaba preparado. Seguridad e integridad de los datos: El DBMS debe supervisar las solicitudes de los usuarios y rechazar los intentos de violar las medidas de seguridad e integridad definidas por el DBA Recuperacin y concurrencia de datos: El DBMS debe cuidar del cumplimiento de ciertos controles de recuperacin y concurrencia. Diccionario de datos: El DBMS debe incluir una funcin de diccionario de datos. El contenido del diccionario puede considerarse como Datos acerca de los datos (los cuales a veces reciben el nombre de metadatos), es decir, definiciones de otros objetos del sistema y no solo datos en bruto. En el diccionario se almacenan todos los esquemas y correspondencias tanto en sus versiones fuente como objeto. Tambin incluye referencias cruzadas para indicar, por ejemplo, cuales programas usan que partes de la base de datos, cuales usuarios requieren que informes, etc. Desempeo: Por ltimo, el DBMS deber ejecutar todas las funciones recin identificadas en la forma ms eficiente posible.

MySQL Data Base Management System

MySQL es un SGBD que ha ganado popularidad por una serie de atractivas caractersticas: Est desarrollado en C/C++. Se distribuyen ejecutables para cerca de diecinueve plataformas diferentes. La API se encuentra disponible en C, C++, Eiffel , Java, Perl, PHP, Python, Ruby y TCL. Est optimizado para equipos de mltiples procesadores. Es muy destacable su velocidad de respuesta. Se puede utilizar como cliente-servidor o incrustado en aplicaciones. Cuenta con un rico conjunto de tipos de datos. Soporta mltiples mtodos de almacenamiento de las tablas, con prestaciones y rendimiento diferentes para poder optimizar el SGBD a cada caso concreto. Su administracin se basa en usuarios y privilegios. Se tiene constancia de casos en los que maneja cincuenta millones de registros, sesenta mil tablas y cinco millones de columnas. Sus opciones de conectividad abarcan TCP/IP, sockets UNIX y sockets NT, adems de soportar completamente ODBC. Los mensajes de error pueden estar en espaol y hacer ordenaciones correctas con palabras acentuadas o con la letra . Es altamente confiable en cuanto a estabilidad se refiere. Para todos aquellos que son adeptos a la filosofa de UNIX y del lenguaje C/C++, el uso de MySQL les ser muy familiar, ya que su diseo y sus interfaces son acordes a esa filosofa: crear herramientas que hagan una sola cosa y que la hagan bien. MySQL tiene como principal objetivo ser una base de datos fiable y eficiente. Ninguna caracterstica es implementada en MySQL si antes no se tiene la certeza que funcionar con la mejor velocidad de respuesta y, por supuesto, sin causar problemas de estabilidad. La influencia de C/C++ y UNIX se puede observar de igual manera en su sintaxis. Por ejemplo, la utilizacin de expresiones regulares, la diferenciacin de funciones por los parntesis, los valores lgicos como 0 y 1, la utilizacin del tabulador para completar sentencias, por mencionar algunos. ACCESO A UN SERVIDOR MYSQL Para conectarse con el servidor deberemos asegurarnos de que ste est funcionando y de que admite conexiones, sean stas locales (el SGBD se est ejecutando en la misma mquina que intenta la conexin) o remotas. Adicionalmente, deberemos disponer de las credenciales necesarias para la conexin. Distintos tipos de credenciales nos permitirn distintos niveles de acceso. Para simplificar, supondremos que disponemos de las credenciales (usuario y contrasea) del administrador de la base de datos (normalmente, usuario root y su contrasea). En el apartado que concierne a la administracin de MySQL, se comenta detalladamente los aspectos relacionados con el sistema de usuarios, contraseas y privilegios del SGBD.

El cliente de MySQL en modo interactivo nos permite tanto la introduccin de sentencias SQL para trabajar con la base de datos (crear tablas, hacer consultas y ver sus resultados, etc.) como la ejecucin de comandos propios del SGBD para obtener informacin sobre las tablas, ndices, etc. o ejecutar operaciones de administracin.

TIPOS DE DATOS Los tipos de datos que puede haber en un campo, se pueden agrupar en tres grandes grupos: 1. Tipos numricos 2. Tipos de Fecha 3. Tipos de Cadena

1 Tipos numricos: Existen tipos de datos numricos, que se pueden dividir en dos grandes grupos, los que estn en coma flotante (con decimales) y los que no. TinyInt: es un nmero entero con o sin signo. Con signo el rango de valores vlidos va desde -128 a 127. Sin signo, el rango de valores es de 0 a 255 Bit Bool: un nmero entero que puede ser 0 1 SmallInt: nmero entero con o sin signo. Con signo el rango de valores va desde -32768 a 32767. Sin signo, el rango de valores es de 0 a 65535. MediumInt: nmero entero con o sin signo. Con signo el rango de valores va desde -8.388.608 a 8.388.607. Sin signo el rango va desde 0 a16777215. Integer, Int: nmero entero con o sin signo. Con signo el rango de valores va desde -2147483648 a 2147483647. Sin signo el rango va desde 0 a 429.4967.295 BigInt: nmero entero con o sin signo. Con signo el rango de valores va desde 9.223.372.036.854.775.808 a 9.223.372.036.854.775.807. Sin signo el rango va desde 0 a 18.446.744.073.709.551.615. Float: nmero pequeo en coma flotante de precisin simple. Los valores vlidos van desde 3.402823466E+38 a -1.175494351E-38, 0 y desde 1.175494351E-38 a 3.402823466E+38. xReal, Double: nmero en coma flotante de precisin doble. Los valores permitidos van desde 1.7976931348623157E+308 a -2.2250738585072014E-308, 0 y desde 2.2250738585072014E-308 a 1.7976931348623157E+308 Decimal, Dec, Numeric: Nmero en coma flotante desempaquetado. El nmero se almacena como una cadena Tipo de Campo TINYINT SMALLINT MEDIUMINT INT INTEGER Tamao de Almacenamiento 1 byte 2 bytes 3 bytes 4 bytes 4 bytes

BIGINT FLOAT(X) FLOAT DOUBLE DOUBLE PRECISION REAL DECIMAL(M,D

8 bytes 4 8 bytes 4 bytes 8 bytes 8 bytes 8 bytes M+2 bytes s D > 0, M+1 bytes s D = 0 M+2 bytes if D > 0, M+1 bytes if D = 0

NUMERIC(M,D)

2 Tipos fecha: A la hora de almacenar fechas, hay que tener en cuenta que Mysql no comprueba de una manera estricta si una fecha es vlida o no. Simplemente comprueba que el mes esta comprendido entre 0 y 12 y que el da est comprendido entre 0 y 31. Date: tipo fecha, almacena una fecha. El rango de valores va desde el 1 de enero del 1001 al 31 de diciembre de 9999. El formato de almacenamiento es de ao-mes-dia DateTime: Combinacin de fecha y hora. El rango de valores va desde el 1 de enero del 1001 a las 0 horas, 0 minutos y 0 segundos al 31 de diciembre del 9999 a las 23 horas, 59 minutos y 59 segundos. El formato de almacenamiento es de ao-mes-dia horas:minutos:segundos TimeStamp: Combinacin de fecha y hora. El rango va desde el 1 de enero de 1970 al ao 2037. El formato de almacenamiento depende del tamao del campo: Tamao 14 Formato AoMesDiaHoraMinutoSegundo aaaammddhhmmss AoMesDiaHoraMinutoSegundo aammddhhmmss oMesDia aaaammdd AoMesDia aammdd AoMes aamm Ao aa

12 8 6 4 2

Time: almacena una hora. El rango de horas va desde -838 horas, 59 minutos y 59 segundos a 838, 59 minutos y 59 segundos. El formato de almacenamiento es de 'HH:MM:SS' Year: almacena un ao. El rango de valores permitidos va desde el ao 1901 al ao 2155. El campo puede tener tamao dos o tamao 4 dependiendo de si queremos almacenar el ao con dos o cuatro dgitos. Tipo de Campo DATE DATETIME TIMESTAMP TIME YEAR Tamao de Almacenamiento 3 bytes 8 bytes 4 bytes 3 bytes 1 byte

3 Tipos de cadena: Char(n): almacena una cadena de longitud fija. La cadena podr contener desde 0 a 255 caracteres. VarChar(n): almacena una cadena de longitud variable. La cadena podr contener desde 0 a 255 caracteres. Dentro de los tipos de cadena se pueden distinguir otros dos subtipos, los tipo Test y los tipo BLOB (Binary large Object) La diferencia entre un tipo y otro es el tratamiento que reciben a la hora de realizar ordenamientos y comparaciones. Mientras que el tipo test se ordena sin tener en cuenta las Maysculas y las minsculas, el tipo BLOB se ordena tenindolas en cuenta. Los tipos BLOB se utilizan para almacenar datos binarios como pueden ser ficheros. TinyText y TinyBlob: Columna con una longitud mxima de 255 caracteres. Blob y Text: un texto con un mximo de 65535 caracteres. MediumBlob y MediumText: un texto con un mximo de 16.777.215 caracteres. LongBlob y LongText: un texto con un mximo de caracteres 4.294.967.295. Hay que tener en cuenta que debido a los protocolos de comunicacin los paquetes pueden tener un mximo de 16 Mb. Enum: campo que puede tener un nico valor de una lista que se especifica. El tipo Enum acepta hasta 65535 valores distintos

Set: un campo que puede contener ninguno, uno varios valores de una lista. La lista puede tener un mximo de 64 valores. Tipo de campo CHAR(n) VARCHAR(n) TINYBLOB, TINYTEXT BLOB, TEXT MEDIUMBLOB, MEDIUMTEXT LONGBLOB, LONGTEXT ENUM('value1','value2',...) Tamao de Almacenamiento n bytes n +1 bytes Longitud+1 bytes Longitud +2 bytes Longitud +3 bytes Longitud +4 bytes 1 dos bytes dependiendo del nmero de valores 1, 2, 3, 4 8 bytes, dependiendo del nmero de valores

SET('value1','value2',...)

Diferencia de almacenamiento entre los tipos Char y VarChar Valor '' 'ab' 'abcd' 'abcdefgh' CHAR(4) '' 'ab ' 'abcd' 'abcd' Almace Almace VARCHAR(4) namiento namiento 4 bytes 4 bytes 4 bytes 4 bytes " 'ab' 'abcd' 'abcd' 5 bytes 1 byte 3 bytes

FIN PARTE 1