Base de Datos

Base de DatosDiseo de una base de datosMg. Milagros Elisa Leonardo RamosDiseo de una base de datosEn este punto se tratar a fondo el diseo de una base de datos, desde la interpretacin y anlisis de un problema hasta el diseo y propuesta de un modelo que dar solucin al problema planteado.Representacin del problemaEl diseo de base de datos consiste en extraer todos los datos relevantes de un problema.Por ejemplo:Conocer los datos implicados en el proceso de facturacin de una empresa de ventas de seguros de automvil.Conocer los datos necesarios para llevar el control veterinario de los animales de un zoolgico.Conocer los datos correspondientes a la gestin de urgencias de un hospitalPara ello, lo primero que se debe hacer para extraer estos datos es realizar un anlisis en profundidad del dominio del problema para saber qu datos son esenciales y cuales no para la base de datos.ACTIVIDAD 1: Examinar el archivo SRS Software Requirements Specification, y verificar como los analistas de software organizan los requisitos de una aplicacin extrados de las conversaciones con usuarios.Si se va a desarrollar para una empresa de seguros de automvil, el dominio del problema sera el conjunto de conceptos como: pliza, asegurado, siniestro, franquicia, parte, etc.

Si se va a desarrollar una aplicacin para la gestin de urgencias de un hospital, el dominio del problema sera todo el conjunto de conceptos relacionados: urgencia, paciente, triage, ingreso, guardia, admisin, diagnstico, etc. 3Modelo de datosPara modelar un problema de base de datos es necesario tener en cuenta las siguientes consideraciones:La persona que realiza la modelizacin es un analista informtico, pero es necesario contar con la participacin del futuro usuario de la base de datos que conozca a fondo todos los pormenores del negocio.Hay que modelar siguiendo una filosofa estndar para que el resto de la comunidad informtica pueda entender y comprender el modelo realizado.La base de datos estar gestionada por un SGBD que tendr caractersticas tcnicas, de tal manera, no se tratar igual la implantacin de la base de datos en un sistema MySQL que en uno DB2.Modelo ConceptualModelo LgicoSe analizan las relaciones entre entidades y entre atributos de las entidades. Se estudian los atributos, valores de datos, claves, registros de datos, archivos de datos.Se realiza el proceso de Normalizacin, para determinar las estructuras de informacin que corresponden a la organizacin o al sistema.Se debe aplicar al modelo conceptual, las restricciones propias del modelo de base de datos de que se trate: Ejemplo: Jerrquicas, redes, relacionales, Objetos, etc.1er. Paso: Diseo del modelo fsico .

2do. Paso: Evaluar su performance Modelo Conceptual : Define las caractersticas del negocio en forma independiente de la tecnologa de implementacin. Est Representado por las Entidades de la empresa y sus relaciones.Diseo Lgico de Base de Datos : Define la solucin tecnolgica, tomando como base el modelo conceptual.Diseo Fsico: se encarga de todo lo relativo a funciones de la Base de Datos, accesos, almacenamiento, estructuras fsicas de informacin.Modelo FsicoModelo de datosModelo de datosLa interaccin entre los tres modelos es fundamental para un diseo de calidad:Primero se negocia con el usuario el modelo conceptual.Segundo, se pasa el modelo conceptual al modelo lgico, realizando una serie de transformaciones necesarias para adaptar el lenguaje del usuarioal del gestor de base de datos.Finalmente, se transforma el modelo lgico en fsico, obteniendode esta forma la base de datos final.USUARIO EXPERTOINFORMTICO DISEADOR-BDPROGRAMADOR BDADMINISTRADOR BDBASE DE DATOSDOMINIO DEL PROBLEMAMODELO CONCEPTUALMODELO FSICOModelo lgicoDiagrama E-RPara representar el modelo conceptual se usa el modelo Entidad Relacin.Este modelo consiste en plasmar el resultado del anlisis del problema mediante diagramas Entidad Relacin.Estos diagramas fueron propuestos por Peter P. Chen a mediados de los aos 70 para la representacin conceptual de los datos y establecer qu relacin existan entre ellos.La notacin es muy sencilla, fcil de entender por el usuario.Diagrama E-R1. Entidad:Cualquier tipo de objeto o concepto sobre el que recoge informacin.Puede ser una cosa, persona, concepto abstracto o suceso.Es representado grficamente mediante un rectngulo incluyendo su nombre al interior (generalmente en singular).Cada nombre es nico, solo puede aparecer una vez en el diagrama.

Diagrama E-REjemplo:

CLIENTEEMPLEADOPEDIDOPRODUCTODiagrama E-RTipos de Entidad:

Fuertes: Una entidad fuerte es una entidad que existe por mrito propio.

Dbiles:Una entidad dbil es una entidad cuya existencia depende de la existencia de otra entidad.Se representan mediante un rectngulo doble

Diagrama E-RTipos de Entidad:Un ejemplo tpico es la existencia de dos entidades para la representacin de un pedido:Por un lado la entidad pedido representa informacin genrica sobre el pedido, como: fecha de pedido, fecha de envi, estado, etc.Por otro lado la entidad detalle de pedido, recopila las lneas de informacin especficas sobre los artculos y unidades pedidas.

PedidoDetalle de pedidoEn este caso detalle de pedido es la entidad dbil puesto que la eliminacin del pedido implica la eliminacin de las lneas de detalle asociado al pedido.No tendra sentido almacenar informacin especfica del pedido si se ha eliminado ese pedido.11Diagrama E-R2. Relacin:Una relacin, es una correspondencia o asociacin entre dos o ms entidades.Cada relacin tiene un nombre que describe su funcin.Las relaciones se expresan grficamente segn rombos y su nombre en el interior.Por lo general el nombre de relacin corresponde a un verbo ya que representan acciones entre entidades.

Normalmente debe utilizarse un nombre que exprese con totalidad la finalidad de la relacin evitando poner un nombre que pueda significar muchas cosas, como tener, hacer, poseer.12Diagrama E-RBinarias:

Unarias:

Tipos de Relacin:MECNICOVEHCULOTerciarias:

N-arias:

ReparaALUMNOMDULOCursaCICLONormalmente debe utilizarse un nombre que exprese con totalidad la finalidad de la relacin evitando poner un nombre que pueda significar muchas cosas, como tener, hacer, poseer.13Diagrama E-R2. Participacin:La participacin de una ocurrencia de una entidad, indica mediante una pareja de nmeros, el mnimo y mximo nmero de veces que puede aparecer en la relacin asociada a otra ocurrencia de entidad.

ParticipacinSignificado(0,1)Mnimo cero, mximo uno(1,1)Mnimo uno, mximo uno(0,n)Mnimo cero, mximo n (Muchos)(1,n)Mnimo uno, mximo n (Muchos)Normalmente debe utilizarse un nombre que exprese con totalidad la finalidad de la relacin evitando poner un nombre que pueda significar muchas cosas, como tener, hacer, poseer.Las reglas se rigen en funcin a las reglas del negocio, las que conocemos a travs de los requisitos del problema.14REPASOLas Reglas empresariales toman la forma de una oracin donde hay un verbo que enlaza dos entidades.

Por Ejemplo

Suponiendo que del modelo empresarial de una compaa elegimos dos Entidades, digamos:

EMPLEADO y DEPARTAMENTO16Podemos definir una regla que relacione estos dos objetos y que refleje la forma como opera la empresa

Un EMPLEADO Trabaja en un DEPARTAMENTO

Como vemos, hay un verbo que relaciona los dos conceptos.REPASOEMPLEADODEPARTAMENTOTrabaja enREPASOToda regla empresarial debe de tratar de escribirse en los dos sentidos, es decir que para el ejemplo anterior, debemos poder expresar la misma relacin pero en sentido inverso, es decir tendramos.

"En UN DEPARTAMENTO trabajan UNO O MAS EMPLEADOS"

Notemos que para poder ser consistentes al escribir la relacin en forma inversa hemos tenido que colocar las palabras UNO O MAS y no simplemente UN EMPLEADO.Las palabras UNO, UNO o MAS indican la "cardinalidad" de la relacin. El tratar de escribir las reglas de relacin en los dos sentidos, nos obliga a precisar la cardinalidad de relacin.