INTRODUCCIÓN DE LUCIDCHART

 

¿QUÉ ES LUCIDCHART?

DEFINICIÓN:

Lucidchart es una herramienta de diagramación basada en la web, que permite a los usuarios colaborar y trabajar juntos en tiempo real, creando diagramas de flujo, organigramas, esquemas de sitios web, diseños UML, mapas mentales, prototipos de software y muchos otros tipos de diagrama. Construida con estándares web, como HTML5 y JavaScript, Lucidchart funciona en todos los navegadores web modernos, como Google Chrome, Firefox, Safari e Internet Explorer 8+.

Características del producto

Lucidchart utiliza una interfaz de arrastrar-y-soltar y capacidades de colaboración en tiempo real.11​ Sumado a su capacidad de funcionar en los principales sistemas operativos, como Microsoft Windows, Mac OS X y Linux, Lucidchart también es funcional en iPad, a través de una aplicación especialmente optimizada para esta plataforma.

Basado en la nube

Lucidchart está basado en la nube, con lo que no necesita descargas ni actualizaciones de software. El trabajo se guarda automáticamente en la nube y múltiples usuarios pueden trabajar simultáneamente en un mismo documento, de manera similar al funcionamiento de Google Drive.

Colaboración

Lucidchart utiliza una variedad de funcionalidades colaborativas, incluyendo chat integrado en el editor, comentarios y video chat y colaboración en tiempo real con otros editores.12​

Opciones de publicación de documentos

Lucidchart también permite publicar los diagramas en la web y compartirlos con otros vía correo electrónico, generando un enlace.13​

Lucidchart permite la impresión de PDF vectoriales así como también imágenes rasterizadas en formatos JPG y PNG.

Librería de formas

Lucidchart cuenta con una gran colección de librerías de formas estándar. Estas librerías incluyen formas y plantillas para:

 

©      Diagramas de Flujo14​

©      Diagramas de Red15​

©      Modelos y Notación de Procesos de Negocio16​

©      Diagramas de Circuitos

©      Planos

©      Lenguaje Unificado de Modelado17​

©      Bocetos

©      Futuro novato.

©      Esquemas

©      Mapas Mentales

©      Mapas Conceptuales18​

©      Organigramas19​

©      Modelos de Entidad-Relación20​

©      Diagramas de Ven

©      La librería de formas para Diagramas de flujo, es la más popular en términos de uso.

INTEGRIDAD REFERENCIAL

 

INTEGRIDAD REFERENCIAL EN BASE DE DATOS.

DEFINICIÓN:

La integridad referencial es propiedad de la base de datos. La misma significa que la clave externa de una tabla de referencia siempre debe aludir a una fila válida de la tabla a la que se haga referencia. La integridad referencial garantiza que la relación entre dos tablas permanezca sincronizada durante las operaciones de actualización y eliminación.

Todas las bases de datos relacionales gozan de esta propiedad gracias a que el software gestor de base de datos vela por su cumplimiento. En cambio, las bases de datos jerárquicas requieren que los programadores se aseguren de mantener tal propiedad en sus programas.

Existen tres tipos de integridad referencial:

©      Integridad referencial débil: si en una tupla de R todos los valores de los atributos de K tienen un valor que no es el nulo, entonces debe existir una tupla en S que tome esos mismos valores en los atributos de J;

©      Integridad referencial parcial: si en una tupla de R algún atributo de K toma el valor nulo, entonces debe existir una tupla en S que tome en los atributos de J los mismos valores que los atributos de K con valor no nulo; y

©      Integridad referencial completa: en una tupla de R todos los atributos de K deben tener el valor nulo o bien todos tienen un valor que no es el nulo y entonces debe existir una tupla en S que tome en los atributos de J los mismos valores que toman los de K.

Tipos de relaciones

Entre dos tablas de cualquier base de datos relacional pueden haber dos tipos de relaciones, relaciones uno a uno y relaciones uno a muchos:

 Relación Uno a Uno:

 Cuando un registro de una tabla sólo puede estar relacionado con un único registro de la otra tabla y viceversa.

Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qué profesor es jefe de qué departamento, tenemos una relación uno a uno entre las dos tablas ya que un departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento.

 Relación Uno a Varios:

 Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener más de un registro relacionado en la tabla secundaria, en este caso se suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla secundaria como tabla 'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un padre (regla más fácil de recordar).

Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará empadronado) en una única población. En este caso la tabla principal será la de poblaciones y la tabla secundaria será la de habitantes. Una población puede tener varios habitantes pero un habitante pertenece a una sola población. Esta relación se representa incluyendo en la tabla 'hijo' una columna que se corresponde con la clave principal de la tabla 'padre', esta columna es lo denominamos clave foránea (o clave ajena o clave externa).

 

CLAVE  FORANEA

Una clave foránea es pues un campo de una tabla que contiene una referencia a un registro de otra tabla. Siguiendo nuestro ejemplo en la tabla habitantes tenemos una columna población que contiene el código de la población en la que está empadronado el habitante, esta columna es clave ajena de la tabla habitantes, y en la tabla poblaciones tenemos una columna código de población clave principal de la tabla.

Relación Varios a Varios:

 Cuando un registro de una tabla puede estar relacionado con más de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar relacionadas directamente, se tiene que añadir una tabla entre las dos que incluya los pares de valores relacionados entre sí.

Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artículos que se venden en la empresa, un cliente podrá realizar un pedido con varios artículos, y un artículo podrá ser vendido a más de un cliente.

No se puede definir entre clientes y artículos, hace falta otra tabla (por ejemplo una tabla de pedidos) relacionada con clientes y con artículos. La tabla pedidos estará relacionada con cliente por una relación uno a muchos y también estará relacionada con artículos por un relación uno a muchos.

 

¿ Cuándo se pueden producir errores en los datos?

 

©      Cuando insertamos una nueva fila en la tabla secundaria y el valor de la clave foránea no existe en la tabla principal. insertamos un nuevo habitante y en la columna población escribimos un código de población que no está en la tabla de poblaciones (una población que no existe).

 

©      Cuando modificamos el valor de la clave principal de un registro que tiene 'hijos', modificamos el código de Valencia, sustituimos el valor que tenía (1) por un nuevo valor (10), si Valencia tenía habitantes asignados, qué pasa con esos habitantes, no pueden seguir teniendo el código de población 1 porque la población 1 ya no existe, en este caso hay dos alternativas, no dejar cambiar el código de Valencia o bien cambiar el código de población de todos los habitantes de Valencia y asignarles el código 10.

©      Cuando modificamos el valor de la clave foránea, el nuevo valor debe existir en la tabla principal. Por ejemplo cambiamos la población de un habitante, tenía asignada la población 1 (porque estaba empadronado en valencia) y ahora se le asigna la población 2 porque cambia de lugar de residencia. La población 2 debe existir en la tabla de poblaciones.

©      Cuando queremos borrar una fila de la tabla principal y ese registro tiene 'hijos', por ejemplo queremos borrar la población 1 (Valencia) si existen habitantes asignados a la población 1, estos no se pueden quedar con el valor 1 en la columna población porque tendrían asignada una población que no existe. En este caso tenemos dos alternativas, no dejar borrar la población 1 de la tabla de poblaciones, o bien borrarla y poner a valor nulo el campo población de todos sus 'hijos'.

 

Asociada a la integridad referencial están los conceptos de actualizar los registros en cascada y eliminar registros en cascada.

Actualización y borrado en cascada

El actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la clave foránea y que le indican al sistema gestor qué hacer en los casos comentados en el punto anterior.

 Actualizar registros en cascada:

Esta opción le indica al sistema gestor de la base de datos que cuando se cambie un valor del campo clave de la tabla principal, automáticamente cambiará el valor de la clave foránea de los registros relacionados en la tabla secundaria.

Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10 en el campo código (la clave principal), automáticamente se actualizan todos los habitantes (en la tabla secundaria) que tienen el valor 1 en el campo población (en la clave ajena) dejando 10 en vez de 1.

Si no se tiene definida esta opción, no se puede cambiar los valores de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor 1 del código de la tabla de poblaciones , no se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han podido modificar por infracciones de clave.

 

 Eliminar registros en cascada:

Esta opción le indica al sistema gestor de la base de datos que cuando se elimina un registro de la tabla principal automáticamente se borran también los registros relacionados en la tabla secundaria.

Por ejemplo: Si borramos la población Onteniente en la tabla de poblaciones, automáticamente todos los habitantes de Onteniente se borrarán de la tabla de habitantes.

Si no se tiene definida esta opción, no se pueden borrar registros de la tabla principal si estos tienen registros relacionados en la tabla secundaria. En este caso, si intentamos borrar la población Onteniente, no se produce el borrado y el sistema nos devuelve un error o un mensaje que los registros no se han podido eliminar por infracciones de clave.

TEORIA DE NORMALIZACIONES BASE DE DATOS

 

TEORÍA DE LAS NORMALIZACIONES BASE DE DATOS.

 CLAVE:

SE OBTIENE UNA TABLA.

FN= FASE

REDUNDANCIA DE DATOS = (MUCHAS VUELTAS)  NINGUNA EXPLICACIÓN DE DATOS NO HAY RELACION CON LAS TABLAS.

QUE  NO HAYA  AMBIGÜEDAD NI REDUNDANCIA  SE PUEDE  PERDER DATOS 

DEFINICIÓN:

El proceso de normalización es un proceso de descomposición de los esquemas de relación hasta que

todas las relaciones alcancen la forma normal deseada. En general, interesa:

©      Determinar las llaves candidato (míniales) de cada relación.

©      Determinar la forma normal de la relación.

©      ¿Está en FNBC? Si no, normalizar.

©      ¿La normalización no asegura la preservación de información y dependencias? Conformarse con 3FN

Objetivo

Las bases de datos relacionales se normalizan para:

©      Minimizar la redundancia de los datos.

©      Disminuir problemas de actualización de los datos en las tablas.

©      Proteger la integridad de datos.

En el modelo relacional es frecuente llamar tabla a una relación; para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

©      Cada tabla debe tener su nombre único.

©      No puede haber dos filas iguales. No se permiten los duplicados.

©      Todos los datos en una columna deben ser del mismo tipo

REGLAS DE NORMALIZACIÓN:

El punto de partida del proceso de normalización es un conjunto de tablas con sus atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla está en una determinada forma normal si satisface un cierto número de restricciones impuestas por la correspondiente regla de normalización. La aplicación de una de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que no se ha introducido ningún nuevo atributo.

Un esquema relacional se compone de una serie de ternas T(A,D) donde T es el nombre de una tabla, A el conjunto de los atributos de esa tabla y D el conjunto de dependencias funcionales que existen entre esos atributos.

Si una tabla no satisface una determinada regla de normalización, se procede a descomponerla en otras dos nuevas que sí las satisfagan. Esto usualmente requiere decidir qué atributos de la tabla original van a residir en una u otra de las nuevas tablas. La descomposición tiene que conservar dos propiedades fundamentales:

 

1.      No pérdida de información.

Sea T(A,D) que se divide en T1(A1,D1) y T2(A2,D2). A partir de los atributos comunes en ambos esquemas es posible determinar los atributos de T1 no presentes en T2 (es decir, el conjunto A1 - A2) o bien los atributos de T2 no presentes en T1 (el conjunto diferencia A2 - A1). Desde cualquier esquema se consigue recuperar los datos del otro mediante un mecanismo de clave ajena que permite reconstituir el esquema original de partida. Expresado mediante dependencias funcionales, la intersección de los conjuntos de atributos A1 y A2 debe determinar funcionalmente la diferencia de los conjuntos de atributos A1 - A2 o bien A2 - A1.

 

 

2.      No pérdida de dependencias funcionales.

La normalización consiste pues en descomponer los esquemas relacionales (tablas) en otros equivalentes (puede obtenerse el original a partir de los otros) de manera que se verifiquen unas determinadas reglas de normalización. Evidentemente las reglas de normalización imponen una serie de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Según se avance en el cumplimiento de reglas y restricciones se alcanzará una mayor forma normal. Existen

cinco formas normales hacia las cuales puede conducir el proceso de normalización de forma incremental más una forma normal independiente de las otras.

El proceso de normalización  consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

 

Las bases de datos relacionales se normalizan para:

©      Evitar la redundancia de los datos.

©      Disminuir problemas de actualización de los datos en las tablas.

©      Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

©      Cada tabla debe tener su nombre único.

©      No puede haber dos filas iguales. No se permiten los duplicados.

©      Todos los datos en una columna deben ser del mismo tipo.

Primera Forma Normal (1FN)

Una relación está en primera forma normal cuando todos sus atributos son atómicos.  Una tabla está en Primera Forma Normal si:

©      Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.

©      La tabla contiene una clave primaria única.

©      La clave primaria no contiene atributos nulos.

©      No debe existir variación en el número de columnas.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

©      Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

©      Una tabla no puede tener múltiples valores en cada columna.

©      Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).

©      Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN)

Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional  es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional  es una dependencia parcial si hay algunos atributos  que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es .

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relación  está en 3 Forma Normal Elmasri-Navathe, si para toda dependencia funcional , se cumple al menos una de las siguientes condiciones:

©      es super llave o clave.

©      es atributo primo de ; esto es, si es miembro de alguna clave en .

©      Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Por ejemplo {DNI, ID_PROYECTO}  HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente funcional dado que ni DNI  HORAS_TRABAJO ni ID_PROYECTO  HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO}  NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI  NOMBRE_EMPLEADO mantiene la dependencia.

Forma normal de Boyce-Codd (FNBC)

La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante la presencia de un intervalo seguido de una formalización perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir.

©      Formalmente, un esquema de relación  está en FNBC, si y sólo si, para toda dependencia funcional  válida en , se cumple que es súper llave o clave.

©      De esta forma, todo esquema  que cumple FNBC, está además en 3FN; sin embargo, no todo esquema  que cumple con 3FN, está en FNBC.

Formas Normales de Alto Nivel

Cuarta Forma Normal (4FN)

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si:

La tabla esta en 4FN

No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.

QUE ES UNA BASE DE DATOS.

                                

DEFINICIÓN.

Una base de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido; una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.

Hay programas denominados sistemas gestores de bases de datos, abreviado SGBD (del inglés Database Management System o DBMS), que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de estos DBMS, así como su utilización y administración, se estudian dentro del ámbito de la informática.

Clasificación de bases de datos

Base de datos de particulares

Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se esté manejando, la utilidad de las mismas o las necesidades que satisfagan.

 

Bases de datos estáticas

Son bases de datos únicamente de lectura, utilizadas principalmente para almacenar datos históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones, tomar decisiones y realizar análisis de datos para inteligencia empresarial.

 

Bases de datos dinámicas

Son bases de datos donde la información almacenada se modifica con el tiempo, permitiendo operaciones como actualización, borrado y edición de datos, además de las operaciones fundamentales de consulta. Un ejemplo, puede ser la base de datos utilizada en un sistema de información de un supermercado.

 

Bases de datos bibliográficas

Solo contienen una subrogante (representante) de la fuente primaria, que permite localizarla. Un registro típico de una base de datos bibliográfica contiene información sobre el autor, fecha de publicación, editorial, título, edición, de una determinada publicación, etc. Puede contener un resumen o extracto de la publicación original, pero nunca el texto completo, porque si no, estaríamos en presencia de una base de datos a texto completo (o de fuentes primarias —ver más abajo). Como su nombre lo indica, el contenido son cifras o números. Por ejemplo, una colección de resultados de análisis de laboratorio, ayuda mucho a la redundancia de datos.

 

Bases de datos de texto completo

Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas las ediciones de una colección de revistas científicas.

 

Bases de datos o "bibliotecas" de información química o biológica

Son bases de datos que almacenan diferentes tipos de información proveniente de la química, las ciencias de la vida o médicas. Se pueden considerar en varios subtipos:

 

Las bases de datos de rutas metabólicas.

Bases de datos de estructura, comprende los registros de datos experimentales sobre estructuras 3D de biomoléculas.

Bases de datos clínicas.

Bases de datos bibliográficas (biológicas, químicas, médicas y de otros campos)

 

MODELO DE BASE DE DATOS.

Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guardan los datos), así como de los métodos para almacenar y recuperar datos de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos.

 

 

 

Bases de datos jerárquicas

En este modelo los datos se organizan en forma de árbol invertido (algunos dicen raíz), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas. Son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento.

Base de datos de red

Este es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).

 

 

Bases de datos transaccionales

Son bases de datos cuyo único fin es el envío y recepción de datos a grandes velocidades, estas bases son muy poco comunes y están dirigidas por lo general al entorno de análisis de calidad, datos de producción e industrial, es importante entender que su fin único es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y duplicación de información no es un problema como con las demás bases de datos, por lo general para poderlas aprovechar al máximo permiten algún tipo de conectividad a bases de datos relacionales.

 

Base de datos relacionales.

En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.

 

Bases de datos multidimensionales

Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación de Cubos OLAP. Básicamente no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podría serlo también en una base de datos multidimensional), la diferencia está más bien a nivel conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan métricas que se desean aprender.

 

Bases de datos orientadas a objetos

Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento). Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos:

 

©     Encapsulación - Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos.

©     Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases.

©     Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos.

 

Bases de datos documentales

Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes, sirven para almacenar grandes volúmenes de información de antecedentes históricos. Tesaurus es un sistema de índices optimizado para este tipo de bases de datos.

 

Bases de datos deductivas

Un sistema de base de datos deductiva, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a través de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas son también llamadas bases de datos lógicas, a raíz de que se basa en lógica matemática.

 

Lenguaje

Utiliza un subconjunto del lenguaje Prolog llamado Datalog el cual es declarativo y permite al ordenador hacer deducciones para contestar a consultas basándose en los hechos y reglas almacenados.

 

Ventajas

©     Uso de reglas lógicas para expresar las consultas.

©     Permite responder consultas recursivas.

©     Cuenta con negaciones estratificadas

Fases

Fase de Interrogación: se encarga de buscar en la base de datos informaciones deducibles implícitas. Las reglas de esta fase se denominan reglas de derivación.

Fase de Modificación: se encarga de añadir a la base de datos nuevas informaciones deducibles. Las reglas de esta fase se denominan reglas de generación.

Interpretación

Encontramos dos teorías de interpretación de las bases de datos deductiva por lo cual consideramos las reglas y los hechos como axiomas. Los hechos son axiomas base que se consideran como verdaderos y no contienen variables. Las reglas son axiomas deductivos ya que se utilizan para deducir nuevos hechos.

 

Teoría de Modelos: una interpretación es llamada modelo cuando para un conjunto específico de reglas, estas se cumplen siempre para esa interpretación. Consiste en asignar a un predicado todas las combinaciones de valores y argumentos de un dominio de valores constantes dado. A continuación se debe verificar si ese predicado es verdadero o falso.

Mecanismos

Existen dos mecanismos de inferencia:

©     Ascendente: donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia.

©     Descendente: donde se parte del predicado (objetivo de la consulta realizada) e intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.