===== Concepto de tabla =====
Una tabla es una estructura lógica que sirve para almacenar los datos de un mismo tipo, 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. 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, 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:
Cada fila almacena los datos de una factura , 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 =====
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. De todas formas vamos a imaginar que es así. La 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, en base de datos se están almacenando los restantes con un carácter de relleno, en nuestro caso el carácter “·”
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. //
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. El método para realizar este análisis más conocido es 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.
· 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:
