DISEO DE BASES DE DATOS RELACIONALES: PRINCIPIOS BSICOS DE DISEO El modelo relacional

Todos los datos se representan en tablas. o Incluso los resultados de cualquier consulta son otra tabla. Las tablas estn compuestas por filas y columnas. Las filas y las columnas, en principio, carecen de orden (p.ej., el orden en el que se muestren las filas y las columnas no importa). o Las filas slo se ordenan si se le indica a la base de datos que lo haga, mediante el correspondiente comando. De no ser as, el orden ser arbitrario, y puede cambiar en caso de tratarse de una base datos dinmica. o El orden de las columnas lo determina cada consulta. Cada tabla tiene una clave primaria, un identificador nico, compuesto por una o ms columnas. La mayora de las claves primarias estn formadas por una nica columna (p.ej.,CIUDAD_ID). Para establecer una relacin entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria. Estos dos conceptos --clave primaria y secundaria-- son los ms importantes en el diseo de bases de datos. Es importante dedicarles tiempo, para entender bien en qu consisten y cmo funcionan.

Cualidades de un buen diseo de base de datos

Reflejar la estructura del problema en el mundo real. Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo. Evitar el almacenamiento de informacin redundante. Proporcinar un acceso eficaz a los datos. Mantener la integridad de los datos a lo largo del tiempo. Ser claro, coherente y de fcil comprensin.

Nota: A veces, estos objetivos pueden ser contradictorios.

Introduccin al modelo Entidad/Interrelacin (E/R)

El modelo Entidad/Interrelacin (E/R): un mtodo de diseo de bases de datos. Muestra de una versin simplificada. Representa los datos mediante una serie de entidades que disponen de atributos. Una entidad es una clase de objetos o conceptos claramente identificable. Las entidades establecen interrelaciones con otras entidades. El resultado de este proceso es una base de datos normalizada que facilita el acceso a los datos y evita su duplicado. Nota: en su mayor parte, el diseo formal de una base de datos se centra en la normalizacin de la base y en asegurar que el diseo se ajuste a un nivel de normalizacin (p.ej., first normal form, second normal form, etc.). Este nivel de formalidad va mucho ms all, pero es importante saber que existen tales formalidades.

Proceso de diseo en el modelo E-R

Identificar las entidades que debe presentar la base de datos. Determinar las cardinalidades de las interrelaciones establecidas entre las distintas entidades y clasificar estas interrelaciones entre los siguientes tipos: o Uno a uno (p.ej., una parcela slo tiene una direccin). o Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios). o Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender varios propietarios y cada propietario puede vender varias parcelas). Dibujar el diagrama Entidad/Interrelacin. Determinar los atributos de cada entidad. Definir la clave primaria (nica) de cada entidad.

Problemas al trabajar con bases de datos y ArcView

ArcView slo permite establecer relaciones a travs de una columna: o Esto obliga a los usuarios a recurrir a una serie de procedimientos elaborados para construir una clave de una sola columna. ArcView no puede trabajar con expresiones "al vuelo": o Los porcentajes y las proporciones se deben almacenar en columnas extra. o Estos valores pueden quedar desfasados y su creacin requiere un gran trabajo extra. ArcView no funciona demasiado bien con relaciones muchos a muchos. o Una relacin uno a muchos produce un valor arbitrario en la tabla relacionada. o Un "enlace" o vnculo, ms que una relacin, proporciona alguna capacidad muchos a uno, aunque bastante limitada. Las herramientas de agregado y "agrupamiento" disponibles son tambin limitadas. Por ejemplo, "Campo | Estadsticas y campo | Resumir" (Field | Statistics and Field | Summarize). Las herramientas para trabajar con sistemas de gestin de bases de datos externos (p.ej., Oracle) son bastante lentas y difciles de usar.

Paso del modelo E/R al diseo de la base de datos

Las entidades entre las que hay una interrelacin uno a uno se deben fusionar en una sola entidad. Una vez hecho esto, cada una de las entidades que quedan se convierte en una tabla con una clave primaria y una serie de atributos, de los cuales algunos pueden ser claves secundarias. Las interrelaciones uno a muchos se transforman en atributo y clave secundaria de la tabla que representa a la entidad situada del lado de la interrelacin correspondiente a muchos . Las interrelaciones muchos a muchos entre dos entidades pasan a ser una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias debern formar parte de la clave primaria de la tabla en la que se convierte la interrelacin, cuando corresponda. Hay una serie de herramientas disponibles en el mercado que pueden automatizar el proceso de conversin de un modelo E/R en un esquema de base de datos.

http://mit.ocw.universia.net/curso11208/11/11.208/IAP02/lecture-notes/lecture52.html Base de datos relacionales En una computadora existen diferentes formas de almacenar informacin. Esto da lugar a distintos modelos de organizacin de la base de datos: jerrquico, red, relacional y orientada a objeto. Los sistemas relacionales son importantes porque ofrecen muchos tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario final, perodos cortos de aprendizaje y las consultas de informacin se especifican de forma sencilla. Las tablas son un medio de representar la informacin de una forma ms compacta y es posible acceder a la informacin contenida en dos o ms tablas. Ms adelante explicaremos que son las tablas. Las bases de datos relacionales estn constituidas por una o ms tablas que contienen la informacin ordenada de una forma organizada. Cumplen las siguientes leyes bsicas:

Generalmente, contendrn muchas tablas. Una tabla slo contiene un nmero fijo de campos. El nombre de los campos de una tabla es distinto. Cada registro de la tabla es nico. El orden de los registros y de los campos no est determinados. Para cada campo existe un conjunto de valores posible.

Diseo de las bases de datos relacionales El primer paso para crear una base de datos, es planificar el tipo de informacin que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la informacin disponible y la informacin que necesitamos. La planificacin de la estructura de la base de datos, en particular de las tablas, es vital para la gestin efectiva de la misma. El diseo de la estructura de una tabla consiste en una descripcin de cada uno de los campos que componen el registro y los valores o datos que contendr cada uno de esos campos.

Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definicin de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc. Los registros constituyen la informacin que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la direccin de este. Generalmente los diferente tispos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numrico (nmeros), Fecha / Hora, Lgico (informaciones lgicas si/no, verdadero/falso, etc., imgenes. En resumen, el principal aspecto a tener en cuenta durante el diseo de una tabla es determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud. Bases de datos orientadas a objetos (BDOO) Qu es O.O.? En esos mundos OO, el conocimiento se descentraliza en todos los objetos que lo componen, cada objeto sabe hacer lo suyo y no le interesa saber cmo el vecino hace su trabajo, pero sabe que lo hace y qu es lo que puede hacer. Como bien lo defini Dan Ingalls de Smalltalk con las siguientes palabras: "La orientacin a objetos proporciona una solucin que conduce a un Universo de Objetos 'bien educados' que se piden de manera corts, concederse mutuamente sus deseos". Por qu O.O.? La meta es dejar la etapa en la que la construccin del software es una labor de artesanos, y pasar a la etapa en la que se pueda tener fbricas de software, con gran capacidad de reutilizacin de cdigo y con metodologa eficientes y efectivas que se apliquen al proceso de produccin. Qu es una BDOO? A finales de los 80's aparecieron las primeras BDOO, es una base de datos inteligente. Soporta el paradigma orientado a objetos almacenando datos y mtodos, y no slo datos. Est diseada para ser eficaz, desde el punto de vista fsico, para almacenar objetos complejos. Evita el acceso a los datos; esto es mediante los mtodos almacenados en ella. Es ms segura ya que no permite tener acceso a los datos (objetos); esto debido a que para poder entrar se tiene que hacer por los mtodos que haya utilizado el programador. Un Modelo Conceptual Unificado

Las tcnicas OO utilizan los mismos modelos conceptuales para el anlisis, diseo y construccin. La tecnologa de las BDOO da un paso ms hacia la unificacin, el modelo conceptual de la base de datos OO es igual al del resto del mundo OO, en lugar de utilizar tablas por relacin independientes como SQL. El uso del mismo modelo conceptual para todos los aspectos del desarrollo simplifica ste, particularmente con las herramientas CASE OO; mejora la comunicacin entre usuarios, analistas y programadores, adems de que reduce las posibilidades de error. Para ver las figuras faltantes haga click en el men superior "Bajar Trabajo" (Figura No.2) El desarrollo tradicional tiene cuatro modelos conceptuales Arquitectura de Una BDOO En la siguiente (TablaNo1) se muestran algunos de los principales productos de BDOO y sus vendedores. Los primeros se disearon como una extensin de los lenguajes de programacin como Smalltalk C++. El LMD ( lenguaje para el manipulacin de datos; tambin conocido como DML) y el LDD (lenguaje para la definicin de los datos; tambin conocido como DDL) construan un lenguaje OO comn. El diseo de las BDOO actuales debe aprovechar al mximo l CASE e incorporar mtodos creados con cualquier tcnica poderosa, incluyendo enunciados declarativos, generadores de cdigos e inferencias con base en reglas. Para ver la tabla faltante haga click en el men superior "Bajar Trabajo" (Tabla No.1) (Figura No.3) Seis Productos de BDOO y sus Proveedores. Algunas caractersticas son independientes de la arquitectura fundamental de una BDOO pero son comunes a la mayora de ellas: * Versiones.- La mayora de los sistemas de bases de datos slo permiten que exista una representacin de un ente de la base de datos dentro de esta. Las versiones permiten que las representaciones alternas existan en forma simultnea. * Transacciones compartidas.- Las transacciones compartidas soportan grupos de usuarios en estaciones de trabajo, los cuales desean coordinar sus esfuerzos en tiempo real, los usuarios pueden compartir los resultados intermedios de una base

de datos. La transaccin compartida permite que varias personas intervengan en una sola transaccin Desarrollo con Bases de Datos OO Las BDOO se desarrollan al describir en primer lugar los tipos de objetos importantes del dominio de aquellos tipos de objetos. Estos tipos de objetos determinan las clases que conformarn la definicin de la BDOO. Por ejemplo: Una base de datos diseada para almacenar la geometra de ciertas partes mecnicas incluira clases como CILINDRO, ESFERA Y CUBO. El comportamiento de CILINDRO podra incluir informacin relativa a sus dimensiones, volumen rea superficial: Clase de CILINDRO{ ALTURA FLOTANTE (); RADIO FLOTANTE (); VOLUMEN FLOTANTE (); AREA DE SUPERFICIE FLOTANTE (); Se puede llegar a definiciones similares para el cubo y la esfera. En la definicin anterior, ALTURA,RADIO y REA representan los mensajes que se pueden enviar a un objeto CILINDRO . La Implantacin se lleva a cabo en el mismo lenguaje, escribiendo funciones correspondientes a las solicitudes OO: CILINDRO::ALTURA () {RETORNA CILINDRO_ALTURA;} CILINDRO::VOLUMEN () {RETORNA PI*RADIO ()*ALTURA ();} En este caso, la Altura se almacena como un elemento de los datos, mientras que volume se calcula mediante la frmula apropiada. Observe que la implantacin interna de volume utiliza solicitudes para obtener altura y radio. Sin embargo, el aspecto ms importante es la sencillez y uniformidad que experimentan los usuarios de CILINDRO. Slo necesitan conocer la forma de enviar una solicitud y las solicitudes disponibles. Tres Enfoques de Construccin de Bases de Datos OO Las BDOO se pueden construir mediante alguno de los tres enfoques siguientes:

El Primero.- se puede utilizar el cdigo actual altamente complejo de los sistemas de administracin de las bases de datos, de modo que una BDOO se implante ms rpido sin tener que iniciar de cero. Las tcnicas orientadas a objetos se pueden utilizar como medios para el diseo sencillo de sistemas complejos. Los sistemas se construyen a partir de componentes ya probados con un formato definido para las solicitudes de las operaciones del componente. * El Segundo: considera a la BDOO como una extensin de la tecnologa de las bases de datos por relacin. De este modo, las herramientas, tcnicas, y vasta experiencia de la tecnologa por relacin se utilizan para construir un nuevo SABD. Se pueden aadir apuntadores a las tablas de relacin para ligarlas con objetos binarios de gran tamao (BLOB). La base de datos tambin debe proporcionar a las aplicaciones clientes un acceso aleatorio y por partes a grandes objetos, con el fin de que slo sea necesario recuperar a travs de la red la parte solicitada de los datos. * El Tercero: reflexiona sobre la arquitectura de los sistemas de bases de datos y produce una nueva arquitectura optimizada, que cumple las necesidades de la tecnologa OO. Las compaas como Versant, Objectivity, Itasca, etc. Utilizan est enfoque y afirman que la tecnologa de relacin es un subconjunto de una capacidad ms general. Adems que las BDOO no de relacin son aproximadamente dos veces ms rpidas que las bases de datos por relacin para almacenar y recuperar la informacin compleja. Por lo tanto, son esenciales en aplicaciones como CAD y permitiran que un depsito CASE fuera una facilidad de tiempo real en vez de una facilidad por lotes. La Arquitectura de Versant est designada al soporte Cliente/Servidor con acercamiento a la computacin distribuida; cualquier aplicacin de Cliente el servidor la procesa, usa las EDT y las mquinas servidoras que pueden cooperar en una BD distribuida de Versant. Las BD pueden estar levantadas como un sistema m-Cliente/n-Servidor. Un servidor en el medioambiente de Versant es una mquina que est corriendo los procesos del servidor, esta soporta accesos concurrentes por usuarios mltiples de una o ms BD. Un cliente es un proceso de aplicacin este tiene acceso a espacios de trabajo de BD persistentes privadas y en adicin puede accesar diversas BD sobre servidores concurrentes con otras aplicaciones de cliente. Fig. No. 4 Arquitectura de Versant Para ver las figuras faltantes haga click en el men superior "Bajar Trabajo"

Impacto de la Orientacin a Objetos en la Ingeniera del Software. En las BDOO, la organizacin "Gestin Manejadora de Datos Objeto (ODMG)" representa el 100% de las BDOO industriales y ha establecido un estndar de definicin (ODL - Lenguaje de Definicin de datos) y manipulacin (OQL Lenguaje de consulta) de bases de datos equivalente a SQL. Respecto a las relacionales, todas (Oracle, Informix, etc.) estn aadiendo en mayor o menor grado algunos aspectos de la orientacin a objetos. ANSI(Instituto Nacional Estadounidense de Estndar), por su parte, est definiendo un SQL-3 que incorpora muchos aspectos de la orientacin a objetos. El futuro del SQL-3 es sin embargo incierto, ya que ODMG ha ofrecido a ANSI su estndar para que sirva de base para un nuevo SQL, con lo que solo habra un nico estndar de base de datos. El grupo ODMG (Grupo Manejador de Datos Objeto) naci de un grupo ms grande, llamado "Grupo Manejador de Objetos (OMG)", donde estn representados todas las cosas con alguna influencia en el sector. Este grupo esta definiendo un estndar universal por objetos. Este estndar permitir que un objeto sea programado en cualquier lenguaje y sistema operativo. Esto facilitar enormemente el desarrollo de sistemas abiertos cliente-servidor. Ventajas en BDOOs Est su flexibilidad, y soporte para el manejo de tipos de datos complejos. Por ejemplo, en una base de datos convencional, si una empresa adquiere varios clientes por referencia de clientes servicio, pero la base de datos existente, que mantiene la informacin de clientes y sus compras, no tiene un campo para registrar quin proporcion la referencia, de qu manera fue dicho contacto, o si debe compensarse con una comisin, sera necesario reestructurar la base de datos para aadir este tipo de modificaciones. Por el contrario, en una BDOO, el usuario puede aadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia. La subclase heredar todos los atributos, caractersticas de la definicin original, adems se especializar en especificar los nuevos campos que se requieren as como los mtodos para manipular solamente estos campos. Naturalmente se generan los espacios para almacenar la informacin adicional de los nuevos campos. Esto presenta la ventaja adicional que una BDOO puede ajustarse a usar siempre el espacio de los campos que son necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan. La segunda ventaja de una BDOO, es que manipula datos complejos en forma rpida y gilmente. La estructura de la base de datos est dada por referencias (o apuntadores lgicos) entre objetos.

Posibles Desventajas Al considerar la adopcin de la tecnologa orientada a objetos, la inmadurez del mercado de BDOO constituye una posible fuente de problemas por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar su producto en una lnea de produccin sustantiva. Por eso, en este artculo se propone que se explore esta tecnologa en un proyecto piloto. El segundo problema es la falta de estndares en la industria orientada a objetos. Sin embargo, el "Grupo Manejador de Objetos" (OMG), es una organizacin Internacional de proveedores de sistemas de informacin y usuarios dedicada a promover estndares para el desarrollo de aplicaciones y sistemas orientados a objetos en ambientes de cmputo en red. La implantacin de una nueva tecnologa requiere que los usuarios iniciales acepten cierto riesgo. Aquellos que esperan resultados a corto plazo y con un costo reducido quedarn desilusionados. Sin embargo, para aquellos usuarios que planean a un futuro intermedio con una visin tecnolgica avanzada, el uso de tecnologa avanzada, el uso de tecnologa orientada a objetos, paulatinamente compensar todos los riesgos. Rendimiento Las BDOO permiten que los objetos hagan referencia directamente a otro mediante apuntadores suaves. Esto hace que las BDOO pasen ms rpido del objeto A al objeto B que las BDR, las cuales deben utilizar comandos JOIN para lograr esto. Incluso el JOIN optimizado es ms lento que un recorrido de los objetos. As, incluso sin alguna afinacin especial, una BDOO es en general ms rpida en esta mecnica de caza-apuntadores. * Las BDOO hacen que el agrupamiento sea ms eficiente. La mayora de los sistemas de bases de datos permiten que el operador coloque cerca las estructuras relacionadas entre s, en el espacio de almacenamiento en disco. Esto reduce en forma radical el tiempo de recuperacin de los datos relacionados, puesto que todos los datos se leen con una lectura de disco en vez de varias. Sin embargo, en una BDR, los objetos de la implantacin se traducen en representaciones tabulares que generalmente se dispersan en varias tablas. As, en una BDR, estos renglones relacionados deben quedar agrupados, de modo que todo el objeto se pueda recuperar mediante una nica lectura del disco. Esto es automtico en una BDOO. Adems, el agrupamiento de los datos relacionados, como todas las subpartes de un ensamble, puede afectar radicalmente el rendimiento general de una aplicacin. Esto es relativamente directo en una BDOO, puesto que representa el primer nivel de agrupamiento. Por el contrario, el agrupamiento fsico es imposible en una BDR, puesto que esto requiere un segundo nivel de agrupamiento: un nivel para agrupar las hileras que representan a los objetos individuales y un segundo para los grupos de hileras que representan a los objetos relacionados.

Caractersticas mandatorias reglas de oro Un sistema de BDOO debe satisfacer dos criterios: * Debe tener un BDMS * Debe ser un sistema OO Por ejemplo: para la extensin posible este debe ser consistente en los actuales cortes de lenguajes de programacin OO El primer criterio se traduce en 5 caractersticas como son: Persistencia, Manejador de almacenamiento secundario, Concurrencia, Recuperacin, y Facilidad de Query, La Segunda se traduce en 8 caractersticas: Objetos Complejos, Identidad del objeto, Encapsulacin, Tipos Clases, Sobre paso con combinacin retrasada, Extensibilidad y Completacin Computacional. Manifiesto de sistema de gestin de BDOO Esta publicacin intenta definir un sistema de BDOO y describe las principales caractersticas. Hemos separado estas caractersticas en 3 grupos: * Mandatorias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de BDOO y estos son: Objetos complejos, Identidad de objetos, Encapsulacin, Tipos Clases, Sobre paso combinado con unin retardada, Extensibilidad, Completacin Computacional, Persistencia y Manejador de almacenamiento secundario, Concurrencia, Recuperacin y Facilidad de Query. * Opcional.- Son las que pueden ser aadidas para hacer el sistema mejor pero que no son Mandatorias estas son de: herencia mltiple, chequeo de tipos e inferencia distribucin y diseo de transacciones y versiones. * Abiertas.- Son los puntos donde el diseador puede hacer un nmero de opciones y estas son el paradigma de la programacin la representacin del sistema el tipo de sistema y su uniformidad. Hemos tomado una posicin no muy a la expectativa para tener una palabra final ms bien para proveer un punto de orientacin para un debate futuro.

Caractersticas obligatorias Este es un punto que no debe faltar en una BD. * Predominancia combinada con enlace retardado.- Se puede definir que sea Excel, Autocad, etc. desde la programacin. * Extensibilidad.- Proporciona los tipos de datos como: Caracter, booleano, String, etc. * Concurrencia.- Permite que varios usuarios tengan acceso a una BD al mismo tiempo. * Recuperacin.- Cuando se hace una transaccin pero no se puede realizar y se regresa al mismo estado. * Facilidad de "Consultas a Modo".- Esto es que se tienen diferentes estndares http://html.rincondelvago.com/base-de-datos-relacional.html

BASES DE DATOS RELACIONALES ste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM enSan Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados "tuplas". Pese a que sta es la teora de las bases de datos relacionales creadas por Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar. Esto es pensando en cada relacin como si fuese una tabla que est compuesta por registros (las filas de una tabla), que representaran las tuplas, y campos (las columnas de una tabla). En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar para un usuario espordico de la base de datos. La informacin puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la informacin.

El lenguaje ms habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estndar implementado por los principales motores o sistemas de gestin de bases de datos relacionales. Durante su diseo, una base de datos relacional pasa por un proceso al que se le conoce como normalizacin de una base de datos. Durante los aos 80 la aparicin de dBASE produjo una revolucin en los lenguajes de programacin y sistemas de administracin de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestin. BASES DE DATOS ORIENTADAS A OBJETOS Este modelo, bastante reciente, y propio de los modelos informticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento). Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos: Encapsulacin - Propiedad que permite ocultar la informacin al resto de los objetos, impidiendo as accesos incorrectos o conflictos.

Herencia - Propiedad a travs de la cual los objetos heredan comportamiento dentro de una jerarqua de clases.

Polimorfismo - Propiedad de una operacin mediante la cual puede ser aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definicin de la base de datos. Una operacin (llamada funcin) se especifica en dos partes. La interfaz (o signatura) de una operacin incluye el nombre de la operacin y los tipos de datos de sus argumentos (o parmetros). La implementacin (o mtodo) de la operacin se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicacin de los usuarios pueden operar sobre los datos invocando a dichas operaciones a travs de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podra denominarse independencia entre programas y operaciones.

SQL:2003, es el estndar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.

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

Base de datos orientados a objetos. Las aplicaciones de las bases de datos en reas como el diseo asistido por computadora, la ingeniera de software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones. El modelo de bases de datos orientado a objetos es una adaptacin a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y cdigo que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensin del concepto ISA del modelo Entidad - Relacin. Puesto que el valor de un dato en un objeto tambin es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto. El propsito de los sistemas de bases de datos es la gestin de grandes cantidades de informacin. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestin de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerrquicas y, ms tarde, en bases de datos relacionales. Estructura de objetos. El modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. Un objeto tiene asociado:

un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto. Un conjunto de mensajes a los que el objeto responde. Un mtodo, que es un trozo de cdigo para implementar cada mensaje. Un mtodo devuelve un valor como respuesta al mensaje.

El trmino mensaje en un contexto orientado a objetos, no implica el uso de un mensaje fsico en una red de computadoras, si no que se refiere al paso de

solicitudes entre objetos sin tener en cuenta detalles especficos de implementacin. La capacidad de modificar la definicin de un objeto sin afectar al resto del sistema est considerada como una de las mayores ventajas del modelo de programacin orientado a objetos. Jerarqua de clases. En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y tipo. Sera intil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definicin comn, aunque difieran en los valores asignados a las variables. As que bsicamente las bases de datos orientados a objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase. Por ejemplo: Retomemos la relacin alumno-cursa-materia agregndole la entidad maestro; donde los atributos considerados para cada uno son alumno: Nombre, Direccin, Telfono, Especialidad, Semestre, Grupo; Maestro: Nombre, Direccin, Telfono, Nmero econmico, Plaza, RFC; Materia: Nombre, Crditos, Clave. Los atributos de nombre, direccin y telfono se repiten en la entidad alumno y maestro, as que podemos agrupar estos elementos para formar la clase Persona con dichos campos. Quedando por separado en alumno: Especialidad, semestre, Grupo. Y en maestro: Nmero econmico, Plaza y RFC; la materia no entra en la agrupacin (Clase persona) ya que la clase especfica los datos de solo personas, as que queda como clase materia. Herencia. Las clases en un sistema orientado a objetos se representan en forma jerrquica como en el diagrama anterior, as que las propiedades o caractersticas del elemento persona las contendrn (heredaran) los elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar al utilizado en la de especializacin (la relacin ISA) del modelo E-R. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo as que una jerarqua (en forma grfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan.

Consultas orientadas a objetos: Los lenguajes de programacin orientados a objetos requieren que toda la interaccin con objetos se realiza mediante el envo de mensajes. Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la materia de Base de Datos 1, para realizar esta consulta se tendra que enviar un mensaje a cada instancia alumno As un lenguaje de consultas para un sistema de bases de datos orientado a objetos debe incluir tanto el modelo de pasar el mensaje de objeto a objeto como el modelo de pasar el mensaje de conjunto en conjunto. Complejidad de Modificacin. En base de datos orientados a objetos pueden existir los siguientes cambios:

Adicin de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la jerarqua de clase o subclase cuidando las variables o mtodos de herencia correspondientes. Eliminacin de una clase: Se requiere la realizacin de varias operaciones, se debe de cuidar los elementos que se han heredado de esa clase a otras y reestructurar la jerarqua.

En s la estructuracin de modelos orientados a objetos simplifica una estructura evitando elementos o variables repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando en modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar una reestructuracin que involucra una serie de pasos complejos. http://sistemas.itlp.edu.mx/tutoriales/basedat1/tema7.htm Base de Datos Orientado a Objetos En una base de datos orientada a objetos, la informacin se representa mediante objetos como los presentes en la programacin orientada a objetos. Cuando se integra las caractersticas de una base de datos con las de un lenguaje de programacin orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programacin en uno o ms lenguajes de programacin a los que d soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma

transparente, control de concurrencia, asociativas y otras capacidades.

recuperacin

de

datos,

consultas

Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un buen rendimiento en la manipulacin de tipos de dato complejos. Los ODBMS proporcionan los costes de desarrollo ms bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integracin transparente con el programa escrito en un lenguaje de programacin orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento. Una BD Orientada a Objetos (BDOO) es una base de datos en el sentido de la definicin inroductoria, donde los elementos de datos son objetos y las relaciones se mantienen por medio inclusn lgica. Las entidades de aplicacin estan representadas como clases. La autodescripcion se obtiene porque las clases son metaobjetos que contiene los nombres de atributos y mtodos de seal. Una BDOO contiene un mtodo sistemtico de representacin de relacin, y la interfaz uniforme de usuario es un sistema de mensajes que puede explorar los objetos y sus interconexiones. En una BDOO, las entidades de aplicacin son las clases, las instrancias de entidad son objetos creados desde las clases, y las relaciones se mantienen por medio de inclusin lgica. Un sistema de seales y mtodos para procesarlas contiene una interfaz uniforme para la base de datos.

Estructura de una BD OO

El paradigma orientado a objetos se basa en el encapsulamiento de datos y del cdigo relacionado con cada objeto en una sola unidad. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por lo tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos. En general, cada objeto esta asociado con:

Un conjunto de variables que contiene los datos del objeto; las variables corresponden con los atributos del modelo E-R. Un conjunto de mensajes a los que responde; cada mensaje puede o no tener parmetros o tener uno o varios. Un conjunto de mtodos, cada uno de los cuales es el cdigo que implementa un mensaje; el mtodo devuelve un valor como respuesta al mensaje.

Mensaje en entorno OO no implica uso de mensajes fsicos en redes informticas. Por el contrario, hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles correctos de su implementacin. Se utiliza a veces la expresin invocar un mtodo para detonar al hecho de enviar un mensaje a un objeto y la ejecucin del mtodo correspondiente.

EJEMPLOS: CLASES DE OBJETOS class empleado { / / Variables string nombre; strin direccin; date fecha de alta; int sueldo; / / Mensajes int sueldo-anual (); string obtenerNombre (); string obtenerDireccion (); int definirDireccion (string nueva-dir); int antigedad(); }; Generalmente en una base de datos hay muchos objetos similares (se entiende que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y tipo). Por tanto sera un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos se agrupan para formar

clases. Todos los objetos de una clase comparten una definicin comn, pese a que se diferencien en los valores asignados a las variables. El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R.

El ejemplo Empleado muestra las variables y los mensajes que responden a los objetos de la clase; no se muestran aqu los mtodos para el tratamiento de los mensajes.

Los

principales

conceptos

que

se

utilizan

en

las

BDOO

son:

A.

IDENTIDAD DE OBJETOS

Un sistema de BDOO provee una identidad nica a cada objeto independiente almacenado en la base de datos. Esta identidad nica suele implementarse con un identificador de objeto nico, generado por el sistema, u OID. El valor de un OID no es visible para el usuario externo, sino que el sistema lo utiliza a nivel interno para identificar cada objeto de manera nica y para crear y manejar las referencias entre objetos. La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la identidad del objeto del mundo real que se est presentando. Tambin es preferible que cada OID se utilice slo una vez; esto es aunque un objeto se elimine de la Base de datos, su OID no se deber asignar a otro objeto. Estas dos propiedades implican que el OID no debe depender del valor de ningn atributo del objeto, pues estos valores pueden cambiar. Tambin suele considerarse inapropiado basar el OID en la direccin fsica del objeto en el almacenamiento, ya que una reorganizacin de los objetos de la base de datos podra cambiar los OID. Sin embargo, algunos sistemas s usan la direccin fsica como OID para aumentar la eficiencia de la obtencin de los objetos. Si la direccin fsica cambia, puede colocarse un apuntador indirecto en la direccin

anterior, dando la nueva ubicacin fsica del objeto. Un sistema de BDOO debe contar con algn mecanismo para generar los OID con la propiedad de inmutabilidad. Algunos modelos de datos OO requieren que todo se represente como un objeto, ya sea un valor simple o un objeto complejo; as, todo valor bsico, como un entero, una cadena o un valor boleano, tiene un OID. Con ello dos valores bsicos pueden tener diferentes OID, lo cual es muy til en algunos casos. Por ejemplo, en algunas ocasiones se podra usar el valor entero 50 para representar un peso en Kilogramos, y en otras para referirse a la edad de una persona. As podran crearse dos objetos bsicos con diferentes OID, y ambos tendran el mismo valor bsico de 50. Aunque resulta til como modelo terico, esto no es muy prctico porque puede obligar a generar demasiados OID. Por ello tambin, la mayor parte de los sistemas de BDOO permiten representar tanto objetos como valores. Todo objeto debe tener un OID inmutable, pero los valores no tienen OID y se representan as mismo. Los objetos tienen identidades nicas, independientes de los valores de sus atributos. La estructura orientada a objetos automticamente impone las restricciones relacionales, generalmente ms aplicables: dominio, llave integridad de entidad e integridad referencial.

B. CONSTRUCTORES DE TIPOS En las BDOO, los valores (o estados) de los objetos complejos se pueden construir a partir de otros objetos mediante ciertos constructores de tipos. Una forma de representar tales objetos es considerar a cada objeto como tripleta (i, c, v), donde i es un identificador de objeto nico (el OID), c es un constructor (esto es, una indicacin de cmo se construye el valor del objeto) y v es el valor (o estado) del objeto. Puede haber varios constructores, segn el modelo de datos y el sistema OO. Los tres constructores bsicos son: constructores de tomos.

constructores de tuplas. constructores de conjuntos.

Otros constructores de uso ms comn son los de listas y de arreglos. Tambin existe un dominio D que contiene todos los valores atmicos bsicos que estn disponibles directamente en el sistema. Por lo regular estos incluyen los enteros, los nmeros reales, las cadenas de caracteres, los tipos bolanos, las fechas y cualesquiera otros tipos de datos que el sistema maneje directamente. C. ENCAPSULAMIENTO: Tanto la estructura de los objetos como las operaciones que se pueden aplicar a ellos se incluyen en las definiciones de clases de los objetos.

D. COMPATIBILIDAD CON LENGUAJES DE PROGRAMACION Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-Relacin para modelar los datos y luego se convierten de manera manual en un conjunto de relaciones; por lo tanto los conceptos de la Programacin Orientada a Objetos se utilizan simplemente como herramientas de diseo y se codifican, utilizndose para trabajar con una base de datos. Hay varios lenguajes posibles en los que se pueden integrar estos conceptos:

Una opcin es extender un lenguaje para el tratamiento de datos como el SQL aadiendo tipos complejos y la programacin orientada a objetos. Los sistemas proporcionan extensiones orientadas a objetos a los sistemas relacionales se denominan sistemas relacionales orientados a objetos.

Otra opcin es tomar un lenguaje de programacin orientado a objetos ya existente y extenderlo para que trabaje con las bases de datos. Estos lenguajes se denominan lenguajes de programacin persistentes. Estos lenguajes permiten a los programadores trabajar directamente con los datos, desde el lenguaje de programacin; sin tener que pasar por un

lenguaje para el tratamiento de datos como SQL. Se denominan persistentes porque los datos siguen existiendo una vez que el programa que los cre ha concluido.

A la hora de decidir que opcin utilizar se debe tener en cuenta que los Lenguajes Persistentes suelen ser potentes y resulta relativamente sencillo cometer errores de programacin que daen las vases de datos. La complejidad de los lenguajes hace la optimizacin automtica de alto nivel, como la reduccin de E/S de disco, resulte dificil. En muchas aplicaciones, la posibilidad de las consultas declarativas es de gran importancia, pero los lenguajes persistentes no permiten actualmente las consultas declarativas sin que aparezcan problemas de algun tipo.

E. JERARQUIA DE TIPOS Y HERENCIA Los esquemas de BDOO suelen necesitar un gran nmero de clases. Sin embargo, varias clases son parecidas entre s. Para permitir la representacin directa de parecidos entre las clases, hay que ubicarlas en una jerarqua de especializaciones. El concepto de jerarqua de clases es parecido al de especializacin del modelo E-R. Las especializaciones de las clases son denominadas subclases; lo cual especifica atributos y mtodos adicionales para una clase existente. Los objetos creados por medio de una sub clases heredan todos los atributos y mtodos de la clase padre. Algunas de estas caractersticas heredadas pueden ellas mismas haber sido heredadas de clases ms altas en la jerarqua. Ejemplo:

Ejemplo: (Grafico) Class persona { string nombre; strin direccin; };

Class cliente isa persona { int inters-prestamo; }; Class empleado isa persona{ date fecha de alta; int sueldo; }; Class secretaria isa empleado { int velocidad; int horas-trabajadas

F. MANEJO DE OBJETOS COMPLEJOS Los objetos se consideran complejos porque requieren un rea de almacenamiento sustancial y no forman parte de los tipos de datos estndar que suelen ofrecer los SGBD. Puesto que el tamao de los objetos es considerable, un SGBD podra obtener una porcin del objeto y proporcionarla al programa de aplicacin antes de obtener todo el objeto. El SGBD podra tambin usar tcnicas de almacenamiento intermedio y cach para obtener por anticipado porciones del objeto, antes de que el programa de aplicacin necesite tener acceso a ellas. En un SGBOO, esto puede lograrse definiendo un nuevo tipo de datos abstracto para los objetos no interpretados y suministrados los mtodos para seleccionar, comprar y exhibir tales objetos. Como un SGBOO permite a los usuarios crear nuevos tipos, y como un tipo incluye tanto estructura como operaciones, podemos considerar que un SGBOO tiene un sistema de tipos extensibles. Podemos crear bibliotecas de nuevos tipos definiendo su estructura y operaciones, incluso con tipos complejos. Muchos SGBDOO pueden almacenar y obtener objetos no estructurados extensos en forma de cadenas y caracteres o de bits, que se pueden pasar tal cual al programa de aplicacin para que las interprete. Es posible almacenar y manipular estructurados como no estructurados. objetos complejos tanto

G. POLIMORFISMO El polimorfismo se refiere al uso de la misma firma de mensaje para dirigir diferentes mtodos en diferentes clases. Cuando el diseador enva una seal a un objeto, el mtodo de la clase de objeto, posiblemente heredado, procesa la seal. Un mtodo puede tener acceso directamente a atributos de un objeto destino por no nombre, al incluir cualesquiera atributos heredados de clases padres, pero debe tener acceso a atributos de otros objetos con seales secundarias. En sntesis este concepto permite enlazar el mismo nombre o smbolo de operador a dos o ms implementaciones diferentes del operador, dependiendo del tipo de objetos a los que ste se aplique. EJEMPLO: OBJETO_GEOMETRICO: Forma, Area, PuntoCentral RECTANGULO subtype_of OBJETO_GEOMETRICO (Forma=rectngulo): Ancho, Altura TRIANGULO subtype_of OBJETO_GEOMETRICO (Forma=tringulo): Lado1, Lado2, Angulo CIRCULO subtype_of OBJETO_GEOMETRICO(Forma=crculo): Radio

H. CREACION DE VERSIONES Muchas aplicaciones de bases de datos que usan sistemas OO requieren la existencia de varias versiones del mismo objeto. Por lo regular, se aplican actividades de mantenimiento a un sistema de software conforme sus requerimientos evolucionan. Por lo regular, el mantenimiento implica modificar algunos de los mdulos de diseo y de implementacin. Si el sistema ya est en operacin, y si es preciso modificar uno o ms mdulos, el diseador deber crear una nueva versin de cada uno de ellos para efectuar cambios.

Cabe sealar que puede haber ms de dos versiones de un objeto. En caso que se requieran dos versiones, adems del mdulo original. Se puede actualizar concurrentemente las propias versiones del mismo mdulo del software. Esto se llama ingeniera concurrente. Sin embargo, siempre llega el momento en que es preciso combinar (fusionar) estas dos versiones para que la versin hibrida incluya los cambios realizados. Es necesario de que sus cambios sean compatibles. Un objeto complejo, como un sistema de software, puede constar de muchos mdulos. Cuando se permite la creacin de mltiples versiones, es posible que cada una de esos mdulos tenga varias versiones distintas y un grafo de versiones. Como se deduce del anlisis anterior, un SGBDOO debe ser capaz almacenar y controlar mltiples versiones del mismo objeto. http://edinunez.wordpress.com/2008/05/07/base-de-datos-orientado-a-objetos/ 5. Diseo de bases de datos relacionales 5.1. Introduccin El proceso de diseo de bases de datos est involucrado en el ciclo de vida de un sistema de informacin: 1. Recoleccin y anlisis de requisitos 2. Diseo 2.1. Diseo de la base de datos 2.2. Diseo de los programas de aplicacin 3. Implementacin 4. Validacin y pruebas 5. Operacin de

La metodologa de diseo de bases de datos relacionales se ha consolidado a lo largo de los aos satisfaciendo las propiedades de generalidad (independencia de la plataforma hardware/software), calidad del producto (precisin, completitud y eficacia) y facilidad de uso. Consta de las siguientes fases: 1. Diseo conceptual. Herramienta: Modelo conceptual de datos. Se usa alguna variante del modelo entidadrelacin. Resultado: Esquema conceptual de la base de datos. 2. Diseo lgico. Herramienta: Modelo lgico de datos. Se usa el modelo lgico que implemente el sistema de gestin de bases de datos objetivo, pero es independiente de los aspectos fsicos. Se usan tcnicas formales para verificar la calidad del esquema lgico; la ms usual es la normalizacin. Resultado: Esquema lgico de la base de datos. 3. Diseo fsico. Herramienta: Modelo fsico de datos. Detalles de la implementacin fsica: organizacin de archivos e ndices para el SGBD considerado. Resultado: Esquema fsico de la base de datos. Requisitos (Especificaciones escritas en lenguaje natural)

Diseo conceptual Esquema conceptual (Modelo entidad-relacin) Diseo lgico Diseo de tablas Diseo fsico Organizacin de archivos e ndices http://www.fdi.ucm.es/profesor/milanjm/bdsi0304/Tema05.pdf

relacionales Los datos se muestran en forma de tablas y relaciones. Este es el modelo que se comenta en el presente documento. De hecho es el claramente ms popular. orientadas a objetos Desde la aparicin de la programacin orientada a objetos (POO u OOP) se empez a pensar en bases de datos adaptadas a estos lenguajes. En estos lenguajes los datos y los procedimientos se almacenan juntos. Esta es la idea de las bases de datos orientadas a objetos. A travs de esta idea se intenta que estas bases de datos consiguen arreglar las limitaciones de las relacionales. Por ejemplo el problema de la herencia, tipos definidos

por el usuario, disparadores almacenables en la base de datos, soporte multimedia... Se supone que son las bases de datos de tercera generacin (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales (aunque cada vez hay ms). Su modelo conceptual se suele disear en UML y el lgico en ODMG 3.0 objeto relacionales Tratan de ser un hbrido entre el modelo relacional y el orientado a objetos. El problema de las bases de datos orientadas a objetos es que requieren reinvertir de nuevo para convertir las bases de datos. En las bases de datos objeto relacionales se intenta conseguir una compatibilidad relacional dando la posibilidad de integrar mejoras de la orientacin a objetos. Estas bases de datos se basan en el estndar SQL 99 que dict las normas para estas bases de datos. En ese estndar se aade a las bases relacionales la posibilidad de almacenar procedimientos de usuario, triggers, tipos definidos por el usuario, consultas

recursivas, bases de datos OLAP, tipos LOB,... Las ltimas versiones de la mayora de las grandes bases de datos relacionales (Oracle, SQL Server, Informix, ...) son objeto relacionales. http://www.jorgesanchez.net/bd/bdrelacional.pdf

DISEO Y NORMALIZACIN DE BASES DE DATOS RELACIONALES Diseando la BD Para disear una base de datos se parte de la recoleccin de atributos o campos que va a tener, y de la definicin de sus tipos de dato. La manera ms profesional es realizando el anlisis de requisitos con todas las personas que van a hacer uso de los datos. Pero por experiencia ya sabis que esto se hace muy a ojo: os piden realizar una aplicacin y segn los requisitos de la aplicacin hacis el diseo de la BD. El primer mtodo est ms estandarizado, y suele ser ms lento pero a cambio es improbable que el diseo salga mal. El segundo esms rpido porque directamente se piensa en las tablas y sus datos sobre la marcha. Se utiliza principalmente en la metodologa de programacin conocida como programacin extrema y en las dems de la familia desarrollo gil de software; y es ms propenso a fallos de diseo, proporcionalmente inversos al tiempo que se dedique a su definicin y valoracin (ms tiempo, menos probabilidad de fallos). Normalizando la BD La normalizacin es un mtodo de anlisis de BD para conseguir una BD relacional, que respete la integridad referencial, y que no tenga redundancia de datos. Se divide en formas normales, y aunque hay un montn y es toda una ciencia, explicar por encima las 3 primeras ya que el nivel 3 es suficiente para la mayora de casos. Hay que destacar que la normalizacin se puede hacer a nivel completo de la BD, o a nivel de tablas o esquemas. La tcnica es la misma: analizar el conjunto de campos y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de facturacin

podemos partir de los datos del cliente aadiendo la clave del cliente, y segn vayamos normalizando nos saldrn todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irn saliendo otras tablas subordinadas si acaso. Las reglas de Codd Adems de la normalizacin hay unas reglas, las reglas de Codd, que ayudan a disear una BD relacional perfecta (desde el punto de vista de Codd, claro) que merece la pena estudiarlas pues son casi de lgica comn y nos harn la vida ms fcil en todos los sentidos. La idea de estas reglas surgi porque la normalizacin no era suficiente para que una BD fuera relacional, consistente e independiente. Hay ocasiones en las que los diseadores de las BD confeccionan la BD para satisfacer necesidades lgicas y funcionales de una aplicacin, por ejemplo almacenando los datos en un formato que luego la aplicacin se encarga de transformar. Esto es bastante tpico cuando el diseador es el programador de la aplicacin, y lo hace por comodidad o falta de conocimiento. La moraleja es que una BD debe ser independiente de la aplicacin, y si lo pensis bien es mejor as. Segn las reglas de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (tpicamente SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada desde la aplicacin). Con esto conseguiremos que mediante el SQL no se puedan realizar operaciones que hagan que la aplicacin no funcione (introduciendo datos en un formato inesperado para la aplicacin, por ejemplo), y entre otras cosas, que si tenemos que realizar informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que parsear nada ni realizar consultas sobre consultas. Normalizando la BD: primera forma normal (1FN) Se podra decir que al aplicarla hay que asegurarse de que: No se permiten vectores de campos en una columnaUn ejemplo de esto es cuando en un campo de texto metemos varios valores del mismo dominio, como por ejemplo tres nmeros de telfono, o dos direcciones e-mail. Lo tpico en estos casos es separar los datos por comas, espacios u otro carcter y depus procesarlo mediante la aplicacin.

Para evitar esto hay que definir una nueva tabla que tendr el identificador de la tabla de la que parte y el campo multivaluado, haciendo juntos de clave nica compuesta (se puede definir otra incremental si se desea, pero el conjunto de los otros dos campos tiene que ser nico). Adems en esta tabla se puede agregar campos que ayuden a describir el tipo de registro. Ejemplo Incorrecto clientes IDCliente Nombre 45 275 Correcto clientes IDCliente Nombre 45 275 Francisco Miguel Telefono

Francisco 444444444 Miguel 555555555,666666666

telefonos_cliente IDCliente Telefono 45 275 275 444444444 555555555 666666666

No se permiten grupos repetidos en varias columnas Esto es una variante de lo anterior: separamos los campos de un mismo dominio en varias columnas, haciendo un grupo difcilmente procesable a la hora de consultarlo. En el ejemplo anterior sera tener el campo telefono1, telefono2 y as. Es evidente que este fallo del diseo es incluso peor que el anterior pues habr muchos campos nulos, y en caso de necesitar ms tendramos que redimensionar la tabla con un nuevo campo (telefono3). Pero la solucin es sencilla: la misma que en el anterior caso. Ejemplo

Incorrecto clientes IDCliente Nombre 45 275 Correcto clientes IDCliente Nombre 45 275 Francisco Miguel Telefono Telefono2 Telefono3 NULL

Francisco 444444444 NULL Miguel

555555555 666666666 NULL

telefonos_cliente IDCliente Telefono 45 275 275

444444444 555555555 666666666

No se permiten campos nulos Esta regla es algo discutible, pero tiene su lgica. Para empezar, si un campo

va a tener valores nulos, qu proporcin de registros tendrn ese campo con valor nulo? En mi opinin esta regla nos ayuda a separar unas entidades de otras, porque si una cantidad de registros tienen unos atributos que otros no, no ser que pertenecen a otra clase? Por ejemplo, si en una tabla de productos definimos los campos talla, kilates y potencia se ve que los productos tendrn clases diversas y entonces habr que crear una entidad para cada clase (ropas, joya y elctricos, por ejemplo) construyendo lo que se llama una generalizacin. Ejemplo Incorrecto productos IDProducto 147 155 221 Correcto productos IDProducto 147 155 221 ropas IDProducto Talla 147 joyas 44 Nombre Blusa fashion Broche duquesa Subwoofer extreme Nombre Blusa fashion Broche duquesa Talla Kilates Potencia 44 NULL NULL NULL 1500

NULL 24

Subwoofer extreme NULL NULL

IDProducto Kilates 155 electricos IDProducto Potencia 221 1500 24

Normalizando la BD: segunda forma normal (2FN) Una tabla est en segunda forma normal siempre que est en primera forma normal y todos sus atributos (campos) dependan totalmente de la clave candidate sin ser parte de ella. Viene a ser que, si un campo de la tabla no depende totalmente de una clave nica (que pueden ser compuestas), debe sacarse fuera con la parte de la clave principal de la que es dependiente. Ejemplo Incorrecto lineas_pedido IDCliente IDProducto Cantidad 29 46 204 144 42 9 42 10 1 5 1 1 Nombre_producto Zapatillas deportivas de tenis Baln reglamentario de baloncesto Zapatillas deportivas de tenis Zapatillas deportivas de rugby

Correcto lineas_pedido IDCliente IDProducto Cantidad

29 46 204 144 productos

42 9 42 10

1 5 1 1

IDProducto 9 10 42

Nombre_producto Baln reglamentario de baloncesto Zapatillas deportivas de rugby Zapatillas deportivas de tenis

Como vemos en la tabla lineas_pedido del ejemplo incorrecto, la nica clave candidata es IDCliente + IDProducto, ya que en conjunto son nicas en la tabla (podramos tener un IDLinea_pedido nico tambin, pero an as esos dos campos seguran siendo una clave candidata). El campo Cantidad es dependiente de la clave candidata, pues el cliente ha pedido de ese producto una cantidad determinada de artculos, pero el nombre en cambio es dependiente slo del producto, no del cliente. Si dejaramos esa tabla como est, tendramos por una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla de productos, y adems podran darse inconsistencias de datos si cambiamos el nombre del producto en un registro cul sera el nombre real del producto 42 si en varios registros tiene un nombre distinto? Conclusiones Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves candidatas (compuestas), que identifican de manera nica el registro; comprobar que los campos que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el segundo paso puede ayudar preguntarse lo siguiente: puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte

de la clave candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el anlisis esto requiere un mnimo de agudeza, pues puede que casualmente el valor de un campo se repita para una parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en cantidades de 5) pero sabemos que no es dependiente de ella. Por ltimo, aclarar que hay ocasiones en las que el anlisis no tiene que ser tan cerrado, ya que a veces las apariencias engaan. Un ejemplo de ello es una tabla de facturas que tiene el nombre, direccin, NIF, y dems datos del cliente: a simple vista esos datos estn duplicados y dependen del cliente y no de la factura, pero resulta que esos datos deben permanecer ah pues fiscalmente debemos saber a qu datos se emiti una factura; esos datos son realmente dependientes de la factura, no del cliente. Si no los incluyramos en la tabla de facturas, al modificar el registro del cliente en la tabla de clientes no sabramos a qu datos fiscales se emiti la factura. As que una vez ms, hay que utilizar un poco de ingenio y no aplicar normas como una mquina y sin pensar. Normalizando la BD: tercera forma normal (3FN) Una tabla est en tercera forma normal siempre que est en segunda forma normal (y por consiguiente en primera) y todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen nicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta: ningn campo que no sea parte de la clave candidata puede depender de otro campo que no sea la clave candidata.

Ejemplo Incorrecto carga_diaria IDServidor 21 21 21 Fecha IDServicio Nombre_servicio Carga Oracle MySQL Apache 100 100 85

2009-01-14 1 2009-01-15 9 2009-01-16 22

34 34 34 66 66 66

2009-01-14 3 2009-01-15 22 2009-01-16 22 2009-01-14 9 2009-01-15 22 2009-01-16 1

PostgreSQL Apache Apache MySQL Apache Oracle 10g

74 58 67 98 94 84

Correcto carga_diaria IDServidor 21 21 21 34 34 34 66 66 66 servicios IDServicio Nombre_servicio Fecha IDServicio Carga 100 100 85 74 58 67 98 94 84

2009-01-14 1 2009-01-15 9 2009-01-16 22 2009-01-14 3 2009-01-15 22 2009-01-16 22 2009-01-14 9 2009-01-15 22 2009-01-16 1

1 9 22 3 22 22 9 22 1

Oracle MySQL Apache PostgreSQL Apache Apache MySQL Apache Oracle 10g

Imaginad que una tabla se encarga de registrar el primer servicio que ms carga los servidores cada da. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha son la clave candidata, pues identifican de manera nica los registros. Analizando vemos que el IDServicio, que no es un campo primario, depende nicamente de la clave candidata, y que la carga tambin. Pero resulta que el Nombre_servicio depende de esa clave candidata pero tambin depende del IDServicio, pues con el IDServicio podemos averiguar qu Nombre_servicio tiene el registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el IDServicio para que sea la clave principal pues es el campo del que depende. Y con este ejemplo vemos qu fcil es librarnos de las inconsistencias de no cumplir la tercera forma normal, y de la redundancia de datos. Si no hubieramos normalizado tendramos que en un registro el IDServicio 22 es Apache y nadie nos asegura que en otro el IDServicio 22 tambin lo sea pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un histrico de 500 servidores durante 1000 das, tendramos 500 mil registros con un campo innecesario que estara duplicado muchsimas veces.

Diseando la BD sobre la marcha Si en vuestro desempeo habitual del trabajo os encontris con que no podis aplicar, de una manera formal y detallada, la normalizacin a la hora de disear BD, no os alarmis pues le pasa a mucha gente. Lo que puede ocurrir es que nos quede una BD no relacional, y eso es siempre negativo, pero a base de experiencia iris adquiriendo una soltura y capacidad analtica automticas. La normalizacin, al basarse en reglas lgicas, se puede memorizar muy fcilmente y al final forma parte del instinto del diseador: no necesitaris bolgrafo y papel para ver que una tabla no est normalizada. De hecho cuando sepis que datos necesita la aplicacin pensaris directamente en las tablas que saldrn. Primero, documentarse Lo ms importante para disear la BD sobre la marcha es tener la mente amplia, conocer las bases de la normalizacin, y dejarse aconsejar por los expertos. Todo esto de las BD relacionales no es nuevo y hay muchos gurs (Codd, Edgar Frank Codd, es el padre de todos) que os pueden ayudar a entender qu caractersticas debe cumplir una BD para ser relacional. De modo que si no sabis del tema, lo mejor es que os olvidis de las malas enseanazas que tengis imbuidas: una BD con muchas tablas no est mal diseada (una con pocas es ms probable que s lo est); llevarse el cdigo del cliente a todas las tablas (lo necesiten o no) no es la forma de tener una BD relacional; guardar los datos serializados en un campo no te hace la vida ms fcil; tener un campo que hace referencia a una tabla unas veces y a otra en otras ocasiones no es un buen diseo (un campo referencial slo puede referenciar a una tabla, as que usad la generalizacin en esas situaciones). Errores habituales Un error habitual a la hora de usar este mtodo de diseo es tener un campo referencial que admite valores nulos o vacos (tpico clave_referencia 0 cuando no referencia a nada). Si la BD es relacional, un campo referencial tiene que apuntar a otro registro en la BD. A veces tenemos un campo IDPadre que hace referencia a un mismo registro de la tabla, o vale 0 cuando el registro es padre en s pero lo correcto en una relacin reflexiva (una tabla relacionada consigo misma) que da lugar a otro tabla que contiene el IDHijo y el IDPadre; consultando esa tabla podemos saber si un registro es hijo (tiene entradas con su ID en IDHijo) o padre (su ID est en algn IDPadre) y sacar todos los hijos de un padre.

Consejos Otro buen consejo, que no est limitado a este mtodo de disear, es tener en cuenta el tamao de las tablas en cuanto a longitud de fila (en bytes). De hecho recuerdo que me hablaron de una regla de diseo de BD que deca que una tabla no deba contener ms de X campos y bueno, siempre es discutible pero es ms ptimo que la longitud de la fila no sea muy larga, sobre todo en las tablas que se consultan con frecuencia. Es una prctica muy recomendada que si tenemos campos grandes, tipo TEXT o BLOB, saquemos esos datos a otra tabla para que las bsquedas y JOIN generales que no necesiten ese campo sean ms rpidas. Hay que tener en cuenta que el sistema de gestin de BD (SGBD) en ocasiones no puede optimizar las consultas y necesita escanear por completo la tabla, o tiene que volcarla a la memoria fsica o virtual. En definitiva: recordad que una BD relacional no puede ser dependiente de la aplicacin, sino al revs. As que olvidaros de disearla pensando qu es lo mejor para la aplicacin, y pensad qu es lo correcto para que sea ms ptima y sencilla de manejarindependientemente del cliente que la maneje (aplicacin, consultas directas, herramientas de informe).

http://www.the-evangelist.info/2010/04/diseno-y-normalizacion-de-bases-de-datosrelacionales/