PASO 2 DIAGRAMA RELACIONAL

Ahora tenemos lo necesario para continuar con el siguiente paso, es el desarrollo de nuestro DIAGRAMA RELACIONAL, este no es de mucha ayuda ya que describe de manera gráfica la forma en la que estará estructurada, y nos brinda un mejor entorno para poder manipularla, para realizarlo hay que respetar ciertas reglas y conceptos dentro de esto.

Conceptos importantes que debemos conocer:

Super llave: aplica una llave o restricción a varios atributos dentro de una entidad, esto se hace para asegurar que en su conjunto no se repitan varias veces y así evitar caer en dudas al querer identificar un registro.

Llave Primaria: aplica a solo un atributo de forma que no permita que se repita en la misma entidad. Esto significa que cada ENTIDAD o TABLA deberá tener una llave primaria que la identifique, esta llave primaria puede ser cualquiera de los atributo o campos que ya le hemos asignado pero que no haya confusiones, es decir que en ese campo no puede haber repeticiones de datos, es por eso que mejor deberemos crear una llave primaria ARTIFICIAL es decir un nuevo campo, y para que resulte sencillo de comprender ejemplificaremos con algunas de nuestras Tablas de la Base de Datos:

*** Para la tabla TBLFACTURA, sabemos que toda factura lleva un registro único y necesario que la distinguirá por todas las demás, este normalmente es un correlativo, es de esa forma que ideamos u campo que sera único para cada registro de una factura, en nuestro caso lo llamaremos NODOCUMENTO (Numero de Documento) .

*** Para la tabla TBLARTICULO crearemos un código propio para que cada articulo nuevo se identifique y este será ARTICULOID.

*** Para la tabla TBLSUCURSAL crearemos también un código que identificara a cada sucursal y se llamará SUCURSALID.

Y así sucesivamente se creara para cada una de las tablas que conformen nuestra Base de Datos, mas adelante podrán visualizar las llaves primarias asignadas a cada una en el diagrama relacional.

Llave Foránea: se establece sobre un campo que debe estar relacionado estrictamente con la llave primaria de otra entidad, para así exigir que exista previamente esa llave.

Normas sencillas a seguir.

 Se crean las tablas que son las unidades de almacenamiento principal de todos los datos.

 Todas las tablas deberán estar compuestas por filas (que son los registros) y por columnas (que son los campos) que almacenaran cada uno de los registros.

 Las filas y columnas carecen, en un principio, de orden a la hora de ser almacenadas.

 El orden de las columnas lo determina cada consulta

 Cada tabla posee un identificador único de cada registro compuesto por una o más columnas, es decir posee una llave primaria.


 Para establecer una relación entre dos tablas es necesario que se incluya en una columna la llave primaria de la otra. Esta columna pasara a ser la llave foránea

Reglas básicas para realizar un diagrama relacional:

1. Todo tipo de entidad se convierte en una relación. La tabla toma el nombre de la entidad, los atributos dentro de la tabla pasaran a ser las columnas de la tabla y el atributo identificador principal será la llave primaria de la tabla y no puede llevar un valor nulo, caso contrario los otros atributos pueden tener valor nulo, es decir pueden guardar un dato en vacío.

2. Todo tipo de relación M: M (muchos a muchos) se transforma en una relación. Las relaciones muchos a muchos se transforman en otra tabla cuya llave primaria será la concatenación (la unión) de los atributos principales de las entidades que se asocian; estos atributos en esta nueva tabla serán llaves foráneas que referencia a las respectivas tablas donde son llaves primarias y los atributos de esta relación muchos a muchos serán las columnas de la tabla nueva. Usaremos un claro ejemplo para describir este tipo de relación:

** Según el planteamiento del problema menciona que los artículos se almacenaran en bodegas y que estos podrán trasladarse de una bodega a la otra, por lo tanto deducimos que: un articulo puede estar en varias bodegas y que en una bodega pueden haber varios artículos  así identificamos que es una relación muchos (artículos) a muchos (bodegas) y viceversa por lo tanto para crear un vinculo entre las dos, crearemos una nueva tabla llamada EXISTENCIABODEGA que funcionara como tabla intermedia entre las dos tablas en la que la llave primaria de TBLARTICULO osea NODOCUEMTO y la llave primaria de TBLBODEGA pasaran como llaves FORÁNEAS y a la vez PRIMARIAS (por carecer de una llave primaria) de la tabla EXISTENCIABODEGA.

De este modo es como tendremos que identificar si hay mas relaciones de este tipo y se solucionara con la creación de una TABLA INTERMEDIA, dentro de nuestra base de datos identificaremos las necesarias:

**** TBLARTICULOBODEGA -- TBLBODEGA :::: tabla intermedia: EXISTENCIABODEGA.

**** TBLARTICULO -- TBLNIVELPRECIO:::: tabla intermedia: TBLARTICULO_PRECIO.

**** TBLARTICULOPROVEEDOR -- PROVEEDOR ::::  tabla intermedia: PROVEEDORARTICULO.


3. Para todo tipo de relación 1: M se realiza lo que se denomina propagación de llave (regla general), o se creara una nueva relación. Las relaciones uno a muchos (1: M) o uno a uno (1:1) se transforman propagando el atributo identificador principal de la entidad que tiene cardinalidad máxima 1 a la que tiene cardinalidad máxima M; caso contrario si la relación fuese 1 a 1 la propagación podría realizarse en cualquier sentido de las entidades, el atributo propagado es una llave foránea que referencia a la tabla con cardinalidad máxima de 1.

***Para ejemplificar este tipo de relación usaremos las tablas TBLCLIENTE y TBLFACTURA  y analizaremos que un cliente puede tener emitidas muchas facturas pero una factura sera emitida solo para un cliente  es decir que en una factura no pueden haber registrados mas de un cliente a la vez, por lo tanto establecemos que es una relación UNO(cliente) A MUCHO(facturas) de esto surge que: la llave primaria de TBLCLIENTE osea CLIENTE se propagara o trasladara a la tabla TBLFACTURA convirtiéndose en llave foránea en ella. De este modo si identificamos relaciones de este tipo, este sera el procedimiento y que por lo general en la tabla de destino de la llave, se identificara por las siglas FK (Foreing Key).

En los siguientes temas visualizaremos mejor las relaciones formadas entre nuestras tablas y lo que ocurre con cada una de ellas en el DIAGRAMA RELACIONAL.

Los campos marcados con PK indican aquellos que son llaves primarias. Aquí se aplica la integridad de la entidad ya que una llave primaria no puede tomar valores nulos, ya que esta permite identificar sin equivocación a las tuplas de una relación.

Los campos marcados con FK son llaves foráneas, indican aquellos campos que van a almacenar llaves primarias de otras tablas de modo que se puedan relacionar con la tabla actual. Dicho de otra forma son un conjunto de atributos de una tabla que son llave primaria en otra tabla.

Los campos marcados con <M> (mandatory) indican que es un campo al cual se le exige guarde o almacene un valor.

DIAGRAMA RELACIONAL

Para realizar el DIAGRAMA RELACIONAL de nuestra base de datos, primero tendremos que comprender como serán las formas en la cual lo expresaremos para así asimilar la forma en que funcionara y tomar las decisiones adecuadas para crear nuestra base de datos, a continuación explicaremos de manera clara los tres tipos de modelo en el que se basará nuestro diagrama.

Las siguientes imágenes son a la vez el DIAGRAMA RELACIONAL de nuestra base de datos:

MODELO CONCEPTUAL

Se trata de obtener el esquema conceptual de la base de datos a partir de la lista descriptiva de objetos y asociaciones identificadas en  la organización durante el análisis.

El  Modelador debe asegurar la representación formal de los fenómenos; es decir, realizar su Modelización.  Esta Modelización debe  conservar la  semántica  de  lo  real expresado en la lista y descripción de los objetos y asociaciones y traducirla en forma no redundante.

Es decir que este diseño es independiente del modelo de DDBB usado, del ordenador, del sistema gestor de bases de datos. Simplemente se estudia el problema y se seleccionan los elementos del mundo real que vamos a modelar. El diseño Entidad/Relación

El modelo ER es uno de los enfoques de modelización de datos que más se utiliza actualmente por su simplicidad y legibilidad. Su legibilidad se ve favorecida porque proporciona una notación diagramática muy comprensiva. Es una herramienta útil tanto para ayudar al diseñador a reflejar en un modelo conceptual los requisitos del mundo real de interés como para comunicarse con el usuario final sobre el modelo conceptual obtenido y, de este modo, poder verificar si satisface sus requisitos.

MODELO LÓGICO

Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.

El objetivo principal de este díselo es transformar el diseño conceptual en un modelo de datos determinado para un sistema de gestión de bases de datos determinado. Para lograr esto se tiene que hacer uso de la normalización.

MODELO FÍSICO

El modelo físico es un modelo que representa la realidad en la implementación y por lo tanto es dependiente de la plataforma que se use. Se utiliza para plasmar la solución a nivel físico, en el caso de una base de datos, acá se tiene que modelar de acuerdo al motor de base de datos que se use.

Por consecuencia, lo mas recomendable es que se inicie con el MODELO CONCEPTUAL del diagrama para luego seguir con el MODELO LÓGICO y luego pasar el MODELO FÍSICO, que para este punto se habrá identificado lo que cada modelo requiere.

USO DE HERRAMIENTA CASE: POWER DESIGNER

Para poder diseñar estos diagramas existe una herramienta case llamada Power Designer que es un único conjunto de herramientas de modelamiento que combina distintas técnicas estándar de modelamiento: modelamiento de aplicación a través de UML, técnicas de Modelamiento de Procesos Empresariales y técnicas tradicionales de modelamiento de base de datos.

Con esta herramienta podemos iniciar a diseñar el diagrama de nuestra base de datos desde el modelo conceptual.

Generar diagrama conceptual con Power Designer

1. Seleccionar Create Model… para iniciar un nuevo proyecto

2. Seleccionar el tipo de Modelo Conceptual Data Model y asignar nombre y click en aceptar.

En pantalla se desplegará nuestra área de trabajo:

3. Agregar una entidad (tabla)

4. En la pestaña general se debe asignar el Nombre a nuestra entidad.

5.  Seleccionar la pestaña atributos

6. Realizar del paso 3 al paso 5 con cada una de las entidades.

7. Al ingresar todas las entidades seleccionar de la paleta la opción Relationship (Relación), para agregar entre entidades.

8. Dar un click sostenido entre las entidades que se desean relacionar 

9. Dar doble click sobre la relación 

10. Asignar un nombre a la relación en la pestaña General y dar click en el botón aplicar.

11. Agregar la cardinalidad que existe entre cada una de las entidades y dar click en Aplicar

12. Realizar los mismos pasos con cada una de las entidades ingresadas

Al finalizar nuestro diagrama se vera de la siguiente manera:

Otra más de las ventajas que ofrece Power Designer es que al finalizar el diagrama de manera conceptual se puede realizar la conversión al Modelo Lógico con unos simples click.

1. En la barra de herramientas seleccionar la pestaña Tools.

2. Dentro de la lista de opciones, busquemos la opción Generate Logical Data Model…

3. Nos mostrara un cuadro de opciones, en el cual se le asignara un nombre a nuestro nuevo diagrama o se actualizara uno ya existente, luego damos click en Aplicar y Aceptar.

4. Nos mostrara mensaje de creación de nuevo diagrama.

El Diagrama Lógico quedara de la siguiente Manera

Cuando ya tengamos nuestro diagrama en el modelo Lógico entonces podemos convertirlo al Modelo Físico 

1. En la barra de herramientas seleccionar la pestaña Tools. 

2. Dentro de la lista de opciones, busquemos la opción Generate Physical Data Model…

3. Nos mostrara un cuadro de opciones, en el cual se le asignara un nombre a nuestro nuevo diagrama o se actualizara uno ya existente, ademas de eso tenemos la opción de elegir sobre que SISTEMA GESTOR DE BASE DE DATOS sera implementado luego damos click en Aplicar y Aceptar.

El diagrama Físico quedaría de la siguiente manera:

Power Designer tiene nos brinda la gran ayuda que al encontrarse en el modelo Físico nos ayuda a generar el scrip para poder generar la Base de datos. 

Que es un script? Los scripts de base de datos son archivos adicionales que contienen instrucciones Transact-SQL (T-SQL) o utilidades como SQLCMD que no forman parte de la definición del esquema de base de datos. Puede utilizar scripts de base de datos como parte del proceso de implementación (scripts anteriores y posteriores a la implementación) o pueden ser scripts de administración que se almacenan en el proyecto de base de datos. 

Durante una operación de refactorización de base de datos en un objeto de esquema, puede actualizar automáticamente cualquier script que contenga un objeto de base de datos cuyo nombre cambie como parte de esa operación. 

Proceso para generar script

1. Dar click en la pestaña Database 

2. Click en la opción Generate Database… 

3. Seleccionar el directorio en donde se guardara y asignar un nombre

El Scrip se generara a través del MODELO FÍSICO lo que significa que se creará para ser implementado directamente al Sistema Gestor de Bases de Datos sobre el que este fue creado, de lo cual se hablaremos mas adelante.

Nos muestra mensaje que se generó el archivo en la que se muestra también la dirección sobre la que se ha almacenado:

Y de esta forma se ve al abrir el archivo creado sobre el Sistema Gestor de Bases de Datos SQL SERVER 2014 del cual se hará mención.