1. Arquitectura de la base de datos
1.1. Arquitectura ANSI / SPARC
1.1.1. La arquitectura ANSI / SPARC se divide en 3 niveles denominados: 1. EL NIVEL INTERNO: Es el más cercano al almacenamiento físico. Es el que se ocupa de la forma como se almacenan físicamente los datos. (DBA). 2. EL NIVEL EXTERNO: Es el más cercano a los usuarios, es decir, es el que se ocupa de la forma como los usuarios individuales perciben los datos. REPRESENTACIONES, PUEDE HACER TANTAS VISIONES COMO USUARIOS PUEDA TENER UNA BD. (N. VISIÓN) 3. EL NIVEL CONCEPTUAL: Es un nivel de mediación entre los otros dos. (TRABAJA DEFINIENDO ESTRUCTURAS DE ALMACENAMIENTO EL DBA).
1.1.1.1. Nivel Interno
1.1.1.1.1. Es una descripción de la base datos en términos de su almacenamiento físico mediante un esquema interno. Es una representación de bajo nivel de toda la base de datos y consiste en muchas ocurrencias de cada uno de los tipos de registros internos. Se describe por medio del esquema interno, define los diferentes tipos de registros almacenados, especifica que tipos de índices existen, como están representados los campos almacenados, en que secuencia están dichos registros.
1.1.1.2. Nivel Conceptual
1.1.1.2.1. Es una representación de todo el contenido de la información de la BD. Pretende ser una vista de los datos tal como son. Se describe la estructura de toda la base de datos para un sistema de información o la parte de él a tratar mediante un esquema conceptual. Este esquema oculta los detalles físicos de almacenamiento y se centra en la estructura organizacional de los datos obtenida al reunir los requerimientos de todos los usuarios, es decir, se centra en elementos lógicos para describir entidades, atributos, relaciones, operaciones de los usuarios y restricciones con independencia del SGBD y de la máquina. (Esquema global).
1.1.1.3. Nivel Externo
1.1.1.3.1. Es el nivel del usuario individual (programador de aplicaciones, usuario final). Cada uno tiene un lenguaje. Estos lenguajes incluirán un sublenguajede datos (SLD). El sublenguajede datos está incrustado dentro de un lenguaje anfitrión. Si no son distintos y difícilmente pueden distinguirse decimos que están fuertemente acoplados; si son claras y fácilmente separables, decimos que está débilmente acoplados. Cualquier sublenguaje de datos es una combinación de por lo menos 2 lenguajes subordinados: un DDL(lenguaje de definición de datos) y un DML(lenguaje de manipulación de datos).
2. Diseño físico de bases de datos
2.1. Conceptualmente, podemos definir el diseño físico de una base de datos como un proceso que, a partir de su diseño lógico y de información sobre su uso esperado, creará una configuración física de la base de datos adaptada al entorno donde se alojará y que permita el almacenamiento y la explotación de los datos de la base de datos con un rendimiento adecuado.
2.2. Elementos de diseño físico
2.2.1. Los elementos ofrecidos por el SGBD para afinar el modelo físico de la base de datos son principalmente los siguientes: • Espacios para tablas • Índices • Vistas materializadas • Particiones
2.2.2. Espacios para tablas
2.2.2.1. Un espacio para tablas, tablespace en inglés, es un componente del SGBD que indica dónde se almacenarán los datos de la base de datos y en qué formato. El espacio para tablas permite asociar un fichero físico a un conjunto de elementos de la base de datos (tablas, índices, etc.). Dicho fichero contendrá los datos correspondientes a los elementos de la base de datos asociados.
2.2.3. Índices
2.2.3.1. Los índices son estructuras de datos que permiten mejorar el tiempo de respuesta de las consultas sobre los datos de una tabla. Los índices mantienen los valores de una o más columnas de una tabla en una estructura que permite el acceso a las filas de la tabla. Cada posible valor v tiene correspondencia con la dirección (o direcciones) física que contiene las filas de la tabla que tienen a v como valor de la columna indexada.
2.2.4. Vistas materializadas
2.2.4.1. Los resultados de las consultas sobre una o más tablas se pueden almacenar en vistas materializadas. A diferencia de las vistas convencionales, el conjunto de filas que conforma el contenido de una vista materializada se almacena físicamente en la base de datos, como las filas que conforman el contenido de una tabla.
2.2.5. Particiones
2.2.5.1. Las particiones permiten distribuir los datos de una tabla en distintos espacios físicos. Las particiones se pueden hacer de acuerdo a multitud de criterios: distribuyendo las filas de la tabla en función de los valores de una columna, o de un conjunto de ellas (fragmentación horizontal), distribuyendo los datos de las filas de una tabla entre distintos espacios en función de las columnas a las que pertenecen (fragmentación vertical), e incluso agrupando datos con características comunes, como es el caso de la distribución de los datos agrupados por dimensiones en los data warehouse.
3. Bibliografia
3.1. Cabello, M. V. (2010). Introducción a las Bases de Datos relacionales. Madrid: Vision Libros. Caralt, J. C., & Rodríguez Gonzáles, M. E. (s.f.). Diseño Físico de Base de Datos. Cobo, A. (2014). Diseño y programación de bases de datos. Madrid: Vision Libros. Date, C. (2001). Introducción a los sistemas de Base de Datos 7ma Edición. Mexico: Pearson Educación. Hansen, G., & Hansen, J. (1997). Diseño y administración de bases de datos. Madrid: Prentice Hall. Mannino, M. V. (2007). Administración de bases de datos Diseño y desarrollo de aplicaciones Tercera edición. Mexico: McGraw Hill Interamericana. Rodríguez, D. R., Chirino, R. R., & Valdés, B. C. (2017). Implementación de una Base de Datos Relacional para la Aplicación BEHIQUE SIC. Scielo. Silberschatz, A., Korth, H. F., & Sudarshan. (2002). Fundamentos de base de datos Cuarta Edición. Madrid: McGraw Hill Interamericana. Tecnologías Información . (s.f.). Obtenido de Modelos de datos: Modelo Conceptual, Físico y Lógico
4. Fases de Diseño
4.1. Video
4.2. Análisis de Requerimientos:
4.2.1. Descripción operacional en un lenguaje natural; se realiza la fase de adquisición de conocimiento: • Entrevista con los usuarios del sistema. • Identifica necesidades. • Asegurar que se tenga los datos necesarios para las funciones y aplicaciones donde se usará la base de datos. La salida son los requerimientos del sistema.
4.3. Diseño Conceptual:
4.3.1. Trata de reflejar cómo son los datos, de manera participativa y con refinamientos sucesivos a través de la interacción de los diseñadores y usuarios del sistema. Intenta crear un Modelo Parcial del Universo donde se trata de capturar lo suficiente para poder soportar todas las funciones a las que servirá el sistema final. Identifica entidades y sus relaciones. La salida es un esquema de la base de datos utilizando el modelo Entidad/Relación.
4.4. Diseño Lógico:
4.4.1. Diseño que se acerca más a la implementación en un Sistema manejador de Base de Datos. Transforma el modelo Entidad-Relación en tablas que podrán ser implementadas en un sistema manejador de base de datos en particular. El modelo que se puede usar es el ELKA (EntityLink Key Attribute).
4.5. Normalización:
4.5.1. Elimina ciertas anomalías debidas a la redundancia y diversos defectos del diseño.
4.6. Diseño Físico:
4.6.1. Decide la estructura de almacenamiento y las estrategias de acceso: •Estructura de almacenamiento: como almacenar los datos, archivos planos, comprimidos, codificados, formatos espcíficos. •Estrategia de acceso: acceso secuencial, acceso binario. •Selecciona los tipos de datos.
4.7. Optimización:
4.7.1. Según el criterio de almacenamiento interno, como el espacio en disco y el tiempo medio de acceso.