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.
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
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
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 |
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
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:
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)
There are many more datatypes you can use - check the PostgreSQL manual!
Vamos a utilizar un caso de estudio sencillo cómo se construye una base de datos. Queremos crear una dirección base de datos.
Anotar las propiedades que forma una dirección sencilla y que desea almacenar en nuestra base de datos.
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!
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.
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’.
Let’s take a look at a simple example:
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.
Rediseñar la tabla teórica personas anterior para reducir duplicidad y para normalizar la estructura de datos.
You can read more about database normalisation here
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
Imagine you are reading a textbook and looking for the explanation of a concept - and the textbook has no index! You will have to start reading at one cover and work your way through the entire book until you find the information you need. The index at the back of a book helps you to jump quickly to the page with the relevant information:
create index person_name_idx on people (name);
Now searches on name will be faster:
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)
Una secuencia es un generador de números único. Se utiliza normalmente para crear un identificador único para una columna en una tabla.
In this example, id is a sequence - the number is incremented each time a record is added to the table:
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
In a normalised database, you typically have many relations (tables). The entity-relationship diagram (ER Diagram) is used to design the logical dependencies between the relations. Consider our non-normalised people table from earlier in the lesson:
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í:
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.
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.
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.
If we look at our people example, the table definition shows that the street column is a foreign key that references the primary key on the streets table:
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)
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.
Las bases de datos le permite administrar datos en una forma estructurada utilizando estructuras de código sencillo.
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.