INGENIERÍA DIRECTA Y REVERSA
APLICACION DEL ALUMNO
miércoles, 21 de diciembre de 2011
SEMANA 18
ODBC
Open Data Base Conectivity
O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos una aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si después queremos que la misma aplicación, y sin reescribir nada, utilice tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no funcionará. Nuestra aplicación, diseñada para un motor concreto, no sabrá dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no tendríamos este problema.... aunque eso no es probable que ocurra nunca.Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro sea capaz de dialogar con una DB concreta, solo tendríamos que ir cambiando este elemento, y nuestra aplicación siempre funcionaría sin importar lo que hay al otro lado... algo así como ir cambiando las boquillas de una manguera. A esas piezas intercambiables las llamaremos orígenes de datos de ODBC
Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación, como velocidad de proceso, tiempos de espera, máxima longitud de registro, número máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras técnicas de programación, pero aún le quedan muchos años de buen servicio.
Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service Pack 4 o superior instalado (el último publicado es el 6). El Option Pack 4 para actualizar el IIS y las extensiones ASP. SQL Server 6.5 y Access 97. Por supuesto, también funciona con las versiones modernas de servidores como 2003 Server, y también XP PRO, que lleva un IIS 5.0 de serie. Igualmente es posible utilizar bases de datos de Access 2000 o 2003.
Esas otras técnicas de programación antes mencionadas, se utilizan ya en el nuevo Windows 2003, Office 2003 y SQL Server 2000, que además de ODBC pueden utilizar.... pero esa es otra historia.
Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre homogéneas, y por el otro permite distintos controladores que aseguran la conectividad de la aplicación con diferentes bases de datos.
Configurar orígenes de datos ODBC
Una aplicación de Conectividad abierta de bases de datos (ODBC) utiliza un origen de datos ODBC para conectarse a una instancia de Microsoft MicrosoftSQL Server. Un origen de datos ODBC es una definición almacenada que registra:
- El controlador ODBC que se va a utilizar para las conexiones que especifican el origen de datos.
- La información que utiliza el controlador ODBC para conectarse a un origen de datos.
- Opciones específicas del controlador que se van a utilizar para la conexión. Por ejemplo, un SQL Server origen de datos ODBC puede registrar las opciones de ISO que va a utilizar o si los controladores deben registrar estadísticas de rendimiento.
SEMANA 17
INTRODUCCIÓN A LAS HERRAMIENTAS CASE
ERwin
PLATINUM ERwin es una herramienta para el diseño de base de datos, que Brinda productividad en su diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, además ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos.
ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad _ relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
La migración automática garantiza la integridad referencial de la base de datos. ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, ERwin genera automáticamente tablas, vistas, índices, reglas de integridad referencial (llaves primarias, llaves foráneas), valores por defecto y restricciones de campos y dominios.
ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
Software para Aplicaciones Compatibles:
* NetDynamics
* PowerBuilder
* PROGRESS
* Visual Basic
Bases de Datos Compatibles:
* CA-Clipper * CA-OpenIngres
* DB2 for MVS * DB2 for OS/390,
* DB2 UDB * dBASE
* FoxPro * HiRDB,
* Informix * InterBase,
* Microsoft Access * Microsoft SQL Server,
* Oracle * Paradox,
* Rdb * red Brick Warehouse,
* SAS * SQL Anywhere,
* SQLBase * Sybase,
* Teradata
Sistemas Operativos Compatibles:
* Windows NT
* Windows 95
* Windows 98
Requerimientos Técnicos:
Mínimo 10 MB de espacio de disco duro, 16 MB RAM (32 MB RAM recomendado para modelos largos.)
PowerDesigner
La Herramienta Líder en Modelamiento Empresarial
PowerDesigner, la herramienta de modelamiento número uno de la industria, permite a las empresas, de manera más fácil, visualizar, analizar y manipular metadatos, logrando un efectiva arquitectura empresarial de información.
PowerDesigner para Arquitectura Empresarial también brinda un enfoque basado en modelos, el cual permite alinear al negocio con la tecnología de información, facilitando la implementación de arquitecturas efectivas de información empresarial. Brinda potentes técnicas de análisis, diseño y gestión de metadatos a la empresa.
PowerDesigner combina varias técnicas estándar de modelamiento con herramientas líder de desarrollo, como .NET, Sybase WorkSpace, Sybase Powerbuilder, Java y Eclipse, para darle a las empresas soluciones de análisis de negocio y de diseño formal de base de datos. Además trabaja con más de 60 bases de datos relacionales.
SEMANA 15
NORMALIZACION III
En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que : - Ninguna Columna puede depender de una columna que no tenga una clave
- No puede haber datos derivados
| VentaID | ItemID | ProductoID | Cantidad | Descripcion | Medida | Proveedor |
| 1 | 1 | 3455 | 12 | Impresora HP LJ8000 | 122cm | 1 |
| 1 | 2 | 2455 | 34 | Scanner HP A3555 | 33cm | 1 |
| 2 | 1 | 5444 | 21 | Mouse HP Wireless | - | 1 |
ConclusiónFinalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance.
SEMANA 14
NORMALIZACION II
- 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.
Ocurre esta forma normal cuando una tabla está en forma normal de Boyce Codd y toda dependencia multivaluada es una dependencia funcional.
Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y y X,Z reproducen sin perder información lo que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN
- 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.
Es la más compleja y polémica de todas. Polémica pues no está claro en muchas ocasiones que sea una solución mejor que el no llegar a este nivel de normalización. Fue definida también por Fagin.
Es raro encontrarse este tipo de problemas cuando la normalización llega a 4FN. Se deben a restricciones muy concretas.
SEMANA 13
NORMALIZACION I
La normalización o estandarización es la redacción y aprobación de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos fabricados, la seguridad de funcionamiento y trabajar con responsabilidad social.
La normalización es el proceso de elaborar, aplicar y mejorar las normas que se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas. La asociación estadounidense para pruebas de materiales (ASTM) define la normalización como el proceso de formular y aplicar reglas para una aproximación ordenada a una actividad específica para el beneficio y con la cooperación de todos los involucrados.
Según la ISO (International Organization for Standarization) la normalización es la actividad que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto dado, que puede ser tecnológico, político o económico.
La normalización persigue fundamentalmente tres objetivos:
Simplificación: se trata de reducir los modelos para quedarse únicamente con los más necesarios.
Unificación: para permitir el intercambio a nivel internacional.
Especificación: se persigue evitar errores de identificación creando un lenguaje claro y preciso.
Las elevadas sumas de dinero que los países desarrollados invierten en los organismos normalizadores, tanto nacionales como internacionales, es una prueba de la importancia que se da a la normalización.
SEMANA 12
TEORÍA DE NORMALIZACIÓN
Fundamentos de la normalización
La normalización es el proceso de organizar los datos de una base de datos. Se incluye la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias incoherentes.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal". Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
En las descripciones siguientes se incluyen ejemplos.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal". Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
En las descripciones siguientes se incluyen ejemplos.
Primera forma normal
· Elimine los grupos repetidos de las tablas individuales.
· Cree una tabla independiente para cada conjunto de datos relacionados.
· Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
Segunda forma normal
· Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.
· Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla Clientes o en una tabla Direcciones independiente.
Tercera forma normal
· Elimine los campos que no dependan de la clave.
Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único registro de la tabla, considere colocar estos campos en una tabla independiente. Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
SEMANA 11
MODELADO DE DATOS E/R
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo de datos permite describir:
Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.
Una clasificación de los modelos de datos
Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan:
- Modelos de Datos Conceptuales
Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.
- Modelos de Datos Lógicos
Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).
- Modelos de Datos Físicos
Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.
martes, 25 de octubre de 2011
SEMANA 9
TIPOS DE RELACIONES
Clasificación por Cardinalidad
Relación Uno a Uno: Cuando un registro de una tablasólo puede estar relacionado con un único registro de laotra tabla y viceversa.En este caso la clave foránea se ubica en alguna de las
2 tablas.
Relación Uno a Muchos: Cuando un registro de unatabla (tabla secundaria) sólo puede estar relacionado conun único registro de la otra tabla (tabla principal) y un registrode la tabla principal puede tener más de un registrorelacionado en la tabla secundaria.En este caso la clave foránea se ubica en la tabla secundaria.
Relación Muchos a Muchos: Cuando un registro deuna tabla puede estar relacionado con más de un registrode la otra tabla y viceversa. En este caso las dos tablasno pueden estar relacionadas directamente, se tieneque añadir una tabla entre las dos (Tabla débil o de vinculación)que incluya los pares de valoresrelacionadosentre sí.
SEMANA 8.
Teoria de Relaciones
Recursivas:
Modelan las situaciones en que dos entidades del mismo conjunto se relacionan entre si.
Es nesesario especificar el rol de cada entidad en la relacion.
- Los padres y los hijos.
-Las piezas estan formadas de piezas.
Entidades:
Las entidades son el fundamento del modelo entidad relación. Podemos adoptar como definición de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podrían interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avión, o abstractas, como por ejemplo un préstamo o una reserva. Se representan por medio de un rectángulo.
SEMANA 8
RECURSIVIDAD
Definición.Hablamos
de recursividad, tanto en el ámbito informático como en el ámbito matemático,
cuando definimos algo (un tipo de objetos, una propiedad
o una operación) en función
de sí mismo. La recursividad en programación
es una herramienta sencilla, muy útil y potente.
Tipos.Podemos
distinguir dos tipos de recursividad:Directa: Cuando un subprograma se llama
a si mismo una o mas veces directamente.Indirecta: Cuando se definen una
serie de subprogramas usándose unos a otros.
Características.Un
algoritmo recursivo consta de una parte recursiva, otra iterativa o no recursiva
y una condición de terminación. La parte recursiva y la condición de terminación
siempre existen. En cambio
la parte no recursiva puede coincidir con la condición de terminación.Algo
muy importante a tener en cuenta cuando usemos la recursividad es que es
necesario asegurarnos que llega un momento en que no hacemos más llamadas
recursivas. Si no se cumple esta condición el programa no parará
nunca.
Ventajas
e inconvenientes.La
principal ventaja es la simplicidad de comprensión y su gran potencia,
favoreciendo la resolución de problemas
de manera natural, sencilla y elegante; y facilidad para comprobar y convencerse
de que la solución del problema es correcta.El principal inconveniente es la
ineficiencia tanto en tiempo como en memoria,
dado que para permitir su uso es necesario transformar el programa recursivo en
otro iterativo, que utiliza bucles y pilas
para almacenar las variables.
Estructura
RepresentaciónUna tabla es una estructura homogénea en la que todos los
elementos que la componen son del mismo tipo. Son estáticas, no crecen ni
decrecen en tiempo de ejecución y tienen un límite preestablecido antes de la
compilación.Para acceder a los elementos de una tabla se utilizan los
"índices" y estos pueden ser de cualquier tipo escalar de PASCAL
(enumerados, INTEGER, CHAR, subrogo, BOOLEAN).Por ello las tablas son
estructuras de acceso directo o acceso por índice.
Búsqueda
secuencial.Búsqueda secuencial con centinela.Almacenamiento
externoUsamos espacios fuera de las de la tabla para colocar las colisiones.
Dentro del almacenamiento externo hay varios tipos.Encadenamiento directo y
zona de overflow.Encadenamiento directo.Esta realización considera la
tabla como un vector en el que cada posición contiene un elemento y un campo
adicional con el comienzo de la lista de elementos con los que existe colisión.
Es decir, las posibles colisiones se resuelven construyendo una lista de
elementos cuya imagen
hash coincida.
Ventajas:
eficientes y rápidos.Inconvenientes: Para cada elemento de la lista se debe
reservar un espacio para punteros lo que significa un desaprovechamiento de
memoria en el "manejo de lista".
Zona
de Overflow.Se reserva espacio en cierta zona de externa a la propia tabla,
de aproximadamente el 10% de su tamaño, para introducir las colisiones. Cada
sinónimo se almacena en la primera celda disponible de la zona de
overflow.Inconveniente: Desaprovechamiento de memoria (poco).Es poco
eficiente cuando se han producido colisiones, ya que la búsqueda en la zona de
overflow es secuencial.Ventajas: Ocupa menos memoria que el anterior. El
algoritmo de búsqueda y de inserción es mas sencillo.
Almacenamiento
internoCuando el espacio usado para almacenar las colisiones esta dentro de
los límites
de la tabla. Dentro del almacenamiento interno están: Encadenamiento directo y
encadenamiento vacío.
Encadenamiento
directo.Se usa dentro de la tabla un campo de tipo puntero para que apunte
al siguiente colisionado, que estará dentro de la tabla. En ese campo se guarda
la direccióndel siguiente colisionado.En el encadenamiento directo con zona de overflow
podemos sobredimensionar la tabla para almacenar las colisiones, en esta zona
las casillas estarán encadenadas con una variable que apunte al primer espacio
libre de la zona de overflow. Consiste en enlazar todos los elementos cuyas
claves generan igual índice primario por medio de enlaces dentro de la tabla a
las nuevas posiciones ocupadas por estos elementos.Inconvenientes: Espacio
reservado en cada elemento para el enlace.Ventajas: Más rápido que el
externo con zona de overflow ya que evita la búsqueda secuencial.Ocupación
de memoria: Depende del método
usado. El primer caso ocupa menos memoria, y el segundo es más
rápido.
Como todo buen diseñador de base de datos sabe, es bastante común
encontrarse con entidades recursivas en el diseño de nuestra BD, 2 ejemplos
típicos son el jefe y el subordinado, en el diseño ambas personas se encuentran
registradas como duplas dentro de la entidad Persona o Funcionario (según el
diseño que hemos tomado, incluso estaría mejor diseñado si se lo hace en base al
cargo), al no existir 2 entidades que tengan cardinalidad 1:M, por que
así obtendríamos duplicación de datos, debemos determinar un modo que
ambos estén en la misma entidad y a su vez tener la capacidad de controlar quién
es jefe de quién, esto se lograría agregando una columna más que sea del mismo
dominio que su propia PK, es decir, la columna nueva sería FK de la PK que le
determina, logrando así una cardinalidad 1:M recursiva.
Otro ejemplo típico es el caso de los contratos, estos suelen tener
la característica que vencen en una fecha determinada, por cuestiones de
ventas/marketing al cliente se le facilita normalmente este proceso con
una renovación de contrato (en algunos casos automáticas), entonces el
nuevo contrato debe poder determinarse lo siguiente: la renovación de que
contrato está siendo, o si es el primer contrato, para realizarlo se aplica el
mismo ejemplo anterior, una columna FK que sea del mismo dominio de la
PK que le determina.
ENTIDADES ASOCIATIVASEn
este subapartado veremos un mecanismo que nos permite considerar una
interrelación entre entidades como si fuese una entidad.La entidad que resulta de
considerar una interrelación entre entidades como si fuese una entidad es una
entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que
se define.La
utilidad de una entidad asociativa consiste en que se puede interrelacionar con
otras entidades y, de forma indirecta, nos permite tener interrelaciones en las
que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el
rombo de la interrelación de la que proviene.
Ejemplo
de entidad asociativa
La
figura siguiente muestra un ejemplo de entidad asociativa:
Recorrido
es
una interrelación de conectividad M:N que registra las ciudades por donde han
pasado los diferentes viajes organizados por una empresa de reparto de paquetes.
Consideramos recorrido una entidad asociativa con el fin de interrelacionarla
con la entidad cliente;
de este modo nos será posible reflejar por orden de qué clientes se han hecho
repartos en una ciudad del recorrido de un viaje, así como el número de paquetes
cargados y descargados siguiendo sus indicaciones.El
mecanismo de las entidades asociativas subsume el de las entidades
débilesy
resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil
podremos sustituirla por una entidad asociativa, pero no al
revés.
Ejemplo
de sustitución de una entidad débil por una asociativaA
continuación se muestra la entidad débil despacho, que tiene la interrelación
asignación
con la entidad empleado.
Podríamos
modelizar este caso haciendo que despacho fuese una entidad asociativa si
consideramos una nueva entidad número-despacho que contiene simplemente números
de despachos. Entonces, la entidad asociativa despacho se obtiene de la
interrelación entre edificio
y número-despacho.Aunque
las entidades débiles se puedan sustituir por el mecanismo de las entidades
asociativas, es adecuado mantenerlas en el modelo ER porque resultan menos
complejas y son suficientes para modelizar muchas de las situaciones que se
producen en el mundo real.
Dependencias
funcionales
El concepto de dependencia funcional Hay veces en que los atributos están relacionados entre si de manera
más especifica que la de Pertenecer a una misma relación. Hay veces en que es posible
determinar que un atributo depende de otro funcionalmente, como si existiera una función f en el “mundo”, tal que t [A] = f (t [B]). La funci´on se anotaría como f: A! B, pero como f es desconocida (o sino B seria un atributo derivado), sólo nos quedamos con A! B, la dependencia funcional, que se lee “A determina B”. Formalmente, X! Y en R se
Cumple si y sólo si 8s, t 2 R, s [X] = t[X] ) s[Y
Dependencias Funcionales (1/3)
I Es un conceptos muy importante en el diseño de base de
Datos relaciones Una dependencia funcional es una restricción entre
dos
Conjuntos de atributos de la base de datos.
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o implica a Y, que se representa por X! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y.
Dependencias Funcionales (2/3)
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o
implica a Y , que se representa por X ! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y .X! Y para dos duplas cualesquiera t1 y t2 de un estado relación r de R, si t1 [X] = t2 [X], entonces t1 [Y] = t2[Y ]. Si una restricción de R dice que no puede haber más de una dupla con un valor X dado en cualquier instancia de relación r (R), X es una clave candidata de R y X! Y para cualquier subconjunto de atributos de Y de R. Si X! Y, no nos dice que Y! X o no.
Dependencias Funcionales (3/3)
ej.: cód. Libro! titulo, el código del libro determina el titulo. El es el implicante y
titulo es el implicado. Siempre el implicado es un hecho (una información)
acerca del implicante.
OBS1: la afirmación cód. libro determina titulo NO significa que a
partir de cód. libro podamos conocer el titulo. Es decir, para un esquema
R, si tenemos la dependencia funcional X ! Y, dado un valor de X no podemos en general conocer el valor de Y. Solo nos limitaremos a afirmar que para dos duplas de cualquier
extensión de R que tengan el mismo valor de X, el valor de Y también será igual en ambas. I OBS2: Las dependencias son predicados o restricciones sobre cualquier
extensión válida del esquema de relación, por lo que observar una determinada
extensión (datos) no puede llevarnos a afirmar la existencia de una dependencia
funcional.
Definición.Hablamos
de recursividad, tanto en el ámbito informático como en el ámbito matemático,
cuando definimos algo (un tipo de objetos, una propiedad
o una operación) en función
de sí mismo. La recursividad en programación
es una herramienta sencilla, muy útil y potente.
Tipos.Podemos
distinguir dos tipos de recursividad:Directa: Cuando un subprograma se llama
a si mismo una o mas veces directamente.Indirecta: Cuando se definen una
serie de subprogramas usándose unos a otros.
Características.Un
algoritmo recursivo consta de una parte recursiva, otra iterativa o no recursiva
y una condición de terminación. La parte recursiva y la condición de terminación
siempre existen. En cambio
la parte no recursiva puede coincidir con la condición de terminación.Algo
muy importante a tener en cuenta cuando usemos la recursividad es que es
necesario asegurarnos que llega un momento en que no hacemos más llamadas
recursivas. Si no se cumple esta condición el programa no parará
nunca.
Ventajas
e inconvenientes.La
principal ventaja es la simplicidad de comprensión y su gran potencia,
favoreciendo la resolución de problemas
de manera natural, sencilla y elegante; y facilidad para comprobar y convencerse
de que la solución del problema es correcta.El principal inconveniente es la
ineficiencia tanto en tiempo como en memoria,
dado que para permitir su uso es necesario transformar el programa recursivo en
otro iterativo, que utiliza bucles y pilas
para almacenar las variables.
Estructura
RepresentaciónUna tabla es una estructura homogénea en la que todos los
elementos que la componen son del mismo tipo. Son estáticas, no crecen ni
decrecen en tiempo de ejecución y tienen un límite preestablecido antes de la
compilación.Para acceder a los elementos de una tabla se utilizan los
"índices" y estos pueden ser de cualquier tipo escalar de PASCAL
(enumerados, INTEGER, CHAR, subrogo, BOOLEAN).Por ello las tablas son
estructuras de acceso directo o acceso por índice.
Búsqueda
secuencial.Búsqueda secuencial con centinela.Almacenamiento
externoUsamos espacios fuera de las de la tabla para colocar las colisiones.
Dentro del almacenamiento externo hay varios tipos.Encadenamiento directo y
zona de overflow.Encadenamiento directo.Esta realización considera la
tabla como un vector en el que cada posición contiene un elemento y un campo
adicional con el comienzo de la lista de elementos con los que existe colisión.
Es decir, las posibles colisiones se resuelven construyendo una lista de
elementos cuya imagen
hash coincida.
Ventajas:
eficientes y rápidos.Inconvenientes: Para cada elemento de la lista se debe
reservar un espacio para punteros lo que significa un desaprovechamiento de
memoria en el "manejo de lista".
Zona
de Overflow.Se reserva espacio en cierta zona de externa a la propia tabla,
de aproximadamente el 10% de su tamaño, para introducir las colisiones. Cada
sinónimo se almacena en la primera celda disponible de la zona de
overflow.Inconveniente: Desaprovechamiento de memoria (poco).Es poco
eficiente cuando se han producido colisiones, ya que la búsqueda en la zona de
overflow es secuencial.Ventajas: Ocupa menos memoria que el anterior. El
algoritmo de búsqueda y de inserción es mas sencillo.
Almacenamiento
internoCuando el espacio usado para almacenar las colisiones esta dentro de
los límites
de la tabla. Dentro del almacenamiento interno están: Encadenamiento directo y
encadenamiento vacío.
Encadenamiento
directo.Se usa dentro de la tabla un campo de tipo puntero para que apunte
al siguiente colisionado, que estará dentro de la tabla. En ese campo se guarda
la direccióndel siguiente colisionado.En el encadenamiento directo con zona de overflow
podemos sobredimensionar la tabla para almacenar las colisiones, en esta zona
las casillas estarán encadenadas con una variable que apunte al primer espacio
libre de la zona de overflow. Consiste en enlazar todos los elementos cuyas
claves generan igual índice primario por medio de enlaces dentro de la tabla a
las nuevas posiciones ocupadas por estos elementos.Inconvenientes: Espacio
reservado en cada elemento para el enlace.Ventajas: Más rápido que el
externo con zona de overflow ya que evita la búsqueda secuencial.Ocupación
de memoria: Depende del método
usado. El primer caso ocupa menos memoria, y el segundo es más
rápido.
Como todo buen diseñador de base de datos sabe, es bastante común
encontrarse con entidades recursivas en el diseño de nuestra BD, 2 ejemplos
típicos son el jefe y el subordinado, en el diseño ambas personas se encuentran
registradas como duplas dentro de la entidad Persona o Funcionario (según el
diseño que hemos tomado, incluso estaría mejor diseñado si se lo hace en base al
cargo), al no existir 2 entidades que tengan cardinalidad 1:M, por que
así obtendríamos duplicación de datos, debemos determinar un modo que
ambos estén en la misma entidad y a su vez tener la capacidad de controlar quién
es jefe de quién, esto se lograría agregando una columna más que sea del mismo
dominio que su propia PK, es decir, la columna nueva sería FK de la PK que le
determina, logrando así una cardinalidad 1:M recursiva.
Otro ejemplo típico es el caso de los contratos, estos suelen tener
la característica que vencen en una fecha determinada, por cuestiones de
ventas/marketing al cliente se le facilita normalmente este proceso con
una renovación de contrato (en algunos casos automáticas), entonces el
nuevo contrato debe poder determinarse lo siguiente: la renovación de que
contrato está siendo, o si es el primer contrato, para realizarlo se aplica el
mismo ejemplo anterior, una columna FK que sea del mismo dominio de la
PK que le determina.
ENTIDADES ASOCIATIVASEn
este subapartado veremos un mecanismo que nos permite considerar una
interrelación entre entidades como si fuese una entidad.La entidad que resulta de
considerar una interrelación entre entidades como si fuese una entidad es una
entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que
se define.La
utilidad de una entidad asociativa consiste en que se puede interrelacionar con
otras entidades y, de forma indirecta, nos permite tener interrelaciones en las
que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el
rombo de la interrelación de la que proviene.
Ejemplo
de entidad asociativa
La
figura siguiente muestra un ejemplo de entidad asociativa:
Recorrido
es
una interrelación de conectividad M:N que registra las ciudades por donde han
pasado los diferentes viajes organizados por una empresa de reparto de paquetes.
Consideramos recorrido una entidad asociativa con el fin de interrelacionarla
con la entidad cliente;
de este modo nos será posible reflejar por orden de qué clientes se han hecho
repartos en una ciudad del recorrido de un viaje, así como el número de paquetes
cargados y descargados siguiendo sus indicaciones.El
mecanismo de las entidades asociativas subsume el de las entidades
débilesy
resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil
podremos sustituirla por una entidad asociativa, pero no al
revés.
Ejemplo
de sustitución de una entidad débil por una asociativaA
continuación se muestra la entidad débil despacho, que tiene la interrelación
asignación
con la entidad empleado.
Podríamos
modelizar este caso haciendo que despacho fuese una entidad asociativa si
consideramos una nueva entidad número-despacho que contiene simplemente números
de despachos. Entonces, la entidad asociativa despacho se obtiene de la
interrelación entre edificio
y número-despacho.Aunque
las entidades débiles se puedan sustituir por el mecanismo de las entidades
asociativas, es adecuado mantenerlas en el modelo ER porque resultan menos
complejas y son suficientes para modelizar muchas de las situaciones que se
producen en el mundo real.
Dependencias
funcionales
El concepto de dependencia funcional Hay veces en que los atributos están relacionados entre si de manera
más especifica que la de Pertenecer a una misma relación. Hay veces en que es posible
determinar que un atributo depende de otro funcionalmente, como si existiera una función f en el “mundo”, tal que t [A] = f (t [B]). La funci´on se anotaría como f: A! B, pero como f es desconocida (o sino B seria un atributo derivado), sólo nos quedamos con A! B, la dependencia funcional, que se lee “A determina B”. Formalmente, X! Y en R se
Cumple si y sólo si 8s, t 2 R, s [X] = t[X] ) s[Y
Dependencias Funcionales (1/3)
I Es un conceptos muy importante en el diseño de base de
Datos relaciones Una dependencia funcional es una restricción entre
dos
Conjuntos de atributos de la base de datos.
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o implica a Y, que se representa por X! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y.
Dependencias Funcionales (2/3)
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o
implica a Y , que se representa por X ! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y .X! Y para dos duplas cualesquiera t1 y t2 de un estado relación r de R, si t1 [X] = t2 [X], entonces t1 [Y] = t2[Y ]. Si una restricción de R dice que no puede haber más de una dupla con un valor X dado en cualquier instancia de relación r (R), X es una clave candidata de R y X! Y para cualquier subconjunto de atributos de Y de R. Si X! Y, no nos dice que Y! X o no.
Dependencias Funcionales (3/3)
ej.: cód. Libro! titulo, el código del libro determina el titulo. El es el implicante y
titulo es el implicado. Siempre el implicado es un hecho (una información)
acerca del implicante.
OBS1: la afirmación cód. libro determina titulo NO significa que a
partir de cód. libro podamos conocer el titulo. Es decir, para un esquema
R, si tenemos la dependencia funcional X ! Y, dado un valor de X no podemos en general conocer el valor de Y. Solo nos limitaremos a afirmar que para dos duplas de cualquier
extensión de R que tengan el mismo valor de X, el valor de Y también será igual en ambas. I OBS2: Las dependencias son predicados o restricciones sobre cualquier
extensión válida del esquema de relación, por lo que observar una determinada
extensión (datos) no puede llevarnos a afirmar la existencia de una dependencia
funcional.
SEMANA 7
TEORÍA DE RELACIONES
Cardinalidad
Otra de las características importantes que hay que tener en cuenta en este modelo es la cardinalidad de cada extremo en una relación. La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están relacionadas con cuántas entidades del conjunto del otro extremo. Pueden ser ``uno a uno'', ``uno a varios'' o ``varios a varios''. Por ejemplo, un artículo puede ser escrito por un solo autor o por varios, pero nunca por ninguno; un autor puede pertenecer a exactamente una institución (no para cero o varias); un artículo puede tener cero, uno o varios experimentos. Finalmente, un autor puede escribir muchos artículos, o ninguno. Observe que las cardinalidades en algunos casos dependen de restricciones arbitrarias: se podría decidir aceptar sólo aquellos autores que han escrito al menos un artículo (y con esto cambiaría la última regla mencionada); hemos decidido considerar sólo la institución primaria para la cual un determinado autor trabaja (y esto ha determinado nuestra segunda regla).
Hay varias maneras de mostrar las cardinalidades en el diagrama. Una de ellas es poner etiquetas en las líneas que unen las relaciones con las entidades. La etiqueta consiste de un mínimo y un máximo, cada uno de los cuales contiene un cero, un uno o una letra n (``varios''). Si la cardinalidad es exactamente uno, se pone sólo el uno. En el caso de una relación varios a varios, lo usual es poner una m en un extremo y una n en el otro.
SEMANA 6
MODELO FISICO
El modelo físico está construido sobre las bases del modelo lógico y describe como los datos son almacenados. Este es el nivel más bajo de abstracción.
SEMANA 5
MODELO LOGICO
Lenguaje que se utiliza para describir esquemas Lógicos; hay varios modelos lógicos: de red, relacional, Orientado a objetos,Este modelo es el puente entre el modelo conceptual y el modelo físico; describecomo se verán los datos. Existen en el diseño de bases de datos 3 modelos lógicos:
v Jerárquico
v Red
v Relacional
SEMANA 4
El Modelo de Datos Entidad-Relación (E/R)
Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos
Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.
Entidades y Relaciones
El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:
- Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
- Que sea única.
- Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada cliente un número de cliente?.
- Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
- Relación.- Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:
- Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
- Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN).
- Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).
Ejemplos
Relación muchos a muchos.
Ejemplos
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color - Tarjeta de circulación -Propietario, No_serie, Tipo.
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país. 
Relación muchos a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona). 
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.
Relación muchos a muchos.El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona).
SEMANA 3
MODELO ENTIDAD RELACION I
El Modelo de Entidad Relación es un modelo de datos basado en una percepcióndel mundo real que consiste en un conjunto de objetos básicos llamados entidades y relaciones entre estos objetos, implementándose en forma gráfica a travésdel Diagrama Entidad Relación.
MODELO CONCEPTUAL
El modelo conceptual deberá reflejar todas las relaciones lógicas y es totalmenteindependiente de su implementación física. Este es un modelo de entidad relación.
Modelos conceptuales propuestos
v Modelo semántico de datos
v Modelo Semántico
v Modelo Binario
v Modelo Entidad-Relación
SEMANA 1
BASE DE DATOS
§ CONCEPTOS GENERALES
Una base de datos o banco de datos (abreviado con B.D. o b. d.), es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. Como ejemplo, una biblioteca puede considerarse como una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su posterior consulta. En la actualidad, 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, que ofrece un grande rango de soluciones al problema de almacenar datos.
Existen programas denominados sistemas gestores de base de datos, que permiten almacenar y luego poder acceder a los datos de forma rápida y estructurada.
Las aplicaciones más usuales son para la gestión empresas e instituciones públicas. También son utilizadas ampliamente en entornos científicos con el objeto de almacenar la información experimental.
Modelo de Datos:
Un modelo de datos es básicamente una descripción de algo conocido como “contenedor de datos” (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas, sino son abstracciones que permiten implementar un sistema eficiente de base de datos; por lo general se refieren a algoritmos y conceptos matemáticos.
Algunos modelos utilizados con frecuencia:
Ø Bases de datos Jerárquicas: Estas almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en forma de un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres se llama raíz y a los nodos que no tienen hijos se llaman hojas.
Son útiles para manejar un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento.
Uno de sus problemas, es la incapacidad de representar eficientemente la redundancia de datos.
Ø Base de datos de Red: Aquí un mismo nodo puede tener varios padres.
Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero aun, así, la dificultad que resultaba administrar la información en una base de datos de red ha significado que sea un modelo utilizado por programadores más que por usuarios finales.
Ø Base de datos Transaccionales: Su fin es el envío y recepción de datos a grandes velocidades, 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 único fin es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y la duplicación de información no es un problema como con las demás bases de datos, por lo general para aprovecharlas al máximo permiten algún tipo de conectividad a base de datos relacionales. Un ejemplo habitual es el traspaso de dinero entre cuentas bancarias.
Normalmente se realiza mediante dos operaciones distintas, una en la que se decrece el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema, las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es, bien se realiza las dos operaciones o no se realizan ninguna.
Ø Base de datos relacionales: Este es el modelo usado en la actualidad para modelar problemas reales y administrar datos dinámicamente. En este modelo, el lugar y la forma en que se almacenan los datos no tienen relevancia. 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 almacenada o recuperada mediante “consultas” que ofrecen una gran flexibilidad y poder para poder administrar la información.
El Lenguaje más habitual para construir las consultas a base de datos relacionales es SQL (Structured Query Language), un estándar implementado por los principales motores o sistemas de gestión de base de datos relacionales.
Durante su diseño, una base de datos relacional pasa por un proceso llamado “normalización de una base de datos”.
Ø Base de datos multidimensionales: Ideadas para desarrollar aplicaciones muy concretas, como creación de Cubos OLAP.
Ø Base de datos orientadas a objetos: Este modelo bastante reciente, es propio de los modelos informáticos orientados a objetos, y tratan de almacenar los objetos completos en la base de datos (estado y comportamiento).
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.
En base de datos orientados a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos.
Una operación se especifica en dos partes. La interfaz de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos. La implementación de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en que se hayan implementado. Esto podría denominarse independencia entre programas y operaciones.
Ø Base de datos documentales: Permiten la indexación a texto completo, y en líneas generales hacer búsquedas más potentes. Tesaurus es un sistema de índices optimizado para este tipo de base de datos.
Ø Base de datos deductivos: Permite hacer deducciones a través de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. También son llamados bases de datos lógicas, a raíz que se basa en lógica matemática. Surge debido a limitaciones de la base de datos relacional de responder a consultas recursivas y de deducir relaciones indirectas de los datos almacenados en la base de datos.
Ø Lenguaje: Utiliza un subconjunto del lenguaje Prolog llamado Datalog, el cual es declarativo y permite al ordenador hacer deducciones para contestar 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.
- Capacidad de obtener nueva información a través de la ya almacenada en la base de datos mediante inferencia.
- Uso de algoritmos de optimización de consultas.
- Soporta objetos y conjuntos complejos.
Ø Desventajas:
- Crea procedimientos eficaces de deducción para evitar caer en bucles infinitos.
- Encontrar criterios que decidan la utilización de una ley como regla de deducción.
- Replantear las convenciones habituales de la base de datos.
Ø Fases:
- Fases 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.
- Fases 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:
- Teoría de demostración: Consideramos las reglas y los hechos como axiomas.
Los hechos son axiomas bases 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 especifico de reglas, están 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:
- Ascendente: Donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia.
- Descendente: Donde se parte del predicado y se intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.
Ø Gestión de base de datos Distribuida:
La base de datos y el software SGBD pueden estar distribuidos en múltiples sitios conectados por una red.
- Distribuidos homogéneos: Utilizan el mismo SGBD en múltiples sitios.
- Distribuidos heterogéneos: Da lugar a los SGBD federados o sistemas multibases de datos en los que los SGBD participantes tienen cierto grado de autonomía local y tienen acceso a varias bases de datos autónomas preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura cliente - servidor.
Surgen debido a la existencia de física de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder así a distintas universidades, sucursales de tienda, etc.
DBMS:
Un sistema de administración de base de datos (DBMS - Database Management System), es un sistema basado en computador que maneja una base de datos, o una colección de base de datos o archivos. La persona que administra un DBMS es conocida como el DBA (Database Administrator).
Está compuesta por:
- DDL (Data Definition Language): Lenguaje de definición de datos.
- DML (Data Manipulation Language): Lenguaje de Manipulación de Datos.
- SQL (Structured Query Language) : Lenguaje Estructurado de Consultas.
Uso y funciones de un DBMS:
- Permiten a los usuarios acceder y manipular la base de datos proveyendo métodos para construir sistemas de procesamiento de datos para aplicaciones que requieran acceso a datos.
- Proveer a los administradores las herramientas que le permitan ejecutar tareas de mantenimiento y administración de datos.
Algunas de las funciones son:
- Definición de la base de datos: Aquí se verá, como, la información será almacenada y organizada.
- Creación de base de datos: Almacenamiento de datos en una base de datos definida.
- Recuperación de los datos: Consultas y reportes.
- Actualización de los datos: Cambiar los contenidos de las bases de datos.
- Programación de aplicaciones para el desarrollo de software.
- Control de la integridad de la base de datos.
- Monitoreo del comportamiento de la base de datos.
Suscribirse a:
Entradas (Atom)