- DISEÑO DE BASE DE DATOS -

Hasta ahora hemos dado por supuesto que los datos de la base de datos tienen una estructura, por ejemplo los empleados tienen nombre, apellido, dirección, entre otros. Pero ¿cómo obtenemos esta estructura? La respuesta es muy simple, la estructura de la base de datos se determina durante el diseño de la base de datos sin embargo esta tarea puede se muy compleja. 

Para producir un sistema que satisfaga a toda la organización se debe usar un enfoque distinto al usado en el procesamiento de archivos donde se dirigía el trabajo hacia un departamento y las aplicaciones que necesitaba. Ahora se debe pensar primero en los datos y luego en las aplicaciones, por lo que una base de datos mal diseñada puede llevar a errores que pueden llevar a decisiones incorrectas.

El objetivo fundamental del diseño de bases de datos es obtener un conjunto de datos y un conjunto de operaciones sobre ellos, que permitan satisfacer las necesidades de la organizacion

 FASES DEL DISEÑO DE BASE DE DATOS 

El proceso de diseño esta compuesto por una serie de fases que servirán como guía al diseñador acerca de las técnicas apropiadas en cada una. 

a. Diseño conceptual de la base de datos: Es la primera fase del diseño de BD e implica la creación de un modelo de datos conceptual (donde se reflejen los conceptos) para aquellos procesos de la empresa que se desean modelar. Este modelo se construye usando la información documentada en la especificación de requisitos de los usuarios, y es “independiente” de los detalles de implementación tales como el tipo de SMBD, los programas de aplicación, los lenguajes de programación o la plataforma de Hardware, es decir, en esta fase no importa como o donde se va a implementar la base de datos. Este modelo se valida de acuerdo a los requerimientos de los usuarios y es una fuente de información para la siguiente fase.

b. Diseño lógico de la base de datos: En esta segunda fase, el diseñador traduce el modelo conceptual a un modelo lógico, donde se toma en cuenta la implementación del SMBD (si es relacional, orientado a objetos, entre otros), pero ninguna otra consideración física, igualmente se valida con los requerimientos de los usuarios y se verifica que no tenga problemas de redundancia. 

c. Diseño físico de la base de datos. En esta fase el diseñador decide como implementar la base de datos, por lo tanto se debe tener claro cuál es el SMBD a usar, ya que el diseño físico estará adaptado a este, en esta fase se implementan las estructuras de datos, sus relaciones, sus restricciones y las medidas de seguridad necesarias para resguardar los datos.

 

Los modelos se utilizan en todo tipo de ciencias. Su finalidad es la de simbolizar una parte del mundo real de forma que sea más fácilmente manipulable. En definitiva es un esquema mental (conceptual) en el que se intentan reproducir las características de una realidad específica. En el caso de los modelos de datos, lo que intentan reproducir es una información real que deseamos almacenar en un sistema informático. Se denomina esquema a una descripción específica en términos de un modelo de datos. El conjunto de datos representados por el esquema forma la base de datos.

CLASIFICACION DE LOS MODELOS DE DATOS

1. €Mundo real. Contiene la información tal cual la percibimos como seres humanos. Es el punto de partida € 

2. Esquema conceptual. Representa el modelo de datos de forma independiente del DBMS que se utilizará. € 

3. Esquema canónico (o de base de datos). Representa los datos en un formato más cercano al del ordenador € 

4. Esquema interno. Representa los datos según el modelo concreto de un sistema gestor de bases de datos (por ejemplo Oracle) € 

Base de datos física. Los datos tal cual son almacenados en disco. 

Para conseguir estos esquemas se utilizan modelos de datos. El paso entre cada esquema se sigue con unas directrices concretas. Estas directrices permiten adaptar un esquema hacia otro. Los dos modelos fundamentales de datos son el conceptual y el lógico. Ambos son conceptuales en el sentido de que convierten parámetros del mundo real en abstracciones que permiten entender los datos sin tener en cuenta la física de los mismos.

FASES PARA EL DISEÑO DE BASE DE DATOS

A.- FASE 1: RECOPILACION Y ANALISIS DE REQUERIMIENTOS.

en esta fase se trata de conocer las expectativas del usuario sobre la base de datos. para ello, se identifican los grupos de usuarios reales y posibles y las areas de aplicacion, se revisa la documentacion existente, se analiza el entorno operativo y los requerimientos de procesado, y se realizan entrevistas y cuestionarios con los usuarios. para todo ello existen tecnicas formalizadas de especificacion de requirimientos.

B.- FASE 2: DISEÑO CONCEPTUAL DE LA BASE DE DATOS

Esta fase se subdivide en otras dos; la fase 2a corresponde al diseño del esquema conceptual, esquema de especificacion del modelo de datos a alto nivel, independiente de cualquier SGBD, que no puede utilizarse para implementar directamente la estructura de la base de datos. la fase 2b corresponde al diseño de transacciones, es decir, a aquellas aplicaciones que van a manipular datos contenidos en la base de datos. se suelen identificar mediante el estudio de las entradas y salidas de datos y su comportamiento funcional.

C.- FASE 3: ELECCION DE UN SGBD.

se consideran diferentes factores tecnicos, economicos y de beneficio, de servicio tecnico y formacion de usuarios, organizativos de rendimiento, etc

D.- FASE 4: TRANSFORMACION DEL MODELO DE DATOS 

en esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformacion de los esquemas de modelo de datos a alto nivel obtenidos en la fase 2a, al modelo de datos ofrecido por el SGBD.

E.- FASE 5: DISEÑO DE LA BASE DE DATOS FISICA. 

consiste en definir las estructuras de almacenamiento y de acceso para alcanzar un rendimiento optimo de las aplicaciones de la base de datos.

F.- FASE 6: IMPLEMENTACION DEL SISTEMA DE BASE DE DATOS.

En esta fase final se hace realidad la base de datos, mediante la creacion y la compilacion del esquema de bases de datos y de los ficheros de bases de datos, asi como de las transacciones, a traves de las aplicaciones.

DIFERENCIAS ENTRE EL MODELO LOGICO Y EL CONCEPTUAL€

El modelo conceptual es independiente del DBMS que se vaya a utilizar. El lógico depende de un tipo de SGBD en particular € 

El modelo lógico es más cercano al ordenador € 

Es más cercano al usuario el modelo conceptual, el lógico forma el paso entre el informático y el sistema. 

El ejemplo mas comun de un modelo conceptual:

• € Modelo E/R €: Fue ideado por Peter Chen en los años 1976 y 1977 a través de dos artículos. Se trata de un modelo que sirve para crear esquemas conceptuales de bases de datos. De hecho es prácticamente un estándar para crear esta tarea. Se le llama modelo E/R e incluso EI (Entidad / Interrelación). Sus siglas más populares son las E/R por que sirven para el inglés y el español. Inicialmente (en la propuesta de Chen) sólo se incluían los conceptos de entidad, relación y atributos. Después se añadieron otras propuestas (atributos compuestos, generalizaciones,...) que forman el llamado modelo entidad relación extendido (se conoce con las siglas ERE)

ENTIDAD: Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda almacenar información en la base de datos.
Ejemplos de entidades son Pedro, la factura número 32456, el coche matrícula 3452BCW.
Una entidad no es un propiedad concreta sino un objeto que puede poseer múltiples propiedades (atributos). 

CONJUNTO DE ENTIDADES: Las entidades que poseen las mismas propiedades forman conjuntos de entidades. Ejemplos de conjuntos de entidades son los conjuntos: personas, facturas, coches,...
En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como conjunto de entidades. De este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona en concreto sería una ocurrencia o un ejemplar de la entidad persona. 

REPRESENTACION GRAFICA DE LAS ENTIDADES: En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro del cual se escribe el nombre de la entidad

TIPOS DE ENTIDADES:

1. Regulares. Son las entidades normales que tienen existencia por sí mismas sin depender de otras. Su representación gráfica es la indicada arriba € 

1. Débiles. Su existencia depende de otras. Por ejemplo la entidad tarea laboral sólo podrá tener existencia si existe la entidad trabajo. Las entidades débiles se presentan de esta forma: 

RELACIONES: Representan asociaciones entre entidades. Es el elemento del modelo que permite relacionar en sí los datos del modelo.
Por ejemplo, en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se realizan ya que las personas trabajan y los trabajos son realizados por personas

REPRESENTACION GRAFICA: La representación gráfica de las entidades se realiza con un rombo al que se le unen líneas que se dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo anterior podría usarse como nombre de relación, trabajar: 

CARDINALIDAD: Indica el número de relaciones en las que una entidad puede aparecer. Se anota en términos de: € 

1. cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá cada ejemplar de la entidad (el valor que se anota es de cero o uno) € 

1. cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer cada ejemplar de la entidad (puede ser uno o muchos)

 En los esquemas entidad / relación la cardinalidad se puede indicar de muchas formas. Actualmente una de las más populares es esta: 

ROLES: A veces en las líneas de la relación se indican roles. Los roles representan el papel que juega una entidad en una determinada relación. Ejemplo:

ATRIBUTOS: Describen propiedades de las entidades y las relaciones. En este modelo se representan con un círculo, dentro del cual se coloca el nombre del atributo. Ejemplo: 

OPCIONALES: Lo son si pueden tener valor nulo: 

IDENTIFICADOR:Se trata de uno o más campos cuyos valores son únicos en cada ejemplar de una entidad. Se indican subrayando el nombre del identificador. 

Para que un atributo sea considerado un buen identificador tiene que cumplir:
1> Deben distinguir a cada ejemplar teniendo en cuenta las entidades que utiliza el modelo. No tiene que ser un identificador absoluto.
2> Todos los ejemplares de una entidad deben tener el mismo identificador.
3> Cuando un atributo es importante aun cuando no tenga una entidad concreta asociada, entonces se trata de una entidad y no de un atributo 

ENTIDAD IS A: Son relaciones de tipo is a (es un) aquellas en las que una entidad se descompone en entidades especializadas. Hay dos tipos de entidades is a: especializaciones y generalizaciones.

 Las especializaciones consisten en que una entidad se divide en entidades más concretas. La entidad general comparte con las especializadas sus atributos. Se observa una especialización cuando hay ejemplares para los que no tienen sentido algunos de los atributos, mientras que para otros sí. 

Se denomina generalización si se agrupan varias entidades en una o más entidades generales. Se observa una generalización si en varias entidades se observan atributos iguales, lo que significa que hay una entidad superior que posee esos atributos. 

En cualquier caso la representación en el modelo es la misma, se representan con un triángulo que tiene el texto ISA. Ejemplo: 

PASOS PARA EL DISEÑO;

1. Encontrar entidades (conjunto de entidades)

2. Identificar atributos de las entidades

3. Buscar identificadores

4. Especificar las relaciones y cardinalidades

5. Identificar entidades debiles

6. Especializar y generalizar entidades donde sea posibles

REFERENCIAS:

• http://es.slideshare.net/tramullas/diseo-de-bases-de-datos-17102226
• http://www.jorgesanchez.net/bd/disenoBD.pdf