jueves, 20 de noviembre de 2014

Detectar Fallas en la PC



1. INICIO PROTOCOLO PRELIMINAR


2. MISSING OPERATING SYSTEM

Mensajes de error antes del arranque del sistema operativo:
  • Invalid partition table.
  • Error loading operating system.
  • Missing operating system.
Descripción: Estos errores se producen cuando el ordenador accede al sector de arranque para localizar al sistema operativo y poder arrancar, y se encuentra con información no válida, errores, datos ilegibles o simplemente es que no hay sistema operativo válido instalado.

Una de las formas de restaurar el sector de arranque es ejecutar la orden:
  • fdisk /mbr
También podemos intentar arrancar con un disco de inicio o con el CD de instalación de Windows y reparar el arranque, o bien en Linux reinstalando el gestor (Lilo o Grub).

3.HARD DISK DRIVE FAILURE

Descripción: El disco duro no está instalado correctamente, no está configurado correctamente en BIOS o está dañado. Este es un fallo serio, lo único que podemos hacer es comprobar que los cables y los jumpers del disco están colocados bien, que en BIOS se detecta y que no está dañado, para esto último podemos instalarlo en otro equipo o bien ponernos en contacto con el fabricante. Una de las opciones suele ser realizar un formateo a bajo nivel.

4. FALTA NTLDR

Descripción: Para solucionar el problema de Falta el archivo NTLDR hay seguir el procedimiento siguiente:

1.- Arrancar el pc con el disco de Windows XP metido.
2.- Cuando nos salga el asistente de instalación de Windows Xp elegir la opción de Reparar Sistema.
(En caso de que no salga el asistente significa que el sistema no ha podido arrancar desde el CD. Prueba a ponerlo en otra unidad y volver a arrancar).
Si sigue igual, entra en la BIOS y comprueba que la primera unidad en la secuencia de arranque es alguna de tus unidades de CD/DVD.
3.- Una vez que tengamos en pantalla el editor con C:\Windows, teclear 1 y pulsar Intro
4.- Nos pedirá la Clave de administrador. Si hemos puesto una clave la tecleamos. Si no hemos puesto clave pulsamos Intro.
5.- Una vez que estemos en C:\Windows teclear FIXMBR y pulsar Intro.
6.- El sistema nos advierte de que si queremos continuar y ponemos S y pulsamos Intro.

*Una vez que estamos en el punto 6, tenemos que copiar dos archivos, debido que en dicha pérdida se arrastra también otro que es el ntdetect, por lo tanto hay que copiar ntldr y ntdetect en nuestro disco duro.

Para ello escribiremos lo siguiente:
  • copy D:\i386\ntldr C:\
  • copy D:\i386\ntdetect.com C:\
(Donde D:\ sería la unidad lectora donde se encuentra el cd de Windows XP y C:\ es la unidad de arranque donde tenemos instalado Windows).
Si todo sale bien debería de funcionar.

Con respecto a este problema debemos tener unas cuestiones en cuenta:

Si el sistema anterior falla no tenemos más remedio que reinstalar Windows, pero eliminando la particion, volviendola a crear y formateando de nuevo (es recomendable utilizar el formateo normal, NO el formateo rápido. Con esto se perderan todos nuestros datos, por lo que es conveniente que tengamos una copia de estos.

NO es normal que se pierda este archivo, por lo que su pérdida es síntoma de un posible problema con el disco duro, sobre todo si el problema se repite con una cierta frecuencia.

5. BIOS ROM CHECKSUM ERROR Ó CMOS BATERY FAILED


Descripción: Estos errores están relacionados. El primero indica que hay un error en la suma de comprobación de la memoria de BIOS, normalmente el problema está en el agotamiento de la pila de la placa base, aunque también puede ser que la ROM del BIOS esté dañada. El segundo error significa que la pila de la placa base, que alimenta la memoria de BIOS, ha fallado. Normalmente con cambiar esta pila suele ser suficiente.

6. FLOPPY DISK FAIL

Descripción: Hay un fallo en la unidad de diskettes y no se puede acceder a ella. Hay que comprobar que el cable de datos está colocado bien, y no al revés. Si sigue marcando el error seguramente la unidad tiene un fallo físico y hay que cambiarla por una nueva.


7. KEYBOARD ERROR OR NOT PRESENT

Descripción: El BIOS no puede acceder al teclado por un fallo interno o porque no lo encuentra (no está conectado). Debemos comprobar que el conector está insertado firmemente y en la posición correcta.

8. X-Y HARD DISK FAIL

donde: X = Primary/Secondary
Y = master/slave

Descripción: El disco marcado como X Y ha fallado. Lo más grave se produce cuando el error es “Primary Master hard disk fail” ya que es el disco que contiene la partición de arranque y no podremos acceder a ningún sistema operativo. En caso de ser otros los dispositivos afectados, bastará con retirarlos del equipo para poderlo arrancar.

Este error puede significar varias cosas: los cables están mal conectados, el BIOS no lo detecta adecuadamente o simplemente hay un fallo físico. Podemos comprobar los cables y el BIOS, pero si hay un defecto físico probablemente no podamos hacer nada.

9. PROTOCOLO FALLOS DE WINDOWS

En este apartado se discuten posibles fallos que puede dar el sistema operativo Windows en su arranque y cómo actuar en algunos. 

Windows puede mostrar una gran cantidad de errores de todo tipo, tantos que en un documento no caben todos, de modo que vamos a resumir y ofrecer los errores más frecuentes y su posible solución (no todos se producen en todas las versiones de Windows).

- STOP 0x0000000A (IRQ_NOT_LESS_OR_EQUAL)
Descripción: Controladores incompatibles o corruptos, overclocking excesivo en FSB.

- STOP 0x0000001E (KMODE_EXCEPTION_NOT_HANDLED)
Descripción: Un proceso intenta ejecutar una instrucción no válida y el manejador de excepciones del núcleo lo ha detectado. Hay software con fallos graves, en controladores de dispositivos o en hardware.

- STOP 0x00000024 (NTFS_FILE_SYSTEM)
Descripción: Windows no puede acceder a la partición NTFS donde se ubican los ficheros. El disco duro está dañado o hay alguna parte corrupta en el sistema de ficheros.

- STOP 0x00000023 ó 0x00000024 (FAT_FILE_SYSTEM o NTFS_FILE_SYSTEM)
Descripción: Error en el archivo controlador de las operaciones de lectura y escritura sobre las particiones.

- STOP 0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA)
Descripción: Un proceso ha solicitado una página de una dirección de memoria inválida. Es probable que la memoria Ram esté defectuosa, o que el problema radique en alguna aplicación.

- STOP 0x00000077 (KERNEL_STACK_INPAGE_ERROR)
Descripción: El núcleo han solicitado una página de memoria y no ha podido ser leída. Probablemente se trate de un sector defectuoso en la zona del archivo de intercambio o un virus.

- STOP 0x0000007B (INACCESSIBLE_BOOT_DEVICE)
Descripción: Windows no puede encontrar la partición donde están sus ficheros. Esto puede ocurrir al cambiar la placa base o la controladora (SCSI), al pasar el disco a otro ordenador, etc...

- STOP 0x000000C2 (BAD_POOL_CALLER)
Descripción: Error en controlador o aplicación de inicio.

- STOP 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL)
Descripción: Error en un controlador (corrupto).

  • Al iniciar el dispositivo nombre de dispositivo. Error de protección de Windows.”
  • “Error de protección de Windows.”
Descripción: Un error de protección de Windows significa que se produjo un error al cargar o descargar un controlador de dispositivo virtual (VxD). En muchos casos podrá deducir a partir del mensaje de error qué VxD no se cargó o descargó. Pero en otros casos no podrá determinar qué VxD provocó el problema.
Solución: Primero se debe acceder al sistema en “Modo a prueba de fallos”. Una vez dentro se debe reinstalar Windows con el comando setup /p I.

  •  “El archivo siguiente XXXXX.XX falta o se dañó. Falta XXXXX.XXX. Asegúrese de que el archivo se encuentra en su directorio Windows. Windows ha detenido. Presione CTRL+ALT+SUPR para reiniciar el equipo.”
Descripción: Windows intenta cargar el archivo XXXXX.XXX necesario para el inicio pero hay problemas (fichero corrupto, no existente). La solución es extraerlo de nuevo desde el fichero CAB correspondiente del CD de instalación de Windows. Como hay muchos ficheros CAB, lo ideal es que busque en Internet la información sobre en qué CAB se encuentra el archivo que da problemas.

Hasta aquí una lista breve general de posibles errores en toda la familia de productos Windows. En algunos hemos detallado una posible solución, en los que no es porque hay que seguir un procedimiento general según:
  •  Controladores incompatibles, corruptos o dañados: hay que reinstalar el controlador dañado descargándolo desde la página del fabricante del dispositivo
  • Software o aplicación con fallos graves o dañado: un programa relacionado con funciones del inicio del sistema tiene problemas, la solución pasa por desinstalar la aplicación, limpiar el registro del sistema con un programa específico para ello y posteriormente instalar de nuevo la aplicación problemática.
En general, si conseguimos entrar en “Modo a prueba de fallos” o “Modo seguro” en un sistema Windows ME/XP podremos intentar “restaurar el sistema” a una fecha anterior, solución que aunque no esté garantizada, es una posibilidad más de actuación.


1.1 PROTOCOLO DISPOSITIVOS HARDWARE

Si hemos llegado hasta aquí es probable que exista algún problema físico con un dispositivo hardware, para ello debemos hacer varias cosas.

Lista de componentes NO esenciales disquetera; unidades de lectura CD, DVD y grabadoras; tarjeta de sonido, tarjeta de red, cualquier tarjeta en los puertos PCI (excepto la tarjeta gráfica), discos duros.

Lista de componentes esenciales (por orden de prioridad): procesador, memoria RAM y tarjeta gráfica.

Podemos actuar de 2 maneras, iniciar un proceso de localización del componente defectuoso o simplemente ver en la lista de “Averías”.

Inicio del proceso de localización del componente defectuoso: 

1 - Retirar todos los dispositivos no esenciales y arrancar el sistema.

2 - Comprobar que arranca correctamente. 

3 - Si no funciona, pasar al Anexo A; de lo contrario seguir en el punto 4. 

4 - Apagar el sistema. 

5 - Añadimos un dispositivo de los que habíamos retirado, encendemos el ordenador y comprobamos que arranca correctamente. Si arranca bien, repetir el punto 5 con el siguiente dispositivo. Si no arranca bien, seguir en el punto 6. Si añadimos todos los dispositivos y arranca bien pasar al punto 7. 

6 - Si acabamos de añadir un dispositivo y el sistema ya no arranca bien, debemos pensar que dicho dispositivo está defectuoso, tendremos que acudir a una tienda de informática para que lo reparen o bien comprar uno nuevo para reponerlo. 

7 - Si hemos añadido todos los dispositivos y ahora el ordenador arranca correctamente, podríamos pensar que había algún componente o cable mal conectado. Si ya funciona todo bien podemos dar por terminado el proceso, de lo contrario podemos consultar la lista de “Averías” que se comenta más adelante. 


Anexo A

Si estamos aquí es porque hemos retirado todos los dispositivos no esenciales y el sistema sigue sin arrancar. El problema debería estar en la placa base, procesador, memoria Ram o tarjeta gráfica.
Si ahora ya vemos algo en pantalla deberíamos volver al diagrama de averías inicial y verificar los errores; si el sistema sigue igual es porque tenemos :

- Error de procesador.
- Error de memoria RAM.
- Error de placa base.
- Error de tarjeta gráfica.

Averías que pueden ocurrir en los dispositivos y que suelen impedir el arranque:

Averías del procesador:
Este tipo de problemas pueden ser fatales e irreparables, afortunadamente tenemos casos frecuentes y algunos solucionables:

1 - El sistema no arranca por un exceso de temperatura en el procesador (comprobable con un sensor de temperatura): esto es frecuente con la práctica del “Overclocking”, en los meses de más calor o simplemente si el ventilador se estropea y ensucia.

Solución: si hemos aumentado artificialmente la frecuencia del procesador tendremos que reducirla de inmediato. En otro caso trataremos de limpiar bien los ventiladores y disipadores y nos aseguraremos de que funcionan.

2 - El sistema se bloquea con frecuencia: en este caso el aumento de frecuencia del procesador es suficiente para permitirle arrancar pero llega un momento en que la temperatura excesiva lo bloquea, acudir al punto anterior para solucionarlo.

3 - En caso de que no sea nada de lo anterior, sólo nos queda: probar el procesador en otro equipo, acudir al servicio técnico.

Averías en la memoria RAM:
Podemos tener varios problemas: zócalo donde se aloja la memoria está dañado, hemos instalado un módulo incorrecto o bien la memoria está defectuosa. En todos los casos sólo podemos limitarnos a extraer la memoria, limpiarla y volver a colocar. Si tenemos módulos defectuosos tendremos que cambiarlos. Se aconseja acudir a un servicio técnico.

Averías en la placa base

Una avería en la placa base suele ser irreparable, y la única solución pasa por cambiarla. Antes de eso se aconseja verificar al 100% que falla, podemos llevar el equipo a un servicio técnico o probarla en otro ordenador con componentes similares al nuestro.

Avería en BIOS

No es frecuente encontrar estos casos. El tipo de error más frecuente (en caso de ocurrir) es un fallo en la actualización del firmware del BIOS y el sistema ya no arranca. Este es un fallo muy grave y hay 2 únicas posibilidades:
  •  Cambiar la placa base.
  •  Reprogramar el chip que alberga la información corrupta. Este paso es muy complejo y siempre lo deben realizar en una tienda de informática / electrónica o bien el propio fabricante de la placa base.
Averías de tarjeta gráfica

No es común que una tarjeta gráfica sufra una avería física. Siempre debemos comprobar que está bien insertada en su puerto correspondiente (AGP, PCI, PCI Express), que el cable VGA del monitor encaja perfectamente con la salida de la tarjeta. Si vemos que con todos los pasos dados anteriormente la tarjeta parece culpable, tendríamos que probarla en otro ordenador. De no funcionar ahí tampoco podríamos sospechar de un fallo físico. Los fallos físicos suelen ser irreparables y se aconseja sustituir la tarjeta por otra nueva.

Averías en otras tarjetas o dispositivos

En general no se suelen producir fallos físicos en el hardware por eso siempre se piensa en ello en última instancia. Lo ideal cuando queramos comprobar si un dispositivo está estropeado en realidad, es probarlo en otro ordenador que tengamos disponible, o bien acudir a un servicio técnico.


1.2 PROTOCOLO POST

El POST (Power On Self Test) es una comprobación que hace el sistema de los dispositivos hardware. Si existen fallos o problemas la placa emitirá una serie de sonidos diferentes según el error. Para identificarlos es necesario disponer del manual de la placa bse (en algunos casos se puede descargar de la propia web del fabricante), en dicho manual se detallan en una tabla los pitidos y su significado.

Aquí reproducimos un ejemplo que sirve para la mayoría, pero no para todas las placas base.

Algunos de estos errores son solucionables de manera trivial: conexión de alimentación, comprobación de que la memoria RAM y/o tarjeta gráfica están bien insertadas. Pero incluso comprobando eso puede seguir habiendo errores internos de los dispositivos. En caso de enfrentarnos a un error intocable, lo mejor que podemos hacer es buscar a un especialista o acudir a una tienda de informática con nuestro equipo. Recuerde siempre consultar el manual de la placa base.



miércoles, 19 de noviembre de 2014

Seguridad en DB2

La seguridad de bases de datos es de extrema importancia actualmente. Las bases de datos en una empresa pueden permitir a los clientes comprar productos en Internet, o puede contener datos históricos usados para predecir tendencias de negocios; en cualquier caso, las compañías necesitan un plan de seguridad sólido para su base de datos.

Un plan de seguridad para base de datos debe definir:

  • Quién tiene permitido el acceso a la instancia y/o base de datos
  • Dónde y cómo se verificará la contraseña de un usuario
  • El nivel de autoridad que se concede a un usuario
  • Los comandos que tiene permitido ejecutar un usuario
  • Los datos que un usuario tiene permitido leer y/o alterar
  • Los objetos de base de datos que un usuario tiene permitido crear, alterar y/o descartar
DB2
El DB2 es un Gestor de Bases de Datos Relacionales. Es un sistema para administración de Bases de Datos Relacionales. Es multiplataforma, especialmente diseñada para ambientes distribuidos, permitiendo que los usuarios locales compartan información con los recursos centrales. Es el sistema de gestión de datos que entrega una plataforma de base de datos flexible y rentable para construir un sistema robusto para aplicaciones de gestión. 

Las tablas son el núcleo principal de una base de datos de DB2. Sin embargo, una base de datos deDB2 implica algo más que una colección de tablas; una base de datos de DB2 también implica otros objetos como, por ejemplo, vistas e índices, y contenedores de datos más grandes como, por ejemplo, espacios de tablas. 

La automatización es una de sus características más importantes, ya que permite eliminar tareas rutinarias y permitiendo que el almacenamiento de datos sea más ligero, utilizando menos hardware y reduciendo las necesidades de consumo de alimentación y servidores. 

La memoria se ajusta y se optimiza el rendimiento del sistema, con un interesante sistema que permite resolver problemas de forma automática e incluso adelantarse a su aparición, configurando automáticamente el sistema y gestión de los valores. 

DB2 para Linux, UNIX y Windows permite la automatización de tareas, reducción de las necesidades de consumo de alimentación, un alto rendimiento que reduce los servidores necesarios para ejecutar la base de datos, escalabilidad sencilla y alta disponibilidad en su arquitectura de discos de datos y otras soluciones que facilitan la colaboración entre profesionales.

El DB2 cuenta con las siguientes características:
  • Integridad: El DB2 incluye características de Integridad, asegurando la protección de los datos aún en caso de que los sistemas sufran un colapso, y de Seguridad permitiendo realizar respaldos en línea con distintos grados de granularidad, sin que esto afecte la disponibilidad de acceso a los datos por parte de los usuarios.
  • Múltiples usos: Provee la capacidad de hacer frente a múltiples necesidades, desde Procesamiento Transaccional de Misión Crítica (OLTP), hasta análisis exhaustivo de los datos para el soporte a la toma de decisiones (OLAP).
  • Escalabilidad: Sus características distintivas de Escalabilidad le permiten almacenar información en un amplio rango de equipos, desde un PC portátil hasta un complejo ambiente de mainframes procesando en paralelo.
  • Universalidad: DB2 es la única base de datos realmente universal; es multiplataforma (16 plataformas - de las cuales 10 no son de IBM), brinda soporte a un amplio rango de clientes, soporta el acceso de los datos desde Internet y permite almacenar todo tipo de datos:
  • Texto, Audio, Imágenes y Video
  • Documentos XML
Mecanismos de seguridad DB2

Existen tres mecanismos principales dentro de DB2 que permiten a un DBA implementar un plan de seguridad de base de datos: autenticación, autoridad y privilegios.

La Autenticación en DB2

La autenticación es el primer recurso de seguridad que se encuentra cuando se intenta acceder a una instancia o base de datos DB2. La autenticación DB2 funciona muy de cerca con los recursos de seguridad del sistema operativo subyacente para verificar los ID y contraseñas de usuario. DB2 también puede trabajar con protocolos de seguridad como Kerberos para autenticar usuarios.

La autenticación DB2 controla los siguientes aspectos del plan de seguridad de base de datos:
  • Quién tiene permitido el acceso a la instancia y/o base de datos
  • Dónde y cómo se verificará la contraseña de un usuario
Esto lo hace con la ayuda de los recursos de seguridad del sistema operativo subyacente cada vez que se emite un comando attach o connect . Los comandos attach se usan para conectar la instancia DB2, mientras que los comandos connect se usan para conectarse a una base de datos dentro de una instancia DB2.

Tipos de autenticación DB2

Los tipos de autenticación son usados por DB2 para determinar dónde tendrá lugar la autenticación. DB2 tiene la capacidad para especificar diferentes mecanismos de autenticación dependiendo de si el usuario está intentando conectarse con la base de datos o efectuar acoples de instancia y operaciones de nivel de instancia. De forma predeterminada, la instancia se configura para que use un tipo de autenticación para todas las solicitudes de nivel de instancia y de nivel de conexión

Autenticación KERBEROS: La autenticación Kerberos proporciona a DB2 una forma para autenticar usuarios sin tener que hacer pasar ID ni contraseñas de usuario sobre la red. El protocolo de seguridad Kerberos lleva a cabo autenticación como un servicio de autenticación externo, usando criptografía convencional para crear una clave secreta compartida. Esta clave se convierte en la credencial del usuario y se utiliza para verificar la identidad de los usuarios durante todas las veces que se soliciten servicios de red o locales. El uso del protocolo de seguridad Kerberos permite el uso de inicio único de sesión para un servidor remoto de base de datos DB2.

Autenticación SERVER: La autenticación se lleva a cabo en el servidor.

Autenticación SERVER_ENCRYPT: La autenticación se lleva a cabo en el servidor. Las contraseñas son cifradas en la máquina cliente antes de ser enviadas al servidor.

Autenticación CLIENT: La autenticación se lleva a cabo en la máquina cliente

Autenticación KERBEROS: La autenticación es llevada a cabo por el software de seguridad Kerberos.

Autenticación KRB_SERVER_ENCRYPT: La autenticación es llevada a cabo por el software de seguridad Kerberos si la configuración de cliente es KERBEROS. En caso contrario, se utiliza SERVER_ENCRYPT.

Autenticación DATA_ENCRYPT: La autenticación se lleva a cabo en el servidor. El servidor acepta el ID y las contraseñas cifradas del usuario y descifra los datos. Esto funciona de la misma forma que SERVER_ENCRYPT, excepto que los datos también son cifrados.

Autenticación DATA_ENCRYPT_CMP: La autenticación es la misma que para DATA_ENCRYPT, excepto que este esquema permite que clientes antiguos que el esquema DATA_ENCRYPT no permite, se conecten usando autenticación SERVER_ENCRYPT. En este caso los datos no serán cifrados. Si el cliente que se está conectando soporta DATA_ENCRYPT, es forzado a cifrar los datos y no puede pasarse a autenticación SERVER_ENCRYPT. Esta autenticación solo es válida en el archivo de configuración de gestor de base de datos del servidor y no es válido cuando se usa con el comando CATALOG DATABASE en una instancia de cliente o de gateway.

Autenticación GSSPLUGIN: La autenticación es controlada por un plug-in GSS-API externo.

Autenticación GSS_SERVER_ENCRYPT: La autenticación es controlada por un plug-in GSS-API externo. en el caso que el cliente no soporte alguno de los plug-in GSS-API del servidor, se utiliza autenticación SERVER_ENCRYPT.

Autoridades DB2

La autoridad involucra determinar las operaciones que los usuarios y/o grupos pueden efectuar y los objetos de datos a los que pueden acceder. La capacidad de un usuario para efectuar operaciones de alto nivel de administración de base de datos y de instancia, está determinada por las autoridades que se le hayan asignado. Existen cinco niveles de seguridad diferentes dentro de DB2 que son: SYSADM, SYSCTRL, SYSMAINT, DBADM y LOAD. La autorización es una parte importante del control de DB2. Los mecanismos de seguridad y autorización que controlan el acceso a datos de DB2 son directos e indirectos.

DB2 realiza comprobaciones de seguridad directas de los ID de usuario y las contraseñas antes de permitir que los usuarios obtengan acceso mediante el DDF. En todos los demás recursos de conexión, es necesario que el usuario se autentique con un DDF antes de conectar a DB2. Los mecanismos de seguridad de DB2 incluyen objetos específicos, privilegios sobre estos objetos y algunos privilegios que proporcionan una autorización más amplia. DB2 también controla indirectamente el acceso a datos mediante comprobaciones de autorización durante el tiempo de vinculación y el tiempo de ejecución para planes y paquetes de aplicaciones.

Por ejemplo, debe tener autorización para ejecutar sentencias de SQL que creen y modifiquen objetos deDB2. Incluso cuando los usuarios ejecutan una sentencia SELECT para consultar la información de una tabla, su autorización puede limitar lo que ven. El usuario puede ver únicamente los datos de un subconjunto de columnas definidas en una vista. Las vistas proporcionan una gran variedad de controles de seguridad.

Antes de emitir mandatos de DB2, ejecutar programas de utilidad, ejecutar paquetes y planes de aplicaciones o utilizar la mayoría de las demás funciones de DB2, necesita tener la autorización o el privilegio adecuados. Por ejemplo, para realizar cambios en una tabla necesita tener autorización para acceder a dicha tabla. Un privilegio permite una acción sobre un objeto. Por ejemplo, para insertar datos en una tabla se necesita el privilegio para insertar datos.

Las sentencias GRANT y REVOKE proporcionan control de acceso para objetos de DB2. Se pueden otorgar privilegios y autorizaciones a los ID de autorización y roles en numerosas combinaciones y también se pueden revocar.

Se puede utilizar el componente RACF o un producto equivalente para controlar el acceso a objetos de DB2. Esta es la mejor opción si desea que el administrador de seguridad de z/OS gestione el acceso a los datos en lugar del administrador de base de datos.

Las autoridades DB2 controlan los siguientes aspectos del plan de seguridad de base de datos:
  • El nivel de autoridad que se le concede a un usuario
  • Los comandos que tiene permitido ejecutar un usuario
  • Los datos que un usuario tiene permitido leer y/o alterar
  • Los objetos de base de datos que un usuario tiene permitido crear, alterar y/o descartar
Las autoridades están compuestas por grupos de privilegios y de operaciones de alto nivel, de mantenimiento y herramientas de gestor de base de datos (nivel de instancia). De las cinco autoridades disponibles en DB2, SYSADM, SYSCTRL, SYSMAINT, y SYSMON son autoridades de nivel de instancia. Eso significa que su alcance incluye comandos de nivel de instancia, así como comandos contra todas las bases de datos dentro de la instancia. Las autoridades DBADM, LOAD y SECADM se asignan a grupos o usuarios para bases de datos particulares.

Tipos de autoridades DB2

Autoridad SYSADM: La autoridad SYSADM en DB2 es comparable a la autoridad raíz UNIX o a la autoridad de Administrador en Windows. Los usuarios con autoridad SYSADM para una instancia DB2 pueden ejecutar cualquier comando DB2 contra esa instancia, cualquier base de datos dentro de la instancia y cualquier objeto dentro de esas bases de datos. Estos también tienen la capacidad para acceder a datos dentro de la base de datos y a conceder o revocar privilegios y autoridades. Los usuarios SYSADM son los únicos usuarios a los que se les permite actualizar el archivo DBM CFG, por lo que también son los únicos que tienen permitido conceder cualquiera de las autoridad SYS* a otros grupos.

Autoridad SYSCTRL: Los usuarios con autoridad SYSCTRL pueden ejecutar todos los comandos administrativos y de mantenimiento dentro de la instancia. No obstante, a diferencia de los usuarios SYSADM, estos no pueden acceder a ningún dato de las bases de datos, a menos que se les concedan los privilegios para hacerlo.

Autoridad SYSMAINT: Los comandos que puede ejecutar un usuario con la autoridad SYSMAINT son un subconjunto de los permitidos a los usuarios con la autoridad SYSCTRL. Los usuarios con SYSMAINT no pueden crear ni descartar bases de datos ni espacios de tabla. Tampoco pueden acceder a ningún dato de las bases de datos, a menos que se les concedan los privilegios para hacerlo.

Autoridad SYSMON: La autoridad SYSMON proporciona la capacidad para tomar capturas instantáneas de supervisión de sistema de base de datos, de una instancia de gestor de base de datos o de sus bases de datos. La autoridad SYSMON está asignada al grupo especificado por el parámetro de configuración sysmon_group . Si se especifica un grupo, la membrecía a ese grupo es controlada por fuera del gestor de base de datos mediante el recurso de seguridad usado por su plataforma. 

Autoridad DBADM: La autoridad DBADM es una autoridad de nivel de base de datos más que una autoridad de nivel de instancia. Resumiendo, los usuarios DBADM tienen control total sobre una base de datos. A los usuarios DBADM también se les conceden automáticamente todos los privilegios para los objetos de base de datos y sus contenidos. Como la autoridad DBADM es una autoridad de nivel de base de datos, puede asignarse tanto a usuarios como a grupos.

Autoridad LOAD: La autoridad LOAD también se considera una autoridad de nivel de base de datos y por lo tanto puede concederse a usuarios y a grupos. Como su nombre lo indica, la autoridad LOAD autoriza a los usuarios a emitir el comando LOAD contra una tabla. El comando LOAD se utiliza normalmente como una alternativa más rápida que los comandos INSERT o IMPORT cuando se está llenando una tabla con grandes cantidades de datos. Dependiendo del tipo de LOAD que desee ejecutar, tener solo la autoridad LOAD no es suficiente. También pueden llegar a requerirse privilegios específicos sobre la tabla.

Autoridad SECADM: La autoridad SECADM es considerada una autoridad de nivel de base de datos, pero solo puede ser concedida a un usuario específico por un usuario SYSADM. Un usuario con SECADM puede hacer lo siguiente:
  • Crear y descartar componentes de etiqueta de seguridad 
  • Crear y descartar políticas de seguridad 
  • Crear y descartar etiquetas de seguridad 
  • Conceder y revocar etiquetas de seguridad 
  • Conceder y revocar exenciones de reglas LBAC 
  • Conceder y revocar privilegios setsessionuser 
  • Ejecutar el enunciado SQL TRANSFER OWNERSHIP sobre objetos que usted no posee 

Privilegios DB2

Los privilegios son un poco más granulares que las autoridades, y pueden asignarse a usuarios y/o grupos. Los privilegios ayudan a definir los objetos que un usuario puede crear o descartar. Estos también definen los comandos que un usuario puede usar para acceder a objetos como tablas, vistas índices y paquetes. En el DB2 es nuevo el concepto de control de acceso basado en etiquetas (LBAC), el cual permite un control más granular sobre quién puede acceder a filas y/o columnas individuales. Los privilegios se pueden ubicar generalmente en dos categorías principales: privilegios de nivel de base de datos, los cuales abarcan todos los objetos de una base de datos, y privilegios de nivel de objeto los cuales están asociados a un objeto específico.

Los privilegios de nivel de base de datos que se le pueden otorgar a un usuario son:
  • CREATETAB: Los usuarios pueden crear tablas dentro de una base de datos.
  • BINDADD: Los usuarios pueden crear paquetes en la base de datos usando el comando BIND.
  • CONNECT: Los usuarios pueden conectarse a la base de datos.
  • CREATE_NOT_FENCED: Los usuarios pueden crear funciones unfenced definidas por usuario (UDF).
  • IMPLICIT_SCHEMA: Los usuarios pueden crear esquemas de forma implícita dentro de la base de datos, sin usar el comando CREATE SCHEMA.
  • LOAD: los usuarios pueden cargar datos a una base de datos
  • QUIESCE_CONNECT: Los usuarios pueden acceder a una base de datos mientras esté en su estado de desactivación temporal.
  • CREATE_EXTERNAL_ROUTINE: Los usuarios pueden crear un procedimiento para que sea usado por aplicaciones y por otros usuarios de la base de datos.
Los objetos de base de datos incluyen tablas, vistas, índices, esquemas y paquetes. Afortunadamente, la mayoría de privilegios de nivel de objeto se explican por sí mismos. La siguiente tabla resume estos privilegios.

Nombre del privilegio
Objetos relevantes
Descripción
CONTROL
Tabla, Vista, Índices, Paquetes, Alias, Tipo Distintivo, Función definida por usuario, Secuencia
Proporciona autoridad completa sobre el objeto. Los usuarios con este privilegio también pueden conceder o revocar privilegios sobre el objeto para otros usuarios.
DELETE
Tabla, Vista
Permite a los usuarios eliminar registros del objeto.
INSERT
Tabla, Vista
Permite a los usuarios insertar registros en el objeto mediante los comandos INSERT e IMPORT.
SELECT
Tabla, Vista
Proporciona a los usuarios la capacidad de ver el contenido del objeto usando el enunciado select.
UPDATE
Tabla, Vista
Permite a los usuarios modificar registros dentro de un objeto usando el enunciado update.
ALTER
Tabla
Permite a los usuarios alterar la definición del objeto usando el enunciado alter.
INDEX
Tabla
Permite a los usuarios crear índices sobre el objeto usando el enunciado index.
REFERENCES
Tabla
Proporciona a los usuarios la capacidad para crear y descartar restricción de claves foráneas sobre el objeto.
BIND
Paquete
Permite a los usuarios volver a vincular paquetes.
EXECUTE
Paquete, Procedimiento, Función, Método
Permite a los usuarios ejecutar paquetes y rutinas.
ALTERIN
Esquema
Permite a los usuarios modificar definiciones de objetos dentro del esquema.
CREATEIN
Esquema
Permite a los usuarios crear objetos dentro del esquema.
DROPIN
Esquema
Permite a los usuarios descartar objetos del esquema.

Cómo controlan el acceso a datos los ID de autorización

Uno de los modos en que DB2 controla el acceso a datos es mediante la utilización de identificadores. Un conjunto de uno o más identificadores de DB2, denominados ID de autorización, representa cada proceso que se conecta o inicia una sesión en DB2.

Los ID de autorización se clasifican en tres tipos:

ID de autorización primario: Como resultado de asignar ID de autorización, cada proceso tiene exactamente un ID que se denomina ID de autorización primario. Generalmente, el ID de autorización primario identifica un proceso.

ID de autorización secundario: Todos los demás ID son los ID de autorización secundarios. Un ID de autorización secundario, que es opcional, puede tener privilegios adicionales disponibles para el proceso.

CURRENT SQLID: Se designa un ID (primario o secundario) como CURRENT SQLID. CURRENT SQLID tiene los privilegios que se ejercen cuando se ejecutan determinadas sentencias de SQL dinámico. Se puede establecer CURRENT SQLID en el ID primario o en cualquiera de los ID secundarios.

Cómo mantienen privilegios y autorizaciones los ID de autorización

DB2 controla el acceso a sus objetos utilizando un conjunto de privilegios. Cada privilegio permite una acción sobre un objeto. Los ID pueden mantener privilegios que les permitan realizar determinadas acciones o que les prohíban realizarlas. Los privilegios de DB2 proporcionan un control extremadamente preciso.

Privilegios relacionados: DB2 define los conjuntos de privilegios relacionados, denominados autorizaciones administrativas. Al otorgar una autorización administrativa a un ID, se otorgan todos los privilegios asociados con ésta, en una sentencia.

Privilegios de objeto: La propiedad de un objeto conlleva un conjunto de privilegios relacionados sobre el objeto. Un ID puede ser el propietario de un objeto que crea o puede crear un objeto que pertenecerá a otro ID. La creación y propiedad de los objetos se controlan de forma separada.

Privilegios de paquete y plan de aplicación: El privilegio para ejecutar un plan de aplicación o un paquete requiere atención especial. La ejecución de un plan o un paquete ejerce implícitamente todos los privilegios que el propietario del plan o paquete ha necesitado para vincularlo. Por lo tanto, el otorgamiento del privilegio para ejecutar puede proporcionar un conjunto detallado de privilegios y puede eliminar la necesidad de otorgar otros privilegios por separado.

Etiquetas de seguridad: La seguridad de varios niveles limita el acceso a un objeto o a una fila basándose en la etiqueta de seguridad del objeto o fila y en la etiqueta de seguridad del usuario.

Roles: Un rol es una entidad de base de datos que agrupa uno o más privilegios. Un rol sólo está disponible cuando el proceso se ejecuta en un contexto fiable. Un contexto fiable es una entidad de base de datos basada en un ID de autorización del sistema y en un conjunto de atributos de fiabilidad de conexión.

Modos de controlar el acceso a subsistemas DB2

DB2 para z/OS realiza comprobaciones de seguridad para autenticar a los usuarios antes de otorgarles acceso a datos de DB2. Existen varios mecanismos de autenticación soportados por peticionarios de DB2 y aceptados por servidores de DB2.

La autenticación se produce cuando la sentencia CONNECT se emite para conectar el proceso de aplicaciones al servidor designado. El servidor o el subsistema DB2 local comprueba el ID de autorización y la contraseña para verificar que el usuario tiene autorización para conectarse al servidor. Se puede utilizar RACF o z/OS Security Server para autenticar los usuarios que acceden a una base de datos de DB2.

Acceso local a DB2

Un usuario de DB2 local está sujeto a varias comprobaciones de seguridad.

Por ejemplo, cuando DB2 se ejecuta bajo TSO y utiliza el ID de inicio de sesión de TSO como ID de autorización primario de DB2, dicho ID se verifica con una contraseña cuando el usuario inicia la sesión. Cuando el servidor es el subsistema DB2 local, RACF verifica la contraseña y comprueba si el ID de autorización tiene permiso para utilizar los recursos de DB2 definidos para RACF. Si se define una rutina de salida, RACF o z/OS Security Server realizan comprobación de seguridad adicional

Acceso remoto a DB2

Cuando el servidor no es el subsistema DB2 local se realizan varias comprobaciones de seguridad.
  • El gestor de seguridad local del servidor verifica el ID y la contraseña de autorización primaria de DB2. Una verificación posterior determina si el ID de autorización tiene permiso para acceder a DB2.
  • Las opciones de seguridad para los protocolos SNA o TCP/IP se comprueban en la base de datos de comunicaciones (CDB).
DDF da soporte a los protocolos de comunicaciones TCP/IP y SNA en un entorno distribuido. Como peticionario o servidor, DB2 elige cómo enviar o aceptar mecanismos de autenticación, basándose en el protocolo de red que se utiliza. DB2 utiliza mecanismos de seguridad de SNA para conexiones de red SNA y mecanismos de seguridad de DRDA para conexiones de red TCP/IP o Kerberos.

Las opciones de seguridad de DRDA proporcionan el siguiente soporte para cifrar datos sensibles:
  • Los servidores de DB2 para z/OS pueden proporcionar cifrado y descifrado de datos de alta velocidad seguros.
  • Los peticionarios de DB2 para z/OS disponen de la opción de cifrar sus ID de usuario y contraseñas cuando se conectan a servidores remotos. Los peticionarios también pueden cifrar datos sensibles de seguridad cuando se comunican con servidores de modo que los datos estén seguros cuando se transmiten por la red.
Se puede utilizar RACF o un subsistema de seguridad similar para realizar autenticación. RACF puede:
  • Verificar un ID de autorización remoto asociado a una conexión mediante la comprobación del ID con su contraseña.
  • Verificar si el ID de autorización tiene permiso para acceder a DB2 a través de una conexión remota.
  • Verificar si el ID de autorización tiene permiso para acceder a DB2 desde un sitio remoto específico.
  • Generar pases, una alternativa a las contraseñas, en el lado transmisor. Un pase permite a los usuarios acceder a un sistema principal sin enviar la contraseña de RACF a través de la red.
Modos de controlar el acceso a los datos

DB2 permite controlar el acceso a datos. El acceso a los datos incluye un usuario que participa en una sesión de terminal interactiva. Por ejemplo, el acceso puede ser desde un servidor remoto, desde una transacción IMS o CICS o desde un programa que se ejecuta en modalidad por lotes.

Esta información describe los diferentes métodos del control de acceso a datos en DB2. En esta información, el término proceso se utiliza para representar todos los modos de acceder a datos. 

La figura siguiente sugiere varias rutas desde un proceso hasta datos de DB2, con controles en cada ruta.

Control de acceso a datos de DB2




El primer método, control de acceso dentro de DB2, utiliza identificadores (ID) para controlar el acceso a objetos de DB2. En primer lugar el proceso debe cumplir los requisitos de seguridad para acceder al subsistema DB2. Cuando el proceso está dentro del subsistema DB2, DB2 comprueba varios ID para determinar si el proceso puede acceder a objetos de DB2. Se describen estos ID (ID de autorización primario, ID de autorización secundario e ID de SQL). Si el proceso tiene el ID o los ID necesarios, puede acceder a los objetos de DB2, incluyendo datos DB2.

El segundo método, protección de conjunto de datos, no se controla desde dentro de DB2. Se aplica la protección de conjunto de datos al proceso fuera de DB2. Si el proceso satisface los criterios de protección, llega a los datos de DB2.

Modos de controlar el acceso a objetos de DB2 mediante autorizaciones y privilegios explícitos

Puede controlar el acceso a los datos de usuario de DB2 otorgando, no otorgando o revocando autorizaciones y privilegios explícitos. Un privilegio explícito es un privilegio con nombre que se otorga con la sentencia GRANT o se revoca con la sentencia REVOKE. Una autorización administrativa es un conjunto de privilegios, que a menudo incluye un conjunto de objetos relacionado. Las autorizaciones incluyen con frecuencia privilegios que no son explícitos, no tienen nombre y no se pueden otorgar individualmente como, por ejemplo, la capacidad de terminar un trabajo de programa de utilidad.

Privilegios explícitos

Los privilegios explícitos proporcionan un control detallado. Por ejemplo, suponga que un usuario necesita seleccionar, insertar y actualizar datos de una tabla. Para completar estas acciones, el usuario debe seleccionar los privilegios SELECT, INSERT y UPDATE en la tabla.

Existen privilegios explícitos disponibles para los objetos siguientes:
  • Agrupaciones de almacenamientos intermedios
  • Colecciones
  • Bases de datos
  • Tipos diferenciados
  • JAR (Java Archive, con formato de archivo para agregar muchos archivos en un archivo)
  • Paquetes
  • Planes
  • Rutinas (funciones y procedimientos)
  • Esquemas
  • Secuencias
  • Grupos de almacenamiento
  • Sistema
  • Tablas
  • Espacios de tablas
  • Vistas

Autorizaciones administrativas

Los privilegios se agrupan en autorizaciones administrativas. Estas autorizaciones forman una jerarquía. Cada autorización incluye un grupo específico de privilegios. Las autorizaciones administrativas se clasifican en las categorías de autorizaciones del sistema, de base de datos y de colección. La autorización administrativa de más alto nivel es SYSADM. Cada nivel de autorización incluye los privilegios de todas las autorizaciones de nivel más bajo.

SYSADM: La autorización de administración del sistema incluye todos los privilegios de DB2 (salvo unos pocos reservados para instalación), los cuales se pueden otorgar todos a otros. Se Puede limitar la capacidad de SYSADM de gestionar el acceso a los roles. También puede limitar la capacidad de SYSADM de otorgar o revocar autorizaciones y privilegios.

SYSCTRL: La autorización de control del sistema incluye la mayoría de los privilegios SYSADM, pero excluye los privilegios para leer o modificar datos del usuario. 

SYSOPR: La autorización de operador del sistema incluye los privilegios para emitir la mayoría de los mandatos de DB2 y terminar cualquier trabajo de programa de utilidad. 

DBADM: La autorización de administración de base de datos incluye los privilegios para controlar una base de datos específica. Los usuarios con autorización DBADM pueden acceder a tablas y modificar o descartar espacios de tablas, tablas o índices de la base de datos. 

DBCTRL: La autorización de control de base de datos incluye los privilegios para controlar una base de datos específica y ejecutar programas de utilidad que pueden modificar datos de dicha base de datos. 

DBMAINT: La autorización de mantenimiento de base de datos incluye los privilegios para trabajar con determinados objetos y emitir determinados programas de utilidad y mandatos en una base de datos específica. 

ACCESSCTRL: La autorización de control de acceso permite a SECADM delegar la capacidad de otorgar y revocar privilegios de objetos y la mayoría de las autorizaciones administrativas. 

DATAACCESS: La autorización de acceso a datos controla el acceso de DBA a datos de usuario en DB2. 

EXPLAIN: La autorización EXPLAIN permite a un usuario emitir sentencias EXPLAIN, PREPARE y DESCRIBE sin que se requiera el privilegio para ejecutar la sentencia. 

PACKADM: La autorización de administrador de paquetes proporciona acceso a colecciones determinadas. 

SECADM: La autorización de administrador de seguridad permite a un usuario gestionar el acceso a una tabla en DB2, pero no puede crear, modificar ni descartar una tabla. 

SQLADM: La autorización de administrador de SQL proporciona la capacidad de supervisar y ajustar el SQL sin privilegios adicionales.


Control de acceso de nivel de fila y de nivel de columna

Se Puede utilizar el control de acceso de nivel de fila y de nivel de columna para restringir el acceso a ciertos tipos de información que exigen seguridad adicional. Los controles de acceso de nivel de fila y nivel de columna pueden ayudar a proteger información confidencial y cumplir las regulaciones gubernamentales de seguridad y privacidad. Estos controles de acceso funcionan con privilegios explícitos y autorizaciones administrativas. Si utiliza el control de acceso de nivel de fila o de nivel de columna, el control de acceso de nivel de visualización no es necesario.

DB2 restringe el acceso a las columnas y las filas según permisos de usuario individuales. Cuando DB2 está en modalidad de nueva función, la autorización SECADMIN gestiona las políticas de privacidad y seguridad asociadas con las tablas individuales. La autorización SECADMIN también otorga y revoca privilegios de acceso a filas y columnas específicas. El control de acceso de nivel de fila y nivel de columna afecta a todos los usuarios y los administradores de base de datos.

El control de acceso de nivel de fila y de nivel de columna proporciona las siguientes ventajas:
  • Integración dentro del sistema de base de datos
  • Seguridad de nivel de base de datos
  • Seguridad aplicada mediante SQL que no exige otros productos para supervisar el acceso
  • Acceso que se gestiona mediante el administrador de seguridad de DB2
  • Varios niveles de acceso basados en usuarios, grupos o roles
  • Control de acceso de nivel de fila y columna con filtrado y máscara de datos
Sin necesidad de filtrar los datos sensibles a nivel de aplicación

Utilización de seguridad de varios niveles para controlar el acceso

DB2 proporciona un esquema de seguridad de gran capacidad denominado seguridad de varios niveles. La seguridad de varios niveles es una política de seguridad que clasifica los datos y usuarios según un sistema de niveles de seguridad jerárquicos y categorías de seguridad no jerárquicas. La seguridad de varios niveles evita que usuarios no autorizados accedan a información de una clasificación superior a su autorización y evita que los usuarios desclasifiquen información.

Con la seguridad de varios niveles puede definir la seguridad para objetos de DB2 y realizar otras comprobaciones, incluidas las comprobaciones de seguridad de nivel inferior. Las comprobaciones de seguridad de nivel inferior controlan qué usuarios tienen autorización para ver, modificar o realizar acciones en filas de tablas. Con la seguridad de varios niveles no necesita utilizar vistas especiales ni variables de base de datos para controlar la seguridad en el nivel inferior.

Puede crear una etiqueta de seguridad para una fila de tabla definiendo una columna de la sentencia CREATE TABLE o ALTER TABLE como la etiqueta de seguridad. Cuando se accede a cada fila, DB2 utiliza RACF para comparar la etiqueta de seguridad de la fila y el usuario para determinar si el usuario tiene la autorización adecuada para acceder a la fila. Las comprobaciones de seguridad de nivel de fila se producen cada vez que un usuario emite una sentencia SELECT, INSERT, UPDATE o DELETE para acceder a una tabla con una columna de etiqueta de seguridad o ejecuta una solicitud de programa de utilidad para datos de una fila protegida mediante una etiqueta de seguridad.

Utilización de otorgamiento y revocación de privilegios para controlar el acceso

La sentencia GRANT de SQL le permite otorgar privilegios explícitamente a los ID de autorización. La sentencia REVOKE le permite revocarlos. Tan solo se puede revocar un privilegio que se haya otorgado explícitamente.

El otorgamiento de privilegios es muy flexible. Por ejemplo, considere los privilegios de tablas. Puede otorgar todos los privilegios de una tabla a un ID. De forma alternativa, puede otorgar privilegios separados específicos que permitan que este ID recupere datos de la tabla, inserte filas, suprima filas o actualice columnas específicas. Al otorgar o no otorgar estos privilegios en vistas de la tabla, puede determinar de forma eficaz y exacta qué acción un ID puede realizar o no en la tabla.

Puede utilizar la sentencia GRANT para asignar privilegios como se indica a continuación:
  • Otorgar privilegios a un único ID o a varios ID en una sentencia.
  • Otorgar un privilegio específico sobre un objeto en una única sentencia, otorgar una lista de privilegios u otorgar privilegios sobre una lista de objetos.
  • Otorgar ALL, para todos los privilegios de acceso a una única tabla o para todos los privilegios asociados con un paquete específico.


En conclusion del tema puedo decir que DB2 es un sistema de gestión de base de datos relacionales completamente habilitado para la web que se puede escalar, desde procesadores simples hasta multiprocesadores simétricos y agrupamientos paralelos masivos.

Mediante el se puede influir en todos los aspectos relativos a la información de la empresa, más allá de simples filas y columnas de datos alfanuméricos, incluyendo información en formato XML, imágenes, video en modalidad continua y otros formatos ricos en los medios.

DB2 dispone de una solución de control de accesos basada en etiquetas. Además, dispone de una nueva función de seguridad para el administrador, que permite unificar distintos privilegios bajo un solo usuario.

12 Reglas de Codd

En la década de los 80’s comenzaron a aparecer numerosos Sistemas de Gestión de Bases de Datos que se anunciaban como relacionales. Sin embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema relacional, perdiendo muchas ventajas del modelo relacional. Como ejemplo extremo de esto sistemas relacionales eran simplemente sistemas que utilizaban tablas para almacenar la información, no disponiendo de elementos como claves primarias, etc.


En 1984 Edgar F. Codd, creador del Modelo Relacional publicó las 12 Reglas que un verdadero Sistema Relacional de Bases de Datos debería cumplir. 

REGLA 0

Para que un sistema se denomine Sistema de Gestión de Bases de Datos Relacionales, este sistema debe usar exclusivamente sus capacidades relacionales para gestionar la base de datos.

REGLA 1: REGLA DE LA INFORMACIÓN.

Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico mediante tablas y sólo mediante tablas.

Por tanto los metadatos (diccionario, catálogo) se representan y se manipulan exactamente igual que los datos de usuario, usando quizás el mismo lenguaje (ejemplo SQL).

REGLA 2: REGLA DEL ACCESO GARANTIZADO

Para todos y cada uno de los datos (valores atómicos) de una base de datos relacional se garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.

Cualquier dato almacenado en una base de datos relacional tiene que poder ser direccionado unívocamente. Para ello hay que indicar en qué tabla está, cuál es la columna y cuál es la fila (mediante la clave primaria).

REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS

Se debe disponer de valores nulos (distintos de la cadena vacía, blancos, 0, etc.) para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos.

Se reconoce la necesidad de la existencia del valor nulo, el cual podría servir para representar, o bien, una información desconocida, o bien una información que no aplica.

Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lógicas, para lo cual se considera una lógica trivaluada, con tres (no dos) valores de verdad: Verdadero, Falso y null. 

REGLA 4: CATÁLOGO DINÁMICO  EN LÍNEA BASADO EN EL MODELO RELACIONAL

La descripción de la base de datos se representa a nivel lógico de la misma manera que los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales.

Los metadatos se almacenan y se manejan usando el modelo relacional, con todas las consecuencias.

REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO

Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ejemplo: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
  • Definición de datos
  •  Definición de vistas
  • Manipulación de datos (interactiva y por programa)
  • Restricciones de integridad
  • Restricciones de transacciones (begin, commit, rollback).

REGLA 6: REGLA DE ACTUALIZACIÓN DE VISTAS

Todas las vistas que son teóricamente actualizables se pueden actualizar también por el sistema.
El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no está muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.

REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL

La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la recuperación de los datos (consultas), sino también a la inserción, actualización y borrado de datos.


Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunos sistemas de bases de datos inicialmente sólo podían modificar las filas de una tabla de una en una (un registro de cada vez).


REGLA 8: INDEPENDENCIA FÍSICA DE DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cualesquiera sean los cambios efectuados, tanto en la representación del almacenamiento, como en los métodos de acceso.

El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.

REGLA 9: INDEPENDENCIA LÓGICA DE DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cualesquiera sean los cambios que se realicen a las tablas base que preserven la información.

Cuando se modifica el esquema lógico preservando información (no valdría por ejemplo, eliminar un atributo) no es necesario modificar nada en niveles superiores.

Ejemplos de cambios que preservan la información:
  •  Añadir un atributo a una tabla base.
  •  Sustituir dos tablas base por la unión de las mismas. Usando           vistas de la unión se pueden recrear las tablas anteriores...


REGLA 10: INDEPENDENCIA DE INTEGRIDAD

Las restricciones de integridad específicas para una determinada base de datos relacional deben poder ser definidos en el sublenguaje de datos relacional, y almacenables en el catálogo, no en los programas de aplicación.

El objetivo de las bases de datos no es sólo almacenar los datos, sino también sus relaciones y evitar que estas restricciones se codifiquen en los programas. Por tanto en una base de datos relacional se deben poder definir restricciones de integridad.

Cada vez se van ampliando más los tipos de restricciones de integridad que se pueden utilizar en los Sistemas de Gestión de Bases de Datos Relacionales, aunque hasta hace poco eran muy escasos.
Como parte de las restricciones inherentes al modelo relacional (forman parte de su definición) están:

  • Integridad de Entidad: Toda tabla debe tener una clave primaria.
  • Integridad de Dominio: Toda columna de una tabla contendrá valores exclusivamente de un determinado dominio (conjunto de valores válidos).
  • Integridad Referencial: Toda clave foránea no nula debe existir en la relación donde es clave primaria.

REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN

Una Base de Datos Relacional es independencia de la distribución.

Las mismas órdenes y programas se ejecutan igual en una base de datos centralizada que en una distribuida. Las bases de datos son fácilmente distribuibles.

Esta regla es responsable de tres tipos de transparencia de distribución:
  •  Transparencia de Localización. El usuario tiene la impresión de que trabaja con una base de datos local. (Regla de Independencia Física)
  • Transparencia de Fragmentación: El usuario no se da cuenta de que la relación con que trabaja está fragmentada. (Regla de Independencia Lógica).
  • Transparencia de Replicación: El usuario no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares.

REGLA 12: REGLA DE LA NO SUBVERSIÓN

Si un sistema relacional tiene un lenguaje de bajo nivel (un registro a la vez), ese bajo nivel no puede ser usado para subvertir (saltarse) las reglas de integridad y las restricciones expresadas en los lenguajes relacionales de más alto nivel (una relación a la cada vez).

Algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel.


Normalmente se usa SQL incorporado en un lenguaje anfitrión para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las filas de una tabla. En cualquier caso no debe ser posible saltarse las restricciones de integridad impuestos al tratar las filas a ese nivel.