Analisis y diseño de una DB (Parte II)
Como había comentado en un post anterior, el diseño de una DB se descompone en 3 grandes fases:
- Diseño conceptual
- Diseño lógico
- Diseño físico
Esta descomposición nos permite un mejor análisis del medio que vamos a modelar, reduciendo la complejidad y permitiendo una mejor abstracción de la realidad.
Para el Diseño conceptual, se parte de la especificación de los requerimientos (como lo llegue a visualizar en el proyecto DULAS: el llamado análisis de requerimientos), el cual produce como resultado el esquema conceptual de la base de datos. El objetivo de esta fase es obtener una buena representación de la “realidad” que se modela, con independencia del usuario o aplicaciones en particular y fuera de consideraciones de eficiencia de la PC. Recuerdo que mi amigo Gsus me comentaba que para esta parte teníamos que ver a nuestro sistema como una “caja negra”, es decir: no debe de importarnos como lo hace, debemos enfocarnos en lo que hace, lo que obtenemos, lo que queremos de esta caja negra. Es en base a este principio por el cual empezamos el desarrollo de nuestra base de datos, desde el diseño conceptual. Este diseño consta a su vez de 2 fases:
- Análisis de requisitos (¿que representamos?): Aquí se busca elaborar un esquema descriptivo del “mundo real” mediante la recolección de datos (sobretodo entrevistas a los futuros usuarios acerca de lo que necesitan)
- Conceptualización (¿cómo representamos?): Aquí vamos refinando el primer esquema descriptivo obtenido del primer esquema descriptivo (refinar la data se podría decir), para conseguir pasar del mundo real al esquema descriptivo y de éste al esquema conceptual, siendo independiente del sistema a implementar.
Para el Diseño lógico, partimos del esquema conceptual, con el cual obtenemos la descripción de nuestra DB que puede procesarse en el sistema. El objetivo central es transformar el esquema conceptual para obtenemos la descripción de nuestra DB adaptándolo al modelo de datos del sistema. Aquí ya tratamos operaciones de consulta y actualización de la data de la DB, obteniendo el esquema lógico. Para esta fase utilizamos el modelo relacional aplicando un proceso denominado NORMALIZACIÓN.
El proceso de normalización consiste en sustituir una relación por un conjunto de esquemas equivalentes, los cuales representan la misma información que la relación de origen, pero no presentan cierto tipo de anomalías a la hora de realizar operaciones sobre ella.
Anomalías: Son todos aquellos aspectos indeseables que pueden presentarse dentro de una relación cuando los atributos que la conforman no son interdependientes entre sí. Tenemos las anomalías por supresión, por inserción y por actualización.
Sin embargo este proceso no cubre toda la fase, por lo que a veces es necesario hacer continuas reestructuraciones de las relaciones.
Esta fase consta de dos etapas:
- Estructuración: Consiste en la estructuración de las relaciones atendiendo a consideraciones de tipo lógico. Esto incluye la normalización como el particionamiento horizontal, vertical o mixto. El objetivo de esta parte es obtener un esquema relacional estructurado, obteniendo un esquema normalizado.
- Reestructuración: Su objetivo es mejorar la eficiencia de la DB, ya que si bien es cierto, en la primera parte obtenemos una representación “real” del mundo real, quizás no cumpla con el objetivo de “ser un servidor operacional y eficiente de datos”.
Para el Diseño físico, partimos del esquema lógico. Aquí se describe las estructuras de almacenamiento, los métodos para acceder a la DB de una manera eficiente, hardware, requisitos de procesos, características del sistema, es decir, cualquier factor cercano al ordenador. Como resultado obtenemos un esquema físico que describe las estructuras de almacenamiento y los métodos de acceso.
EL objetivo primordial es conseguir una instrumentación lo más eficiente posible del esquema lógico. Aquí se busca disminuir tiempos de respuesta (para no aburrirse mientras la pag web se blanquea, o nuestro aplicativo al parecer se cuelga), minimizar espacio de almacenamiento, proporcionar máxima seguridad y optimizar el consumo de servicios (para evitar que se ponga lenta la máquina), entre otros.
Es a partir de la fase del diseño lógico donde aplicamos la arquitectura de 3 capas, ya aquí detallamos los llamados “pantallazos” que usuario va a visualizar (nivel externo) y como va a interactuar (nivel lógico):
Notas:
- Anomalía por supresión: Supresión involuntaria de un atributo al realizar la “supresión” de otro atributo independiente que no debe de ir.
- Anomalía por inserción: Necesidad de inserción de un atributo independiente al momento de realizar la inserción de una ocurrencia nueva del atributo dependiente.
- Anomalía por actualización: Necesidad forzosa de actualizar todas las celdas en las cuales un determinado atributo posee un cierto valor que no ha sido modificado. El simple cambio de valor de uno de los atributos puede dar lugar a una ampliación o reducción del dominio de dicho atributo, dañando la consistencia del resto.
Las principales ideas de este comentario han sido extraidas del libro"Bases de Datos con SQL Server 2000. Transact SQL" de Jorge Moratalla del grupo "EIDOS"
