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º alumno	Tutor	Despacho-Tut	Clase1	Clase2	Clase3
   1022	García	412	101-07	143-01	159-02
   4123	Díaz	216	201-01	211-02	214-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º alumno	Tutor	Despacho-Tut	Nº clase
   1022	García	412	101-07
   1022	García	412	143-01
   1022	García	412	159-02
   4123	Díaz	216	201-01
   4123	Díaz	216	211-02
   4123	Díaz	216	214-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º alumno	Tutor	Despacho-Tut
   1022	García	412
   4123	Díaz	216

   
   
   Registro:
   
    

   Nº alumno	Nº clase
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-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º alumno	Tutor
   1022	García
   4123	Díaz

   
   
   Personal:
   
    

   Nombre	Habitación	Dept
   García	412	42
   Díaz	216	42

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