*Base de datos relacional*

*DEFINICIÓN*

Una base de datos relacional es una base de datos que está de acuerdo al modelo relacional, y puede también ser definida como un conjunto de relaciones o una base de datos construida en un sistema de gestión de base de datos.

Un sistema de gestión de bases de datos (SGBD), es un sistema que administra o gestiona datos utilizando el modelo relacional. Frecuentemente, el término "SGBD" es inadecuadamente usado como una etiqueta genérica para el concepto de las bases de datos relacionales.

Una base de datos relacional es una  base de datos que cumple con el modelo relacional, y se refiere a una base de datos y base de datos de esquema lógico (la estructura de la base de datos datos). Un uso común del término "Sistema de gestión de base de datos" técnicamente se refiere al software usado para crear un base de datos relacional, pero a veces erróneamente se refiere a una base de datos relacional.

*CARACTERISTICAS*

En una computadora existen diferentes formas de almacenar información. Esto da lugar a distintos modelos de organización de la base de datos: jerárquico, red, relacional y orientada a objeto.

Los sistemas relacionales son importantes porque ofrecen muchos tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario final, períodos cortos de aprendizaje y las consultas de información se especifican de forma sencilla.

Las tablas son un medio de representar la información de una forma más compacta y es posible acceder a la información contenida en dos o más tablas. Más adelante explicaremos que son las tablas.

Las bases de datos relacionales están constituidas por una o más tablas que contienen la información ordenada de una forma organizada. Cumplen las siguientes leyes básicas:

• -Generalmente, contendrán muchas tablas.

• -Una tabla sólo contiene un número fijo de campos.

• -El nombre de los campos de una tabla es distinto.

• -Cada registro de la tabla es único.

• -El orden de los registros y de los campos no está determinados.

• -Para cada campo existe un conjunto de valores posible.

Características mandatorios ó reglas de oro

Un sistema de BDOO debe satisfacer dos criterios:

* Debe tener un BDMS

* Debe ser un sistema OO

Por ejemplo: para la extensión posible este debe ser consistente en los actuales cortes de lenguajes de programación OO

El primer criterio se traduce en 5 características como son:

Persistencia, Manejador de almacenamiento secundario, Concurrencia, Recuperación, y Facilidad de Query,

La Segunda se traduce en 8 características: Objetos Complejos, Identidad del objeto, Encapsulación, Tipos ó Clases, Sobre paso con combinación retrasada, Extensibilidad y Completación Computacional.

Manifiesto de sistema de gestión de BDOO

Esta publicación intenta definir un sistema de BDOO y describe las principales características.

Hemos separado estas características en 3 grupos:

* Mandatorias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de BDOO y estos son: Objetos complejos, Identidad de objetos, Encapsulación, Tipos ó Clases, Sobre paso combinado con unión retardada, Extensibilidad, Completación Computacional, Persistencia y Manejador de almacenamiento secundario, Concurrencia, Recuperación y Facilidad de Query.

* Opcional.- Son las que pueden ser añadidas para hacer el sistema mejor pero que no son Mandatorias estas son de: herencia múltiple, chequeo de tipos e inferencia distribución y diseño de transacciones y versiones.

* Abiertas.- Son los puntos donde el diseñador puede hacer un número de opciones y estas son el paradigma de la programación la representación del sistema ó el tipo de sistema y su uniformidad. Hemos tomado una posición no muy a la expectativa para tener una palabra final más bien para proveer un punto de orientación para un debate futuro.

Características obligatorias

Este es un punto que no debe faltar en una BD.

* Predominancia combinada con enlace retardado.- Se puede definir que sea Excel, Autocad, etc. desde la programación.

* Extensibilidad.- Proporciona los tipos de datos como: Caracter, booleano, String, etc.

* Concurrencia.- Permite que varios usuarios tengan acceso a una BD al mismo tiempo.

* Recuperación.- Cuando se hace una transacción pero no se puede realizar y se regresa al mismo estado.

* Facilidad de "Consultas a Modo".- Esto es que se tienen diferentes estándares.

*VENTAJAS Y DESVENTAJAS*

Ventajas

Está su flexibilidad, y soporte para el manejo de tipos de datos complejos. Por ejemplo, en una base de datos convencional, si una empresa adquiere varios clientes por referencia de clientes servicio, pero la base de datos existente, que mantiene la información de clientes y sus compras, no tiene un campo para registrar quién proporcionó la referencia, de qué manera fue dicho contacto, o si debe compensarse con una comisión, sería necesario reestructurar la base de datos para añadir este tipo de modificaciones. Por el contrario, en una BDOO, el usuario puede añadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia.

La subclase heredará todos los atributos, características de la definición original, además se especializará en especificar los nuevos campos que se requieren así como los métodos para manipular solamente estos campos. Naturalmente se generan los espacios para almacenar la información adicional de los nuevos campos. Esto presenta la ventaja adicional que una BDOO puede ajustarse a usar siempre el espacio de los campos que son necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan.

La segunda ventaja de una BDOO, es que manipula datos complejos en forma rápida y ágilmente. La estructura de la base de datos está dada por referencias (o apuntadores lógicos) entre objetos.

Desventajas

Al considerar la adopción de la tecnología orientada a objetos, la inmadurez del mercado de BDOO constituye una posible fuente de problemas por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar su producto en una línea de producción sustantiva. Por eso, en este artículo se propone que se explore esta tecnología en un proyecto piloto.

El segundo problema es la falta de estándares en la industria orientada a objetos. Sin embargo, el "Grupo Manejador de Objetos" (OMG), es una organización Internacional de proveedores de sistemas de información y usuarios dedicada a promover estándares para el desarrollo de aplicaciones y sistemas orientados a objetos en ambientes de cómputo en red. La implantación de una nueva tecnología requiere que los usuarios iniciales acepten cierto riesgo. Aquellos que esperan resultados a corto plazo y con un costo reducido quedarán desilusionados. Sin embargo, para aquellos usuarios que planean a un futuro intermedio con una visión tecnológica avanzada, el uso de tecnología avanzada, el uso de tecnología orientada a objetos, paulatinamente compensará todos los riesgos.

*ESQUEMA*

El modelo relacional

• Todos los datos se representan en tablas.
  • Incluso los resultados de cualquier consulta son otra tabla.

• Las tablas están compuestas por filas y columnas.

• Las filas y las columnas, en principio, carecen de orden (p.ej., el orden en el que se muestren las filas y las columnas no importa).
  • Las filas sólo se ordenan si se le indica a la base de datos que lo haga, mediante el correspondiente comando. De no ser así, el orden será arbitrario, y puede cambiar en caso de tratarse de una base datos dinámica.
  • El orden de las columnas lo determina cada consulta.

• Cada tabla tiene una clave primaria, un identificador único, compuesto por una o más columnas.

• La mayoría de las claves primarias están formadas por una única columna (p.ej., CIUDAD_ID).

• Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria.

• Estos dos conceptos --clave primaria y secundaria-- son los más importantes en el diseño de bases de datos. Es importante dedicarles tiempo, para entender bien en qué consisten y cómo funcionan.

• Reflejar la estructura del problema en el mundo real.

• Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.

• Evitar el almacenamiento de información redundante.

• Proporcionar un acceso eficaz a los datos.

• Mantener la integridad de los datos a lo largo del tiempo.

• Ser claro, coherente y de fácil comprensión.

• Nota: A veces, estos objetivos pueden ser contradictorios.

Introducción al modelo Entidad/Interrelación (E/R)

• El modelo Entidad/Interrelación (E/R): un método de diseño de bases de datos.

• Muestra de una versión simplificada.

• Representa los datos mediante una serie de entidades que disponen de atributos.

• Una entidad es una clase de objetos o conceptos claramente identificable.

• Las entidades establecen interrelaciones con otras entidades.

• El resultado de este proceso es una base de datos normalizada que facilita el acceso a los datos y evita su duplicado.
  Nota: en su mayor parte, el diseño formal de una base de datos se centra en la normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización (p.ej., first normal form, second normal form, etc.). Este nivel de formalidad va mucho más allá, pero es importante saber que existen tales formalidades.

Proceso de diseño en el modelo E-R

• Identificar las entidades que debe presentar la base de datos.

• Determinar las cardinalidades de las interrelaciones establecidas entre las distintas entidades y clasificar estas interrelaciones entre los siguientes tipos:
  • Uno a uno (p.ej., una parcela sólo tiene una dirección).
  • Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios).
  • Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender varios propietarios y cada propietario puede vender varias parcelas).

• Dibujar el diagrama Entidad/Interrelación.

• Determinar los atributos de cada entidad.

• Definir la clave primaria (única) de cada entidad.

Problemas al trabajar con bases de datos y ArcView®

• ArcView® sólo permite establecer relaciones a través de una columna:
  • Esto obliga a los usuarios a recurrir a una serie de procedimientos elaborados para construir una clave de una sola columna.
     
• ArcView® no puede trabajar con expresiones "al vuelo":
  • Los porcentajes y las proporciones se deben almacenar en columnas extra.
  • Estos valores pueden quedar desfasados y su creación requiere un gran trabajo extra.
     
• ArcView® no funciona demasiado bien con relaciones muchos a muchos.
  • Una relación uno a muchos produce un valor arbitrario en la tabla relacionada.
  • Un "enlace" o vínculo, más que una relación, proporciona alguna capacidad muchos a uno, aunque bastante limitada.
• Las herramientas de agregado y "agrupamiento" disponibles son también limitadas. Por ejemplo, "Campo | Estadísticas y campo | Resumir" (Field | Statistics and Field | Summarize).

• Las herramientas para trabajar con sistemas de gestión de bases de datos externos (p.ej., Oracle) son bastante lentas y difíciles de usar.

Paso del modelo E/R al diseño de la base de datos

• Las entidades entre las que hay una interrelación uno a uno se deben fusionar en una sola entidad.
   
• Una vez hecho esto, cada una de las entidades que quedan se convierte en una tabla con una clave primaria y una serie de atributos, de los cuales algunos pueden ser claves secundarias.
   
• Las interrelaciones uno a muchos se transforman en atributo y clave secundaria de la tabla que representa a la entidad situada del lado de la interrelación correspondiente a muchos .
   
• Las interrelaciones muchos a muchos entre dos entidades pasan a ser una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias deberán formar parte de la clave primaria de la tabla en la que se convierte la interrelación, cuando corresponda.
   
• Hay una serie de herramientas disponibles en el mercado que pueden automatizar el proceso de conversión de un modelo E/R en un esquema de base de datos.

*EJEMPLOS DE LA VIDA REAL*

Éste es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla).

En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.

El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.

Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.

Durante los años '80 (1980-1989) la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.