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