Iniciación a Oracle - El modelo relacional

Concepto de tabla

Una tabla es una estructura lógica que sirve para almacenar los datos de un mismo tipo (desde el punto de vista conceptual). Almacenar los datos de un mismo tipo no significa que se almacenen sólo datos numéricos, o sólo datos alfanuméricos. Desde el punto de vista conceptual esto significa que cada entidad se almacena en estructuras separadas. Por ejemplo: la entidad factura se almacena en estructuras diseñadas para ese tipo de entidad: la tabla FACTURA, la tabla FACTURA_COMPRA etc. Así, cada entidad, tendrá una estructura (tabla) pensada y diseñada para ese tipo de entidad. Cada elemento almacenado dentro de la tabla recibe el nombre de registro o fila. Así, si la tabla FACTURA almacena 1.000 facturas, se dice que la tabla FACTURA contiene 1.000 registros o filas.

Una tabla se compone de campos o columnas, que son conjuntos de datos del mismo tipo (desde el punto de vista físico). Ahora cuando decimos “del mismo tipo” queremos decir que los datos de una columna son de todos del mismo tipo: numéricos, alfanuméricos, fechas

Con lo que hemos dicho la estructura de una tabla es esta:

En este esquema se puede ver que cada fila almacena los datos de una factura (es decir, la entidad factura en sí), y cada columna almacena los datos de un mismo tipo (las descripciones, los clientes, etc). De este modo se pude crear una tabla para cada tipo de entidad, y almacenar en ella los valores correspondientes.

Concepto de índice

Antes de ver qué es un índice tenemos que entender cómo se almacenan los datos. Los registros de una tabla se almacenan uno detrás de otro, respetando las longitudes de cada columna. Esto es una norma general pero en la actualidad no cumple en todas las bases de datos, ya que este sistema es poco eficiente. De todas formas vamos a imaginar que es así, ya que va a servir para entender qué pasa entre bastidores. Los tabla de FACTURA que hemos visto antes tiene la siguiente estructura:

|| Columna || Tipo || Ocupación (bytes) ||
|| Nº factura || N(3) || 3+1 ||
|| Descripción || A(50) || 50+1 ||
|| Cliente || A(20) || 20+1 ||
|| Importe || N(12) || 12+1 ||
|| Descuento || N(3) || 3+1 ||
|| Importe final || N(10) || 10+2 ||

La ocupación se incrementa en uno para incluir una marca de fin de columna, y en la última columna una marca de fin de registro.

La forma de almacenar en el disco duro los registros el ejemplo anterior sería la siguiente:

BOF||001|Tornillos sin rosca······························|Pepe················00000000 1000|010|0000000900||002|Tuercas·sin·agujero····························· ··|Juancito·············000000005500|000|0000005500||003|Tuercas·de·segun da·mano···························|Toñete··············000000000500|001|0 000000495|EOF

Podemos ver que al principio de la tabla hay una marca BOF (Begin Of File), y al final de la tabla una marca EOF (End Of File). Esto delimita el rango en el que están los datos de una determinada tabla. Hay que darse cuenta que aunque la descripción de la factura no ocupe los 50 caracteres, es base de datos se están almacenando los restantes con un carácter de relleno, en nuestro caso el carácter “·”

Si a la base de datos le damos la siguiente orden: “Dime la descripción de aquellas facturas cuyo cliente sea Toñete”

Lo que hará es recorrerse el fichero de datos desde la marca BOF hasta la marca EOF, “dando saltos” de N caracteres para leer sólo el campo cliente. Así dará saltos de 55 (3+1+50+1) bytes que es el espacio que hay entre el principio de registro y el principio de la columna “Cliente”. Una vez encontrada esta posición, sabemos que la descripción está 51 bytes anteriores al cliente, así que hay que posicionarse en ese byte, leer el valor y retornar el resultado. El pseudocódigo que representa este algoritmo puede ser:

Abrir fichero;

Bucle mientras no se acabe el fichero

Dar salto de 54 bytes en el fichero;Valor_campo = Leer 20 bytes de fichero;

Si valor_campo = “Toñete” entonces Posicion_cliente = Posicion actual del fichero;Dar salto de –posicion_cliente bytes; al principio del ficheroDar salto de posicion_cliente – 51 bytes;Valor = Leer 50 bytes;Retornar valor;

Fin-si;

Fin-bucle;

Retornar NO_ENCONTRADO;

En este pseudocódigo tenemos que tener en cuenta una de las características de la programación con ficheros: la instrucción de lectura es muy rápida (su tiempo es casi despreciable), mientras que el desplazamiento del cursor del fichero es una operación my lenta. Esto se traduce en que la instrucción leer no consume casi tiempo, sin embargo la instrucción dar salto es la que más tiempo consume y cuando mayor sea el número de bytes de desplazamiento, peor. Esto es debido a que la operación más lenta en los soportes de disco es el posicionamiento de las cabezas lectoras en el cilindro y sector adecuados, y una vez que el posicionamiento ya está hecho, la lectura es prácticamente instantánea. Así que en este algoritmo es muy lento porque hace demasiados saltos. A este tipo de lectura se le denomina lectura secuencial o FULL SCAN y es el caso más desfavorable en una consulta a base de datos. Además, cuando mayor sea el volumen de datos, se consiguen peores tiempos con un FULL SCAN.

Ahora vamos a lo que nos ocupa: un índice es una tabla paralela a otra principal que tan sólo contienen la(s) columna(s) indicada(s) durante su creación. Estas columnas se las denomina columnas indexadas.

Podemos usar la analogía del índice de un libro. Cuando nosotros necesitamos buscar un tema en un libro, tenemos dos posibilidades:

1.- Recorrernos todas las páginas del libro buscando la primera hoja de cada tema y comprobando si es el que necesitamos. En esta búsqueda perderemos la mayoría del tiempo pasando hojas y hojas, (lo que sería el posicionamiento de las cabezas lectoras), buscando el principio de cada tema. Cada vez que encontrásemos el principio de un nuevo tema, comprobaríamos si el es el que buscamos (lo que equivaldría a la lectura del dato), y esta operación de lectura no nos ocupará nada de tiempo.

2.- Podemos ir al índice en el que sólo están escritos los títulos de los temas y tan solo con pasar tres hojas (el posicionamiento de la cabezas lectoras es mínimo) ya hemos recorrido todo el temario. Después vamos a la página que nos indique el índice y consultamos lo que necesitemos. Este último desplazamiento sería el equivalente al salto que damos utilizando un puntero en un lenguaje de programación con el C.

Los índices en las tablas de BD son equivalentes a los índices de los libros. Siempre que exista índice, debe consultarse porque si no las búsquedas se dispararán en tiempo.

Formas normales

El análisis de un sistema de base de datos consiste en la investigación para decidir qué tablas nos hacen falta para resolver un problema. Existen muchos métodos para realizar este análisis, aunque quizá el más conocido sea el Entidad/Relación. Para completar el análisis de bases de datos, es necesario pasar por varias etapas, entre ellas, las principales son:

· Análisis conceptual (o lógico, o relacional): es un análisis abstracto de aquellas entidades que formarán la base de datos, así como las relaciones que establecen unas con otras y las restricciones que se aplican a cada una de ellas. El resultado de esta fase de análisis se ve reflejado en algo llamado Modelo Conceptual o lógico, que es una descripción de las entidades, atributos, relaciones y restricciones que compondrán la base de datos. El análisis conceptual es abstracto, por lo que no depende de la base de datos que vayamos a utilizar, ni del sistema en que se vaya a implementar dicha base de datos.

· Análisis físico: consta de un análisis específico teniendo en cuenta que base de datos se va a utilizar (Oracle, Sybase…) y en qué arquitectura se va a implementar la base de datos (entornos multiusuario, plataformas NT…)

Las formas normales no son más que tres reglas que se deben tener un cuenta dentro del Análisis conceptual, utilizando concretamente el método Entidad/Relación. El proceso de aplicar las tres formas normales se llama normalización. Un diseño de base de datos que no cumpla la primera forma normal no será correcto. Cuantas más formas normales cumpla el diseño de base de datos, significará que la base de datos está más correctamente analizada.

Primera forma normal

Identificar cada tabla con una clave primaria, y poner los datos en tablas separadas, de manera que los datos de cada tabla sean de un tipo similar (desde el punto de vista conceptual)

Segunda forma normal

Sacar las columnas que sólo dependen de una parte de la clave primaria a otra tabla.

Tercera forma normal

Incluir en cada tabla sólo datos que pertenezcan a la misma unidad lógica.

Estas tres normas las vamos a explicar con un ejemplo: Supongamos que necesitamos una tabla para almacenar facturas, y los datos que nos interesan son los siguientes:

|| Dato || Tipo ||
|| Descripción || A(50) ||
|| Nombre del cliente || A(20) ||
|| Dirección del cliente || A(30) ||
|| Teléfono del cliente || A(10) ||
|| Importe || N(12) ||

Si el programador que está diseñando la tabla, no tiene mucha experiencia, lo primero que hará es definir la tabla tal y como aparece anteriormente. Si además metemos datos, la tabla se verá así:

|| Descripción || || Nombre cliente || Dirección cliente || Teléfono cliente || Importe ||
|| Tornillos sin rosca || || Federico Antóñez || C/ Alta, nº 2 || 555-123546 || 500 ||
|| Servicios prestados || || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 4.587 ||
|| Compra de tuercas agujero || sin || Federico Antóñez || C/ Baja, nº 2 || 555-123456 || 258.987 ||
|| Atrasos || || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 1.245.847 ||
|| Tornillos sin rosca || || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 500 ||

Según la primera forma normal, tenemos la necesidad de identificar cada uno de los registros de esta tabla inequívocamente. No podemos utilizar la descripción porque es posible que haya dos facturas con la misma descripción (dos ventas de tornillos), tampoco el cliente porque un cliente suele tener más de una factura. Ni tampoco el importe porque es normal tener varias facturas con el mismo importe. Para ello tenemos que definir una nueva columna que nos identifique cada una de las facturas Es posible (y bastante común) que no encontremos una columna que sea capaz de identificar a al registro completo, por ello se puede definir más de una columna dentro de la clave. En este caso es el conjunto de valores de las columna seleccionadas el que no se podrá repetir. Esta columna (o conjunto de ellas) se denomina clave primaria (o primary key).

|| Columna || Tipo ||
|| (*) Referencia || A(10) ||
|| Descripción || A(50) ||
|| Nombre cliente || A(20) ||
|| Dirección || A(30) ||
|| cliente || ||
|| Teléfono cliente || A(10) ||
|| Importe || N(12) ||

Las columnas marcadas con (*) son las que componen la clave primaria. Según este nuevo esquema, nuestra tabla con datos quedará así:

|| Ref. || Descripción || Nombre cliente || Dirección cliente || Teléfono cliente || Importe ||
|| FR00123 || Tornillos sin rosca || Federico Antóñez || C/ Alta, nº 2 || 555-111111 || 500 ||
|| FR00124 || Servicios prestados || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 4.587 ||
|| FR00125 || Compra de tuercas sin agujero || Federico Antóñez || C/ Baja, nº 2 || 555-111112 || 258.987 ||
|| FR00126 || Atrasos || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 1.245.847 ||
|| FR00127 || Tornillos sin rosca || Juancito Pérez Pí || C/ del Abedul, s/n || 555-131415 || 500 ||

Ahora podemos estar seguros de que no habrá dos facturas con la misma referencia por lo que podemos consultar la factura con referencia ‘FFR00123’ y estaremos seguros de que sólo habrá una.

El siguiente paso de la primera forma normal es poner los datos en tablas separadas, asegurándonos de que los datos de una tabla son datos correspondientes a aquello que almacena la tabla.

En este ejemplo podemos ver cómo en la tabla FACTURA se están guardando datos del cliente (dirección y teléfono). En caso de que un cliente tenga más de una factura (como en el ejemplo), estaremos repitiendo la dirección y el teléfono para cada una de las facturas. Esto se denomina redundancia de datos y produce tres efectos negativos: