PROCEDIMIENTO / MANUAL OPERATIVO

Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
¿Qué es una Base de Datos y un Sistema de Gestión de Bases de Datos?
Una base de datos es un conjunto de datos no redundantes, almacenados en un
soporte informático, organizados de forma independiente de su utilización y accesibles
simultáneamente por distintos usuarios y aplicaciones.
La diferencia de una BD respecto a otro sistema de almacenamiento de datos es que
éstos se almacenan de forma que cumplan tres requisitos básicos:
 No redundancia: Los datos se almacenan una sola vez. Si varias aplicaciones
necesitan los mismos datos no crearán cada una su propia copia sino que todas
accederán a la misma.
 Independencia: Los datos se almacenan teniendo en cuenta la estructura
inherente a los propios datos y no la de la aplicación que los crea. Esta forma de
trabajar es la que permite que varias aplicaciones puedan utilizar los mismos
datos. Se puede hablar de dos tipos de independencia: independencia física, de
tal manera que la estructura física de la BD puede ser modificada de forma
transparente para los programas que la utilizan, e independencia lógica, es decir
el programador usa la BD pero desconoce su estructura interna
 Concurrencia: Varios usuarios, ejecutando la misma o diferente aplicación,
podrán acceder simultáneamente a los datos.
Arquitectura de un SGBD
La mayoría de los SGBDs actuales están inspirados en una arquitectura sugerida en
1978 por un grupo de trabajo de ANSI. Es conocida como ANSI/X3/SPARC "DBMS
Framework
Esta arquitectura divide la base de datos en tres niveles :
 El nivel externo.- Es la representación de los datos tal y como los ve el usuario.
Cada
usuario tendrá una visión distinta de la base de datos dependiente del subconjunto de
datos que está autorizado a ver según sus privilegios de acceso y también, del formato
en que se le presentan que dependerá de las herramientas que utilice (por ejemplo, un
programa COBOL o un 4GL).
 El nivel lógico.- Es una representación abstracta del contenido total de la base
de datos Contiene la definición de todos los datos
existentes más otras informaciones como restricciones de seguridad, controles de
integridad, etc.
 El nivel interno.- Es el más cercano a la máquina. Es una representación a bajo
nivel
1
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
de la BD en la que se define la forma en la que los datos se almacenan físicamente en
la máquina. Se definen características como los dispositivos en donde se almacenan los
datos, el espacio que se reserva, las estrategias de acceso, la creación de ficheros de
índices, etc. Es dependiente de la máquina en que se vaya a instalar la BD, del sistema
operativo que exista, etc.
Un Sistema de Gestión de Bases de Datos (SGBD) es el conjunto de programas que
permiten definir, manipular y utilizar la información que contienen las bases de datos,
realizar todas las tareas de administración necesarias para mantenerlas operativas,
mantener su integridad, confidencialidad y seguridad.
El funcionamiento del SGBD está muy interrelacionado con el del Sistema Operativo,
especialmente con el sistema de comunicaciones.
Funciones de un SGBD
Normalmente se clasifican en definición, manipulación y utilización.
 Función de definición: Permite describir los elementos de datos, sus
estructuras, sus interrelaciones y sus validaciones a nivel externo, lógico e
interno. Esta función es realizada por una parte del SGBD denominada lenguaje
de definición de datos (LDD o DDL, Data Definition Language).
 Función de manipulación: Permite buscar, añadir, suprimir y modificar los datos
de la BD. (LMD o DML, Data Manipulation Language).
 Función de utilización: Incluye otras funcionalidades tales como: modificar la
capacidad de los registros, cargar archivos, realizar copias de seguridad,
rearranque, protección frente a accesos no autorizados, gestión de la
concurrencia, estadísticas de utilización, etc.
Un sistema de gestión de bases de datos consiste de una colección de datos
interrelacionados y un conjunto de programas para acceder a esos datos. La colección
de datos es la base de datos, y es la que contiene información, por ejemplo acerca de
una empresa determinada.
El objetivo principal de un SGBD.- Es suministrar la interfaz entre el conjunto de los
datos y todos los tipos de usuarios. debe proporcionar a los otros usuarios (analistas,
programadores, administradores) las correspondientes herramientas que les permitan
un adecuado desarrollo de sus funciones.
Definición del SGBD
Es un conjunto coordinado de programas, procedimientos, lenguajes, etc. que
suministra, tanto a usuarios no informáticos como a los analistas, programadores o al
administrador, los medios necesarios para describir, recuperar y manipular los datos
almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.
2
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Funciones del SGBD
De Descripción o Definición
Debe permitir al administrador de la base especificar los datos que
la integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semántica, los
controles a efectuar antes de autorizar el acceso a la base, etc., así como las característica de tipo físico y
las vistas lógicas de los usuarios. Esta función la realiza el lenguaje de definición de datos (DDL), propio
del SGBD, y debe ser capaz de definir las estructuras de datos a los tres niveles (nivel externo, nivel lógico
global o conceptual y nivel interno).
A nivel interno se define:
Espacio reservado para la base(volúmenes , cilindros y pistas) Longitud de los campos
Modo de representación de los datos (binario, decimal, alfanumérico, etc.) Caminos de
acceso como punteros e índices.
A nivel externo y conceptual, la función de descripción proporciona los instrumentos
para la definición de entidades, su identificación, atributos, interrelaciones entre ellas,
autorizaciones de acceso, restricciones de integridad, et El SGBD, además de describir,
debe permitir la correspondencia o mapping entre estos niveles.
De Manipulación
Permite a los usuarios de la base (todos) buscar, eliminar o modificar los datos de la
base, de acuerdo a las especificaciones y normas de seguridad dadas por el
administrador.
Esto se realiza mediante el lenguaje de manipulación de datos.- (DML), mediante un
conjunto de instrucciones (lenguaje huésped que son admitidas por un lenguaje de
programación (lenguajeanfitrión), o bien, mediante un lenguaje auto contenido, que
posee todas las instrucciones necesarias para llevar a cabo estas tareas. De Utilización
Reúne todas las interfaces que necesitan los diferentes tipos de usuarios para
comunicarse con la base y proporciona un conjunto de procedimientos para el
administrador.
Algunas de estas funciones de servicio son:
 cambiar capacidades de los archivos
 obtener estadísticas de utilización
 respaldos
3
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
 carga y descarga de la base
 seguridad
Lenguajes de los SGBD
Por las distintas funciones que cumple un SGBD, se hace necesario contar con
diferentes lenguajes y procedimientos que permitan la comunicación con la base
de datos.
Por tipo de función, tendremos lenguajes de definición y lenguajes de manipulación.
Por tipo de usuarios tendremos lenguajes para informáticos y lenguajes para no
informáticos o usuarios finales. Estos últimos, pueden tener aplicaciones formalizables
tal como la gestión de personal o no formalizables como cualquier proceso de toma de
decisiones. Por otro lado, los usuarios informáticos, como el DBA, analistas y
programadores requerirán medios poderosos por los cuales podrán definir, extraer y
manipular los datos en algún lenguaje de programación. A este lenguaje se le llama
lenguaje anfitrión (por ejemplo, C).
Casi la totalidad de los SGBD disponen de lenguajes de 4ta generación, que se
caracterizan por ser poco procedí mentales y el acceso a la base de datos se realiza
mediante sentencias embebidas en el lenguaje de 4ta generación y escritas en SQL
(SGBD relacionales).
Los lenguajes que por si mismos pueden actuar con la base de datos, sin necesidad de
apoyarse en otro lenguaje se llaman autocontenidos.
Lenguaje de Definición de Datos (DDL)
Las instrucciones más utilizadas del DDL son:
CREATE: Permite crear tablas, vistas, bases de datos o cualquier otro objeto
perteneciente a la base de datos.
CREATE TABLE: Para crear las tablas previamente definidas en el modelo relacional.
Sintaxis:
CREATE TABLE <nombre_tabla
(<nombre_atributo <tipo_dato,<restricciones);
Ejemplo:
CREATE TABLE alumno
4
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
(rut number(11),
dv number(1),
nombre char(20),
cod_carrera number(4),
direccion char(20),
constraint alumno_pk primary key rut);
Observaciones: La sintaxis para las restricciones es:
CONSTRAINT <nombre_constraint <tipo_constraint <columna [<opcional]
CONSTRAINT <nombre_constraint PRIMARY KEY <nombre_atributo
CONSTRAINT <nombre_constraint FOREIGN KEY <nombre_atributo
REFERENCES <tabla_referenciada.<atributo_referenciado
ALTER TABLE: Permite modificar los campos. Es posible agregar restricciones a las
tablas.
Sintaxis:
ALTER TABLE <nombre_tabla
ADD <nombre_atributo <tipo_dato;
ALTER TABLE <nombre_tabla
DD CONSTRAINT <restricción
Ejemplo:
ALTER TABLE alumno
ADD telefono number(8);
ALTER TABLE alumno
ADD CONSTRAINT alumno_fk_carrera FOREIGN KEY cod_carrera
REFERENCES carrera.cod_carrera;
Lenguajes de Manipulación de Datos (DML)
Para cumplir los objetivos asignados a la función de manipulación, se ha de contar con
lenguajes que den a los usuarios la posibilidad de referirse a determinados conjuntos de
datos que cumplan ciertas condiciones (criterio de selección).
El SQL como lenguaje de manipulación de datos tiene la propiedad dual, es decir,
puede actuar como huésped o autocontenido.
Los DML pueden ser procedimentales o no procedimentales, es decir, si necesitamos
especificar con detalle el acceso a la base tendremos un lenguaje procedimental.
Los lenguajes orientados al usuario final deben ser lo menos procedurales posible. Aquí
basta con decir qué se quiere, sin explicar cómo obtenerlo.
5
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Por otro lado, los DML pueden ser navegacionales, que recuperan o actualizan datos
registro a registro. Otros lenguajes actúan sobre un conjunto de registros, de forma que
una única sentencia puede dar lugar a la recuperación o actualización del conjunto de
registros que cumpla el criterio de selección especificado, tal como el SQL.
Condiciones:
 =, ,<,=,<=,!=: Indican que el atributo de la tabla puede ser igual, mayor, menor,
etc., que el valor especificado.
 BETWEEN <valor1 AND <valor2: Indica que el atributo debe encontrarse entre
los valores especificados.
 IN (<lista de valores separados por comas): Indica que el atributo debe tener uno
de los
 valores especificados en la lista.
 IS NULL: Indica que el atributo tiene valor nulo.
 LIKE <x: El atributo debe tener un patrón x.
 NOT: Puede preceder a cualquiera de las condiciones anteriormente
especificadas.
Precedencia para las condiciones:
INSERT:.- Permite insertar datos en la tabla.
Si se omite la lista de atributos, el intérprete SQL asume que se ingresarán valores para
todos los atributos de la tabla.
UPDATE.-: Permite actualizar datos en la tabla.
Sintaxis:
UPDATE <nombre_tabla
SET <atributo1=valor_atributo1 [,..,atributoN=valor_atributoN]
[WHERE <condiciones_para_los atributos] ;
Ejemplo:
UPDATE alumno
6
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
SET fono=41480430
WHERE nombre='Ismael Cortés B.'
DELETE: Permite eliminar registros completos de una tabla ,la condición, la
sentencia borrará todos los registros de la tabla.
Observaciones:
 Si se omiten las condiciones, se obtendrán todos los valores de los atributos
seleccionados para cada registro de la tabla.
 Si se coloca el símbolo * en la lista de atributos a seleccionar, se obtienen todos
los valores de los atributos de la tabla.
 DESC: Permite observar las columnas de una tabla
 DROP: Elimina una tabla de la base de datos.
Ejemplo.
Dado el siguiente esquema Entidad/Interrelación:
Con las siguientes definiciones para el modelo relacional:
Conceptos
Los principales conceptos que se manejan en bases de datos son:
Diccionario de datos: Reúne la información sobre los datos almacenados en la BD
(descripciones, significado, estructuras, consideraciones de seguridad, edición y uso de
las aplicaciones, etc.).
Directorio de datos: Es un subsistema del SGBD que describe dónde y cómo se
almacenan los datos de la BD (modo de acceso y características físicas de los datos).
Modelo de datos: Es un conjunto de conceptos, reglas y convenciones que permiten
describir y manipular los datos.
7
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Modelo relacional: Propuesto por Codd a finales de los sesenta introduce la teoría de
las relaciones en el campo de las BD. En este modelo los datos se estructuran en tablas
manteniendo la independencia de esta estructura lógica respecto al modo de
almacenamiento u otras características físicas. Las tablas se manejan mediante
operaciones de la teoría de conjuntos y el álgebra relacional.
DDL (Data Definition Language): Lenguaje de definición de datos, se utiliza para crear
y mantener la base de datos y los elementos que contiene a nivel externo, lógico e
interno. Es propio de cada SGBD. Permite definir entidades, identificadores (claves),
atributos, interrelaciones, autorizaciones de acceso, restricciones de integridad, etc. A
nivel interno facilita la definición del espacio físico, longitud de los campos,
representación de los datos (binario, alfanumérico...), caminos de acceso (punteros,
índices...), etc.
DML (Data Manipulation Language): Lenguaje de manipulación de datos, se utiliza
para la
actualización y consulta de los datos almacenados en la base de datos. Permite añadir,
seleccionar, suprimir o modificar los datos de la BD respetando las reglas establecidas
por el DDL.
SQL (Structured Query Language). El SQL es un lenguaje de alto nivel, no procedural,
normalizado que permite la consulta y actualización de los datos de BD relacionales. Se
ha convertido en el estándar de acceso a BD relacionales. La primera versión se aprobó
como norma ISO en 1987 y la segunda, conocida como SQL2 y vigente actualmente, en
1992. Actualmente se trabaja en la norma SQL3 que soportará bases de datos
orientadas a objeto y bases de datos activas.
El SQL facilita un lenguaje de definición de datos y un lenguaje de manipulación de
datos. Además, incluye un interfaz que permite el acceso y la manipulación de la BD a
usuarios finales. El SQL estándar no es un lenguaje de programación aunque sus
sentencias se pueden utilizar en lenguajes de tercera generación como COBOL o
FORTRAN. Mediante librerías dinámicas o controladores ODBC también se puede
emplear el SQL (aunque ya orientado hacia SGBDs específicos que proporcionan
dichas librerías y controladores) en lenguajes de cuarta generación, como C/C++, Visual
Basic, Clipper, etc.
Transacción: Conjunto de modificaciones sobre una BD que son una unidad
inseparable. Es decir, si se realiza alguna de las modificaciones deben realizarse todas,
en caso contrario no debe realizarse ninguna. Por ejemplo, si hay que transferir fondos
entre dos cuentas hay que impedir que un fallo del sistema permita que se reste el
dinero de una cuenta sin
llegar a sumarse a la otra.
8
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Commit: Los SGBDs ofrecen sentencias especializadas para la gestión de
transacciones, la nomenclatura habitual en bases de datos relacionales es: COMMIT
WORK, finalizar una transacción; ROLLBACK, deshacerla.
Two-Phase Commit: Proceso necesario para realizar Commit en BD distribuidas. Para
garantizar que todas las BD involucradas quedarán correctamente modificadas, el
Commit se divide en dos fases. Primero, se comprueba que todos los nodos
involucrados están listos para realizar la actualización. En segundo lugar, se modifican
las bases de datos si, y sólo si, todos los nodos están preparados.
Bloqueo: Cuando una transacción necesita asegurarse de que el contenido de un
recurso de la BD (un fichero, un registro u otro) no cambiará hasta que la transacción
finalice, se bloquea. El bloqueo impide que otras transacciones lo modifiquen. Existen
dos tipos principales de bloqueos: bloqueos exclusivos y bloqueos compartidos. Si una
transacción realiza un bloqueo exclusivo sobre un recurso, ninguna otra podrá ejecutar
ningún tipo de bloqueo contra el recurso. Se utilizan cuando la transacción va a
actualizar el recurso. Si una transacción realiza un bloqueo compartido, otras
transacciones podrán realizar bloqueos compartidos (pero no exclusivos) sobre ese
mismo recurso. Esta última técnica se utiliza cuando la transacción no va a actualizar los
datos pero desea evitar que otras transacciones puedan modificarlo.
Interbloqueos: Los interbloqueos se producen cuando dos transacciones que acceden
a una base de datos se bloquean mutuamente al intentar realizar un bloqueo exclusivo
sobre los mismos recursos. Todo SGBD debe implementar técnicas automáticas para
evitar los interbloqueos ya que si se producen ninguna de las transacciones puede
continuar y permanecerán en ese estado hasta que el SGBD lo resuelva.
Inconsistencia: Una base de datos está inconsistente si dos datos que deberían ser
iguales no lo son. Por ejemplo, un empleado aparece en una tabla como activo y en otra
como jubilado.
Integridad: Mantener la integridad de una base de datos es asegurarse de que los
datos que contiene son correctos, evitando datos inconsistentes o erróneos de cualquier
otro tipo. Por ejemplo, que un empleado aparezca como perteneciente a un
departamento que no existe en la tabla correspondiente.
Redundancia: Se llama redundancia al hecho de que los mismos datos estén
almacenados más de una vez en la base de datos. Las redundancias además de
suponer un consumo de recursos de almacenamiento pueden llevar a situaciones en las
que un dato se actualice en una de sus ubicaciones y en otra no y se pierda la integridad
de la BD, por tanto deben evitarse.
Redundancia controlada: En ocasiones, es necesario introducir voluntariamente
redundancia en la BD por consideraciones de rendimiento. En estos casos los
administradores del sistema repiten conscientemente algunos datos y, a la vez,
9
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
preparan al sistema para mantener automáticamente las distintas copias y que no se
pierda la integridad.
Confidencialidad: Consiste en proteger la BD contra accesos no autorizados. Debe
asegurarse no sólo que los usuarios no autorizados no consigan acceso a la BD sino,
también, que los usuarios legítimos acceden sólo a los datos autorizados.
Recuperación: Su objetivo es proteger a la BD contra fallos (lógicos o físicos) que
destruyan su contenido parcial o totalmente. Los SGBDs suelen incluir los llamados
"ficheros de log" en los que se almacenan todos los cambios antes de almacenarlos en
la BD, así como, marcas de comienzo y final de transacción. A partir de ellos, el SGBD
puede decidir después de un fallo, si una transacción estaba terminada o no y, por tanto
si hay que mantenerla o deshacerla.
Normalización: Según el modelo relacional, las tablas deben definirse siguiendo una
serie de reglas precisas para asegurarse de que no se producirán anomalías en la
actualización de la base de datos. Para ello, es habitual que se necesite descomponer
las tablas iniciales en otras más simplificadas que no presenten dichos problemas. Este
proceso es lo que se conoce como normalización y es un método formalizado con
diferentes niveles, a cada uno de los cuales se le llama forma normal.
Middleware: Véase Escenarios Globales
Características de extensibilidad de los SGBD
Los SGBDs deben reunir una serie de características que contemplen las nuevas
funcionalidades que deben proporcionar en estos momentos. Dichas características son:
Soporte ODBC
ODBC (siglas que significan Open DataBase Conectivity, Conectividad Abierta de Bases
de Datos) se define como un método común de acceso a bases de datos, diseñado por
Microsoft para simplificar la comunicación en Bases de Datos Cliente/Servidor. ODBC
consiste en un conjunto de llamadas de bajo nivel que permite a las aplicaciones en el
cliente intercambiar instrucciones con las aplicaciones del servidor y compartir datos, sin
necesidad de conocer nada unas respecto a las otras. Las aplicaciones emplean
módulos, llamados controladores de bases de datos, que unen la aplicación con el
SGBD concreto elegido. Se emplea el SQL como lenguaje de acceso a los datos. El
SGBD debe proporcionar los controladores adecuados para poder ser empleados por
los distintos lenguajes de programación que soporten ODBC.
Orientación a objetos
Los SGDBs relacionales tradicionales sólo pueden almacenar y tratar con números y
cadenas de caracteres. Las mejoras en el terreno de la multimedia obligan a que las
10
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
aplicaciones desarrolladas actualmente precisen cada vez más almacenar, junto con la
información númerica y de caracteres, tipos de datos más complejos que permitan
gestionar objetos de sonido, imágenes, vídeos, etc. Algunos SGBDs relacionales
avanzaron en este sentido dando cabida en sus BDs a tipos de datos binarios (donde se
puede guardar código binario, que es el que forma los objetos de sonido, imágenes,
programas ejecutables, etc.), pero esto no es suficiente. La aparición de SGBDs
relacionales Orientados a Objetos (SGBDROO) proporcionan toda la potencia y
robustez de los SGBD relacionales, y al mismo tiempo, permiten gestionar objetos de un
modo nativo, así como los campos númericos y de caracteres que se han visto
recogidos tradicionalmente. Los SGBDROO cuentan con todas las posibilidades de un
motor de consultas SQL clásico, pero el lenguaje puede manipular tipos definidos por el
usuario, de la misma manera que gestiona los tipos predefinidos de los sistemas más
antiguos. Por lo tanto, se trata de un SGBD relacional, pero extendido y ampliado de
manera que soporte la gestión de objetos. Por otra parte, la tendencia a la generación
de aplicaciones distribuidas, donde los usuarios, datos y componentes de la aplicación
están físicamente separados, facilita e impulsa el uso de SGDROO, pues los objetos y
las aplicaciones distribuidas están "hechos el uno para el otro".
Conectividad en Internet
Los distintos SGDBs existentes incorporan en sus últimas versiones software de tipo
middleware (capa de software que se sitúa sobre el SGBD) para añadir conectividad a la
base de datos a través de Internet. Microsoft ha desarrollado los ADO (Access Database
Object, Objetos de Acceso a Bases de Datos) que, incorporados en scripts dentro de
páginas Web en HTML, proporcionan conexión con Bases de Datos, tanto locales como
remotas, empleando ODBC. Los middleware desarrollados en los distintos SGBDs
suelen emplear ODBC ( o JDBC, conectividad abierta de bases de datos preparada para
el lenguaje Java) para conectar con la BD, junto con diversos conjuntos de herramientas
para facilitar al usuario la implementación de la comunicación con la BD a través de
Internet.
Soporte de estándares objetuales
Hay varios estándares de objetos diseñados para proporcionar una guía en el diseño y
desarrollo de aplicaciones distribuidas que trabajen con BD relaciones con orientación a
objetos. Los SGBDs actuales hacen uso de software del tipo middleware que asumen
las tareas de servicio de transacciones de objeto siguiendo alguno de los estándares de
objetos existentes. Los principales estándares de objeto son:
11
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
CORBA (Common Object Broker Architecture, o Arquitectura común de gestores de
solicitudes de objetos), del Object Management Group (OMG).
DCOM (Distributed Component Model) de Microsoft.
Java Remote Method Invocation de Sun.
Los actuales SGBD proporcionan soporte, como mínimo, a CORBA y DCOM.
Data Mining, Data Warehousing, OLAP
Los SGBD deben incorporar una serie de herramientas que permitan, de forma cómoda,
sencilla e intuitiva, la extracción y disección-minería de datos (Data Mining), y soporte
para OLAP (OnLine Analytical Processing, Procesamiento Análitico de Datos En Vivo),
que
se traa de una categoría de las nuevas tecnologías del software que permite obtener y
extraer información mediante un complejo análisis y procesamiento del contenido de
una Base de Datos, todo ello en tiempo real.
También deben proporcionar una escabilidad y robustez cada vez mejores, que
permitan mejorar los almacenes de datos (Data Warehousing), mercados de datos (Data
Marts) y Webs de datos, procesos de transacciones y otras aplicaciones de misión
crítica.
.- Características de los SGBDs relacionales
Basados en el modelo relacional los datos, y también empleados en modelos
transaccionales, se describen como relaciones que se suelen representar como tablas
bidimensionales consistentes en filas y columnas. Cada fila de la relación(o tupla, en
terminología relacional) representa una ocurrencia. Las columnas (o atributos)
representan propiedades de las filas. Cada tupla se identifica por una clave primaria o
identificador.
Esta organización de la información, permite recuperar de forma flexible los datos de
una o varias tablas, así como combinar registros de diferentes tablas para formar otras
nuevas. No todas las definiciones posibles de tablas son válidas según el modelo
relacional. En él, deben emplearse diseños normalizados que garantizan que no se
producirán anomalías en la actualización de la BD. En un diseño normalizado para cada
tabla:
 No pueden existir tuplas duplicadas.
 El orden de las tuplas es irrelevante.
 La tabla es plana, es decir, en el cruce de un atributo y una tupla solo puede
haber
 un valor (el orden de los atributos no es significativo).
12
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Para asegurar la integridad de los datos, se definen uno o más atributos de una tabla
como clave candidata, única y no nula, de modo que no pueden haber filas con dicha
clave duplicada. De entre las posibles claves candidatas escogeremos una como clave
primaria.
Las BD relacionales deben cumplir, además, como mínimo las tres primeras formas
normales
(FN) fundamentales definidas por Codd. Una relación está en 1FN si no contiene grupos
repetitivos. Estará en 2FN si no hay nada fuera de la clave que dependa de parte de la
clave. Por último, una relación está en 3FN si si no hay nada no clave que dependa de
algo no clave.
De todas formas otras consideraciones, principalmente de rendimiento, llevan en
ocasiones a que los diseños que se implantan no estén totalmente normalizados. Hallar
el punto de equilibrio entre normalización y rendimiento es, con frecuencia, un punto
clave para obtener un buen diseño de la BD cuando se utilizan SGBDs relacionales.
Los SGBDs relacionales se han impuesto hasta llegar a dominar casi totalmente el
mercado actual. Ello se ha debido principalmente a su flexibilidad y sencillez de manejo.
Igualmente conviene destacar la amplia implantación del lenguaje SQL que se ha
convertido en un estándar para el manejo de datos en el modelo relacional lo que ha
supuesto una ventaja adicional para su desarrollo. Además, los SGBDs objetuales
emplean de manera subyacente un SGBD relacional.
Arquitectura de implantación de un SGBD
Un SGBD se puede implantar en una organización siguiendo distintas arquitecturas. En
esta guía consideraremos tres escenarios de arquitectura: centralizada, distribuida y
cliente/servidor.
No debe confundirse el SGBD con la arquitectura que se elige para implantarlo. Algunos
SGBD sólo se pueden implantar en una de las arquitecturas y otros en todas ellas.
La arquitectura centralizada es la más clásica. En ella, el SGBD está implantado en una
sola plataforma u ordenador desde donde se gestiona directamente, de modo
centralizado, la totalidad de los recursos. Es la arquitectura de los centros de proceso de
datos tradicionales. Se basa en tecnologías sencillas, muy experimentadas y de gran
robustez.
En la arquitectura distribuida el SGBD y la BD no están asociados a un determinado
ordenador, sino a una red cuyos nodos se reparten las funciones. Una base de datos
distribuida es vista por las aplicaciones igual que si fuera centralizada. Es el SGBD
distribuido el que se encarga de preservar la integridad y coherencia de la BD. Sin
embargo existe otra definición mucho menos estricta de base de datos distribuida
utilizada por muchos fabricantes de SGBD, según la cual una base de datos es
distribuida si permite lecturas y modificaciones remotas, independientemente de que
13
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
éstas sean transparentes o no para las aplicaciones. Esta definición no es adecuada
cuando se desea seleccionar una BD realmente distribuida.
Se suele distinguir entre sistemas homogéneos y heterogéneos. Un sistema es
homogéneo si el SGBD usado en todas las máquinas es el mismo. Si existe más de un
SGBD distinto el sistema se denomina heterogéneo.
Ventajas e inconvenientes de los SGBD
La instalación de un SGBD en un sistema que está funcionando sin él, normalmente
proporciona una amplia serie de ventajas. Entre las más importantes se pueden
destacar:


















Eliminan las inconsistencias en los datos. Algo especialmente difícil sin un SGBD
cuando los mismos datos se utilizan y actualizan en diferentes procesos.
Permiten compartir los mismos datos entre diferentes aplicaciones con distintas
necesidades. Por ejemplo: aplicaciones transaccionales junto con aplicaciones de
soporte a la dirección.
Se adaptan mejor a la existencia de aplicaciones rápidamente cambiantes. En
estos casos con los enfoques tradicionales se puede requerir la conversión de los
datos cada vez. Un SGBD proporcionará independencia de los datos respecto a
las
aplicaciones.
Ahorran espacio de almacenamiento al no existir redundancia o ser ésta escasa.
También porque muchos SGBDs utilizan mecanismos de compresión para
almacenar
los datos.
Mejoran la seguridad de los datos pues normalmente incorporan mecanismos de
seguridad en el propio SGBD.
Permiten la creación de entornos de alta disponibilidad. Los SGBDs modernos
suelen permitir realizar gran parte (a veces todo) del mantenimiento del sistema
sin
necesidad de parar las aplicaciones. Por tanto, con algunos SGBDs es posible
llegar
a disponer de aplicaciones funcionando ininterrumpidamente.
Por otra parte, si se escoge adecuadamente el SGBD no suelen presentarse problemas
de tipo técnico que no se presenten con los sistemas anteriores de almacenamiento de
datos sino que los problemas suelen ser los típicos de cualquier equipo lógico complejo:
 La puesta en funcionamiento puede ser larga. Pues antes de obtener los
primeros
 resultados se necesita un período de formación y adaptación variable según la
 complejidad del entorno.
14
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
 Se necesita personal especializado para su mantenimiento. En principio un
 diseñador de la BD y un administrador permanente de la BD.
Tendencias tecnológicas y del mercado
En la tecnología actual de SGBDs relacionales se observan las siguientes tendencias.
 Los datos siguen estando centralizados en cuanto a modelado y administración
 mientras que el desarrollo de aplicaciones se descentraliza o se distribuye a
través
 de Internet.
 Los usuarios finales acceden a las BDs con mayor facilidad (existencia de
 productos en el mercado), incrementándose la seguridad en el acceso, sobre
todo si
 es a través de servicios de Internet.
 El ordenador central pasa de soportar los procesos de manera centralizada a ser
un
 servidor de datos. Los procesos pasan a máquinas clientes, o se distribuyen a los
 usuarios finales via Internet/Intranet.
 Nuevas herramientas para gestión y soporte de las nuevas tendencias respecto al
 almacenamiento de datos (Data Mining, Data Warehousing) o respecto al
 procesamiento de los datos (OLAP, OnLine Transaction Processing).
En cuanto a los SGBDs distribuidos, aunque no hay estándares definidos, existen en el
mercado algunos productos que incorporan características de estos SGBDs.
Los SGBD relacionales orientados a objetos
Una vez ya desarrolados los SGBD orientados a objetos, surge la necesidad de un
SGBD que, aparte de soportar la orientación a objetos, tenga la robustez y capacidad de
procesamiento de información de los SGBD relacionales. De esta manera aparecen los
SGBD relacionales orientados a objetos, ya tratados anteriormente, pero que todavía se
encuentran en fase de expansión, tanto en su uso como en sus posibilidades de integrar
distintos paradigmas pertenecientes a la Orientación a Objetos.
Por otra parte, entre los temas en los que se está trabajando para la próxima versión de
SQL (SQL3) se encuentra el soporte de bases de datos orientadas a objetos. También
existen varios fabricantes de SGBD relacionales que están incorporando, lentamente,
capacidades de orientación a objetos en sus SGBD, abriendo así otra vía al desarrollo
de SGBD orientados a objetos que parece muy prometedora en un futuro muy próximo.
15
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Los SGBD activos
Otra de las novedades es el desarrollo de los SGBD activos. A diferencia de los SGBD
orientados a objetos que constituyen un nuevo diseño del modelo de datos, los SGBD
activos son un refinamiento de los sistemas existentes que intenta almacenar la
semántica de los datos además de los propios datos. Podemos definir un SGBD activo
como aquel que,
cuando se producen ciertas condiciones predefinidas, ejecuta de forma automática, es
decir, sin la intervención del usuario, una serie de acciones (denominadas disparadores,
reglas, etc.) especificadas de antemano en la fase de definición de la base de datos.
Los SGBD activos están, en parte, "dirigidos por los datos" en lugar de estar dirigidos
exclusivamente por programas como los actuales. La lógica de control se codifica en
reglas almacenadas en la base de datos en lugar de en los propios programas.
Las principales ventajas de los SGBD activos son las siguientes:
 Simplifican los programas al descargarlos de aquellos controles que, en realidad,
forman parte de la semántica de los datos.
 Consiguen una mayor productividad y un menor mantenimiento ya que las reglas
se almacenan y, si es necesario, se modifican una sola vez en el diccionario de la
base de datos en lugar de hacerlo en cada programa.
 Reducen el tráfico de red pues al almacenar parte de los procedimientos en los
 servidores se limita la cantidad de información que éstos deben devolver.
 Facilitan el acceso a la base de datos por los usuarios finales al almacenar las
 reglas de actualización en el propio SGBD. Este podrá preservar la integridad de
los
 datos independientemente de cuál sea el método de acceso empleado lo que
permite
 a los usuarios finales acceder sin peligro de dañar la base de datos.
OLE DB .-Se trata de la siguiente generación de ODBC, donde se hace mayor hincapié
en el soporte de objetos y en mejorar la conectividad y la transparencia de conexión
entre el SGDB y las aplicaciones que hacen uso de la base de datos. Los objetos OLE
DB proporcionan la ventaja de poder acceder y manipular la información existente en la
BD sin ni siquiera emplear SQL, simplemente empleando objetos y colecciones de
objetos que se pueden tratar como tales dentro del código de la aplicación generada.
SQL3.-SQL3 es, como se ha mencionado, la próxima versión de SQL. En este momento
está en estudio por el grupo correspondiente de ISO (ISO/IEC JTC1/SC21 WG3 DBL) y
se espera que sus trabajos finalicen a finales de 1999. SQL3 soportará, entre otras, las
extensiones necesarias para bases de datos orientadas a objeto y bases de datos
activas.
16
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
ASPECTOS TECNICOS DEL PROCESO DE ADQUISICION DE SISTEMAS DE
GESTION DE BASES DE DATOS
En este capítulo se pretende dar la orientación suficiente al comprador para la
preparación del conjunto de especificaciones que definirán los requisitos que han de
cumplir los servicios de gestión de bases de datos objeto de la adquisición.
Se realiza en primer lugar un análisis de las necesidades del comprador, a continuación
se recogen los factores relevantes a tener en cuenta en el proceso de adquisición y,
finalmente, se describe cómo deben ser planteadas las especificaciones técnico funcionales para la elaboración del Pliego de Prescripciones Técnicas, qué normas,
estándares y cláusulas tipo pueden ser de aplicación, y cuál es el cuestionario técnico
diseñado para normalizar las ofertas y facilitar su evaluación.
Antes de comenzar el proceso de selección de un SGBD, se deben establecer con la
máxima aproximación posible los requisitos que se deben satisfacer mediante su
instalación. A continuación se van a detallar varios puntos a tener en cuenta en este
análisis.
Modelo de datos y arquitectura de implantación específica
Actualmente, la práctica totalidad de las instalaciones se están realizando con SGBDs
relacionales, instalados bien en modo centralizado, bien en modo cliente/servidor y, en
pocas ocasiones, arquitecturas distribuidas. Esta es sin duda la solución más
conveniente casi siempre y la que proporcionará un mayor número de posibilidades de
elección.
Dimensionamiento de la BD
El SGBD deberá garantizar que es capaz de manejar el volumen de datos requerido.
Para ello, deberá comprobarse que es adecuado en cada uno de los siguientes puntos:






Número total de bases de datos que se van a crear.
Número total de tablas por base de datos.
Numero máximo de filas por tabla.
Longitud máxima de fila.
Número máximo de índices por tabla.
Número máximo de campos por índice.
Rendimiento transaccional exigible
Si se va a utilizar el SGBD en un entorno transaccional se deberá conocer cuál es la
carga (en transacciones por segundo o por minuto) que deberá soportar el sistema y
también, se debe indicar cual es el tiempo de respuesta aceptable (máximo y medio).
17
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Plataforma/s sobre la/s que debe funcionar
Se deberá especificar la plataforma o plataformas, físicas y lógicas, sobre las que debe
funcionar el SGBD. Para cada una se deberá especificar, al menos, el fabricante,
modelo y sistema operativo (especificando el número de versión).
Tipo de información que se va a tratar
Todos los productos incluyen soporte para una serie de datos básicos: alfanuméricos,
numéricos (enteros y decimales), empaquetados, lógicos y fecha. Según las
necesidades específicas de cada caso se deberá exigir el soporte de tipos de datos
especiales tales como: gráficos, información textual, etc.
Acceso a los datos
Para el acceso a los datos debería evaluarse además del acceso desde el lenguaje
propio del SGBD (si existe), la existencia de herramientas de usuario final tales como
generadores de informes, formularios de entrada de datos, etc. También, la posibilidad
de acceder desde los lenguajes que se estén utilizando previamente como COBOL,
PL/I, etc., que suelen estar soportados por medio de precompiladores.
Se debe tener en cuenta que el lenguaje SQL es el único modo estandarizado de
acceso a los datos en BDs relacionales, por lo que es especialmente deseable que esté
soportada la versión normalizada de dicho lenguaje.
También es muy importante que el SGBD proporcione los controladores y utilidades
ODBC necesarios para acceder a la base de datos por esta vía.
Es conveniente que se proporcionen herramientas para facilitar el acceso a la
información de la BD via Internet/Intranet/Extranet.
Integración en el entorno existente
Si la buena integración de cualquier producto informático con el resto de la instalación
es siempre una materia de gran importancia, en el caso de un SGBD es absolutamente
imprescindible dadas sus características como almacén integrado de datos.
Aunque todo SGBD suele tener alguna herramienta de desarrollo propia, en las
instalaciones con desarrollos previos es importante examinar si se podrá acceder a la
base de datos con las antiguas herramientas y a que coste. Este punto determinará en
18
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
gran medida si es posible integrar las aplicaciones antiguas con el SGBD. También es
necesario preparar la migración de los datos del soporte antiguo a la BD y evaluar el
coste en recursos y de personal que supondrá.
Otro factor importante es la integración del SGBD con el sistema operativo en que se
vaya a instalar, por ejemplo, su integración con las herramientas estándar de seguridad
del sistema operativo o su capacidad para aprovechar las facilidades de los monitores
de teleproceso instalados.
Si se tiene intención de exportar o importar periódicamente los datos a otras plataformas
o productos, se debe asegurar que el SGBD soporta directamente esta facilidad, por
ejemplo, creando ficheros ASCII para tratarlos desde PC. no debe olvidarse que es cada
vez más habitual que una organización tenga distintos modelos de SGBD y/o un SGBD
en varias plataformas distintas. Por tanto, se debe estudiar la capacidad de comunicarse
entre sí de todos ellos. Para ello es fundamental que el SGBD seleccionado soporte los
estándares del mercado.
Herramientas de administración
El número de las herramientas a disposición del administrador de la base de datos suele
ser muy variable según el SGBD. Se deberá tener en cuenta que es frecuente que parte
de ellas se comercialicen como opciones separadas.
Típicamente existirán herramientas para crear la base de datos, definir la estructura
física, cargar los datos a partir de ficheros secuenciales externos y viceversa, copias de
seguridad, utilidades para reorganizar la base de datos para mejorar su eficiencia,
aumentar o reducir su tamaño, etc.
Se debe valorar la existencia de herramientas para gestionar la seguridad, de
monitorización y de obtención de estadísticas (de utilización, consumo, rendimiento...) .
Características de multiproceso
En entornos donde se requiere un alto rendimiento puede ser interesante que el SGBD
soporte multiproceso. Esto permite que una BD sea accedida por varios procesos que
están ejecutándose a la vez en distintos procesadores y, por tanto, evita las
contenciones debidas a sobrecarga del procesador.
Conectividad y comunicaciones
Cuando se necesite poder acceder a BDs situadas en varias máquinas, habrá que
asegurarse que el SGBD es capaz de hacerlo o que se incluye el producto adecuado
19
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
que lo permite. Igualmente, se debe comprobar que funciona con el protocolo de
comunicación bajo el que se desea trabajar.
Factores relevantes en el proceso de adquisición
En la definición del objeto del contrato y los requisitos inherentes al mismo, así como en
la valoración y comparación de ofertas de los licitadores pueden intervenir muchos
factores y de muy diversa índole.
Es de suma importancia que todos los factores relevantes que intervienen en el proceso
de contratación queden debidamente recogidos en el pliego de prescripciones técnicas
que regule el contrato. Así mismo, es conveniente que las soluciones ofertadas por los
licitadores sean recogidas en los cuestionarios disponibles a tal efecto:
 De empresa
 Económicos
 Técnicos particulares
Se van a relacionar a continuación algunos de los factores que suelen tener mayor peso
al seleccionar un SGBD. Sin embargo, debe tenerse en cuenta que la importancia de
cada factor variará en función de cada caso particular, por lo que siempre será
necesario identificar la importancia relativa de cada punto.
Pruebas en condiciones reales
Como se ha expresado anteriormente, el rendimiento real de un SGBD es muy difícil de
predecir mediante procedimientos teóricos. Por ello, si se va a instalar una BD que
contendrá un gran volumen de datos o, si por cualquier otra razón, existen dudas sobre
la capacidad del SGBD de dar unas prestaciones adecuadas en las máquinas
disponibles se debe exigir al suministrador una prueba anterior a la adquisición del
SGBD. Esta prueba debe realizarse en la propia instalación de destino.
La prueba se debería realizar en las condiciones más parecidas a las reales que se
puedan conseguir. Para ello se deberá cargar la BD con un volumen de datos adecuado
y se deberán crear procesos de prueba similares a los más costosos de los que se
vayan a desarrollar. Igualmente, se debe realizar en un momento en que la carga del
ordenador sea la normal (no en horas de poca utilización) e intentando simular el acceso
de un número de usuarios parecido al esperado.
Durante la prueba se deberán evaluar conceptos objetivos fácilmente medibles. Como
ejemplos se pueden mencionar el tiempo de respuesta, el tiempo de realizar una copia
20
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
de respaldo, la ocupación de disco real en kBytes y cualquier otro que se considere
crítico en la instalación.
Volumen y organización de los datos
Debe estar garantizado que el SGBD es capaz de tratar el volumen de datos que se
vaya a necesitar en la instalación. Para ello debe verificarse no sólo que el SGBD
puede manejar el volumen total de datos, sino que no existe ninguna limitación que
impide organizarlo de la forma más conveniente. Como ejemplo, se pueden señalar
limitaciones al número total de bases de datos, de tablas por base de datos, de filas por
tabla o de índices por tabla. La importancia de las limitaciones en cada uno de estos
puntos debe evaluarse por separado.
Rendimiento transaccional
Se debe comprobar que el SGBD puede efectuar la cantidad necesaria de
transacciones por unidad de tiempo para proporcionar a los usuarios un tiempo de
respuesta adecuado. En general este punto es difícil de definir teóricamente. En primer
lugar porque la información necesaria para calcular la carga de transacciones que
deberá soportar el sistema es compleja y difícil de obtener y, en segundo lugar porque
las medidas de transacciones por segundo que ofrecen los distintos fabricantes no
siempre son comparables.
Además el rendimiento de un mismo SGBD es ampliamente variable según las
características de la máquina en la que esté instalado (capacidad y velocidad de los
discos, cantidad de memoria, potencia de la UCP, etc).
Por todo ello, lo más conveniente suele ser diferir la resolución sobre este punto hasta
que se pueda comprobar experimentalmente realizando una prueba en la propia
instalación.
A pesar de lo comentado, existen varias pruebas de rendimiento (benchmark) estándar
que ofrecen datos útiles. Los más interesantes para SGBDs son los del Transaction
Processing Performance Council, organismo fundado en 1988 al que pertenecen más
de cuarenta fabricantes de plataformas físicas y lógicas de bases de datos, que ha
definido especificaciones de benchmarks estándar para sistemas de proceso de
transacciones en entornos comerciales.
A continuación, se relacionan dichas pruebas de rendimiento:
21
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Dimensionamiento de la plataforma de instalación
De lo comentado en los dos puntos anteriores puede deducirse que existe la posibilidad
de que sea necesario redimensionar la máquina en la que se instale el SGBD. En la
medida de lo posible se debe intentar prever esta necesidad, especialmente en cuanto a
las necesidades de memoria principal y capacidad de los dispositivos de
almacenamiento secundario, que son los factores críticos más habituales.
Reconversión o sustitución de las aplicaciones existentes
Se debe intentar calcular las necesidades que se presentarán por este motivo y el coste
que supondrán.
Formación y reconversión del personal
Este es un factor que de no programarse adecuadamente puede constituir un importante
cuello de botella al iniciar la operación del sistema. Por lo tanto, se debería planificar la
forma en la que el personal involucrado reciba la formación necesaria previa a la puesta
en marcha del SGBD. Además de los usuarios finales y usuarios informáticos existirá un
perfil de administrador y un perfil de diseñador.
Módulos que componen el SGBD
Los SGBD suelen necesitar varios módulos que se venden como productos
independientes, para alcanzar su plena funcionalidad. Por lo tanto, en el pliego de
22
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
condiciones se debe especificar que las funcionalidades a cubrir por el SGBD deben
estar totalmente cubiertas por los módulos ofertados.
Igualmente se debe exigir que se detalle cuáles son las funcionalidades que cubre cada
módulo y, para cada uno de ellos, cuáles de los otros son un prerrequisito para poder
utilizarlo. Uno de los módulos más importantes es aquél que permita al SGBD
comunicarse con otras bases de datos remotas a través de redes de comunicaciones.
Licencias de Explotación y Desarrollo
Es posible que para algunos o todos los módulos ofertados existan dos versiones
distintas. Una versión completa conocida normalmente como versión de 'Desarrollo' y
otra con alguna de las funcionalidades restringidas o inexistentes, usualmente llamada
versión de 'Explotación' o 'Producción' (a veces se utiliza Runtime).
Es necesario que el suministrador detalle cual de las dos versiones está ofreciendo para
cada una de las licencias que se compren y si alguna de ellas fuese una versión
limitada, que especifique claramente cuales de las funcionalidades ofertadas no se
encuentran presentes en la versión restringida.
Condiciones económicas y del soporte
Existen actualmente varios sistemas de cobro por el uso de SGBDs según el fabricante.
Los más utilizados son facturar por:




Cada máquina en la que se instale.
Cada usuario que acceda al SGBD.
Una combinación de los dos anteriores.
Por tiempo de utilización.
Es imprescindible que el suministrador indique con toda claridad el método utilizado.
También debe explicitarse que, salvo indicación en contrario, todas las licencias son de
versiones completas sin ninguna restricción respecto a las funcionalidades ofertadas.
También es conveniente pedir los precios de los productos adicionales que no se desee
instalar en el momento pero que puedan ser interesantes en el futuro.
Otro factor importante es la duración de la garantía, período de tiempo durante el que el
suministrador proporcionará soporte gratuito a sus productos y, también el precio del
soporte en años sucesivos. Este último precio debe fijarse sobre variables presentes en
el contrato no sobre futuros precios de lista del fabricante.
23
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Otro factor que debe evaluarse es la calidad del soporte ofrecido. Este puede dividirse
en un gran número de puntos cuya importancia variará en función de las necesidades
del comprador. Entre ellos, se pueden citar:
 La inclusión o no de la instalación en el precio del producto.
 El tiempo máximo de entrega.
 La inclusión o no de prestaciones adicionales gratuitas como puede ser un cierto
número de horas de formación.
 Capacitación y experiencia del personal que presta soporte técnico y consultoría.
 Calidad de la documentación, idioma en que está escrita, número de copias
suministradas gratuitamente y precio de las copias adicionales.
 Capacidad técnica de la empresa y de la asistencia técnica que presta para lo
que es recomendable pedir referencias a otros usuarios de la Administración de
este tipo de productos.
Diseño del pliego de prescripciones técnicas particulares
En la Guía para la Tramitación de Adquisiciones de Bienes y Servicios Informáticos se
recogen recomendaciones de carácter general para la elaboración de los Pliegos de
Prescripciones Administrativas y Técnicas, así como para la evaluación y selección de
ofertas.
Véase Guía de Tramitación
En el pliego de prescripciones técnicas se deben indicar aquellas consideraciones que,
extraídas del proceso de análisis de necesidades efectuado previamente, van a
determinar las características y requisitos del objeto de nuestro contrato y en el caso
particular de SGBDs de propósito general deberán contemplar aspectos tales como:





Plataforma (modelo) y sistema operativo (versión).
Tipo de gestor elegido.
Número de usuarios concurrentes que debe soportar.
Tamaño y número de los registros a gestionar.
Cumplimiento de estándares.
Existe un grupo de trabajo dentro de ISO específicamente dedicado a la normalización
dentro del terreno de las bases de datos. Se trata del grupo ISO/JTC1/SC21/WG3 que
es el responsable de la mayoría de los estándares existentes en el tema. Actualmente,
está elaborando las especificaciones de SQL3.
24
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
Las normas y estándares aplicables a los SGBD podrán ser los siguientes:



















Lenguaje SQL:
ISO/IEC 9075 (1987). "Database Language SQL".
ISO/IEC 9075 (1989). "Database Language SQL with Security
enhancements".
ISO/IEC 9075 (1992). "Database Language SQL" (conocido como SQL2).
Arquitectura de los SGBD:
ANSI/X3/SPARC (1977). "DBMS Framework".
ANSI/X3/SPARC DBTG (1986). "Reference model for DBMS
Standardization".Incorpora el anterior añadiendo la interconexión de
sistemas abiertos y las bases de datos distribuidas.
ANSI/X3/SPARC DBTG (1988). "Reference model for DBMS User
Facility".
Bases de datos distribuidas:
ISO DIS 9579 partes 1 y 2 (1990). "Remote Database Access".
Diccionarios de recursos de Información:
ISO 10027 (1990a). "Information Resource Dictionary System (IRDS).
Framework".
ISO 10027 (1991b). "Information Resource Dictionary System (IRDS).
Services Interface".
Las cláusulas tipo aplicables podrán ser las siguientes:
 Cláusula de actualización tecnológica de equipos arrendados.
 Cláusula tipo de certificado de empresa registrada.
 Cláusula tipo de cliente más favorecido.
 Cláusula tipo de garantía de calidad.
 Cláusula tipo de normalización.
 Pruebas de eficiencia.
 Cláusula efecto año 2000, adquisiciones y servicios.
 Cláusula efecto año 2000, aplicable a mantenimiento de software
 Cláusula entrada en vigor de la Moneda Única Europea.
 Cláusula tipo de juego de caracteres.
Diseño del pliego de prescripciones técnicas particulares
En la Guía para la Tramitación de Adquisiciones de Bienes y Servicios Informáticos se
recogen recomendaciones de carácter general para la elaboración de los Pliegos de
Prescripciones Administrativas y Técnicas, así como para la evaluación y selección de
ofertas.
En el pliego de prescripciones técnicas se deben indicar aquellas consideraciones que,
extraídas del proceso de análisis de necesidades efectuado previamente, van a
determinar las características y requisitos del objeto de nuestro contrato y en el caso
particular de SGBDs de propósito general deberán contemplar aspectos tales como:
25
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA





Fecha de revisión: No
aplica
Fecha de elaboración:
Plataforma (modelo) y sistema operativo (versión).
Tipo de gestor elegido.
Número de usuarios concurrentes que debe soportar.
Tamaño y número de los registros a gestionar.
Cumplimiento de estándares.
Existe un grupo de trabajo dentro de ISO específicamente dedicado a la normalización
dentro del terreno de las bases de datos. Se trata del grupo ISO/JTC1/SC21/WG3 que
es el responsable de la mayoría de los estándares existentes en el tema. Actualmente,
está elaborando las especificaciones de SQL3.
Las normas y estándares aplicables a los SGBD podrán ser los siguientes:
Lenguaje SQL:
 ISO/IEC 9075 (1987). "Database Language SQL".
 ISO/IEC 9075 (1989). "Database Language SQL with Security enhancements".
 ISO/IEC 9075 (1992). "Database Language SQL" (conocido como
SQL2).arquitectura de los SGBD:
 ANSI/X3/SPARC (1977). "DBMS Framework".
 ANSI/X3/SPARC DBTG (1986). "Reference model for DBMS
 Standardization".Incorpora el anterior añadiendo la interconexión de sistemas
abiertos y las bases de datos distribuidas.
 ANSI/X3/SPARC DBTG (1988). "Reference model for DBMS User Facility".
 Bases de datos distribuidas:
 ISO DIS 9579 partes 1 y 2 (1990). "Remote Database Access".
 Diccionarios de recursos de Información:
 ISO 10027 (1990a). "Information Resource Dictionary System (IRDS).
Framework".
 ISO 10027 (1991b). "Information Resource Dictionary System (IRDS).
 Services Interface".
Cláusulas tipo aplicables
Las cláusulas tipo aplicables podrán ser las siguientes:









Cláusula de actualización tecnológica de equipos arrendados.
Cláusula tipo de certificado de empresa registrada.
Cláusula tipo de cliente más favorecido.
Cláusula tipo de garantía de calidad.
Cláusula tipo de normalización.
Pruebas de eficiencia.
Cláusula efecto año 2000, adquisiciones y servicios.
Cláusula efecto año 2000, aplicable a mantenimiento de software
Cláusula entrada en vigor de la Moneda Única Europea.
26
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
 Cláusula tipo de juego de caracteres.
Cuestionario técnico de normalización y valoración de ofertas de SGBD
El establecimiento en los pliegos de prescripciones técnicas de cuestionarios
predefinidos, que deben ser obligatoriamente cumplimentados e incorporados en las
ofertas, tiene como objetivo la normalización de las ofertas de las empresas licitadoras
de modo que se facilite y simplifique la comparación entre ellas.
Los cuestionarios, que de forma general deben acompañar a un pliego de contratación,
están estructurados de la siguiente forma:
1. Cuestinonarios comunes:
 De empresa
 De datos económicos
2. Cuestionario técnico particular
Estos cuestionarios tienen un carácter orientativo y abierto, es decir, podrán modificarse
para incluir o suprimir algunas cuestiones particulares, dependiendo de las
circunstancias de cada contratación. En cualquier caso, las normas recomendadas para
la constitución del conjunto total de cuestionarios y su cumplimentación por parte de los
oferentes se recogen dentro de la Guía de Tramitación al igual que los dos
cuestionarios comunes.
Cuestionario técnico de normalización y valoración de ofertas (cont.)
CUESTIONARIO TÉCNICO DE SISTEMAS DE GESTIÓN DEBASES DE DATOS DE
PROPÓSITO GENERAL
Con carácter general y a fin de utilizar la información recopilada de cara a la
contratación, es importante destacar que los datos recogidos en este cuestionario están
dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia
técnica o profesional de la empresa en aquellos casos en que no sea requerida la
clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando
esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato",
siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
CUESTIONARIO TÉCNICO DE SISTEMAS DE GESTIÓN DE BASES DE DATOS DE PROPÓSITO
GENERAL
Con carácter general y a fin de utilizar la información recopilada de cara a la
contratación, es importante destacar que los datos recogidos en este cuestionario están
dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia
técnica o profesional de la empresa en aquellos casos en que no sea requerida la
clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando
27
Negocios al estilo de AOL.
Responsable del Documento:
LIC.BADILLO VARGAS SARA
Fecha de revisión: No
aplica
Fecha de elaboración:
esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato",
siendo, en el resto de los casos, de carácter meramente informativo.
28