DISEÑO DE BASES DE DATOS
1. CONCEPTOS
- Base de Datos.- Cualquier conjunto de datos organizados para su respectivo almacenamiento en la memoria de un ordenador o computador, diseñado para facilitar su mantenimiento y acceso de forma estándar. Los datos suelen aparecer en forma de texto, números o gráficos. Hay cuatro modelos principales de bases de datos: el modelo jerárquico, el modelo en Red, el modelo relacional (el más extendido hoy en día).
- Base de Datos Relacional.- Tipo de base de datos o sistema de administración de bases de datos, que almacena información estrictamente en tablas de valores (filas y columnas de datos) y realiza búsquedas utilizando los datos de columnas especificadas de una tabla para encontrar datos adicionales en otra tabla, en donde todas las operaciones de la base de datos operan sobre estas mismas tablas.
Estas bases de datos, son percibidas por los usuarios como una colección de relaciones normalizadas de diversos grados que varían con el tiempo.
2. MODELO DE DATOS
Es un conjunto de herramientas conceptuales para describir los datos, las relaciones entre ellos, su semántica y sus limitantes.
Clases de Modelos de Datos:
Modelos Lógicos Basados en Objetos.- Son aquellos que nos permiten una definición clara y concisa de los esquemas conceptuales y de visión. Su característica principal es que permiten definir en forma detallada las limitantes de los datos.
Modelos Lógicos Basados en Registros.- Operan sobre niveles conceptuales y de visión. Se caracterizan principalmente porque permiten una descripción más
amplia de la implantación, pero no son capaces de especificar con claridad las limitantes de los datos.
Modelos Físicos de Datos.- Describen los datos en el nivel más bajo y permiten identificar algunos detalles de implantación para el manejo del hardware de almacenamiento.
3. SISTEMAS DE GESTIÓN DE BASES DE DATOS
Arquitectura de Red.- La infraestructura de comunicación por medio de redes.
La red más sencilla es una conexión directa entre dos computadoras. Usando la terminología de redes, una relación es llamada conjunto, y cada conjunto está compuesto por al menos dos tipos de registros:
- Un registro propietario, que es el equivalente al padre en el modelo jerárquico.
- Un registro miembro, equivalente a un registro hijo en el modelo jerárquico.
La diferencia entre el modelo jerárquico y el de red es que este último incluye una condición en la cual un miembro puede aparecer en más de un conjunto. Es decir, un miembro puede tener muchos propietarios.
Lo que distingue a este modelo de los demás es que, en este todos los registros mantienen una interconexión entre si, y también pueden existir relaciones de muchos a muchos.
Arquitectura Jerárquica.- La estructura de base de datos jerárquica puede ser representada como un árbol hacia abajo. El usuario percibe la base de datos como una jerarquía de segmentos. Un segmento, también llamado nodo, es el equivalente al tipo registro de un sistema de archivos, es decir que es una colección de registros que se perciben organizados para conformar la estructura de un árbol. Jerárquicamente, el nivel superior (la raíz) es percibido como el padre del segmento que directamente depende de él. En cambio, los segmentos
abajo de otros segmentos son hijos de los segmentos que se encuentran arriba de ellos. Una de sus características principales es que un segmento padre puede tener varios segmentos hijos. Y al mismo tiempo se dan problemas como la redundancia de información, que es superado por otros modelos.
Arquitectura Relacional.- El gran salto en la administración de bases de datos se produce con el modelo relacional, basado en la proposición de Edgar Codd, en 1970. La proposición del diagrama Entidad-Relación hizo que los diseñadores y programadores prefirieran la implantación de este nuevo modelo. Entendemos al diagrama entidad-relación como una propuesta de ver los datos como objetos del mundo real, diferenciables unos de otros por sus características. Un objeto o entidad es describible por la colección de características que tienen y, a la vez, es diferenciable de otros objetos por las mismas características o atributos.
Entonces, se tiene una serie de entidades que comparten elementos característicos comunes, o un conjunto de entidades. Estos conjuntos de entidades pueden ser ilimitados, pero los atributos que los diferencian son limitables. Actualmente este modelo es el más utilizado en la práctica, esto es debido a la facilidad de entendimiento y de manipulación por parte de diseñadores y administradores.
Para entender este modelo de base de datos hay que tener claros ciertos conceptos sencillos que son importantes a la hora de diseñar la base de datos y sus relaciones.
Entidad: es una persona, cosa o transacción de la cual se puede guardar información. Las entidades, en la fase de diseño (diagrama E-R), llegarán a convertirse posteriormente en las tablas de la base de datos.
Atributos: son las características que se desean almacenar de las entidades.
Relación: una relación es una asociación entre dos entidades.
Conectividad: Se utiliza para clasificar el tipo de relación que une a las dos entidades (uno a uno, un a muchos ó muchos a muchos).
Especifica el número específico de ocurrencias de la entidad asociadas con una ocurrencia de la entidad relacionada.
4. ADMINISTRADOR DE LA BASE DE DATOS (DBA)
El administrador de datos (DA) es la persona identificable que tendrá la responsabilidad central (de gestionar y controlar todas las actividades que tienen que ver con los datos de la empresa y con la base de datos). Ya que los datos son uno de los activos más valiosos de la empresa, es imperativo que exista una persona que los entienda junto con las necesidades de la empresa con respecto a esos datos, a un nivel de administración superior. Por lo tanto, es labor del administrador decidir en primer lugar qué datos deben ser almacenados en la base de datos y establecer políticas para mantener y manejar esos datos una vez almacenados.
El administrador de base de datos (DBA) es el técnico responsable de implementar las decisiones del administrador de datos. Por lo tanto, debe ser un profesional en IT. El trabajo del DBA consiste en crear la base de datos real e implementar los controles técnicos necesarios para hacer cumplir las diversas decisiones de las políticas hechas por el DA. El DBA también es responsable de asegurar que el sistema opere con el rendimiento adecuado y de proporcionar una variedad de otros servicios técnicos.
El administrador de datos juega un papel más importante que el administrador de la base de datos en las siguientes etapas del ciclo de vida: planificación de la base de datos, definición del sistema, recolección y análisis de los requisitos, diseño conceptual y diseño lógico de la base de datos. En el resto de las etapas es donde el administrador de la base de datos tiene el papel más importante:
selección del SGBD, diseño de las aplicaciones, diseño físico, prototipo, implementación, conversión y carga de datos, prueba y mantenimiento.
5. DICCIONARIO DE DATOS
El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD). Es el segundo componente del análisis estructurado. También se conoce como "Data Repository". Incluye el contenido de los data flow (flujos de datos), los "data store", las entidades externas y los procesos.
Data elements (elementos de datos).- Es la parte más pequeña de los datos que tiene significado en el sistema de información. Se combinan varios elementos de datos para hacer los registros o "data structures". Ejemplo:
Nombre, Dirección, Dni.
Las características que se describen en el diccionario de datos son:
Name.- Es el nombre del elemento de datos; debe ser significativo.
Alias.- Cualquier otro nombre que se pueda usar para referirse al elemento de datos. Por ejemplo, el nombre de un elemento de datos puede ser Balance actual, y el alias puede ser Deuda. Solo se incluye el alias si realmente es necesario utilizarlo.
Type y Size.- se refiere a si el elemento de datos contiene valor numérico, caracteres o alfabético. Size o tamaño se refiere al máximo de caracteres o de dígitos que puede tener el elemento de datos.
Formato de salida o mascara de edición.- Indica cómo se presenta el dato al mostrarse en pantalla o al imprimirse en un reporte. Por ejemplo, el número de teléfono del cliente se puede guardar en el disco usando solo números 7878889999, pero presentarse editado en la pantalla o en el reporte (787) 888- 9999.
Default value.- Es el valor que el elemento de datos tiene si no se cambia entrando otro valor.
Prompt, column header or field caption.- Es el nombre que se presenta en la pantalla o el título del dato en el reporte.
Source (fuente).- De dónde se origina el valor del elemento de datos. Puede ser una forma, un departamento, otro sistema, etc.
Security.- Identifica los individuos o departamentos que pueden modificar el elemento de datos. Por ejemplo, la línea de crédito puede ser cambiada por el gerente de crédito.
Responsible user(s).- Identifica el (los) usuarios responsables de entrar o cambiar los valores del elemento de datos.
Acceptable Data and Data validation.- Se especifica el dominio o valores permitidos. Pueden ser valores específicos, una lista de valores, los valores que
se encuentren en otro archivo, etc. El valor puede tener reglas de validación; por ejemplo, el salario debe estar entre lo permitido para la posición que el empleado ocupa.
Derivation formula.- Si el valor es el resultado de un cálculo, se muestra la fórmula que se utiliza.
Description or comments.- Para proveer información adicional, notas o descripciones.
Data Structure (Estructura de datos)
También se conocen como record. Es la combinación de elementos de datos relacionados que se incluye en un flujo de datos o se retiene en un "data store".
Data flows (Flujo de datos) - Las características que se describen en el flujo de datos son:
Name – El nombre del flujo de datos tal y como aparece en el DFD.
Alias – Otro nombre con que se conozca el flujo de datos.
Abbreviation or ID – Código que provee acceso rápido al flujo de datos en un diccionario de datos automatizado.
Description – Describe el flujo de datos y su propósito.
Origin – De donde sale (la fuente) el flujo de datos. Puede ser un proceso, un
“data store” o una entidad.
Destination – El punto final del flujo de datos en el DFD. Puede ser un proceso, un “data store” o una entidad.
Record – Cada flujo de datos representa un grupo de elementos de datos relacionados, o un record. Los records y los flujos de datos se definen por separado para que más de un flujo de datos o “data store” pueda hacer referencia al mismo record.
Volume and frequency – Describe el número esperado de ocurrencias para el flujo de datos por unidad de tiempo.
“Data store” – Las características que se describen en el “data store” son:
Name – El nombre del “data store” según aparece en el DFD.
Alias – Otro nombre con el que se pueda llamar al “data store”.
Abbreviation or ID – Código que provee un acceso rápido al “data store” en un diccionario de datos automatizado.
Description – Describe el “data store” y su propósito.
Input data flows – Los nombres de los flujos de datos que entran al “data store”.
Output data flows – Los nombres de los flujos de datos que salen del “data store”.
Record – El nombre del record en el diccionario de datos para el “data store”.
Volume and Frequency – El número estimado de records guardados en el “data store”, al igual que el aumento o cambio esperado.
Proceso – Se documenta cada función primitiva. Se incluye:
Process name or label – El nombre del proceso como aparece en el DFD.
Purpose or description – Un resumen del propósito general del proceso. Los detalles se documentan en el Process Description.
Process number – Número de referencia que identifica el proceso y su relación con los niveles del sistema.
Input data flows – Los nombres de los flujos de datos que entran al proceso.
Output data flows – Los nombres de los flujos de datos que salen del proceso.
Process Description – Se explican los detalles del proceso.
Entidades Externas – Las características que se describen son:
Name Alias
Description – Describe a la entidad y su propósito.
Input data flow Output data flow
Record (Registro) – Se describe lo siguiente:
Record name Alias
Description
Record content or composition – Una lista de todos los elementos de datos incluidos en el record. Se identifica cualquier “LLAVE” primaria, o sea un elemento de datos en el record que identifica en forma única al record.
DISEÑO LOGICO DE BASE DE DATOS
El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se va a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use de modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones.
Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos.
En un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional.
Metodología de diseño lógico en el modelo relacional
La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.
1. Convertir los esquemas conceptuales locales en esquemas lógicos locales
En este paso, se eliminan de cada esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente:
(a) Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una nueva entidad intermedia y dos relaciones de uno a muchos de esta nueva entidad con las entidades originales. La nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales.
(b) Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de
las entidades originales. La cardinalidad de estas nuevas relaciones binarias dependerá de su significado.
(c) Eliminar las relaciones recursivas, sustituyendo cada una de ellas por una nueva entidad (débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La cardinalidad de estas relaciones dependerá de su significado.
(d) Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales. La cardinalidad de estas relaciones dependerá del tipo de la relación original y de su significado.
(e) Eliminar los atributos multievaluados, sustituyendo cada uno de ellos por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original.
(f) Revisar las relaciones de uno a uno, ya que es posible que se hayan identificado dos entidades que representen el mismo objeto (sinónimos). Si así fuera, ambas entidades deben integrarse en una sola.
(g) Eliminar las relaciones redundantes. Una relación es redundante cuando se puede obtener la misma información que ella aporta mediante otras relaciones. El hecho de que haya dos caminos diferentes entre dos entidades no implica que uno de los caminos corresponda a una relación redundante, eso dependerá del significado de cada relación.
Una vez finalizado este paso, es más correcto referirse a los esquemas conceptuales locales refinados como esquemas lógicos locales, ya que se adaptan al modelo de base de datos que soporta el SGBD escogido.
2. Derivar un conjunto de relaciones (tablas) para cada esquema lógico local
En este paso, se obtiene un conjunto de relaciones (tablas) para cada uno de los esquemas lógicos locales en donde se representen las entidades y relaciones entre entidades, que se describen en cada una de las vistas que los usuarios tienen de la empresa. Cada relación de la base de datos tendrá un nombre, y el
nombre de sus atributos aparecerá, a continuación, entre paréntesis. El atributo o atributos que forman la clave primaria se subrayan. Las claves ajenas, mecanismo que se utiliza para representar las relaciones entre entidades en el modelo relacional, se especifican aparte indicando la relación (tabla) a la que hacen referencia.
A continuación, se describe cómo las relaciones (tablas) del modelo relacional representan las entidades y relaciones que pueden aparecer en los esquemas lógicos.
(a) Entidades fuertes. Crear una relación para cada entidad fuerte que incluya todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes.
Cada uno de los identificadores de la entidad será una clave candidata. De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas. Para escoger la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:
- Escoger la clave candidata que tenga menos atributos.
- Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro.
- Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en el futuro.
- Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto).
- Escoger la clave candidata más fácil de utilizar desde el punto de vista de los usuarios.
(b) Entidades débiles. Crear una relación para cada entidad débil incluyendo todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes. Añadir una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de la relación que representa a la entidad padre en la nueva relación creada para la entidad débil. A continuación, determinar la clave primaria de la nueva relación.
