15.1. Introducción a Bases de Datos Lesson:

Antes de utilizar PostgreSQL, vamos a asegurarnos de nuestro terreno cubriendo la teoría de base de datos general. No es necesario ingresar algún código de ejemplo; sólo existe para fines de ilustración.

La meta para esta lección: Para entender los conceptos fundamentales de los conceptos de base de datos.

15.1.1. ¿Qué es una base de datos?

Una base de datos consiste de una colección organizada de datos para uno o más usuarios, típicamente en forma digital. - Wikipedia

Un Sistema de Administración de base de datos (DBMS) consiste de software que opera base de datos, para el almacenamiento, acceso, seguridad, respaldo y otras facilidades. - Wikipedia

15.1.2. Tablas

En base de datos relacionales y base de datos de archivo plano, una tabla es un conjunto de elementos de dato (valores) que se organizan mediante un modelo de columnas verticales (que están identificadas por su nombre) y filas horizontales. Una tabla tiene un numero especifico de columnas pero puede tener cualquier numero de filas. Cada fila se identifica por los valores que aparecen en un subconjunto de columna en particular que ha sido identificado como una llave candidata. - Wikipedia

 id | name  | age
----+-------+-----
  1 | Tim   |  20
  2 | Horst |  88
(2 rows)

En base de datos SQL una tabla también es comocida como una relación

15.1.3. Columnas / Campos

Una columna es un conjunto de valores de datos de un tipo simple particular, uno para cada fila de la tabla. Las columnas proporcionan la estructura de acuerdo a que filas por las que esta compuesta. El campo término se utiliza a menudo como sinónimo de la columna, aunque muchos consideran que es más correcto utilizar el campo (o valor de campo) para referirse específicamente al único elemento que existe en la intersección entre una fila y una columna. - Wikipedia

Una columna:

| name  |
+-------+
| Tim   |
| Horst |

Un campo:

| Horst |

15.1.4. Registros

Un registro es la información almacenada en una fila de tabla. Cada registro tiene un campo para cada una de las columnas en la tabla.

2 | Horst |  88  <-- one record

15.1.5. Tipo de datos

Tipo de datos restringe el tipo de información que puede ser almacenada en una columna. - Tim y Horst

Hay muchas clases de tipos de datos. Enfoquemonos en los más comunes:

  • Cadena - para almacenar datos de texto de formato libre

  • Entero - para almacenar números enteros

  • Real - para almacenar números decimales

  • Fecha - para guardar el cumpleaños de Horst para que nadie se olvide

  • Booleano - para almacenar valores simples verdaderos/falsos

Puede decirle a la base de datos que le permita no almacenar nada en un campo. Si no hay nada en un campo, entonces el contenido del campo se denomina como valor “null”:

insert into person (age) values (40);

select * from person;

Resultado:

id | name  | age
---+-------+-----
 1 | Tim   |  20
 2 | Horst |  88
 4 |       |  40  <-- null for name
(3 rows)

Hay muchos más tipos de datos que puede usar - `!consulte el manual de PostgreSQL!<https://www.postgresql.org/docs/current/datatype.html>`_

15.1.6. Modelización de una dirección de base de datos

Vamos a utilizar un caso de estudio sencillo cómo se construye una base de datos. Queremos crear una dirección base de datos.

Try Yourself basic

Anotar las propiedades que forma una dirección sencilla y que desea almacenar en nuestra base de datos.

Respuesta

Para nuestra tabla de direcciones teórica, podríamos querer almacenar las siguientes propiedades:

House Number
Street Name
Suburb Name
City Name
Postcode
Country

Al crear la tabla para representar un objeto de dirección, crearíamos columnas para representar cada una de estas propiedades y las nombraríamos con nombres compatibles con SQL y posiblemente abreviados:

house_number
street_name
suburb
city
postcode
country

Estructura de Dirección

Las propiedades que describen una dirección son las columnas. El tipo de información almacenada en cada columna es su tipo de dato. En la siguiente sección analizaremos nuestra tabla de dirección conceptual para ver ¡cómo podemos hacerlo mejor!

15.1.7. Teoría de base de datos

El proceso para crear una base de datos implica la creación de un modelo del mundo real; tomando conceptos del mundo real y representándolos en la base de datos como entidades.

15.1.8. Normalización

Una de las ideas principales de una base de datos es para evitar duplicidad / redundancia. El proceso de eliminar redundancia de una base de datos se llama normalización.

Normalización es una forma sistemática de asegurar que una estructura de base de datos es adecuada para consultas de propósito general y libre de ciertas características indeseables-inserción, actualización y eliminación de anomalías- que podrían conducir a una pérdida de la integridad de los datos.

Hay diferentes tipos de normalización “formas”.

Echemos un vistazo a un ejemplo sencillo:

Table "public.people"

Column    |          Type          |                Modifiers
----------+------------------------+------------------------------------
 id       | integer                | not null default
          |                        | nextval('people_id_seq'::regclass)
          |                        |
 name     | character varying(50)  |
 address  | character varying(200) | not null
 phone_no | character varying      |
Indexes:
 "people_pkey" PRIMARY KEY, btree (id)

select * from people;

id |     name      |           address           |  phone_no
---+---------------+-----------------------------+-------------
 1 | Tim Sutton    | 3 Buirski Plein, Swellendam | 071 123 123
 2 | Horst Duester | 4 Avenue du Roix, Geneva    | 072 121 122
(2 rows)

Imagine que tiene muchos amigos con el mismo nombre de calle o ciudad. Cada vez que se duplican estos datos, se consume espacio. Peor aún, si el nombre de una ciudad cambia, tiene que hacer mucho trabajo para actualizar su base de datos.

15.1.9. Try Yourself basic

Rediseñar la tabla teórica personas anterior para reducir duplicidad y para normalizar la estructura de datos.

Puede leer más sobre la normalización de la base de datos aquí

Respuesta

El mayor problema con la tabla personas es que hay un solo campo de dirección que contiene la dirección completa de una persona. Pensando en nuestra tabla teórica dirección anterior en esta lección, sabemos que una dirección se compone de muchas propiedades diferentes. Al almacenar todas estas propiedades en un campo, hacemos que sea mucho más difícil actualizar y consultar nuestros datos. Por lo tanto, necesitamos dividir el campo de dirección en varias propiedades. Esto nos daría una tabla que tiene la siguiente estructura:

id |     name      | house_no |  street_name   |    city    |   phone_no
 --+---------------+----------+----------------+------------+-----------------
 1 | Tim Sutton    |     3    | Buirski Plein  | Swellendam | 071 123 123
 2 | Horst Duester |     4    | Avenue du Roix | Geneva     | 072 121 122

En la siguiente sección, aprenderá sobre las relaciones de clave externa que podrían usarse en este ejemplo para mejorar aún más la estructura de nuestra base de datos.

15.1.10. Índices

Un índice de base de datos es una estructura que mejora la velocidad de operaciones de recuperación de datos en una tabla de base de datos. - Wikipedia

Imagínese que está leyendo un libro de texto y buscando la explicación de un concepto, ¡y el libro de texto no tiene índice! Tendrá que comenzar a leer en una sola portada y recorrer todo el libro hasta que encuentre la información que necesita. El índice al final de un libro le ayuda a pasar rápidamente a la página con la información relevante:

create index person_name_idx on people (name);

Ahora las búsquedas por nombre serán más rápidas:

Table "public.people"

Column   |          Type          |               Modifiers
----------+------------------------+-------------------------------------
 id       | integer                | not null default
          |                        | nextval('people_id_seq'::regclass)
          |                        |
 name     | character varying(50)  |
 address  | character varying(200) | not null
 phone_no | character varying      |
Indexes:
 "people_pkey" PRIMARY KEY, btree (id)
 "person_name_idx" btree (name)

15.1.11. Secuencias

Una secuencia es un generador de números único. Se utiliza normalmente para crear un identificador único para una columna en una tabla.

En este ejemplo, id es una secuencia: el número se incrementa cada vez que se agrega un registro a la tabla:

id |     name     |           address           |  phone_no
---+--------------+-----------------------------+-------------
 1 | Tim Sutton   | 3 Buirski Plein, Swellendam | 071 123 123
 2 | Horst Duster | 4 Avenue du Roix, Geneva    | 072 121 122

15.1.12. Diagrama de entidad relación

En una base de datos normalizada, normalmente tiene muchas relaciones (tablas). El diagrama entidad-relación (diagrama ER) se utiliza para diseñar las dependencias lógicas entre las relaciones. Considere nuestra tabla de personas no normalizada de antes en la lección:

select * from people;

 id |     name     |           address           |  phone_no
----+--------------+-----------------------------+-------------
 1  | Tim Sutton   | 3 Buirski Plein, Swellendam | 071 123 123
 2  | Horst Duster | 4 Avenue du Roix, Geneva    | 072 121 122
(2 rows)

Con un pequeño trabajo podemos dividirlo en dos tablas, eliminando la necesidad de repetir el nombre de la calle para individuos que viven en la misma calle:

select * from streets;

 id |     name
----+--------------
 1  | Plein Street
(1 row)

y:

select * from people;

 id |     name     | house_no | street_id |  phone_no
----+--------------+----------+-----------+-------------
  1 | Horst Duster |        4 |         1 | 072 121 122
(1 row)

Podemos entonces enlazar las dos tablas utilizando las “claves” streets.id y people.streets_id.

Si dibujamos el diagrama ER para estas dos tablas se vería algo así:

../../../_images/er-people-streets.png

El diagrama ER nos ayuda a expresar relaciones “uno a muchos”. En este caso, el símbolo de flecha muestra que una calle puede tener mucha gente viviendo en ella.

Try Yourself moderate

Nuestro modelo personas tiene aún problemas de normalización - intente ver si se puede normalizar aún más y mostrar sus ideas por medio de un diagrama de ER.

Respuesta

Nuestra tabla de personas actualmente se ve así:

id |     name     | house_no | street_id |  phone_no
---+--------------+----------+-----------+-------------
 1 | Horst Duster |        4 |         1 | 072 121 122

La columna street_id representa una relación de “uno a muchos” entre el objeto de personas y el objeto de calle relacionado, que se encuentra en la tabla calles.

Una forma de normalizar aún más la tabla es dividir el campo de nombre en first_name y last_name:

id | first_name | last_name  | house_no | street_id |  phone_no
---+------------+------------+----------+-----------+------------
 1 |    Horst   |   Duster   |     4    |     1     | 072 121 122

También podemos crear tablas separadas para el nombre del pueblo o ciudad y el país, vinculándolas a nuestra tabla personas a través de relaciones “uno a muchos”:

id | first_name | last_name | house_no | street_id | town_id | country_id
---+------------+-----------+----------+-----------+---------+------------
 1 |    Horst   |   Duster  |     4    |     1     |    2    |     1

Un diagrama ER para representar esto se vería así:

../../../_images/er-people-normalised-example.png

15.1.13. Restricciones, claves primarias y claves foráneas

Una restricción de base de datos se utiliza para asegurar que datos en un relación coinciden con la vista del modelador de cómo ese dato debería ser almacenado. Por ejemplo una restricción en su código postal podría asegurar que el número cae entre 1000 y 9999.

Una clave primaria es uno o más valores de campo que hacen un único registro. Normalmente la clave primaria es llamada id y es una secuencia.

Una clave foránea es utilizada para referirse a un registro único en otra tabla (utilizando la clave primaria de esa otra tabla).

En diagramas de ER, el enlace entre tablas se basa normalmente en claves foráneas que enlazan con claves primarias.

Si miramos nuestro ejemplo de personas, la definición de la tabla muestra que la columna de la calle es una clave externa que hace referencia a la clave principal en la tabla de calles:

Table "public.people"

 Column    |         Type          |  Modifiers
-----------+-----------------------+--------------------------------------
 id        | integer               | not null default
           |                       | nextval('people_id_seq'::regclass)
 name      | character varying(50) |
 house_no  | integer               | not null
 street_id | integer               | not null
 phone_no  | character varying     |
Indexes:
"people_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
"people_street_id_fkey" FOREIGN KEY (street_id) REFERENCES streets(id)

15.1.14. Transacciones

Al añadir, cambiar o borrar datos en una base de datos, siempre es importante que se deje la base de datos en buen estado si algo va mal. La mayoría de la base de datos proporciona una característica llamada asistencia de transacciones. Las transacciones permiten crear una posición de reversión que se puede volver si sus modificaciones a la base de datos no se han ejecutado como estaba previsto.

Tome un esenario donde tenga un sistema de contabilidad. Necesita transferir fondos de una cuenta y añadirlos a otra. La secuencia de pasos sería algo así:

  • eliminar R20 de Joe

  • añadir R20 a Anne

Si algo va mal durante el proceso (por ejemplo, corte de energía), la transacción se deshace.

15.1.15. In Conclusion

Las bases de datos le permite administrar datos en una forma estructurada utilizando estructuras de código sencillo.

15.1.16. What’s Next?

Ahora que hemos visto en teoría cómo las bases de datos funcionan, vamos a crear una nueva base de datos para implementar la teoría que hemos cubierto.