Está en la página 1de 10

MODELAMIENTO DE BASE DE DATOS Modelo de BD Un modelo de base de datos es la fundacin terica de una base de datos y fundamentalmente determina de que

manera los datos van a ser guardados, organizados y manipulados en un sistema de base de datos. De esta forma, define la infraestructura ofrecida por un sistema de base de datos particular. El ejemplo mas popular de un modelo de base de datos, es el modelo relacional. Modelos de Base de Datos Un modelo de base de datos es una teora o especificacin que describe como una base de datos es estructurada y usada. Varios modelos han sido sugeridos. Modelos comunes: Modelo jerrquico Modelo de red Modelo relacional Modelo entidad-relacin Modelo objeto-relacional Modelo de objeto tambin define el conjunto de las operaciones que pueden ser realizadas sobre los datos.

Diseo de una BD El diseo de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando tcnicas especficas. As, el diseo de una base de datos se descompone en diseo conceptual, diseo lgico y diseo fsico."

Modelo Conceptual. "Se utilizan para representar la realidad a un alto nivel de abstraccin. Mediante los modelos conceptuales se puede construir una descripcin de la realidad fcil de entender." Se utiliza para la abstraccin de la base de datos, para construir una descripcin para entender en la realidad

Modelo Lgico. "Es una descripcin de la estructura de la base de datos en trminos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lgico es un lenguaje usado para especificar esquemas lgicos (modelo relacional, modelo de red, etc.). El diseo lgico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto." Es una descripcin usada para especificar el esquema lgico detallado del modelo conceptual, depende del tipo SGBD que se va a utilizar y no depende del producto concreto. Modelo Fsico. "Es una descripcin de la implementacin de una base de datos en memoria secundaria: las estructuras de almacenamiento y los mtodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseo fsico depende del SGBD concreto y el esquema fsico se expresa mediante su lenguaje de definicin de datos."

SISTEMA DE GESTIN DE BASES DE DATOS Objetivos Existen distintos objetivos que deben cumplir los SGBD:

Abstraccin de la informacin. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento fsico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. As, se definen varios niveles de abstraccin.

Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (fsico o lgico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, ser necesario vigilar que aquella informacin que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultnea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debera aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programacin de este tipo de condiciones.

Seguridad. La informacin almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta informacin se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categoras de permisos.

Manejo de transacciones. Una transaccin es un programa que se ejecuta como una sola operacin. Esto quiere decir que luego de una ejecucin en la que se produce una falla es el mismo que se obtendra si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho ms simple que si no se dispusiera de ellos.

Ventajas Proveen facilidades para la manipulacin de grandes volmenes de datos (ver objetivos). Entre stas: Simplifican la programacin de equipos de consistencia. Manejando las polticas de respaldo adecuadas, garantizan que los cambios de la base sern siempre consistentes sin importar si hay errores correctamente, etc. Organizan los datos con un impacto mnimo en el cdigo de los programas. Disminuyen drsticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores. Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperacin de los datos.

Inconvenientes Tpicamente, es necesario disponer de una o ms personas que administren la base de datos, de la misma forma en que suele ser necesario en instalaciones de cierto porte disponer de una o ms personas que administren los sistemas operativos. Esto puede llegar a incrementar los costos de operacin en una empresa. Sin embargo hay que balancear este aspecto con la calidad y confiabilidad del sistema que se obtiene. Si se tienen muy pocos datos que son usados por un nico usuario por vez y no hay que realizar consultas complejas sobre los datos, entonces es posible que sea mejor usar una hoja de clculo. Complejidad: los software muy complejos y las personas que vayan a usarlo deben tener conocimiento de las funcionalidades del mismo para poder aprovecharlo al mximo. Tamao: la complejidad y la gran cantidad de funciones que tienen hacen que sea un software de gran tamao, que requiere de gran cantidad de memoria para poder correr. Coste del hardware adicional: los requisitos de hardware para correr un SGBD por lo general son relativamente altos, por lo que estos equipos pueden llegar a costar gran cantidad de dinero.

Productos SGBD en el mercado Sistemas libres PostgreSQL (http://www.postgresql.org Postgresql) Licencia BSD Firebird basada en la versin 6 de InterBase, Initial Developer's PUBLIC LICENSE Version 1.0. SQLite (http://www.sqlite.org SQLite) Licencia Dominio Pblico DB2 Express-C (http://www.ibm.com/software/data/db2/express/) Apache Derby (http://db.apache.org/derby/) MariaDB (http://mariadb.org/) MySQL (http://dev.mysql.com/) Drizzle (http://www.drizzle.org/)

Sistemas no libres MySQL: Licencia Dual, depende del uso. No se sabe hasta cundo permanecer as, ya que ha sido comprada por Oracle. Sin embargo, existen 2 versiones: una gratuita que sera equivalente a la edicin "express" SQL server de Microsoft Windows, y otra ms completa de pago. Advantage Database dBase FileMaker Fox Pro gsBase IBM DB2: Universal Database (DB2 UDB) IBM Informix Interbase de CodeGear, filial de Borland MAGIC

Microsoft Access Microsoft SQL Server NexusDB Open Access Oracle Paradox PervasiveSQL Progress (DBMS) Sybase ASE Sybase ASA Sybase IQ WindowBase IBM IMS Base de Datos Jerrquica CA-IDMS

Sistemas no libres y gratuitos Microsoft SQL Server Express Edition (Es una edicin gratis de SQL Server ideal para desarrollo y pequeas aplicaciones) Microsoft SQL Server Compact Edition Basica Sybase ASE Express Edition para Linux (edicin gratuita para Linux) Oracle Express Edition 10 (solo corre en un servidor, capacidad limitada) DB2 Express-C

DER "Diagrama de Entidad Relacin" es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de informacin as como sus interrelaciones y propiedades.

Modelado Entidad-Relacin 1. Se elabora el diagrama (o diagramas) entidad-relacin. 2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente: Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).

Base terica y conceptual El modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.

Entidad Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos: Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin). Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc...

Atributos Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca.

Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ... Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.

Relacin Describe cierta dependencia entre entidades o permite la asociacin de las mismas. Ejemplo: Si tenemos dos entidades, "CLIENTE" y "HABITACION", podemos entender la relacin entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podriamos tener la ocurrencia "Habitacin 502", de la entidad "HABITACION" y la ocurrencia "Henry Jonshon Mcfly Bogard", de la entidad "CLIENTE", entre las que es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry. Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un husped (entidad), se aloja (relacin) en una habitacin (entidad).

Conjunto de relaciones Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.

Restricciones Son reglas que deben mantener los datos almacenados en la base de datos. Correspondencia de cardinalidades Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser: Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo). Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas). Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo). Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

Restricciones de participacin Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos: Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.

Claves

Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves: Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades. Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias.

Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos: R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes. R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes. Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades: R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R. R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

Diagrama entidad-relacin Anteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.

Entidades Las entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo.

Atributos Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidad-relacin, sino descritos textualmente en otros documentos adjuntos.

Relaciones Se representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.

LENGUAJE UNIFICADO DE MODELADO Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar.

UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es el lenguaje estndar para realizar el modelado de los sistemas de software y es independiente del lenguaje de programacin utilizado.

En este artculo no vamos a entrar en ms detalles de lo que es UML y de su historia, nos vamos a centrar en las partes ms significativas del lenguaje.

UML tiene tres elementos fundamentales: Bloques bsicos de construccin o Elementos o Relaciones o Diagramas Reglas que dictan como se pueden combinar estos bloques bsicos. UML tiene reglas para: o Nombres o Alcance o Visibilidad o Integridad o Ejecucin Mecanismos comunes. Que se basen en algn patrn, al igual que en arquitectura se puede hablar del barroco, romnico, etc.. o Especificaciones o Adornos o Divisiones comunes o Mecanismos de extensibilidad

Como dijo Grady Booch: El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML.

En todo proceso de software donde se utilice una metodologa orientada a objetos y la notacin UML no pueden faltar los diagramas, para representar las diferentes vistas del producto final.

Los diagramas de UML se pueden dividir en estticos (aportan una visin esttica del sistema) y dinmicos (aportan una visin dinnica del sistema).

Los diagramas estticos: Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de componentes Diagrama de despliegue

Los diagramas dinmicos: Diagrama de estados Diagrama de actividad Diagramas de interaccin: o o Diagrama de secuencia Diagrama de colaboracin

Como se puede ver hay demasiados diagramas y en muchos proyectos no son necesarios todos los diagramas. Ser la prctica y experiencia y el tipo de sistema a desarrollar lo que nos ayudar a escoger los diagramas a utilizar, por ejemplo podemos decir que para aplicaciones cliente se suelen utilizar los diagramas de casos de uso, de clase y de colaboracin o de secuencia, para aplicaciones donde sean importantes los eventos se puede utilizar el diagrama de estados, para aplicaciones cliente-servidor aparte de los diagramas de casos de uso, clases y objetos tambin puede ser conveniente utilizar los diagramas de despliegue y componentes, y para aplicaciones complejas cliente-servidor pues si ser recomendable utilizar todos los diagramas ya que dar una visin ms amplia de cmo ser el sistema final.