martes, 20 de diciembre de 2011

ODBC: Concepto - Configuración

Qué es el 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.
Cada origen de datos ODBC de un cliente tiene un nombre del origen de datos (DSN) exclusivo. Un origen de datos ODBC para el controlador ODBC de SQL Server incluye toda la información utilizada para conectarse a una instancia de SQL Server, más las opciones fundamentales.

INTRODUCCIÓN A LAS HERRAMIENTAS CASE

INTRODUCCIÓN A LAS HERRAMIENTAS CASE

. Introducción.
Las Herramientas case es la mejor base para el proceso de análisis y desarrollo de software, así que las computadoras afectan nuestras vidas nos guste o no. Utilizamos las maquinas en nuestra vida diaria, la mayor parte del tiempo sin reconocer conscientemente que estamos haciéndolo, a diario utilizamos aplicaciones domésticas como microondas, televisión, vídeo Casseteras o en la calle los cajeros automáticos, entre otros.
La verdad es que no podemos escapar de las computadoras. El rápido incremento es una hazaña de las computadoras junto al dramático decremento en tamaño y costo, y así esta tecnología, es una larga variedad de aplicaciones que éstas pueden soportar.

Desde el inicio de la escritura de software, ha existido un conocimiento de la necesidad de herramientas automatizadas para ayudar al diseñador del software. Inicialmente, la concentración estaba en herramientas de apoyo a programas como traductores, recopiladores, ensambladores, procesadores de macros, montadores y cargadores. Este conjunto de aplicaciones, aumentó de una manera rápida en un breve espacio de tiempo, causando una gran demanda por nuevo software a desarrollar. A medida que se escribía nuevo software, habían ya en existencia millones y millones de líneas de código que necesitaban se mantenidas y actualizadas.
Significado sigla CASE
Computer
Aided Assisted Automated
Software Systems
Engineering
Qué son las Herramientas CASE?
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.).
CASE es también definido como el Conjunto de métodos, utilidades y técnicas que facilitan el mejoramiento del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.
Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
Existe también el CASE integrado que fue comenzando a tener un impacto muy Significativo en los negocios y sistemas de información de las organizaciones, además con este CASE integrado las compañías pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios.

Historia de las Herramientas CASE.
Las Herramientas CASE se iniciaron con un procesador de palabras que fue usado para crear y manipular documentación. Los 70’s vieron la introducción de técnicas gráficas y diagramas de flujo de datos. Sobre este punto, el diseño y especificaciones en forma pictórica han sido extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y análisis estructural, hecho posible a través de las mejoras en las Herramientas CASE.

Pronto se reemplazaron los paquetes gráficos por paquetes especializados que habilitan la edición, actualización e impresión en múltiples versiones de diseño. A diario, las herramientas gráficas integradas con diccionarios de base de datos para producir poderosos diseños y desarrollar herramientas, podrían sostener ciclos completos de diseño de documentos. Como un paso final, la verificación de errores y generadores de casos de pruebas fueron incluidos para validar el diseño del software. Todos estos procesos pueden saberse integrados en una simple herramienta CASE que soporta todo el ciclo de desarrollo. La primera herramienta comercial se remonta a 1982, aunque algunos especialistas indican que algunos ejemplos de herramientas para diagramación ya existían.
No fue sino hasta 1985 cuando las herramientas CASE se volvieron realmente importantes en el proceso de desarrollo de software. Los proveedores prometieron a la Industria que muchas actividades serían beneficiadas por la ayuda de las CASE.
El objetivo en 1985 para muchos vendedores era producir software más rápidamente. Las herramientas del CASE serían una familia de métodos favorablemente estructurados para planeamiento, análisis y diseño. Esto llevaría a la generación automática de código para desarrollo de software. Esto traería como beneficio: Una mejora en la calidad, fiabilidad, utilidad y rendimiento.

 Clasificación de las Herramientas Case
No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase en común. Podrían clasificarse así:
  • Las plataformas que soportan.
  •  Las fases del ciclo de vida del desarrollo de sistemas que abarca.
  • La arquitectura de las aplicaciones que produce.
  • Su funcionalidad. Las herramientas CASE, en función de las fases del ciclo de vida que cubre, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de Herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento

Rango de las Herramientas Case.
Algunas Herramientas CASE son sólo para la fase de Diseño. Otras, son sólo generadoras de Código, Algunas Herramientas de Análisis y Diseño tienen una visión de Desarrollo orientada a procesos sin la capacidad de modelamiento.
Algunas proveen Herramientas para el modelamiento sin incluir los procesos de Análisis o Diseño.

 Componentes y funcionalidades de una herramienta de una herramienta CASE
Repositorio:
Base de datos central de una herramienta CASE. El repositorio amplía el concepto de diccionario de datos para incluir toda la información que se va generando a lo largo del ciclo de vida del sistema, como por ejemplo: componentes de análisis y diseño (diagramas de flujo de datos, diagramas entidad-relación, esquemas de bases de datos, diseños de pantallas), estructuras de programas, algoritmos, etc.
Las características más importantes de un repositorio son:
* Tipo de información: Que contiene alguna metodología concreta, datos, gráficos, procesos, informes, modelos o reglas.
* Tipo de controles: Si incorpora algún módulo de gestión de cambios, de mantenimiento de versiones, de acceso por clave, de redundancia de la información.
* Tipo de actualización: Si los cambios en los elementos de análisis o diseño se ven reflejados en el repositorio en tiempo real o mediante un proceso por lotes. Esto será importante en función a la necesidad de que los cambios sean visibles por todos los usuarios, en el acto.
* Reutilización de módulos para otros diseños: El repositorio es la clave para identificar, localizar y extraer código para su reutilización.
Módulos de diagramación y modelación
Algunos de los diagramas y modelos utilizados con mayor frecuencia son

  • Diagrama de flujo de datos.
  •  Modelo entidad - interrelación.
  •  Historia de la vida de las entidades.
  •  Diagrama Estructura de datos.
  •  Diagrama Estructura de cuadros.
  •  Técnicas matriciales.
Herramienta de prototipazo

El objetivo principal de esta herramienta es poder mostrar al usuario, desde los momentos iniciales del diseño, el aspecto que tendrá la aplicación una vez desarrollada. Ello facilitará la aplicación de los cambios que se consideren necesarios, todavía en la fase de diseño.
Para la construcción del resto de la aplicación. Actualmente, es imprescindible utilizar productos que incorporen esta funcionalidad por la cambiante tecnología y necesidades de los usuarios. Los prototipos han sido utilizados ampliamente en el desarrollo de sistemas tradicionales, ya que proporcionan una realimentación inmediata, que ayudan a determinar los requisitos del sistema. Las herramientas CASE están bien dotadas, en general, para crear prototipos con rapidez y seguridad.
Generador de código
Normalmente se suele utilizar sobre ordenadores personales o estaciones de trabajo, por lo que el paso posterior del código al host puede traer problemas, al tener que compilar en ambos entornos.
Módulo generador de documentación
El módulo generador de la documentación se alimenta del repositorio para transcribir las especificaciones allí contenidas.

Ejemplos de Herramientas Case más utilizadas.
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.)
EasyCASE
EasyCASE Profesional - el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniería de Base de Datos- es un producto para la generación de esquemas de base de datos e ingeniería reversa - trabaja para proveer una solución comprensible para el diseño, consistencia y documentación del sistema en conjunto.
Esta herramienta permite automatizar las fases de análisis y diseño dentro del desarrollo de una aplicación, para poder crear las aplicaciones eficazmente – desde el procesamiento de transacciones a la aplicación de bases de datos de cliente/servidor, así como sistemas de tiempo real.
EasyCASE Profesional, una herramienta multi-usuario, es ideal para aquellos que necesitan compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder proyectos localizados en el servidor de la red concurrentemente. Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al registro, al archivo y al proyecto, y niveles de control de acceso.
Base de datos que soporta:
* Oracle * Paradox
* Progress * SQLBase
* SQL Server * Sybase
* Watcom SQL * Access
* ANSI SQL * Clipper
* dBASE III, IV, V * DB2
* FoxPro * Informix
Requerimientos del sistema:
EasyCASE Professional 4.2 o superior requiere:
EasyCASE Database Engineer; PC’s 386/486/Pentium y compatibles; Microsoft Windows 3.1 o superior, 8 MB RAM, 8 MB de espacio en disco duro; VGA o mejor color.
Oracle Designer:
Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor gráficas. Integrado con Oracle Developer, Oracle Designer, que provee una solución para desarrollar sistemas empresariales de segunda generación.

Todos los datos ingresados por cualquier herramienta de Oracle Designer, en cualquier fase de desarrollo, se guardan en un repositorio central, habilitando el trabajo fácil del equipo y la dirección del proyecto.
En el lado del Servidor, Oracle Designer soporta la definición, generación y captura de diseño de los siguientes tipos de bases de datos, por conexión de Oracle:
  • Oracle8, Oracle7
  •  Personal Oracle Lite
  •  Rdb
  •  ANSI 92
  •  DB2/2 and MVS
  •  Microsoft SQL Server
  • Sybase
System Architect
Esta herramienta posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balanceamiento entre diagramas "Padre e Hijo", además de balanceamiento horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.
El System Architect Traduce modelos de entidades en esquemas para:
* Sybase
* DB2
* Oracle u Oracle 7
* Ingress
* SQL Server
* RDB
* XDB
* Progress
* Paradox
* SQL Base
* AS400
* Interbase
* OS/2
* DBMS
* Dbase 111
* Informix
Esta herramienta también Genera en Windows DDL, definiciones de datos para lenguaje C/C++ y estructuras de datos en Cobol. En esta ultima versión del System Architect es posible a través de ODBC, la creación de bases de datos a partir del modelo de entidades, además Posee esquemas de seguridad e integridad a través de contraseñas que posibilitan el acceso al sistema en diversos niveles, pudiéndose integrar a la seguridad de la red.
GLOSARIO

CASE: Ayuda por PC a la Ingeniería de Software.
TECNOLOGIA CASE: Una tecnología del software que mantiene una disciplina de la ingeniería automatizada para el desarrollo de software, con metodologías estructuradas y herramientas automatizadas.
HERRAMIENTA CASE: Una herramienta del software que automatiza una parte del ciclo de desarrollo de software.
SISTEMA CASE: Un conjunto de herramientas CASE integradas que comparten una Interface del usuario común.
KIT de HERRAMIENTAS CASE: Un conjunto de herramientas CASE integradas que se han diseñado para trabajar juntas y automatizar, o proveer ayuda automatizada al ciclo de desarrollo de software, incluyendo el análisis, diseño, codificación y pruebas.
METODOLOGIA CASE: Una metodología estructurada que define una disciplina e ingeniería como un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento de software.
PUESTO DE TRABAJO para CASE: Una estación de trabajo técnica, diseñada a 32 bits o computadora personal equipada con Herramientas Case que automatiza varias funciones del ciclo.
PLATAFORMA de HARDWARE para CASE: Una arquitectura de hardware con uno, dos o tres sistemas puestos en línea, que proveen una plataforma operativa para las Herramientas Case.

NORMALIZACIÓN II - 4FN,5FN

Semana 14

NORMALIZACIÓN II - 4FN,5FN

Cuarta Forma Normal – 4FN

• Una relación esta en 4FN si esta en la BCFN y no
contiene dependencias multivaluadas.
• Existe una dependencia multivaluada cuando hay
tres atributos (A,B y C) en una relación, tal que
por cada valor de A existe un bien definido
conjunto de valores de B y un bien definido
conjunto de valores de C, sin embargo el
conjunto de valores de B es independiente del
conjunto C y viceversa.

Quinta Forma Normal – 5FN
• Permite hacer frente a un tipo de dependencia
denominada dependencia de unión (Join
dependency).
• Suele presentarse cuando resolvemos tres (o mas)
entidades, todas relacionadas con una relación
muchos-a-muchos a las otras.
• Es algunas veces referida como Join-Proyection
Normal Form (JPNF).
• Estas relaciones son raras en la práctica.

 

NORMALIZACIÓN I -Aplicacion

Semana 13

NORMALIZACIÓN I -APLICACIÓN

Normalizar una tabla de ejemplo

Estos pasos demuestran el proceso de normalización de una tabla de alumnos ficticia.
  1. Tabla sin normalizar:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutorDespacho-TutClase1Clase2Clase3
    1022García412101-07143-01159-02
    4123Díaz216201-01211-02214-01
  2. Primera forma normal: no hay grupos repetidos

    Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.

    Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutorDespacho-TutNº clase
    1022García412101-07
    1022García412143-01
    1022García412159-02
    4123Díaz216201-01
    4123Díaz216211-02
    4123Díaz216214-01
  3. Segunda forma normal: eliminar los datos redundantes

    Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.

    Las dos tablas siguientes demuestran la segunda forma normal:

    Alumnos:
     
    Nº alumnoTutorDespacho-Tut
    1022García412
    4123Díaz216


    Registro:
     
    Nº alumnoNº clase
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tercera forma normal: eliminar los datos no dependientes de la clave

    En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:

    Alumnos:
     
    Nº alumnoTutor
    1022García
    4123Díaz


    Personal:
     
    NombreHabitaciónDept
    García41242
    Díaz21642

TEORÍA DE 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.
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.
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.


Fundamentos de la normalización E/R Técnicas de aplicación

Semana 11


Modelado de datos



martes, 11 de octubre de 2011

Recursividad, Entidades asociativas,dependencias funcionales

Semana 8
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ón
Una 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 externo
Usamos 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 interno
Cuando 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ón del 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 ASOCIATIVAS

En 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ébiles
y 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 asociativa.
A 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.