NORMALIZACION

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. 

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.

PROGRAMACION ORIENTADA A OBJETOS (POO)

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

Los objetos son entidades que combinan estado (atributo), comportamiento (método) e identidad:

• El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
• El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

ORIGEN

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "en marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos tomó posición como el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado, soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

CONCEPTOS FUNDAMENTALES

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
• Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
• Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
• Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
• Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
• Componentes de un objeto: atributos, identidad, relaciones y métodos.
• Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

CARACTERISTICAS DE LA POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:

• Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

• Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

• Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

• Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
• Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

LENGUAJE SQL

El SQL es el lenguaje estándar ANSI/ISO de definición, manipulación y control

De bases de datos relacionales. Es un lenguaje declarativo: sólo hay que indicar

Qué se quiere hacer. En cambio, en los lenguajes procedimentales es necesario

Especificar cómo hay que hacer cualquier acción sobre la base de datos. El SQL

Es un lenguaje muy parecido al lenguaje natural; concretamente, se parece al

Inglés, y es muy expresivo. Por estas razones, y como lenguaje estándar, el SQL

Es un lenguaje con el que se puede acceder a todos los sistemas relacionales

Comerciales.

OBJETOS,METODOS,EVENTOS Y PROPIEDADES DE VISUAL BASIC

Objetos: Un objeto es una  que tiene asociado un conjunto de métodos, eventos y propiedades. Hay muchas clases de objetos, y por tanto, puede llegar a haber tantos métodos, eventos y propiedades distintas como objetos diferentes.  Ejemplo: Una caja de texto (TextBox) en la cual podemos escribir cualquier línea es un objeto.entidad

Métodos: Son procedimientos definidos en Visual Basic para realizar operaciones específicas sobre los objetos (Controles o Formularios).

Eventos: Es una acción como hacer clic,  clic, presionar una tecla, mover el puntero del , etc. Que el usuario debe realizar para que un objeto ejecute una acción determinada cada control responde a diferentes , algunos de ellos tienen características comunes. Los eventos pueden Visualizarse en la ventana de código.eventosmousedoble

Propiedades: Son los datos que hacen referencia a un objeto o formulario.
Ejemplo: Color de fondo del formulario, Fuente de texto de un TextBox.

ESPACIO DE NOMBRES

En programación, un espacio de nombres (del inglés namespace), en su acepción más simple, es un conjunto de nombres en el cual todos los nombres son únicos.

Un espacio de nombres es un contexto en el que un grupo de uno o más identificadores pueden existir. Un identificador definido en un espacio de nombres está asociado con ese espacio de nombres. El mismo identificador puede independientemente ser definido en múltiples espacios de nombres, eso es, el sentido asociado con un identificador definido en un espacio de nombres es independiente del mismo identificador declarado en otro espacio de nombres. Los lenguajes que manejan espacio de nombres especifican las reglas que determinan a qué espacio de nombres pertenece una instancia de un identificador.

Por ejemplo, Pedro trabaja para la compañía X y su número de empleado es 123. María trabaja para la compañía Y y su número de empleada también es 123. La razón por la cual Pedro y María pueden ser identificados con el mismo número de empleado es porque trabajan para compañías diferentes. Diferentes compañías simbolizan en este caso diferentes namespaces.

En programas grandes o en documentos no es infrecuente tener cientos o miles de identificadores. Los namespaces (O técnicas similares como la emulación de namespaces) disponen de un mecanismo para ocultar los identificadores locales. Ellos proveen los medios para agrupar lógicamente los identificadores relacionados en sus correspondientes namespaces, haciendo así el sistema más modular.

Muchos lenguajes de programación manejan espacios de nombres. En algunos lenguajes, como C++ o Python, estos identificadores nombrando espacios de nombres están asociados con un espacio de nombres que los agrupa. Así pues, en estos lenguajes, los espacios de nombres se pueden anidar formando un árbol de espacios de nombres. En la raíz de éste árbol se encuentra el espacio de nombres anónimo global.

RELACIONES ENTRE TABLAS

En una base de datos relacional, las relaciones permiten evitar datos redundantes. Por ejemplo, si está diseñando una base de datos que realiza un seguimiento de información sobre libros, podría tener una tabla denominada títulos que almacena información sobre cada libro, como el libro? título, la fecha de publicación y Publisher. También hay información que desea almacenar sobre el Editor, como el número de teléfono, dirección y código postal. Si tuviera que almacenar toda esta información en los títulos de tabla, el publicador? s número de teléfono se duplicaría por cada título de la editorial.
Una solución mejor es almacenar la información del editor una sola vez en una tabla independiente, Publisher. A continuación, podría colocar un puntero de la tabla titles que haga referencia a una entrada en la tabla Publisher.

Para asegurarse de que los datos no están sincronizados, puede exigir integridad referencial entre las tablas títulos y editores. Relaciones de integridad referencial ayudan a garantizar que la información en una tabla coincide con la información en otro. Por ejemplo, cada título de la tabla títulos debe estar asociado con un editor específico de la tabla Publisher. No se puede agregar un título a la base de datos de un editor que no existe en la base de datos.

Tipos de relaciones de tablas

Una relación hace coincidir los datos de columnas de claves, normalmente columnas con el mismo nombre en ambas tablas. En la mayoría de los casos, la relación hace coincidir la clave principal de una tabla, que proporciona un identificador único para cada fila, con una entrada de la clave externa de la otra tabla. Por ejemplo, se pueden asociadas las ventas a los títulos específicos vendidos mediante la creación de una relación entre la columna title_id de la tabla titles (la clave principal) y la columna title_id de la tabla de ventas (clave externa).

Hay tres tipos de relaciones entre tablas. El tipo de relación que se crea depende de cómo se definen las columnas relacionadas.

Relaciones uno a varios

Una relación uno a varios es el tipo más común de relación. En este tipo de relación, una fila de tabla A puede tener muchas filas coincidentes en la tabla B, pero una fila en la tabla B puede tener sólo una fila coincidente en la tabla a. Por ejemplo, las tablas Publisher y titles tienen una relación de uno a varios: cada editorial genera muchos títulos, pero cada título procede sólo una editorial.

Se crea una relación uno a varios si sólo uno de las columnas relacionadas es una clave principal o tiene una restricción unique.

En Access, el lado de la clave principal de una relación uno a varios se denota mediante un símbolo de clave. El lado de clave externa de una relación se indica mediante un símbolo de infinito.

Relaciones varios a varios

En una relación varios a varios, una fila de la tabla puede tener muchas filas coincidentes en la tabla B y viceversa. Se crea una relación de tal definiendo una tercera tabla, denominada tabla de unión, cuya clave principal consta de las claves externas de las tablas A y B. Por ejemplo, la tabla authors y la tabla titles tienen una relación de varios a varios definida por una relación de uno a varios desde cada una de estas tablas a la tabla Título Autores. La clave principal de la tabla Título Autores es la combinación de la columna au_id (la tabla authors? s clave principal) y la columna title_id (la tabla titles clave principal).

Relaciones uno a uno

En una relación uno a uno, una fila de la tabla puede tener no más de una fila coincidente en la tabla B y viceversa. Se crea una relación uno a uno si ambos de las columnas relacionadas son claves principales o tienen restricciones únicas.

Este tipo de relación no es común porque la mayoría información relacionada de esta manera estaría todo en una tabla. Puede utilizar una relación uno a uno para:

• Dividir una tabla con muchas columnas.
• Aislar parte de una tabla por razones de seguridad.
• Almacenar datos que se corta duración y se puede eliminar fácilmente eliminando simplemente la tabla.
• Almacenar información que se aplica sólo a un subconjunto de la tabla principal.

En Access, el lado de la clave principal de una relación uno a uno se denota mediante un símbolo de clave. El lado de clave externa también se indica mediante un símbolo de clave.

Cómo definir relaciones entre tablas

Cuando se crea una relación entre tablas, no es necesario tener los mismos nombres de los campos relacionados. Sin embargo, los campos relacionados deben tener el mismo tipo a menos que el campo de clave principal sea un campo Auto numérico de datos. Puede hacer coincidir un campo Auto numérico con un campo numérico sólo si la propiedad Tamaño Del Campo de ambos campos coincidentes es el mismo. Por ejemplo, puede hacer coincidir un campo Auto numérico y un campo numérico si la propiedad Tamaño Del Campo de ambos campos es entero largo. Incluso cuando ambos campos coincidentes son campos numéricos, deben tener el mismo valor de la propiedad Tamaño Del Campo.