unidad profesional interdisciplinaria de ...centrado en cumplir con las funciones y características...
TRANSCRIPT
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS
SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
MAESTRIA EN CIENCIAS CON ESPECIALIDAD EN INFORMÁTICA
“PROPUESTA DE UN MODELO DE DATOS SQL MULTIPLATAFORMA BASADO EN
EL ESTANDAR SQL: 2003”
T E S I S
Q U E P A R A O B T E N E R E L G R A D O D E M A E S T R O E N
C I E N C I A S C O N E S P E C I A L I D A D E N I N F O R M Á T I C A
PRESENTA:
FERNANDO RENÉ SÁNCHEZ SERRANO
DIRECTOR: DR. JAVIER GARCÍA GARCÍA
MÉXICO, D.F. 2010
2
3
4
Agradecimientos
Al Dr. Javier García por el interés mostrado en la realización del presente trabajo.
A los profesores del comité tutorial por su tiempo dedicado para llegar a la culminación del presente trabajo.
A todos los profesores de la sección de posgrado de la UPIICSA por su enseñanza.
Al Instituto Politécnico Nacional por ser el marco perfecto para la enseñanza y el aprendizaje.
5
A mis padres, por la semilla sembrada.
A Ana Lilia, por el amor renacido.
A René, por ser la luz que alumbra mi vida.
6
Resumen
El papel de las bases de datos en el área de la computación y las tecnologías de
información ha sido muy importante y trascendente desde los primeros modelos
presentados en los años 70´s; uno de estos fue modelo relacional y fue presentado por E.
Codd. Este modelo fue rápidamente aceptado e implementado por varias empresas
desarrolladoras de software por la consistencia y calidad del modelo. A partir de éste han
surgido varios sistemas manejadores de base de datos (SMDB) que hoy día siguen
vigentes. Las bases de datos son una parte crucial en la mayoría de los sistemas de
información de las organizaciones.
Posterior a la salida de este tipo de sistemas surgió la necesidad de desarrollar algún
lenguaje que permitiera administrar y manipular las funciones de los sistemas
manejadores de base datos así como los datos mismos que almacenaba. De aquí surgió
un lenguaje de consultas estructuradas denominado SQL (Structured Query Language).
Este lenguaje fue también rápidamente adoptado por la mayoría de los sistemas
manejadores debido a su fácil uso y la fuerte adaptación que guardaba con el modelo
relacional.
Dada la gran aceptación que tuvo el lenguaje por parte de los fabricantes y al mismo tipo
de los desarrolladores, éste ha crecido enormemente y se ha convertido en el lenguaje
“de facto” de los sistemas relacionales de base de datos.
Debido a esto, surgieron muchas versiones e implementaciones del mismo, lo cual llevo a
la necesidad de desarrollar un estándar que unificara estas versiones y ampliará el nivel
de compatibilidad entre los sistemas que lo implementaban.
A partir de esto se han desarrollado varios estándares sobre el lenguaje SQL; estos han
sido desarrollados por institutos de estandarización como ANSI e ISO. Existen tres
principales estándares: SQL-92, SQL-99 y SQL:2003.
A pesar que los fabricantes han hecho un esfuerzo por alcanzar altos niveles de
cumplimiento al estándar, todavía no se ha alcanzado el punto en el que pueda existir una
compatibilidad abierta y transparente entre los sistemas que adoptan e implementan el
estándar.
El cumplimiento que dan los sistemas manejadores al estándar SQL muchas veces está
centrado en cumplir con las funciones y características que dicta el estándar, y no a que
estas funciones o características se apeguen según las reglas que establece y tampoco
que éstas sean compatibles entre otros sistemas.
El presente trabajo investiga sobre el nivel de cumplimiento que dan algunos manejadores
al estándar sobre algunas instrucciones de SQL definidas en la versión SQL:2003, y la
compatibilidad que puede existir al trasladarse dichas instrucciones en las diferentes
implementaciones de los manejadores.
7
Abstract
The role of databases in computing systems and applications is of great significance since
most of them need to store data continuously. The systems in charge of managing such
sets of data are called Database Managing Systems (DBMS). Most of these database
managing systems have implemented the relational model, which was presented by E.
Codd (Codd 1970) in the nineteen seventies and was created as a new data storage
model based on relations. This model was adopted by many software developers
companies due to the completeness and quality of the model. There are many database
systems based on this model that are still present in today´s database products.
Just after the presentation of this model, there came up the necessity of developing a
language that allows developers manage and manipulating the functions and data stored
in database systems. As a result of this, there was a development of a structured query
language called “SQL”. This language was rapid adopted because of its ease of use and
the strong compliance to relational model.
SQL has been adopted by all relational database systems and has become “de facto”
language of databases.
The standardization process of SQL was first developed by ANSI (American National
Standards Institute); the first standard was SQL-92, followed by SQL-99 and extended to
SQL:2003.
Although the effort of many developers to fulfill the standard, there still been incompatibility
among database systems which implement the standard. SQL sentences written in any
compliant SQL system cannot been portable to other system without modification.
The compliance of database systems to SQL is focus in covering such characteristics
promoted by the standard and not in generating portable sentences among database
systems which implement such a standard.
The purpose of this investigation is to evaluate the compliance level of database system to
SQL:2003 and establish some factors to write portable SQL sentences among different
database systems.
8
Contenido
INTRODUCCIÓN ................................................................................................................................. 10
Trabajo relacionado ..................................................................................................................... 13
Objetivos y Motivación ................................................................................................................ 14
FUNDAMENTOS DE BASE DE DATOS Y LENGUAJES RELACIONALES. ................................................ 16
Conceptos .................................................................................................................................... 16
Lenguaje de Manipulación de Datos (DML) ................................................................................. 17
Lenguaje de Definición de Datos (DDL). ....................................................................................... 17
Operadores relacionales .............................................................................................................. 18
ESTADO ACTUAL DE LOS SISTEMAS MANEJADORES DE BASE DE DATOS (SMBD). ........................... 23
EL LENGUAJE SQL “STRUCTURED QUERY LANGUAGE” (LENGUAJE DE CONSULTAS
ESTRUCTURADAS). ............................................................................................................................ 28
ALGUNAS IMPLEMENTACIONES DEL LENGUAJE SQL. ....................................................................... 35
Oracle ........................................................................................................................................... 35
SQL SERVER .................................................................................................................................. 38
POSTGRESQL ................................................................................................................................ 42
MYSQL .......................................................................................................................................... 45
Resumen de características generales. ........................................................................................ 47
EL ESTÁNDAR SQL:2003 .................................................................................................................... 50
CUMPLIMIENTO DE LOS SMBD AL ESTÁNDAR SQL:2003 .................................................................. 55
ORACLE ......................................................................................................................................... 56
SQL SERVER .................................................................................................................................. 57
POSTGRESQL ................................................................................................................................ 57
MYSQL .......................................................................................................................................... 58
Tabla resumen. ............................................................................................................................. 59
Tipos de datos .............................................................................................................................. 59
Otros aspectos de cumplimiento al estándar SQL:2003 .............................................................. 61
Aspectos generales sobre el cumplimiento de SQL SERVER al estándar SQL:2003. ..................... 64
EXPERIMENTACIÓN ........................................................................................................................... 69
Catálogos (Catalogs) ..................................................................................................................... 71
Esquemas (Schemas). ................................................................................................................... 73
9
Tablas (Tables).............................................................................................................................. 76
Tipos De Datos (Data Types) ........................................................................................................ 80
Tipos numéricos. .......................................................................................................................... 82
Proyección .................................................................................................................................. 104
Eliminación ................................................................................................................................. 107
Inserción ..................................................................................................................................... 110
Actualización. ............................................................................................................................. 113
Ordenación ................................................................................................................................. 115
CONCLUSIONES. .............................................................................................................................. 119
REFERENCIAS ................................................................................................................................... 123
10
Índice de tablas
Tabla 1 Evolución de SQL .................................................................................................................. 32
Tabla 2 Estructura del Estándar SQL ................................................................................................. 51
Tabla 3 Características de Oracle ...................................................................................................... 56
Tabla 4 Características de SQL Server ............................................................................................... 57
Tabla 5 Características de POSTGRESQL ........................................................................................... 58
Tabla 6 Características de MYSQL ..................................................................................................... 59
Tabla 7 Tabla Resumen de características ........................................................................................ 59
Tabla 8 Tipos de datos ....................................................................................................................... 60
Tabla 9 Versiones SMBD en la experimentación............................................................................... 70
Tabla 10 Plataforma de experimentación ......................................................................................... 70
Tabla 11 Tipos de datos Fecha y Tiempo .......................................................................................... 95
Índice de figuras
Figura 1 Operadores relacionales ..................................................................................................... 21
Figura 2 Tabla Características ............................................................................................................ 49
Figura 3 CREATE DATABASE-ORACLE ................................................................................................ 71
Figura 4 CREATE DATABASE-SQLSERVER........................................................................................... 72
Figura 5 CREATE DATABASE POSTGRESQL ........................................................................................ 72
Figura 6 CREATE DATABASE-MYSQL.................................................................................................. 73
Figura 7 CREATE SCHEMA-ORACLE ................................................................................................... 75
Figura 8 CREATE SCHEMA - SQLSERVER ............................................................................................ 75
Figura 9 CREATE SCHEMA POSTGRESQL ........................................................................................... 76
Figura 10 CREATE SCHEMA MYSQL ................................................................................................... 76
Figura 11 CREATE TABLE - ORACLE .................................................................................................... 78
Figura 12 CREATE TABLE-SQLSERVER ................................................................................................ 79
Figura 13 CREATE TABLE-POSTGRESQL ............................................................................................. 79
Figura 14 CREATE TABLE-MYSQL ....................................................................................................... 80
Figura 15 TIPO NUMERICO-ORACLE .................................................................................................. 82
Figura 16 TIPO NUMERICO-SQLSERVER ............................................................................................ 83
Figura 17 TIPO NUMERICO-POSTGRESQL ......................................................................................... 84
Figura 18 TIPO NUMERICO-MYSQL ................................................................................................... 84
Figura 19 CONVERSION TIPO NUMERICO SQLSERVER ...................................................................... 85
Figura 20 CONVERSION SQL SERVER ................................................................................................. 85
Figura 21 CONVERSION TIPO NUMERICO-MYSQL ............................................................................ 86
Figura 22 TIPO ESTANDAR NUMERICO-ORACLE ............................................................................... 87
Figura 23 TIPO ESTANDAR NUMERICO-SQLSERVER .......................................................................... 88
Figura 24 TIPO ESTANDAR NUMERICO-SQLSERVER .......................................................................... 88
11
Figura 25 TIPO ESTANDAR NUMERICO-MYSQL ................................................................................. 89
Figura 26 TIPO CADENA-ORACLE....................................................................................................... 90
Figura 27 TIPO CADENA-SQLSERVER ................................................................................................. 91
Figura 28 TIPO CADENA-POSTGRESQL .............................................................................................. 91
Figura 29 TIPO CADENA-MYSQL ........................................................................................................ 92
Figura 30 CHARACTER LARGE OBJECT-MYSQL .................................................................................. 93
Figura 31 CHARACTER LARGE OBJECT-SQLSERVER ........................................................................... 93
Figura 32 CHARACTER LARGE OBJECT-ORACLE ................................................................................. 94
Figura 33 TIPO FECHA/TIEMPO-ORACLE ........................................................................................... 96
Figura 34 FECHA/TIEMPO-SQLSERVER .............................................................................................. 96
Figura 35 FECHA/TIEMPO-SQLSERVER .............................................................................................. 97
Figura 36 FECHA/TIEMPO-MYSQL ..................................................................................................... 98
Figura 37 ZONA HORARIA-MYSQL ..................................................................................................... 99
Figura 38 ZONA HORARIA-SQLSERVER .............................................................................................. 99
Figura 39 FORMATO FECHA-MYSQL ................................................................................................ 100
Figura 40 FORMATO FECHA-SQLSERVER ......................................................................................... 101
Figura 41 FORMATO FECHA-POSTGRESQL ...................................................................................... 101
Figura 42 TIPO BOOLEANO-ORACLE ................................................................................................ 102
Figura 43 TIPO BOOLEANO-SQLSERVER .......................................................................................... 103
Figura 44 TIPO BOOLEANO-POSTGRESQL ....................................................................................... 103
Figura 45 TIPO BOOLEANO-MYSQL ................................................................................................. 104
Figura 46 PROYECCION-ORACLE ...................................................................................................... 105
Figura 47 PROYECCION-SQLSERVER ................................................................................................ 106
Figura 48 PROYECCION-POSGRESQL ............................................................................................... 106
Figura 49 PROYECCION-MYSQL ....................................................................................................... 107
Figura 50 ELIMINACION-ORACLE..................................................................................................... 108
Figura 51 ELIMINACION-SQLSERVER ............................................................................................... 108
Figura 52 ELIMINACION-POSTGRESQL ............................................................................................ 109
Figura 53 ELIMINACION-MYSQL ...................................................................................................... 109
Figura 54 INSERCION-ORACLE ......................................................................................................... 111
Figura 55 INSERCION-SQLSERVER ................................................................................................... 111
Figura 56 INSERCION-POSTGRESQL ................................................................................................ 112
Figura 57 INSERCION-MYSQL .......................................................................................................... 112
Figura 58 ACTUALIZACION-ORACLE ................................................................................................ 113
Figura 59 ACTUALIZACION-SQLSERVER ........................................................................................... 113
Figura 60 ACTUALIZACION-POSTGRESQL ........................................................................................ 114
Figura 61 ACTUALIZACION-MYSQL .................................................................................................. 114
Figura 62 ORDENACION-ORACLE .................................................................................................... 116
Figura 63 ORDENACION-SQLSERVER ............................................................................................... 116
Figura 64 ORDENACION-POSTGRESQL ............................................................................................ 117
Figura 65 ORDENACION-MYSQL ...................................................................................................... 118
12
INTRODUCCIÓN
El papel de las bases de datos en los sistemas y aplicaciones de cómputo es de gran
importancia ya que la mayoría de estos sistemas tienen alguna necesidad de almacenar
datos de manera persistente. Los sistemas encargados de la administración de esos
conjuntos de datos son llamados sistemas manejadores de base de datos (SMBD). La
mayoría de estos sistemas manejadores de base de datos han implementado el modelo
relacional, este modelo relacional fue presentado por E. Codd (Codd 1970) en los años
setentas y surgió como una nuevo modelo de almacenamiento de datos basado en
relaciones. La implementación que han hecho los sistemas manejadores varía de un
sistema a otro, ofreciendo características diferenciales que les permiten penetrar
diferentes nichos de mercado. Hoy en día existen un gran número de productos en el
mercado de base de datos.
Un sistema manejador de base de datos (SMBD) consiste en una colección de datos
interrelacionados y un conjunto de programas para acceder a dichos datos. La colección
de datos, normalmente denominada base de datos, contiene información relevante para
una empresa u organización. El objetivo principal de un SMBD es proporcionar una forma
de almacenar y recuperar la información de una base de datos de manera que sea tanto
práctica como eficiente (Silberschatz, Korth et al. 2006). La base de datos la podemos
entender como un conjunto de datos perteneciente a un mismo contexto o dominio
almacenados en forma sistemática para su uso.
Todos los sistemas manejadores de base de datos actuales siguen en alguna medida el
modelo relacional presentado en 1970 por E. Codd (Codd 1970). A pesar que el modelo
ha sido utilizado desde entonces, el desarrollo de nuevas tecnologías, la programación
orientada a objetos, sistemas en tiempo real, etc. han generado el surgimiento de otros
tipos de sistemas manejadores de base de datos como por ejemplo los que soportan
bases de datos activas (Rabuzin, Malkovic et al. 2007).
Paralelamente al modelo presentado por Codd, se desarrollo un lenguaje estructurado
basado en el algebra relacional que ejecutaba las operaciones relacionales del modelo,
este lenguaje fue llamado SEQUEL (Chamberlin, D. et al. 1974). Este lenguaje también
fue adoptado por la mayoría de los SMBD por la facilidad de uso y al apego al modelo y
hoy en día se ha convertido en el lenguaje “de facto” de los Sistemas Manejadores de
Base de Datos Relacionales.
Dada la popularidad del lenguaje SQL, se ha desarrollado el estándar que describe al
lenguaje. Dicho estándar establece las pautas para su implementación en los
manejadores de base de datos. Los fabricantes de SMBD han tratado de incorporar
funciones y características de dicho estándar en sus implementaciones y también han
desarrollado las propias o nativas alrededor de su manejador. Pese al cumplimiento al
estándar por parte de los SMBD existen lagunas que no permiten hacer que un modelo de
13
datos basado en el estándar pueda ser migrado a lo largo de dichos manejadores que
dicen cumplir el estándar.
El cumplimiento que los SMBD dan al estándar está orientado a ser tomado como una
guía en el diseño y construcción de dichos sistemas; éstos siguen normalmente las reglas
léxicas y sintácticas que dicta el estándar y son utilizadas en el diseño del lenguaje propio
del manejador.
El lenguaje ha pasado por un largo proceso de estandarización y está plasmado en
documentos de estándares como ISO y ANSI.
A pesar de la existencia de este estándar, cada manejador lo ha implementado de
manera diferente y por esta razón existen diferencias sintácticas o semánticas en la
escritura de instrucciones SQL que no son compatibles de un sistema a otro.
El presente trabajo realiza un estudio para identificar las diferencias en la implementación
de dichas instrucciones en cada sistema manejador propuesto y propone un esquema que
si pueda ser compatible en los sistemas manejadores en cuestión.
Trabajo relacionado
El trabajo que se ha realizado alrededor de este tema es muy amplío y está centrado en
varios aspectos; uno de ellos es el propio proceso de estandarización que ha que se le ha
dado al lenguaje por parte de dos organizaciones de estándares, el American National
Standards Institute (ANSI) y el International Standards Organizations (ISO), las primeras
versiones del estándar fueron desarrolladas por ANSI y posterioremente siguieron
desarrollándose bajo ISO. Otra línea de investigación ha sido referente a medir el nivel de
cumplimiento que logra un sistema manejador de base de datos en relación al estándar;
también encontramos números trabajos que marcan las diferencias que existen en la
implementación que cada sistema realiza del estándar; otro tipo de trabajos están
orientado a la definición de ciertas guías para la escritura de programas basados en SQL
que puedan ser trasladados en diferentes SMBD.
Alejandro Tanasi (Tanasi 2008) realiza una tabla comparativa de los tipos de datos que
soportan los diferentes manejadores de base de datos, esta tabla muestra los tipos de
datos que establece el estándar y el soporte que cada sistema tiene del tipo de dato, con
esta guía podemos ver la compatibilidad que puede existir de un dato por si mismo entre
diferentes sistemas, pero no considera la compatibilidad en la definición y ejecución de
instrucciones SQL que definen estos tipos de datos dentro que cada sistema manejador
con lo que en varios casos estas instrucciones no pueden compatibles de un sistema a
otro. En contraste a esta investigación, el presente trabajo muestra las diferencias en la
escritura de dichas instrucciones alrededor de los sistemas en cuestión.
IBM publicó un libro (IBM 2002) donde menciona algunas mejores prácticas para la
escritura de instrucciones SQL que puedan ser compatibles entre otros sistemas
manejadores de base datos, este trabajo está centrado en su propio sistema DB2, la
14
compatibilidad que indica es a partir de este sistema y no en relación a un estándar de
SQL, a diferencia de este trabajo presento un estudio de compatibilidad entre sistemas
manejadores partiendo del estándar SQL:2003 y no de un sistema en particular.
Peter Gulutzan (Gulutzan and Pelzer 2003) realizó un estudio de desempeño en la
ejecución de instrucciones SQL basadas en el estándar sobre diferentes sistemas
manejadores de base de datos que nos permiten visualizar el impacto que puede tener
ejecutar instrucciones basadas en el estándar con instrucciones o funciones nativas de
cada manejador, este permite considerar los aspectos para la toma de decisiones sobre la
implementación de SQL nativo o estándar bajo ciertos tipos de aplicaciones.
El proyecto AstroGrid (AstroGrid 2009) realizó un estudio comparativo de diferentes
sistemas manejadores donde mencionan algunas características generales de cada
sistema, estas características refieren información acerca de las plataformas,
licenciamiento, desempeño, tipos de datos, escalabilidad, entre otros. La compatibilidad
que sugiere este trabajo está más relacionada a las plataformas y aspectos de hardware
que tiene cada implementación.
Un trabajo de maestría en la universidad VIT de la India (KALIAPPAN and WLOKA 2007)
presenta una investigación sobre el cumplimiento que dan ciertos manejadores al
estándar SQL:2003, se concentra en la parte de “SQL/Schemata” definido en el estándar,
este trabajo muestra características específicas del estándar ejecutadas en los diferentes
sistemas y mide el nivel cumplimiento que tiene cada sistema; con esta información
proporciona un resumen indicando algunos porcentajes que indican el nivel de
cumplimiento que tiene cada sistema en relación al estándar SQL:2003; en contra parte al
presente trabajo encontramos nuevamente que esta información no proporciona
elementos que permitan definir y ejecutar dichas instrucciones de manera transparente en
diferentes sistemas de manera compatible.
Bristle Software (Software 2009) desarrolló un contenido que sugiere algunas técnicas y
puntos importantes para la escritura de instrucciones SQL que puedan ser compatibles en
diferentes sistemas manejadores, en contraste, el presente trabajo incluye la
experimentación sobre la ejecución de instrucciones SQL marcando la incompatibilidad y
sugiriendo algunas alternativas para cumplir con el estándar y permitir su migración hacia
otros sistemas.
Objetivos y Motivación
La posibilidad de almacenar datos de manera persistente a través de medios electrónicos
es una de las razones que han impulsado el desarrollo de sistemas y aplicaciones en gran
escala, esta necesidad llevo al desarrollo de modelos para el almacenamiento y
recuperación de datos y es lo que hoy en día denominados “base de datos”. Las bases
tienen un papel muy importante en el desarrollo de sistemas y aplicaciones ya que la
mayoría de estos sistemas requieren almacenar datos para su operación.
15
Uno de los modelos más importantes es el modelo relacional presentado por E. Codd en
los años 70, y hoy después de más de 30 años sigue vigente en la mayoría de los
sistemas manejadores de base de datos del mercado. Este es un modelo de datos
establece todos los fundamentos que un sistema relacional de base datos debe seguir o
contener para operar como un sistema relacional. El seguimiento que los sistemas que
han implementado el modelo ha sido criticado ya que actualmente no existe un sistema
que lo cumpla de manera completa, sin embargo las implementaciones que se han
desarrollado alrededor de este modelo ha resultado en un mercado extenso y valuado en
billones de dólares.
Otro aspecto fundamental en la existencia de los sistemas manejadores ha sido el
lenguaje que han implementado para la definición y manipulación de datos. De manera
paralela a la presentación del modelo relacional fue presentado también un lenguaje que
permitía manipular a través de instrucciones y comandos las funciones del modelo, este
lenguaje fue “SEQUEL” hoy en día llamado “SQL”. La penetración y aceptación que tuvo
este lenguaje lo ha llevado a ser considerado el lenguaje “de facto” de los sistemas
manejadores de base de datos; mucho del éxito que han tenidos estos sistemas es por el
lenguaje que han implementado.
Este lenguaje ha sido producto de un largo proceso de estandarización, y ha producido
una serie estándares. Los sistemas que han implementado dicho estándar no han logrado
hacer una plataforma compatible entre los propios sistemas que lo implementa. De aquí
que es importante resaltar las diferencias que pueden existir entre las diferentes
implementaciones.
OBJETIVO
El objetivo es hacer un estudio sobre el estándar SQL:2003, las implementaciones que lo
han adoptado y establecer el nivel de compatibilidad que existe entre ellos; también el
recolectar información relevante para desarrolladores interesados en la migración de
esquemas de datos entre diferentes manejadores y para nuevos desarrollos que
requieran asegurar un nivel mínimo de compatibilidad al ser implementado con diferentes
sistemas manejadores de base de datos. Por otro lado, dadas las diferencias
encontradas, establecer las alternativas que pudiesen existir para desarrollar esquemas
de datos compatibles así como establecer algunos factores importantes para ayudar en la
toma de decisiones sobre la implementación de un sistema manejador de base de datos.
16
FUNDAMENTOS DE BASE DE DATOS Y LENGUAJES RELACIONALES.
En este apartado se muestran algunos conceptos fundamentales alrededor del modelo
relacional de base de datos, las instrucciones básicas del sublenguaje de definición y
manipulación de datos y algunos conceptos de los operadores relacionales.
Conceptos
Un sistema manejador de base de datos por sus siglas SMBD, consiste en una colección
de datos interrelacionados y un conjunto de programas para acceder dichos datos. Es un
conjunto de programas especializados para describir, proteger, almacenar y acceder a
una base de datos (Silberschatz, Korth et al. 2006).
Una base de datos puede ser vista como un conjunto de datos que pertenecer a un
mismo contexto y son almacenados sistemáticamente para su uso posterior.
Un sistema relacional de base de datos está basado en el modelo relacional y usan un
conjunto de tablas para representar tanto los datos como las relaciones entre ellos
(Silberschatz, Korth et al. 2006).
El modelo relacional está basado en un modelo matemático que abarca la teoría de dos
ramas: la teoría de conjuntos y la lógica de predicados de primer orden (Zavala 2009).
Matemáticamente, una relación se puede definir como un subconjunto del producto
cartesiana de una lista de dominios (D1, D2, …Dn), donde cada elemento de la relación,
Tupla, es una serie de n valores.
Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales
se le asigna un nombre exclusivo. Cada fila de la tabla representa una tupla y cada
atributo de la tupla es una columna con un valor de un conjunto de posibles, dominio.
El modelo relacional trata tres aspectos fundamentales de los datos: estructura, integridad
y manipulación (Zavala 2009).
El modelo introduce algunos conceptos alrededor del concepto:
Relación: Representa una tabla dentro de la base de datos.
Tupla: Es una fila dentro de una tabla.
Atributo: Es una propiedad o columna de la tabla.
Cardinalidad: Es el número de filas o tuplas que contiene una tabla.
Grado: Es el número de atributos que contiene una tabla.
17
Clave: Es un atributo o conjunto de atributos que identifican de manera única una tupla
dentro de una relación.
Dominio: Es el conjunto de valore posibles que puede tomar un atributo.
Los sistemas manejadores de base de datos proporcionan un lenguaje de definición de
datos para especificar el esquema de la base de datos y un lenguaje de manipulación de
datos para expresar las consultas y las modificaciones de la base de datos (Silberschatz,
Korth et al. 2006). Actualmente existe un lenguaje denominado SQL que ha sido
implementado por la mayoría de los sistemas manejadores de base de datos; este
lenguaje está compuesto de manera general en 3 subconjuntos principales:
DML (Data Manipulation Language). Lenguaje de Manipulación de Datos.
DDL (Data Definition Language). Lenguaje de Definición de Datos.
DCL (Data Control Language). Lenguaje de Control de Datos.
Lenguaje de Manipulación de Datos (DML)
Un lenguaje de manipulación de datos es un lenguaje que permite a los usuarios tener
acceso a los datos de acuerdo a la estructura de los mismos y a su manipulación
(Silberschatz, Korth et al. 2006).
Algunas de las acciones que permite la utilización de este lenguaje son:
Recuperación de información almacenada.
Inserción de nuevos datos en las relaciones de la base de datos.
Eliminación de información de la base de datos.
Modificación de datos de la base de datos.
Este lenguaje es del tipo declarativo ya que permite especificar qué datos serán
manipulados sin la necesidad de establecer cómo se ejecutara dicha acción.
Lenguaje de Definición de Datos (DDL).
La estructura que guarda una base de datos se denomina esquema de datos, este
esquema declara la estructura lógica que tendrán los datos dentro de las relaciones y las
restricciones que aseguran la integridad de los mismos (Silberschatz, Korth et al. 2006).
Las instrucciones que permiten la definición de estos esquemas están integradas en el
lenguaje de definición de datos (DDL).
18
Este lenguaje contiene instrucciones que permite crear, modificar y eliminar relaciones;
provee también instrucciones para definir las restricciones de integridad y la definición de
llaves que aseguren que no exista duplicidad en los datos.
Operadores relacionales
Los operadores básicos permiten a cualquier usuario obtener información de cualquier
parte de la base de datos en una forma flexible y poderosa, sin tener que atender detalles
de programación. La estructura de estos operadores están basados en la lógica de
predicados de primer orden, ésta lógica de predicados fue adoptada por el modelo como
el estándar. Los operadores no están contemplados para ser parte del sistema
manejadores de base de datos, sino para estar integrados en un lenguaje externo al
sistema (CODD 1990).
Los operadores están divididos básicamente en dos, los que operan sobre las relaciones
mismas, y aquellos que permiten manipular los datos contenidos en las tablas.
Operadores básicos (Codd 1990):
Proyección (projection).
Selección theta (theta-selection).
Unión relacional (relational union).
Intersección relacional (relational intersection).
Diferencia relacional (relational difference).
Producto cartesiano (cartesian product).
Reunión theta (theta-join).
Reunión natural (natural join).
División relacional (relational division).
La proyección y la selección aplican sobre un solo operador, el resto de los operadores
utiliza dos operaciones (relaciones).
Proyección: El operador proyección produce una nueva relación de R que contiene solo
algunas columnas o atributos de R.
19
Selección: El operador selección aplicado a una relación R, produce una nueva relación
con un subconjunto de tuplas de R.
Unión: La unión de dos relaciones R y S es el conjunto de tuplas que se encuentran en R
o en S o en ambas.
R y S deben tener el mismo conjunto de atributos y su tipo debe ser también el mismo.
Los atributos de R y S deben aparecer en el mismo orden.
Intersección: La intersección de dos relaciones R y S es el conjunto de tuplas que están
en ambas relaciones R y S.
Las mismas condiciones que tiene la unión se cumple en la intersección.
Diferencia: La diferencia de dos relaciones R y S es el conjunto de tuplas que están en R
pero no están en S.
Las mismas condiciones que tiene la unión se cumple en la diferencia.
20
Producto cartesiano: El producto cartesiano de dos relaciones R y S es el conjunto de
pares conformado por cada tupla de R con cada tupla de S.
Reunión theta: La reunión theta de dos relaciones R y S es el conjunto de tuplas en el
producto cartesiano de R y S que satisfacen alguna condición C.
S
Reunión natural. La reunión natura de dos relaciones R y S es el conjunto de de pares de
tuplas, una de R y la otra de S, que coincidan en cualquier atributo común en las
relaciones R y S.
La relación resultante contiene la unión de los atributos de R y S.
Dadas las relaciones R(A,B,C) y S(B,C,D)
En la siguiente figura podemos resumir los operadores básicos del modelo relacional
(Murali 2009).
21
Figura 1 Operadores relacionales
Operadores de manipulación:
Inserción (insert).
Actualización (update).
Actualización de llave primaria con actualización es cascada (primary key update).
Eliminación (delete).
Eliminación en cascada (delete with cascade).
Estos operadores se ejecutan sobre varios registros o tuplas a la vez, puede ser, cero,
uno o más.
Inserción: El operador de inserción permite una colección de uno o más tuplas ser insertadas dentro de una relación. En esta operación el usuario no tiene ningún control de la forma en que la inserción se realiza. En esta operación no se admiten tuplas duplicadas, si existen duplicados se eliminaran y solo se insertara una tupla .
22
Actualización: Esta operación permite modificar los valores de uno o más atributos de alguna o algunas tuplas ya existentes en la relación. Esta operación debe verificar la integridad referencial y actualizar los índices asociados a la relación.
Actualización de llave primaria: Cuando el valor del atributo corresponde a la lista de atributos que definen la llave primaria de la relación, la actualización se debe realizar para toda llave foránea donde esté implicado el atributo a modificar. Esta actualización se debe llevar en cascada hacia las otras relaciones. Eliminación: Este operador permite eliminar o borrar múltiples tuplas o renglones de una relación: “múltiple” incluye los casos especiales de cero y uno.
Eliminación en cascada: Al igual que la actualización en cascada, cuando la llave primaria de la tupla a eliminar esta presente como llave foránea e alguna otra relación, éstas deben ser eliminadas también siempre que se cumplan todas las reglas de integridad asociadas a las relaciones. Los operadores de actualización y eliminación permiten incorporar el operador de selección para identificar las tuplas en las que aplicara el operador.
23
ESTADO ACTUAL DE LOS SISTEMAS MANEJADORES DE BASE DE DATOS (SMBD).
Los sistemas manejadores de bases de datos surgen en los años 70’s, cuya funcionalidad
principal es el proceso de datos de negocio centralizada bajo un concepto de operaciones
en línea. En los últimos 25 años la mayoría de los sistemas manejadores de bases de
datos han seguido este paradigma. Este paradigma ha dejado de estar vigente ya que
han surgido problemas sobre dominios específicos en las que los sistemas actuales ya no
satisfacen de forma integral las soluciones, esto generará la creación de una colección de
sistemas de bases de datos independientes y heterogéneos, donde cada uno contará con
características orientadas a satisfacer las necesidades de ciertos dominios. Entre los
dominios que ya no son manejados de forma completa por los sistemas actuales
podemos encontrar: “dataware housing”, “stream processsing”, “sensor-based
applications”, “text search” (Stonebraker and Çetintemel 2006).
Hoy en día existe una gran variedad de dispositivos de cómputo que ejecutan una gama
de nuevas aplicaciones y servicios que en el pasado era difícil pensarlas, muchas de
estas se encuentran en el cómputo móvil tales como el envío de mensajes de texto y
multimedia, búsquedas de localidades físicas como el caso de GPS, juegos con motores
de búsqueda y almacenaje de datos distribuidos entre otros (SELTZER 2005).
Estas nuevas aplicaciones en conjunto con los dispositivos demandan nuevos esquemas
de almacenamiento y recuperación de datos, donde estas funciones varían de una
aplicación a otra.
Estas funciones de almacenamiento y recuperación de datos sugieren evidentemente el
uso de bases de datos, en esta caso relacionales. Las bases de datos relaciones han
tenido un enorme éxito en las últimas tres décadas y SQL ha sido el lenguaje “de facto”
para su definición y manipulación de las mismas.
Mucho del éxito de los manejadores de base de datos relacionales se debe a dos
aspectos fundamentales; el primero refiere al hecho de que en el pasado los
programadores eran responsables de dotar de funciones para el almacenamiento y
recuperación de datos atendiendo los factores involucrados en la organización física y
lógica de dichas funciones. Estas funciones eran programadas en cada aplicación, esto
consumía una gran cantidad de tiempo y focalizaba el esfuerzo de los programadores en
aspectos físicos de almacenamiento y recuperación más que crear vistas lógicas de los
datos que apoyaran los objetivos reales de las aplicaciones, así, el uso de las bases de
datos relacionales permitió al programador encargarse de la parte lógica de la aplicación
dejando el resto del trabajo al manejador de base datos; el segundo aspecto
fundamental es que dichos manejadores incorporan el uso de un lenguaje declarativo que
describe los datos en consultas específicas (querys) (SELTZER 2005).
De aquí que las grandes organizaciones que manejaban un gran volumen de datos
adoptarán rápidamente este tipo de sistemas y con esto creció de igual forma la oferta de
estos sistemas en el mercado donde los fabricantes agregaban funcionalidad que les
24
diera cierta diferenciación en el nicho de mercado que atacaban; este hecho generó que
los sistemas manejadores contaran con cada vez mas funciones propietarias que hacían
de ellos sistemas enormes y robustos (SELTZER 2005).
Al paso de las últimas tres décadas es evidente que el modelo de los manejadores de
base de datos actuales se ha vuelto complejo y las tareas de configuración y
administración se han vuelto esenciales para operarlas.
Ante esta situación han surgido numerosos estudios y propuestas que dejan ver que la
arquitectura convencional de manejadores actuales se han vuelto inapropiados para
resolver problemas de nichos específicos. Esto ha llevado al un replanteamiento total
acerca de los manejadores de base datos, de donde se ha sugerido que dichos
manejadores deben ser modulares y expresadas en bloques de componentes (SELTZER
2005).
A pesar de esto, los fabricantes han seguido manejando la idea que sus productos son la
respuesta a cualquier necesidad de administración de datos. Algunos dominios a los que
los manejadores actuales no satisfacen de manera integral la necesidad de administración
de de datos son: Data Warehousing, XML, WebSearch, Stream processing.
Data warehousing.
Este tipo de aplicaciones utiliza tablas con enorme volumen de datos que en la mayoría
son accedidos en formato de solo lectura, solo algunos campos de estas tablas son
utilizados y existe la necesidad de ordenar y sortear las tablas y consultas en diferentes
formas, estas necesidades y funciones han sido adaptadas en los manejadores actuales
para proveer la funcionalidad.
XML.
Las transacciones en línea que utilizan e intercambian información en documentos
codificados y expresados en XML ha aumentado; la solución actual a este tipo de
aplicaciones involucra tareas de conversión de XML a formatos tradicionales de bases de
datos relaciones y viceversa cuando esta información es solicitada, esta solución es
costosa e ineficiente y deja ver la necesidad de contar con modelos de almacenamiento y
administración de datos nativos a XML.
Web search.
La búsqueda de información en Internet está construida sobre herramientas de
administración de datos y de acceso y recuperación de información. El tipo de datos,
objeto del almacenamiento y las consultas, están expresados en archivos con formato
semiestructurado, tal es el caso de HTML, y no en archivos de texto plano, en donde el
resultado de las consultas genera una lista ordenada de posibles respuestas, esta tarea
requiere del uso de índices altamente paralelizados.
Stream processing.
25
Este tipo de aplicaciones utilizan un intenso flujo de envío y recepción de datos, dicha
actividad se centra más en las tareas de filtrado de estos datos más que en el hecho de la
administración y almacenamiento de los mismos. SQL esta principalmente diseñado para
trabajar sobre fuentes de datos persistentes, el stream processing utiliza muchos tipos de
datos que se almacenan de forma temporal y transitoria, con esto podemos ver que los
sistemas manejadores de base de datos actuales no están equipados con funciones
adecuadas para este tipo de tareas.
Estos tipos de aplicaciones no son soportados de manera integral por los sistemas
relacionales actuales; su uso para satisfacer este tipo de aplicaciones requiere
adecuaciones y un sobre-funcionamiento de los mismos. Dado que no existe una
solución única para atacar dichos problemas se ha planteado la necesidad de construir
aplicaciones flexibles que puedan ser adaptadas a las necesidades de una aplicación en
particular; no se debe seguir viendo a los sistemas relacionales actuales como una
solución única y total a todos los tipos de aplicaciones.
Existen varias formas de proporcionar flexibilidad a las aplicaciones: la primera es un
retorno a las prácticas pasadas en las que cada aplicación tenía que desarrollar su propio
de mecanismo o servicio de almacenamiento de datos, esta solución es la más simple y la
menos práctica que podría funcionar para pequeñas aplicaciones, aunque por otro lado,
sería una solución que debería cubrir los requerimientos de almacenamiento en una forma
completa para el tipo de aplicación en cuestión.
La segunda forma de proporcionar flexibilidad es proporcionando un tablero con un
extenso número de opciones que puedan adaptar las necesidades de una clase de
aplicación, esta es una forma usada en los manejadores actuales tal es caso de las
funciones de datawarehousing y OLTP.
La tercera forma es producir motores de almacenamiento con un alto nivel de
configurabilidad que puedan ser ajustadas a los requerimientos de aplicaciones
individuales. La solución que ha emergido alrededor de este tipo de solución es contar
con un número razonable de sistemas de almacenamiento y administración de datos que
sean útiles a un amplio número de clases de aplicaciones.
Existen dos propiedades fundamentales que las aplicaciones deben poseer para poder
responder a la amplia gama de necesidades que se presentan en las aplicaciones
actuales: modularidad y configurabilidad. Son pocas las aplicaciones que requieren y
utilizan toda la funcionalidad que provee un sistema manejador, por ello las aplicaciones
que no requieren de cierto tipo de funcionalidad no deberían pagar por ello en tamaño,
complejidad o costo. Por lo tanto, un motor flexible debe permitir al desarrollador incluir o
excluir subsistemas dependiendo de la necesidad propia de la aplicación.
Modularidad
Algunos opinan que la arquitectura de las base de datos están en la necesidad de una
revolución semejante a la que sufrió el equipo de hardware tipo RISC. La arquitectura
monolítica de los actuales manejadores de base de datos no son lo suficientemente
26
adaptables a las necesidades actuales de datos, de aquí que se deben desarrollar nuevas
capacidades en la administración de datos basadas en componentes sencillos y
reutilizables.
La idea de contar una arquitectura basada en componentes puede extendida para incluir
otros aspectos del diseño de base de base de datos como son el control de concurrencia,
uso de transacciones, registro y alta disponibilidad (SELTZER 2005).
Algunas aplicaciones son completamente de hilos de ejecución único y no requieren
bloqueo, otras aplicaciones tienen un nivel bajo de concurrencia y deben ser atendidos
por bloque a nivel tabla o bloqueos a nivel aplicación; y finalmente existen aplicaciones
que tienen un alto nivel de concurrencia que requieren un bloqueo con un alto nivel de
granularidad así como múltiples grados de aislamiento. En los sistemas convencionales
de base de datos el bloqueo se asume, pero en esta nueva gama de aplicaciones el
bloqueo es opcional y diferentes componentes pueden ser usados para proveer diferentes
niveles de concurrencia.
Las transacciones dan la ilusión de que un conjunto de operaciones son aplicadas a la
base de datos como una unidad atómica y que una vez aplicada, las operaciones
persistirán aun si el sistema falla. El manejo de transacciones es una de las
características medulares de los sistemas manejadores de base de datos, muchas de los
recursos y funciones de los mismos están enfocados a satisfacer este necesidad, esto a
pesar de que muchas aplicaciones no requieren la integración de transacciones en sus
procesos, en este nuevo esquema basado en componentes, esta característica se vuelve
un componente opcional también.
Muchos de los sistemas que manejan transacciones utilizan algún método de registro
para poder realizar la funciones de recuperación (rollback), esto hace latente la necesidad
de integrar el control de registro de la base de datos como un componente adicional, el
cual sería configurado para satisfacer diferentes tipos y niveles de registro dándole la
posibilidad de decidir al diseñador si dicha función de registro es necesaria.
En algunos casos los datos son críticos o altamente sensibles y cualquier tiempo en el
que no estén disponibles es inaceptable. Muchos sistemas de base de datos proveen
modelos de replicación para satisfacer esta necesidad, a pesar que esta funcionalidad ya
es ofrecida como módulos adicionales no existe la posibilidad de incluir o excluir funciones
o conjunto de funciones del sistema base.
Además de proveer aplicaciones más pequeñas y simples, componentes con interfaces
bien definidas y claras proveen un grado de extensibilidad lo cual no es posible en
sistemas monolíticos.
Configurabilidad
La configurabilidad es otro aspecto importante que debe ser cubierto por el nuevo modelo
basado en componentes. Mientras que el aspecto de modularidad es un mecanismo
arquitectónico, la configuración es un mecanismo en el tiempo de ejecución. En una
27
arquitectura basada en componentes, la configuración está involucrada en la selección
apropiada de componentes. Una misma selección de componentes pueden correr en
diferentes sistemas con diferencias en sus capacidades.
La configurabilidad se refiere al hecho de que tan bien un sistema o aplicación puede ser
ajustado a su ambiente y necesidades.
Los ambientes de hardware introducen variabilidad en velocidad de CPU, tamaño de
memoria, capacidad de almacenamiento persistente entre otros.
Esta variabilidad en la tecnología de almacenamiento persistente coloca nuevas
necesidades en los motores de base de datos que permitan tener un control sobre los
medios de almacenamiento y el esquema de persistencia y recuperación.
A pesar que muchos sistemas son capaces de manejar dispositivos sobre diferentes
plataformas, aún existen muchos propietarios. Los modelos de almacenamiento y
administración de datos debe ser portable a una variedad de plataformas de hardware y
sistemas operativos mediante la utilización de librerías en los códigos fuente (SELTZER
2005).
28
EL LENGUAJE SQL “STRUCTURED QUERY LANGUAGE” (LENGUAJE DE CONSULTAS ESTRUCTURADAS).
SQL (Structured Query Languaje) es el lenguaje de definición y manipulación de datos ,
es una lenguaje de consulta estructura (Ullman and Widowm 1999), SQL es el lenguaje
más usado en los sistemas manejadores de bases de datos.
SQL es un lenguaje diseñado para la obtención y administración de datos de un Sistema
Relacional de Base de Datos (RDBMS), así como para la creación de bases de datos y
control de acceso a los mismos (Chapple 2007) (IBM 2006).
Las bases de datos relacionales son las más importantes en el mundo de las bases de
datos porque no son muy difíciles de entender y porque además cuentan con un amplío
estándar: SQL(Baroni, Calero et al. 2005).
El éxito de las bases de datos relacionales no es el resultado únicamente de altos niveles
de independencia de datos y modelos de datos más sencillos que en sistemas anteriores,
mucho de este éxito proviene de la estandarización que ofrecen. La aceptación de SQL
estándar permite un alto grado de portabilidad e interoperabilidad entre sistemas (Catell
and Barry 2000).
Después de cuatro décadas de continua maduración, las bases de datos han llegado a
ser un componente crucial de los sistemas de información, jugando un rol estratégico en
el soporte de decisiones. Una muestra de esto es el mercado de las bases de datos
orientadas a objetos y relacionales alcanzaron 13.6 miles de millones de dólares el año
pasado y se espera alcanzar cerca de 20 mil millones para este año 2008 (IDC, 2005)
(Calero, Ruiz et al. 2005). La piedra angular de un sistema manejador de base de datos
es su lenguaje de consulta.
El modelo relacional de base de datos se fue convirtiendo en el estándar de la industria de
las bases de datos a finales de los años 80’s. El problema es que a pesar de que SQL se
convirtió en un lenguaje de base de datos comúnmente reconocido, la diferencias en la
implementación del mismo en los sistemas manejadores de bases de datos crecían y así
un proceso de estandarización se volvía cada vez más necesario (Kriegel and Trukhov
2008).
Alrededor de 1978, el Comité de Lenguajes y Sistemas de Datos (CODASYL por sus
siglas en Inglés) comisionó el desarrollo de un modelo de datos de red como un prototipo
para cualquier implementación futura de una base de datos. Este trabajo continuo inicio a
finales de los años 70’s con el Comité del Lenguaje de Definición de Datos (DDLC). Para
el año 1982, estos esfuerzos culminaron en la creación del Lenguaje de Definición de
Datos (DDL) y el Lenguaje de Manipulación de Datos (DML) como lenguajes estándares.
Y fue así que después de cuatro años se consiguió el primer estándar del ahora llamado
SQL (Kriegel and Trukhov 2008).
29
SQL ha sido el foco de un proceso intenso de estandarización a lo largo de los años
(87,89,92,95,96,99,2003) en donde la mayoría de los desarrolladores y vendedores de
DBMS han estado involucrados de forma activa. La más reciente versión del estándar,
nombrada SQL:2003, presenta algunas mejoras importantes desde su predecesor:
SQL:1999 (Calero, Ruiz et al. 2005).
El estándar de SQL esta desarrollado por dos organizaciones: el American National
Standards Institute (ANSI) y el International Standards Organizations (ISO). El estándar es
fundamentalmente una base sobre la cual está basada la sintaxis y la lógica del lenguaje
SQL dentro de la implementación de un manejador de base de datos (Jones 2005).
El SQL originalmente llamado SEQUEL (Structured English Query Language) fue
implementado en un prototipo de IBM (SEQUEL-XRM), durante la mitad de los 70’s
(Chamberlin, D. et al. 1974). Algunos años más tarde, un subconjunto de este lenguaje
fue implantado en el (System-R) Sistema-R de IBM. En 1979, ORACLE surgió como el
primer Sistema Manejador de Base de Datos (DBMS) comercial basado en SQL, seguido
de muchos otros productos como: SQL/DS, DB2, DB/SQL, SYBASE, INTERBASE,
INFORMIX, UNIFY. Aún cuando estos productos no implementaban SQL como su
sistema de consulta original ofrecían interfaces SQL como INGRES, ADABAS, SUPRA,
IDMS/R) (Calero, Ruiz et al. 2005).
Como resultado de este proceso, SQL llego a ser el estándar de facto, esto gracias a que
el primer SMDB comercial, ORACLE, lo adoptó. Lo anterior fue comentado por el propio
Don Chamberlin en la conferencia de SIGMOD en 2005 (Chamberlin 2005). A finales de
1982, ANSI H2 empezó a estandarizar una versión del modelo relacional de datos a
través de la aportación del lenguaje de IBM, SEQUEL (ANSI, 1982). Renombrado como
SQL H2, el SQL básico se completó y llego a ser un estándar del ANSI en 1986, y pronto
un estándar ISO en 1987 (Calero, Ruiz et al. 2005).
En 1989, la primera versión del estándar SQL fue revisada y un addendum (ISO,1989) la
cual incluía mejoras en aspectos principales de integridad referencial. Así, ANSI creó un
estándar para el SQL incrustado (embedded) (ANSI, 1989) (Calero, Ruiz et al. 2005).
Al inicio de los años 90’s una nueva versión conocida como SQL2 o SQL-92 fue publicada
por ISO (ISO, 1982). Las capacidades semánticas del lenguaje y el manejo de errores
fueron considerablemente mejoradas en esta versión. El estándar fue complementado
algunos años después con el aprobado SQL/CLI (Call-Level Interface) (ISO,1995) y el
SQL/PSM (Persistent Stored Modules) (ISO, 1996). SQL se convirtió en un completo
lenguaje computacional con características como el control de estructuras y el manejo de
excepciones. Durante la segunda mitad de los 90’s SQL fue extendido por la inclusión de
capacidades de orientación a objetos. El estándar resultante fue dividido en varias partes.
Esta versión formalmente conocida como SQL3 y finalmente nombrada SQL:1999,
incorporó características como nuevos tipos de datos, tipos de datos definidos por el
usuario, operadores de consulta recursivos, cursores sensitivos, generalización de tablas
y roles de usuario (Calero, Ruiz et al. 2005).
30
Desde el estándar SQL:1999 se soporta el paradigma de orientación a objetos. Este
nuevo paradigma propone una buena asociación entre el modelo relacional y el modelo
orientado a objetos. Esta formación tiene un modelo de datos robusto y poderosos
mecanismos de optimización de consultas, recuperación, seguridad y concurrencia. En
esta última versión se incluyen mecanismos de orientación a objetos como el
encapsulamiento, generalización, agregación y polimorfismo que permiten representar
elementos más complejos que son requeridos en varios dominios como CAD, CAM o GIS.
Las bases de datos orientadas a objetos ofrecen la posibilidad de definir clases o tipos de
datos abstractos, así como tablas, llaves primarias y restricciones como las bases de
datos relacionales (Calero, Ruiz et al. 2005).
En la versión ANSI 1992 conocida como SQL 92 se incluyeron aspectos como conexiones
a base de datos, creación de SQL dinámico y “outer joins”, además se establecieron
niveles de cumplimiento al estándar: inicial, intermedio y completo que podían cubrir los
sistemas manejadores. El siguiente estándar fue SQL:1999 el cual incluyo mas tipos de
datos, como arreglos, tipos definidos por el usuario, booleanos, y blobs. Posteriormente
se definió SQL:2003 el cual expandió toda la funcionalidad de su predecesor el SQL:1999
además de incluir un mayor número de tipos de datos con algunas otras funciones; de
aquí que si se le da cumplimiento al estándar SQL:1999 se puede decir que también
cumple con el estándar SQL:2003, es importante resaltar el hecho que un sistema
manejador cumple con el estándar SQL:2003 no significa que ha implementado toda la
funcionalidad y cambios propuestos en la versión.
La última versión del estándar, SQL:2003 (ISO,2003), es el resultado de revisiones
mayores y extensiones de la mayoría de las partes sobre el estándar SQL:1999. Esta
versión incluye SQL/XML (especificaciones XML), nuevos tipos de datos (bigint, multiset,
y XML), mejoras a las rutinas de invocación de SQL, extensiones para la sentencia de
creación de tablas (CREATE TABLE) y la nueva sentencia MERGE, un nuevo esquema
objeto y dos nuevos ordenadores de columnas, identidad y generado (Calero, Ruiz et al.
2005).
SQL ha sido utilizado como un lenguaje estándar para la obtención y manipulación de
datos en los sistemas relacionales de base de datos. Sistemas manejadores como
ORACLE, MSSQL, MYSQL Y POSTGRESQL han adoptado varias técnicas para alcanzar
cierto nivel de cumplimiento al estándar SQL:2003 pero a pesar de esto, la
implementación del estándar no lo hace compatible de un sistema a otro; cada uno de
estos sistemas tienen su propia funcionalidad pero muchas veces logran un nivel mínimo
de cumplimiento a dicho estándar (KALIAPPAN and WLOKA 2007).
El propósito primordial del lenguaje SQL es proveer una forma en la que los sistemas
manejadores de base de datos pudieran definir y obtener datos en una forma declarativa.
Esta forma declarativa se refiere a un tipo de programación en la cual el usuario pueda
especificar o definir los datos que serán seleccionados, actualizados, agregados e
eliminados sin con que éste tenga que conocer la forma en la que éstos datos están
almacenados (Jones 2005). Dentro de las funciones principales que tiene el lenguaje
SQL dentro de un sistema manejador de base de datos podemos encontrar:
31
Obtener datos e información almacenada en el sistema manejador.
Agregar, eliminar o actualizar datos en la base de datos.
Administrar permisos a los usuarios de la misma.
Crear y modificar la estructura de la base de datos.
Existen 3 modelos básicos en los que el lenguaje SQL puede ser implementado (Jones
2005):
Incrustado. Las sentencias SQL están integradas o incrustadas en programas separados
del sistema manejador.
Directo. El implementador provee funcionalidad de operar SQL directamente en el
implementador.
Modulo. Son extractos de código modularizados que pueden ser llamados desde
programa externos y regresan valores o resultados a los mismos.
Actualmente el estándar no establece un nivel de cumplimiento al mismo por parte de los
manejadores por lo cual es estándar es tomado como una base de implementación del
lenguaje SQL dentro de los manejadores de base de datos(Jones 2005).
El objetivo principal de un lenguaje estándar es proveer portabilidad de aplicaciones entre
productos o plataformas. Con el mismo conjunto de datos sobre dos sistemas
manejadores de bases de datos, los mismos “querys” retornaran los mismos resultados.
Pero en la realidad la portabilidad sobre diferentes sistemas o aplicaciones implica una
serie de retos significativos para su ejecución (Paul 1999).
Un lenguaje estándar es relevante en la medida que asegure que sea útil y usado. Nos
referimos al término útil cuando el lenguaje estándar ayuda a resolver problemas que se
supone están dentro del ámbito de dominio; y usado en el sentido que sea adoptado por
fabricantes y desarrolladores de aplicaciones (Paul 1999).
Evolución de SQL (Calero, Ruiz et al. 2005)
Año Descripción
70’s Modelo Relacional Prototipos DBMS (SEQUEL XRM) Aparece el primer SMBD Relacional
80’s ANSI SQL-86 ISO SQL-87
32
Año Descripción
SQL-89 ANSI Embedded SQL
90’s SQL 92 SQL/CLI SQL/PSM SQL:1999
2003 SQL:2003
2008 SQL:2008 Tabla 1 Evolución de SQL
Proceso de estandarización de SQL (Kriegel and Trukhov 2008)
SQL-86/87 (SQL1)
X3H2 fue un mandato para estandarizar el modelo relacional en el año de 1982. El
proyecto estaba basado inicialmente en las especificaciones el sistema de IBM SQL/DS, y
durante algún tiempo éste siguió el sistema el desarrollo de DB2 de IBM.
En 1984, el estándar fue rediseñado con el objetivo de ser más genérico y de permitir una
mayor diversificación dentro de los diferentes fabricantes de sistemas manejadores de
base de datos. Después de un largo proceso burocrático fue reconocido como estándar
hasta 1986 por el American National Standards. En 1987, la International Organization for
Standardization ISO adopto el estándar.
SQL-89 (SQL1.1)
SQL-89 es en cierto grado un estándar minimalista que fue establecido para incorporar
todos los sistemas manejadores existentes en 1989. Solo comprendía un número limitado
de características relacionadas estrictamente a la colocación y recuperación de datos en
un sistema relacional de base de datos. Muchos de los fabricantes de sistema
comerciales no pudieron llegar a un acuerdo al respecto de ciertas características del
estándar y por tal razón éste quedo intencionalmente incompleto y muchas características
fueron marcadas como “definidas por el implementador”.
SQL-92 (SQL2)
Debido a las diferencias y limitaciones que presentaba el estándar, éste fue revisado y se
publicó el primer estándar solido de SQL: SQL-92. ANSI tomó el estándar SQL-89 como
su base pero corrigió muchas debilidades que presentaba y llenó muchos aspectos
inconclusos y finalmente presento características conceptuales de SQL. Cabe mencionar
que SQL-92 es cinco veces más grande que su antecesor (cerca de 500 páginas más)
y establece 3 niveles de cumplimiento.
El primer nivel de cumplimiento (Entry-Level) fue básicamente introducido desde el
estándar SQL-89, las diferencias en realidad fueron muy pocas con el antecesor, por
ejemplo, la especificación de la inclusión de “WITH CHECK OPTION” fue simplemente
ampliada en su explicación.
33
El nivel intermedio de cumplimiento (Intermediate-Level) fue un conjunto de mejoras
significativas que incluía, por ejemplo, nombres definidos por el usuario para las
restricciones (constraints); soporte para caracteres de longitud variable y la especificación
de conjuntos de caracteres, expresiones de “casting”, operadores de unión (join’s),
inclusión de comandos para modificar estructuras de tablas como “alter table”, uso de
transacciones, uso de subconsultas (subqueries) en vistas actualizables y el uso de
operadores que permitían unir el resultado de varias consultas, por ejemplo, UNION,
EXCEPT, INTERSECT. Este nivel de cumplimiento ofrececia al desarrollador una serie
de características que permitían potenciar el uso de los sistemas manejadores de base de
datos relacionales.
El nivel de cumplimiento total (Full-Level) incluía algunas características avanzadas como
la deshabilitación de restricciones (constrainst), tablas temporales y el establecimiento de
permisos sobre conjuntos de caracteres y dominios.
La medición sobre el nivel de cumplimiento que un sistema daba al estándar de SQL era
evaluado por el Departamento de Comercio del gobierno de los Estados Unidos a través
de su Instituto Nacional de Estándares y Tecnología (NIST). Los fabricantes que querían
ser considerados como compatibles con el estándar tenían que aprobar dicha prueba.
Esto se convirtió en una ley en 1990, y establecía que un sistema relacional de base de
datos (RDBMS) debía cumplir con dicha prueba para poder ser considerado por cualquier
agencia federal.
En 1996, NIST desmantelo el programa de verificación de cumplimiento al estándar
debido a razones de costo. Desde entonces, los fabricantes han dejado el objetivo
fundamental de generar sistemas que cumplieran de manera estricta con el estándar; esto
le ha permitido desarrollar sistemas que incluyen una alta variedad de funciones
propietarias y de sistemas que proporcionan características que los diferencian de sus
competidores sin tener un nivel estándar de cumplimiento.
SQL:1999 (SQL3)
SQL:1999 representó un avance muy importante en el desarrollo del estándar de lenguaje
SQL. El trabajo y los esfuerzos por desarrollar este estándar iniciaron incluso un año
antes de que su predecesor fuera adoptado. El desarrollo de este nuevo estándar estuvo
guiado por ambos comités de estandarización: el ISO y el ANSI, este cambió introdujo
cambios dramáticos en el mundo de las bases de datos como el cambio de paradigma en
la adopción y diseño de bases de datos basados totalmente en el modelo relacional.
Su incomparable complejidad se ve reflejada en el número de páginas impresas que
contenía este nuevo estándar, 2000 páginas, que comparadas con las 120 del SQL-89 y
las 628 del SQL-89 representaba y suponía un estándar mas amplío y con muchas
nuevas características. Algunas de las características que incluía este estándar eran
implementadas como extensiones a los sistemas base de los fabricantes, como el caso
de los procedimientos almacenados (stored procedures) que no estaban incluidos como
parte del núcleo y se ofrecían como extensiones al mismo. La inclusión de funciones y
34
características del modelo orientado a objetos fueron completamente elementos nuevos
en esta versión del estándar. SQL3 fue liberado como un estándar ANSI e ISO en 1999.
SQL3 extiende el modelo relacional tradicional para incorporar objetos y tipos de datos
complejos dentro de las tablas relacionales, así como todas las funciones soportadas.
Este estándar trae todos los principales principios de la programación orientada a objetos,
como la herencia, encapsulamiento, polimorfismo a parte de todas las características del
estándar que ya incluía su antecesor.
SQL:2003
Este estándar surge con una expectativa muy grande alrededor de XML. Adicionalmente
tiene algunas modificaciones y agregaciones al estándar anterior, SQL:1999, así como
algunas nuevas características como son las funciones de tabla, generadores de
secuencia, valores autogenerados, columnas identidad y algunas modificaciones al
Lenguaje de Manipulación de Datos (DML) como el caso del comando MERGE y también
al Lenguaje de Definición de Datos: CREATE TABLE LIKE y CREATE TABLE AS.
También se quitaron un par de tipos de datos ya obsoletos como es el caso de BIT y BIT
VARYING y al mismo tiempo se agregan algunos como BIGINT, MULTISET y XML.
SQL:2003 consiste de nueve partes y consta de alrededor de 3600 páginas, lo cual es
casi dos veces el tamaño del estándar anterior.
SQL:2008
SQL:2008 es la última revisión del estándar de SQL. En este estándar se hizo una
revisión y se le hicieron ciertas modificaciones a la parte relacionada a XML y algunos
cambios que quedaron pendientes en su versión anterior. Esta nueva versión incluye
nueves tipos de datos como BINARY, el manejo de expresiones regulares y la posibilidad
de incluir comandos como FIRST n en las vistas.
35
ALGUNAS IMPLEMENTACIONES DEL LENGUAJE SQL.
Un aspecto importante en la comprensión de las bases del lenguaje SQL ANSI como
estándar, es conocer y ver la forma en la que es implementado en los sistemas
manejadores de base de datos, ya que a pesar que el estándar establece las bases del
lenguaje, cada manejador lo implementa de forma diferente dando como resultado
diferencias significativas entre los sistemas que implementan dicho estándar.
En este apartado haremos un recorrido por las principales implementación de SQL en el
mercado; mostraremos las características generales que cada manejador ofrece dentro
de su sistema.
Las implementaciones que abordaremos son: ORACLE, SQL SERVER, POSTGRESQL y
MYSQL. De cada uno presentaremos sus características principales, posición en el
mercado y algunos aspectos comerciales de los mismos. Las características que se
muestran son generales y en algunos casos diferenciales que los fabricantes marcan para
su producto como mejoras o nuevas características, de aquí que no se mencionen las
mismas características para todos los sistemas.
Oracle
La base de datos de Oracle es un popular sistema manejador de base de datos (SMBD)
desarrollado y comercializado por una de las compañías de software más importantes del
mundo, Oracle Corporation (Kimpo, Lucero et al. 2004).
IBM fue unos de las empresas que implementó el modelo relacional presentado por E.
Codd en un sistema manejador de base de datos relacional comercial, éste fue el caso de
“System/R” que a su vez incorporó un lenguaje de creación y manipulación de datos
denominado SEQUEL, y más tarde nombrado SQL. Este trabajo trajo la atención de un
grupo de ingenieros en California, E.U. alrededor del modelo relacional y posteriormente
fundaron una empresa denominada Relational Software; para finales de década de los
70’s esta empresa liberó su primera versión de un SMBD comercial denominado
ORACLE. Años más tarde la empresa cambió su nombre por Oracle Corporation, nombre
que hoy en día sigue vigente (Kimpo, Lucero et al. 2004).
A lo largo de la década de los 80’s Oracle Corporation creció y se consolidó como el
proveedor más grande en la venta de sistemas manejadores de base de datos con un
total de 1000 instalación para el año de 1985 (Kimpo, Lucero et al. 2004).
A partir de la versión 8.0 el sistema integra un paradigma nuevo orientado a objetos, lo
cual lo pone nuevamente un paso adelante con respecto a sus competidores, la última
versión 11 g sigue siendo un sistema relacional pero con una crecida lista de
características orientadas a objetos (Kimpo, Lucero et al. 2004).
36
Características generales.
La base de datos de Oracle está disponible para distintos sistemas operativos en los que
podemos encontrar: Linux, Mac OS X, Solaris y Windows. También disponible en
diferentes versiones: un usuario, multi-usuario, red y distribuido.
Incluye características orientadas a objetos dentro del esquema relacional, es
considerado un sistema híbrido. Para este efecto el lenguaje SQL del manejador incluye
una instrucción para la creación de objetos (CREATE TYPE as object).
Oracle utiliza un dialecto de SQL denominado SQL*PLUS, el cual es reconocido como la
implementación de SQL más completa y sofisticada. Oracle soporta el estándar de SQL y
extiende el lenguaje a través de sus funciones propias.
Fundamentos de Oracle Database.
Diseño seguro. Oracle utiliza una arquitectura centralizada (kernerlized architecture), la
cual emplea un sistema que opera entre la base de datos, el manejador, las vistas
externas y los usuarios de la misma. Este sistema aumenta la protección y administra las
peticiones de datos a nivel físico.
Identificación y autenticación de usuarios: Oracle provee dos mecanismos para el acceso
seguro: la autenticación por contraseñas y a nivel sistema operativo.
Integridad de datos: Oracle es compatible con el manejo de transacciones alrededor del
concepto ACID (Atomic, Consistent, Isolation, Durability)(Kimpo, Lucero et al. 2004).
Permite el bloqueo a nivel registro, incluye también reversas completas y parciales
(rollforwards) para la restauración de datos.
Funciones avanzadas: Oracle suporta el uso de procedimientos almacenados (store
procedures), vistas (views), secuencias (sequences), disparadores (triggers), cursores
(cursors), herencia (inheritances) y datos definidos por el usuario (user_defined data-
types).
Ordenación (Indexing). Oracle emplea poderos mecanismos de ordenación y soporta
índices en columnas simples, multicolumna, llaves primarias y campos de texto.
Métodos de interface: Oracle permite realizar interfaces a través de ODBC, JDBC, C++ y
Java. La versión profesional también permite interfaces con COBOL, FORTRAN, PL/1
ADA y PASCAL.
Restricciones de integridad (Integrity Constraints). Oracle soporta la opción de habilitar y
deshabilitar las restricciones de integridad.
Mejoras a la última versión.
Los procesos de respaldo, recuperación y restauración han sido aumentadas y mejoradas
incluyendo varias nuevas características:
37
Copias de imagen extendidas (Expanded Image Copying). Una copia de un archivo de
datos se restaura más rápido que una archivo de datos completo debido a que la
estructura física del archivo de datos ya existe.
Creación y actualización de respaldos incrementales (Incrementally Udated Back-Ups).
Permite crear y aplicar cambios de base de datos incrementales hacia una copia de
imagen de un respaldo.
Creación automática de archivos de datos faltantes.
Mantenimiento mejorado de logs de recuperación.
Administración mejorada en los recursos y procesos de respaldo.
Recuperación independiente de tablas. Permite recuperar tablas eliminadas de manera
independiente sin la necesidad de recuperar la base de datos completa, esto gracias a
que cada que se elimina una tabla ésta es enviada a una bandeja de reciclaje.
Análisis de fortalezas y debilidades.
Fortalezas:
Oracle es el más fuerte sistema manejador de la industria en términos de complejidad y
características ofrecidas. Siendo el primer SMBD relacional lo hace un “veterano” en ese
campo y le permite consolidarse como el líder tras cinco décadas de mejoras. También el
sofisticado dialecto de SQL que implementa (SQL*PLUS) da una vasta lista de
capacidades y da a su vez mas elementos y herramientas al desarrollador para usar,
ampliar y explotar las bases de datos.
Las estrategias de ordenación son por mucho superiores a las ofrecidas por SMBD de
código abierto (Open Source) ya que la naturaleza relacional y orientada a objetos le da al
desarrollador la libertad de explotar los beneficios de ambos paradigmas.
Otra ventaja que ofrece Oracle son las diferentes plataformas o sistemas operativos en
los que puede correr el sistema como Linux, Windows y Unix. Oracle permite también
administrar terabytes de información de manera sencilla a diferencia de sus competidores.
Debilidades.
La complejidad que mantiene Oracle es una de sus principales debilidades ya que
requiere que el desarrollador mantenga un nivel alto de conocimiento para poder realizar
funciones dentro del sistema.
Dado que el sistema Oracle está dotado de un gran número de características, éste tiene
un costo significativo; es precio es otra debilidad en el sentido que se vuelve en algunos
casos un sistema “caro” que deja fuera algunas organizaciones de adquirirlo. La versión
sencilla no contiene muchas de las funciones importantes que tiene Oracle.
38
Además, la inclinación de un sistema hibrido, orientado a objetos y relacional, que
mantiene el manejador aumente la complejidad e introduce flujos no deseados en el
modelo relacional.
Al comparar las fortalezas y debilidades de Oracle encontramos tres aristas
fundamentales: Precio vs Potencia, Complejidad vs Facilidad de Uso y Modelo Objeto-
Relacional vs Modelos no Relacionales.
La base de datos de Oracle fue pionera en la implementación del modelo relacional y uno
de los primeros en la implementación del lenguaje SQL como su lenguaje base; Oracle es
un sistema caro y complejo pero lleno de características incluidas en un paquete que
permiten manejar cualquier escala de datos sobre una amplia variedad de plataformas.
Oracle fue el primer sistema manejador de base de datos relacional que incluyó por
primera vez el lenguaje SQL como su base de definición y manipulación de datos. En su
versión 10g, Oracle cumple con el estándar SQL:2003 y cuenta con diferentes versiones
para sistemas operativos.
SQL SERVER
Microsoft es una de las compañías más grandes de desarrollo de software. Cuenta con un
manejador de base de datos denominado SQL SERVER en diferentes versiones,
actualmente la más reciente es SQL SERVER 2008.
SQL Server (MSSQL) ha pasado por un largo proceso de evolución. La versión original de
SQL Server fue liberada en 1988 como un producto de Microsoft y Sybase que corría
sobre OS/2 exclusivamente. Esta versión fue una falla ya que no hubo una buena
aceptación en el mercado.
En 1994, Microsoft finalizó su relación con Sybase y liberó una nueva versión 6.0 en 1995
seguida de otra versión 6.5 en 1996. No fue hasta esta última versión en la que SQL
Server inició a penetrar en el mercado generando aceptación entre los directores y
desarrolladores de base de datos.
Mucho de este nuevo éxito que experimentó el sistema de Microsoft fue gracias a las
nuevas características que incluyó en su última versión y gracias a que de manera
paralela existía un crecimiento en la adquisición e instalación de servidores basados en
procesadores Intel y a su vez basados en el sistema operativo de Microsoft Windows NT.
Posteriormente Microsoft liberó su versión 7.0 con la que finalmente permitió el ingreso de
SQL Server al mercado de base de datos de alta disponibilidad.
Licenciamiento
SQL Server tiene tres opciones de licenciamiento:
39
Licencia por procesador.
Se requiere de una licencia por cada procesador en el sistema operativo. Este tipo de
licencia no requiere licencias para los clientes que se conectan al servidor.
Licencia por dispositivo (Server plus device CALs).
Este tipo de licencia requiere una licencia para el servidor que corre el servidor de base
de datos y una licencia para cada dispositivo cliente que se conecta al servidor de base
de datos.
Licencia por usuario (Server plus user CALs).
Requiere una licencia para el servidor que corre el servidor de base de datos y otra para
cada usuario que se conecta al mismo.
Características principales
Integración con Windows.
Correo de manera integrada en todos los sistemas operativos de servidor de Microsoft
Windows.
Disponibilidad en ambiente Web.
Permite correr aplicaciones en ambiente Web.
Soporte enriquecido de XML.
Trabaja de forma integrada con archivos con formato XML en alojamiento y transferencia
de éstos.
Análisis Web.
Permite analizar data de cubos OLAP remotos que sean disponibles desde Web.
Acceso Web a datos.
Permite la conexión del servidor de base de datos hacia cubos OLAP de manera flexible.
Alta disponibilidad.
Permite integrar el servidor en arreglos de clusters, realizar respaldos en línea y llevar un
registro detallado de actividades (log).
Escalabilidad.
Permite escalar las aplicaciones hasta en un máximo de 32 CPU’s y utilizar hasta 64 GB
en memoria RAM.
40
Seguridad.
Establece un sistema de seguridad basado en role e implementa encriptación en archivos
y redes.
Vistas distribuidas particionadas.
Permite dividir o particionar la carga de procesamiento a lo largo de diferentes servidores.
Administración de base de datos simplificada.
SQL Server incorpora una consola de administración que permite afinar el sistema y dar
mantenimiento al mismo.
Servicio de transformación de datos.
El servidor tiene herramientas que permiten integrar datos desde fuentes externas y
heterogéneas de información hacia la base de datos.
Vistas ordenadas.
Permite guardar resultados de query’s en el hardware disponible al sevidor y utilizarlo
posteriormente, esto reduce el tiempo de respuesta del servidor de base de datos.
Replicación
SQL Server implementa un modelo de replicación transaccional, combinado y resumida.
Creación de preguntas en inglés.
Permite al usuario redactar preguntas no estructuradas en el lenguaje inglés hacia la
base de datos.
Servicio de análisis OLAP.
Permite realizar análisis rápidos y sofisticados sobre sets de datos largos y complejos.
Minería de datos.
Incluye herramientas que permiten ejecutar tareas de minería de datos para descubrir
patrones, tendencias en los datos almacenados.
Aspectos de Seguridad
SQL Server implementa un mecanismo de identificación y autenticación para poder
acceder a los datos en la base alojada. Cualquier usuario debe ser autentificado antes de
poder acceder al sistema y a los datos.
SQL Server incorpora dos mecanismos de autenticación de usuarios: el primero basado
en el modelo de Windows NT, normalmente adjunto al sistema operativo, y el segundo
basado el modelo integrado del propio manejador de base de datos.
41
SQL Server administra dos tipos de cuentas de usuario:
Login ID.
Database User ID.
E incorpora tres tipos de permisos:
Statement.
Object.
Implied.
Respaldo de base de datos.
El método de respaldo de base de datos que utiliza SQL Server es uno de los más
versátiles y confiables. Dentro de las funciones de respaldo con las que cuenta el servidor
podemos mencionar:
Respaldo de bases de datos enteras.
Respaldo de archivos específicos de base de datos.
Respaldo del archivo de registro (log).
Respaldos diferenciales.
Los respaldos que realiza el servidor son confiables ya que nunca realiza respaldos de
transacciones de manera parcial, con esto, este tipo de respaldos mantienen la integridad
de los datos.
Los respaldos los pueden realizar de manera dinámica, es decir, permite ejecutar los
procesos de respaldo mientras esta en uso la propia base de datos.
Características diferenciales.
Servicios de notificación.
Permite a los negocios construir aplicaciones de notificación enriquecidas que envían
información personalizada en tiempos predefinidos hacia cualquier dispositivo.
Servicios de reportes.
Una de las características importantes que incluye SQL Server son los servicios
integrados para la generación de reportes que incluye la creación de archivos en formato
PDF.
Uno de los objetivos principales de este sistema manejador de base de datos es
proporcionar un fácil uso al usuario a un costo accesible en comparación de otros
sistemas bajo el esquema de licencias comerciales.
42
Otro aspecto importante es que esta manejador incorpora su propia implementación de
SQL denominada T-SQL el cuál no cumple de manera amplía el estándar ANSI de SQL a
pesar que no muestra diferencias aparentes con dicho estándar (Jones 2005).
Una limitante importante que muestra este manejador de base de datos es que solo
puede correr en la propia plataforma del sistema operativo de Microsoft.
POSTGRESQL
PostgreSQL es un sistema manejador de base de datos orientado a objetos y relacional
derivado del paquete POSTGRES, fue desarrollado en 1986 en la universidad de
California en Berkeley (Kimpo, Lucero et al. 2004; Jones 2005). El proyecto fue lidereado
por el profesor Michael Stonebraker y patrocinado por la Agencia de Proyectos de
Investigación Avanzada de la Defensa (DARPA por sus siglas en Inlgés), la Oficina de
Investigación de la Armada (ARO), la Fundación Nacional Científica (NSF) y la
corporación ESL Inc. (Kimpo, Lucero et al. 2004) .
La primera demostración operacional del software fue el 1987. Posteriormente en junio de
1989, la versión 1 fue liberada para solo algunos usuarios externos al proyecto. Como una
respuesta a la revisión del sistema de reglas de sistema, la versión 2 fue liberada el año
siguiente. La versión 3 apareció en el año de 1991 la cual agregó soporte para múltiples
modos y administradores de almacenamiento, un ejecutor de query’s mejorados y un
sistema de reglas re-escrito completamente. El proyecto de Berkeley POSTGRES terminó
oficialmente con la versión 4.2 después de un largo tiempo de desarrollo e investigación
(Kimpo, Lucero et al. 2004).
En 1994, Andrew Yu y Jolly Chen agregaron un intérprete del lenguaje SQL al sistema
POSTGRES. Esto generó una nueva versión denominada Postgres95 la cual fue liberada
en la web, dejando una marca en el mercado de las base de datos como un descendiente
de código abierto (open-source) del proyecto de Berkeley POSTGRES.
Esta nueva versión está escrita complemente en ANSI C. Además de todas las
correcciones de los “bugs” conocidos de la versión anterior, el lenguaje de consultas
PostQUEL fue remplazado por SQL. Con esto, el uso de subqueries fue soportado. Las
funciones de agregación fueron re-implementadas en su totalidad con lo que la sentencia
de agrupación GROUP BY fue agregada al sistema.
Así, PostgreSQL nació de la integración del proyecto original POSTGRES y la inclusión
de SQL como el lenguaje base del sistema manejador.
Licenciamiento
PostgreSQL es distribuido bajo GNU Public License, la cual permite muchas posibilidades
sin costo alguno, como son el uso, modificación, distribución para cualquier propósito ya
sea privado, comercial o académico.
Características Principales.
43
PostgreSQL soporta los estándares SQL92 y SQL99 y ofrece la creación de query’s
complejos, llaves foráneas (foreign keys), disparadores (triggers), reglas (rules), vistas
(views), integridad transacional y control de concurrencia multicontrol.
PostgreSQL puede ser extendido por el usuario de manera libre y abierta como por
ejemplo agregando nuevos tipos de datos, funciones, operadores, funciones de
agregación métodos y lenguajes procedimentales.
PostgreSQL es el único sistema “open source” que soporta lenguajes procedimentales
para la construcción de procedimientos almacenados (strored procedures) y disparadores
de eventos (triggers). Utiliza el lenguaje PL/pgSQL para la definición de estos comandos.
Este lenguaje sigue el formato y estructura del homologo PL/SQL de Oracle.
PostgreSQL incluye interfaces nativas para ODBC, JDBC, C, C++, PHP, Perl, TCL,
ECPG, Python y Ruby.
PostgreSQL soporta comunicación SSL y utiliza mecanismos de autenticación basados en
Kerberos.
Cumple con ambos esquemas para el manejo de transacciones ACID (atomicity,
consistency, isolation, durability) y el ANSI SQL.
PostgreSQL permite la replicación, siendo posible la duplicación de servidores maestros a
múltiples servidores esclavos. Dado que PostgreSQL es un sistema orientado a objetos,
permite la herencia.
PostgreSQL ejecuta outer JOIN y SUBSELECT y soporta UNION, UNION ALL y EXCEPT.
También incorpora el operador SQL LIKE y SIMILAR TO del SQL99, permite también la
ejecución de expresiones regulares con estilo POSIX.
El sistema cuenta con herramientas que permiten generar instrucciones SQL portables
ejecutables en otros sistemas compatibles con SQL. Las funciones son compatibles con
tablas cruzadas para permitir una transición desde sistemas con un menor rango de
compatibilidad.
PostgreSQL corre en modo servidor de manera nativa en Linux, Windows, UNIX entre
otros.
Las versiones recientes son capaces de recuperarse desde una falla de una sentencia
dentro de una transacción mediante el uso de puntos de recuperación (savepoints). No es
posible realizar una recuperación desde disco ante una falla excepto si se hace la
recuperación desde un respaldo previo o desde un servidor de replicación. Establecer
puntos de recuperación temporales permite realizar respaldos continuos del servidor. Así,
es posible recuperar desde un punto de falla o desde una transacción pasada.
El uso y definición de espacios de tablas (tablespaces) son una característica más del
sistema. A través de estos, los administradores pueden seleccionar los sistemas de
archivos donde se pueden almacenar tablas, índices y base de datos completas. Los
44
espacios de tablas permiten mejorar el desempeño y control sobre el espacio en disco
que se utiliza para almacenar las bases de datos.
En versiones pasadas, la precisión de un número flotante era tomada para establecer el
número de dígitos en un número decimal. Esta característica fue corregida para cumplir
con el estándar de SQL, el cual indica que la precisión debe ser medida in dígitos
binarios. También en versiones anteriores, las cadenas muy largas eran siempre
truncadas sin generar error alguno y los bits eran truncados o rellenados con ceros en la
derecha, con o si un casting explicito.
PostgreSQL es un software complejo, en función de otros sistemas de código abierto de
base de datos, y su administración puede resultar una tarea complicada. Muchas de las
mejoras que se buscan para el sistema se desarrollan más eficientemente cuando son
desarrollados de manera separada al núcleo del sistema. Algunas de estas interfaces son:
psqlODBC Interface común para aplicaciones basadas en Windows.
Pgjdbc Interface JDBC para aplicación de Java.
Npgsql Interface para aplicaciones Windows basadas en el framework .NET
Libpqxx Una versión nueva de la interface para el lenguaje C++.
Pgperl Interface para el lenguaje de programación Perl.
DBD-Pg Interface Perl que utiliza la API entandar DBD.
Pgtclng Interface para TCL.
PyGreSQL Interface para Python.
Análisis de fortalezas y debilidades.
Fortalezas.
Es libre en el sentido que no hay que pagar un costo económico.
Flexibilidad para realizar investigación y desarrollo de prueba.
Soporta un subconjunto amplio del estándar SQL.
Soporta tamaño de tablas muy grandes, incluso rebasa el límite máximo en sistemas
Linux.
Es un sistema completamente programable.
Es un sistema extensible ya que el código está disponible para cualquier persona sin
costo adicional.
45
Se encuentra en el rango medio de velocidad de respuesta de los sistemas manejadores
de bases de datos comerciales.
Está disponible para casi todas las marcas de UNIX, Linux y Windows.
Permite utilizar múltiples estrategias de almacenamiento para renglones o tuplas en
ambientes con altos niveles de volúmenes de datos.
Debilidades.
PostgreSQL esta aún en el camino de lograr el cumplimiento total a los estándares SQL92
y SQL99.
Existe una falla al aplicar funciones de permisos a la base de datos.
Existe otra falla de “buffer overflow” cuando existe una declaración de cursor.
PostgreSQL corre más lento que su competidor directo MySQL.
Diferenciadores.
PostgreSQL es el único sistema de código abierto (Open source) que soporta un lenguaje
procedural para construir procedimientos almacenados (Strored procedures) y
disparadores (triggers). Utiliza un lenguaje llamado PL/pgSQL para estos comandos.
Incluye tipos de datos adicionales como son tipo de datos geométricos como puntos,
líneas, cuadros, polígonos, círculos y direcciones de red como inet, cidr, inet y macaddr.
PostgreSQL es un sistema más completo y complejo que su competidor MySQL, pero
tiene una ejecución más lenta.
PostgreSQL es considerado el manejador más potente en el mercado “Open Source”. Fue
desarrollado inicialmente para correr sobre plataformas UNIX pero en las versiones más
recientes puede correr en plataformas basadas en Windows. PostgreSQL fue desarrollado
con el objetivo fundamental de ser compatible con el estándar.
MYSQL
MySQL es un manejador de base de datos “Open Source” desarrollado por la compañía
Sueca MySQL AB. MySQL fue completado en mayo del 2005 por Michael Monty (Kimpo,
Lucero et al. 2004). Este manejador fue inicialmente desarrollado con el objetivo de de
proporcionar velocidad y desempeño más que con el objetivo de cumplir con un estándar.
46
Es un sistema de código abierto desarrollado en ANSI C y tiene conexión nativa desde
diferentes lenguajes de programación como C, C++ Smaltalk, Java, Perl, PHP, etc.
MySQL está disponible bajo dos tipos de licencias:
GNU General Public License. Los permisos de usuario están protegidos en dos
esquemas: software copyright y posesión de licencia que proporciona permisos legales de
copia, distribución y/o modificación.
Commercial License. En este esquema, no se proporcionan los códigos fuentes. Los
clientes adquieren una licencia comercial con soporte. Existe la posibilidad de re-distribuir
el software.
Características principales de MySQL.
Velocidad.
Es una de las características principales del sistema manejador, fue uno de los principales
objetivos desde su desarrollo (Kimpo, Lucero et al. 2004). Algunos estudios comparativos
de desempeño colocan a MySQL como uno de los más rápidos ante diferentes pruebas
realizadas en diferentes sistemas manejadores de base de datos.(AB 2005)
Precio.
Aunque existe una versión libre de MySQL que no tiene un costo, existe una licencia
comercial que está por debajo de los 500 dólares mientras que otros sistemas están
alrededor de los 50,000 dólares (Kimpo, Lucero et al. 2004).
Seguridad.
El servidor de la base de datos soporta SSL (transport-layer encryption) como parte del
sistema avanzado de seguridad y permisos. La versión 4.0 permite establecer recursos
por usuario (Kimpo, Lucero et al. 2004).
Multiplataforma.
MySQL puede ejecutarse sobre Linux, Windows, FreeBSD, Sun, MAC OS, entre otros.
Adicionalmente tiene soporte para diferentes lenguajes de programación así como un
conector ODBC para la base de datos (Kimpo, Lucero et al. 2004).
Confiabilidad.
MySQL es un sistema que normalmente no requiere grandes esfuerzos en
mantenimiento, no son usuales las caídas del sistema; cuando llega a existir una caída se
puede recuperar fácilmente. MySQL AB tiene un control de código con las versiones que
libera y siempre incluye las modificaciones a los “bugs” conocidos.
47
Flexibilidad.
En MySQL el administrador de la base de datos puede elegir el tipo de motor de
almacenamiento de las relaciones:
InnoDb: Orientado a aplicaciones con transacciones con commits, roll back y crash
recovery.
MyISAM. Es el motor por default, orientado a aplicaciones no transaccionales. Este
tipo de motor ofrece un mejor desempeño.
MySQL permite definir diferentes tipos de motores para diferentes tablas en una misma
base de datos.
BLOB’s.
MySQL permite manejar atributos binarios que son tratados como cadenas binarias y
pueden almacenar datos binarios no procesados, como archivos los cuales pueden ser
manipulados como cualquier tipo común de datos.
Transacciones y Operaciones Atómicas.
A partir de la versión 4.0, MySQL provee soporte para transacciones, esto es solo posible
en el motor tipo InnoDB y BDB.
Replicación.
MySQL incorpora un sistema de replicación en la que están involucrados al menos dos
servidores: uno en un modo maestro y el otro en modo esclavo. Esta opción de clusters
permite mantener trabajando el servidor de base datos si uno o varios de ellos fallan. La
arquitectura de replicación de MySQL permite a cada servidor contar con su propia
memoria y disco duro así, las tablas almacenadas en los nodos de almacenamiento son
accesibles directamente desde cualquier otro servidor MySQL en el cluster.
MySQL es un sistema confiable, abierto y con un aspecto de simplicidad que lo hacen una
opción en la elección de un sistema manejador de base de datos. MySQL incorpora
menos funcionalidad con respecto a sus competidores directos como el caso PostgreSQL
aunque en general MySQL sigue manteniendo características de velocidad y flexibilidad.
Resumen de características generales.
Oracle, MSSQL, PostgreSQL y MySQL representan los cuatro sistemas manejadores de
bases de datos más utilizados y prominentes en el mercado de las bases de datos. Oracle
y MSSQL son sistemas comerciales mientras que PostgreSQL y MySQL son sistemas de
código abierto.
48
Oracle es el primer sistema relacional manejador de base de datos en el mercado, y su
complejidad y cantidad de características van en relación directa con el precio, es el
sistema más caro dentro de esto cuatro en cuestión.
Por el otro lado MSSQL es un sistema potente que ofrece una alternativa accesible en
cuanto a costo en relación a Oracle, aunque sigue siendo cara desde el punto de vista de
un desarrollador personal. MSSQL puede ser visto como un sistema más simple y con
una interfaz de usuario más amigable en comparación de Oracle; se puede decir que
cuenta con gran parte de las características que ofrece Oracle pero limitado a una sola
plataforma: Windows.
Oracle y MSSQL son ambos aptos para una administración de base de datos a de nivel
personal y empresarial, aunque sus costos y características individuales pueden llegar a
ser más apropiadas para corporaciones y/o departamentos.
En contra parte a estos sistemas comerciales encontramos dos opciones en el mercado
de código abierto: MySQL y PostgreSQL los cuales pueden ser usados sin costo alguno.
Mientras que ambos pueden ser usados a nivel personal o comercial, las aplicaciones de
código abierto son normalmente implementadas en soluciones “stand-alone” o
comerciales de baja demanda.
PostgreSQL se proclamo a sí mismo como el “sistema relacional manejador de base de
datos de código abierto más avanzado”, mientras que MySQL es el sistema de código
abierto más popular en este mercado. Estos dos sistemas han dejado ver que son una
opción viable en contraparte a los sistemas comerciales que existen en el mercado
aunque es evidente también que aun no pueden cubrir totalmente la complejidad relativa
de las opciones comerciales que se ofrecen en el mercado como es el caso de Oracle y
MSSQL (Kimpo, Lucero et al. 2004).
49
Tabla comparativa de características generales (Kimpo, Lucero et al. 2004)
Figura 2 Tabla Características
50
EL ESTÁNDAR SQL:2003
El lenguaje SQL está presente en la mayoría de los SMBD y se ha convertido en el
lenguaje “defacto”, ante esta situación el lenguaje ha sido objeto de un intenso proceso de
estandarización que ha resultado en varias versiones del mismo. El estándar al que nos
referiremos en este trabajo es SQL:2003, este se encuentra descrito en el estándar
ISO/IEC 9075, en el apartado Tecnología de Información-Lenguajes de base de datos
(Baroni, Calero et al. 2006).
El ISO/IEC 9075 define el lenguaje SQL. El alcance del lenguaje SQL es la definición de
las estructuras y operaciones sobre la estructura de almacenamiento de datos (ISO/IEC
2008).
El estándar SQL:2003 está compuesto de nueve partes. La numeración de las partes no
es continua debido a razones históricas. Algunas partes han desaparecido (ejemplo: parte
5 de SQL:1999 SQL/Bindings está incluida en la parte 2 del estándar SQL:2003) y
algunas otras son nuevas. Las partes del nuevo estándar son el resultado de una mayor
división o del resultado de la implementación de nuevos requerimientos, como son las
partes 13 y 14 que hablan de algunos métodos JAVA o el manejo de datos XML (Calero,
Ruiz et al. 2005). Las partes 1,2 y 11 enmarcan los requerimientos mínimos del lenguaje.
El resto de las partes definen extensiones del mismo.
El estándar define también las formas en las que el lenguaje SQL puede ser usado en
conjunto con XML. Define las formas de importar y almacenar datos XML en base de
datos basadas en SQL.
A continuación presentamos la estructura general del estándar (Calero, Ruiz et al. 2005):
Parte Nombre Descripción
1 “Framework” Es un resumen general del estándar. Describe el marco conceptual usado en otras partes para especificar la gramática del SQL y el resultado de el procesamiento de sentencias en el lenguaje que implemente SQL. También define los términos y notaciones utilizadas en el resto de las partes.
2 “Foundation” Esta parte define la estructura de datos y las operaciones básica sobre datos SQL. Provee las características funcionales para crear, acceder, mantener, controlar y proteger datos SQL. Esta parte también especifica la sintaxis y semántica del lenguaje SQL. Trata aspectos de la portabilidad de la definición de datos y compilación entre implementaciones de SQL y la interconexión de las implementaciones.
3 “Call-Level Interface” (SQL/CLI)
Define las estructuras y procedimientos que pueden ser usado para ejecutar sentencias SQL en ó desde aplicaciones que utilicen lenguajes de programación estándar.
4 “Persistent Stored Esta parte especifica la sintaxis y semántica del lenguaje
51
Parte Nombre Descripción
Modules” (SQL/PSM)
para declarar y mantener rutinas del lenguaje persistentes en módulos de servidor SQL.
9 “Management of External Data” (SQL/MED)
En esta parte se definen extensiones al lenguaje de base de datos SQL para soportar la administración de datos externos.
10 “Object Language” Define extensiones para soportar sentencias SQL incrustadas en programas desarrollados en Java comúnmente conocidos como “SQLJ”. Esta parte especifica la sintaxis y semántica de los “SQLJ” así como los mecanismos para asegurar la portabilidad binaria resultado de aplicaciones “SQLJ”. Adicionalmente especifica un número de paquetes y clases del lenguaje Java.
11 “Information and Definition Schema” (SQL/Schemata”
Esta parte define un esquema de información y un esquema de definición que describe el identificador de objeto SQL, la estructura y las restricciones de integridad de los datos SQL, la especificación de la seguridad y autorización relacionada a los datos SQL, las características y sub-características y paquetes de este estándar, y el soporte que cado uno tiene en la implementación de SQL. También incluye información de implementación y dimensionamiento de objetos.
13 “Routines and Types Using the Java Programming Language” (SQL/JRT)
Esta parte especifica las facilidades de invocar métodos estáticos escritos en lenguaje Java como rutinas que invocan SQL y el uso de clases definidas en Java como tipos de datos definidos por el usuario.
14 “XML-Related Specifications” (SQL/XML)
Esta parte contiene todos los aspectos relacionados a la implementación de XML dentro del lenguaje SQL.
Tabla 2 Estructura del Estándar SQL
El estándar SQL:2003 hace una revisión de todas las partes de su antecesor SQL:1999 y
agrega una parte más, la parte 14 relacionada a los aspectos de SQL/XML.
Adicionalmente se hizo una reorganización de las partes heredadas de su antecesor. Una
porción de la parte 2 de su antecesor, SQL/Foundation, que trata el Information Schema y
el Definition Schema fue separado y se creó una parte exclusiva: la parte 11
SQL/Schemata in SQL:2003 (Eisenberg, Kulkarni et al. 2004).
La parte 5 de SQL:1999 SQL/Bindings ha sido eliminada en SQL:2003 y su contenido fue
movido a la parte 2 de SQL:2003, SQL/Foundation.
Algunas de las nuevas características del estándar SQL:2003 en relación con su
antecesor podemos encontrar:
Nuevos tipos de datos.
52
Mejoramiento en la invocación de rutinas SQL.
Extensiones a la declaración CREATE TABLE.
Una nueva declaración: MERGE.
Un nuevo objeto esquema.
Dos nuevas ordenaciones de columnas, columnas de identidad y columnas
generadas.
Nuevos tipos de datos.
SQL:2003 conserva todos los datos existentes en la versión anterior con la excepción de
BIT y BIT VARYING que fueron removidos del estándar debido a la falta de soporte en los
sistemas manejadores actuales. El estándar SQL:2003 introduce tres nuevos tipos de
datos: BIGINT, MULTISET y XML.
Los nuevos tipos de datos son consideraros de primera clase, ya que pueden ser usados
en todos los contextos de los ya existentes: tipos de atributos, parámetros y tipos de
retorno de funciones.
El nuevo tipo de dato BIGINT es similar al SMALLINT y al tipo INT pero implementa una
mayor precisión, la mayoría de las implementaciones utilizan actualmente valores de 64
bits pero se puede especificar otra precisión. Este tipo soporta las mismas operaciones
que los otros tipos de entero como es la suma, resta, valor absoluto, modulo, etc.
El tipo MULTISET es un tipo de colección similar al ya existente ARRAY, pero sin que
exista un orden implícito en sus elementos; es una colección de elementos sin ordenación
alguna, todos del mismo tipo y con la posibilidad de contener elementos duplicados.
El tipo del elemento puede ser cualquiera de los ya existentes soportados por SQL, por
ejemplo INTEGER MULTISET define que los elementos del MULTISET son del tipo
INTEGER. El tipo MULTISET no requiere de la especificación de un número máximo de
elementos, sin embargo si existe un número máximo.
El tipo de dato MULTISET soporta operaciones para moldear un conjunto de datos
(multiset) dentro un arreglo u otro multiset con un tipo de elemento compatible, para
remover duplicados del multiset, para regresar el número de elementos de un multiset y
para retornar el único elemento de un multiset que contiene un solo elemento.
Adicionalmente, la unión, intersección y la diferencia de dos multiset están soportadas y
contiene además tres nuevas funciones: COLLECT, FUSION, INTERSECTION.
Funciones de tabla
53
Las funciones de tabla son un elemento nuevo en SQL:2003. Una función de tabla es una
invocación SQL que retorna una tabla, la especificación indica que el tipo de retorno es
equivalente al tipo MULTISET el cual puede ser consultado (“queried”) como cualquier
tabla. Esta es una función no mandatoria dentro del estándar.
Extensiones CREATE TABLE.
Una de las declaraciones más importantes en el lenguaje de definición de datos (DDL) es
CREATE TABLE ya que permite al usuario definir el elemento de almacenamiento de sus
datos. De manera simplificada una tabla consiste de columnas con un nombre, un tipo de
dato asociado, las restricciones asociadas a la tabla sobre llaves primarias y foráneas y
los valores por defecto que tienen dichas columnas en los casos que no se especifique el
valor.
En SQL:2003 existen dos nuevas posibilidades para declarar una columna: la primera
como una columna identidad (identity) y la segunda como una columna generada, en
ambos casos el valor es generado en cada inserción; otra característica nueva es la
posibilidad de crear nuevas a tablas a partir de la estructura de las ya existentes a través
de la declaración CREATE TABLE LIKE, existe una variante de esta comando que
permite crear la nueva tabla solo con una parte de la estructura de la tabla original
mediante la declaración CREATE TABLE AS.
Declaración MERGE.
Anterior a SQL:2003 el lenguaje SQL incluía tres declaraciones para actualizar las tablas
o vistas de una base de datos: INSERT, UPDATE y DELETE, en la nueva versión se
agregó una cuarta declaración: MERGE.
Esta nueva declaración permite transferir un conjunto de tuplas o renglones de una tabla
hacia otra; normalmente este proceso se realiza en dos pasos, el primero consiste en
hacer un UPDATE de los renglones de la tabla destino, y un segundo paso consiste en
realizar un INSERT de aquellos renglones que no existen en la tabla destino, la
instrucción MERGE permite combinar estos dos pasos en uno solo haciendo más
eficiente este tipo de operaciones.
Generadores de secuencia.
Un generador de secuencia es un nuevo tipo de objeto de base de datos con un valor
numérico asociado.
Un generador de secuencia se realiza mediante la ejecución de una declaración CREATE
SEQUENCE, en esta declaración es posible definir el valor inicial, el valor mínimo,
máximo y el incremento.
El generador de secuencia contiene un valor base asociado al tiempo y un ciclo que
consiste en todos los valores posibles entre el valor mínimo y máximo. SQL:2003 incluye
54
una función que permite obtener el siguiente valor de la secuencia a través de la
instrucción NEXT VALUE FOR, el cual al ser ejecutada regresa el valor siguiente y
modifica el valor base de la función.
SQL:2003 también incluye declaraciones para modificar los generadores de secuencias
como ALTER SEQUENCE y RESTART WITH.
Columnas Identidad.
A pesar que los generadores de secuencia proveen un mecanismo para genera valores
únicos para columnas, es necesario la invocación de la función NEXT VALUE FOR cada
que se requiera acceder al siguiente valor, esto es una tarea que se tiene que realizar de
manera repetitiva lo cual no es lo más eficiente, ante esta situación SQL:2003 provee una
nueva característica que propone un mejor mecanismo para la generación de valores
únicos para la identificación de columnas, esta nueva función es IDENTITY COLUMNS.
Columnas identidad son columnas declaradas con la palabra reservada IDENTITY. Este
calificador hereda los mismos atributos de los generadores de secuencia como el valor
inicial, el incremento, el valor mínimo y máximo.
Cuando se establece este calificador de la columna ya no es necesario establecer un
valor para la columna identidad al momento de realizar un INSERT a la tabla, éste se
generara de manera automática y será insertado en la posición de dicha columna, es
importante destacar que solo puede existir una columna identidad en una tabla.
Columnas generadas.
Las columnas generadas están asociadas a una expresión escalar y su valor es
calculado en cada inserción o actualización basada en dicha expresión. Las expresiones
pueden contener valores de otras columnas dentro de la misma tabla que contiene la
columna generada y una columna generada no puede referenciar otra columna generada.
55
CUMPLIMIENTO DE LOS SMBD AL ESTÁNDAR SQL:2003
El nivel de cumplimiento que un sistema manejador de base de datos da al estándar de
SQL puede ser muy variable; esta situación es debido a que la implementación que
ejecuta cada sistema manejador es muy compleja, ya que atiende a diferentes factores
como la arquitectura del propio manejador, los aspectos de rendimiento, lineamientos u
objetivos generales que tiene cada sistema y también debido a aspectos diferenciales que
cada sistema guarda con respecto al mercado.
Existen numerosos documentos que indican el nivel de cumplimiento que dan los
sistemas manejadores al estándar, sin embargo las características que evalúan difieren
de un sistema a otro; algunas publicaciones con este tipo de información provienen
directamente del fabricante y por ende no muestran información en contraste con el resto
de los sistemas.
Como ya se mencionó anteriormente, muchas ocasiones éste cumplimiento se refiere a
satisfacer las características que establece el estándar, mas no así a que estas
características sean compatibles de un sistema manejador a otro que implementan el
estándar.
A continuación se enlistaran algunas características que establece el estándar y se
mencionará si su definición dentro del lenguaje SQL es estándar y compatible con el resto
de los sistemas manejadores en cuestión.
El estándar consta de nueve partes en las cuales están definidas todas las reglas y
características que sigue el estándar, por ende el número de características y reglas es
muy amplio. Para efecto de este trabajo, nos concentraremos en la parte de “Foundation”
donde están definidas las estructuras e instrucciones básicas del lenguaje SQL.
Dentro del aparatado “Foundation” estan definidos tres sublenguajes de SQL: el lenguaje
de definición de datos (DDL), el lenguaje de manipulación de datos (DML) y el lenguaje de
control de datos (DCL). Este trabajo se concentra en las dos partes principales: el “DDL”
y el “DML”.
Como primer lugar se mostrara un conjunto de características que serán evaluadas en
cada sistema manejador y se indicara el cumplimiento al estándar; estas características
están agrupadas en instrucciones de definición de datos y manipulación de datos. Dentro
del lenguaje de definición de datos existe una parte importante que refiere a la definición
de los tipos de datos que soportan las relaciones como atributos. Se incluirá un listado
con los tipos de datos estándar.
En la segunda parte se incluirán algunas consideraciones importantes de cada sistema
manejador en función al proceso de estandarización y nivel de cumplimiento al mismo.
Características DDL y DML
56
Las instrucciones o características evaluadas son las siguientes.
Creación de esquemas “CREATE SCHEMA”.
Creación de tablas “CRATE TABLE”
Creación de vistas “CREATE VIEW”.
Proyección “SELECT”
Selección “WHERE”
Ordenación “ORDER BY”
Primeros registros “LIMIT”.
Inserción “INSERT INTO”
Actualización “UPDATE “
Eliminación “DELETE”
Reuniones “JOIN”
ORACLE
Característica Cumplimiento
CREATE SCHEMA Da cumplimiento completo al estándar.
CREATE TABLE Da cumplimiento completo al estándar.
CREATE VIEW Da cumplimiento completo al estándar.
SELECT Da cumplimiento completo al estándar.
WHERE Da cumplimiento completo al estándar.
ORDER BY Da cumplimiento completo al estándar. Los valores con marca de
nulos son ordenados antes que los valores “no nulos”. Este
comportamiento puede ser alterado con el uso del modificador
“NULLS FIRST, NULLS LAST” que indica el estándar.
LIMIT Da cumplimiento parcial al estándar. Soporta la función
“ROW_NUMBER” del estándar y no así la instrucción “FETCH
FIRST”
INSERT INTO Da cumplimiento completo al estándar.
UPDATE Da cumplimiento completo al estándar.
DELETE Da cumplimiento completo al estándar.
JOIN Da cumplimiento completo al estándar.
Tabla 3 Características de Oracle
57
SQL SERVER
Característica Cumplimiento
CREATE SCHEMA Da cumplimiento completo al estándar.
CREATE TABLE Da cumplimiento completo al estándar.
CREATE VIEW Da cumplimiento completo al estándar.
SELECT Da cumplimiento completo al estándar.
WHERE Da cumplimiento completo al estándar.
ORDER BY No da cumplimiento al estándar. Los valores con marca de nulos
son ordenados después de los valores “no nulos”. No incluye los
modificadores “NULLS FIRST, NULLS LAST” que indica el
estándar.
LIMIT Da cumplimiento parcial al estándar. Soporta la función
“ROW_NUMBER” del estándar y no así la instrucción “FETCH
FIRST”
INSERT INTO Da cumplimiento completo al estándar.
UPDATE Da cumplimiento completo al estándar.
DELETE Da cumplimiento completo al estándar.
JOIN Da cumplimiento parcial al estándar, no soporta las reuniones
naturales y la inclusión del modificador “USING”
Tabla 4 Características de SQL Server
POSTGRESQL
Característica Cumplimiento
CREATE SCHEMA Da cumplimiento completo al estándar.
CREATE TABLE Da cumplimiento completo al estándar.
CREATE VIEW Da cumplimiento parcial al estándar. No permite la actualización
de vistas.
SELECT Da cumplimiento completo al estándar.
58
Característica Cumplimiento
WHERE Da cumplimiento completo al estándar.
ORDER BY Da cumplimiento completo al estándar. Los valores con marca de
nulos son ordenados antes que los valores “no nulos”. Este
comportamiento puede ser alterado con el uso del modificador
“NULLS FIRST, NULLS LAST” que indica el estándar.
LIMIT Da cumplimiento completo al estándar.
INSERT INTO Da cumplimiento completo al estándar.
UPDATE Da cumplimiento completo al estándar.
DELETE Da cumplimiento completo al estándar.
JOIN Da cumplimiento completo al estándar.
Tabla 5 Características de POSTGRESQL
MYSQL
Característica Cumplimiento
CREATE SCHEMA Da cumplimiento completo al estándar.
CREATE TABLE Da cumplimiento completo al estándar.
CREATE VIEW Da cumplimiento completo al estándar.
SELECT Da cumplimiento completo al estándar.
WHERE Da cumplimiento completo al estándar.
ORDER BY No da cumplimiento al estándar. Los valores con marca de nulos
son ordenados después de los valores “no nulos”. No incluye los
modificadores “NULLS FIRST, NULLS LAST” que indica el
estándar.
LIMIT No da cumplimiento total al estándar.
INSERT INTO Da cumplimiento completo al estándar.
UPDATE Da cumplimiento completo al estándar.
DELETE Da cumplimiento completo al estándar.
JOIN Da cumplimiento parcial al estándar. No permite reuniones
59
Característica Cumplimiento
completas “FULL JOIN”
Tabla 6 Características de MYSQL
Tabla resumen.
Característica ORACLE SQLSERVER POSTGRESQL MYSQL
CREATE
SCHEMA
CREATE TABLE
CREATE VIEW
SELECT
WHERE
ORDER BY
LIMIT PARCIAL PARCIAL
INSERT INTO
UPDATE
DELETE
JOIN PARCIAL PARCIAL
Tabla 7 Tabla Resumen de características
Tipos de datos
Los tipos de datos que soporta cada manejador son un factor importante en aspectos de
migración y compatibilidad entre diferentes sistemas manejadores. El estándar define
varios tipos de datos agrupados en cuatro partes principales: tipos numéricos, de cadena
de caracteres, de fecha y tiempo y datos binarios como cadenas grandes de caracteres.
Podemos decir que todos los tipos de datos establecidos en el estándar son soportados
por los sistemas manejadores de acuerdo a la especificación del valor de dato que
almacena. Sin embargo en algunos casos el nombre del tipo de dato difiere de un sistema
a otro y eso no permite una compatibilidad sin cambio; en otros casos el tipo es soportado
aunque los rangos y el espacio de memoria asignado son diferentes. En el apartado de
experimentación se estudiaran estos casos.
60
A continuación se muestra una tabla comparativa con los tipos de datos que soporta cada
manejador en su aspecto general.
ORACLE SQLSERVER POSTGRESQL MYSQL
CHARACTER
CHARACTER
VARYING
CHARACTER
LARGE
OBJECT
BINARY
LARGE
OBJECT
NUMERIC
DECIMAL
SMALLINT
INTEGER
BIGINT
FLOAT
REAL
DOUBLE
PRECISION
BOOLEAN
DATE
TIME
TIMESTAMP
Tabla 8 Tipos de datos
Como podemos ver existen algunos tipos de datos que no son compatibles, esta
incompatibilidad es debida a que el sistema no reconoce la palabra, es decir, se trata de
un error léxico; sin embargo el manejador ofrece un tipo de dato para almacenar dicho
61
valor. Para algunos de estos casos existen ciertas alternativas que pueden definir un tipo
de datos que almacenen ese tipo de valor bajo otro tipo de dato diferente al que establece
el estándar.
Otros aspectos de cumplimiento al estándar SQL:2003
Aspectos generales sobre el cumplimiento de ORACLE al estándar SQL:2003.
El estándar de SQL ha sido uno de los más populares en el área de computo (Lee 2003).
Aunque el volumen de características y especificaciones alrededor del estándar ha
crecido y se ha vuelto más compleja y sofisticada, SQL ha evolucionado para cubrir de
manera completa las demandas de crecimiento alrededor de este lenguaje.
SQL:2003 incluye grandes mejoras en un gran número de áreas clave del estándar. En
primer lugar encontramos las características de programación orientada a objetos en el
modelo relaciones. En segundo lugar SQL:2003 incluye y revoluciona una serie de
características y funciones de OLAP. En tercer lugar encontramos que SQL:2003 ha
integrado una parte muy amplia e importante para el manejo e integración de XML con
SQL, esto en la parte 14 del estándar (XML-Related Specifications SQL/XML).
Oracle, como el primer sistema comercial que implementó SQL hace 25 años, continúa
como líder en la industria de las bases de datos en la implementación del estándar de
SQL. De hecho, muchas de las características que incluye SQL:2003 ya estaban
presentes en la versión 8i (Multisets, funciones OLAP, etc). En la versión 9i se incluyeron
funciones adicionales de OLAP, funciones de tabla (table functions), tipos de datos de
colecciones (nested collections types), datos estructurados tipo “Final”. La versión 10g
soporta nuevas características adicionales de SQL:2003, como el manejo avanzado de
“Multisets” así como muchas otras características que van más allá del estándar como el
manejo de expresiones regulares y funciones estadísticas.
Oracle es compatible o cumple con el estándar SQL:2003 en las tres nuevas categorías
clave del estándar:
Esquema Objeto-Relacional (Object-Relational).
Inteligencia de Negocios (Business Intelligence).
SQL/XML.
Características Objeto-Relacional
El incremento en aplicaciones más complejas de eCommerce y eBusiness, ha hecho que
se adopte cada vez más el esquema de programación orientado a objetos para simplificar
62
y manejar dicha complejidad. Para tal efecto se han tomado lenguajes de programación
orientados a objetos como el caso de Java o C++.
El modelo tradicional relacional estaba lejos de cubrir estas necesidades desde el punto
de vista de orientación a objetos, esto ha marcado el crecimiento de nuevas necesidades.
Desde la versión del estándar SQL:1999 se introdujeron características que seguían en
alguna medida el paradigma orientado a objetos y lo cual permita simplificar las tareas de
almacenar y recuperar estructuras complejas y estructuradas de objetos. Oracle soporta
estas nuevas características desde su versión Oracle 8/8i. SQL:2003 realizó mejoras en
esta área definiendo estas nuevas características:
Soporte para tipos de datos “Multiset”.
El nuevo tipo de datos “Multiset” es un tipo de datos que almacena colecciones
desordenadas. Desde la versión 8, estas características son soportadas e incluye
operaciones para el soporte de este tipo de datos.
Soporte Avanzado para tipos “Multiset”.
SQL:2003 define soporte avanzado para tipos de datos Multiset con operadores de
comparación (Comparison) y asignación (Set) como uniones e intersecciones (UNION,
INTERSECTION). Estas características están soportadas desde la versión 10g.
Tipos de colección agrupadas (Nested Collection Types).
SQL:2003 soporta dos tipos de colecciones, el “Array” y el “Multiset” adicionalmente al tipo
de datos “Nested Table”, Oracle soporta el tipo “Array” y “Varray” desde la versión 8. Las
colecciones agrupadas de “Array” y “Varray” son soportadas a partir de la versión 9i.
Tipos estructurados “Final”.
Un tipo de datos definido por el usuario puede ser creado con el modificador “Final” o “Not
Final” para indicar cuando un subtipo de datos puede heredar de éste. Oracle soporta
estas características desde la versión 9i.
Características de inteligencia artificial.
La proliferación de la información y el tamaño de las bases de datos siguen creciendo, las
empresas desean obtener información que se encuentra oculta es esas bases de datos.
Herramientas como Datawarehousing, OLAP, Minería de Datos se han convertido
esenciales para las organizaciones para extraer y ejecutar inteligencia de negocios que
apoyen a la toma de decisiones.
En el pasado, todas las funciones de OLAP “On-Line Analytical Processing” eran
ejecutadas fuera de la base de datos, en un servidor OLAP separado y que utilizaban
aplicaciones no basadas en estándares. Esto hizo aparente que uno de los impedimentos
que tenían las aplicaciones OLAP era el mover grandes cantidades de información desde
el servidor de base de datos hasta el servidor OLAP. Una solución simple a este problema
63
es el procesar las funciones OLAP dentro de la misma base de datos utilizando las
funciones estándar de SQL.
Para este efecto, ANSI publico en el año 2000 una adición al estándar SQL:1999 donde
definía una extensa lista de funciones OLAP las cuales ahora forman parte del estándar
SQL:2003. Oracle fue uno de los principales colaboradores en la definición de estas
funciones OLAP dentro del estándar. Estas características son soportadas desde la
verstion 9i de Oracle. El estándar incluye también una serie de funciones orientadas a
tareas de minería de datos dentro de las que podemos mencionar:
Window Functions: SQL:2003 define funciones de cálculo como ROW_NUMBER, RANK,
DENSE_RANK, PERCENT_RANK, CUME_DIS, también icluye funciones agregadas
como INVERSE DISTRIBUTION, HYPOTHETICAL SET, entre otras.
Clausulas NULL FIRST, NULL LAST en operaciones de ordenación como ORDER BY.
Esta clausula permite establecer el orden de la secuencia de las marcas de nulo (NULL).
Funciones de tabla. Una función de tabla está definida como una función que produce un
conjunto de renglones como salida. Estas funciones son soportadas desde la versión 9i y
proveen soporte para la ejecución de transformaciones implementadas en PL/SQL o Java.
Inverse Percentile Family
Una pregunta de análisis frecuente es encontrar el valor dentro de un conjunto de datos
que corresponde a un por ciento específico. Oracle incluye dos funciones para obtener
estos valores: PERCENTILE_CONT y PERCENTILE_DISC. Estas funciones pueden ser
utilizadas como ya sea como funciones de agregación o como funciones de reporte de
agregación. Cuando son usadas como funciones de agregación retornan un valor simple
por cada conjunto ordenado de datos, y cuando son usadas como funciones de reportes,
éstas repiten el valor sobre cada renglón devuelto. PERCENTILE_DISC retorna el valor
actual “discreto” el cual es el más cercano al valor porcentual especificado, mientras que
la función PERCENTILE_CONT calcula el valor porcentual “continuo” utilizando una
interpolación linear. Estas funciones utilizan una nueva clausula para especificar el orden:
WITHIN GROUP.
Hypothetical Rank y Distribution Family.
Este tipo de funciones permiten conocer la forma en se comportaría un nuevo valor si
fuese agregado a nuestro conjunto de datos existente. Estas funciones retornan la
posición (Rank) o el valor porcentil el cual sería asignado si un nuevo renglón fuera
insertado en el conjunto de datos.
Las funciones hipotéticas pueden calcular RANK, RANK_DENSE, PERCENT_RANK y
CUME_DIST.
Características de XML.
64
El volumen de datos que es representado actualmente en formato XML ha crecido
considerablemente, de aquí que ha surgido la necesidad de poder almacenar este tipo de
datos en los manejadores de base de datos. Con las nuevas características de SQL/XML
se pueden tener todos los beneficios de un sistema relacional además de los beneficios
de XML en un mismo sistema. La parte 14 del estándar SQL:2003 define la forma en que
SQL puede ser utilizado en conjunto con XML dentro de una misma base de datos. Esta
parte define detalladamente el nuevo tipo de dato: XML, los valores de un tipo XML, el
mapeo entre las construcciones SQL y las construcciones XML y las funciones para
generar XML desde datos SQL. Estas funciones están soportadas desde la versión 91
Release 2 de Oracle como parte integral de XML-DB.
XML-DB incluye además un conjunto de extensiones de SQL para realizar consultas,
modificaciones y transformación de este tipo de datos. Oracle trabaja muy cerca del
comité de estandarización para estandarizar estas extensiones.
Aspectos generales sobre el cumplimiento de SQL SERVER al estándar SQL:2003.
SQL SERVER da cumplimiento completo al primer nivel (entry-leve) del estándar SQL y
un cumplimiento parcial a niveles superiores (Turley 2005).
Inserción simultanea de registros.
El estándar permite hacer la inserción de varios registros a la vez sin la necesidad de
especificar la palabra VALUES en cada registro. SQL Server no soporta dicha función.
Columnas únicas (UNIQUE)
SQL Server sigue el estándar y permite la identificación de columnas únicas.
Llaves autogeneradas (Automatic key generation)
SQL Server soporta dicha característica pero con una diferencia sintáctica; SQL Server
adiciona el atributo IDENTITY que es aplicado a una columna y permite que su valor sea
auto-generado siguiendo una secuencia.
Eliminación de registros (TRUNCATE)
SQL Server sigue el estándar y permite eliminar todos los registros de una tabla dada. Su
ejecución es permitida con otras operaciones.
65
Listas de base de datos
El estándar no especifica una función para obtener un listado de las bases de datos
alojadas en el manejador, sin embargo, esta lista se encuentra almacenada dentro de una
tabla del propio manejador; su acceso es mediante una proyección sobre cierto atributo
de dicha tabla. SQL Server permite el listado de las bases de datos a través de la claúsula
EXEC SP_HELPDB.
Listas de esquemas
Al igual que las bases de datos, los esquemas están almacenados en una tabla del
sistema, el estándar permite obtener una lista de dichos esquemas a través de una
consulta a dicha tabla. SQL Server sigue el estándar:
SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA.
Listado de tablas
La parte 11 del estándar de SQL especifica el esquema INFORMATION_SCHEMA el cual
forma parte de los catálogos de cualquier base de datos.
SQL Server sigue el estándar mediante la ejecución de esta sentencia: SELECT * FROM
INFORMATION_SCHEMA.TABLES
Versión del sistema
El estándar permite conocer la versión del sistema manejador mediante la ejecución de la
sentencia:
SELECT CHARACTER_VALUE
FROM INFORMATION_SCHEMA.SQL_IMPLEMENTATION_INFO
WHERE IMPLEMENTATION_INFO_NAME='DBMS
SQL Server no implementa IMPLEMENTATION_SCHEMA_INFO y por tanto no sigue el
estándar. SQL Server implementa una función propietaria: SELECT @@VERSION
Aspectos generales sobre el cumplimiento de POSTGRESQL al estándar SQL:2003
66
PostgreSQL hace un cumplimiento parcial al estándar SQL:2003 (ISO/IEC 9075
“Database Language SQL”). El proyecto PostgreSQL clama por cumplir el estándar con
la última versión oficial del estándar donde dicho estándar no contradiga las funciones
tradicionales o el sentido común del proyecto. El proyecto PostgreSQL no está
representado en el grupo de trabajo del ISO/IEC 9075 en la preparación de la versión
pero a pesar de esto muchas de las funciones requeridas por el estándar están
soportadas (PostgreSQL 2008).
El estándar SQL-92 definió tres conjuntos de características para el cumplimiento:
entrada, intermedio y completo. PostgreSQL cumplió solo el nivel de entrada a raíz que
los dos niveles superiores eran demasiado voluminosos y entraban en conflicto con el
comportamiento nativo del mismo.
Iniciando con SQL:1999, el estándar definió un conjunto más largo de características
individuales a diferencia de tres conjuntos como el SQL:92. Un conjunto más largo de
estas características representan la base “Core”, donde cada implementación al
cumplimiento de SQL debe satisfacer. El resto de las características son netamente
opcionales.
PostgreSQL cubre las partes 1,2,11 y 14. La parte 3 es similar a la interface ODBC, y la
parte 4 es similar al lenguaje de programación PL/pgSQL.
PostgreSQL soporta la mayoría de características más significativas del estándar
SQL:2003. Fuera de las 164 características obligadas que dictan el cumplimiento base del
estándar, PostgreSQL cumple al menos 150. Es importante notar que al momento de
esta escritura, ningún manejador de base de datos actual cumple con la base del estándar
SQL:2003 al 100% (PostgreSQL 2008).
Aspectos generales sobre el cumplimiento de MYSQL al estándar SQL:2003
MySQL cumple con configuraciones establecidas que pueden cambiar de acuerdo a las
opciones incrementando el nivel en que se apliquen.
Inserciones simultáneas.
El estándar de MySQL soporta la inserción de varias líneas de datos al mismo tiempo
haciendo uso de las clausulas INSERT INTO…. VALUES
Concatenación.
El estándar de MySQL soporta la función CONCAT para la unión de registros.
Restricciones
67
Columnas únicas (unique)
MySQL en su estándar permite la combinación de datos únicos (solamente en valores)
proporcionando un valor NOT NULL.
Generación Automática de Llave (automática key generation)
El estándar de MySQL no soporta esta característica y como alternativa asigna un
atributo condicionando el atributo a través de AUTO_INCREMENT asignado a un valor.
Asegurando la inserción con variantes como ALWAYS Y BY DEFAULT.
Eliminación de datos (trúncate table)
El uso del comando TRUNCATE en MySQL no sigue generalmente el estándar y en
alguno de los casos es el equivalente a un DELETE dependiendo del manejador de la
base de datos.
Listas de bases de datos.
MySQL a través del comando SHOW DATABASES muestra la lista de las bases de datos
almacenados en nuestro manejador.
Lista de esquemas.
El estándar de MySQL no soporta el comando SCHEMA_NAME.
Lista de tablas.
El estándar de MySQL no soporta el comando SCHEMA.TABLES, sin embargo con el uso
del comando SHOW TABLES podemos obtener la lista de las tablas que componen
nuestra base de datos.
Descripción de Tablas.
El estándar de MySQL no soporta SCHEMA.TABLE sin embargo usando el comando
TABLE_NAME podemos obtener los datos solicitados.
68
69
EXPERIMENTACIÓN
Los experimentos propuestos en este trabajo tiene como objetivo medir el nivel de
compatibilidad de instrucciones SQL en cuatro sistemas manejadores de base de datos:
ORACLE, SQLSERVER, POSTGRESQL y MYSQL.
Las instrucciones SQL que se ejecutarán están definidas en el apartado de Lenguaje de
Definición de Datos (DDL) y en la parte del Lenguaje de Manipulación de Datos (DML), la
definición de estos sublenguajes está definida en la parte dos del estándar SQL:2003
marcada como “Foundation”.
Para el caso del Lenguaje de Definición de Datos la experimentación se centra en
instrucciones de creación y eliminación de esquemas y relaciones bajo las siguientes
instrucciones SQL:
CREATE SCHEMA
DROP SCHEMA
CREATE TABLE
DROP TABLE
En la creación y definición de relaciones (tablas) se evaluó también la compatibilidad de
los tipos de datos y la definición de llaves primarias y foráneas de una relación.
Para el caso del Lenguaje de Manipulación de Datos se incluyeron las siguientes
instrucciones SQL:
SELECT
INSERT INTO
UPDATE
DELETE
WHERE
ORDER BY
Las pruebas se ejecutaron en las versiones más recientes disponibles con el fabricante al
momento de la ejecución de estas pruebas. Las versiones fueron:
Sistema Versión
70
Sistema Versión
ORACLE 10g
SQLSERVER 2008
POSTGRESQL 8.3
MYSQL 5.1
Tabla 9 Versiones SMBD en la experimentación
Los sistemas manejadores se instalaron bajo las siguientes plataformas de software y
hardware:
SMBD Sistema Operativo Hardware
ORACLE UNIX-AIX HP ITANIUM
SQLSERVER Windows Server 2003 SP2
XENON 2.0 GHZ, 1GB
RAM, DISCO DURO 120
GB.
POSTGRESQL Windows Vista Home
Edition
Core 2 DUO 2.66 GHZ,
4 GB RAM, DISCO DURO
500 GB.
MYSQL Windows Vista Home
Edition
Core 2 DUO 2.66 GHZ,
4 GB RAM, DISCO DURO
500 GB.
Tabla 10 Plataforma de experimentación
El estándar establece una estructura lógica sobre la cual se organizan los objetos de la
base de datos; el estándar establece los siguientes tipos de objetos:
Catálogo (CATALOG).
Esquema (SCHEMA)
Tablas (TABLE).
Índices (INDEX).
Vistas (VIEW).
71
Catálogos (Catalogs)
El estándar define un catalogo como un conjunto de esquemas, descriptores y datos
dentro de un ambiente SQL (ISO/IEC 2008). El objeto catalogo presume la más alta
precedencia, sobre esta se crean el resto de los objetos, el estándar establece que la
creación de este objeto se deja abierto a la implementación del sistema manejador, no
existe una instrucción SQL del estándar para crearla. Esta objeto, solo existe en el
sistema PostgreSQL y permite guardar la estructura y metadatos de la base de datos, en
el resto de los sistemas no existe, en su lugar existe un objeto que puede representar el
objeto de mayor precedencia especificado por el estándar, este es el caso del objeto
denominado “Base de Datos” (DATABASE).
El objeto base de datos (DATABASE) es aquel donde están definidas los esquemas,
relaciones, datos, restricciones y reglas de integridad de un conjunto de datos (Melton
2003), esta descripción coincide con la propuesta por el estándar para el objeto tipo
“catalogo” (CATALOG).
El estándar no establece alguna instrucción para crear el objeto catalogo, sin embargo
todos los sistemas manejadores implementan la instrucción “CREATE DATABASE” para
crear el objeto base de datos, el cual no está definido en el estándar. Todos los sistemas
manejadores en cuestión implementan esta instrucción y su ejecución resulta en el mismo
resultado: la creación del objeto “DATABASE”. Sin embargo, el caso de ORACLE acepta
la instrucción pero requiere de varios parámetros para la ejecución de la instrucción, este
es debido a que la estructura lógica que tiene ORACLE es más grande y compleja que la
que define el estándar, el resto de los manejadores lo ejecutan de manera compatible.
Experimento 1: “CREATE DATABASE”.
1.1 ORACLE
Figura 3 CREATE DATABASE-ORACLE
72
1.2 SQLSERVER
Figura 4 CREATE DATABASE-SQLSERVER
1.3 POSTGRESQL
Figura 5 CREATE DATABASE POSTGRESQL
73
1.4 MYSQL
Figura 6 CREATE DATABASE-MYSQL
Los manejadores también implementan una instrucción para eliminar dicho objeto, este el
case de “DROP DATABASE”, al igual que la instrucción “CREATE DATABASE”, ésta es
compatible con todos los sistemas manejadores en cuestión.
Así, podemos decir que la instrucción “CREATE DATABASE” es compatible con todos los
sistemas manejadores de base de datos evaluados en este trabajo, a pesar que la
instrucción no existe en el estándar SQL:2003.
Esquemas (Schemas).
El estándar define un esquema como una colección de descriptores en estado
persistente, estos descriptores son tablas, vistas, procedimientos almacenados,
funciones, etc. La creación y eliminación de esquemas se realiza a través de la ejecución
de instrucciones SQL (Melton 2003).
Los catálogos y esquemas son elementos de organización lógica que utilizan los sistemas
manejadores para alojar todos los objetos asociados a una base de datos.
La forma de organización de estos objetos depende directamente del manejador en
cuestión aún cuando utilizan las mismas instrucciones de SQL para su creación y
mantenimiento, sin embargo, una misma instrucción puede generar una estructura lógica
diferente en cada manejadores.
La instrucción asociada en SQL:2003 para la creación de esquemas está definida en la
siguiente regla:
74
CREATE SCHEMA <schema name clause> [ <schema character set or path> ] [ <schema element>... ]
La instrucción “CREATE SCHEMA” es aceptada por los cuatro sistemas manejadores de
acuerdo a la especificación del estándar, sin embargo su ejecución resulta en la creación
de diferentes objetos lógicos dentro de la base de datos.
En el caso de, ORACLE, SQLSERVER y POSTGRESQL, la instrucción genera el mismo
tipo de objeto dentro de la organización de la base de datos de acuerdo a la
especificación del estándar, esto permite tener múltiples esquemas dentro de una misma
base de datos.
Para el caso de MySQL el objeto “DATABASE” y “SCHEMA” tienen el mismo significado,
ambos se crean con el mismo objeto al mismo nivel lógico, es decir, los dos crean una
base de datos en cierto directorio y con cierto espacio físico dentro del sistema.
Normalmente el uso de esquemas permite tener objetos con el mismo nombre bajo
diferentes esquemas y facilita también los aspectos de seguridad y acceso a los objetos y
datos de una base de datos.
Experimento 2: “CREATE SCHEMA”
2.1 ORACLE
ORACLE si integra el objeto esquema según el estándar, pero la sintaxis que define el
manejador difiere de la establecida por el propio estándar. Una diferencia importante es
que el nombre del esquema debe ser el mismo de un usuario ya dado de alta en el
sistema manejador ya que será éste el dueño del esquema. En cuanto al aspecto de la
estructura lógica si cumple de acuerdo al tipo de objeto que representa ya que permite
agregar múltiples esquemas sobre una misma base de datos.
75
Figura 7 CREATE SCHEMA-ORACLE
2.2 SQLSERVER
Figura 8 CREATE SCHEMA - SQLSERVER
76
2.3 POSTGRESQL
Figura 9 CREATE SCHEMA POSTGRESQL
2.4 MySQL
Figura 10 CREATE SCHEMA MYSQL
Como se mencionó anteriormente, esta instrucción es aceptada a nivel sintáctico por
todos los manejadores, sin embargo, el tipo de objeto lógica que crea en cada sistema
puede cambiar, este fue el caso de MYSQL que crea un objeto “DATABASE” y no así un
objeto “SCHEMA”.
Tablas (Tables)
El estándar establece una instrucción para la definición y creación de una tabla
persistente o temporal dentro de una base de datos. De acuerdo al estándar estas tablas
se crean sobre un esquema perteneciente a una base de datos.
El estándar establece la siguiente regla para esta instrucción:
77
<table definition> ::=
CREATE [ <table scope> ] TABLE <table name> <table contents source>
[ ON COMMIT <table commit action> ROWS ]
<table contents source> ::=
<table element list>
| <typed table clause>
| <as subquery clause>
<table scope> ::= <global or local> TEMPORARY
<global or local> ::=
GLOBAL
| LOCAL
<table commit action> ::=
PRESERVE
| DELETE
<table element list> ::=
<left paren> <table element> [ { <comma> <table element> }... ] <right paren>
<table element> ::=
<column definition>
| <table constraint definition>
| <like clause>
<typed table clause> ::=
OF <path-resolved user-defined type name> [ <subtable clause> ]
[ <typed table element list> ]
<typed table element list> ::=
<left paren> <typed table element>
[ { <comma> <typed table element> }... ] <right paren>
<typed table element> ::=
<column options>
| <table constraint definition>
| <self-referencing column specification>
<self-referencing column specification> ::=
REF IS <self-referencing column name> [ <reference generation> ]
<reference generation> ::=
SYSTEM GENERATED
| USER GENERATED
| DERIVED
<self-referencing column name> ::= <column name>
<column options> ::= <column name> WITH OPTIONS <column option list>
<column option list> ::=
[ <scope clause> ] [ <default clause> ] [ <column constraint definition>... ]
<subtable clause> ::= UNDER <supertable clause>
<supertable clause> ::= <supertable name>
<supertable name> ::= <table name>
<like clause> ::= LIKE <table name> [ <like options> ]
<like options> ::= <like option>...
<like option> ::=
<identity option>
| <column default option>
| <generation option>
<identity option> ::=
INCLUDING IDENTITY
| EXCLUDING IDENTITY
<column default option> ::=
INCLUDING DEFAULTS
| EXCLUDING DEFAULTS
<generation option> ::=
INCLUDING GENERATED
| EXCLUDING GENERATED
78
<as subquery clause> ::=
[ <left paren> <column name list> <right paren> ] AS <subquery>
<with or without data>
<with or without data> ::=
WITH NO DATA
| WITH DATA
De aquí podemos inferir la instrucción mínima:
CREATE TABLE NOMBRE_TABLA(
<column_definition>
);
Esta instrucción es compatible para todos los sistemas manejadores en cuestión, es
reconocida léxica, sintáctica y semánticamente por todos.
Experimento 3: “CREATE TABLE”
3.1 ORACLE
Figura 11 CREATE TABLE - ORACLE
79
3.2 SQLSERVER
Figura 12 CREATE TABLE-SQLSERVER
3.3 POSTGRESQL
Figura 13 CREATE TABLE-POSTGRESQL
80
3.4 MySQL
Figura 14 CREATE TABLE-MYSQL
Como se pudo observar, esta instrucción es totalmente compatible entre todos los
sistemas manejadores de base de datos que se están evaluando ya que se ejecuto sin
error y crean el mismo tipo de objeto dentro de la base de datos.
Tipos De Datos (Data Types)
En la gramática para la creación de una tabla existe un elemento denominado
<column_definition>, este elemento está representado por la definición de atributos que
tiene la tabla, así como el tipo y longitud de cada uno de ellos. Los tipos de datos son uno
de los elementos más importantes en la definición de tablas ya que es ahí donde se
encuentran varias diferencias en los elementos sintácticos y semánticos sobre la
implementación de cada sistema.
Es importante notar que la compatibilidad de los datos puede ser vista como el tipo de dato que representa (valor) y la definición del mismo en el sistema manejador de base de datos. Es decir, un dato puede ser compatible entre diferentes sistemas por el tipo de dato en cuanto a su almacenamiento, aunque la definición del dato dentro del propio sistema sea diferente. Este trabajo se refiere a la compatibilidad en cuanto a la definición de los tipos de datos que se establece a través del lenguaje SQL
El estándar establece un tipo de dato como un conjunto de valores representables.
El estándar SQL:2003 soporta tres conjuntos de tipos de datos:
Datos predefinidos.
Tipos construidos.
Tipos definidos por el usuario.
81
Los tipos predefinidos son normalmente llamadas “inter-construidos”, los tipos definidos
por el usuario pueden ser definidos por un estándar, una implementación o por una
aplicación. Un tipo inter-construido se especifica utilizando alguno de los constructores de
tipos de datos de SQL: ARRAY, MULTISET y REF. Los tipos de datos de arreglo
(ARRAY) y multiconjunto (MULTISET) son generalmente conocidos como tipo de
colección.
El estándar define los tipos predefinidos mediante las siguientes palabras reservadas:
CHARACTER. CHARACTER VARYING. CHARACTER LARGE OBJECT. BINARY LARGE OBJECT. NUMERIC. DECIMAL. SMALLINT. INTEGER. BIGINT. FLOAT REAL. DOUBLE PRECISION. BOOLEAN. DATE. TIME. TIMESTAMP. INTERVAL.
Los tipos CHARACTER, CHARACTER VARYING y CHARACTER LARGE OBJECT son
referidos como tipos de cadenas de caracteres.
Los tipos BINARY LARGE OBJECT son referidos como cadenas binarias.
Los tipos CHARACTER LARGE OBJECT y BINARY LARGE OBJECT son referidos como
cadenas largas de objetos.
Los tipos NUMERIC, DECIMAL, SMALLINT, INTEGER y BIGINT son referidos como tipos
de números exactos.
Los tipos FLOAT, REAL y DOUBLE PRECISION son referidos como números
aproximados.
Los tipos de números exactos y aproximados son referidos de manera general como tipos
numéricos.
Los tipos TIME WITHOUT TIME ZONE y TIME WITH TIME ZONE son referidos como
tipos de tiempo.
Los tipos de datos DATE, TIME y TIMESTAMP son referidos como tipos fecha-hora.
82
Los tipos TIMESTAMP WITHOUT TIME ZONE y TIMESTAMP WITH TIME ZONE son
referidos como tipos de fecha-hora de sistema con zona horaria.
Tipos numéricos.
Todos los tipos de datos numéricos establecidos en el estándar son soportados por tres
sistemas manejadores: PostgreSQL, MySQL y SQLSERVER, sin embargo encontramos
que existe cierta diferencia ya que el número de bytes asignados y por ende el rango que
soporte difiere uno del otro. El caso de ORACLE existen dos tipos de datos que no son
soportados al menos sintácticamente.
Este cumplimiento o compatibilidad con algunos tipos de datos establecidos en el
estándar se cumple a nivel de declaración léxica y sintáctica ya que una vez que esta
declaración es procesada por el sistema manejador de base de datos éste lo convierte a
un tipo de dato interno del manejador con un rango, precisión y escala diferente , este es
el caso de ORACLE que utiliza un tipo de dato interno denominado NUMBER que permite
almacenar datos numéricos fijos y aproximados en un mismo tipo de dato.
Podemos encontrar que existe compatibilidad léxica y semántica en la implementación del
estándar SQL que hacen los sistemas manejadores en cuanto a los tipos de datos
numéricos pero no existe una compatibilidad semántica de los mismos.
Podemos decir que un valor numérico puede ser compatible en los diferentes
manejadores bajo distintos tipos de datos aunque éste no sea el óptimo en cuanto al
espacio que ocupa.
Experimento 4: “Tipos de datos numéricos”
4.1 ORACLE.
Figura 15 TIPO NUMERICO-ORACLE
83
En este caso podemos ver que ORACLE no soporta el tipo de dato “BIGINT” ya que no
reconoce la palabra reservada aunque tiene un tipo de dato que permite almacenar datos
de esta naturaleza.
4.2 SQLSERVER
Figura 16 TIPO NUMERICO-SQLSERVER
84
4.3 POSTGRESQL
Figura 17 TIPO NUMERICO-POSTGRESQL
4.4 MYSQL.
Figura 18 TIPO NUMERICO-MYSQL
Como ya se mencionó anteriormente, tres sistemas aceptan todos los tipos de datos
numéricos establecidos por el estándar ya que pudimos comprobar que pasan
correctamente el análisis léxico y sintáctico; en cuanto al análisis semántico que realizó
cada manejado éste se realizó correctamente pero cada manejador dio una interpretación
85
diferente sobre la precisión, escala y rango sobre el tipo de dato. En algunos casos, el
manejador realizó conversiones a tipos de datos nativos del propio manejador.
Esto se puede visualizar en las siguientes ejecuciones:
En el caso de SQLSERVER se puede observar que el tipo de datos doble precisión fue
convertido a un tipo de punto flotante:
Figura 19 CONVERSION TIPO NUMERICO SQLSERVER
Para el caso de POSTGRESQL, nuevamente encontramos que el tipo numérico mantuvo
su definición, pero el tipo de dato decimal fue convertido por el manejador a un tipo
numérico de manera interna. Lo mismo ocurrió con el tipo de dato flotante que fue
convertido a un tipo de doble precisión.
Figura 20 CONVERSION SQL SERVER
86
En el caso de MYSQL, se pudo observar que el tipo numérico y decimal fueron
convertidos a decimal, y el tipo real y doble fueron convertidos a su vez a doble.
Figura 21 CONVERSION TIPO NUMERICO-MYSQL
De acuerdo a las ejecuciones realizadas fue posible observar que para el tipo de datos
numérico exactos podemos utilizar el tipo de dato NUMERIC que nos ofrece una mayor
compatibilidad entre los manejadores ya que nos permite definir un tipo numérico
indicando la precisión y escala del mismo; así es posible definir los tipos numéricos
exactos, positivos y negativos así como aquellos con decimales con una precisión de
hasta 39. En cuanto a los tipos REAL, FLOAT y DOBLE PRECISION se puede ocupar
esta último indicando la precisión que requiere el valor número a almacenar. Con esta
acción se pueden definir tipos de datos que almacenen de manera precisa los valores
numéricos que requiera el esquema de datos sin perder precisión y evitando errores como
el sobrepasar los rangos máximos sobre aquellos tipos que convierte el manejador.
De lo anterior, podemos representar un valor entero de la siguiente manera:
NUMBER(10,0)
Un entero largo:
NUMBER(19,0)
O bien un valor decimal con una escala de 2:
NUMBER(12,2)
87
Experimento 5: “Definición de datos numéricos estándar”
De acuerdo a experimento anterior, se implementará el resultado para generar una
definición que cumpla con el estándar y pueda ser ejecutada e interpretada por todos los
sistemas manejadores en cuestión.
5.1 ORACLE
En este caso se puede ver que este acercamiento produce el mismo resultado y permite
definir varios tipos de datos bajo la definición de uno sólo:
Figura 22 TIPO ESTANDAR NUMERICO-ORACLE
5.2 POSTGRESQL
Aquí se puede visualizar que el efecto fue el mismo ya que todos los tipos de datos
NUMERIC conservaron su tipo como un tipo interno del manejador y respetando la
definición de la precisión y escala.
88
Figura 23 TIPO ESTANDAR NUMERICO-SQLSERVER
5.3 SQLSERVER
La definición fue ejecutada sin error y todos los datos tipo NUMERIC conservaron el tipo
original y mantuvieron la precisión y escala del mismo.
Figura 24 TIPO ESTANDAR NUMERICO-SQLSERVER
89
5.4 MYSQL
Para este manejador es posible observar que la declaración estándar NUMERIC resulta
en una conversión al tipo interno DECIMAL del manejador respetando la precisión y
escala del tipo de dato.
Figura 25 TIPO ESTANDAR NUMERICO-MYSQL
Con este acercamiento podemos decir que es posible representar cualquier valor
numérico computable exacto sobre cualquier sistema manejador de base de datos que
implemente el tipo de dato estándar NUMBER(m[,n]) ya que permite conservar el espacio
y valor máximo en base a la precisión y escala del numero sin el riesgo de tomar los
rangos de datos que internamente el sistema manejador asigna a cierto tipo de datos que
puedan llevar a errores de “stackoverflow”.
Tipo Cadena de Caracteres
El estándar SQL:2003 establece los siguientes tipos de datos para almacenar cadenas:
CHARACTER CHARACTER VARYING CHARACTER LARGE OBJECT, NCHARACTER NCHARACTER VARYING
90
Donde CHARACTER permite almacenar “n” caracteres de manera consecutiva y fija
donde n representa el número máximo de caracteres que se pueden almacenar, cuando
la cadena es menor a n, el manejador rellena con blancos a la derecha dicha cadena
hasta completar el número definido en n. Estos espacios en blanco junto con el valor de la
izquierda son almacenados en el campo de la base de datos. Al obtener estos valores de
la base de datos, el manejador elimina dichos espacios en blanco.
CHARACTER VARYING permite almacenar “n” caracteres de manera variable, es decir,
cuando la cadena es menor a n, esta es almacenada tal cual sin agregar espacios.
Los tipos NCHARACTER y NCHARACTER VARYING actúan de la misma manera que los anteriores, la diferencia radica en el conjunto de caracteres que controla el espacio de dicho dato. Para el caso de CHARACTER Y CHARACTER VARYING el conjunto de caracteres es el definido por la base de datos y para el caso de NCHARACTER y NCHARACTER VARYING está definido por la variable del sistema manejador de base de datos que establece dicho valor. El tipo CHARACTER LARGE OBJECT permite almacenar datos binarios sin establecer un
conjunto de caracteres.
Todos los sistemas manejadores implementan los tipos de datos “CHARACTER”, “CHARACTER VARYING”, “NATIONAL CHARACTER” y “NATIONAL CHARACTER VARYING” de acuerdo al estándar y son compatibles léxica, sintáctica y semánticamente.
Experimento 6: “Tipos de datos cadena de caracteres” 6.1 ORACLE. Figura 26 TIPO CADENA-ORACLE
91
6.2 SQLSERVER. Para este manejador, también son aceptados todos los tipos de cadena marcados en el estándar: Figura 27 TIPO CADENA-SQLSERVER
6.3 POSTGRESQL En este caso podemos ver que los cuatro tipos son aceptados por el manejador. Figura 28 TIPO CADENA-POSTGRESQL
92
6.4 MYSQL.
Este sistema acepta las cuatro definiciones establecidas por el estándar: Figura 29 TIPO CADENA-MYSQL
De aquí podemos decir que los cuatro sistemas manejadores en cuestión son compatibles en cuanto a la definición de datos tipo cadena. Sin embargo, el estándar establece un tipo de dato para almacenar cadenas largas de caracteres binarios, en este caso no existe una compatibilidad ya que cada uno implementa su tipo de dato para este fin. El tipo CHARACTER LARGE OBJECT es implementado únicamente por PostgreSql; MySQL, MSSQL y ORACLE implementan sus propios tipos de datos para almacenar datos binarios. En la siguiente ejecución podemos visualizar el error que genera MySQL al no reconocer el tipo de dato CHARACTER LARGE OBJECT.
93
Figura 30 CHARACTER LARGE OBJECT-MYSQL
Este último tipo de dato tampoco es reconocido por el manejador SQLSERVER:
Figura 31 CHARACTER LARGE OBJECT-SQLSERVER
Y ocurre el mismo caso cuando se ejecuta en ORACLE:
94
Figura 32 CHARACTER LARGE OBJECT-ORACLE
Así, el tipo de dato CHARACTER LARGE OBJECT no es compatible en todos los
manejadores de base de datos en cuestión, ya que no es reconocido con las mismas
palabras reservadas establecidas en el estándar. Este tipo de dato permite almacenar
grandes volúmenes de caracteres binarios (BINARY) y no binarios (BLOB’s); en ambos
casos, tampoco existe una compatibilidad entre los sistemas manejadores ya que cada
uno implementan sus propios tipos de datos.
Una alternativa para guardar datos binarios es guardarlos como cadenas de caracteres y
hacer la conversión a datos binarios del lado de la aplicación. Para el caso de cadenas
grandes de caracteres, se puede utilizar el tipo de dato “VARCHAR” implementando su
valor máximo. Normalmente la necesidad de almacenar grandes cantidades de caracteres
surge de almacenar archivos directamente en la base de datos, esto es una práctica que
en algunas ocasiones no resulta la más conveniente debido a la carga de procesamiento
en tareas de recuperación y ordenación que tiene que realizar el sistema. Una alternativa
a esta cuestión es almacenar dichos archivos directamente en el sistema de archivos del
sistema operativo y guardar únicamente la ruta donde se encuentra el archivo dentro de la
base de datos, esto presupone que el almacenamiento y recuperación depende de la
aplicación y no de la base de datos y también que las rutas deben ser siempre accesibles
para la aplicación de datos.
Podemos decir que cuando el dominio de una aplicación sea el tratamiento de archivos
binarios muy grandes como fotografías, streams, música, etc. la implementación de tipos
de datos estándar puede resultar en rangos de almacenamiento insuficiente.
Tipo de datos de Fecha y Tiempo (DateTime)
El estándar SQL:2003 enuncia los siguientes descriptores de tipo de datos de fecha y
tiempo:
DATE. TIME WITHOUT TIME ZONE. TIMESTAMP WITHOUT TIME ZONE. TIME WITH TIME ZONE. TIMESTAMP WITH TIME ZONE.
95
Cada uno de estos tipos de datos está conformado por un subconjunto de los siguientes campos.
Campo Significado
YEAR Año
MONTH Mes dentro de año.
DAY Día dentro de mes.
HOUR Hora dentro del día.
MINUTE Minuto dentro de la hora.
SECOND Segundo y posiblemente la fracción de
segundo dentro de un minuto.
TIMEZONE_HOUR Valor de hora del desplazamiento de la
zona.
TIMEZONE_MINUTE Valor del minuto del desplazamiento de la
zona.
Tabla 11 Tipos de datos Fecha y Tiempo
Existe un orden significativo, del más significativo al menos significativo: YEAR, MONTH,
DAY, HOUR, MINUTE y SECOND.
El estándar define tres clases de tipos de datos de fecha/tiempo:
DATE Contiene los campos primarios: YEAR, MONTH y DAY.
TIME Contiene los campos primarios: HOUR, MINUTE y SECOND.
TIMESTAMP Contiene los campos primarios: YEAR, MONTH, DAY, HOUR,
MINUTE y SECOND.
Los campos tipo fecha/tiempo son comparables solo si contienen los mismos campos
primarios.
Los cuatro sistemas manejadores en cuestión tiene algún tipo de dato para almacenar
fechas y tiempo, sin embargo todos exceptuando ORACLE incluyen los tres tipos de datos
establecidos en el estándar.
Experimento 7: “Tipo de datos Fecha/Tiempo”
7.1 ORACLE
En el caso de ORACLE el tipo de dato “TIME” no es reconocido por el sistema:
96
Figura 33 TIPO FECHA/TIEMPO-ORACLE
El tipo de dato “DATE” de ORACLE permite guardar toda la estructura que indica el
estándar tanto para la parte de fecha como de tiempo en el mismo tipo, es por esto, que
no incluye un tipo de dato para el tiempo exclusivamente.
7.2 SQLSERVER.
Al igual que los anteriores, también soporta los tipos de datos fecha/tiempo establecidos
en el estándar:
Figura 34 FECHA/TIEMPO-SQLSERVER
97
En el caso de SQLSERVER el tipo de dato timestamp no está documentado como un tipo
de dato del manejador, sin embargo, al ejecutar la instrucción esta fue reconocida e
interpretada como un tipo de dato que guarda fecha y hora del sistema.
7.3 POSTGRESQL
Este sistema también soporta los tres tipos de datos marcados en el estándar:
Figura 35 FECHA/TIEMPO-SQLSERVER
98
7.4 MYSQL.
MySQL soporta los tres tipos de acuerdo al estándar:
Figura 36 FECHA/TIEMPO-MYSQL
De acuerdo al resultado, no todos los tipos de datos de fecha y tiempo establecidos por el
estándar son compatibles por los sistemas manejadores en cuestión.
Una alternativa para crear un tipo de dato compatible que guarde fecha y tiempo en todos
los manejadores es utilizar el tipo “TIMESTAMP” que guarde ambos valores, y desde la
aplicación o dentro del sistema manejador extraer a través de funciones el tipo de valor de
deseado, ya sea la fecha o la parte del tiempo.
El estándar establece que los tipos de datos de fecha/tiempo pueden o no incluir la zona
horaria. Esta especificación no es compatible tampoco de acuerdo al estándar ya que
MySQL y SQLSERVER no reconocen dichos tipos de datos de acuerdo a las palabras
reservadas y gramática que utiliza para su ejecución. Estos manejadores establecen sus
propias reglas para definir estos tipos de datos:
99
MySQL
Figura 37 ZONA HORARIA-MYSQL
SQL SERVER
Figura 38 ZONA HORARIA-SQLSERVER
100
Otro aspecto importante en la implementación de instrucciones SQL compatibles es el
formato en el que se definen los campos de fecha/tiempo. SQL establece que estos
campos son declarados como cadenas de caracteres y el manejador debe hacer una
interpretación o conversión del mismo hacia un valor correcto de dichos campos. Esta
conversión a veces puede resultar ambigua por los valores que puede tomar un campo en
cierto punto del tiempo. Para este efecto los manejadores incorporan algunas variables
globales para establecer de manera precisa el tipo de interpretación que debe dar a la
entrada y salida de datos de fecha/tiempo. Algunos sistemas manejadores toman este
valor de la configuración del ambiente y plataforma donde esta ejecutándose el sistema
manejador.
Es importante notar que aunque el manejador realiza dicha interpretación, en la mayoría
de los casos estos valores son almacenados en el formato estándar ISO 8601 que
establece un formato de YYYY-MM-DD para la fecha, donde YYYY son cuatro dígitos que
representan el año, MM dos dígitos que representan el mes y DD que representa dos
dígitos para el día. Y para el caso del tiempo establece un formato de 24 horas:
HH:MM:SS.
Establecer la entrada de estos tipos de datos bajo este formato permite que la escritura de
dichas entradas sea portable entre los sistemas manejadores que implementan dicho
estándar evitando ambigüedades en la interpretación de estos formatos.
Este caso lo encontramos en MySQL donde se escribió una instrucción con un atributo de
tipo fecha bajo el formato de DDMMYYYY el cual no pudo interpretar:
Figura 39 FORMATO FECHA-MYSQL
101
El formato DDMMYYYY fue interpretado correctamente por el resto de los sistemas,
aunque internamente el valor fue almacenado en formato YYYYMMDD.
Esto lo podemos corroborar en la siguiente ejecución sobre el sistema SQLSERVER y
POSTGRESQL:
Figura 40 FORMATO FECHA-SQLSERVER
Figura 41 FORMATO FECHA-POSTGRESQL
102
En ambos casos podemos observar que internamente los sistemas realizaron una
conversión hacia el formato que tiene establecido el sistema manejador.
Tipo de datos Booleano
El estándar SQL:2003 define el tipo de datos booleano con el descriptor:
BOOLEAN
Este tipo de campo permite almacenar tres valores de verdad, basado en la lógica de tres
valores:
True (verdadero).
False(falso).
Null(desconocido).
Este último puede ser almacenado siempre y cuando el atributo no contenga una
restricción de no nulos (NOT NULL).
El tipo de de dato BOOLEAN fue aceptado en ORACLE, PostgreSQL y MySQL; para el
caso de SQLSERVER no fue reconocido ya que este tipo de dato no lo incorpora en sus
tipos de datos nativos.
Experimento 8: “Tipo de dato Booleano”
8.1 ORACLE
Figura 42 TIPO BOOLEANO-ORACLE
103
8.2 SQLSERVER
Figura 43 TIPO BOOLEANO-SQLSERVER
8.3 POSTGRESQL
Figura 44 TIPO BOOLEANO-POSTGRESQL
104
8.4 MYSQL
Figura 45 TIPO BOOLEANO-MYSQL
En ciertos casos este tipo de atributo es convertido a un entero pequeño y almacena un
valor de “1” para verdadero, “0” para false y la marca de nulo prevalece.
Esta puede ser una alternativa para almacenar un valor de verdad, sin embargo, no es
posible que dichos valores sean evaluados como valores de verdad como lo indica el
estándar. El seguir esta alternativa orillaría al programador a llevar esta lógica de
evaluación al nivel de la aplicación y no al nivel de la base de datos.
Proyección
La proyección está representada por la función “SELECT” en el lenguaje SQL, esta
instrucción forma parte del conjunto de instrucciones del sublenguaje de manipulación de
datos (DML).
Según el estándar, la instrucción SELECT está definida de la siguiente forma:
<query specification> ::= SELECT [ <set quantifier> ] <select list> <table expression> <select list> ::= <asterisk> | <select sublist> [ { <comma> <select sublist> }... ] <select sublist> ::= <derived column> | <qualifier> <period> <asterisk> <derived column> ::= <value expression> [ <as clause> ] <as clause> ::= [ AS ] <column name>
105
<table expression> ::= <from clause> [ <where clause> ] [ <group by clause> ] [ <having clause> ] <from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
Esta instrucción esta implementada de acuerdo al estándar en los cuatro sistemas
manejadores en cuestión:
Dada la siguiente relación:
Estudiante = {IdAlumno, Nombre, Apellido, Grado}
Con los siguientes datos:
IdEstudiante Nombre Apellido Grado
1000 RENE SANCHEZ SERRANO 1
1002 FERNANDO SOLIS PEREZ 1
1003 ANA AYALA HERNANDEZ 1
Se realizara una proyección sobre todos los atributos de la relación (*):
Experimento 9: “Proyección (SELECT)”
9.1 ORACLE
Figura 46 PROYECCION-ORACLE
106
9.2 SQLSERVER
Figura 47 PROYECCION-SQLSERVER
9.3 POSTGRESQL.
Figura 48 PROYECCION-POSGRESQL
107
9.4 MYSQL.
Figura 49 PROYECCION-MYSQL
La proyección (SELECT) es una operación que es compatible con todos los sistemas
manejadores en cuestión de acuerdo al estándar SQL.
Eliminación
La eliminación de renglones dentro de una tabla se hace a través de la instrucción
“DELETE” del lenguaje SQL.
De acuerdo a la especificación del estándar de SQL, la instrucción “DELETE” está
definida de la siguiente manera:
<delete statement: searched> ::=
DELETE FROM <target table> [ [ AS ] <correlation name> ]
[ WHERE <search condition> ]
Donde:
<target table> representa el nombre de la relación dentro de la base o esquema de datos.
<search condition> es la selección que se realiza sobre una relación R. La ausencia de
esta selección, elimina todas las tuplas de la relación.
Esta instrucción se encuentra implementada en los cuatro sistemas en cuestión. De
acuerdo a las pruebas realizadas todos los sistemas cumplen con el estándar y son
compatibles uno con otro.
108
Dada la siguiente relación:
Estudiante = {IdAlumno, Nombre, Apellido, Grado}
Con los siguientes datos:
IdEstudiante Nombre Apellido Grado
1000 RENE SANCHEZ SERRANO 1
1002 FERNANDO SOLIS PEREZ 1
1003 ANA AYALA HERNANDEZ 1
Se ejecutará la instrucción para eliminar la tupla identificada por el número 1002.
Experimento 10: “Eliminación (DELETE)”
10.1 ORACLE
Figura 50 ELIMINACION-ORACLE
10.2 SQLSERVER
Figura 51 ELIMINACION-SQLSERVER
109
10.3 POSTGRESQL
Figura 52 ELIMINACION-POSTGRESQL
10.4 MYSQL
Figura 53 ELIMINACION-MYSQL
110
En todos los casos el resultado de la ejecución de la instrucción fue un registro eliminado
dentro de la relación, es posible decir que el operador de eliminación es compatible con
todos los sistemas manejadores en cuestión de acuerdo al estándar SQL.
Inserción
La agregación de nuevas tuplas a una relación está definida por la instrucción “INSERT”
de SQL.
Según el estándar esta instrucción sigue la siguiente definición:
<insert statement> ::=
INSERT INTO <insertion target> <insert columns and source>
<insertion target> ::= <table name>
<insert columns and source> ::=
<from subquery>
| <from constructor>
| <from default>
<from subquery> ::=
[ <left paren> <insert column list> <right paren> ]
[ <override clause> ]
<query expression>
<from constructor> ::=
[ <left paren> <insert column list> <right paren> ]
[ <override clause> ]
<contextually typed table value constructor>
<override clause> ::=
OVERRIDING USER VALUE
| OVERRIDING SYSTEM VALUE
<from default> ::= DEFAULT VALUES
<insert column list> ::= <column name list>
Donde:
<table name> es el nombre de la relación donde se añadirá la nueva tupla.
<insert columns and source> es la lista de los atributos y la lista de los valores a cada
atributo. Estos valores pueden provenir de una sub-consulta, valores por default o valores
asignados.
Continuando con la relación Estudiante, se ejecutará la instrucción “INSERT” de acuerdo
al estándar para agregar una nueva tupla a la relación.
111
Experimento 11. “Inserción (INSERT INTO)”
11.1 ORACLE
Figura 54 INSERCION-ORACLE
11.2 SQLSERVER
Figura 55 INSERCION-SQLSERVER
112
11.3 POSTGRESQL
Figura 56 INSERCION-POSTGRESQL
11.4 MYSQL
Figura 57 INSERCION-MYSQL
De acuerdo a los resultados observados es posible afirmar que esta instrucción es
compatible entre todos los sistemas manejadores en cuestión de acuerdo al estándar
SQL.
113
Actualización.
La instrucción de SQL que actualiza los valores de los atributos de una tupla es
“UPDATE”.
Según el estándar esta instrucción sigue la siguiente definición:
<update statement: searched> ::=
UPDATE <target table> [ [ AS ] <correlation name> ]
SET <set clause list>
[ WHERE <search condition> ]
De acuerdo al estándar y siguiendo con la relación Estudiante, se ejecutara la instrucción
“UPDATE” en los sistemas manejadores.
Experimento 12: “Actualización (UPDATE)”
12.1 ORACLE
Figura 58 ACTUALIZACION-ORACLE
12.2 SQLSERVER:
Figura 59 ACTUALIZACION-SQLSERVER
114
12.3 POSTGRESQL
Figura 60 ACTUALIZACION-POSTGRESQL
12.4 MYSQL
Figura 61 ACTUALIZACION-MYSQL
Al igual que las instrucciones anteriores, la actualización es compatible con todos los
sistemas en evaluación de acuerdo al estándar de SQL.
115
Ordenación
El orden de las tuplas de una relación no es trascendente según el modelo relacional
establecido por Codd, sin embargo la implementación de SQL introduce una instrucción
que permite ordenar una relación en base a una expresión bajo la siguiente forma:
<sort specification list> ::=
<sort specification> [ { <comma> <sort specification> }... ]
<sort specification> ::=
<sort key> [ <ordering specification> ] [ <null ordering> ]
<sort key> ::= <value expression>
<ordering specification> ::=
ASC
| DESC
<null ordering> ::=
NULLS FIRST
| NULLS LAST
SQL realiza la ordenación en base al tipo de dato evaluado en la lista de atributos. Es
decir, evalúa tipos numéricos, carácter, fechas, horas, etc. La ordenación por defecto es
en forma ascendente, la cual puede ser modificada por el modificador “DESC” que hace
que la ordenación sea de forma descendente. Esta última especificación la cumplen de
manera completa todos los manejadores de base de datos sobre tipos nativos del
estándar.
Cuando el campo o atributo evaluado para la ordenación contiene marcas de nulos o
ausencia de valores, la operación por defecto que establece el estándar es colocar dichas
tuplas al último de la relación. Solo los manejadores ORACLE y POSTGRESQL cumplen
con el estándar. Esto se puede observar ver en las siguientes ejecuciones:
Experimento 13: “Ordenación”
13.1 ORACLE
Este manejador si hace la ordenación de acuerdo al estándar, pone los nulos al final de la
ordenación:
116
Figura 62 ORDENACION-ORACLE
13.2 SQLSERVER:
En este manejador también coloca los nulos al principio:
Figura 63 ORDENACION-SQLSERVER
117
13.3 POSTGRESQL
Este sistema manejador si cumple con lo establecido con el estándar, coloca los nulos al
final:
Figura 64 ORDENACION-POSTGRESQL
118
13.4 MYSQL
En este manejador, los atributos con ausencia de valor son ordenados al principio,
contrario a lo que establece el estándar:
Figura 65 ORDENACION-MYSQL
Como se pudo observar MySQL Y SQLSERVER ordenan en primera instancia las tuplas
que contiene marca de nulos en los atributos evaluados por la ordenación. A pesar que el
estándar establece una especificación para la ordenación de nulos (NULLS FIRSTS,
NULLS LAST), estos manejadores no reconocen dicha especificación.
119
CONCLUSIONES
El modelo relacional presentado por Codd ha revolucionado el mercado de las bases de
datos; después de más de 30 años sigue vigente entre los principales sistemas
manejadores de base de datos. A lo largo de este tiempo ha sido implementado por casi
todos los sistemas de base de datos existente en el mercado. Paralelamente al
surgimiento e implementación del modelo relacional ha existido un lenguaje estructurado
para definir y manipular los datos dentro de los sistemas relacionales de base de datos,
este ha sido el caso de SQL. Este lenguaje al igual que el modelo relacional ha sido
implementado por casi todos los sistemas relacionales que existen en el mercado, su
propagación y aceptación ha crecido al mismo ritmo que los sistemas relacionales. En
algunos casos, la implementación de este lenguaje dentro de los sistemas manejadores
ha permitido la aceptación y crecimiento de dichos sistemas.
El lenguaje SQL fue propuesto como un lenguaje basado en el algebra relacional y con un
gran apego a las operaciones establecidas en el propio modelo, esto le ha permito una
gran aceptación entre los usuarios de base de datos, esto también debido a la facilidad de
uso que presenta el lenguaje. SQL es un lenguaje declarativo, esto permite ocultar al
usuario las tareas requeridas para obtener cierto resultado deseado.
La aceptación que ha tenido SQL dentro los sistemas manejadores de base de datos lo
ha convertido en el lenguaje “de facto” de los sistemas de base de datos.
Al convertirse en un lenguaje aceptado por casi todos los sistemas manejadores, han
surgido al mismo tiempo tantas versiones como implementaciones del mismo. Ante esta
situación surgió la necesidad de establecer un lenguaje que pudiese ser considerado
estándar a lo largo de los sistemas que lo implementan.
Esta tarea ha sido un proceso largo, y ha sido llevado a cabo por algunas organizaciones
de estándares, como es el caso de ISO y ANSI. Este proceso de estandarización ha
pasado por varios estados y momentos dentro del mercado de las base de datos. En
primera instancia, el estándar pretendía incluir las características y funcionalidad que cada
manejador ofrecía, y de estas características construir un estándar. Esta situación no
aseguraba la compatibilidad del lenguaje entre los sistemas que lo implementaban tan
solo representaba un compendio de características similares no necesariamente
compatibles.
120
Otro momento en el proceso de estandarización ha sido cuando el equipo y
organizaciones encargadas de desarrollar dicho estándar establecen una plataforma que
incluye definiciones, reglas, aspectos de implementación y cumplimiento del “como” es
implementado el lenguaje SQL dentro de los manejadores; en este momento los
desarrolladores de sistemas relacionales de base de datos tomaron el estándar y
pretendieron dar cumplimiento al mismo en sus implementación, esta tarea acerca más la
posibilidad de establecer un lenguaje compatible entre los manejadores, sin embargo,
cada uno siguió marcando diferencias en la implementación. En la mayoría de los casos,
estas diferencias no son provocadas por condiciones técnicas de la implementación, sino
más bien por aspectos de diferenciación de sus productos en el mercado.
En la última etapa que ha tenido el estándar hemos observado que nuevamente son
algunos sistemas manejadores de base de datos los que han influido fuertemente en sus
definición y desarrollo, esto lo podemos ver en que la versión 2003 del estándar esta
incluyendo dos partes nuevas: la primera relacionada a los tipos de datos de conjunto
(SETS) y lo relacionado al uso y manipulación de datos en formato XML. A la aparición de
este estándar, estos temas ya estaban previamente implementados por algunos
manejadores, como es el caso de ORACLE, y es notorio ver que el estándar sigue en
gran medida la implementación que ya han hecho estos sistemas manejadores.
Hoy en día, el interés de la mayoría de los sistemas manejadores no se centra en darle un
cumplimiento al estándar de SQL, más bien podemos decir que el estándar sirve como
una guía para la implementación que cada sistema hace del lenguaje, y como marco
técnico para desarrollar aspectos propios de cada manejador como el caso funciones y
tipos de datos.
El estándar establece la mayoría de los aspectos que se requieren para su
implementación, si el sistema manejador siguiera la especificación del estándar entonces
el resultado sería una implementación estándar y compatible con cualquier otro sistema
que siga dicho estándar, sin embargo, el nivel de cumplimiento que cada sistema le da al
estándar no depende de los aspectos técnicos, más bien cada sistema trata de desarrollar
productos con diferenciales que les permitan penetrar nichos mercado. En algunas
ocasiones estos diferenciales provienen desde propia filosofía que plantea cada
manejador y por ende el lenguaje que implementa sigue en gran medida estos objetivos
más que el de generar productos estándar que puedan ser compatibles.
121
La compatibilidad que dicen tener los sistemas manejadores con el estándar se centra en
características funcionales y de operación y no en la forma de implantación que debe
soportar dichas características. Por ejemplo, podemos encontrar que el estándar
establece un cierto de tipo de dato, en la documentación podemos ver que todos los
sistemas soportan dicho tipo de dato, pero la definición que hace cada sistema para este
tipo de dato es diferente y en consecuencia no es compatible dicha definición.
De las dos partes o sublenguajes que cubre este trabajo como son el lenguaje de
definición de datos (DDL) y el lenguaje de manipulación de datos (DML) encontramos que
la mayor parte de la incompatibilidad se encuentra en el apartado de la definición de
datos. Esto es debido, como ya se mencionó anteriormente, a los aspectos diferenciales
que plantea cada manejador y es aquí donde son más notorios ya que la definición de los
esquemas de datos está totalmente ligada a aspectos de estructura lógica y física que
ofrece cada sistema. Estas estructuras son aspectos importantes a considerar en la
elección y utilización de un sistema manejador ya que representan las características de
desempeño, distribución, utilización, replicación, consistencia, entre otros, que hacen a los
sistemas manejadores más apropiados para cierto tipo de aplicación y plataformas de
despliegue. Podemos decir que estas estructuras de algunos sistemas manejadores son
mucho más complejas que en otros, dado que dan un nivel de granularidad más alto y
complejo.
En la parte del lenguaje de manipulación podemos ver si existe un alto nivel de
compatibilidad entre los sistemas manejadores de acuerdo al estándar. Esto hace posible
definir instrucciones SQL que pueden ser ejecutadas en los sistemas manejadores sin
realizar cambio alguno en su escritura.
Algunas de las diferencias que encontramos están relacionadas directamente a cierto de
tipo de aplicaciones que utilizan este tipo de características, por ejemplo en cuanto a los
tipos de datos pudimos ver que aplicaciones que utilizan almacenamiento de grandes
archivos binarios o de caracteres como son archivos de imágenes, texto, secuencias,
entre otros, son difícilmente compatibles, por la definición y forma de almacenamiento que
tiene cada sistema. De aquí podemos decir que este tipo de aplicaciones no son
compatibles desde el origen y requieren una definición del esquema de datos
directamente en el sistema manejador.
122
Existen otro tipo de diferencias que no definen del todo un tipo o rubro de aplicación que
marque una incompatibilidad, este tipo de diferencias en la mayoría de los casos tiene al
menos una alternativa para crear instrucciones SQL compatibles que ofrezcan la misma
funcionalidad, en algunos casos requiere de de realizar pruebas de compatibilidad en
sentido contrario al estándar, es decir, existen ciertas definiciones, y sobre todo en los
tipos de datos, en los que el sistema manejador realizar conversiones internas aunque en
la definición de más alto nivel se indique otra especificación, al comparar estas
conversiones podemos ver que el resultado es un tipo de dato interno del manejador que
a su vez es compatible con el estándar y permite almacenar el mismo tipo de dato en
todos los manejadores. En otros casos se tiene que llevar la funcionalidad hacia la
aplicación para mantener la compatibilidad, esto es un tema de discusión que resalta el
objetivo de los sistemas manejadores de base de datos, ya que en algunos casos se lleva
gran parte de la lógica de negocio o aplicación hacia la base de dato, por ejemplo,
grandes procedimientos almacenados, desarrollo de funciones de usuario, control de
atributos auto-incrementables, etc. en la mayoría de estos casos estas funciones pueden
ser ejecutadas del lado de la aplicación y se deja al sistema manejador las tareas de
definición, almacenamiento, recuperación e integridad de datos, basadas en la definición
forma un sistema manejador de base de datos.
De acuerdo a todo lo anterior, podemos decir que si es posible establecer un esquema de
datos basado en el lenguaje SQL bajo el estándar SQL:2003 que pueda ser compatible
entre los sistemas que lo implementan. Un esquema de datos compatible bajo este
estándar permite una funcionalidad básica, refiriéndonos al término básico como un
esquema en donde dicho esquema:
Se defina a partir del objeto de base de datos denominado esquema (SCHEME).
No incluya la definición de campos para almacenar grandes cantidades de
archivos binarios o cadena de caracteres.
El cálculo de valores auto-incrementables se lleve del lado de la aplicación.
La ordenación de tuplas con ausencia de valores se lleve del lado de la aplicación.
Los campos booleanos se conviertan a un entero corto (0,1).
Se utilice el estándar para la definición de fechas y tiempos.
123
REFERENCIAS
AB, M. (2005). "MySQL Performance Benchmarks." 2009, from http://www.greatlinux.com/userfiles/mysql-performance-whitepaper.pdf. Arvin, T. (2008). "Comparison of different SQL implementations." Retrieved 10/12/2008, 2008, from http://troels.arvin.dk/db/rdbms/. AstroGrid. (2009). "DBMS Evaluations." I, from http://wiki.astrogrid.org/bin/view/Astrogrid/DbmsEvaluations. Baroni, A. L., C. Calero, et al. (2005). "A FORMAL DEFINITION FOR OBJECT-RELATIONAL DATABASE METRICS." Baroni, A. L., C. Calero, et al. (2006). "The Theory of Active Databases vs. The SQL Standard." Bauer, C. and G. King (2007). Java Persistence with Hibernate, Manning. Calero, C., F. Ruiz, et al. (2005). "An Ontological Approach to Describe the SQL:2003 Object-Relational Features." Catell, R. G. G. and D. K. Barry (2000 ). The Object Database Standard: ODMG 2.0. Chamberlin. (2005). "Query Processing." Retrieved 27/05/2008, 2008, from http://cimic.rutgers.edu/~sigmod05/SIGMODprogram.htm#is1. Chamberlin, D. D., et al. (1974). SEQUEL: A Structured English Query Language. Proceedings of the 1974 ACM SIGIDET Workshop on Data Description, Access and Control, ACM. Chapple, M. (2007) SQL Fundamentals. About.com Volume, DOI: CODD, E. (1990). The relational model for database management: version 2, Addison-Wesley. Codd, E. F. (1970). "A Relational Model of Data for Large Shared Data Banks." Communications of the ACM 13: 377-387. Codd, E. F. (1990). The relational model for database management : version 2, ADDISON-WESLEY. Eisenberg, A., K. Kulkarni, et al. (2004). "SQL:2003 Has Been Published." SIGMOD Record 33(1). Española, R. A. (2001). Real Academia Española. DICCIONARIO DE LA LENGUA ESPAÑOLA. Gulutzan, P. and T. Pelzer (2003). SQL Perfomance Tuning, Addison-Wesley. Hector, G.-M. (2009). Database Systems The Complete Book, Pearson Prentice Hall. IBM (2002). SQL Reference for Cross-Platform Development
124
IBM (2006) Structured Query Language (SQL). Volume, DOI: ISO/IEC. (2008). "ISO/IEC 9075-1:2003." Retrieved 10/11/2008, 2008, from http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=34132. Jones, A. S., Ryan K.; Plew, Ronald R.; Garrett, Robert F.; Kriegel, Alex (2005). SQL FUNCTIONS, Hungry Minds Inc,U.S. KALIAPPAN, P. S. and U. WLOKA (2007). "Investigations to the Conformance about Oracle, DB2, MS SQL Server, Sybase with respect to SQL:2003 Standard." Fachthema 23/2007: 38-44. Kimpo, P., A. Lucero, et al. (2004) An Introduction to the Oracle, MySQL, MS SQL SERVER and PostgreSQL Database Managemente Systems. Volume, DOI: Kriegel, A. and B. M. Trukhov (2008). SQL BIBLE Second Edition, Wiley. Lee, G. (2003) SQL 2003 Standard Support in Oracle Database 10g. Volume, DOI: Melton, J. (2003). Information technology — Database languages — SQL — Part 1: Framework(SQL/Framework). ISO/IEC. Melton, J. (2003). Information technology — Database languages — SQL — Part 2: Foundation (SQL/Foundation). ISO/IEC. Murali, T. M. (2009, ENERO, 2010). "SQL and Relational Algebra." from http://courses.cs.vt.edu/~cs4604/Fall09/lectures/lecture-03-intro-sql-relational-algebra.pdf. Paul, B. (1999). Implementing the spirit of SQL-99. International Conference on Management of Data, ACM. Pokorný, J. (2005). "Database architectures: current trends and their relationships to environmental data management." Pokrajac, D., H. Patel, et al. (2005). "INHERITANCE CONSTRAINTS IMPLEMENTATION IN POSTGRESQL." PostgreSQL. (2008). "SQL Conformance." Retrieved 10/11/2008, 2008, from http://www.postgresql.org/docs/8.3/static/features.html. Rabuzin, K., M. Malkovic, et al. (2007). "The Theory of Active Databases vs. The SQL Standard." SELTZER, M. I. (2005). "Beyond Relational Databases." Silberschatz, A., H. Korth, et al. (2006). Fundamentos de bases de datos. Software, B. (2009). "SQL Tips." from http://www.bristle.com/Tips/SQL.htm.
125
Stephens, R. K. and R. R. Plew (2005). Sams Teach Yourself SQL in 21 days, Sams. Stonebraker, M. and U. Çetintemel (2006). "“One Size Fits All”: An Idea Whose Time Has Come and Gone." T¨urker, C. and M. Gertz (2001). "Semantic integrity support in SQL:1999 and commercial (object-)relational database management systems." The VLDB Journal. Tanaka, M. (2005). "RDBMS conformance to standard SQL." 5. Tanasi, A. (2008). DataType Comparison. Turley, P. (2005). Beginning Transact-SQL with SQL Server 2000 and 2005. Ullman, J. D. and J. Widowm (1999). Introducción a los sistemas de Bases de Datos, Prentice Hall, México. Zavala, E. R. (2009). OPTIMIZACION DE RECURSOS DE BASE DE DATOS PARA OBTENER SISTEMAS DE INFORMACION DE ALTO DESEMPEÑO. SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN. MEXICO, D.F., INSTITUTO POLITÉCNICO NACIONAL. Maestro en Ciencias.