| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Motores de persistencia"
Este artículo estudia el problema que supone el hecho de que los programas y las bases de datos tratan los datos de forma diferente. Se estudian diferentes soluciones a este problema y se concluye que la mejor es usar un motor de persistencia. Se informa sobre los principales motores de persistencia que existen en el mercado.
Artículo "Motores de persistencia" (continuación)
2. MODELO RELACIONAL. Muy ajeno a la revolución que supuso la orientación a objetos, el área de las bases de datos sigue fiel a un modelo antiguo pero que ha probado su eficacia, el llamado “modelo relacional”. El modelo relacional se basa en un artículo publicado por E.F.Codd en 1970. Las primeras bases de datos relacionales comerciales aparecen en la segunda mitad de los años setenta. Desde entonces, el modelo relacional se convierte en un estándar prácticamente universal para el acceso a datos, dominando totalmente el área de las bases de datos hasta la actualidad. El modelo relacional es muy diferente del modelo orientado a objetos. Por una parte, el modelo relacional sólo se ocupa de la parte estática de la aplicación (de los “datos”) y no de la parte dinámica (“los procesos”). Usando el ejemplo anterior, en el modelo relacional, sólo me interesan las características del auto (su color, su tipo de caja de cambios, etc) y no las acciones que puedo hacer con él (acelerar, frenar, etc.) . Este énfasis en los datos es lógico en un modelo cuyo objetivo es modelar la parte estática de la aplicación, es decir, la base de datos. Hay otras diferencias entre los dos modelos. Por ejemplo, la forma en la que el modelo relacional trata los datos es muy diferente a cómo lo hace el modelo orientado a objetos. Mientras en este último, los datos son modelados en forma de objetos, en el modelo relacional son modelados como registros, los cuales son una serie de datos pertenecientes a una misma entidad de la vida real. Un registro difiere de un objeto en que sólo modela datos y que éstos no tienen estructura. La representación gráfica de un registro aparece en la figura 4. Figura 4. Representación gráfica de un registro de datos Los registros similares se agrupan en tablas. Podemos imaginarnos las tablas como listados de datos parecidos a los listados de impresión que hay en las empresas (de empleados, de facturas, etc.). En esta comparación, cada registro sería una línea del listado. Usando el ejemplo anterior, cada registro contendría los datos de un determinado auto (color rojo, caja de cambios automática, diesel, etc.) y las tablas no serían más que listas de autos con todos sus datos, como se observa en la figura 5. Figura 5. Los registros de las piezas están separados de los registros del auto El modelo relacional no refleja la estructura de la realidad. Como hemos dicho, si un auto contiene piezas, un objeto de software “Auto” contiene objetos “Pieza”. Sin embargo, en el modelo relacional, los registros de los autos y piezas están por separado (esto se muestra en la figura 5) y se relacionan por un mecanismo implícito llamado “clave foránea”. El programador debe saber que hay una relación entre los autos y las piezas y debe programar de acuerdo a ello. Sin embargo, el modelo no refleja explícitamente esta relación y, en general, la estructura de la realidad, al contrario del modelo orientado a objetos.
Ir a la página: 1 2 3 4 5 6 7 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |