Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 12
U idad didá ti a
I t odu ió a ase de
datos BD
Presentación
En esta unidad se presentan los elementos principales relacionados al modelado de una BD, partiendo desde
una concepción conceptual hasta un modelado lógico previo a su implementación en un SGBD.
Contenidos
Los temas que trataremos son:
Metodología de diseño de una BD
Tipos de modelos aplicables
Modelo entidad-relación
Modelo relacional
Objetivos
Conocer los objetivos del proceso de diseño de una BD
Conocer los tipos de modelos aplicables
Identificar las características del modelo entidad-relación
Identificar las características del modelo relacional
Conocer las reglas de transformación de un modelo a otro
Introducción
El diseño de BD es el proceso que determina la organización de una BD, su estructura y contenido teniendo
en cuenta el cumplimiento de objetivos de gestión de datos para una organización en particular. Desde sus
inicios por la segunda mitad del siglo XX, se han definido técnicas y buenas prácticas para el diseño de BD,
alcanzando un consenso en la comunidad informática sobre las técnicas a aplicar en cada etapa, sus
requerimientos y sus resultados esperados.
ISIV – Educación a Distancia Pag. 12
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 13
En este contexto, una estrategia a seguir implica descomponer el problema de diseño de la BD en partes o
subproblemas y resolver cada uno de estos con las técnicas y/o herramientas que mejor aplican. Es así como
el diseño de BD en la actualidad se descompone en: diseño conceptual, lógico y físico.
En la primera etapa, el diseño conceptual trata de plasmar en un esquema los requisitos del usuario en
cuanto a qué elementos del mundo real se van a registrar en la BD. De esta manera, se obtiene una
descripción de alto nivel de la estructura de la BD que resulta independiente del SGBD a utilizar para su
implementación definitiva. Para generar este modelo conceptual se usará algún formalismo cuyo objetivo
será reflejar el contenido de la BD a desarrollar y las relaciones que puedan definirse en el mismo, no
considerará estructuras ni métodos puntuales de almacenamiento.
Posteriormente, el diseño lógico, usa como punto de partida el resultado del diseño conceptual para generar
un esquema lógico en donde se define la arquitectura de la BD en términos de las estructuras que puede
procesar un SGBD. En este caso, nuevamente se recurre a algún tipo de formalismo que define un modelo a
generar, pudiendo ser: un modelo relacional, un modelo de red, un modelo jerárquico, entre otros. Por este
motivo, el tipo de modelo lógico a generar deberá estar intrínsecamente relacionado con el tipo de motor de
BD que vaya a ser empleado posteriormente.
Finalmente, el diseño físico toma como insumo al modelo lógico generado previamente y lo implementa a
través de algún lenguaje que describa cómo se va a generar la BD. Este esquema físico es dependiente del
SGBD en concreto que se vaya a utilizar y por lo tanto se utilizará su lenguaje de definición de datos. Además
de definir e implementar las estructuras de la BD se podrán crear diferentes métodos para facilitar el acceso
a los datos. El desarrollo de esta fase del diseño será abordado en la Unidad III.
Modelos de datos
Un modelo es una representación de una entidad, sistema o porción de la realidad. En el contexto de este
documento, los modelos de datos describen a los datos y las relaciones que existen entre ellos para un
escenario o problema en particular.
Se ha mencionado previamente que existen dos tipos de modelos de datos, los conceptuales y los lógicos.
Los conceptuales representan la realidad con un alto nivel de abstracción, mientras que los lógicos las
descripciones de los datos tienen una mayor correspondencia con la estructura de una BD.
Los modelos de tipo conceptual serán los primeros en ser utilizados en el proceso de diseño de una BD para
obtener una descripción general de los datos que deben manejarse para el problema en cuestión.
Posteriormente, a través de un modelo lógico se transforma esa descripción general a una abstracción que
es mucho más cercana a la organización de una BD. Este trabajo en dos fases tiene por objetivo reducir la
complejidad de la tarea de diseño, además de proveer resultados intermedios como es el modelo conceptual
que pueden servir para identificar errores de interpretación que no serán posteriormente integrados en el
modelo lógico a partir de una revisión.
En general los modelos conceptuales deben presentar las siguientes características:
Expresividad para representar claramente a la realidad.
Simplicidad para favorecer su comprensión.
ISIV – Educación a Distancia Pag. 13
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 14
Minimalidad para que un mismo concepto no pueda tener diferentes interpretaciones.
Formalidad para que el esquema de modelado sea comprensible por otros además de su(s) autor(es),
esto se logra a partir del seguimiento de un formalismo en su definición.
Tipos de modelos
Los modelos de datos suelen estar clasificados en tres categorías:
1. Modelos lógicos basados en objetos: usados generalmente para describir datos en un nivel
conceptual. Ejemplos de esta categoría son:
a. Modelo entidad - relación.
b. Modelo binario.
c. Modelo semántico de datos.
d. Modelo infológico.
2. Modelos lógicos basados en registros: usados generalmente para describir datos en los niveles
conceptual y físico. Utilizan registros e instancias para representar la realidad y permiten definir la
estructura lógica de la BD. Ejemplos de esta categoría son:
a. Modelo relacional, donde los datos y las relaciones se expresan a través de tablas que
pueden estar relacionadas entre sí a partir de diferentes columnas.
b. Modelo de red, donde los datos se representan mediante registros y las relaciones entre
ellos a través de aristas como si se tratara de un grafo.
c. Modelo jerárquico, que respeta los mismos lineamientos del modelo de red pero lo hace a
través de una estructura de árbol.
3. Modelos físicos de datos: operan en un nivel más bajo y permiten identificar o definir diversos
detalles de implementación relacionados al almacenamiento de los datos en un dispositivo hardware.
Ejemplos de esta categoría son:
a. Modelo unificador.
b. Modelo de memoria de cuadros.
En las próximas secciones se presentan los modelos a emplear para las diferentes etapas de diseño de una
BD.
Modelo entidad - relación
Es un modelo de representación conceptual por lo que se lo puede asociar a una instancia inicial de diseño
de una BD. Hace uso de una simbología particular para representar los elementos del mundo real que serán
ISIV – Educación a Distancia Pag. 14
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 15
almacenados en la BD. No cuenta con una implementación física y sus principales componentes son las
entidades y las relaciones.
Una entidad es un objeto real del cual se desea almacenar datos por medio de sus propiedades o atributos.
La distinción entre entidades se logra a partir de sus atributos, que serán particulares a ella. Estos atributos
tendrán rangos de valores posibles, lo que se denomina dominio. Por ejemplo:
Entidad Atributos
Persona ● CUIL
● Nombre
● Apellido
● Sexo
● Fecha_nacimiento1
Automóvil ● Nro_chasis
● Nro_motor
● Marca
● Modelo
● Anio_fabricacion2
Cuenta_bancaria ● CBU_numerico
● CBU_alias
● Saldo
● Nro_cuenta
En el modelo entidad - relación (MER) las entidades se representan a través de rectángulos y los atributos se
expresan mediante óvalos conectados a la entidad en cuestión (ver figura 3).
1
Los nombres de atributos (y entidades) no deben tener espacios en blanco, por lo que al momento de necesitar
expresar un atributo cuyo nombre se componga de dos o más términos se podría usar una división de las palabras
mediante guiones ajos _ .
2
Los nombres de atributos (y entidades) usualmente se escriben desde esta fase de diseño en un lenguaje que pueda
se llevado a la i ple e ta ió de u a BD po lo ue a a te es o o la o o a e tos o suele e plea se dado
que no todos los SGBD los aceptan.
ISIV – Educación a Distancia Pag. 15
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 16
Figura 3. Ejemplo de definición de una entidad en un MER.
Una relación se define como una asociación entre dos o más entidades. Es así como las diferentes entidades
del modelo van a poder representar los vínculos que existen entre ellas en la realidad. Por ejemplo:
Clientes Relación: Cuentas_bancarias
CUIL Apellido titular_de Nro_cuenta Saldo
20-12345678-0 López ==> 24237190 5000.00
23-23456789-1 Gómez ==> 24238245 35670.00
==> 24337233 12800.04
27-34567890-1 Pérez ==> 23838901 8023.26
el eje plo a te io se puede o se va dos e tidades Clientes Cuentas_bancarias . ada u a de
ellas con sus atributos:
● Clientes
○ CUIL
○ Apellido
● Cuentas_bancarias
○ Nro_cuenta
○ Saldo
ISIV – Educación a Distancia Pag. 16
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 17
Y ade ás se a ep ese tado la ela ió titular de ue esta le e el vínculo existente entre un cliente de
una entidad bancaria y las cuentas que tiene a su nombre (pudiendo ser una o más, como en el caso del
cliente Gómez que registra dos cuentas).
Una relación podría incorporar atributos que ayuden a lograr una representación más adecuada de la
realidad. Además, una relación podría estar definida con una única entidad, lo que se determina una relación
recursiva. A nivel de representación, en el MER las relaciones se expresan a través de rombos que indican en
su interior el nombre de la relación (ver figura 4).
Figura 4. Ejemplo entidades relacionadas en un MER.
Cardinalidad de una relación
Ante la definición de una relación, se suele expresar la cantidad de elementos o instancias de una entidad
que se pueden asociar con la otra entidad. Es así como se tienen las siguientes opciones de cardinalidad:
● UNA A UNA (expresada generalmente como 1:1): una instancia de la entidad A puede relacionarse
como máximo con una instancia de la entidad B (ver figura 5).
En este caso, la relación de la igu a de e lee se o o una provincia tiene una ciudad como capital
y una ciudad puede ser capital únicamente de una provincia . sta le tu a idi e io al de la ela ió
es la que representa la cardinalidad.
Un detalle de representación es que la cardinalidad uno se expresa con una punta de flecha hacia la
e tidad desti o. O si ple e te pod a ag ega se al lado de la ela ió la le e da 1:1 .
ISIV – Educación a Distancia Pag. 17
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 18
Figura 5. Ejemplo de cardinalidad 1:1 en un MER.
● UNA A MUCHAS (expresada generalmente como 1:N): una instancia de la entidad A puede
relacionarse una o más instancias de la entidad B (ver figura 6).
este aso la ela ió de la igu a de e lee se o o un cliente realiza uno o más pedidos, pero un
pedido puede ser realizado por únicamente un cliente .
Un detalle de representación es que la cardinalidad muchas se expresa con una línea sin punta hacia
la e tidad desti o. O si ple e te pod a ag ega se al lado de la ela ió la le e da 1:N .
Figura 6. Ejemplo de cardinalidad 1:N en un MER.
● MUCHAS A UNA (expresada generalmente como N:1): una o más instancias de la entidad A pueden
relacionarse únicamente una instancia de la entidad B (ver figura 7).
este aso la ela ió de la igu a de e lee se o o un alumno cursa una carrera, pero una
carrera puede ser cursada por uno o más alumnos .
Como se mencionó previamente, la cardinalidad muchas se expresa con una línea sin punta hacia la
e tidad desti o. O si ple e te pod a ag ega se al lado de la ela ió la le e da N:1 .
Figura 7. Ejemplo de cardinalidad N:1 en un MER.
ISIV – Educación a Distancia Pag. 18
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 19
● MUCHAS A MUCHAS (expresada generalmente como N:M o N:N): una o más instancias de la
entidad A pueden relacionarse con una o más instancias de la entidad B (ver figura 8).
En este caso, la relación de la figura debe leerse como uno o más docentes dictan una asignatura, y
una asignatura puede ser dictada por uno o más docentes .
Como se mencionó previamente, la cardinalidad muchas se expresa con una línea sin punta hacia la
entidad destino. O simplemente podría agregarse al lado de la ela ió la le e da N:M .
Figura 8. Ejemplo de cardinalidad N:M en un MER.
Claves primarias
Se entiende por clave primaria al atributo que permite identificar en forma unívoca (única e inequívoca) a
una instancia de una entidad. Usualmente al momento de realizar el diseño conceptual de cada entidad se
reconocen uno o más atributos que podrían cumplir esta función, se denominan claves candidatas. Siempre
se deberá priorizar que sean atributos concretamente exclusivos de la entidad. Posteriormente, en el
proceso de diseño de la BD se optará por seleccionar uno o más atributos para que sean la clave primaria
entre las candidatas. En el MER, la clave primaria se expresa a través de subrayar el nombre del atributo.
Por ejemplo:
En este caso, la entidad clientes tiene
representados dos atributos de ejemplo, entre
ellos el atributo CUIL se encuentra subrayado dado
que puede cumplir la función de ser la clave
primaria de la entidad.
Esto se considera válido ya que un número de CUIL
no podría repetirse entre dos o más clientes, por lo
tanto sirve para identificar unívocamente a cada
uno de ellos.
En un caso como el de la entidad pedidos, podría
pasar que no se encuentre un atributo que sea
una clave primaria. En estos casos, se suele
generar un atributo extra para la entidad y es su
clave primaria.
Por convención en este caso se ha empleado
ID_PEDIDO o o o e de at i uto. ste
ISIV – Educación a Distancia Pag. 19
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 20
nombre se construye a partir del prefijo ID (identificador) un guion bajo y el nombre de la entidad en
singular.
ISIV – Educación a Distancia Pag. 20
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 21
Modelo relacional
Es un modelo basado en la teoría de conjuntos en donde todos los datos se estructuran lógicamente en
forma de tablas (también llamadas relaciones en algunas bibliografías). Las tablas conforman la única
estructura del modelo y se componen de un conjunto de filas o tuplas. Cada fila representa a una instancia o
un elemento de una entidad en particular, la tabla en sí representa a toda la entidad. Las columnas de cada
tabla representan los atributos de las entidades.
Una notación aplicable en formato texto es la que plantea a los atributos como parte de un conjunto que es
la tabla, por ejemplo:
ALUMNOS (nro_legajo, dni, nombre, apellido, fecha_nacimiento, sexo)
Nombre de la tabla Listado de atributos
Cada tabla debe tener un nombre que será único en todo el modelo, de igual manera, los nombres de los
atributos dentro de una tabla no pueden repetirse. La clave primaria de una tabla debe estar subrayada y no
pueden existir dos tuplas idénticas dentro de una tabla. Por ejemplo:
CLIENTES(CUIT, razon_social, direccion, telefono)3
PEDIDOS(id_pedido, fecha_recepcion, fecha_entrega)
Estos ejemplos consideran la estructura de las tablas en cuestión, los ejemplos correspondientes a sus
instancias podrían ser como los siguientes:
Tabla CLIENTES:
CUIT razon_social direccion telefono
20-12345678-0 U o“ L Av. Uno 2345 1148645768
23-23456789-1 Dos “. . Dos 2031 PB 3221456789
27-34567890-1 T es so . Av. Tres 4567 2214987654
Se debe notar que en la actualidad existen herramientas software de soporte para el diseño de bases de
datos ue utili a e o a di e ta u a o e latu a de ta las e ve de la ota ió te tual e io ada
previamente. Por una cuestión de compatibilidad y por ser el escenario más común en la actualidad se
pasará a describir tal notación y será utilizada en adelante. Se transforman a continuación los ejemplos
presentados a ese formato (ver figura 9).
3
Nótese que en este caso los nombres de los atributos no se encuentran acentuados, esto se debe al mismo motivo
ue se e e e ió e el aso del uso de la let a p evia e te.
ISIV – Educación a Distancia Pag. 21
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 22
Figura 9. Tablas de ejemplo en formato tabular como se presenta en herramientas software.
Como se puede observar, en este otro formalismo los elementos del modelo son claramente más visuales.
Esto se debe a que constituyen un acercamiento al estilo de trabajo que utilizan las herramientas de diseño
que usualmente acompañan a los SGBD del mercado. Por ejemplo: para el motor de BD MySQL o MariaDB la
aplicación MySQL Workbench / Database Worlbench usa este formalismo para su instancia de diseño de la
estructura de la BD. Si bien existen aplicaciones vinculadas a un SGBD también pueden encontrarse otras
ue so genéricas pe ite vi ula se a u a va iedad de oto es de BD u pli la is a
funcionalidad. Un detalle a considerar es que las claves primarias, generalmente pasan a utilizar su nombre
equivalente en idioma inglés, Primary Key y su abreviatura PK.
Transformación del MER al Modelo Relacional
Para realizar la conversión del MER al modelo relacional (MR) se puede seguir un conjunto de reglas a
ejecutar en forma progresiva. Tales reglas se describen a continuación:
1. Toda entidad del MER se convierte en una tabla. Las claves primarias mantienen esta condición en
el MR.
Por ejemplo, considerando una entidad productos con tres atributos se obtiene una tabla del mismo
nombre y la misma cantidad de atributos / columnas respetando su clave primaria (ver figura 10).
Figura 10. Aplicación de la regla número 1 de conversión MER > MR.
2. Toda relación M:N se transforma en una nueva tabla. Sus atributos son las claves primarias de las
entidades (en este punto ya convertidas a tablas) involucradas en la relación. Además, si hubiese
atributos propios de la relación se incluyen también en la tabla. La clave primaria de la tabla en este
caso es compuesta y se conforma por las claves de las tablas vinculadas. El nombre de la nueva tabla
ISIV – Educación a Distancia Pag. 22
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 23
suele ser una unión de los o es de las ta las o igi ales u idas po u a _x_ .
Por ejemplo considerando una relación con cardinalidad N:M como es docentes que dictan
asignaturas se obtiene una nueva tabla docentes_x_asignaturas que toma las claves de las tablas
originales y, en este caso, agrega un atributo propio definido en la relación (ver figura 11). Debe
notarse que en este caso para representar el vínculo existente entre las tablas se suelen trazar unas
líneas para conectar ambas tablas.
Figura 11. Aplicación de la regla número 2 de conversión MER > MR.
3. Toda relación 1:N (o N:1) es absorbida por la tabla de la cardinalidad muchos. En este caso se
introduce el concepto de clave foránea4 para representar la relación en esa tabla. Esta regla aplica
siempre que la relación no tenga atributos propios, en tal caso se deberá generar una nueva tabla
siguiendo lo establecido en la regla número 2.
Por ejemplo considerando una relación entre clientes y los pedidos que estos realizan, dado que la
relación no tiene atributos, la aplicación de la regla deriva en que en la tabla pedidos que es la que
tiene la cardinalidad muchos incorpora una FK con la PK de la tabla clientes. De esta manera, cada
pedido al momento de ser almacenado en la BD tendrá la información del cliente que lo ha realizado
(ver figura 12).
Usualmente, el atributo que cumple la función de FK en una tabla suele tener en su nombre una
i di a ió de la ta la desde la ual proviene es de i la ta la a la ue se a e la e e e ia de la
4
Se trata de una clave presente en una tabla pero que en realidad es un atributo (clave también) de otra tabla con la
que se establece la asociación en cuestión. Se suele denominar por su nombre en idioma inglés Foreign Key, o su sigla
FK.
ISIV – Educación a Distancia Pag. 23
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 24
relación. En el caso del ejemplo el nombre se construye con el nombre original del atributo y
poste io e te el o e de la ta la cuit_cliente .
Figura 12. Aplicación de la regla número 3 de conversión MER > MR.
4. Toda relación 1:1 es absorbida por una de las tablas involucradas en la relación (mediante el
concepto de clave foránea). Esto se respeta siempre que la relación no presente atributos propios
en cuyo caso, tal como se mencionó en la regla anterior se deberá considerar aplicar el mismo
procedimiento que en la regla número 2. La tabla en la que se agrega la FK será aquella que brinde
una mayor legibilidad al modelo planteado, priorizando así la comprensión del diseño y la utilidad
del mismo para la gestión de los datos en cuestión.
Por ejemplo en una relación entre una provincia y una ciudad que marque la calidad de esta última
de ser capital de la provincia en cuestión, la relación se ha diseñado previamente con la cardinalidad
1:1. En la aplicación de la regla la decisión de la ubicación de la FK podría ser agregarla en la tabla de
p ovi ias dado ue apo ta u a a o legi ilidad al dete i a qué ciudad es la capital de esa
provincia ve igu a 1 .
En este caso, debe notarse que en el ejemplo el nombre del atributo que conforma la FK en la tabla
ciudades tiene el no e id_ciudad_capital e este aso dado ue el o e de la ta la es el
mismo del último término del atributo se ha optado por emplear otro término en su definición para
que mejorar la legibilidad del caso al establecer el motivo de la relación de esa provincia con la
ciudad en cuestión.
ISIV – Educación a Distancia Pag. 24
Folio N°
Sistemas de Base de Datos I – Unidad didáctica 3 25
Figura 13. Aplicación de la regla número 4 de conversión MER > MR.
ISIV – Educación a Distancia Pag. 25
