Universidad De Costa Rica Facultad De Ingeniería Escuela De Ingeniería Eléctrica

Transcript

Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica IE – 0502 Proyecto Eléctrico DESARROLLO DEL PROGRAMA “ESTIMADOR DE OBRAS ELECTRICAS” EN LENGUAJE JAVA Por: Miguel Ortega Álvarez Ciudad Universitaria Rodrigo Facio Diciembre del 2010 DESARROLLO DEL PROGRAMA “ESTIMADOR DE OBRAS ELECTRICAS” EN LENGUAJE JAVA Por: MIGUEL ORTEGA ALVAREZ Sometido a la Escuela de Ingeniería Eléctrica de la Facultad de Ingeniería de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERÍA ELÉCTRICA Aprobado por el Tribunal: _________________________________ Ing. Juan Ramón Rodríguez Solera Profesor Guía _________________________________ Ing. Luis Fernando Andrés Jácome Profesor lector _________________________________ Ing. Wagner Pineda Rodríguez Profesor lector ii ÍNDICE GENERAL ÍNDICE GENERAL.......................................................................................iii ÍNDICE DE FIGURAS....................................................................................v NOMENCLATURA........................................................................................vi RESUMEN......................................................................................................vii CAPÍTULO 1: Introducción...........................................................................1 1.1 Objetivos...........................................................................................................................2 1.1.1Objetivo general......................................................................................................2 1.1.2Objetivos específicos..............................................................................................2 1.2 Metodología......................................................................................................................3 CAPITULO 2: Bases de Datos........................................................................4 2.1Conceptos básicos de los sistemas de bases de datos........................................................6 2.2 Modelado de datos con el enfoque Entidad-Relación (ER)...........................................8 2.2.1Entidades y atributos...............................................................................................9 2.2.2 Relaciones............................................................................................................13 2.3 El modelado de datos relacional..................................................................................16 2.3.1Restricciones del modelo relacional......................................................................18 2.4 Transformación ER-Relacional...................................................................................21 2.4.1Algoritmo de transformación ER-Relacional........................................................22 2.5 SQL..............................................................................................................................25 2.5.1SQL: Un lenguaje no procedimental.....................................................................27 2.6 Diseño de la BD del programa presupuestador............................................................29 CAPÍTULO 3: Conexión a bases de datos...................................................31 3.1Máquina Virtual de Java (JVM) .....................................................................................31 3.1.1Distribución de la aplicación.................................................................................32 ......................................................................................................................................32 3.2Arquitectura Cliente/ Servidor.........................................................................................32 3.2.1Arquitectura cliente/ servidor de dos capas..........................................................33 3.3API JDBC.......................................................................................................................35 3.3.1URLs en JDBC......................................................................................................38 3.3.2Código JDBC........................................................................................................39 CAPÍTULO 5: Conclusiones y recomendaciones........................................42 5.1 Conclusiones...............................................................................................................42 iii 5.2 Recomendaciones.......................................................................................................43 BIBLIOGRAFÍA............................................................................................45 ANEXO 1........................................................................................................46 ANEXO 2........................................................................................................48 iv ÍNDICE DE FIGURAS Figura 2.1 Entorno simplificado de un sistema de bases de datos [1]................................5 Figura 2.2 Esquema ilustrativo de una base de datos..........................................................7 Figura 2.3 Diagrama de esquema ER................................................................................12 Figura 2.4 Relación con razón de cardinalidad 1: N.........................................................15 Figura 2.5 Relación Cliente...............................................................................................17 Figura 2.6 Relaciones con restricciones de integridad referencial....................................21 Figura 2.7 Resultado de la transformación ER-Relacional a la figura 2.3........................25 Figura 2.8 Diagrama ER de la BD para el programa estimador.......................................29 Figura 2.9 Modelo relacional para el programa estimador...............................................30 v NOMENCLATURA API Application Programming Interface BD Base de Datos DBMS Data Base Management System DDL Data Definition Language DML Data Manipulation Language ER Modelo Entidad-Relación FK Foreign Key GUI Graphic User Interface IDE Integrated Development Environment JAR Java Archive JDBC Java Data Base Connectivity JDK Java Development Kit JRE Java Runtime Environment JVM Java Virtual Machine PK Primary Key SQL Structure Query Language URL Uniform Resource Locator vi RESUMEN Cuando un procedimiento o cálculo se realiza con mucha frecuencia, puede ser conveniente programarlo para facilitar su uso, ahorrar tiempo y evitar errores. Por ello se desea desarrollar un programa distribuible en lenguaje Java que realice presupuestos para obra eléctrica, basado en cálculos simples que utilizan el costo del material y los índices de labor; los índices de labor son un aproximado del tiempo que tarda personal calificado en instalar los diferentes materiales que se utilizan en las obras eléctricas. Para facilitar el desarrollo de la aplicación, se utilizan bases de datos, que servirán para almacenar información de clientes, de proyectos, materiales, y la información necesaria para calcular los presupuestos. La base de datos debe ser accesible y manipulable desde el programa informático, el cual debe poseer una interfaz gráfica para interacción con el usuario. Para el desarrollo del proyecto, se utilizan herramientas computacionales que permiten la elaboración de esquemas de bases de datos y de interfaces gráficas de usuario en forma simple y rápida, como los programas MySQL Workbench y el NetBeans IDE. Se logró obtener una base de datos que cumple con los requerimientos de datos del programa, y se lograron algunas de las funciones básicas de conexión entre la base de datos y el programa, como insertar información a la base de datos, desplegar información de la base de datos en forma de lista y en forma de tabla, además de realizar los cálculos de presupuestos. Con esta metodología de desarrollo, se pueden obtener programas similares para muchas aplicaciones de la ingeniería. vii CAPÍTULO 1: Introducción Se pretende crear una herramienta que estime el presupuesto para obras eléctricas de una manera fácil, rápida y confiable, y tratar de reducir la subjetividad con que se calcula la mano de obra actualmente. Hasta ahora, gracias al aporte de estudiantes en semestres pasados, se cuenta con un programa con una interfaz gráfica amigable para el usuario y con una funcionalidad de estimación básica. Sin embargo, para que el programa funcione, se necesita primero diseñar una base de datos relacional que cumpla con los requerimientos de datos de la aplicación, por ejemplo información de los materiales, registros de clientes y proyectos, además de toda la información necesaria para realizar los cálculos. La base de datos se crea y se manipula con un tipo de software muy específico, conocido como DBMS (Data Base Management System), que además sirve de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de módulos como compiladores del lenguaje SQL (lenguaje estándar en bases de datos), optimizadores de consultas, y procesadores de datos, que administran automáticamente la gestión de las bases de datos. Existen muchos DBMS comerciales, aunque se utilizará el MySQL por ser uno de los más difundidos y además por ser de libre acceso. Para conectar la aplicación con el DBMS, se utiliza una interfaz conocida como API JDBC, el cual es un programa que provee acceso a las bases de datos desde el código fuente 1 escrito en Java. Con el API se pueden ejecutar instrucciones en SQL, actualizaciones o cambios en los datos y recuperación de registros, desde el lenguaje huésped (Java). 1.1 Objetivos 1.1.1 Objetivo general Completar el desarrollo del programa “Estimador de obras eléctricas” en lenguaje JAVA 1.1.2 Objetivos específicos • Aplicar las técnicas de estimación de costos de obras eléctricas en el programa informático. • Establecer el procedimiento para la creación de una base de datos basada en MySQL compatible con los requerimientos del programa. • Establecer los métodos para conectar la aplicación con la base de datos. • Estudiar e investigar la posibilidad de la distribución del programa en disco compacto. 2 1.2 Metodología Para la realización del proyecto se necesita adquirir cierto dominio de los conceptos relacionados con bases de datos, así como de varias herramientas computacionales. Parte fundamental del trabajo será el estudio bibliográfico relacionado con la teoría de bases de datos, así como el uso de los programas MySQL, MySQL Workbench y NetBeans IDE, de los cuales se consultará la ayuda que brindan y se estudiarán tutoriales e información que brindan los respectivos fabricantes en el Internet. De esta forma se pretende adquirir la habilidad para la elaboración de bases de datos, y así definir un esquema que se adecue al que necesita el programa. Seguidamente, se investigará y estudiará el procedimiento para establecer conexiones entre aplicaciones y bases de datos, para luego aplicarlo con el programa existente y el esquema de base de datos recién creada. Para esto se estudiará la lógica y estructura de los bloques de código que realizan tal función dentro de la aplicación, así como el lenguaje Java. Realizada la conexión, se debe determinar la fuente de falla del programa y tratar de solucionarlo. Por último, cuando el programa esté funcionando lo que procedería es el llenado de la base de datos con información de materiales utilizados en la industria eléctrica nacional y que satisfaga los requerimientos generales de cualquier usuario. También se ideará una manera de posibilitar la distribución de la aplicación en disco compacto. 3 CAPITULO 2: Bases de Datos Las bases de datos y su tecnología desempeñan un papel muy importante en todas las áreas de aplicación de las computadoras, como los negocios, la ingeniería, la medicina, y la educación, por mencionar unas cuantas. El término bases de datos es tan común que se debe comenzar por qué quiere decir: Es un conjunto de datos relacionados entre sí, que poseen las siguientes características: • Representa algún aspecto del mundo real, llamado minimundo. Las modificaciones del minimundo se reflejan en la base de datos. • Es un conjunto de datos lógicamente coherente, con cierto significado inherente. Una colección aleatoria de datos no puede considerarse una base de datos. • Toda base de datos se diseña, construye y se llena con datos para un propósito específico. Está dirigida a un grupo de usuarios y tiene ciertas aplicaciones que interesan a dichos usuarios. [1] Las bases de datos pueden ser de cualquier tamaño y tener diversos grados de complejidad, desde una simple lista de nombres y direcciones hasta las que tienen las autoridades fiscales para llevar el control de las declaraciones fiscales. Las bases de datos computarizadas se crean y mantienen con un grupo de programas de aplicación escritos específicamente para esa tarea, llamado Sistema de Gestión de Bases de Datos (DBMS, Data Base Management System). El DBMS facilita el proceso de definir, construir y manipular bases de datos para diversas aplicaciones. En la figura 2.1 se puede 4 apreciar el esquema general, en donde el DBMS sirve como interfaz entre la base de datos y los programas de aplicación y los usuarios. El catálogo (metadatos) contiene información sobre los datos, como el tipo y formato de almacenamiento de cada elemento. El catálogo “son datos que describen otros datos”. Figura 2.1 Entorno simplificado de un sistema de bases de datos [1] Un DBMS consta de diversos componentes o módulos, como los módulos para implementar el catálogo, los lenguajes de consulta, los procesadores de interfaz, el acceso a 5 los datos y la seguridad. Debe poder comunicarse con otros programas del sistema, como el sistema operativo y los compiladores de diversos lenguajes de programación. Existen varios DBMS libres y no libres, entre los que encontramos: Libres: - MySQL - DB2 - PostgreSQL - Apache Derby - SQLite No libres: 2.1 - Microsoft SQL Server - Oracle - Microsoft Access Conceptos básicos de los sistemas de bases de datos Un modelo de datos es un conjunto de conceptos que pueden servir para describir la estructura de una base de datos. Una estructura de base de datos son los tipos de datos, los vínculos y las restricciones que deben cumplirse para esos datos. Los modelos de datos de alto nivel o conceptuales disponen de conceptos muy cercanos al modo como los usuarios perciben los datos. Estos utilizan conceptos como entidades, atributos y vínculos. Una entidad representa un objeto o concepto del mundo real, por ejemplo un cliente o un proyecto; un atributo representa alguna propiedad de 6 interés que da una descripción más amplia de una entidad, como nombre o edad. Un vínculo o relación describe una interacción entre dos o más entidades, por ejemplo el vínculo “Se le presupuesta” entre un cliente y un proyecto. En cualquier modelo de datos es importante distinguir entre la descripción de la base de datos y la base de datos misma. La descripción se conoce como esquema de la base de datos (o metadatos). En la figura 2.2 se presenta un diagrama simplificado del esquema para la base de datos del programa presupuestador, con las entidades Cliente, Proyecto y Material, y sus respectivos atributos. Cliente Nombre Email Teléfono Proyecto NombreP Nivel_Dificultad Salarioxhora Material NombreM Indice_Labor Costo Unitario Figura 2.2 Esquema ilustrativo de una base de datos Este esquema se especifica durante el diseño y no es de esperar que se modifique muy a menudo. En cambio, los datos reales de la base de datos pueden cambiar con mucha 7 frecuencia cada vez que se agregan o actualizan registros. Los datos que la base de datos contiene en un determinado momento se denominan estado de la base de datos. Cuando definimos una nueva base de datos, sólo especificamos su esquema al DBMS. En ese momento, el estado correspondiente de la base de datos es el estado vacío, sin datos. Cuando cargamos éstos, la base de datos pasa al estado inicial. De ahí en adelante, siempre que se aplique una operación de actualización a la base de datos, tendremos otro estado. El DBMS se encarga de asegurar que todos los estados sean estados válidos; esto es, que satisfagan la estructura y las restricciones especificadas en el esquema. El DBMS almacena el esquema en su catálogo, de modo que pueda consultarlo siempre que necesite hacerlo. [1] Los modelos de datos se clasifican como relacionales, de red, jerárquicos, y orientado a objetos. El mas ampliamente utilizado en la actualidad y en el que se va a basar este proyecto es el relacional, el cual representa la base de datos como una colección de tablas que se pueden almacenar como archivos individuales. [1] 2.2 Modelado de datos con el enfoque Entidad-Relación (ER) El modelo Entidad-Relación (ER) es un modelo de datos conceptual de alto nivel muy utilizado. Este modelo se emplea a menudo en el diseño conceptual de aplicaciones de bases de datos, y muchas herramientas de diseño de bases de datos aplican sus conceptos. El modelo ER describe los datos como entidades, atributos y vínculos o relaciones. 8 2.2.1 Entidades y atributos El objeto básico que se representa en el modelo ER es la entidad: “algo” del mundo real con existencia independiente. Una entidad puede ser un objeto con existencia física (una persona, un automóvil, una casa o un empleado) o un objeto con existencia conceptual, como una compañía, un puesto de trabajo o un proyecto. El tipo de entidad define a una colección de instancias que tienen los mismos atributos y se representa en los diagramas ER por medio de rectángulos que encierran el nombre del tipo de entidad (ver figura 2.3). [1] Cada entidad tiene propiedades específicas, llamadas atributos, que la describen. Por ejemplo, una entidad Cliente puede describirse por su nombre, dirección, teléfono, y correo electrónico. Una instancia de la entidad tendrá un valor para cada uno de sus atributos. En el modelo ER se manejan varios tipos distintos de atributos: simples o compuestos, monovaluados o multivaluados, y almacenados o derivados. El nombre del atributo se encierra en un óvalo en el diagrama ER y se conectan con su tipo de entidad con líneas rectas (ver figura 2.3). Los atributos compuestos se pueden dividir en atributos simples más pequeños. Por ejemplo el atributo NombreCompleto se puede dividir en los atributos simples Nombre, Apellido1 y Apellido2. Los atributos simples no son divisibles y también se llaman atómicos. En su mayoría, los atributos tienen un solo valor para una entidad en particular, y reciben el calificativo de atributos monovaluados. Sin embargo, hay casos en los que es 9 necesario un atributo multivaluado, que puede tener un conjunto de valores para la misma entidad. Por ejemplo, el atributo Teléfonos para la entidad Cliente es multivaluado ya que un cliente puede tener varios teléfonos donde contactarlo, pero el atributo Edad es monovaluado ya que una persona solo puede tener una edad. En algunos casos se relacionan dos o más valores de atributos; por ejemplo, los atributos Edad y FechaNacimiento de una persona. Para una entidad Persona en particular, el valor de Edad se puede determinar a partir de la fecha actual y el valor de FechaNacimiento de esa persona. Por tanto, se dice que el atributo Edad es un atributo derivado, y que es derivable del atributo FechaNacimiento, el cual es un atributo almacenado. Cada uno de los atributos de un tipo de entidades está asociado a un conjunto de valores (o dominio), que especifica los valores que es posible asignar a ese atributo para cada instancia de la entidad. [1] En algunos casos, una cierta entidad podría no tener ningún valor aplicable para un atributo. Por ejemplo, el atributo NumDpto de una dirección sólo se aplica a direcciones que corresponden a edificios de departamentos o condominios, pero no a otro tipo de residencias. En situaciones de este tipo se crea un valor especial llamado nulo. Los atributos se definen nulos cuando: su valor existe pero puede ser desconocido, su valor no aplica para una entidad particular, o si no se sabe si el valor existe. [1] Atributos clave de un tipo de entidades: Una restricción importante de un tipo de entidad es la restricción de clave o unicidad. Los tipos de entidades deben tener un atributo 10 cuyo valor es distinto para cada instancia o entidad individual. Los atributos de esta naturaleza se denominan atributos clave o llave primaria, y sus valores sirven para identificar de manera única a cada entidad. El atributo Cédula es una clave del tipo de entidad Cliente, ya que no hay dos clientes con el mismo número de cédula. El atributo CorreoElectrónico también es una clave o llave primaria de Cliente. Cuando existen varios atributos que pueden servir como llave primaria, cada atributo se le conoce como llave candidata. Hay ocasiones en que varios atributos juntos constituyen una clave, o sea que la combinación de los valores de los atributos es distinta para cada entidad individual. En la notación de los diagramas ER, el nombre de todo atributo clave aparece subrayado dentro del óvalo. Los conceptos anteriores son muy importantes a la hora de diseñar la base de datos. En la figura 2.3 se ilustra una propuesta de diagrama ER para la base de datos del programa estimador. 11 IdProyect o SalarioxHor a Email Nombre PROYECTO Se Le Presupuesta CLIENTE 1 N presupuesta N Telefon o Cantidad Nombr e Se Compone De IdMaterial Nombr e M MATERIAL CostoUnitario Figura 2.3 Diagrama de esquema ER El diseño de la base de datos es la construcción del esquema ER. Para esto, los diseñadores entrevistan a los futuros usuarios de la base de datos para entender y documentar sus requerimientos de información. En paralelo con la especificación de los requerimientos de datos, conviene especificar los requerimientos funcionales conocidos de la aplicación. Estos consisten en las operaciones definidas por el usuario que se aplicarán a 12 la base de datos, e incluyen la obtención de datos y la actualización. Como se verá luego, se utiliza un algoritmo simple para pasar del modelo ER al modelo relacional que utiliza el DBMS. En la figura 2.3 hay vínculos o relaciones entre los diversos tipos de entidades. De hecho, siempre que un atributo de un tipo de entidades hace referencia a otro tipo de entidad, hay alguna relación. 2.2.2 Relaciones Un tipo de relación entre n tipos de entidades define un conjunto de asociaciones entre entidades o instancias de estos tipos. En la figura 2.3 se observa el tipo de relación “Se le presupuesta” que define las asociaciones entre el cliente y cada uno de los proyectos que se le presupuesta. El grado de la relación es el número de entidades que participan en la relación; en nuestro diagrama solo existen relaciones binarias o de grado dos y serán las únicas necesarias para este proyecto. En los diagramas ER, los tipos de relación se representan con rombos conectados mediante líneas rectas con los rectángulos que representan a los tipos de entidades participantes en la relación. 13 Restricciones estructurales: Los tipos de relaciones típicamente tienen ciertas restricciones que limitan las posibles combinaciones de entidades que pueden participar en las instancias de relación (Las instancias de relación son las ri de la figura 2.4, mientras que las instancias de entidades son las ci y las p i en la misma figura). Existen dos tipos de restricciones de relación: 1) Razón de cardinalidad: Especifica cuantas entidades de un tipo pueden estar asociadas con las entidades del otro tipo que participa en la relación y viceversa. Las razones de cardinalidad se especifican como 1: N, N: 1, M: N y algunas veces 1: 1. En la figura 2.3 se observan razones de 1:N y M: N. 2) Restricción de participación: Especifica si la existencia de una entidad depende de que esté relacionada con otra entidad a través del tipo de relación. Visto de otra manera especifica el número mínimo de instancias de entidades que deben participar en la relación. Existen dos tipos de restricciones de participación: • Total: Todas las entidades del conjunto de entidades tienen que participar en la relación. También se conoce como dependencia de existencia. Se representa en el diagrama con una doble línea que conecta la relación con la entidad. • Parcial: Sólo un subconjunto del conjunto de entidades participa en la relación. [1] 14 Cliente Se Le Presupuesta Proyecto r1 p1 r2 p2 r3 p3 r4 p4 c1 c2 Figura 2.4 Relación con razón de cardinalidad 1: N Atributos de las relaciones: Los tipos de relación, al igual que los tipos de entidad, pueden tener atributos. Sin embargo, los atributos de los tipos de relación 1: 1 pueden migrar hacia uno de los tipos de entidad participantes, preferiblemente a la que tiene la participación total, y los atributos de los tipos de relación 1: N pueden migrar sólo hacia la entidad que participa en el lado N de la relación. En el caso de los tipos de relación M: N tales atributos deberán especificarse como atributos de la relación. Todo esto se verá más claro cuando se utilice el algoritmo de transformación ER-Relacional. 15 2.3 El modelado de datos relacional El modelo relacional de los datos fue introducido por Edgar Frank Codd de los laboratorios IBM en 1970. Se basa en una estructura de datos simple y uniforme –la relación- y tiene fundamentos teóricos sólidos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. El modelo relacional está íntimamente relacionado con el modelo ER, por lo que se aplican muchos de sus conceptos. Para evitar confusiones, en el modelo ER una relación define asociaciones entre tipos de entidades (representados en el diagrama por rombos), mientras que en el modelo relacional una relación debe ser visualizada como una tabla de valores. Cada tipo de entidad en el modelo ER es ahora una relación (tabla) en el modelo relacional que se llama como el tipo de entidad, y los atributos de la entidad nombran cada columna de la relación. De esta manera, cada fila o tupla representa una colección de valores de datos relacionados entre sí o instancias. En la figura 2.5 se observa la relación Cliente obtenida del modelo ER, junto con su estado. 16 Atributos Cliente Email Nombre Teléfono alvarez@mail Ana Álvarez 22334455 manuel@mail Manuel Palacios 44556677 will@mail Will Soto 66557788 Figura 2.5 Relación Cliente Un esquema de relación R, denotado por R ( A1 , A2 ,..., An ), se compone de un nombre de relación, R, y una lista de atributos A1 , A2 ,..., An . Un esquema de relación sirve para describir la relación. El grado de una relación es el número de atributos, n, de su esquema de relación. [1] Un ejemplar de relación en un momento dado (el estado actual de la relación) refleja solo las tuplas validas que representan un estado específico del mundo real. En general, a medida que cambia el estado del mundo real, se debe cambiar la relación correspondientemente, transformándose en otro estado de la relación. Sin embargo, el esquema R es relativamente estático, y no cambia con frecuencia; lo hace, por ejemplo, 17 cuando se añade un atributo para representar información nueva que no estaba representada originalmente en la relación. [1] 2.3.1 Restricciones del modelo relacional En un esquema de base de datos relacional se pueden especificar diversos tipos de restricciones. Entre estas restricciones se cuentan las de dominio, de clave, de integridad de entidades y de integridad referencial. Restricciones de Dominio: Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor atómico del dominio para ese atributo. El dominio debe tener un nombre lógico, un tipo de datos y un formato. Los tipos de datos asociados a los dominios por lo regular incluyen los tipos de datos numéricos estándar de los números enteros y reales. También se dispone de caracteres, cadenas de longitud fija y cadenas de longitud variable, así como tipo de datos de fecha, hora, tiempo y dinero. Es posible describir los dominios mediante un subintervalo de valores de un tipo de datos. Restricciones de clave: Por definición, todas las tuplas de una relación deben ser distintas, lo que significa que no puede haber dos tuplas que tengan la misma combinación de valores para todos sus atributos. Existen subconjuntos de atributos de un esquema de relación R, denominados superclave, con la propiedad de que no existen dos tuplas con la misma combinación de valores para estos atributos. Toda relación tiene por lo menos una superclave: el conjunto de todos sus atributos. Sin embargo, un concepto más importante es 18 el de clave o llave primaria PK, que es una superclave con la propiedad adicional de que la eliminación de cualquier atributo A deja un conjunto de atributos que ya no es una superclave de R. En otras palabras, es una superclave mínima, a la cual no podemos quitarle atributos sin que deje de cumplirse la restricción de unicidad. En general, un esquema de relación puede tener más de una clave; en tal caso, cada una de ellas se denomina clave candidata. La elección de una clave candidata para fungir como clave primaria es arbitraria; sin embargo, casi siempre es mejor escoger una clave primaria con un solo atributo o un número reducido de atributos. Se adopta la convención de subrayar los atributos que forman clave primaria de un esquema de relación, como en la figura 2.5. Restricción de integridad de entidades: Establece que ningún valor de llave primaria puede ser nulo. Esto es porque el valor de la clave primaria sirve para identificar las tuplas individuales en una relación; el que la llave primaria tenga valores nulos implica que no podemos identificar o distinguir algunas tuplas. Restricción de integridad referencial: Las restricciones anteriores se especifican sobre relaciones individuales, en tanto que la restricción de integridad referencial se especifica entre dos relaciones. Una base de datos relacional suele contener muchas relaciones y en éstas las tuplas están relacionadas de diversas maneras para mantener la consistencia entre sus tuplas. [1] La integridad referencial se basa en el uso de llaves externas (foreign keys). Una llave externa FK de una relación R que referencia a otra relación S es un conjunto de 19 atributos de R cuyo dominio es el mismo que el de los atributos de la llave primaria de S, y cuyo valor para toda tupla de R es igual al valor de la llave primaria de alguna tupla de S. En otras palabras, la llave externa FK es en una sola dirección, sólo una relación o tabla referencia a la otra y las llaves externas sólo se deben referir a atributos clave primaria existentes. Existe una llave externa en una relación R cuando la llave primaria de otra relación S existe en R. La llave externa en R por su parte puede o puede que no sea la llave primaria de R: 1) Vínculos identificadores: Cuando la llave externa es incluida como clave primaria. Se dan en las relaciones M: N. 2) Vínculos no identificadores: Cuando la llave externa no es incluida como llave primaria. Se dan en las relaciones 1: N. Se permite que un atributo que represente el mismo concepto del mundo real tenga nombres que pueden o no ser idénticos en diferentes relaciones. De manera similar, se permite que atributos que representen diferentes conceptos tengan el mismo nombre en relaciones distintas. En la figura 2.6 se ilustran los conceptos relacionados con restricciones de integridad referencial. 20 Cliente Email Nombre Teléfono Proyecto IdProyecto Nombre SalarioxHora EmailCliente(FK) Material IdMaterial Nombre CostoUnitario Se Compone De IdProyecto(FK) IdMaterial(FK) Cantidad Figura 2.6 Relaciones con restricciones de integridad referencial 2.4 Transformación ER-Relacional Como se mencionó anteriormente, los diseñadores de bases de datos consultan a los futuros usuarios de la aplicación para determinar las necesidades de datos de éstos; a partir de la información recopilada se crea un diagrama ER. Desde muchas herramientas computacionales se puede crear el esquema ER gráficamente, y luego se convierte automáticamente en un esquema de base de datos relacional expresado en lenguaje SQL. 21 También existen herramientas como SQL Workbench que convierte automáticamente el diagrama de esquema relacional al esquema de base de datos expresado en lenguaje SQL, para lo que es necesario convertir primero el diagrama ER al esquema relacional. A continuación se presenta un algoritmo que se utiliza para convertir un diagrama ER al esquema de base de datos relacional correspondiente. 2.4.1 Algoritmo de transformación ER-Relacional El algoritmo es el siguiente: Paso 1: Por cada tipo de entidad E del esquema ER, se crea una relación R que contenga todos los atributos simples de E, incluyendo sólo los atributos simples componentes de un atributo compuesto. Se elige uno de los atributos clave de E como clave primaria de R. Si la clave elegida es compuesta, el conjunto de atributos simples que la forman constituirá la clave primaria de R. Paso 2: Por cada tipo de entidad débil D del esquema ER con tipo de entidad dominante E, se crea una relación R y se incluyen todos los atributos simples (o componentes simples de los atributos compuestos) de D como atributos de R. Además, se incluyen como atributos de clave externa de R los atributos de clave primaria de la relación dominante E. La clave primaria de R es la combinación de las claves primarias de las dominantes y la clave parcial de D, si existe. 22 Paso 3: Por cada tipo de vínculo binario 1: 1 R del esquema ER, se identifican las relaciones S y T que corresponden a los tipos de entidades que participan en R. Se escoge una de las relaciones (S) y se incluye como clave externa en S la clave primaria de T. Es mejor elegir un tipo de entidades con participación total en R en el papel de S. Se incluyen todos los atributos simples (o componentes simples de los atributos compuestos) del tipo de vínculos 1: 1 R como atributos de S. Cabe mencionar que las relaciones 1:1 son poco comunes. Paso 4: Por cada tipo de vínculos normal (no débil) binario 1: N R, se identifica la relación S que representa el tipo de entidad participante del lado N del vínculo R. Se incluye como clave externa en S la clave primaria de la relación T que representa al otro tipo de entidad que participa en R. Se incluyen todos los atributos simples (o componentes simples de los atributos compuestos) de R como atributos de S. Paso 5: Por cada tipo de vínculo binario M: N R, se crea una nueva relación S para representar R. Se incluyen como atributos de clave externa en S las claves primarias de las relaciones que representan los tipos de entidades participantes; su combinación constituirá la clave primaria de S. También se incluyen todos los atributos simples (o componentes simples de los atributos compuestos) del tipo de vínculos M: N R como atributos de S Paso 6: Por cada atributo multivaluado A se crea una nueva relación R que contiene un atributo correspondiente a A más el atributo de clave primaria K de la relación que representa el tipo de entidad o de vínculo que tiene a A como atributo. Se selecciona como 23 clave primaria de R a la combinación de A y K, y como llave externa a K. Si el atributo multivaluado es compuesto, se incluyen sus componentes simples. Paso 7: Por cada tipo de vínculos n-ario, n>2, se crea una nueva relación S que represente a R. Se incluyen como atributos de clave externa en S las claves primarias de las relaciones que representan los tipos de entidades participantes. También se incluyen los atributos simples (o los componentes simples de los atributos compuestos) del tipo de vínculos n-ario como atributos de S. La clave primaria de S es la combinación de todas las claves externas que hacen referencia a las relaciones que representan los tipos de entidades participantes. [1] Según cada diagrama ER y sus características los pasos anteriores son o no son aplicables, por lo que en una transformación específica se pueden saltar varios pasos. Por ejemplo, para el diagrama ER de la figura 2.3, los pasos 2, 3, 6 y 7 no son aplicables. En la figura 2.7 se observa el esquema relacional obtenido de la transformación ER-Relacional aplicado al diagrama ER de la figura 2.3 CLIENTE (Email, Nombre, Teléfono) PROYECTO (IdProyecto, Nombre, SalarioxHora, EmailCliente (FK a Cliente)) MATERIAL (IdMaterial, Nombre, CostoUnitario) SE COMPONE DE (IdProyecto (FK a Proyecto), IdMaterial (FK a Material), Cantidad) Figura 2.7 Resultado de la transformación ER-Relacional a la figura 2.3 24 En la figura 2.7 se obtuvieron las relaciones “Cliente”, “Proyecto” y “Material” con sus atributos y llaves primarias del paso 1 del algoritmo, excepto la llave externa de “Proyecto” que se obtuvo del paso 4. La llave externa “EmailCliente” es la llave primaria “Email” de la relación “Cliente”, pero se le cambió el nombre para resaltar que se refiere a “Cliente”. La relación “Se Compone” se obtuvo del paso 5, y contiene “IdProyecto” como llave externa a “Proyecto” e “IdMaterial” como llave externa a “Material”, y su combinación conforma la llave primaria de la relación. Además se incluye el atributo “Cantidad”. De esta transformación se obtuvo la figura 2.6 en primer lugar. Además, se observa que la llave externa de “Proyecto” es no identificadora, mientras que la llave externa de “Se Compone De” es identificadora. 2.5 SQL Junto con la definición de modelo relacional, Edgar Frank Codd propuso un lenguaje llamado DSL/Alpha para manipular los datos en las tablas relacionales. Poco después, IBM conformó un grupo de especialistas para construir un prototipo basado en las ideas de Codd. Este grupo creó una versión simplificada de DSL/Alpha que llamaron 25 SQUARE. Refinamientos de SQUARE llevaron a un lenguaje llamado SEQUEL que fue, finalmente, renombrado SQL. SQL ha sido cambiado frecuentemente a través del tiempo. A mediados de 1980, la American National Standards Institute (ANSI) empezó a trabajar en el primer estándar para el lenguaje SQL, que fue publicado en 1986. Subsecuentes mejoras llevaron a nuevas versiones del estándar SQL en 1989, 1992, 1999, 2003 y 2006. [4] El resultado de una consulta SQL es una tabla, llamada result set. Una nueva tabla permanente puede ser creada en una base de datos relacional almacenando el result set de una consulta. Similarmente, tanto tablas permanentes como results sets pueden ser consultados en el DBMS. El lenguaje SQL se divide en distintas partes: • DDL (Data Definition Language): Es el lenguaje de definición de datos que permite especificar la estructura de los datos almacenados en la BD. Estos elementos son almacenados en unas tablas especiales conocidas como metadatos o diccionario de datos. • DML (Data Manipulation Language): Es el lenguaje de manipulación de datos que permite recuperar, insertar, borrar y modificar los datos almacenados. • DQL (Data Query Language): Cuando el DML es usado de forma interactiva fuera de un lenguaje de programación se le llama lenguaje de consulta de datos. 26 • DCL (Data Control Language): Lenguaje de control de datos que permite controlar el acceso a los recursos de sistema. • VDL (View Definition Language): Es el lenguaje de definición de vistas que permite especificar las vistas de usuario y su correspondiente mapeo al esquema conceptual. En la mayoría de DBMS se usa el DDL como VDL. En general, las sentencias o comandos DDL no requieren mucha discusión aparte de la sintaxis. Por su parte las sentencias DML, aunque pocas (select, update, insert y delete), ofrecen numerosas oportunidades de estudio detallado. 2.5.1 SQL: Un lenguaje no procedimental En los lenguajes de programación como Java o C++, se definen variables y estructuras de datos, se utiliza lógica condicional (if-then-else) e iteraciones (for-while), y se parte el código en pequeñas piezas reutilizables (métodos-funciones). El código se compila, y el ejecutable que resulta hace exactamente lo que se le programa a hacer. Estos son lenguajes procedimentales en los que se está en completo control de lo que el programa hace. Un lenguaje procedimental define los resultados deseados y el mecanismo o proceso por el que los resultados son generados. En cambio, un lenguaje no procedimental 27 también define los resultados deseados, pero el proceso por el que son generados se deja a un agente externo. [4] Con SQL, se debe ceder parte del control, ya que la manera en que una sentencia es ejecutada se deja a un componente del DBMS llamado optimizador. El optimizador mira la sentencia SQL, y tomando en consideración como están configuradas las tablas decide el camino más eficiente de ejecución. [4] Si solo se necesitan ejecutar comandos SQL interactivamente, cada vendedor de DBMS provee al menos una herramienta de comandos simple para enviar las sentencias SQL al motor de la base de datos. La mayoría de los vendedores proveen una herramienta gráfica que incluye una ventana que muestra los comandos SQL y otra ventana distinta que muestra los resultados de éstos. Para escribir una aplicación completa, se debe integrar SQL con alguno de los lenguajes de programación conocidos. [4] 28 2.6 Diseño de la BD del programa presupuestador El siguiente es el diseño de la base de datos para el programa estimador: NivelDificulta d IdP Emai l IdC CLIENTE NombreP 1 N Se Le SalarioxHora PROYECTO Presupuesta Presupuest o presupuesta Telefon o Nombre C Se Compone De Cantidad IdM N M MATERIAL IndiceLabor CostoUnitario N NombreM UnidadMedida SeClasificaPor 1 IdF FAMILIA NombreF Figura 2.8 Diagrama ER de la BD para el programa estimador 29 Se observa del diagrama que un cliente puede tener varios proyectos asociados, y que todo proyecto debe estar necesariamente asociado a un cliente (indicado por la doble línea). Un proyecto se compone de varios materiales, y varios materiales pueden estar asociados a varios proyectos. A su vez, varios materiales están clasificados dentro de una familia. Las entidades anteriores tienen sus atributos correspondientes. La figura 2.9 muestra el mapeo ER-Relacional luego de utilizar el algoritmo de transformación, y en el anexo 2 se encuentra el código correspondiente para implementarlo en MySQL. CLIENTE (IdC, NombreC, Teléfono, Email) PROYECTO (IdP, Presupuesto, NombreP, SalarioxHora, NivelDificultad, IdC (FK a Cliente)) MATERIAL (IdM, NombreM, CostoUnitario, IndiceLabor, UnidadMedida, IdF (FK a Familia)) SE COMPONE DE (IdP (FK a Proyecto), IdM (FK a Material), Cantidad) FAMILIA (IdF, NombreF) Figura 2.9 Modelo relacional para el programa estimador 30 CAPÍTULO 3: Conexión a bases de datos 3.1 Máquina Virtual de Java (JVM) Se dice que los programas escritos en Java son portables, porque pueden ser ejecutados sin cambio alguno en diversos sistemas operativos a través de la Máquina Virtual de Java (JVM), que interpreta y traduce el bytecode al sistema operativo. Cuando la compilación de un programa es exitosa, se crea la versión compilada del archivo fuente llamada bytecode (código byte). El nombre del archivo bytecode generado por el compilador tendrá el sufijo .class, mientras que el prefijo es el mismo que el del código fuente. A diferencia de las instrucciones del lenguaje de máquina o el código de máquina, el bytecode de Java no está atado a ningún sistema operativo o CPU en particular, lo que significa que es el mismo independientemente de la plataforma donde se genere. Lo único necesario para ejecutar los mismos programas Java en diferentes sistemas operativos es tener los intérpretes del bytecode para los sistemas operativos deseados. Un intérprete también es llamado Máquina Virtual de Java (JVM), porque es como una máquina virtual que ejecuta el bytecode, mientras el CPU es una máquina real que ejecuta el código de máquina. El JVM viene incorporado en el JRE (Java Runtime Environment), y se encarga de ejecutar los programas compilados (bytecode). Cada sistema operativo tiene su implementación correspondiente de JRE, que interpreta el bytecode para poder ser ejecutado en su lenguaje máquina. 31 3.1.1 Distribución de la aplicación Para poder distribuir la aplicación a los usuarios, se debe crear un disco compacto con los archivos necesarios. El disco debe llevar el instalador de MySQL, el cual es un archivo .msi que se descarga de la página web mysql.com, así como el ejecutable .JAR (Java Archive), que se crea desde el NetBeans IDE y que se compone de un comprimido del programa compilado y las clases y librerías que el programa utiliza. Los dos archivos anteriores es el software necesario para utilizar la aplicación, sin embargo el disco debe llevar también dos archivos pdf para las instrucciones de instalación de MySQL (Anexo 1), y para las instrucciones de uso del programa. También, se debe incluir un archivo Word que contenga el script tanto del esquema de la base de datos, como su estado (llenado de la relación “material”), que se carga desde MySQL. Este script se encuentra en el Anexo 2. 3.2 Arquitectura Cliente/ Servidor Los primeros sistemas de bases de datos fueron de arquitectura centralizada, donde la base de datos, el DBMS y las aplicaciones de usuario estaban en una misma computadora. Los usuarios accedían a estos sistemas por medio de terminales con muy baja capacidad de procesamiento que prácticamente sólo servían para visualizar la información enviada por el computador central o mainframe. Posteriormente, las terminales fueron reemplazadas por PCs y estaciones de trabajo, pero eran usadas de modo similar (sólo para visualización). 32 Gradualmente, los DBMS tomaron ventaja de la capacidad de procesamiento del lado del usuario, dando paso a las arquitecturas cliente/ servidor. [1] 3.2.1 Arquitectura cliente/ servidor de dos capas La arquitectura cliente/servidor se desarrolló para entornos de redes de computadoras donde existían máquinas cliente con cierta capacidad de procesamiento y máquinas servidor poderosas que ofrecían diferentes tipos de servicios. Servidores: máquinas con funcionalidades específicas. Pueden ser de diferentes tipos, por ejemplo: servidores de impresión, de archivos, de email, y DBMS. Los últimos se usan para todas las tareas relacionadas con la creación, manipulación y mantenimiento de bases de datos. Clientes: máquinas con capacidad de procesamiento local para ejecutar las aplicaciones locales y usar los servicios ofrecidos por las computadoras servidor. Cuando el servidor se utiliza como DBMS, los programas de interfaz de usuario y los programas de aplicación se ejecutan del lado del cliente. El cliente puede comunicarse con el DBMS siempre y cuando tenga instalado el software necesario y obtenga la conexión requerida (por medio de JDBC). El servidor ejecuta la funcionalidad de consulta y transacción, relacionada con el procesamiento de comandos SQL. Los componentes de software están, por ende, distribuidos en dos sistemas: cliente y servidor. [1] 33 También es posible tener las aplicaciones en el servidor. Algunas de las ventajas de de esta configuración son que: • Se pueden compartir entre diferentes usuarios. • Es más fácil optimizarlas y modificarlas. • Se puede restringir su uso a personas autorizadas con más facilidad. • Se puede guardar su versión ya compilada disminuyendo el tiempo de respuesta a la consulta. [1] También existe la arquitectura de tres capas, la cual contiene una capa intermedia entre el cliente y el servidor de la base de datos. En las aplicaciones web esta capa intermedia almacena las reglas de comercio (procedimientos o restricciones) que se usan para acceder a los datos del servidor de la BD. Esta capa agrega un nivel más de seguridad al comprobar los credenciales del cliente antes de enviar una solicitud al servidor. La capa de presentación es la interfaz de usuario y permite la entrada de datos, la capa lógica comercial maneja las reglas y restricciones comerciales, y la capa de servicios incluye todo lo referente a la administración de los datos. De lo anterior se desprende la capacidad de lograr mayores niveles de integración que utilizan el Internet para las comunicaciones e intercambio de información, con el uso de DBMS y aplicaciones portables. 34 3.3 API JDBC Una aplicación Java y una base de datos se comunican entre sí por medio del API JDBC. Un API (Application Programming Interface) es una interfaz implementada por un programa que permite la interacción con otro programa. JDBC (Java DataBase Connectivity) es un API incluido dentro del lenguaje Java para el acceso a bases de datos, y consiste en un conjunto de clases e interfaces escritos en Java que permiten interactuar con bases de datos. Debido a que JDBC está escrito completamente en Java, también posee la ventaja de ser independiente de la plataforma, mientras posea una JVM. Tampoco será necesario escribir un programa para cada DBMS; una misma aplicación que utilice JDBC podrá manejar bases de datos de Oracle, SQL Server o MySQL. El API JDBC viene incluido en el paquete java.sql. Básicamente el API JDBC hace posible las siguientes tareas: • Establecer una conexión con una base de datos • Enviar sentencias SQL • Manipular los datos • Procesar los resultados de la ejecución de las sentencias [3] La columna vertebral de JDBC es la clase Driver Manager (gestor de drivers), que se encuentra representado por la clase java.sql.DriverManager. El gestor de drivers es pequeño y simple y su función principal es la de seleccionar el driver adecuado para conectar la aplicación con una base de datos determinada, y acto seguido desaparece. [3] 35 JDBC es una especificación formada por una colección de interfaces y clases abstractas, que deben implementar todos los fabricantes de drivers que quieran que su driver sea 100% Java y compatible con JDBC. Se puede considerar que JDBC ofrece dos conjuntos de clases e interfaces bien diferenciados, aquellas de mas alto nivel que serán utilizadas por los programadores de aplicaciones para el acceso a bases de datos, y otras de mas bajo nivel enfocadas hacia los programadores de drivers que permiten la conexión a la base de datos. [3] Los drivers permiten conectarse a una base de datos determinada. Existen cuatro tipos de drivers JDBC, cada tipo presenta una filosofía de trabajo diferente. Sin embargo, el que se necesita para el desarrollo del presente proyecto es el driver tipo 4 por sus características. Este tipo de driver convierte directamente las llamadas en JDBC al protocolo utilizado por el DBMS, lo que permite una comunicación directa entre la máquina cliente y el servidor en que se encuentra el DBMS. Este driver está escrito totalmente en Java. Para cada tipo de driver existe un gran número de drivers disponibles en la página web de sun microsystems, donde se ofrece un formulario de búsqueda que permite seleccionar el tipo de driver que se busca junto con el sistema gestor de bases de datos al que se desea acceder y la versión JDBC que implementa el driver. El driver tipo 4 necesario para MySQL se descarga gratuitamente de su página web (mysql.com), llamado Connector/J, aunque el NetBeans IDE trae incorporado un driver para conectar aplicaciones con bases de datos MySQL, haciendo innecesaria su descarga. 36 El nombre del driver que brinda el fabricante para reconocerlo desde Java es el siguiente: com.mysql.jdbc.Driver Como se dijo anteriormente, el API JDBC se encuentra dentro del paquete java.sql que se incorpora como un paquete más dentro del lenguaje Java. Dentro de las clases, interfaces y excepciones mas importantes que se encuentran en este paquete podemos mencionar: • java.sql.DriverManager: Es la clase gestora de los drivers. Esta clase se encarga de cargar y seleccionar el driver adecuado para realizar la conexión con una base de datos determinada. • java.sql.Connection: Representa una conexión con una base de datos. • java.sql.Statement: Actúa como un contenedor para ejecutar sentencias SQL sobre una base de datos. • java.sql.PreparedStatement: Permite la ejecución de sentencias SQL precompiladas a las que se le pueden pasar parámetros de entrada. • java.sql.CallableStatement: Permite ejecutar procedimientos almacenados de una base de datos. • java.sql.ResultSet: Controla el acceso a los resultados de la ejecución de una consulta, es decir, de un objeto Statement. Permite también la modificación de estos resultados. • java.sql.SQLException: Para tratar las excepciones que se produzcan al 37 manipular la base de datos, ya sea durante el proceso de conexión, desconexión u obtención y modificación de los datos. • java.sql.Warning: Nos indica los avisos que se produzcan al manipular y realizar operaciones sobre la base de datos. • java.sql.Driver: Esta interfaz la deben implementar todos los fabricantes de drivers que deseen construir un driver JDBC. Representa un driver que podemos utilizar para establecer una conexión con una base de datos. • java.sql.ResultSetMetaData: Esta interfaz ofrece información detallada relativa a un objeto ResultSet determinado. • java.sql.DatabaseMetaData: Ofrece información detallada sobre la base de datos a la que se encuentra conectada la aplicación. • java.sql.Types: Realiza la conversión o mapeo de tipos estándar del lenguaje SQL a los tipos de datos del lenguaje Java. [3] En un programa sencillo sólo unas cuantas de estas clases, interfaces y excepciones son necesarias. 3.3.1 URLs en JDBC Una URL de JDBC ofrece un mecanismo para identificar una base de datos de forma que el driver adecuado la reconozca y establezca una conexión con ella. Al igual que las 38 URLs generales sirven para identificar de un modo único un recurso en Internet, una URL de JDBC localizará una base de datos determinada. La sintaxis estándar de las URLs de JDBC es la siguiente: jdbc:: Siempre se debe comenzar por jdbc pero es el fabricante del driver quien debe especificar la sintaxis exacta de la URL para su driver. El subprotocolo suele ser el nombre del driver o del mecanismo de conectividad con la base de datos y el subnombre es una forma de identificar a la base de datos concreta. El subnombre puede variar ya que puede identificar una base de datos local, una base de datos remota, un número de puerto específico o una base de datos que requiera identificador de usuario y contraseña. [3] La URL para bases de datos de MySQL es la siguiente: jdbc:mysql://localhost:3306/nombredebd 3.3.2 Código JDBC Para conectar aplicaciones con bases de datos, se debe hacer por medio de instrucciones en el lenguaje huésped (java). Para usar JDBC, se empieza por establecer una conexión a la base de datos. Para ello, se debe cargar el driver utilizando la clase DriverManager. Ésta devuelve un objeto Connection que le dirá a un objeto Statement que ejecute un comando DDL o DML, a un objeto PreparedStatement que ejecute un comando DML precompilado, o a un objeto CallableStatement que ejecute un procedimiento 39 almacenado. Los tres tipos de statement devuelven resultados de consultas como un ResultSet que presenta los datos como un conjunto de filas y columnas. [5] Un objeto Connection representa una conexión física a una base de datos. Es utilizado para crear Statements, para preparar PreparedStatements, para preparar CallableStatements, y para manejar transacciones. [5] Lo primero que se debe hacer es cargar el driver: String driver = "com.mysql.jdbc.Driver"; try { Class.forName(driver).newInstance(); } Catch (Exception e){ e.printStackTrace(); System.exit(1); } Una vez que el driver se carga, se utiliza el método getConnection() para establecer la conexión: Connection con = null; String password = “password”; String url = "jdbc:mysql://localhost:3306/nombredebd"; String user = “root”; 40 try{ conn = DriverManager.getConnection(url, user, password); } catch (Exception e){ System.out.println("ERROR en insertar registro --> "+e); e.printStackTrace(); } Para insertar, borrar y actualizar registros, se utiliza el método executeUpdate(), mientras que para sentencias select se utiliza executeQuery() de la clase Statement. De la misma forma, se debe programar la funcionalidad de cada botón del programa. 41 CAPÍTULO 5: Conclusiones y recomendaciones 5.1 Conclusiones • El uso de bases de datos se facilita con ayuda de programas como MySQL Workbench, porque generan automáticamente scripts para esquemas de bases de datos a partir del diseño de la misma. Esto ahorra mucho tiempo a la hora de trabajar con una base de datos específica, porque se pueden hacer las modificaciones necesarias al diseño, abstrayéndose de las dificultades del lenguaje DDL cada vez. De la misma manera, se puede cambiar el esquema de la BD en todo momento para requerimientos distintos de datos. Desde esta herramienta es posible el llenado de la base de datos en forma simple y rápida, ya que el programa también genera estas sentencias automáticamente. Las bases de datos no limitan de ninguna manera a las aplicaciones, más bien se puede modificar dinámicamente su estructura según sea necesario. • Con el uso del IDE NetBeans, es posible desentenderse de aspectos del lenguaje java que de otra manera demandarían tiempo y dedicación, como la programación de Interfaces Gráficas de Usuario (GUI). Utilizando esta característica es posible desarrollar aplicaciones de manera rápida y se facilita el añadir mejoras de funcionalidad cuando se desee, volviendo al programa muy flexible. Además, permite desarrollar aplicaciones para ingeniería de fácil uso y con un aspecto muy profesional. Esta herramienta facilita la labor del programador al comprender de editor de texto mejorado, compilador, intérprete y depurador. 42 5.2 Recomendaciones • Para lograr una mejor estimación, es mejor utilizar el nivel de dificultad como un atributo de cada material asociado a un proyecto, y no como un atributo de un proyecto como se venía trabajando. Así, el nivel de dificultad caracterizará la dificultad de instalación de cada material utilizado en el proyecto. Para lograr esto, se debe programar la base de datos con el atributo “NivelDificultad” como atributo del vínculo “SeComponeDe” entre las entidades “Proyecto” y “Material” • Es posible añadir funciones al programa, por lo que se podría añadir una forma de buscar materiales en el programa a través del código de identificación que se utiliza en la página web laferreteriadigital.com. De esta manera, se pueden buscar materiales de una forma interactiva, aunque sería una alternativa extra para que quienes no tengan acceso a Internet no tengan problema en utilizar el programa. Para esto, se debe programar la base de datos y el programa para que sea posible incluir el código de material cada vez que se añade un material nuevo. • Es muy conveniente programar una tabla con los índices de labor de los materiales para consultarla a la hora de hacer presupuestos. Estos índices se encuentran en el National Electrical Estimator. Para esto se debe añadir un botón en la ventana de creación de presupuesto, que al presionarlo despliegue una tabla con los valores de los índices de labor. 43 • El programa puede utilizarse para estimar costos de toda obra, no necesariamente eléctrica. Simplemente se debe llenar la base de datos con los materiales que se utilizan en el desarrollo de proyectos. Igualmente, si el programa se utiliza de esta manera, es conveniente que el salario base sea un atributo de cada material asociado a un proyecto, y no un atributo del proyecto como se tiene actualmente. Esto debido a que cada trabajo según su naturaleza dentro de un proyecto tiene diferentes salarios. Ejemplos de presupuestos en los que se puede utilizar el programa: Estructuras metálicas y de madera, soldadura, pisos, techos, construcción, entre otros. • Para seguir con el desarrollo del programa, se recomienda estudiar el API JDBC, lenguaje SQL avanzado, algebra relacional, componentes swing de java, programación basada en eventos, estimación de presupuestos de obra eléctrica. 44 BIBLIOGRAFÍA 1. Elmasri, R. “Sistemas de Bases de Datos”, segunda edición, Pearson, México, 2000. 2. Thomas, W. “Programación en Java”, primera edición, McGrawHill, México, 2008. 3. Ángel, E. “Acceso a Bases de Datos con Java-JDBC 2.0”, primera edición, Grupo Eidos, España, 2000. 4. Beaulieu, A. “Learning SQL”, segunda edición, O’reilly, Estados Unidos, 2009. 5. Bales, D. “JDBC Pocket Reference”, primera edición, O’reilly, Estados Unidos, 2003. 6. http://www.oracle.com/index.html 7. http://netbeans.org/ 8. http://mysql.com/ 45 ANEXO 1 Procedimiento para instalar MySQL: 1) Ir a mysql.com. En la pestaña de “Downloads (GA)”, ingresar al link MySQL Community Server x.x ubicado de primero en el lado derecho. Seleccionar el instalador msi Windows Essentials (x86), de 32 o 64 bits según corresponda y hacer click en “download”. En la página siguiente, hacer click en “No thanks, just take me to the downloads” ubicado en la parte inferior. Por último, seleccionar un espejo HTTP ubicado en Estados Unidos y salvar el instalador en algún directorio de la computadora. 2) Doble click en el instalador una vez que se ha descargado, y pulsar Ejecutar. Cuando aparezca la ventana Setup Wizard, pulsar Next. Activar Typical y pulsar Next. En la siguiente ventana pulsar Install. La instalación durará varios minutos. 3) En la ventana MySQL Enterprise pulsar Next dos veces seguidas. Asegurarse que “Configure the MySQL Server now” esté seleccionada y pulsar Finish. Emerge la ventana “Configuration Wizard”, pulsar Next. En la ventana “Instance configuration” escoger la opcion “Reconfigure instance” 4) Activar el botón “Standard Configuration” y pulsar Next. Asegurarse que “Install as Windows Server” y “Include Bin Directory in Windows PATH” estén seleccionadas. Además seleccionar “Launch the MySQL Server automatically”. Pulsar Next. 46 5) Seleccionar solamente “Modify Security Settings” para asignar la nueva contraseña y confirmación de contraseña (dejar “current root password” en blanco si es primera vez que se instala MySQL). Pulsar Next y luego Execute. Finalmente pulsar Finish. En este punto, el servidor debe estar instalado y corriendo. Para utilizar el programa, en Inicio, buscar MySQL en todos los programas y ejecutar MySQL Command Line Client, donde se necesitará la contraseña pedida anteriormente. Una vez aceptada la contraseña, se pueden dar instrucciones SQL, como crear y llenar bases de datos. También se puede copiar y pegar el script del anexo 2 para la creación de la base de datos del programa estimador. 47 ANEXO 2 Script para la creación de la base de datos en MySQL: SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0; SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL'; CREATE SCHEMA IF NOT EXISTS `EstimadorElectrico` DEFAULT CHARACTER SET utf8 COLLATE utf8_spanish_ci ; USE `EstimadorElectrico`; -- ------------------------------------------------------ Table `EstimadorElectrico`.`Cliente` -- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `EstimadorElectrico`.`Cliente` ( `IdCliente` INT UNSIGNED NOT NULL AUTO_INCREMENT , `NombreC` VARCHAR(60) NOT NULL , `Telefono` VARCHAR(9) NULL , `Email` VARCHAR(45) NULL , PRIMARY KEY (`IdCliente`) ) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_spanish_ci; 48 -- ------------------------------------------------------ Table `EstimadorElectrico`.`Proyecto` -- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `EstimadorElectrico`.`Proyecto` ( `IdProyecto` INT UNSIGNED NOT NULL AUTO_INCREMENT , `NombreP` VARCHAR(60) NOT NULL , `SalarioxHora` FLOAT NOT NULL , `NivelDificultad` FLOAT NOT NULL , `IdCliente` INT UNSIGNED NOT NULL , `Presupuesto` FLOAT NULL , PRIMARY KEY (`IdProyecto`) , INDEX `fk_Proyecto_Cliente` (`IdCliente` ASC) , CONSTRAINT `fk_Proyecto_Cliente` FOREIGN KEY (`IdCliente` ) REFERENCES `EstimadorElectrico`.`Cliente` (`IdCliente` ) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_spanish_ci; -- ------------------------------------------------------ Table `EstimadorElectrico`.`Familia` 49 -- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `EstimadorElectrico`.`Familia` ( `IdFamilia` INT UNSIGNED NOT NULL AUTO_INCREMENT , `NombreF` VARCHAR(60) NOT NULL , PRIMARY KEY (`IdFamilia`) ) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_spanish_ci; -- ------------------------------------------------------ Table `EstimadorElectrico`.`Material` -- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `EstimadorElectrico`.`Material` ( `IdMaterial` INT UNSIGNED NOT NULL AUTO_INCREMENT , `NombreM` VARCHAR(60) NOT NULL , `CostoUnitario` FLOAT NOT NULL , `IndiceLabor` FLOAT ZEROFILL NULL , `UnidadMedida` VARCHAR(20) NOT NULL , `IdFamilia` INT UNSIGNED NOT NULL , PRIMARY KEY (`IdMaterial`) , INDEX `fk_Material_Familia1` (`IdFamilia` ASC) , CONSTRAINT `fk_Material_Familia1` FOREIGN KEY (`IdFamilia` ) REFERENCES `EstimadorElectrico`.`Familia` (`IdFamilia` ) 50 ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_spanish_ci; -- ------------------------------------------------------ Table `EstimadorElectrico`.`SeComponeDe` -- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `EstimadorElectrico`.`SeComponeDe` ( `Cantidad` INT UNSIGNED ZEROFILL NULL , `IdProyecto` INT UNSIGNED NOT NULL , `IdMaterial` INT UNSIGNED NOT NULL , PRIMARY KEY (`IdProyecto`, `IdMaterial`) , INDEX `fk_EsDe_Proyecto` (`IdProyecto` ASC) , INDEX `fk_EsDe_Material` (`IdMaterial` ASC) , CONSTRAINT `fk_EsDe_Proyecto` FOREIGN KEY (`IdProyecto` ) REFERENCES `EstimadorElectrico`.`Proyecto` (`IdProyecto` ) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `fk_EsDe_Material` FOREIGN KEY (`IdMaterial` ) REFERENCES `EstimadorElectrico`.`Material` (`IdMaterial` ) 51 ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_spanish_ci; SET SQL_MODE=@OLD_SQL_MODE; SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS; -- ------------------------------------------------------ Data for table `EstimadorElectrico`.`Familia` -- ----------------------------------------------------SET AUTOCOMMIT=0; USE `EstimadorElectrico`; INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (1, 'Cable portaelectrodo'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (2, 'Cable p/ audio'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (3, 'Cables utp'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (4, 'Cables coaxiales'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (5, 'Cables p/ telefono'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (6 , 'Cordones tsj y spt'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (7, 'Cables p/ timbre'); INSERT INTO `Familia` (`IdFamilia`, `NombreF`) VALUES (8, 'Cables thhn'); 52 COMMIT; -- ------------------------------------------------------ Data for table `EstimadorElectrico`.`Material` -- ----------------------------------------------------SET AUTOCOMMIT=0; USE `EstimadorElectrico`; INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (1, '#2 viakon', 4154, 0, 'metro', 1); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (2, '#4 viakon', 3792, 0, 'metro', 1); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (3, 'Cable tsj 2x14 awg viakon', 534, 0, 'metro', 6); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (4, 'Cable tsj 3x8 awg ', 4762, 0, 'metro', 6); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (5, 'Cable tsj 3x10 awg', 1928, 0, 'metro', 6); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (6, 'Cable thhn 1/0 awg', 4148, 0, 'metro', 8); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (7, 'Cable thhn 2 awg', 259098, 0, 'caja', 8); INSERT INTO `Material` (`IdMaterial`, `NombreM`, `CostoUnitario`, `IndiceLabor`, `UnidadMedida`, `IdFamilia`) VALUES (8, 'Cable thhn 2 awg negro', 280348, 0, 'caja', 8); COMMIT; 53 54