MODELOS DE BASE DE DATOS

DICCIONARIO DE DATOS

El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema.

El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades.

Define con precisión los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc.Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos , los diagramas e untidad-relación, etc. 

Características Un diccionario de datos contiene las características lógicas de los datos que se van a utilizar en un sistema, incluyendo nombre, descripción, alias, contenido y organización. El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD (Diagrama de flujo de datos), en una especificación del proceso y en el propio diccionario de datos.

3. Objetivo El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades. Estos diccionarios se desarrollan durante el análisis de flujo de datos y su contenido también se emplea durante el diseño del proyecto en general.

4. ¿Para qué sirve? Describe el significado de los flujos y almacenes que se muestran en los DFD. Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos (los que no se pueden descomponer en unidades más elementales). Describe la composición de los paquetes de datos en los almacenes. Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.

5. Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama entidad- relación Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema. Además de esto, su contenido también se emplea durante el diseño. ¿Para qué sirve?

6. Tipos de Diccionarios Existen tres tipos de diccionarios de datos: Diccionario Off-LineDiccionario Off-Line Diccionario On-LineDiccionario On-Line Diccionario In-LineDiccionario In-Line

7. Diccionario Off-Line • Se ocupa de mantener el diccionario en condiciones. • No tiene injerencia en el uso dinámico de los datos.

8. Diccionario On-Line •Trabaja junto con el compilador. • Impide que el programador defina los datos en el programa y los toma directamente del diccionario. • Verifica que los datos nombrados existan en el diccionario. • Incorpora al programa, desde el diccionario la definición de los datos. • Inconveniente: si uno se olvida de recompilar, estarán conviviendo datos en la correcta versión actual con otros en una versión superada.

9. Diccionario In-Line • No incorpora la definición de datos en el programa, sino que las carga cuando se ejecuta.

10. Notación del Diccionario de datos

11. Ejemplos

12. Definiciones de datos Una definición de un dato se introduce mediante el símbolo “=”; en este contexto el “=” se lee como “está definido por”, o “está compuesto de”, o “significa”. Para definir un dato completamente, la definición debe incluir: El significado del dato en el contexto de la aplicación. Esto se documenta en forma de comentario. La composición del dato, si es que está compuesto de otros elementos significativos. Los valores que el dato puede tomar, si se trata de un dato elemental que ya no puede ser descompuesto.

13. Ejemplo A=B+C Cuando digamos A, queremos decir una B y una C. A se define de B y C. Peso=*peso del paciente al ser admitido al hospital* *unidades: kilogramos; gama 1-200* Estatura=*estatura del paciente al ser admitido al hospital* *unidades: centímetros; escala 20-200*

14. Contenido En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son:  Datos elementalesDatos elementales  Flujo de datosFlujo de datos  Almacenes de datosAlmacenes de datos  ProcesosProcesos Entidades externasEntidades externas El diccionario de datos guarda los detalles y descripción de todos estos elementos.

15. Datos elementalesDatos elementales Son aquellos para los cuales no hay una descomposición significativa. Es decir, 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 records o "data structures". EJEMPLOS:EJEMPLOS: • Nombre • Dirección • Seguro social

16. Cuando se han identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripción acerca del significado del dato. EJEMPLOS:EJEMPLOS:  Peso = * peso del paciente al ingresar al hospital, unidad: kilo, rango: 2-150 *  Altura = * unidad: cm., rango: 100-200 *  Sexo = * valores: [F|M] * Calificación= ** ** Significa “sin comentarios”.

17. Descripción de los Datos en el diccionario Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada articulo se identifica por:  Nombre de datoNombre de dato  Descripción del datoDescripción del dato  Sinónimo o aliasSinónimo o alias  Longitud de campoLongitud de campo  Valores de datosValores de datos Cabe mencionar que cada uno tiene valores específicos que se permiten para éste en el sistema estudiado.

18. Nombre de dato Para distinguir un dato de otro, los analista les asigna nombre significativos que se utilizan para tener una referencia de cada elemento a través del proceso total de desarrollo de sistemas. Es importante que se seleccione con cuidado, es decir, en forma significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es más significativa si se llama FECHA FACTURA que si se le conoce como Dato1.

19. Descripción del dato Establece brevemente lo que representa el dato en el sistema; por ejemplo, la descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está preparando la misma (no la fecha en la que fue recibida o enviada la factura, etc.) Es importante que las descripciones se escriban suponiendo que la gente que los lea no conoce nada en relación del sistema. Por lo tanto deben evitarse términos especiales, para que todas las palabras sean entendibles para el lector.

20. Sinónimo o alias Con frecuencia el mismo dato puede conocerse con diferentes nombres, dependiendo de quien lo utilice. El uso de los alias deben evitar confusión. Un diccionario de dato significativo incluirá todos los alias posibles para un dato. Es una alternativa de nombre para un campo. Estos datos deben usarse solo para el nombre primario del dato, para minimizar las redundancias. Comprador=*alias de cliente*

21. Longitud de campo Cuando las características del diseño del sistema se ejecuten más tarde en el proceso de desarrollo del sistemas, será importante conocer la cantidad de espacio que necesita para cada dato. EJEMPLO:EJEMPLO: Nombre= *Máx. 50 caracteres*

22. Valores de datos En algunos procesos solo se permiten valores de datos específicos. Por ejemplo, en muchas compañías con frecuencia los números de orden de compra se proporcionan con un prefijo de una letra para indicar el departamento del origen. Éstos no son usados siempre, sino que se especifican en caso necesario. EJEMPLO:EJEMPLO: Artículo= departamento+ artículo *valores de departamentos: [ D2 | B3 | C4 ]*[ D2 | B3 | C4 ]*

23. Iteración Se usa para indicar ocurrencias repetidas de un componente en un elemento compuesto. Se lee como “cero o más ocurrencias de...” EJEMPLO:EJEMPLO: Orden-de compra = nombre-cliente + dirección-de-Orden-de compra = nombre-cliente + dirección-de- envío + {artículo}envío + {artículo} significa que una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y cero o más ocurrencias de un artículo.

24. En muchas situaciones reales es preferible especificar límites inferior y superior de iteración para evitar problemas. EJEMPLO:EJEMPLO: Orden-de compra = nombre-cliente + dirección-de-Orden-de compra = nombre-cliente + dirección-de- envío + 1{artículo}10envío + 1{artículo}10 Cabe mencionar que es correcto especificar solo el límite inferior, superior, ambos o ninguno. Esto dependerá de las necesidades particulares del sistema desarrollado. Límites de la iteración

25. Datos opcionales Un dato opcional es aquel que puede o no estar presente como componente de un dato compuesto. Ejemplo: Dirección = calle + número + (ciudad) + (país) +Dirección = calle + número + (ciudad) + (país) + (código-postal)(código-postal)

26. Selección Indica que un elemento consiste de exactamente una opción de un conjunto de alternativas. Ejemplos: Sexo = [ Femenino | Masculino ]Sexo = [ Femenino | Masculino ] Tipo-de-cliente = [ Gubernamental | Académico |Tipo-de-cliente = [ Gubernamental | Académico | Industria | Otros ]Industria | Otros ]

27. Flujo de datosFlujo 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.

28. Flujo de datosFlujo de datos 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.

29. Almacenes de datosAlmacenes de datos Las características que se describen en el almacén de datos o “data store” son:  Name – El nombre del “data store” según aparece en el DFD.  Alias – Otro nombre para 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 DD para el “data store”.  Volume and Frequency – El número estimado de records guardados en el “data store”,(el aumento o cambio esperado).

30. ProcesosProcesos 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.

31. Entidades externasEntidades 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

32. Fragmento de un Diccionario deFragmento de un Diccionario de DatosDatos

Ingeniería del Software - Diccionario de Datos - Raquel Martínez

 

Tiposde modelos de bases de datos

1. Hay muchos tipos de modelos de bases de datos. Algunos de los más comunes incluyen:
   • Modelo de base de datos jerárquico
   • Modelo relacional
   • Modelo de red
   • Modelo de base de datos orientado a objetos
   • Modelo entidad-relación
   • Modelo de documentos
   • Modelo entidad-atributo-valor
   • Esquema de estrella
   • Modelo relacional de objetos, que combina los dos que forman su nombre
   Puedes elegir describir una base de datos con cualquiera de ellos dependiendo de varios factores. El mayor factor es si el sistema de gestión de bases de datos que estás usando es compatible con un modelo en particular. La mayoría de los sistemas de gestión de bases de datos están desarrollados con un modelo de datos particular en mente y requieren que los usuarios adopten ese modelo, aunque algunos son compatibles con múltiples modelos.
   Además, diferentes modelos aplican a diferentes etapas del proceso de diseño de bases de datos. Los modelos de datos conceptuales de alto nivel son mejores para crear mapas de relaciones entre datos en las formas en que la gente percibe esos datos. Por otro lado, los modelos lógicos basados en registros reflejan más estrechamente las formas en que los datos se almacenan en el servidor.
   La elección de un modelo de datos también depende de que alinees tus prioridades con las fortalezas de la base de datos de un modelo en particular, ya sea que esas prioridades incluyan velocidad, reducción de costos, usabilidad o algo más.
   Demos un vistazo detallado a algunos de los modelos de bases de datos más comunes.

Modelo relacional

1. Siendo el modelo más común, el modelo relacional ordena los datos en tablas, también conocidas como relaciones, cada una de las cuales se compone de columnas y filas. Cada columna enumera un atributo de la entidad en cuestión, por ejemplo, precio, código postal o fecha de nacimiento. En conjunto, a los atributos en una relación se los llama dominio. Se elige un atributo particular o combinación de atributos como clave primaria, a la cual se puede hacer referencia en otras tablas, en donde se la denomina clave externa.
   Cada fila, también denominada tupla, incluye datos sobre una instancia específica de la entidad en cuestión, por ejemplo, un empleado específico.
   El modelo también representa los tipos de relaciones entre esas tablas, incluidas las relaciones uno a uno, uno a muchos y muchos a muchos. Este es un ejemplo:
2. 

   
   

Modelo jerárquico

1. El modelo jerárquico organiza los datos en una estructura de árbol, en la que cada registro tiene un único elemento o raíz. Los registros del mismo nivel se clasifican en un orden específico. Ese orden se usa a manera de orden físico para almacenar la base de datos. El modelo es bueno para describir muchas relaciones del mundo real.
2. 
   
3. 
   

   

   
   

Modelo de red

1. El modelo de red se basa en el modelo jerárquico, permitiendo relaciones de muchos a muchos entre registros vinculados, lo que implica registros principales múltiples. Basado en la teoría matemática de conjuntos, el modelo se construye con conjuntos de registros relacionados. Cada conjunto consiste de un registro propietario o principal y uno o más registros miembros o secundarios. Un registro puede ser miembro o secundario en múltiples conjuntos, permitiendo que este modelo represente relaciones complejas.

   Fue muy popular en la década de 1970 después de que fue definido formalmente por la Conference on Data Systems Languages (CODASYL).
2. 

Modelo de base de datos orientado a objetos

1. Este modelo define una base de datos como una colección de objetos, o elementos de software reutilizables, con funciones y métodos relacionados. Hay varios tipos de bases de datos orientadas a objetos:

   Una base de datos multimedia incorpora elementos multimedia, tales como imágenes, que no se podrían almacenar en una base de datos relacional.

   Una base de datos de hipertexto permite que cualquier objeto se conecte a cualquier otro objeto. Es útil para organizar lotes de datos disímiles, pero no es ideal para análisis numérico.

   El modelo de base de datos orientado a objetos es el mejor modelo conocido de base de datos posrelacional ya que incorpora tablas, pero no se limita a ellas. A dichos modelos también se los conoce como modelos de base de datos híbridos.

   

Modelo relacional de objetos

1. Este modelo de base de datos híbrido combina la sencillez del modelo relacional con parte de la funcionalidad avanzada del modelo de base de datos orientado a objetos. En esencia, permite a los diseñadores incorporar objetos en una estructura familiar de tablas.

   Entre los idiomas e interfaces de llamada se incluyen SQL3, lenguajes de proveedores, ODBC, JDBC e interfaces de llamada patentadas que son extensiones de lenguajes e interfaces usadas por el modelo relacional.

Modelo entidad-relación

1. Este modelo capta las relaciones entre entidades del mundo real de forma muy similar al modelo de red, pero no está directamente ligado a una estructura física de la base de datos. En cambio, con frecuencia se lo usa para diseñar una base de datos conceptualmente.

   Aquí, a las personas, lugares y cosas, acerca de las cuales se almacenan puntos de datos, se las denomina entidades, cada una de las cuales tiene ciertos atributos que en conjunto forman su dominio. La cardinalidad, o relaciones entre entidades, también se representa en diagramas.

   

   Una forma común del diagrama entidad-relación ER es el esquema de estrella, en el cual una tabla central de información se conecta a múltiples tablas dimensionales.

Otros modelos de bases de datos

1. Otros diversos modelos de bases de datos se han usado y siguen usándose en la actualidad.

Modelo de archivo invertido

1. Una base de datos construida con estructura de archivo invertido se diseña para facilitar búsquedas rápidas de texto completo. En este modelo, el contenido de datos se indexa como una serie de claves en una tabla de búsqueda, donde los valores indican la ubicación de los archivos asociados. Esta estructura puede proporcionar un informe casi instantáneo de, por ejemplo, datos masivos y análisis estadístico.

   Este modelo ha sido usado por el sistema de gestión de bases de datos ADABAS de Software AG desde 1970, y se sigue utilizando en la actualidad.

Modelo plano

1. El modelo plano es el modelo de datos más antiguo y más sencillo. Simplemente presenta todos los datos en una sola tabla, que consiste de columnas y filas. Para acceder a los datos o manipularlos, la computadora tiene que leer todo el archivo plano y traerlo a la memoria, lo que vuelve a este modelo ineficiente para todo, excepto para los conjuntos de datos más pequeños.

Modelo multidimensional

1. Esta es una variación del modelo relacional diseñado para facilitar un mejor procesamiento analítico. Aunque el modelo relacional está optimizado para procesamiento de transacciones en línea (OLTP), este modelo está diseñado para procesamiento analítico en línea (OLAP).

   Cada celda de una base de datos dimensional contiene datos acerca de las dimensiones registradas por la base de datos. Visualmente, es como una colección de cubos, en lugar de tablas bidimensionales.

Modelo semiestructurado

1. En este modelo, los datos estructurales comúnmente contenidos en el esquema de la base de datos están incrustados con los datos mismos. Aquí la diferencia entre los datos y el esquema es imprecisa en el mejor de los casos. Este modelo es útil para describir sistemas, tales como ciertas fuentes de datos basadas en web, las cuales tratamos como bases de datos, pero que no podemos limitar con un esquema. También es útil para describir interacciones entre bases de datos que no se apegan al mismo esquema.

Modelo de contexto

1. Este modelo puede incorporar elementos de otros modelos de bases de datos, según sea necesario. Improvisa elementos de modelos orientados a objetos, semiestructurados y de red.

Modelo asociativo

1. Este modelo divide todos los puntos de datos en base a si describen una entidad o una asociación. En este modelo, una entidad es todo lo que existe de manera independiente, mientras que una asociación es algo que solo existe en relación a algo más.

   El modelo asociativo estructura los datos en dos grupos:

   • Un grupo de elementos, cada uno con un identificador único, un nombre y un tipo.
   • Un grupo de enlaces, cada uno con un identificador único y los identificadores únicos de una fuente, verbo u objetivo. La información almacenada tiene que ver con la fuente y cada uno de los tres identificadores pueden hacer referencia ya sea a un enlace o a un elemento.

   Otros modelos menos comunes de bases de datos incluyen:

   • Modelo semántico, el cual incluye información acerca de cómo los datos almacenados se relacionan con el mundo real.
   • Base de datos XML, la cual permite que los datos sean especificados e incluso almacenados en formato XML.
   • Gráfico etiquetado.
   • Triplestore.

Modelos de bases de datos NoSQL

1. Además del modelo de base de datos de objetos, otros modelos distintos al tipo SQL han surgido en contraste con el modelo relacional:

   El modelo de base de datos gráfico, el cual es aún más flexible que el modelo de red, permitiendo que cualquier nodo se conecte a cualquier otro.

   El modelo multivalor, el cual se desprende del modelo relacional, permitiendo que los atributos contengan una lista de datos en lugar de un solo punto de datos.

   El modelo de documentos, el cual se diseña para almacenar y administrar documentos o datos semiestructurados, en lugar de datos atómicos.

Bases de datos en la web

1. La mayoría de los sitios web dependen de cierto tipo de base de datos para organizar y presentar datos a los usuarios. Cada vez que alguien usa las funciones de búsqueda en estos sitios, sus términos de búsqueda son convertidos en consultas para que un servidor de bases de datos los procese. Generalmente, programas intermedios conectan el servidor web con la base de datos.

   La amplia presencia de las bases de datos les permite ser usadas casi en cualquier campo, desde compras en línea hasta el enfoque detallado en un segmento de votantes como parte de una campaña política. Diversas industrias han desarrollado sus propias normas para el diseño de bases de datos, desde el transporte aéreo hasta la manufactura de vehículos.
2. Video algunos modelos de base de datos

Modelos de base de datos YerelinG

1.