Modelos de datos

Modelos de datos

¿Cuáles son las herramientas que necesita un diseñador de base de datos cuando
se enfrenta a una necesidad o problema de la realidad?

¿Cómo define qué datos se necesitan para darle herramientas al usuario para que
registre la información y luego cuente con ella para su explotación?

En este curso nos vamos a enfocar en los modelos relacionales, explicando todos
los pasos del diseño de las bases de datos. Se comienza por el diseño conceptual,
luego continuamos con el diseño lógico para terminar con el diseño físico, que es
donde se va a registrar la información, que luego deberá ser verificada en el
proceso de testing.

En la figura siguiente se muestra el proceso de modelado de una base de datos

relacional.

Figura 1- Modelado de la base de datos

Base de Datos Relacional

Base de datos relacional

Una base de datos relacional, es la que cumple con el modelo relacional, inventado
por Edgar Codd en 1969. Es el más utilizado en la actualidad para implementar
bases de datos. Permite establecer interconexiones (relaciones) entre los datos que
están guardados en tablas, y a través de esas conexiones, relacionar los datos de
ambas tablas. De ahí proviene el nombre de “Modelo relacional”.

Modelo conceptual
Es la primera etapa en el diseño de una base de datos. Son modelos de muy alto
nivel y están orientados a decidir qué datos son los interesantes para la necesidad
del mundo real que tenemos y como se relacionan entre sí esos datos. No debe
incluir ningún elemento asociado a la implementación, así como tampoco
elementos orientados a la performance base de datos que se creará. La salida de
esta etapa es el Modelo de Entidad Relación.

Lógico

Orientado a expresar manipulaciones en forma abstracta para que sea viable

realizar implementaciones sobre los varios tipos de manejadores disponibles.

Dependiendo del tipo de aplicación que se está testeando, nos podemos encontrar
con el diseño de una base de datos transaccional o de Data Warehouse, por
ejemplo. En ese caso podemos encontrarnos con un modelo lógico que sigue el
esquema de modelo Estrella o modelo de Copos de nieve.

Físico

Orientado a definir elementos en DBMS para el correcto almacenamiento de la

información.

Resumen de los tipos de modelos, y la salida que genera cada etapa de diseño. El
profesional de testing, podrá contar con cualquiera de estos elementos para la
comprensión de las bases de datos y de esta manera poder desarrollar
correctamente la verificación de los datos.

  Orientación Salida
Conceptual Objetos y relaciones Modelo Entidad Relación
(MER)
Lógico Operaciones Modelo Relacional
Físico Almacenamiento Database Management
system (DBMS)
 

Caso de estudio

Presentamos el siguiente caso de estudio que utilizaremos a lo largo de todo el

curso, para poder identificar elementos en el diseño de la base de datos.

Se desea crear un registro de cervezas artesanales del Uruguay y sus puntos de

venta. En el registro de cervezas se desea conocer   sus marcas, estilos de cerveza y
características principales. En los puntos de venta: el nombre del comercio, su
dirección, el tipo de comercio (bares, tiendas y restaurantes), email y medio de
venta (on line, local, email, telefónica).
La información relacionada al caso de estudio, está disponible en esta lección y fue
bajada de un set de datos abiertos de Uruguay. 

A continuación, se hará una introducción al modelo conceptual y lógico, para luego

entrar en los Database Management system (DBMS).

Modelo entidad relación (MER)

El Modelo Entidad Relación (MER) fue propuesto por Peter Chen a mediados de los
años setenta. Es el modelo conceptual más ampliamente conocido. Permite crear el
diseño conceptual de una base de datos. Es una representación gráfica y lingüística
de los objetos que forman parte del mundo real.

Conceptos básicos de este modelo son: entidades, relaciones, atributos y claves.

Entidad: es “una persona, lugar, concepto o suceso, real o abstracto de interés para
la empresa”. (Ansi-1977). En modo resumido podemos decir que modelan objetos
de la realidad. Una entidad puede ser un objeto con existencia física, por ejemplo
“cerveza” o “punto de venta” o un objeto con existencia conceptual, por ejemplo
“compañía”.

Atributos: representan propiedades de entidades o relaciones.

Existen atributos simples; estructurados (ejemplo una dirección siempre se

compone de calle, número de puerta, localidad); multivalorados: devuelven más de
un valor para cada entidad (ejemplo registrar más de un teléfono para la entidad);
determinante que es cuando no pueden existir dos entidades en el conjunto que
tengan el mismo valor con ese atributo (ejemplo en una entidad de personas, la
cédula de identidad).

En el ejemplo de las cervezas los atributos pueden ser:

Cerveza artesanal: marca, color, graduación alcohólica, amargura, tamaño

Puntos de venta: nombre, tipo, dirección, teléfono, localidad, email, medioventa.

Relaciones y cardinalidad: modelan asociaciones entre objetos y se define la

cardinalidad entre las relaciones. 

Dado un conjunto de relaciones en el que participan dos o más conjuntos de

entidades, la cardinalidad indica el número de entidades con las que puede estar
relacionada una entidad dada.

Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, las

cardinalidades pueden ser:
  Uno a Uno: (1:1) Un registro de una entidad A se relaciona con solo un
registro en una entidad B. (ejemplo de las cervezas, una marca de cerveza es
fabricada por una sola empresa, y una empresa, solo fabrica una marca de
cerveza) 

 Uno a Varios: (1: N) Un registro en una entidad en A se relaciona con cero o

muchos registros en una entidad B. Pero los registros de B solamente se
relacionan con un registro en A. (ejemplo: sean las dos entidades, marca de
cerveza y distribuidor por departamento:  un distribuidor puede representar
varias marcas de cerveza, pero una marca de cerveza solo puede tener un
distribuidor por departamento).

 Varios a Uno: (N:1) Una entidad en A se relaciona exclusivamente con una

entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas
entidades en A (ejemplo distribuidor por departamento- marca de cerveza.
Puede ser que una cerveza no sea distribuida por nadie en algún
departamento).

 Varios a Varios: (N:M) Una entidad en A se puede relacionar con 0 o con

muchas entidades en B y viceversa (ejemplo puntos de venta- cervezas
artesanales. En un punto de venta se venden varias marcas de cerveza,
mientras que una marca de cerveza es vendida en varios puntos de venta).

Una relación puede tener además atributos que determinan características propias
de la relación.

Un atributo de la relación, es que la cerveza se vende en determinado punto de

venta en un horario determinado.

Las relaciones pueden ser:

            Relaciones n-arias: relaciona hasta n entidades entre si cada vez

            Autorelaciones: relacionan entidades del mismo tipo de entidad

Agregaciones: transforman una relación en una entidad.

Especialización: modela relaciones jerárquicas entre entidades. Permite definir

cuando existen relaciones “es un/a” entre entidades. Supongamos que tenemos un
conjunto de personas de un colegio y queremos distinguir entre alumnos,
profesores, administrativos, adscriptos, director.

Existen especializaciones parciales o totales. Total: todas las instancias de la súper

entidad tienen un correspondiente en alguna de las sub entidades. Parcial, cuando
existen instancias de la súper entidad que no tienen correspondencia con alguna de
las sub entidades.
Especialización disjunta o no disjunta: las instancias pertenecen a una sola de las
sub entidades y no disjunta cuando las instancias pueden pertenecer a más de una
entidad. En el ejemplo del colegio, la sub entidad alumno es disjunta. La de
profesor, administrativo, director, adscripto puede ser no disjunta.

Claves

Una restricción importante que impone el modelo de Entidad Relación es que cada
entidad tiene que tener un atributo o atributos que permita distinguirla dentro de
un conjunto de entidades.

Superclave: es un conjunto de uno o más atributos, que tomados de forma

conjunta permiten identificar de forma única a una entidad en el conjunto de
entidades. Ejemplo la Cédula de identidad de las personas, es suficiente para
distinguir una de otra.

Clave candidata: es una Superclave que no contiene propiamente una Superclave, o

sea, es la combinación de otros atributos que también distinguen a la entidad de
forma única. Ejemplo puedo tomar el nombre de la persona + dirección de la
persona.

Clave primaria: es una clave que se elige entre las anteriores como elemento para
identificar las entidades. Las restantes pasa a ser calves alternativas. El nombre del
atributo (s) se subraya en el MER. En el ejemplo de las personas, podemos tomar la
cédula de identidad como clave primaria.

Notación de entidad y relación

Modelo Relacional

Es un modelo de datos lógico y se usa como modelo implementado por DBMS. Fue
creado por Codd en los años 70 y actualmente es el modelo lógico dominante.

En una base de datos relacional, todos los datos se almacenan y se accede a ellos
por medio de relaciones. El término relación en el modelo relacional es diferente al
utilizado en el MER.

Las relaciones que almacenan datos son llamadas "relaciones base" y su

implementación es llamada "tabla". Otras relaciones no almacenan datos, pero son
calculadas al aplicar operaciones relacionales. Estas relaciones son llamadas
"relaciones derivadas" y su implementación es llamada "vista" o "consulta". Las
relaciones derivadas son convenientes ya que expresan información de varias
relaciones actuando como si fuera una sola y se pueden utilizar como si fuera una
tabla, salvo que en muchos casos no tiene un almacenamiento físico (depende del
DBMS).

Terminología empleada en el modelo relacional:

 Tabla: estructura base, que representa las entidades como las interrelaciones

vistas en el MER.
 Tupla o registro: es cada una de las filas de la tabla
 Atributo o campo: es cada una de las columnas de la tabla. Todos los
registros o tuplas de una tabla tienen igual número de atributo o campos.
 Cardinalidad: es el número de tuplas de la tabla
 Grado: es el número de atributos de la tabla
 Dominio de un atributo: es el conjunto de valores que puede tomar dicho
atributo.
 Clave candidata: conjunto mínimo de atributos que identifican de forma
univoca cada tupla de una relación.
 Clave principal o primaria: clave candidata elegida para identificar las tuplas
de una relación. Las restantes claves candidatas que no han sido elegidas
como claves primarias de una relación son claves alternativas.
 Clave foránea o externa: conjunto de atributos en una relación que es una
clave primaria en otra (o incluso en la misma)

Ejemplo de esquema de BD relacional:

Cervezas-artesanales (id-cerveza, Brand, color, …)

Puntos de venta (id-punto de venta, name, venue-tupe, …)

 
Ejemplo de instancia en un DBMS:

En el ejemplo podemos ver las dos tablas que se derivan del esquema relacional:
tabla Cervezas Artesanales y tabla Puntos de Venta.

Requisitos de una tabla en una base de datos relacional

 Debe tener un número fijo de atributos para todas las tuplas

 Cada atributo tiene un único dominio
 El orden de las tuplas y atributos no es relevante (puede existir algún caso
que si lo sea)
 No puede haber dos tuplas iguales (la definición de clave primara lo
prohíbe)
 Cada intersección fila-columna debe contener un único valor perteneciente
al dominio del a columna correspondiente

Reglas de integridad

Es muy importante tener en cuenta las reglas de integridad al hacer el testing de la

base de datos.

Las operaciones que pueden afectar a la integridad de los datos son la inserción,
modificación y borrado de registros en la base de datos.

Las tres principales restricciones que forman parte del modelo relacional son

 Integridad de entidad: ningún atributo que forme parte de la clave primaria

de una relación puede tomar el valor nulo o desconocido.
 Integridad de clave: los valores de las claves candidatas deben ser únicos en
cada tabla.
  Integridad referencial: indica que los valores de la clave foránea en la
relación “hijo” deben corresponder con los valores de la clave primaria
“padre”, o ser nulos si es que se permite ese valor.

Para la inserción o modificación, al introducir un valor de una clave foránea si el

valor es no nulo (si es permitido), debe existir en todas las relaciones en las que la
clave foránea sea clave primaria.

No se permite eliminar una tupla de una relación cuyo valor de clave primaria exista
como valor de clave foránea de otra relación.

Por ejemplo, el departamento/city es una clave foránea en la tabla Puntos de Venta

a la tabla Localidad. Se permite que haya varios Punto de Venta para cada
departamento/localidad, pero habrá uno y sólo departamento/localidad para cada
Punto de venta.  

Puntos de venta:

id name venue_type department city

15 Pacharán Restaurant Montevideo Montevideo
87 Iberpark (Costa Urbana) Tienda Canelones Ciudad de la
Costa
117 Jager Bar Bar Cerro Largo Melo
118 Girasoles Almacén Tienda Montevideo Montevideo
Natural
119 Mala Junta Bar Montevideo Montevideo
120 Surea Bar Canelones Las Toscas
 

Localidad
Departament Localidad
o
Montevideo Montevideo
Canelones Ciudad de la costa
Cerro Largo Melo
Canelones Las Toscas
En la siguiente figura se muestra como se representaría esta relación en un DBMS:
Transformación de un MER a un modelo relacional

Una vez obtenido el esquema conceptual mediante el MER los pasos a seguir son:

 Transformar el diagrama MER en modelo relacional

 Aplicar reglas de normalización

Las tres reglas básicas para transformar el diagrama MER al modelo relacional son:

 Toda entidad se transforma en una relación

 Las relaciones N a M se transforman en una relación
 Las relaciones 1 a N dan lugar a una relación o a una propagación de clave

Para ampliar más información sobre esta técnica puede consultar:

"Fundamentals_of_Database_Systems" 7th_Edition, 2010, Elmarsi-Navathi

El modelo relacional, para el modelado y la gestión de bases de datos, es

un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos.

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios
IBM en San José (California), no tardó en consolidarse como un nuevo paradigma
en los modelos de base de datos.

Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse

en forma lógica como conjuntos de datos llamados tuplas. Pese a que esta es la
teoría de las bases de datos relacionales creadas por Codd, la mayoría de las veces
se conceptualiza de una manera más fácil de imaginar, pensando en cada relación
como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería
un registro o "tupla") y columnas (también llamadas "campos").
Es el modelo más utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente.

Diseño Físico

La fase anterior al diseño físico es el diseño lógico de la base de datos. Mientras el

diseño lógico se interesa del QUE, el diseño físico se interesa por el COMO.  En
particular, uno de los temas que también se debe tener en cuenta es cómo
funciona el DBMS seleccionado.

El diseño físico es el último paso del proceso de diseño en el cual, teniendo

presente el requisito de procesos y características del DBMS, Sistema operativo y el
hardware disponible, se deben cumplir los siguientes objetivos:

 Disminuir los tiempos de respuesta.

 Minimizar espacio de almacenamiento.
 Evitar las reorganizaciones.
 Proporcionar la máxima seguridad.
 Optimizar el consumo de recursos.

Modelo Físico- Conceptos básicos de DBMS

Una base de datos registra un conjunto de datos relacionados entre sí, creados
para un propósito específico. Por lo tanto, seguimos con el concepto de que los
datos hacen referencia a hechos conocidos que pueden guardarse y que tienen un
significado específico.

Nombre Teléfono Dirección Localidad País

María 123456 Martin Pérez Montevideo Uruguay
222
Juan 444888 Artigas 333 Tacuarembó Uruguay
 

Este ejemplo puede aplicarse a una base de datos de clientes de una empresa. Los
datos deben estar organizados de una forma lógica y no aleatoria, por lo que
podemos entender que no todas las colecciones de datos son bases de datos. El
tamaño y la complejidad de la base de datos, depende del problema que se está
resolviendo. Podemos tener una base de datos sólo con un listado de personas,
que pueden ser los clientes de una empresa, o tener una base de datos, no solo
con los clientes de la empresa, sino que también con las operaciones que tiene ese
cliente en un banco, por ejemplo, los préstamos que ha sacado.

Por lo tanto, la información tiene que registrarse de forma organizada y controlarse

para que pueda ser accedida y manipulada cuando se necesite. Además, su
almacenamiento y acceso posterior deben ser eficientes, y la información debe ser
de calidad para que sea útil al momento de utilizarla.

La DB (data base) es solo un “almacén” de datos, lo que ha hecho indispensable el

desarrollo de sistemas que los administren y procesen, siendo estos los DBMS.
Los DBMS (Data Base Management System): son las siglas en inglés para los
Sistemas de Gestión de Bases de Datos (SGBD). Los DBMS es un software
especializado en la manipulación de la Base de Datos: controla la organización,
almacenamiento, recuperación, seguridad e integridad de los datos en una base de
datos con el objetivo de servir de interfaz entre la base de datos, los usuarios y las
aplicaciones utilizadas. El propósito general de los DBMS es el de manejar de
manera clara, sencilla y ordenada, los datos de una Base de Datos (DB) que
posteriormente se convertirán en información relevante, para un buen manejo de
los datos.

Funciones de un DBMS

Las funciones principales de un DBMS son las siguientes:

Definición de los datos: Para especificar tipos de datos, estructuras de datos y

restricciones de datos. El DBMS ha de poder definir todos los objetos de la base de
datos partiendo de definiciones en versión fuente para convertirlas en la versión
objeto.

Construcción: Para guardar los datos en un dispositivo de almacenamiento,

controlado por un DBMS.

Manipulación de los datos: para poder consultar y actualizar o suprimir la

información. El manejo de los datos debe ser de forma rápida, según las peticiones
de los usuarios.

Seguridad e integridad de los datos: Además de registrar el uso de las bases de

datos, ante cualquier petición, también aplicará las medidas de seguridad e
integridad de los datos (adopta medidas garantizar su validez) previamente
definidas. Un DBMS debe garantizar su seguridad frente a ataques o simplemente
impedir su acceso a usuarios no autorizados por cualquier razón.
Recuperación y restauración de los datos: La recuperación y restauración de los
datos ante un posible fallo es otra de las principales funciones de un DBMS. Su
aplicación se realizará a través de un Plan de recuperación y restauración de los
datos que sirva de respaldo.

Gracias a este software el usuario puede gestionar la base de datos (almacenar,

modificar y acceder a la información registrada en la misma) mediante el uso de
distintas herramientas que han sido construidas para su análisis, con las que puede
realizar consultas y posteriormente generar informes. Además de gestionar los
datos y mantener su consistencia, su utilización supone numerosas ventajas a la
hora de construir y definir la base de datos a diferentes niveles de abstracción para
distintas aplicaciones, pues facilita los procesos y también su mantenimiento.

En la siguiente lección presentaremos con más profundidad los DBMS.