Bases de Datos (11/12/2020)

 Continuación Unidad 3

En la clase de hoy hemos continuado con el tema 3, sobre el modelo relacional, haciendo un breve repaso de lo visto en la última clase y comenzando con la arquitectura de ANSI-SPARC y los gestores relacionales. 

Se ha visto las diferencias entre el Modelo Relacional (MR) y el ANSI. Aunque el MR se adapta a ANSI, hay algunas excepciones como: 

En MR se permite a un usuario acceder a las relaciones base y las vistas si tiene las autorizaciones. En ANSI el usuario está restringido a la parte externa de la base de datos. En MR no se pueden actualizar todas las vistas, al contrario que en ANSI. Muchas SGBD relacionales no responden a la arquitectura a tres niveles.

A continuación se ha hecho un repaso de como acceder a la máquina virtual, con el servidor debian, a la vez que accedíamos al sistema gestor de bases de datos, en nuestro caso HeidiSQL. A través de este SGBD, donde habíamos creado una base de datos, hemos creado a modo de ejemplo una columna con alguna fila con datos. También se ha repasado de forma similar con otro SGBD que se utilizará, MySQL Workbench.

Después se ha visto las 12 reglas de Codd:

Regla genérica: Un SGBD relacional debe emplear sus facilidades relacionales para gestionar la base de datos. de aquí surgen las 12 reglas:

1. Representación de la información: toda información es representada de forma explícita y única a nivel lógico, con valores en tablas, columnas y filas.
2. Acceso garantizado: todo dato debe ser accesible mediante una combinación de tabla, valor de su clave y nombre de columna.
3. Tratamiento sistemático de valores nulos: debe soportar la representación y manipulación de información desconocida y/o no aplicable.
4. Catálogo en línea: la descripción se debe representar en el nivel lógico, igual que los ordinarios, para los usuarios autorizados.
5. Sublenguaje de datos completos: debe soportar al menos un lenguaje relacional (con sintaxis lineal, usado interactivamente o embebido y con soporte para operaciones de tipo manipulación de datos, definición de datos, etc.).
6. Actualización de vistas: vistas actualizables deben serlo en la práctica.
7. Inserción, modificación y borrado de tuplas de alto nivel: operaciones de manipulación de datos operan sobre conjuntos de filas.
8. Independencia física de los datos: cambios en el acceso físico o almacenamiento no debe afectar al acceso lógico.
9. Independencia lógica de los datos: programas de aplicación no deben ser afectados por cambios en tablas que preservan la integridad.
10. Independencia de la integridad: deben estar separadas de los programas, almacenados en el catálogo de la BD para su edición.
11. Independencia de la distribución: las aplicaciones no deben estar afectadas al distribuir o cambiar la distribución de la Base de Datos.
12. Reglas de no subversión: si es interfaz de bajo nivel, no puede usarse para saltarse las reglas de integridad y las restricciones expresadas por un lenguaje de nivel superior.

Se ha visto las fases de diseño de una base de datos: análisis de requisitos, diseño conceptual, diseño lógico y diseño físico, carga de datos y pruebas y operación.

Están clasificados los modelos de datos entre conceptuales y lógicos.

Por último, se ha tratado las herramientas tipo CASE. Estas ayudan al programador o analista en el diseño conceptual para pasar al lógico o físico, ejemplos como Visio, Oracle designer, EasyCase, etc. Estas herramientas permiten el diseño del modelo de datos conceptual siguiendo las anteriores técnicas, normalmente ER o UML, para obtener el esquema lógico relacional, escrito en SQL estándar o físico. Las herramientas CASE ayudan al diseño, reducen el tiempo de desarrollo, mantenimiento del esquema de datos, reducen el tiempo de la documentación y facilitan la portabilidad a otros gestores.