DBMS

Tipos de gestores de bases de datos

Hay diferentes gestores de base de datos que se pueden clasificar por distintos
criterios.

Si clasificamos los DBMS según el modelo de datos existen los siguientes:

 Relacionales: es el modelo más utilizado y el que estamos viendo en el

curso. La base de este modelo es almacenar la información en tablas que a
su vez están divididas en campos (columnas) y registros (filas). Además, las
tablas se relacionan entre si representando una forma lógica de relacionar
los datos. La forma más habitual de recuperar información en este tipo de
base de datos es mediante consultas. El lenguaje más común para las
consultas es el SQL.
 Jerárquicos: los datos se organizan en forma de árbol. Como limitante es
que no permite representar correctamente la redundancia de datos.
 EnRed: similar a las jerárquicas con la diferencia de que un nodo puede
tener a su vez varios padres. Resuelven el problema de la redundancia.
 Orientados a objetos: de más reciente aparición, aplican el paradigma POO
(Programación orientada a objetos)
 Multidimensionales: similares a las relacionales y utilizadas en casos muy
concretos donde se necesita la representación de varias dimensiones en el
almacenamiento de la información, como por ejemplo cubos OLAP.
 Documentales: permiten el almacenamiento de texto completo. Permiten
recuperar información almacenada en documentos que están estructurados
de alguno modo, como por ejemplo XML. Un ejemplo es MarkLogic
(https://www.marklogic.com/) ubicada en "Challengers" (retadores o
aspirantes) en el cuadrante de Gartner presentado más abajo.

Según Gartner, el mercado de sistemas de bases de datos operacionales (DBMS) se

define como aquellos sistemas que soportan múltiples estructuras y datos de
diferentes tipos, como XML, texto, JavaScript Object Notation (JSON), audio,
imagen y video. Deben incluir mecanismos para aislar los recursos de la carga de
trabajo y controlar diversos parámetros de acceso del usuario final dentro de las
instancias administradas de los datos. [2]

A continuación, presentamos el cuadrante de Gartner publicado en 2019 para

manejadores de bases de datos operacionales, donde se pueden ver los distintos
motores de base de datos existentes en el mercado internacional a la fecha de
publicado el informe [3]. Incluye proveedores de bases de datos no relacionales
(por ejemplo, Amazon DynamoDB) o basados en la nube (por ejemplo, Alibaba
Cluod) las cuales ofrecen nuevas oportunidades para que las empresas puedan
tomar decisiones de modernización. A partir del 2020 Gartner publica el Magic
Quadrant por Cloud Database Management Systms, en el entendido de que la
práctica de gestión de datos, basada en DBMS, continúa cambiando rápidamente a
la nube.  Para esta edición del curso, mantenemos el análisis sobre los
DBMS basados en el informe de Gartner del 2019, que no se refiere exclusivamente
a los DBMS residentes en la nube debido a que se mantienen aún muchos
manejadores que no están en la nube.  Según Gartner para el 2022 el 75% de todas
las bases de datos migrarán o se implementarán en la nube. 

También pueden diferenciarse si son open source o comerciales. Dentro de los

open source se encuentran My SQL, la cual fue comprada por Oracle Corporación
en 2010 y PostgreSQL. Para el informe de Gartner, estos no fueron considerados.

Para el curso, vamos a utilizar el PostgreSQL, en una instalación propia del CES.

[2] Magic Quadrant for Operational Database Management Systems, Published: 12 de octubre

2015 - Analyst(s): Donald Feinberg, Merv Adrian, Nick Heudecker, Adam M. Ronthal, Terilyn
Palanca 

[3] Magic Quadrant for Operational Database Management Systems, Published: 25 de

noviembre 2019-  Analyst(s): Henry Cook, Donald Feinberg, Merv Adrian
Estructura - base de datos relacionales

Las bases de datos relacionales se organizan en dos marcadas secciones: el

esquema y los datos (o instancia) como se indica en la figura 2.

El esquema es la definición de la estructura de la base de datos y principalmente

almacena los siguientes datos:

 El nombre de cada tabla

 El nombre de cada columna
 El tipo de dato de cada columna
 La tabla a la que pertenece cada columna

Las bases de datos relacionales pasan por un proceso al que se le conoce como
normalización, el resultado de dicho proceso es un esquema que permite que la
base de datos sea usada de manera óptima.

Los datos o instancia es el contenido de la base de datos en un momento dado. Es

en sí, es la información registrada en cada una de las tablas.

Figura 2- Sistema de base de datos

Manipulación de la información

El lenguaje más común para construir las consultas a bases de datos relacionales es
SQL (Structured Query Language), un estándar implementado por los principales
motores o sistemas de gestión de bases de datos relacionales. El lenguaje SQL se
verá con más detalle en el tema número 2.
Esquema de base de datos

A continuación, se detallan los elementos que se pueden definir en una base de

datos con un DBMS. Estos elementos deben ser tomados en cuenta por el
profesional de testing en el momento de la verificación de los datos, ya que, así
como las tablas en donde se almacenan los datos, tenemos restricciones, dominios,
claves primarias e índices. Además, los procedimientos almacenados y triggers, son
porciones de programas que modifican los datos y que están almacenados en la
base de datos, y pueden contener gran cantidad de reglas del negocio.

Tablas

La planificación de la estructura de la base de datos, en particular de las tablas, es

vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla
consiste en una descripción de cada uno de los campos que componen el registro y
los valores o datos que contendrá cada uno de esos campos.

Los campos son los distintos datos que componen la tabla, por ejemplo:
nombre, apellido, domicilio. La definición de un campo requiere: el nombre del
campo, el tipo de campo, el ancho del campo, etc.

Los registros constituyen la información que va contenida en los campos de la

tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de
este.

Generalmente los diferentes tipos de datos para cada campo que se pueden
almacenar son los siguientes:

 Texto (caracteres),

 Numérico (números),
 Fecha / Hora,
 Lógico (informaciones lógicas si/no, verdadero/falso, etc.)

En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla

es determinar claramente los campos necesarios, definirlos en forma adecuada con
un nombre especificando su tipo y su longitud. En los numéricos se puede definir
cuantos decimales tendrán y esto es muy importante al momento de verificación de
datos numéricos. Otro tema a tener en cuenta y que puede afectar en la verificación
es el tipo fecha, ya que, al contener la hora, condiciona el tipo de consulta que se
realice.

La nomenclatura es muy importante definirla previamente, y debe ser tanto para

tablas como para campos y cualquier otro objeto de la base de datos que se vaya a
crear.
Siguiendo con el ejemplo de la cerveza artesanal, definimos las siguientes dos
tablas con la relación Cerveza-punto de venta, que como se dijo anteriormente, las
relaciones también se convierten en tablas:

La tabla Cerveza-punto de venta, relaciona las tablas Cervezas Artesanales con

Puntos de venta. Indica en que puntos de ventas se vende cada cerveza artesanal.

Cada uno de los campos tendrá su tipo y su longitud. A continuación, se presenta

un ejemplo de la tabla Puntos de venta, la definición de los campos, y en particular
del campo id_punto_de_venta, que es numérico y es la clave primaria de la tabla.
Restricción

Una restricción es una condición que obliga el cumplimiento de ciertas condiciones

en la base de datos. Algunas no son determinadas por los usuarios, sino que son
inherentemente definidas por el simple hecho de que la base de datos sea
relacional. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar
un campo con valores booleanos true/false.

Las restricciones proveen un método de implementar reglas en la base de datos.

Las restricciones restringen los datos que pueden ser almacenados en las tablas.
Usualmente se definen usando expresiones que dan como resultado un valor
booleano, indicando si los datos satisfacen la restricción o no.

Por ejemplo, podemos decir que el campo “Draft” tiene como restricción dos
valores: True/False.

id brand color alcohol bitterness size draft

1 Bizarra Rubia Medio Bajo 500 cc false
2 Bizarra Rubia Alto Muy alto 500 cc false
4 Cabesas Bier Rubia Medio Medio 500 cc true
5 Cabesas Bier Roja Medio Bajo 500 cc true
6 Cabesas Bier Rubia Medio Medio 500 cc true
7 Cabesas Bier - Sabotaje Negra Alto Medio 500 cc true
8 Cabesas Bier - Atómica Rubia Alto Muy alto 500 cc false
66 Capitán Beer Ambar 7,30% alto 330 false
 

Dominios

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un

dominio restringe los valores del atributo, puede ser considerado como una
restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los
valores de este atributo deben de ser elementos del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha, no procedurales

etc.

 Siguiendo con el ejemplo anterior, podemos decir que el dominio para “Color” es
(rubia, roja, negra, ambar).

Clave única

Cada tabla puede tener uno o más campos cuyos valores identifican de forma única
cada registro de dicha tabla, es decir, no pueden existir dos o más registros
diferentes cuyos valores en dichos campos sean idénticos. Este conjunto de campos
se llama clave única.
Pueden existir varias claves únicas en una determinada tabla, y a cada una de estas
se llama candidata a clave primaria.

Clave primaria

Una clave primaria es una clave única elegida entre todas las candidatas que
define unívocamente a todos los demás atributos de la tabla, para especificar los
datos que serán relacionados con las demás tablas. La forma de hacer esto es por
medio de claves foráneas.

Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave
puede contener valores NULL.

 En el ejemplo de las cervezas, la clave primaria para la tabla “Cervezas artesanales”
es la identificación de la cerveza.

Id_cerveza Brand Color Alcohol bitterness size

53 Bremen Rubia Bajo Bajo 1000 cc
54 Barbot Burton Bitter Rubia Medio Medio chopp
55 Barbot Rubia Medio Medio chopp
56 Barbot De Lobo Porter Negra Medio Medio chopp
 

Clave foránea

Una clave foránea es una referencia a una clave en otra tabla, determina la relación
existente en dos tablas. Las claves foráneas no necesitan ser claves únicas en la
tabla donde están y sí a donde están referenciadas.

Índice

Los índices surgen con la necesidad de tener un acceso más rápido a los datos. Los
índices pueden ser creados con cualquier combinación de campos de una tabla. Las
bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una
de ellas es óptima para cierta distribución de datos y tamaño de la relación.

Es muy importante considerar los índices en el momento de consultar las bases de

datos para la tarea de testing, ya que, si el volumen de datos a testear es muy
grande, se pueden tener muchos problemas de performance si no se utilizan los
mismos.

Procedimientos almacenados

Un procedimiento almacenado es código ejecutable que se asocia y se almacena

con la base de datos. Los procedimientos almacenados usualmente recogen y
personalizan operaciones comunes, como insertar un registro dentro de una tabla,
recopilar información estadística, o encapsular cálculos complejos. Los
procedimientos almacenados no son parte del modelo relacional, pero todas las
implementaciones de motores de base de datos comerciales los incluyen.

En el momento del testing se deben considerar los procedimientos almacenados ya

que son parte del software que se está testeando.

Triggers

Un disparador define una acción que la base de datos debe llevar a cabo cuando se
produce algún suceso relacionado con la misma. Los disparadores (triggers)
pueden utilizarse para completar la integridad referencial, también para imponer
reglas de negocio complejas o para auditar cambios en los datos. El código
contenido en un disparador, denominado cuerpo del disparador, está formado por
bloques PL/SQL. La ejecución de disparadores es transparente al usuario. [1]

Los eventos que hacen que se ejecute un trigger son las operaciones de inserción
(INSERT), borrado (DELETE) o actualización (UPDATE), ya que modifican los datos de
una tabla.

 [1] https://www.todopostgresql.com/postgresql-create-trigger-disparador-
postgresql/ Ultimo acceso julio 2022

Pautas para el diseño

Uno de los temas más importantes al diseñar una base de datos es determinar el
propósito de la base de datos. A continuación, se indican algunos puntos a tener en
cuenta en el proceso de diseño de una base de datos:

Determinar el propósito de la base de datos   Este paso le ayudará a decidir los

datos que desea almacenar y de qué manera.

Si se está diseñando una base de datos transaccional o si se trata de una base de

datos para explotación de datos (DWH), las técnicas de diseño varían mucho.
Asimismo, el contexto de aplicación, puede afectar también, por ejemplo, si se trata
de una base de datos de una aplicación financiera o geográfica.

Perfeccionar el diseño   Luego que ya está el diseño pronto, con las técnicas vistas
en las lecciones anteriores, es bueno que se busquen errores en el diseño. Cree las
tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los
resultados que desea de sus tablas. Haga los ajustes necesarios al diseño.

Normalización. Aplique las reglas de normalización de los datos para comprobar si

las tablas están definidas correctamente. Las bases de datos se normalizan para
evitar la redundancia de datos.
Nomenclatura

 Defina la nomenclatura previamente para todos los objetos de la base de

datos, orientándose a que debe ser entendida por otros profesionales que
no sean de TI.
 No pueden existir dos tablas con el mismo nombre.

Claves principales y foráneas

 La relación entre una tabla padre y un hijo se lleva a cabo por medio de las
claves primarias y foráneas. Esto es recomendable que se lleve a la base de
datos y no se pretenda hacer el control mediante los programas.
 Las claves primarias son la clave principal de un registro dentro de una tabla
y éstas deben cumplir con la integridad de datos. Siempre se debe definir
una clave primaria para cada tabla.

Nulos

 Evite los campos que tendrán en su mayoría valor nulo.

Triggers

 No abusar del uso de triggers ya que son programas que manipulan los
datos y su definición en exceso puede afectar la performance de la base de
datos.

Índices

 La definición de índices debe ser racionalizada y se deben utilizar los

mismos de la forma más óptima posible.

Tuning

 Programar tuning de la base de datos. Muchas veces los problemas de

performance del BD son por el diseño, los cuales no se manifiestan hasta
poner una base de datos en producción ya que los volúmenes de
información en ambientes de testing por lo general son más pequeños.

Históricos

 Históricos: pensar en los históricos que deberá guardar, el periodo necesario

y la forma de depuración o de separación del mismo a otras bases de datos

Interoperabilidad
  Pensar en la interoperabilidad e intercambio de información. Se deben
definir estándares para la definición de códigos y facilitar el intercambio y
comprensión de datos.
 Como ejemplo real, podemos citar la solución de expediente digital provista
por AGESIC que “...permitirá intercambiar expedientes en formato digital con
otros organismos del Estado".  [1].  Además, se cuenta con un catálogo [2]
que presenta información de distintas empresas estatales o para estatales,
por ejemplo, sobre la Caja de Profesionales Universitarios (CJPPU) que,
a partir del documento de una persona, retorna qué profesiones tiene
registrados en CJPPU.  Sería impensable un intercambio de información tan
relevante, si ésta no fuera verificada antes de compartirla con otras
empresas que la necesiten consumir y de la cual pueden depender
decisiones muy importantes (por ejemplo, la actividad laboral o profesional
de una persona).

Seguridad

 Pensar en la seguridad de los datos, si hay datos que son sensibles, si los
datos deben ser encriptados y todo lo referido a la seguridad de la
información.

Calidad de datos

 Finalmente, piense en que la información registrada en la base de datos,

debe ser de calidad, para que todo el proceso de registración y luego
explotación de la misma, cumpla con las expectativas de los usuarios y
consumidores de la misma.

¡Hemos llegado al final del Tema 1! Espero que les haya sido de utilidad la
introducción explicando la importancia de la información, los modelos de datos y
los DBMS. En el tema 2, veremos la importancia de porque testear los datos, como
podemos organizar un testing de datos y comenzaremos con el lenguaje SQL
(Structured Query Language).

 [1] Extraído de https://www.gub.uy/agencia-gobierno-electronico-sociedad-

informacion-conocimiento/comunicacion/noticias/expediente-digital-ministerio-
defensa# , publicado el 29/8/2019

[2] https://www.gub.uy/agencia-gobierno-electronico-sociedad-informacion-
conocimiento/tematica/catalogo-plataforma-interoperabilidad?page=0 ,
consultado el 15/7/2021