CLIENTE SERVIDOR1. 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/ServidorNormalmente 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.
