jueves, 16 de julio de 2009

TIPOS DE DATOS:
String: Caracteres con letras, caracteres especiales, letras con números, números solos, lo importante es que su contenido no sirven para realizar operaciones.

Numérico: Realizar alguna operación. Existen algunos tipos de variables numéricos.
Enteros
byte: Donde su valor va de 0 a 255 el número valor máximo. Es entero.
Integer donde su número menor es de –32768 y el numero máximo es 32767. dato debe ser entero
long: Donde su contenido debe ser entero, y el valor va entre +- 4.127 millones.

Numéricos con decimales:
Single:
Donde su contenido puede ser 38 enteros con 7 decimales
Double: Donde su contenido puede ser decimales y enteros y valores muy grandes.

Otros tipos de variable
Bolean:
Maneja un cero o un uno. True es 1 y falso es cero
Date: Maneja fecha bajo el formato según el sistema ddmmaa.
Time: Maneja la hora del sistema HHMMSS

ALCANCE DE VARIABLES:

Local: Son variables que se definen y se utilizan en el mismo programa que se define. Al terminar su utilización libera la variable y el recurso que requirió. Las variables locales se definen dentro del evento o subprograma.

















Global: son variables que se definen y se utilizan dentro de un formulario. Al terminar su utilización no libera hasta que salga de la aplicación. La global se define dentro del programa principal.















CREAR BOTONES DENTRO DE UN FORMULARIO.

Para crear un botón debo de tener la barra de herramientas, selecciono el botón commandbotton y arrastro al formulario y listo.




































Ejemplo:
Entrar el nombre del usuario y guardarlo en una variable llamado nombre





















Y en ver código debo de tener esto.











































CONTADORES Y ACUMULADORES

Contador: Variable cualquiera a la cual se le incrementan (sumar) solamente valores constantes. Los contadores debe inicializarse normalmente debe ser 0.
Ejemplo: Con = Con + 1 donde 1 es la constante
Con = Con + 8 donde 8 es la constante

Acumulador: Variable cualquiera a la cual se le incrementa variables, no constantes.
Ej. Valor = Valor + horas horas es la variable que tiene una cantidad, la próxima vez que lea la variable horas tendrá otro valor

Al final valor tendrá la suma de todas las horas que se ingresaron o digitaron.









martes, 14 de julio de 2009

TEORÍA BÁSICA DE OBJETOS
¿Qué es Visual Basic?
son aplicaciones para el sistema operativo Microsoft Windows. Las aplicaciones creadas con Visual Basic están basadas en objetos y son manejadas por eventos. Visual Basic se deriva del lenguaje Basic, el cual es un lenguaje de programación estructurado.

¿Que es un objeto?

Cada formulario (ventana), menú o control que se crea con Visual Basic es un módulo autocontenido llamado objeto.

En otras palabras, un objeto formulario ha sido diseñado para cumplir determinada función en una aplicación.

Propiedades:
Propiedad Visual: lo que observamos (ejemplo: un marcador es de gris, es de plástico, etc.)
Ejemplo: Un borrador características visuales ( forma, color, material)
Ejemplo: Botón características visuales (color, titulo, tamaño: (ancho, alto), diseño) .
Métodos:

Los métodos son un conjunto de procedimientos que permiten que un objeto ejecute una acción o tarea sobre sí mismo.
Eventos:

Un evento ocurre (se dispara) como resultado de la interacción del usuario con el objeto. También puede dispararse debido a la ejecución de código (sentencias) o como resultado de la interacción de otro objeto con el objeto de poseedor del evento.

INTERFACE DE VISUAL BASIC:
Como se entra a Visual Basic.

Inicio Programa Microsoft Visual Estudio Visual Basic 6.0







































Cuando se entra aparece una ventana llamado nuevo proyectoCon las siguientes pestañas:


























TIEMPO DE PROGRAMACIÓN:

Tiempo de diseño:
Tiempo en que se hacen las cosas

Tiempo de ejecución: Tiempo en que se muestra como quedaran las cosas. Otro tiempo que se trabaja en VB es tiempo de ejecución, es el totalmente opuesto al diseño, cuando yo lo estoy haciendo es tiempo de diseño, cuando lo esta ejecutando será tiempo de ejecución.



Como Guardar un Proyecto.

Archivo
Guardar proyecto como
Primero guardo los formularios
Luego guardo el proyecto.


Como abrir proyectos anteriores

Cuando entro a Vb doy clic donde dice existente busca en las carpetas y doy clic a los proyectos.

Que es un formulario: es un contenedor de objetos y el mismo es un objeto.


PROPIEDADES PRINCIPALES DEL OBJETO FORMULARIO.

Estas aparecen en la ventana propiedades, la primera propiedad es nombre,
En la ventana izquierda están los nombres de las propiedades en la derecha esta el valor que tiene la propiedad.



Como cambiar el nombre al formulario
form1 doy clic en la ventana propiedades y doy clic en el valor de nombre y lo cambio por el nombre que yo deseo.


Como activar o desactivar el botón de maximizar.

Maxbotton: puede activar o desactivar el boton maximizar del formulario.

Como activar o desactivar el boton de minimizar

Minbotton: puede activar o desactivar el boton minimizar del formulario.

Como activar o desactivar el boton de menu de control

Controlbox: puede activar o desactivar el boton de control automáticamente se desactiva minimizar y maximizar.
Cambiar el color al formulario

Backcolor aparece una flecha y escojo paleta y escojo color y selecciono el color.
Cambiar el ancho del formulario
Width coloco el número de ancho. No permite poner 0, tiene unos limites mínimos 1680
Cambiar el alto del formulario
Height coloco el número de alto. No permite poner 0, tiene unos limites minimos 405


MANEJO DE FORMULARIOS

Como trabajar con varios formularios al mismo tiempo.
Tenemos la ventana explorador de proyectos.



Eventos comunes del formulario
Load: Cargar el formulario en la memoria
Clic: cuando el usuario de clic sobre el formulario
Dblclic: cuando el usuario de dclic sobre el formulario
Unload: Cuando se cierra el formulario
MouseMove: Cuando mueva el mouse encima del formulario.
Keypress: cuando se presiona una tecla se ejecuta.
FUNCIONES EN VISUAL BASIC

Es un fragmento de código que tiene ciertas características.
Siempre cumple una tarea específica
Generalmente tiene parámetros de entrada. (Variable, valores, etc)
Siempre retorna o devuelve un valor o una respuesta.

viernes, 20 de marzo de 2009

CLIENTE SERVIDOR

1. Introducción

Para las organizaciones en muchas ocasiones es necesario establecer una infraestructura de procesamiento de información, que cuente con los elementos requeridos para proveer información adecuada, exacta y oportuna en la toma de decisiones y para proporcionar un mejor servicio a los clientes.

Define al modelo Cliente/Servidor como la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas.

Los sistemas Cliente/Servidor se pueden ver de la siguiente manera, los clientes piden que una tarea sea realizada; El servidor realiza dicha tarea y regresa la información al cliente a través de la red. Cada componente dentro de estos sistemas se encarga de realizar su tarea exclusivamente.

2. Aproximaciones tradicionales de costos Cliente/Servidor

Normalmente se manejan 2 razones principales por las cuales las aproximaciones tradicionales a los costos no facilitan la adecuada cotización o costo de estos sistemas.
Alojan los costos por función en lugar de hacerlo por las actividades que lo generan.
Los costos en los que se incurren durante la planeación, diseño y prototipos que se deben realizar simplemente son muy caros, lo que no permite ver el detalle de estos costos para la organización.

Un sistema Cliente/Servidor Suele Ejecutarse en al menos dos sistemas distintos (uno hace de cliente y el otro de servidor). No obstante, es posible que tanto el cliente como el servidor se encuentren en un único sistema.

. Siempre que el usuario necesite recuperar o almacenar información, la parte cliente de la aplicación ejecuta una solicitud, que se envía (generalmente por una red) al servidor.
Los sistemas Cliente/Servidor se desarrollaron inicialmente para conseguir un rendimiento considerablemente superior con un aumento moderado del precio, pasando parte del procesamiento de la parte del cliente al servidor. De esta forma puede mejorar el rendimiento, pero apenas afecta al costo.

Ventajas: Costos. El enfoque cliente/servidor es económico, sobre todo cuando está unido al concepto de racionalización. Los costos de compra, arrendamiento y mantenimiento de macrocomputadoras centrales son tal elevados que los correspondientes a la compra de servidores, PCs y demás componentes para crear una red de área local parecen ridículos.

Acceso a la información. Si bien el acceso a los datos es posible por otros medios, la arquitectura Cliente/Servidor constituye el ambiente ideal para facilitar el acceso a la información.

Ergonomía. Un buen sistema Cliente/Servidor no se concibe sin una interfaz gráfica de usuario y sin una transparencia total.

Se concentra en el trabajo que debe realizar más que en la tecnología. Buena tecnología en el lugar adecuado. En teoría, un ambiente Cliente/Servidor puede conformarse de varias plataformas, sistemas operativos, Bases de Datos, etc.

Modularidad. En un ambiente Cliente/Servidor, es factible agregar o eliminar estaciones de trabajo y servidores, puesto que el sistema puede ser más o menos fácil de volver a configurar.

Desventajas: Incompatibilidad. El ambiente Cliente/Servidor supone que la época en que IBM tenía todo el mercado dominado ha concluido.

Si las especificaciones se ponen por escrito, no hay problema; pero en la práctica cotidiana, las incompatibilidades mayores o menores entre computadoras, sistemas operativos, lenguajes, protocolos, interfaces y programas de aplicación superan las expectativas.

Capacitación. En casi todos los casos de implantación del modelo Cliente/Servidor, la principal dificultad es la capacitación de los usuarios.

Costos. Si bien el costo es uno de los principales factores que inclinan la balanza en favor de la arquitectura Cliente/Servidor, los inconvenientes antes mencionados conducen a reflexionar sobre la variedad de costos ocultos que conlleva: capacitación, solución de montones de pequeños problemas imprevistos, el tiempo perdido en reconciliarse con lo proveedores, la reorganización y el desarrollo de aplicaciones que aún no se encuentran en el mercado. La implantación del modelo Cliente/Servidor comprende varios elementos. En primer lugar, se debe contar con una arquitectura completa de telecomunicación; es decir, no basta tener un protocolo de comunicación común entre todos los sistemas llamados a cooperar.

En efecto, es necesario disponer de funciones como administración de archivos en red, subordinación de trabajos, mensajería, comunicación entre aplicaciones, etc. Además, sería útil contar con una base de datos distribuida.

Es casi imposible implementar con éxito un proyecto Cliente/Servidor sin contar con el apoyo de los sectores superiores de la administración para dar respaldo al proyecto y controlar la observancia de los planes del proyecto por parte de la organización.

mi proyecto para las taquillas de una terminal de transporte

Problemática

Debido a el problema q hay en los terminales de cada ciudad nos vemos interesados en crear un software que nos solucione los problemas como el del hurto tanto por parte del conductor, la empresa y el pasajero que por ahorrar un porcentaje del 30% aproximadamente ayuda a que el conductor hurte a la empresa y así mismo la empresa no gane debido a este problema nos vemos obligados q en el software debemos dar un buen manejo para q la empresa no pierda y si le queden ganancia y el taquillero también algunas veces por ganar unos pesos $ de mas cobra los pasajes y los pasa o registra con un precio mas bajo y entonces a la empresa a si mismo no le entran las mismos ganancias por eso los trabajadores encargados de la taquilla están interesados en que nosotros le creemos el software para ver si así se acaba el problema del hurto y a ellos le quedan mas ganancias y a los conductores también y los pasajeros deben de pagar el pasaje completo.


Justificación

Con este proyecto nos vemos obligados a darle una solución a este problema ya que un dicho empresario nos cuenta su problema con el robo o hurto en las taquillas por medio de muchas personas que pueden ser el conductor, el taquillero, y puede estar incluido el cliente o pasajero sabiendo que esto es ilegal no se puede hacer nada por impedirlo pues la única solución seria cambiar el sistema de manejo y estar haciendo el inventario mas seguido y así mismo se evitara el desfalco.


Propuesta

Que Luego de creado nuestro proyecto y realizado el software nos
Dejen saber si se le acaba el problema o continúa para así mismo
Buscar otra solución, ver los problemas por completo desde otro punto de vista y darles una buena solución a todos. Para este software yo le pienso dar un manejo fácil y que se puedan evitar los robos, hurtos, desfalcos, etc. y Que tenga un acceso rápido a la base de datos de todos los buses de esa empresa y el nombre de los conductores.




DISEÑO DE BASE DE DATOS RELACIONAL



La concepción de una Base de Datos Relacional es una tarea larga y costosa.
Según Sommerville (1988) " un buen diseño es la clave de una eficiente ingeniería del software.
Muchas veces, el diseño de una base de datos se limita aplicar la teoría de normalización, cuando en realidad debe abarcar muchas otras etapas, que van desde la concepción hasta la instrumentación.

Ø Diseño Conceptual, cuyo objetivo es obtener una buena representación de los recursos de información de la empresa.
Ø Diseño Lógico, cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar (modelo relacional).

Ø Diseño Físico, cuyo objetivo es conseguir una instrumentación lo mas eficiente posible del esquema lógico.

Causas de malos diseños

Ø Falta de conocimiento del dominio de la aplicación, conocimiento que no posee el informático, pero si el usuario (aunque no sepa estructurarlo ni expresarlo de forma precisa).
Ø Falta de experiencia en el modelado.

PELIGROS EN EL DISEÑO DE BASES DE DATOS RELACIONALES

Ø El sistema de base de datos no sufra de anomalías de almacenamiento.
Ø El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.


Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en un ambiente dinámico, que una base de datos con un diseño pobre.

Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma.

Ø Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.
Ø Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes.
Ø Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.
Ø Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.

Pasos de la normalización:

Descomponer todos los grupos de datos en registros bidimensionales.
Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro.
Eliminar todas las relaciones que contengan dependencias transitivas.

Formas normales.

Son las técnicas para prevenir las anomalías en las tablas.



Primera forma normal.

Definición formal: Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.


Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.
Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.
Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.

Segunda forma normal.

Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s).


La segunda forma normal se representa por dependencias funcionales como:

TERCERA FORMA NORMAL Y LA FORMA NORMAL DE BOYCE CODD
Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional).

Definición formal: Una relación R está en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria.

Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos:

Determinante
Uno o más atributos que, de manera funcional, determinan otro atributo o atributos.

Definición formal
Una relación R esta en FNBC si y solo si cada determinante es una llave candidato.

Gráficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:

CUARTA Y QUINTA FORMAS NORMALES


Cuarta forma normal


Definición formal
Un esquema de relaciones R está en 4FN con respecto a un conjunto D de dependencias funcionales y de valores múltiples.

Sí, para todas las dependencias de valores múltiples en D de la forma X->->Y, donde X<=R y Y<=R, se cumple por lo menos una de estas condiciones:

v X->->Y es una dependencia de valores múltiples trivial. X es una superllave del esquema R.


Para nuestro ejemplo, las tablas correspondientes son:

Tabla Especialidad

Clave
Especialidad
S01
Sistemas
B01
Bioquímica
C03
Civil

Tabla Curso

Clave
Curso
S01
Natación
S01
Danza
B01
Guitarra
C03
Natación


QUINTA FORMA NORMALDefinición formal
Un esquema de relaciones R está en 5FN con respecto a un conjunto D de dependencias funcionales, de valores múltiples y de producto, si para todas las dependencias de productos en D se cumple por lo menos una de estas condiciones:

v (R1, R2, R3,... Rn) es una dependencia de producto trivial. Toda Ri es una superllave de R.