Colección de citas famosas - Colección de consignas - ¿Por qué al análisis de redundancia le falta una base de datos?

¿Por qué al análisis de redundancia le falta una base de datos?

Análisis de datos

Análisis de datos redundantes de base de datos

Yumoxuan

Causa

Presta mucha atención

0 Me gusta 5681 personas leer

Este es el artículo anterior. Antes me resultaba inconveniente ponerlo en Baidu. Lo detendré hoy para que los lectores puedan ignorar lo que han leído :)

Un tema que debe considerarse en el diseño de bases de datos es la redundancia de datos causada por varias razones, es decir, la misma información. es almacenado por varias personas en la base de datos, sus desventajas son obvias, incluidas las siguientes:

1. Desperdicio de recursos de almacenamiento

2. y espacio reflejado específicamente en operaciones como inserción, modificación y eliminación;

Sin embargo, la existencia de datos redundantes también tiene sus beneficios:

1. p>

2. Mejorar el rendimiento;

La redundancia de datos se refleja en la capa física y la capa de estructura lógica.

La redundancia física de la base de datos se refiere a la redundancia de los recursos de hardware almacenados en la base de datos, mientras que la redundancia lógica se refiere a la redundancia en tablas, registros, campos, valores de atributos, índices y diccionarios de datos. Debido a que la implementación lógica de la base de datos se basa en varios recursos de hardware, la redundancia física afecta el diseño de la estructura lógica de la base de datos y la redundancia de la estructura lógica eventualmente se reflejará en el nivel físico.

Al diseñar una base de datos, las tablas y registros redundantes son muy comunes, como las tablas temporales (a menudo utilizadas para operaciones relacionales complejas) y algunas que se pueden obtener realizando operaciones funcionales sobre datos en otros campos de tablas.

La redundancia de atributos incluye diferentes atributos de tabla y la misma redundancia de atributos de tabla. La redundancia de atributos en diferentes tablas se utiliza a menudo para resolver el problema de establecer relaciones entre tablas. Debe evitarse en la medida de lo posible la redundancia de atributos en la misma tabla.

Para medir la redundancia, la teoría de la normalización divide las relaciones en los siguientes niveles:

Primer paradigma: Sea R un modelo relacional. Si cada valor en el rango de valores de cada atributo A en R es indescomponible, entonces se dice que R pertenece a la primera forma normal, denotada como R ∈ 1NF.

Segunda forma normal: Si la relación R ∈ 1NF, y cada función completa no primaria en R depende de cualquier código candidato, entonces R ∈ 2NF.

Tercera forma normal: si la relación R ∈ 2NF, y cada atributo no primario en R no tiene dependencia funcional transitiva de ningún código candidato, entonces R ∈ 3NF.

Con el paso del tiempo, se propusieron posteriormente el paradigma BCNF, 4NF y 5NF.

Finalmente, se dan los doce principios básicos del diseño de bases de datos relacionales propuestos por E.F. Codd, el padre de las bases de datos relacionales:

1. Estándares de información: Toda la información en una base de datos relacional debe. Representado explícitamente en el nivel lógico con valores en tablas.

2. Garantice los estándares de acceso: asegúrese de que se pueda acceder lógicamente a todos los elementos de datos de la base de datos según el nombre de la tabla, la clave principal y el nombre de la columna.

3. Manejo sistemático de valores nulos: RDBMS admite valores nulos (diferentes de cadenas vacías o cadenas en blanco, y no 0) para representar sistemáticamente la información faltante, independientemente del tipo de datos.

4. Catalogación en línea basada en el modelo relacional: La descripción de la base de datos debe ser lógicamente la misma que la descripción de los datos generales, de modo que los usuarios autorizados puedan consultar la información de descripción de la base de datos utilizando el modelo relacional. Lenguaje utilizado para consultar datos generales.

5. Estándares de sublenguaje razonablemente amplios: un sistema relacional puede tener múltiples idiomas y múltiples modos de uso de terminal (modo de llenado de formularios, modo de comando, etc.). Las declaraciones se pueden expresar como cadenas usando una sintaxis estricta y pueden admitir completamente las siguientes funciones: definición de datos, definición de vistas, manipulación de datos, restricciones completas, autorización y control de transacciones.

6. Estándares de actualización de vistas: el sistema también debe permitir que todas las vistas teóricamente actualizables sean actualizadas.

7. Inserción, actualización y eliminación avanzadas: utilice una relación básica o una relación derivada como objeto de operación para recuperar, insertar, actualizar y eliminar datos.

8. Independencia física de los datos: independientemente de los cambios en la representación del almacenamiento o los métodos de acceso de los datos en la base de datos, las actividades de la aplicación y del terminal deben permanecer lógicamente sin cambios.

9. Independencia lógica de los datos: Las aplicaciones, terminales y actividades de los terminales deben permanecer lógicamente sin cambios cuando se produzcan cambios en las tablas subyacentes que no destruyan la información teórica.

10. Independencia de la integridad de los datos: las restricciones de integridad de una base de datos relacional deben definirse en el sublenguaje de datos y almacenarse en el directorio, no en la aplicación. Se deben admitir al menos las dos restricciones siguientes: integridad de la entidad: los atributos de la clave principal no pueden ser nulos; integridad referencial: para cada valor de código externo no nulo diferente en la base de datos relacional, debe haber un valor de clave principal coincidente del mismo. dominio.

11. Independencia de distribución: RDBMS debe tener independencia de distribución. El usuario no necesita saber si la base de datos está distribuida. (Independientemente de si la base de datos se encuentra parcialmente en un entorno múltiple complejo)

12 Estándar no destructivo: si el RDBMS tiene un lenguaje de bajo nivel, este lenguaje de bajo nivel no puede violar ni eludir los estándares de integridad. y restricciones de fórmulas de expresiones de lenguaje relacional de alto nivel.