/home/blaster [ Blaster's blog ]

Archive for the ‘Bases de datos’ Category

Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación:

Clientes

ID_Cliente Nombre

Apellidos

Nombre_Producto1 Costo_Producto1

Imagen_Producto1 Nombre_Producto2 Costo_Producto2

Imagen_Producto2 Fecha_Pedido

Cantidad_Pedido

Nombre_Cia_Envios

La tabla se ha descrito de manera abreviada pero aun así representa la idea general.

¿Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un pedido también. ¿Qué tal si quisiera emitir un informe de todos los productos que vende? No podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto fácilmente.

La nomlalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la nomlalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la nomlalización, podría crear las tablas basándose en estos grupos.

El proceso de nomlalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de nomlalización, siempre será bien Iinvertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe.

Otra ventaja de la nomlalización de su base de datos es el consumo de espacio. Una base de datos nomlalizada puede ocupar menos espacio en disco que una no nomlalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.

Grados de normalización

Existen básicamente tres niveles de normalización: Primera Fomla Normal (1NF), Segunda Fomla Normal (2NF) y Tercera Fomla Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera nomlalizada a esa forma de nomlalización. Por ejemplo, supongamos que su

base de datos cumple con todas las reglas del segundo nivel de nomlalización. Se considera que está en la Segunda Fomla Normal. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

Primera Forma Normal

La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir. Observe el esquema de la tabla Clientes de la base de datos.

.

Clientes

ID Cliente

Nombre

Apellidos

Nombre_Producto1

Costo_Producto1

Imagen_Producto1

Nombre_Producto2

Costo_Producto2

Imagen_Producto2

Fecha_Pedido

Cantidad_Pedido

Nombre Cia Envios

–

La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla.

Eliminación de datos repetidos en una base de datos

Clientes Pedidos

ID_Clientes Nombre_Productos

Nombre Costo_Producto

Apellidos Imagen_Producto

Direccion

Numero_Pedido

Fecha_Pedido

Cantidad_Pedido

Clave_Cia_Envios

Nombre_Ci_ Envios

–

Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave primaria que se llame ID_Producto y añada una clave a la tabla Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato ideal.

Primera Forma Normal

Clientes Pedidos

ID_Productos ID_Productos

ID_Clientes Nombre_Productos

Nombre Costo_Producto

Apellidos Imagen_Producto

Direccion

Numero_Pedido

Fecha_Pedido

Cantidad_Pedido

Clave_Cia_Envios

–

Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de datos estará haciendo en la vida real. El cliente tendrá muchos productos que podrá comprar,

sin importar cuántos otros clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir

un cliente cada vez que añade un nuevo producto a su inventario.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. En una empresa de servicios de electricidad, había una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una nueva columna para almacenar la información. Obviamente, el diseño de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para sus programadores/administradores.

La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños. No es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos conducirá aun mejor aprovechamiento de sus activos.

Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una depen dencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que haya organizado la información de pedidos.

Eliminación de las dependencias parciales -Segunda Forma Normal

Clientes Pedidos Productos

ID_Productos ID_Productos ID_Producto

ID_Clientes Nombre_Productos Fecha_Compra

Nombre Cantidad_Pedido Costos_Productos

Apellidos Imagen_Producto

Direccion

Numero_Pedido

Nombre_Cia_Envios

De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalización, así está bien.

Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada.

Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados.

Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto.

Tercera Forma Normal

La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse únicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte.

Eliminación de los datos que no son claves para la Tercera Forma Normal

Clientes Productos PedidoMaestro PedidoDetallado Cias_Envios

ID_cliente ID_Producto ID_Pedido ID_PedidoDetallado ID_Cia_Envios

ID_Producto Nombre_Producto Fecha_Pedido ID_Pedido Nombre_Cia_Envios.

Numero_Pedido Costos_Productos Cantidad_Pedidos Fecha_Pedido

ID_Cia_Envios Foto_Producto Cantidad_Pedido

Nombre

Apellidos

Direccion

Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla está identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

Qué tan lejos debe llevar la normalización

La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su base de datos va a proveer información aun solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes.

A veces puede ocurrir que normalizar sus datos hasta el nivel más alto no tenga sentido. Por ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se muestra a continuación:

ID_Cliente

Nombre

Apellidos

Direccion1

Direccion2

De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se muestra a continuación:

ID_Ciente ID_Direccion

Nombre ID_Cliente

Apellidos Direccion

La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener más de una dirección. El problema aquí es que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalización. En esta instancia, el exceso de normalización frustra el propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de complejidad. Una buena forma de determinar si está llevando demasiado lejos su normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera indicar que está normalizando demasiado. Observe su esquema.

¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta. Es subjetiva.

Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o

Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.

En resumen

La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas entre tablas de una base de datos.

Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita también agregar nuevas columnas sin romper el esquema actual ni las relaciones.

Existen varios niveles de normalización: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma

Normal de Clave de Dominio. Cada nuevo nivel o forma lo acerca más a hacer su base de datos verdaderamente relacional.

Se discutieron las primeras tres formas. Éstas proveen suficiente nivel de normalización para cumplir con las necesidades de la mayoría de las bases de datos.

Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de sentido común y

práctico puede ayudarle a decidir cuándo normalizar.

Si lees el post anterior “Como Exportar a SQLite” veréis todos los pasos con explicaciones. Para los impacientes los 4 pasos a seguir diréctamente:

$ aptitude install mdbtools
$ mdb-schema BD.mdb mysql > BD_esquema_mysql.sql
$ mdb-tables -S -1 BD.mdb > BD.txt
$ for tabla in `cat BD.txt`; do mdb-export -Q -I BD.mdb “${tabla}”; done > datos.sql

Razón: Muchas veces necesitamos hacer búsquedas y no nos sirve usar bases de datos en mysql, un ejemplo puede ser un programa en Java que querramos que sea portable (que toda la aplicacion este en un archivo .jar incluida la base de datos).

Un caso comun es que la persona que vaya a usar nuestro programa no tenga MySQL instalado o no sepa configurarlo, instalarlo, etc. SQLite nos soluciona el problema, pues es un fichero que puede ser adjuntado con el programa, y nos aporta las ventajas de las bases de datos, aunque en un nivel menos, pues no soporta todas las opciones que nos puede dar mysql. Podríamos guardar los datos en un archivo de texto o binario, pero a la hora de recuperar los datos, sqlite es mucho mejor que un archivo.

Como empezar: Para trabajar con las bases de datos de Access necesitamos el paquete mdbtools, y para trabajar con sqlite el paquete sqlite3, así que pasamos a instalarlos:
sudo apt-get install sqlite3 mdbtools

Una vez que tenemos los paquetes, pasamos a exportar del archivo mdb a sentencias sql, lo haremos en dos pasos, primero el esquema (CREATE …) y luego los datos (INSERT INTO ….) . Para exportar el esquema usaremos el siguiente comando:
mdb-schema master.mdb > esquema.sql

El primer parámetro sera el nombre de la base de datos y el segundo el archivo con las sentencias sql. Si vemos el archivo vemos que uno de los campos se llama P/T y que hay dos campos de tipo Memo/Hyperlink (255), pues bien, sqlite no permite poner “/” en los nombres de los campos, y no existen campos de ese tipo, así que con kate, editaremos el archivo y pondremos de nombre del campo PT y el tipo de datos Text(255).

Ahora pasaremos a por el archivo de los datos, para ello, usaremos el comando:

mdb-export -H -I master.mdb Cards > datos.txt

Con esto exportamos los datos con las sentencias INSERT ya incluidas. En mi caso, Cards es el nombre de la tabla, podemos verlo con mdb-tables master.mdb. Pero tenemos dos problemas que hay que solucionar, el primero es que en los INSERT nos ha puesto el campo P/T, y lo hemos cambiado por PT, y el segundo problema es que las sentencias insert no terminan en “;”. Para arreglar eso echaremos mano de sed.

cat datos.txt | sed -e ’s/”)/”);/g’ > datos.temp

Con esto añadimos el ; al final de cada sentencia insert, y para cambiar P/T por PT, basta con:

cat datos.temp | sed -e ’s/P\/T/PT/g’ > datos.sql

Estupendo, ya tenemos todo lo necesario para crear las tablas en sqlite, el proceso es muy sencillo. ejecutamos estas sentencias:

josu@cyrusnet:$ sqlite
SQLite version 2.8.17
Enter “.help” for instructions
sqlite> .read esquema.sql
DROP TABLE Cards;
SQL error: no such table: Cards
sqlite> .read datos.sql
sqlite> .output insert.sqlite
sqlite> .dump
sqlite>

El nombre del archivo se puede cambiar, pero da lo mismo, porque aun no tenemos la base de datos, pero ya solo queda un último paso, que es:
sqlite cartasMagic.db < insert.sqlite

Una pega que tiene esto, es que el archivo mdb ocupaba 7 megas y el sqlite ocupa 25.

Ya esta, ahora solo queda demostrar que podemos ejecutar consultas sql, por ejemplo vamos a buscar las cartas que se llamen Fireball y sean de quinta edición:

josu@cyrusnet:~/downloads$ sqlite cartasMagic.db “SELECT * FROM Cards WHERE Edition=’5E’ AND Name =’Fireball’”

Resultado:
Fireball|R|C|5E||0.8300|Sorcery|XR|Mark Tedin|Pay for each target beyond the first: Fireball deals X damage divided evenly, rounded down, among any number of target creatures and/or players.||||5E\Fireball.jpg|1||NF

SQLite es un excelente motor de bases de datos unipersonales, parecido a Access. Tiene versiones para Windows y Linux y tiene interfaces para muchos lenguajes de programacion como Java, C++, Perl, PHP, ADO .NET

La gran ventaja es que nuestra aplicacion se puede distribuir con el motor SQLite instalado dentro de ella (embebido) asi que el cliente no tiene que configurar nada en su maquina (ODBC, instalar y configurar Postgres, MySQL, SQL Server etc), solo correr nuestra aplicacion.

SQLite parsea claves foraneas e integridad referencial en la definicion del esquema, pero no hace nada con ellas ni las incluye en la metadata.

La solucion mas usada es usar triggers. En este post de otro blog encontre la solucion al problema:

Tomado de: http://www.justatheory.com/computers/databases/sqlite/

Aqui empieza:

After some some Googling and experimentation, I’ve figured out how to enforce foreign key constraints in SQLite. I got most of the code from Cody Pisto’s sqlite_fk utility. I couldn’t get it to work, but the essential code for the triggers was in its fk.c file, so I just borrowed from that (public domain) code to figure it out.

Since I couldn’t find documentation for this elsewhere on the Net (though I’m sure it exists somewhere), I decided to just put an example here. Interested? Read on!

Say you have these two table declarations:

create table foo (

  id INTEGER NOT NULL PRIMARY KEY

);CREATE TABLE bar (

  id INTEGER NOT NULL PRIMARY KEY,

  foo_id INTEGER NOT NULL

         CONSTRAINT fk_foo_id REFERENCES a(id) ON DELETE CASCADE

);

Table bar has a foreign key reference to the primary key column in the foo table. Although SQLite supports this syntax (as well as named foreign key constraints), it ignores them. So if you want the references enforced, you need to create triggers to do the job. Triggers were added to SQLite version 2.5, so most users can take advantage of this feature. Each constraint must have three triggers: one for INSERTs, one for UPDATESs, and one for DELETESs. The INSERT trigger looks like this:

CREATE TRIGGER fki_bar_foo_id

BEFORE INSERT ON bar

FOR EACH ROW BEGIN

  SELECT CASE

     WHEN ((SELECT id FROM foo WHERE id = NEW.foo_id) IS NULL)

     THEN RAISE(ABORT, ‘insert on table "bar" violates foreign key ‘

                || ‘constraint "fk_foo_id"’)

  END;

END;

(You can put the RAISE error string all on one line; I’ve concatenated two lines to keep line lengths reasonable here.) If your foreign key column is not NOT NULL, the trigger’s SELECT CASE clause needs to an extra case:

CREATE TRIGGER fki_bar_foo_id

BEFORE INSERT ON bar

FOR EACH ROW BEGIN

   SELECT CASE

     WHEN ((new.foo_id IS NOT NULL)

           AND ((SELECT id FROM foo WHERE id = new.foo_id) IS NULL))

     THEN RAISE(ABORT, ‘insert on table "bar" violates foreign key ‘

                || ‘constraint "fk_foo_id"’)

  END;

END;

The UPDATE statements are almost identical; if your foreign key column is NOT NULL, then do this:

CREATE TRIGGER fku_bar_foo_id

BEFORE UPDATE ON bar

FOR EACH ROW BEGIN

   SELECT CASE

     WHEN ((SELECT id FROM foo WHERE id = new.foo_id) IS NULL))

     THEN RAISE(ABORT, ‘update on table "bar" violates foreign key ‘

                || ‘constraint "fk_foo_id"’)

  END;

END;

And if NULLs are allowed, do this:

CREATE TRIGGER fku_bar_foo_id

BEFORE UPDATE ON bar

FOR EACH ROW BEGIN

   SELECT CASE

     WHEN ((new.foo_id IS NOT NULL)

           AND ((SELECT id FROM foo WHERE id = new.foo_id) IS NULL))

     THEN RAISE(ABORT, ‘update on table "bar" violates foreign key ‘

                || ‘constraint "fk_foo_id"’)

  END;

END;

The DELETE trigger is, of course, the reverse of the INSERT and UPDATE triggers, in that it applies to the primary key table, rather than the foreign key table. To whit, in our example, it watches for DELETEs on the foo table:

CREATE TRIGGER fkd_bar_foo_id

BEFORE DELETE ON foo

FOR EACH ROW BEGIN

  SELECT CASE

    WHEN ((SELECT foo_id FROM bar WHERE foo_id = OLD.id) IS NOT NULL)

    THEN RAISE(ABORT, ‘delete on table "foo" violates foreign key ‘

               || ‘ constraint "fk_foo_id"’)

  END;

END;

This trigger will prevent DELETEs on the foo table when there are existing foreign key references in the bar table. This is generally the default behavior in databases with referential integrity enforcement, sometimes specified explicitly as ON DELETE RESTRICT. But sometimes you want the deletes in the primary key table to cascade to the foreign key tables. Such is what our example declaration above specifies, and this is the trigger to to the job:

CREATE TRIGGER fkd_bar_foo_id

BEFORE DELETE ON foo

FOR EACH ROW BEGIN

    DELETE from bar WHERE foo_id = OLD.id;

END;

Pretty simple, eh? The trigger support in SQLite is great for building your own referential integrity checks. Hopefully, these examples will get you started down the path of creating your own.

Una de las características fundamentales de los sistemas de bases de datos es que proporcionan cierto nivel de abstracción de datos, al ocultar las características sobre el almacenamiento físico que la mayoría de usuarios no necesita conocer. Los modelos de datos son el instrumento principal para ofrecer dicha abstracción. Un modelo de datos es un conjunto de conceptos que sirven para describir la estructura de una base de datos: los datos, las relaciones entre los datos y las restricciones que deben cumplirse sobre los datos. Los modelos de datos contienen también un conjunto de operaciones básicas para la realización de consultas (lecturas) y actualizaciones de datos. Además, los modelos de datos más modernos incluyen conceptos para especificar comportamiento, permitiendo especificar un conjunto de operaciones definidas por el usuario.

Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la base de datos. Los modelos de datos de alto nivel, o modelos conceptuales, disponen de conceptos muy cercanos al modo en que la mayoría de los usuarios percibe los datos, mientras que los modelos de datos de bajo nivel, o modelos físicos, proporcionan conceptos que describen los detalles de cómo se almacenan los datos en el ordenador. Los conceptos de los modelos físicos están dirigidos al personal informático, no a los usuarios finales. Entre estos dos extremos se encuentran los modelos lógicos, cuyos conceptos pueden ser entendidos por los usuarios finales, aunque no están demasiado alejados de la forma en que los datos se organizan físicamente. Los modelos lógicos ocultan algunos detalles de cómo se almacenan los datos, pero pueden implementarse de manera directa en un ordenador.

Los modelos conceptuales utilizan conceptos como entidades, atributos y relaciones. Una entidad representa un objeto o concepto del mundo real como, por ejemplo, un empleado de la empresa inmobiliaria o una oficina. Un atributo representa alguna propiedad de interés de una entidad como, por ejemplo, el nombre o el salario del empleado. Una relación describe una interacción entre dos o más entidades, por ejemplo, la relación de trabajo entre un empleado y su oficina.

Cada SGBD soporta un modelo lógico, siendo los más comunes el relacional, el de red y el jerárquico. Estos modelos representan los datos valiéndose de estructuras de registros, por lo que también se denominan modelos orientados a registros. Hay una nueva familia de modelos lógicos, son los modelos orientados a objetos, que están más próximos a los modelos conceptuales.

Los modelos físicos describen cómo se almacenan los datos en el ordenador: el formato de los registros, la estructura de los ficheros (desordenados, ordenados, etc.) y los métodos de acceso utilizados (índices, etc.).

A la descripción de una base de datos mediante un modelo de datos se le denomina esquema de la base de datos. Este esquema se especifica durante el diseño, y no es de esperar que se modifique a menudo. Sin embargo, los datos que se almacenan en la base de datos pueden cambiar con mucha frecuencia: se insertan datos, se actualizan, etc. Los datos que la base de datos contiene en un determinado momento se denominan estado de la base de datos u ocurrencia de la base de datos.

La distinción entre el esquema y el estado de la base de datos es muy importante. Cuando definimos una nueva base de datos, sólo especificamos su esquema al SGBD. En ese momento, el estado de la base de datos es el “estado vacío”, sin datos. Cuando se cargan datos por primera vez, la base datos pasa al “estado inicial”. De ahí en adelante, siempre que se realice una operación de actualización de la base de datos, se tendrá un nuevo estado. El SGBD se encarga, en parte, de garantizar que todos los estados de la base de datos sean estados válidos que satisfagan la estructura y las restricciones especificadas en el esquema. Por lo tanto, es muy importante que el esquema que se especifique al SGBD sea correcto y se debe tener muchísimo cuidado al diseñarlo. El SGBD almacena el esquema en su catálogo o diccionario de datos, de modo que se pueda consultar siempre que sea necesario.