Modelado de datos

Reglas de negocio
Las reglas de negocios son aquellas reglas que deben cumplir los datos de la base de
datos.

Se debe ser muy preciso y cuidadoso a la hora de obtener estas reglas. Se pueden
recopilar de diversas fuentes, como el personal de la organización, libros de normas y
procedimientos, manuales, etc.

La correcta identificación de las reglas de negocio permitirá realizar un diseño de la base

de datos acorde con los criterios de la organización. Asimismo, conocerlas será de gran
utilidad a la hora de comenzar a modelar la base de datos.

Recordemos que un modelo es “una construcción teórica de la realidad”. Por este motivo,
cuanto más profundo sea el conocimiento de las reglas de negocio, más correcto será el
modelado que realicemos.

Es el diseñador de la base de datos quien debe tener una comprensión completa y cabal
de dichas reglas y saber cuáles deben aplicarse al modelado de la base de datos y cuáles
no. A modo de ejemplo, una regla que afirme que “se considera cliente a quien realizó al
menos una compra” será de utilidad para el modelado. En cambio, una regla que diga “los
clientes de la región A no pueden comprar productos de tipo X” no podrá ser modelada en
el diseño (Aunque luego sí podrá controlarse esta regla mediante la programación de las
aplicaciones que hagan uso de la base de datos).

Una vez identificadas las reglas de negocios, estaremos en condiciones de comenzar el

modelado. No antes. Por esto es de fundamental importancia comprender el problema a
modelar, sus características, la terminología propia de la organización, los nombres y
estándares, entre otros.

Diagrama de Entidad Relación

El diagrama Entidad-Relación es una herramienta gráfica de modelado que los
diseñadores de bases de datos emplean para representar y documentar de manera
sencilla la información requerida por el administrador de datos y/o usuarios del sistema,

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 1

las reglas de negocio, convirtiéndose entonces en un instrumento de comunicación entre
los diseñadores y los usuarios que permite reducir errores de comunicación.

El D.E.R. es una representación conceptual en la que solo se obtienen los datos del
sistema real, características de esos datos, las relaciones existentes entre ellos y las
restricciones correspondientes, dejando de lado aspectos físicos, como tipo de dato,
organización de los archivos o métodos de acceso para el diseño físico.

Se dice que su técnica es de arriba hacia abajo porque comienza identificando a los datos
más relevantes para los usuarios (Entidades), luego se añaden los detalles o características
(Atributos) que definen a esos datos, las relaciones entre dichos datos y, por último, las
restricciones necesarias para los datos y sus relaciones.

Definiremos, entonces, los conceptos empleados:

Entidad: representa un OBJETO del universo de discurso, minimundo o dominio de

problema, que es distinguible de otro objeto por medio de un conjunto de atributos.

Entiéndase:

Objeto: en el sentido amplio, podría ser un objeto físico (ejemplo: artículo), acción
(compra), persona (cliente), concepto: tipo de IVA, etc.

Universo de discurso, minimundo o dominio del problema: abarca la porción del mundo
real que resulta de interés para el usuario y, por tal motivo, se desea representar.

Atributos: características que definen al objeto de interés o entidad.

Ejemplo: número de legajo, razón social, teléfono, email, zona donde se debe entregar la
mercadería, etc., son las características que nos interesa registrar de cada cliente
(Entidad).

Tipos de atributos
Podremos establecer 2 tipos de atributos:

• Obligatorios: necesariamente, ese atributo podrá tener un único valor o entrada.

• Optativos: consideraremos a los atributos NO claves que pudieran no tener un
valor ingresado. Ejemplo, email del cliente: en ese caso, lo denotaremos con un ?
delante para habilitar que ese atributo tenga un valor o ninguno.

Ejemplo:

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 2

 • Legajo
• Nombre
• Apellido
• ? Email

Características de los atributos

• Completos: deben estar todas las características y además los datos no deben
estar partidos. Ejemplo: #avion1, #avion2 y que el nro. de avión sea la
concatenación de #avion1 + #avion2.
• Mutuamente independiente: mal: peso_kg y peso_libras. El problema es que, si
modifico uno, debería modificar el otro.
• Atómicos/Indivisibles: mal: sala-cine. Correcto: *sala

*cine

En este apartado es fundamental destacar que los atributos que no son atómicos o
indivisibles reciben el nombre de “multivaluados”. Esto es, pueden poseer múltiples
valores. A modo de ejemplo, si el atributo “Provincia” tuviese como valor “Formosa,
Córdoba, Chubut” (los tres juntos), sería multivaluado. Esto está estrictamente prohibido.
La forma correcta, entonces, es que el atributo “Provincia” tome el valor “Formosa”, o
bien “Córdoba” o bien “Chubut”, pero nunca más de un valor.

Clasificación de atributos
Nominadores – Descriptivos – Referenciales.

• Atributos Nominadores: son los atributos que identifican de manera unívoca a las
entidades. Estos pueden ser simples (Ejemplo: nro-cliente) o compuestos (nro-
factura, tipo-factura).
• Atributos Descriptivos: describen características de la entidad de interés para el
sistema (Ejemplo: domicilio del proveedor, teléfono, email).
• Atributos Referenciales: permiten relacionar la entidad a la que pertenecen con
otra entidad (Ejemplo: codcategoria de la entidad EMPLEADO permitirá relacionar
a las tuplas de la entidad EMPLEADO con las tuplas correspondientes de la entidad
CATEGORIAS).

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 3

Cada atributo está asociado con un conjunto de valores potenciales que puede tomar y se
llama dominio. El dominio de un atributo es el conjunto de valores permitidos para uno o
más atributos.

Ejemplo:

• Nombre (todas las letras permitidas o la lista de nombres autorizados).

• Temperatura ambiente (rango de valores decimales de -60º a 50ºC).
• Días del mes (valores de 1 a 31).

Reglas de las entidades y los atributos

• Toda entidad tiene un nombre.
• Todo atributo tiene un nombre.
• Las claves primarias no pueden tener valores nulos.
• El nombre de un atributo es único en la entidad.
• La entidad es un conjunto de tuplas.
• Todas las tuplas de una entidad tienen los mismos atributos.
• Las tuplas no tienen orden.
• Para cada tupla, un atributo tiene una única entrada.
• Todos los valores de un atributo son del mismo tipo.
• Cada entidad tendrá varias ocurrencias distinguibles.
Ejemplo: la entidad Provincia tendrá las ocurrencias:
Código_prov1 Buenos Aires
Código_prov2 Córdoba
Código_prov3 Mendoza

Claves
Un atributo nominador es clave cuando identifica unívocamente una tupla de la entidad.

Tupla: cada una de las ocurrencias de la entidad, también llamada instancia de la entidad,
lo cual representa un acontecimiento particular de la entidad. O registro de la futura tabla
del modelo relacional. Es decir que cualquier valor que tome una clave permitirá ingresar
a una única tupla de la entidad. Por lo cual, se desprende que no puede haber 2 tuplas con
la misma clave.

Ejemplo: Cód_artículo (Cada código de art. identificará a un solo artículo).

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 4

 • Súperclave: SK (Super Key): es todo conjunto de atributos que es identificador
único. Ejemplo: Nro-legajo, DNI, Apellido. Con estos datos, siempre se accederá a
una única tupla de la entidad Empleados.
• Claves Candidatas: CK (Candidate Key): es toda súper clave mínima.

En el caso anterior de la entidad EMPLEADOS es suficiente identificador nro-legajo para

identificar a cada empleado. O también se podría identificar a través del DNI solamente.

• Clave Primaria (PK – Primary Key): es aquella clave candidata que el diseñador
considera más adecuada para la aplicación. Normalmente, se conversa con los
analistas funcionales para elegirla, teniendo en cuenta, por ejemplo, el empleo
habitual del usuario de nro. de legajo o la clave candidata más corta, etc.
• Clave Foránea (FK – Foreign Key): es un atributo de la entidad que, a su vez, es PK
de alguna entidad y tiene la función de relacionar ambas tuplas. Generalmente,
una FK hace referencia a la PK de otra entidad. Entonces, podemos concluir que la
Clave Foránea es un atributo que hace referencia a la clave primaria de la entidad
referenciada.
• Clave Simple: es una clave que está compuesta por un solo atributo.
• Clave Múltiple o Concatenada: es una clave que está compuesta por más de un
atributo.

Relación: es una asociación entre dos entidades. Por lo general, un verbo o preposición
que conecta dos entidades implica una relación.

Cardinalidad: definimos como cardinalidad a la cantidad de tuplas de una entidad que

pueden relacionarse con una única tupla de otra entidad.

Una tupla, ocurrencia o instancia de la entidad es una fila de la entidad.

Ejemplo: para la entidad Empleado con atributos: legajo, nombre, apellido. Una tupla o
instancia podría ser: 104, José Manuel, Pérez García Las cardinalidades pueden ser
máximas o mínimas.

Llamamos cardinalidad máxima a la cantidad máxima de tuplas de una entidad que

pueden relacionarse con una única tupla de otra entidad.

Por ejemplo:

• La cantidad máxima de esposas legales, argentinas y actuales que pueden

relacionarse con un esposo a través del vínculo matrimonio es: una.
• La cantidad máxima de dígitos que puede tener un número es: infinito.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 5

 • Una organización puede tener una regla de negocios que indique que cada
vendedor puede tener como máximo 30 clientes.

Llamamos cardinalidad mínima a la cantidad mínima de tuplas de una entidad que

pueden relacionarse con una única tupla de otra entidad.

Por ejemplo:

• La cantidad mínima de padres biológicos (padre y madre) que puede tener una
persona es: dos.
• La cantidad mínima de ingredientes que puede contener una comida es: uno.

En una relación entre dos entidades tendremos, entonces, cardinalidades máximas y

mínimas en ambos extremos de la relación.

Por ejemplo: si la regla de negocios establece que los empleados de una empresa
específica pueden ser asignados como mínimo a ningún proyecto y como máximo a tres
proyectos a la vez y cada proyecto tiene al menos dos empleados asignados.

Aquí, las cardinalidades de la relación de los empleados a los proyectos (que se denota en
el otro extremo de la relación) es cero como mínimo y tres como máximo.

La cardinalidad de proyectos, uno como mínimo y de dos como máximo, ya que cada
proyecto requiere al menos un empleado para ejecutarlo.

Las relaciones con ambas cardinalidades máximas 1 se llaman 1:1 (se lee 1 a 1). Las
relaciones con una cardinalidad máxima 1 y la otra más de 1 se llaman 1: m (se lee 1 a
muchos).

Las relaciones con ambas cardinalidades máximas mayores a 1 se llaman m:n (se lee
muchos a muchos).

Relaciones condicionales: son aquellas que tienen al menos una cardinalidad mínima cero.

Relaciones incondicionales: son aquellas que tienen ambas cardinalidades mínimas 1.

En el DER, la cardinalidad se puede indicar en ambos extremos de la relación con la

siguiente notación (cardinalidad mínima, cardinalidad máxima), pero generalmente los
diseñadores de bases de datos lo evitan, ya que la mayoría de las herramientas de
modelado no disponen de esta opción y solo indican el tipo de relación con valores cero,
uno o muchos.

Si el diseñador considerara necesario aclarar las cardinalidades específicas, puede

agregarlo manualmente como texto.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 6

Relaciones incondicionales
Analizamos la cardinalidad máxima y mínima de una relación.

Relación: 1:1 (se lee 1 a 1). Ejemplo: PAIS-JEFE_GOBIERNO.

En este caso consideraremos la relación “gobierna a” o “es gobernado por”, teniendo

como regla de negocio que cada país es gobernado por un solo jefe de Gobierno y cada
jefe de Gobierno conduce un solo país.

El análisis correspondiente para establecer las cardinalidades máximas de esta relación

sería:

Cada tupla de la entidad PAIS se puede relacionar como máximo con “una” tupla de la
entidad JEFE_GOBIERNO y cada tupla de la entidad JEFE_DE-GOBIERNO se puede
relacionar como máximo con una tupla de la entidad PAIS, considerando que solo se
guardan los datos de los jefes de Gobierno actuales.

El análisis correspondiente para establecer las cardinalidades mínimas sería: cada tupla de
la entidad País se puede relacionar como mínimo con una tupla de la entidad
Jefe_gobierno. Y cada tupla de la entidad Jefe_gobierno se puede relacionar como
mínimo con “una” tupla de la entidad País.

Las relaciones con cardinalidad 1:1 se resuelven pasando la PK (Clave Primaria) de una
de las entidades a la otra entidad como FK (Clave Foránea). De esta manera, además de
tener los datos de cada país y cada jefe de Gobierno, podemos conocer qué país se
relaciona con qué gobernante.

Esto podemos hacerlo a través de una clave foránea, que será atributo referencial en
una entidad y clave primaria en la otra.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 7

De este modo, podemos relacionar ambas entidades a través de la clave foránea Dni-
jefegob, pero también se podría haber relacionado a través de la clave foránea Cod-País,
de la siguiente manera:

Relación 1:m se lee “uno a muchos”.

Ejemplo: las entidades Sucursales y empleados y la relación “tiene como empleado” o

“trabaja en”.

Aquí la regla de negocio o restricción a aplicar sería: cada empleado trabaja en una sola
sucursal.

El análisis correspondiente para establecer las cardinalidades máximas de esta relación

sería:

Cada tupla de la entidad SUCURSALES se puede relacionar como máximo con “muchas”
tuplas de la entidad EMPLEADOS y cada tupla de la entidad EMPLEADOS se puede
relacionar como máximo con una tupla de la entidad SUCURSAL.

El análisis correspondiente para establecer las cardinalidades mínimas de esta relación

sería:

Cada tupla de la entidad SUCURSALES se puede relacionar como mínimo con “una” tupla
de la entidad EMPLEADOS y cada tupla de la entidad EMPLEADOS se puede relacionar

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 8

 como mínimo con “una” tupla de la entidad SUCURSALES. Lo cual graficamos de la
siguiente manera:

Si paso legajo empleado al

otro lado, sería multivaluado
porque en cada sucursal
trabajan muchos empleados,
tendría más de un valor Sin
embargo, si paso ID sucursal
esta bien porque cada
empleado trabaja en una
ÚNICA sucursal.

En este caso relacionamos ambas entidades a través de la clave foránea id-sucursal, ya

que podemos conocer el vínculo entre las SUCURSALES y los empleados sabiendo en qué
sucursal trabaja cada empleado. (Sería INCORRECTO pasar el atributo legajo-empleado a
la otra identidad para relacionarlas porque entonces dicho atributo podría tener más de
un valor, lo cual violaría la regla que impide que un atributo de una tupla tenga más de
una entrada (sería multivaluado)).

Podemos concluir, entonces:

Las relaciones 1:m se resuelven pasando la PK (Clave Primaria) de la entidad con

cardinalidad máxima 1 a la entidad con cardinalidad máxima muchos como FK
(Clave Foránea).

Nota importante:

En el ejemplo visto de 1:m, hemos indicado que la PK de la entidad con cardinalidad

máxima pasa a la otra entidad como FK.

Esto anterior es siempre válido. Pero es importante analizar dos escenarios. Uno, el
ejemplo dado, SUCURSALES-EMPLEADOS. En dicho ejemplo, la PK de SUCURSALES pasa a
EMPLEADOS como FK.

Veamos ahora este caso:

Se trata de una cadena de cines, que identifica a cada sucursal por un número_sucursal, y
considerar que cada sucursal posee varias salas, cada una de ellas identificada por un
número de sala.

Entonces:

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 9

¡Está mal resuelto! Ya que por un lado con el atributo Nro_sala ÚNICAMENTE no podemos
identificar a cada sala de toda la cadena de cines. A modo de ejemplo, la sala número 3
está en la sucursal “Mendoza” y en la sucursal “Córdoba” (ambas sucursales poseen una
sala nro. 3).
PORQUE
PUEDE TOMAR
Por otra parte, al tener una sala MUCHAS sucursales, el atributo Id_Sucursal es EL VALOR DE
MENDOZA,
multivaluado (recordar: puede tomar múltimples valores). CORDOBA,ETC

Entonces, en este caso, la clave primaria debe estar COMPUESTA por las dos claves: La
original concatenada/compuesta con la FK que pasó de la otra relación.

Gráficamente:

Relaciones condicionales
Las relaciones condicionales son aquellas que tienen alguna cardinalidad mínima cero.

Relación: 1:1c (Se lee 1 a 1 condicional).

Ejemplo: Entidades: VEHICULOS, PATENTES y la relación: “Tiene patente”.

El análisis correspondiente para establecer las cardinalidades máximas de esta relación

sería:

Cada tupla de la entidad VEHÍCULO se puede relacionar como máximo con “una” tupla
de la entidad PATENTES y cada tupla de la entidad PATENTES se puede relacionar como
máximo con una tupla de la entidad VEHICULOS.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 10

El análisis correspondiente para establecer las cardinalidades mínimas sería: cada tupla de
la entidad PATENTES se puede relacionar como mínimo con una tupla de la entidad
VEHÍCULOS. Y cada tupla de la entidad VEHÍCULOS se puede relacionar como mínimo con
“ninguna” tupla de la entidad PATENTES (si el vehículo aún no fue vendido).

Por lo tanto, para resolver esta relación 1:1c y considerando que hay tuplas de la
entidad VEHÍCULOS que no están relacionadas con tupla alguna de la entidad PATENTES,
pero todas las tuplas de la entidad PATENTES se relacionan con una tupla de la entidad
VEHÍCULOS, y con el fin de evitar que queden atributos que son clave foránea con valor
“nulo”, se debe pasar la clave primaria de la entidad VEHÍCULOS como foránea a la
entidad PATENTES.

Relación: 1:mc (se lee 1 a muchos condicional).

Ejemplo: Entidades: ÁREAS y ARTICULOS

El análisis correspondiente para establecer las cardinalidades máximas de la relación

“tiene artículos” o “es vendido en el área” sería:

Cada tupla de la entidad ÁREA se puede relacionar como máximo con “muchas” tuplas
de la entidad ARTÍCULOS y cada tupla de la entidad ARTÍCULOS se puede relacionar como
máximo con una tupla de la entidad ÁREA.

El análisis correspondiente para establecer las cardinalidades mínimas sería: cada tupla de
la entidad ÁREA se puede relacionar como mínimo con “ninguna” tupla de la entidad
ARTÍCULOS (Ejemplo: Área Recursos Humanos).

Cada tupla de la entidad ARTÍCULOS se puede relacionar como mínimo con “una” tupla de
la entidad ÁREA.

El diagrama correspondiente a esta situación sería:

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 11

Por lo tanto, para resolver esta relación 1:mc y considerando que hay tuplas de la
entidad AREAS que no están relacionadas con tupla alguna de la entidad ARTICULOS,
pero todas las tuplas de la entidad ARTICULOS se relacionan con una tupla de la entidad
AREAS, y con el fin de evitar que queden atributos que son clave foránea con valor
“nulo”, se debe pasar la clave primaria de la entidad AREAS como foránea a la entidad
ARTICULOS.

Las relaciones m:n (muchos a muchos), las muchos a 1 condicional (m:1c), así como las
bicondicionales, serán tema de estudio del próximo módulo.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 12