Nombre y apellidos 1* Yerandi Marcheco Díaz

Transcripción

1 Base de Datos de Partes Estandarizadas Para Sistemas CAD Desarrollado Sobre Tecnologías Libres Standardized Part Database For Cad System Built On Free Technologies Nombre y apellidos 1* Yerandi Marcheco Díaz 1 Universidad de las Ciencias Informáticas (UCI). Edificio 55, Apartamento 103, Carretera San Antonio de los Baños, km 2½, La Lisa, Ciudad Habana, Cuba. ymarcheco@uci.cu * Autor para correspondencia: ymarcheco@uci.cu Resumen La mayoría de los sistemas de Diseño Asistido por Computadora (CAD, del inglés Computer Aided Design) libres, no cuentan con un centro de contenido de donde se puedan importar piezas estandarizadas de diferentes normas internacionales como la ISO, ANSI, DIN u otras. El presente trabajo muestra una Base de Datos para almacenar partes estandarizadas a utilizar en sistemas CAD. Se realizó el estudio de diferentes sistemas de base de datos como las Base de Datos Orientadas a Objetos, las Base de Datos Hibridas o Base de Datos Objetos-Relacionales y las Bases de Datos Relacionales. La propuesta está basada en una Base de Datos Relacional sobre el gestor de base de datos libre PostgreSQL. Palabras clave: bases de datos; estándares; relaciones. Abstract Most free CAD (Computer Aided Design) Systems does not include Contents Center modules, from where users would import standardized parts belonging to different international standards such as ISO, ANSI, DIN or others. This paper presents a Database proposal for storing standardized parts used in CAD systems. Different database systems were studied, including Object-Oriented Databases, Hybrid Databases or Relational-Objects Databases and Relational Databases. Finally, the proposal was made using a Relational Database on free Database Manager PostgreSQL. Keywords: database; standards; relations. 1

2 Introducción El Diseño Asistido por Computadora (CAD del inglés Computer-Aided-Design) es el uso de un amplio rango de herramientas computacionales que asisten a ingenieros, arquitectos y a otros profesionales del diseño en sus respectivas actividades. Hoy en día se cuentan con varias versiones de software propietario para el trabajo de tareas CAD (se entiende en este aspecto entre otros SolidWorks, ProEngineering, AutoCAD e Inventor), así como se cuentan también con versiones de software para trabajo de tareas CAD desarrolladas en software libre, pero en este caso las funcionalidades no están a la alturas de las versiones en software propietario. Una de las carencias que tienen los sistemas CAD desarrollados en software libre es que no cuentan con una base de datos de bibliotecas estandarizadas a partir de la cual se puedan importar modelos de piezas que cumplan con los requisitos de los estándares internacionales. En el Centro de Diseño y Simulación de Estructuras Mecánicas (CDSEM) de la Universidad de las Ciencias Informáticas (UCI) se desarrolla un proyecto de software CAD para el diseño y modelación de estructuras mecánicas. Este software tiene como objetivo responder a las necesidades de la Industria China Venezolana de Taladros (ICVT) perteneciente a PDVSA Industrial de la República Bolivariana de Venezuela. Entre los módulos a desarrollar para este software se encuentra el Centro de Contenido, que es la aplicación encargada de gestionar las bibliotecas estandarizadas. El componente básico del Centro de Contenido es una familia de piezas. Las familias se organizan en categorías en una biblioteca del Centro de Contenido y una categoría es una agrupación lógica de los tipos de piezas. Una familia de piezas contiene miembros que tienen la misma plantilla y propiedades de familia, y que representan variaciones de tamaño de una pieza o una operación. Por ejemplo para la pieza ISO 2009 (Tornillos de cabeza avellanada y ranurada) perteneciente a la familia Cabeza Hexagonal de la Categoría Fijaciones según [1], existen 10 designaciones de diámetro nominal, y para cada una de esas designación existen diferentes longitudes nominal, por lo que para una norma se puede tener n*n combinaciones de sus propiedades y cada una de estas combinaciones es una nueva forma de representación, ver Figura 1. 2

3 Figura 1 Ejemplo de diámetros y longitudes de la norma ISO Desarrollo Teniendo en cuenta la diversidad de piezas y complejidad de las mismas, se hace difícil representar una base de datos que permita almacenar toda la información de una biblioteca de estándares. Buscándole solución al problema de modelar una base de datos capaz de almacenar partes estandarizadas sin importar la diversidad y complejidad que tengan las familias y piezas que se almacenen en las mismas, este trabajo expone el estudio de diferentes sistemas de base de datos, y una propuesta de diseño para una base de datos de partes estandarizadas. Sistemas de Bases de Datos Se puede definir un Sistema de Base de Datos como un conjunto exhaustivo y no redundante de datos estructurados, organizados de forma independiente a su utilización o implantación en máquinas, accesibles en tiempo real y compatible con usuarios concurrentes y sus respectivas necesidades de información. Bases de Datos Relacionales Las Bases de Datos Relacionales (BDR) son aquellas que cumplen con el modelo relacional, este modelo es el más utilizado en la actualidad para implementar bases de datos. En este modelo relacional se establecen relaciones entre los datos, de ahí su nombre de Modelo Relacional [2]. Este modelo relacional fue propuesto por Codd [3] y sin duda 3

4 alguna, la propuesta más revolucionaria que dio paso a las bases de datos relacionales, donde todos los datos están estructurados desde el punto de vista lógico mediante relaciones (tablas). Pese a que la estructura lógica del modelo relacional es simple, su estructura teórica es muy sólida. Esta base teórica permite tratar con la semántica de los datos y con los problemas de coherencia y redundancia, junto a un conjunto de reglas de normalización. El modelo relacional propone la independencia entre los datos a la hora de almacenarlos y los programas que los usan. A partir de esa idea se desarrolló el Lenguaje de Consulta Estructurado (SQL del inglés Structured Query Language), que ha llegado a ser un estándar de facto para los sistemas relacionales. La inmensa mayoría de las bases de datos que existen en el mercado hoy en día son del tipo relacional, estas bases de datos cumplen una serie de reglas que procuran evitar redundancia y asegurar la integridad de los datos almacenados en ellas así como la seguridad de los datos. Entre las ventajas de las BDR se pueden encontrar: Garantizan la integridad referencial, de esta forma al eliminar un registro se eliminan todos los registros relacionados dependientes. Poseen independencia física y lógica, debido a que el modo en que se almacenan los datos no influye en su manipulación lógica. Flexibilidad, debido a que se puede presentar a cada usuario los datos de la forma que prefiera. Uniformidad, las estructuras lógicas de datos presentan un estado uniforme. Sencillez, siendo al mismo tiempo la principal característica, en la estructura puesta de manifiesto sobre todo en las operaciones de recuperación y actualización. Entre las desventajas que se pueden encontrar: Presentan deficiencias con datos gráficos, multimedia y sistemas de información geográfica. No se manipulan de forma manejable los bloques de texto como tipo de dato. Este modelo, no permite distinguir entre objetos y asociaciones de objetos. Bases de Datos Orientas a Objetos Las Bases de Datos Orientadas a Objetos (BDOO) son aquellas cuyo modelo de datos está orientado a objetos y almacenan y recuperan objetos en los que se almacena estado y comportamiento [4]. Las BDOO son una colección 4

5 persistente y compatible de objetos definida por un modelo de datos orientado a objetos, este modelo captura la semántica de los objetos soportados en la programación orientada a objetos. Su origen se debe a que en los modelos clásicos de datos existen problemas para representar cierta información, aunque permiten representar gran cantidad de datos, las operaciones que se pueden realizar con ellos son bastante simples [5]. Las clases utilizadas en un determinado lenguaje de programación orientado a objetos son las mismas clases que serán utilizadas en una BDOO ver Figura 2; de tal manera, que no es necesaria una transformación del modelo de objetos para ser utilizado por un Sistema Gestor de Base de Datos Orientadas a Objetos (SGBDOO). De forma contraria, el modelo relacional requiere abstraerse lo suficiente como para adaptar los objetos del mundo real a tablas. Figura 2 Diagrama de clase orientado a objeto La orientación a objetos ofrece flexibilidad, no está limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. La característica clave es la potencia que proporcionan al diseñador, al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos. Entre las ventajas de las BDOO se pueden encontrar: Mayor capacidad de modelado. El modelado de datos orientado a objetos permite modelar el mundo real de una manera mucho más fiel. Mayor extensibilidad. Esto se debe a que se pueden construir nuevos tipos de datos a partir de los ya existentes. Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en una BDOO. Mientras que SQL utiliza el acceso asociativo. El acceso navegacional es más adecuado para gestionar operaciones como los despieces, consultas recursivas, etc. [6]. Mayores prestaciones. Las Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO) proporcionan mejoras significativas de rendimiento con respecto a los Sistemas Gestores de Bases de Datos 5

6 Relacionales (SGBDR). Aunque hay autores que han argumentado que los bancos de prueba usados están dirigidos a aplicaciones de ingeniería donde los SGBDOO son más adecuados. Entre las desventajas de las BDOO se pueden encontrar: Carencia de un modelo de datos universal. No hay ningún modelo de datos que esté universalmente aceptado para las BDOO y la mayoría de los modelos carecen una base teórica. Carencia de experiencia, todavía no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales. Carencia de estándares, existe una carencia de estándares general para las BDOO. Con respecto a las Base de Datos Relacionales y las BDOO estos productos tienen una experiencia de uso considerable. Además, el modelo relacional tiene una sólida base teórica y los productos relacionales disponen de muchas herramientas de soporte que sirven tanto para desarrolladores como para usuarios finales. La optimización de consultas compromete la encapsulación, esta optimización requiere una compresión de la implementación de los objetos, para poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulación. Las BDOO, requiere de gestores de bases de datos que soporten éste tipo de arquitecturas, y éstos son menor en número en comparación a los SGBDR. Bases de Datos Objeto-Relacionales Las Bases de Datos Objeto-Relacionales (BDOR) son bases de datos que han evolucionado desde el modelo relacional hacia otra más amplia que incorpora conceptos del paradigma orientado a objetos para dar soporte a las nuevas aplicaciones en bases de datos. Este tipo de bases de datos usan el estándar SQL: 2003, el cual incluye nuevos tipos y procedimientos definidos por el usuario y soporta objetos de gran tamaño pero siempre basándose en el modelo relacional. Las bases de datos relacionales no son tan descriptivas como las orientadas a objetos para poder soportar las aplicaciones que están surgiendo en la actualidad. La idea que originó las Bases de Datos Objetos-Relacionales fue fusionar las ventajas de ambas e intentar reducir sus deficiencias, manteniendo las mismas tablas relacionales básicas y el mismo lenguaje de consulta aunque incorporando el concepto del tipo objeto, dando como resultado los Sistemas Gestores de Bases de Datos Objeto-Relacionales (SGBDOR). 6

7 Las Bases de Datos Objeto-Relacionales fueron analizadas por Stonebraker [7], proponiendo la división mostrada en la Figura 3. En esta figura se muestra cómo el enfoque orientado a objetos permite ampliar la complejidad de los datos, mientras que la búsqueda de soluciones relacionales mejora la eficiencia en la evaluación de consultas. Entre las características de las Bases de Datos Objeto-Relacionales, se puede destacar que el acceso a la base de datos se puede hacer usando lenguajes de más alto nivel orientados a objetos. Pero donde toda la información es relacional, y las tuplas y las relaciones mantienen el mismo significado que en las bases de datos relacionales, aprovechando su desarrollo y madurez. Figura 3 El mundo de las bases de datos según Stonebraker. Entre las ventajas de las Bases de Datos Objeto-Relacionales se pueden destacar: Reutilización y compartición, ya que surge la capacidad de ampliar los servicios del Sistema Gestor de Bases de Datos para implementar funcionalidad estándar de manera central, en lugar de codificar dicha funcionalidad en cada aplicación. Adaptación de las aplicaciones relacionales a las objeto-relacionales, ya que los SGBDOR pueden introducirse de forma gradual. SQL: 2003 es compatible con SQL: 92, por lo que la transformación de un sistema ya existente se puede realizar por pasos. Los SGBDOR tienen la capacidad de almacenar instancias de clases y atributos clásicos relacionales, esto ofrece la posibilidad de escoger en función de las necesidades de la aplicación, cuál es la implementación más adecuada. Algunas de las desventajas de las Bases de Datos Objeto-Relacionales: 7

8 Aumenta la complejidad y el incremento de costo del rendimiento, ya que se pierde la simplicidad del modelo relacional. Los SGBDOR no añaden todos los valores de la orientación a objetos, ya que tan solo contemplan el modelo de objetos como una extensión del modelo relacional al que se le añade complejidad. La convivencia de datos puramente relacionales y objetos hace que se pierda la homogeneidad de acceso a la información. Esta característica hace que el tratamiento de la información dependa de su naturaleza, y por lo tanto aumente la complejidad del desarrollo de los SGBDOR. Comparación entre los diferentes tipos de bases de datos Aunque en las subsecciones anteriores se muestran muchas de las características de los distintos gestores de bases de datos, en la Tabla 1 se muestra un resumen de algunas de sus características y la madurez de los mismos. Tabla 1 Comparación entre los tipos de bases de datos. BDR BDOO BDOR Estándares SQL2 ODMG-2.0 SQL:2003 Facilidad de uso Fácil Fácil para los programadores, no tanto para el usuario final Similar a las Bases de Datos Relacionales. Facilidad de desarrollo Independencia entre los datos y aplicación. Los objetos son una forma natural de modelar extensible y adaptable. Uso de SQL Completo Extensión de SQL con la creación de OQL adaptado a la orientación de objetos. Independencia entre los datos y aplicación. Definición de SQL3 basado en SQL pero con orientación a objetos. Datos complejos y Difícil de modelar Facilita la definición de tipo Facilita la definición de relaciones complejos y relaciones. tipo complejos y relaciones. Soporte a la Orientación Pobre, es difícil Directa y Extensible. Limitado sobre todo para a Objetos almacenar los objetos en los nuevos tipos de datos. la BD. 8

9 Distribución Muy buena Depende del Sistema Gestor de Bases de Datos. Muy Buena Solución Propuesta: Base de Datos Relacional de partes estandarizadas. Para la creación del modelo relacional de la base de datos de partes estandarizadas se tienen en cuenta las características de los datos a almacenar. Como se mencionaba anteriormente el componente básico del Centro de Contenido es una familia de piezas. Esta familia contiene las piezas, y una pieza tiene diferentes características de diferentes tipos de datos. Lograr representar toda esta información de familias, y piezas en un Modelo Relacional se hace muy difícil por la diversidad de datos y tipos de datos que tiene una pieza. Darle a este Modelo Relacional un enfoque Objeto-Relacional sería lo ideal para lidiar con la diversidad de datos que se maneja. Para ello y para no perder las ventajas que ofrecen las Bases de Datos Relacionales se decide usar una variante del patrón de diseño llamado Entidad-Atributo-Valor, ver Figura 1. Este patrón es la representación de un modelo flexible donde se pueden representar objetos con sus atributos. Es un acercamiento al modelo orientado a objeto representado en el modelo relacional, donde la entidad Class representa las clases, la entidad Attribute representa los atributos de las clases, por su parte la entidad Object representa las instancias de las clases, mientras que la entidad Value representa los valores de cada atributo para cada objeto dado. Figura 4 Representación del modelo entidad-atributo-valor. De esta forma en el Modelo Relacional la representación de una pieza con sus propiedades queda como se muestra en la Figura 5. 9

10 Figura 5 Fragmento del Modelo Relacional de las piezas y sus atributos. Para la representación de la jerarquía entre categorías, subcategorías, familias y piezas se usó el patrón de diseño Árbol Fuertemente Codificado. La representación de la jerarquía entre categorías, subcategorías, familias y piezas queda como se muestra en la Figura 6. Figura 6 Fragmento del Modelo Relacional, jerarquía categoría, subcategoría, familia y piezas. 10

11 Resultados Finalmente obtuvo una Base de Datos Relacional, que está alojada en el gestor de bases de datos libre PostgreSQL, en la que se pueden almacenar bibliotecas estandarizadas. Como se muestra en las Figura 7 y Figura 8, las propiedades de las piezas se mantienen, independientemente de la cantidad y diversidad de datos que tenga la misma. En estos momentos no se cuenta con otra Base de Datos que no sea de tipo Relacional para comparar los resultados, pero se puede decir que los resultados son buenos por lo que se ha podido apreciar del funcionamiento de la base de datos en el software para sistemas CAD que se realiza en el CDSEM. Figura 7 Fragmento de vista de la tabla temporal para la norma ISO

12 Figura 8 Fragmento de vista de la tabla temporal para la norma ISO Conclusiones Como parte del cumplimiento de los objetivos planteados se realizó un estudio de los diferentes tipos de base de datos, con profundidad en los Sistemas de Base de Datos Relacionales, en los que se realizó la solución usando una variante del patrón de diseño Entidad-Atributo-Valor que le da mayor flexibilidad al Modelo Relacional de la base de datos al permitir hacerle un acercamiento al Modelo Orientado a Objeto. Finalmente se obtuvo una Base de Datos Relacional con un Modelo Relacional que puede ser usado para guardar la información de las partes estandarizadas. Referencias AENOR "Asociación Española de Normalización y Certificación" Date, C.: Introducción a los Sistemas de bases de datos. Addison-Wesley, Wilmington, E.U.A, E. F. Codd.: A Relational Model of Data for Large Shared Data Banks, Commun. 12

13 Elisa Bertino, Lorenzo Martino.: Sistemas de bases de datos orientadas a objetos: Conceptos y arquitecturas. Editorial: Addison-Wesley / Díaz de Santos. Silberschatz, Korth, Sudarshan.: Fundamentos de Bases de datos. 5ª Edición. Editorial: McGraw Hill. Alagic, Saud.: Object-oriented Database Programming, M. Stonebraker, D. Moore, P. Brown.: Object-Relational DBMSs. 13