Escenario 2

Unidad 1 / Escenario 2
Lectura fundamental
Diseño de bases de datos
Contenido
1 Diseño conceptual de bases de datos
2 Diseño lógico de la base de datos
3 Modelo físico de una base de datos
Palabras clave: modelo entidad-relación o modelo ER, modelo relacional, entidad, conjunto de entidades, atributo o
propiedad, relación o vínculo, clave primaria, grado de una relación.
Introducción
Así como para construir un edificio es necesario tener claro cuál va a ser su utilidad, para la
elaboración de un diseño y establecer cómo se puede realizar la construcción -en térmicos técnicos-
de una base de datos, es importante tener claras las necesidades del cliente, establecer un diseño
adecuado y determinar cuál es la mejor manera de implementarla.
De forma análoga, cuando se desea establecer una base de datos, es necesario tener claro cuál es la
necesidad por la que el cliente desea desarrollarla. Determinar los requerimientos del cliente de forma
adecuada es fundamental para que los diseñadores de bases de datos y los desarrolladores construyan
una solución que se ajuste a estas necesidades de la mejor manera. Para el desarrollo de una base
de datos, frecuentemente se tienen en cuenta las siguientes fases: definición del sistema, diseño,
implementación, carga y conversión de datos, conversión de aplicaciones, prueba y validación, puesta
en marcha, monitorización y mantenimiento (Figura 1).
Figura 1. Ciclo de vida de un sistema de base de datos

Fuente: elaboración propia
POLITÉCNICO
POLITÉCNICO GRANCOLOMBIANO
GRANCOLOMBIANO 2
En general podemos establecer tres niveles de abstracción en el diseño de una base de datos, así:
• El diseño conceptual
• El diseño lógico
• El diseño físico
En los siguientes apartados se explicará la forma en que se realizan estos diseños.}
1. Diseño conceptual de bases de datos

Con base en la especificación de los requerimientos, se lleva a cabo el diseño conceptual de la base
de datos. Este consiste en una representación de alto nivel de la manera en que se estructurarán
los datos, desde la perspectiva del usuario, más como una representación de la realidad, que desde
el enfoque del almacenamiento. La forma más común de realizar un diseño conceptual es a través
de un diagrama entidad-relación (ER) o de un diagrama entidad-relación extendido (ER+). Estos
diagramas están compuestos principalmente por entidades, atributos y relaciones.
1.1. Diseño conceptual soportado sobre diagramas entidad-relación (ER)
Un modelo entidad-relación representa los datos en entidades, atributos y relaciones. A continuación,

veremos las características de estos elementos y cómo se representan en el diagrama ER.
1.1.1. Entidades
Se denomina entidad a “una cosa del mundo real con una existencia independiente” (Elmasri y
Navathe, 2007, p.55). Puede representar productos, clientes, empleados, etc. En el diagrama ER se
representa normalmente por un rectángulo de línea sencilla (Figura 2).
POLITÉCNICO
GRANCOLOMBIANO 3
E
Figura 2. Símbolo de entidad regular en el diagrama ER

Cuando la entidad no tiene atributos clave propios (Elmasri y Navathe, 2007, p.67), es decir, no
tiene clave primaria y su existencia depende de la presencia de una identidad regular, tenemos lo que
se denomina una entidad débil. En lugar de clave primaria, la entidad débil tendrá una clave parcial a
la que se le denomina también discriminador. Así, la clave parcial estará compuesta en realidad por la
clave primaria de la entidad fuerte y el discriminador. En el diagrama ER se representa normalmente
por un rectángulo de línea doble (Figura 3).
Figura 3. Símbolo de entidad regular en el diagrama ER

1.1.2. Conjunto de entidades
Un conjunto de entidades corresponde a “un contenedor lógico para las instancias de un tipo de
entidad y las instancias de cualquier tipo que se deriven de ese tipo de entidad” (Microsoft, 2017).
Como se verá más adelante, la instancia de una entidad corresponderá a una fila de una tabla, la cual
equivaldrá al conjunto de entidades como tal. Cada instancia tendrá los atributos del conjunto de
entidades y una clave única dentro de este, y no estará presente en otro conjunto de entidades. En el
modelo conceptual no se definen las instancias de las entidades, por lo cual no se requiere representar
el conjunto de entidades dentro de este.
POLITÉCNICO
GRANCOLOMBIANO 4
1.1.3. Atributos
Un atributo, también denominado propiedad, es la “información que deseamos registrar sobre las
entidades” (Date, 2001, p.13). Por ejemplo, el conjunto de entidades estudiante poseería los atributos
número de identificación, apellidos, nombres y grado, lo que se representa así:
estudiante = (id_alumno, apellidos, nombres, grado)
En el diagrama ER, el atributo o propiedad se representa normalmente por una elipse (Figura 4).
Figura 4. Símbolo de atributo en el diagrama ER

Los atributos o propiedades se pueden clasificar de la siguiente manera:
• Simple: son aquellos que no se pueden dividir; por ejemplo, número cédula.
• Compuesto: está constituido por varios atributos; por ejemplo, dirección_empleado puede estar
conformado por número_calle, número_carrera, número_apto, bloque, etc.
• Univalorado: el atributo solo puede tener un valor.
• Multivalorado: el atributo puede tener varios valores.
• Nulo: la entidad no tiene valor.
• Derivado: depende de los valores de otros atributos.
1.1.4. Claves
Asimismo, si el atributo corresponde a un identificador del registro, es decir, dos elementos del mismo
conjunto de entidades no pueden compartir el valor de ese atributo y, como veremos más adelante,
dos filas de una tabla no pueden tener este valor repetido -pues identifica el registro como tal-,
estamos haciendo referencia a un atributo que corresponde a una clave primaria. En el diagrama ER
se representa por una elipse en la que el atributo está subrayado por una línea continua (Figura 5).
POLITÉCNICO
GRANCOLOMBIANO 5
A
Figura 5. Símbolo de atributo con clave primaria en el diagrama ER

Si el atributo corresponde al discriminador de una entidad débil, en el diagrama ER se representará

por una elipse en la que el atributo está subrayado por una línea discontinua (Figura 6).
_A_
Figura 6. Símbolo de atributo con discriminador en el diagrama ER

1.1.5. Relaciones
Además de las entidades que incluyen atributos, tenemos las relaciones. Una relación o vínculo
corresponde a la interacción que tienen dos o más entidades. El grado de una relación se determina
por la cantidad de tipos de entidades participantes. Si, por ejemplo, están involucrados dos tipos de
entidad, se denominará binaria; y si están involucrados tres tipos de entidad, ternaria. En el diagrama
ER estas relaciones se representarán por un rombo y línea que las conectan con las entidades
(Figuras 7 y 8).
E1 R E2
Figura 7. Representación de relación binaria en el diagrama ER

POLITÉCNICO
GRANCOLOMBIANO 6
E1 R E2
E3
Figura 8. Representación de relación ternaria en el diagrama ER

Si la entidad es débil, se entenderá que es una relación de identificación y su símbolo será un rombo
con doble línea (Figura 9).
Figura 9. Símbolo de relación de identificación en el diagrama ER

1.1.6. Razón de cardinalidad
La razón de cardinalidad de una relación binaria “especifica el número máximo de instancias de

relación en las que una entidad puede participar” (Elmasri y Navathe, 2007, p.65). A continuación, se
describen algunos ejemplos:
La razón de cardinalidad 1:N en la relación binaria TRABAJA_EN, DEPARTAMENTO:EMPLEADO,

señala que un departamento puede tener uno o muchos empleados, mientras que un empleado puede
trabajar en uno y solo un departamento.
La razón de cardinalidad 1:1 en la relación binaria ESTA_CASADO_CON, ESPOSO:ESPOSA,

señala que un esposo está casado con una y solo una esposa, y a su vez esta está casada con un y solo
un esposo.
POLITÉCNICO
GRANCOLOMBIANO 7
La razón de cardinalidad N:M en la relación binaria COMPRA, CLIENTE:PRODUCTO, señala que
un cliente puede comprar uno o muchos productos, y a su vez un producto puede ser comprado por
uno o muchos clientes.
Existen ciertas restricciones que pueden darse en la razón de cardinalidad. Por un lado, tenemos la
dependencia de existencia o participación total, que consiste en que para que tengamos instancias
de una entidad es necesario que exista una instancia de otra; es decir, cada entidad de un conjunto
de entidades participa al menos en una relación del conjunto de relaciones. Por ejemplo, para tener
una instancia de empleado debe existir una instancia de departamento en el que trabaje (no podemos
tener un empleado que no pertenezca a un departamento). Por otro parte, tenemos las restricciones
de participación o participación parcial en la que solo algunas entidades del conjunto de entidades
participan en las relaciones del conjunto de relaciones. En este caso, por ejemplo, no todos los
empleados administran un departamento.
La cardinalidad en el diagrama ER se representa con la presencia de una flecha al final de la línea en la

relación con uno, o la ausencia de la flecha en la relación con varios (Figura 10).
Esposo Casado Esposa
Empleado Trabaja Departamento
Cliente Compra Producto
Figura 10. Relaciones de cardinalidad en el diagrama ER

Fuente: elaboración propia.
POLITÉCNICO
GRANCOLOMBIANO 8
1.2. Verificación del diagrama entidad-relación
Para mantener la calidad de los diagramas, se deben incluir ciertas actividades de verificación, las
cuales se describen a continuación.
1.2.1. Completitud del diagrama
Una vez establecida la manera en la que el diagrama representa la realidad, se debe verificar que:
Todos los conceptos del problema estén representados.
El diagrama alcance todos los requerimientos.

En general, que el diagrama satisfaga los requerimientos del sistema.
1.2.2. Corrección del diagrama
Luego, se debe verificar la corrección sintáctica (forma) y semántica (significado). Al verificar la

corrección sintáctica se debe comprobar, en términos de lenguaje, lo siguiente:
Que las cardinalidades de cada relación estén bien orientadas.
Los atributos que determinan cada entidad y cuáles son entidades débiles.
La existencia de una y solo una relación.
Las entidades que intervienen en la relación dentro de cada agregación.
En síntesis, la corrección sintáctica implica que se respete el lenguaje. En ese sentido es aconsejable
utilizar herramientas CASE.
En cuanto a la corrección semántica, esta se asume cuando todos los elementos del problema utilizan
las estructuras que les corresponde. Así, es importante verificar lo siguiente:
La validez de cada atributo, entidad y relación.
Las categorías de entidades.
Establecer si la relación es binaria o múltiple.

Los mecanismos con los que se establecen las entidades.
Las cardinalidades y totalidades.
POLITÉCNICO
GRANCOLOMBIANO 9
1.2.3. Minimalidad del esquema
Los elementos involucrados en el problema deben aparecer una y solo una vez en el diagrama, de tal
forma que se muestren todos los elementos del mundo real y que estos correspondan a los elementos
del esquema.
1.2.4. Expresividad del esquema
Se entiende que un modelo es expresivo cuando de manera natural expresa la realidad empleando
solo la semántica del modelo. Busca determinar cuánto comunica el modelo en términos semánticos.
1.2.5. Explicitud del esquema
El diagrama no utiliza más formalismos que los incluidos en el diagrama entidad-relación; en otras
palabras, los elementos gráficos del modelo son suficientes para modelar la realidad.
1.3. Mecanismos de abstracción
La abstracción es “el proceso mental que se aplica al seleccionar algunas características y propiedades
de un conjunto de objetos y excluir otras” (Carreño, s.f.). Permite tener una definición más ajustada
a las necesidades de los objetos involucrados en la base de datos. En general, tenemos los siguientes
mecanismos:
Clasificación / instanciación
Agregación / descomposición
Generalización / especialización.
POLITÉCNICO
GRANCOLOMBIANO 10
1.3.1. Abstracción por clasificación / instanciación
Una clase en general define un objeto de la realidad, pero no es el objeto de la realidad como tal, sino
solo es la definición del mismo. Un objeto se materializa cuando se crea una instancia. Lo común a
todas las instancias es que posean atributos y métodos comunes a los definidos en la clase. Así, por
ejemplo, la clase vehículo se podría instanciar en un auto rojo e instanciar otro auto azul. Tanto el auto
rojo como el azul, son clasificados como vehículos y son instancias de la clase correspondiente.
1.3.2. Agregación / descomposición
Cuando un conjunto de clases constituye una clase que las comprende, hablamos de agregación. Es
decir, por la agregación de clase constituimos una nueva que las comprende. De modo contrario,
cuando de una clase desprendemos clases que la componen hablamos de descomposición. Si
agregamos las partes chasis, carrocería, silla, llanta (en la cantidad de instancias que sea necesario)
obtenemos un automóvil. A su vez, si descomponemos un automóvil, lo podemos hacer en las partes
que corresponden a clases como tal (Figura 11).
Automóvil
Llanta Chasís Silla Carrocería
Figura 11. Ejemplo de agregación / descomposición

1.3.3. Generalización / especialización
Al aplicar la teoría de conjuntos, vemos como algunas clases son parte de un subconjunto de otra.
Así, entendemos como especialización “el proceso de definir un conjunto de subclases de un tipo de
entidad” (Elmasri y Navathe, 2007, p.91).
POLITÉCNICO
GRANCOLOMBIANO 11
Por otro lado, entenderemos como generalización “el proceso inverso de abstracción en el que
eliminamos las diferencias entre distintas entidades, identifiquemos las características comunes y las
generalizamos en una única superclase” (Elmasri y Navathe, 2007, p.93). La Figura 12 muestra un
ejemplo de generalización / especialización.
Vehículo
Aeronave
Avión de combate Jumbo Helicóptero
Figura 12. Ejemplo de generalización / especialización

2. Diseño lógico de la base de datos

Una vez realizado el diseño del esquema conceptual, se procede al diseño lógico de la base de datos;
en otras palabras, se procede del modelo entidad-relación al modelo relacional. En el presente, con
los sistemas de gestión de bases de datos existentes, el modelo relacional desarrollado por Ted Codd
es el que más se utiliza para el diseño lógico de bases de datos. En este, la estructura fundamental es
la relación (tabla) que representa los objetos y sus asociaciones. Los atributos (campos) corresponden
a las relaciones y están definidos sobre dominios.
2.1. Diagrama relacional (MER)
Los elementos que componen el diagrama relacional son similares a los utilizados en el modelo
entidad-relación; sin embargo, su representación varía, pues busca ajustarse al sistema de gestión de
bases de datos que vamos a emplear.
POLITÉCNICO
GRANCOLOMBIANO 12
2.2. Componentes del diagrama relacional
2.2.1. Relaciones y tuplas
De acuerdo con Date, “dado un conjunto de n tipos o dominios Ti(i=1,2,…,n), que no son
necesariamente todos distintos, r es una relación sobre esos tipos si consta de dos partes: un
encabezado y un cuerpo” (Date, 2001, p.123). Esto corresponde a (aunque no es lo mismo que) una
tabla bidimensional, en la que las filas son los registros y las columnas los campos que corresponden a
los atributos (Tabla 1).
Tabla 1 Ejemplo de tabla para representar una relación
Id_estudiante Nombres Apellidos Grado

2123 Pedro Elías Pérez Sánchez 4
1323 Juan Manuel Mantilla Chacón 3
2132 Javier Eduardo Narváez López 3
La primera fila o cabecera muestra los nombres de los atributos representados en campos. Las
demás filas o cuerpo reciben el nombre de tupla y almacenan instancias (registros) que pertenecen al
conjunto de entidades representadas por la relación (tabla). El grado de la tabla o grado de una relación
corresponde a la cantidad de campos que posee; por ejemplo, cuatro en la relación de la Tabla 1.
La cardinalidad de una relación corresponderá el número de tuplas que contiene. Nótese que la
cardinalidad varía debido a que continuamente se insertan o eliminan registros. Una relación se
representa a través de una tabla, pero son conceptos diferentes. Por ejemplo, una tabla puede tener
filas repetidas, mientras una relación no puede tener tuplas iguales; por consiguiente, una tabla que
represente una relación no podrá tener filas repetidas.
POLITÉCNICO
GRANCOLOMBIANO 13
2.2.2. Dominios
Por dominio entendemos los valores que puede tomar un atributo. Por lo general, en el marco de un
sistema de gestión de bases de datos, el dominio corresponderá a los valores aportados por un tipo de
dato, que es un “conjunto específico de valores de los datos y un conjunto de operaciones que actúan
sobre los datos” (Aguilar, 2008).
Es probable que estos tipos de datos estén definidos por el sistema y por el sistema de gestión de
bases de datos, Así INTEGER, CHAR, VARCHAR, o DATE (Date, 2001) corresponderán a datos
numéricos enteros, caracteres, cadenas de caracteres o fechas correspondientemente. De esta
manera, por ejemplo, si definimos una columna (campo / atributo) denominada fecha_nacimiento
de tipo DATE, su contenido corresponderá a una fecha con las restricciones de sintaxis y de dominio
implicadas. Suponiendo que el formato requerido sea dd-mm-aaaa, colocar a dd un valor inferior a 1 o
superior a 31 (en ocasiones 30 o 28) generaría un error. El siguiente ejemplo de esquema de relación
muestra la manera en que se pueden incluir los dominios:
estudiante = (id_alumno:entero, apellidos:cadena, nombres:cadena, nacimiento:fecha)
Por otro lado, también es posible definir un dominio señalando el conjunto de valores que puede
tomar un dato.
2.2.3. Atributos
En el modelo relacional, un atributo corresponde a una columna o campo de una relación. Cada
atributo tendrá por lo tanto un dominio. Si D es el dominio y A el atributo, D es dominio de A y se
denotará:
D=Dom(A)
Dentro de este marco de referencia, un atributo podrá tomar los valores de un domino. Un atributo
estará asociado siempre con una relación y representa una propiedad de la misma, mientras que el
dominio no depende de las relaciones como tal. Así, varios atributos pueden tener el mismo dominio.
POLITÉCNICO
GRANCOLOMBIANO 14
2.2.4. Llaves
Para identificar las tuplas o para hacer referencia a ellas, existen las llaves. Podemos clasificar las llaves
en llaves primarias, llaves secundarias y llaves foráneas.
Llave primaria: es el atributo o conjunto de atributos no nulos que identifican una tupla en una relación.
Llave secundaria: es un atributo que no fue seleccionada como llave primaria, pero sus características
son únicas en una relación y corresponden solo a una tupla.
Llave foránea: es un atributo de la relación que corresponde a la llave primaria de otra relación de la
cual es referenciada una tupla.
2.3. Integridad referencial
Cuando una llave foránea de una relación haga referencia a la llave primaria de otra relación, es
necesario que la llave primaria corresponda a una tupla válida en su correspondiente relación. Por esa
razón, se aplican los descriptores PK (primary key) y FK (foreign key) para que la llave foránea no
admita valores nulos.
Lo anterior es importante, debido a que entre las operaciones que podemos ejecutar en una relación
r podemos eliminar una tupla que contenga una llave primaria que corresponda a una llave foránea de
otra relación s. Esto conllevaría a que la llave foránea de s apunte a una tupla inexistente en la relación
r, lo que haría inconsistente el modelo. Por lo tanto, para mantener la integridad referencial podemos
tomar alguna de las siguientes acciones:
Rechazar la modificación.
Eliminar las tuplas de la tabla de referencia s y luego eliminar la tupla correpondiente en r.
Asignar un valor nulo a las tuplas de la tabla de referencia s y luego eliminar la tupla
correspondiente en r.
Asignar un valor por defecto a las tuplas de la tabla de referencia s y luego eliminar la tupla
correspondiente en r.
Adicionalmente, es importante tener en cuenta que eliminar una tupla de una relación puede afectar
la integridad referencial de los registros de varias tablas de forma simultánea o en cascada.
POLITÉCNICO
GRANCOLOMBIANO 15
2.4. Operaciones relacionales
Existen varios tipos de operaciones relacionales. Conoceremos alguno a continuación.
2.4.1. Operaciones referenciales de modificación o actualización
Se reconocen tres operaciones básicas. A saber:
• Inserción (insert): permite insertar una tupla en una relación.
• Borrado (delete): elimina una o varias tuplas de una relación.
• Modificación (update): cambia los valores de atributos de tuplas existentes en la relación.
2.4.2. Operaciones referenciales uniarias
Son aquellas que se aplican para consultar una relación. Se reconocen las siguientes operaciones
uniarias:
• Selección (select): permite seleccionar un conjunto de tuplas de una relación que satisfaga unas
condiciones dadas. Su notación es σ_(<condicion de selección>) (R).
• Proyección (project): permite seleccionar un conjunto de columnas o campos de una relación.

Su notación es π_(<lista de atributos>) (R).
• Renombrado (rename): permite cambiar la denominación de los atributos.
2.4.3. Operaciones de algebra relacional de la teoría de conjuntos
Como operaciones de algebra relacional de la teoría de conjuntos, tenemos las siguientes:
• Unión (union): dadas las relaciones R y S, crea una nueva relación que incluye todas las tuplas
que están incluidas en las relaciones preexistentes R o en S. Su notación es RuS.
• Intersección (intersection): dadas las relaciones R y S, crea una nueva relación que incluye solo
las tuplas que están en las relaciones preexistentes R y en S. Su notación es R∩S.
POLITÉCNICO
GRANCOLOMBIANO 16
• Diferencia (minus): dadas las relaciones R y S, crea una nueva relación que incluye solo las
tuplas que están R, pero que no estén en S. Su notación es R - S.
• Producto cartesiano (cartesian product) o concatenación cruzada (cross join): produce nuevas
tuplas concatenando todas las posibles combinaciones entre n relaciones. Su notación es R X S.
2.4.4. Operaciones relacionales binarias
En este conjunto de operaciones tenemos:
Concatenación (join): combina tuplas de dos relaciones en una sola. Su notación es R⋈<condicion de conexión>(S).
División (division): define una relación sobre el conjunto de atributos C, incluido en la relación R, y
que contiene el conjunto de valores de S, que en las filas de R están combinadas con cada una de las
filas de S. Su notación es R(Z)÷S(Y).
Ejemplo de construcción de modelo lógico relacional

En un hospital, se han identificado tres tablas: médicos, salas y pacientes. Un médico se identificará
por la cédula, tendrá nombres, apellidos, dirección, teléfono y una sala que le ha sido asignada. Un
paciente se identificará por la cédula, tendrá nombres y apellidos, y será asignado a una sala para su
intervención. Las salas tendrán un código identificador, un nombre y un número de camas. Una sala
puede ser asignada a varios médicos, pero a cada médico se le asigna solo una sala. Una sala puede
tener varios pacientes, pero una paciente puede estar solo en una sala.
Así el esquema relacional de la base de datos de control de salas quedará así:
SALAS(cod_sala:entero, nombre_sala:cadena, num_camas:entero)
MEDICOS(cedula_medico:entero, Salas_cod_sala:entero, nombres_medico:cadena,
apellidos_medico:cadena, dirección_medico:cadena, telefono_medico:entero)
LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS
PACIENTES(cedula_paciente:entero, Salas_cod_sala:entero ,nombres_
paciente:cadena, apellidos_paciente:cadena,)
LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS
POLITÉCNICO
GRANCOLOMBIANO 17
Así, obtenemos el modelo lógico relacional de un control de salas en un hospital:
Figura 13. Modelo lógico relacional de un control de salas en un hospital
3. Modelo físico de una base de datos

Con base en el diseño lógico, podemos modelar un diseño físico, lo que corresponde a describir
cómo se comporta la base de datos en memoria secundaria. En general, el diseño físico busca:
reducir los tiempos de respuesta, el espacio de almacenamiento y el consumo de recursos, mejorar la
organización y la seguridad.
3.1. Fases del diseño físico de una base de datos
El diseño físico de una base de datos consta de cuatro fases, las cuales se describen a continuación.
3.1.1. Traducir el esquema lógico para el sistema de gestión de bases de datos
Se debe conocer la funcionalidad que ofrece el sistema de gestión de bases de datos; soporte de
llaves primarias, foráneas y alternativas; soporte a la definición de datos, dominios y reglas de negocio;
y cómo se crean las relaciones base.
POLITÉCNICO
GRANCOLOMBIANO 18
3.1.2. Diseñar las relaciones base para el sistema de gestión de bases de datos
La definición de las relaciones base se hacen a través del lenguaje de definición de datos (LDD) que
corresponde a cada sistema de gestión de bases de datos. Se utiliza información obtenida del diseño
lógico, como:
• Diccionario de datos: lista estructurada de los datos que pertenecen al sistema (Tabla 2).
• Esquema relacional: este incluye relaciones, atributos, llaves primarias y foráneas, y reglas de integridad.
Tabla 2. Ejemplo de diccionario de datos
Tabla Llave Nombre Campo Tipo Tamaño Descripción
Código del Almacena el código del

Empleados PK empleado cod_empleado Numérico 4 empleado.
Nombre del Almacena el nombre del

Empleados empleado nom_empleado Texto 50 empleado.
Código de Almacena el código de la

ciudades_cod_
Empleados FK ciudad del ciudad Numérico 4 ciudad del empleado.
empleado
3.1.3. Diseñar las reglas de negocio para el sistema de gestión de bases de datos
Se deben tener en cuenta las restricciones impuestas por las reglas de negocio de la empresa. Por
ejemplo, en el caso del hospital señalado en un apartado anterior, es posible restringir que el número
de camas por salas sea inferior o igual a cinco, y que una sala no puede tener asignados más del
número de camas de la sala. Teniendo esto en cuenta, las restricciones quedarían así:
CONSTRAINT num_camas_chk CHECK (num_camas <=5)
CONSTRAINT pacientes_por_sala CHECK (NOT EXIST (SELECT
Salas_cod_sala FROM Pacientes GROUP BY Salas_cod_sala HAVING
COUNT(*)<num_camas))
POLITÉCNICO
GRANCOLOMBIANO 19
3.1.4. Diseñar el nivel físico
En este caso debe tenerse en cuenta:
• La productividad en las transacciones: teniendo en cuenta la cantidad de transacciones

proyectadas sobre unidad de tiempo.
• El tiempo de respuesta: cuánto tarda el sistema en dar respuesta al usuario.
• Espacio en disco: cuánto espacio se requiere para almacenar los datos soportados por el sistema.
• Memoria principal: corresponde al tamaño de la RAM para obtener un buen desempeño del sistema.
• Procesador o procesadores: en la medida que se usen procesadores más rápidos y se empleen

varios procesadores en paralelo el desempeño será mayor.
• Almacenamiento en disco: es diferente al empleado para el sistema operativo, utilización de

“logs”, uso de arreglos de discos, etc.
• Conexiones de red: ancho de banda y uso de múltiples canales.
3.2. Diseño de mecanismos de seguridad
Cada día, la seguridad se convierte en un factor crítico dentro de los negocios y organizaciones. Cada
sistema de gestión de bases de datos aporta mecanismos de seguridad. Además, se recomienda:
• Diseñar las vistas de los usuarios
• Diseñar reglas de acceso.
POLITÉCNICO
GRANCOLOMBIANO 20
Referencias
Aguilar, L. J. (2008). Fundamentos de Programación. Madrid: Mc Graw Hill.
Carreño, J. (s.f.). Fundamentos de Bases de Datos. Bogotá: Politécnico Grancolombiano.
Date, C. (2001). Introducción a los sistemas de bases de datos. Naucalpan de Juárez, México:
Pearson Education.
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson,

Addison Wesley.
Microsoft. (2017). Microsoft Developer Network: Conjunto de Entidades. Disponible en

https://msdn.microsoft.com/es-es/library/ee382830(v=vs.110).aspx
POLITÉCNICO
GRANCOLOMBIANO 21
INFORMACIÓN TÉCNICA
Módulo: Fundamentos de bases de datos
Unidad 1: Generalidades y conceptos de bases de datos
Escenario 2: Conceptos de diseño de bases de datos
Autor: Luis Ernesto Leyva Camargo
Asesor Pedagógico: María del Pilar Rivera Acosta
Diseñador Gráfico: David Alfonso Rivera
Asistente: Jhon Edwar Vargas
Este material pertenece al Politécnico Grancolombiano.

Prohibida su reproducción total o parcial.
POLITÉCNICO
GRANCOLOMBIANO 22

Escenario 2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Escenario 2

Cargado por

Copyright:

Formatos disponibles

Unidad 1 / Escenario 2

Diseño de bases de datos

1 Diseño conceptual de bases de datos

2 Diseño lógico de la base de datos

3 Modelo físico de una base de datos

Figura 1. Ciclo de vida de un sistema de base de datos

En los siguientes apartados se explicará la forma en que se realizan estos diseños.}

1. Diseño conceptual de bases de datos

1.1. Diseño conceptual soportado sobre diagramas entidad-relación (ER)

Un modelo entidad-relación representa los datos en entidades, atributos y relaciones. A continuación,

Figura 2. Símbolo de entidad regular en el diagrama ER

Figura 3. Símbolo de entidad regular en el diagrama ER

1.1.2. Conjunto de entidades

estudiante = (id_alumno, apellidos, nombres, grado)

Figura 4. Símbolo de atributo en el diagrama ER

Los atributos o propiedades se pueden clasificar de la siguiente manera:

• Univalorado: el atributo solo puede tener un valor.

• Multivalorado: el atributo puede tener varios valores.

• Nulo: la entidad no tiene valor.

• Derivado: depende de los valores de otros atributos.

Figura 5. Símbolo de atributo con clave primaria en el diagrama ER

Si el atributo corresponde al discriminador de una entidad débil, en el diagrama ER se representará

Figura 6. Símbolo de atributo con discriminador en el diagrama ER

Figura 7. Representación de relación binaria en el diagrama ER

Figura 8. Representación de relación ternaria en el diagrama ER

Figura 9. Símbolo de relación de identificación en el diagrama ER

1.1.6. Razón de cardinalidad

La razón de cardinalidad de una relación binaria “especifica el número máximo de instancias de

La razón de cardinalidad 1:N en la relación binaria TRABAJA_EN, DEPARTAMENTO:EMPLEADO,

La razón de cardinalidad 1:1 en la relación binaria ESTA_CASADO_CON, ESPOSO:ESPOSA,

La cardinalidad en el diagrama ER se representa con la presencia de una flecha al final de la línea en la

Esposo Casado Esposa

Empleado Trabaja Departamento

Cliente Compra Producto

Figura 10. Relaciones de cardinalidad en el diagrama ER

1.2.1. Completitud del diagrama

Todos los conceptos del problema estén representados.

El diagrama alcance todos los requerimientos.

1.2.2. Corrección del diagrama

Luego, se debe verificar la corrección sintáctica (forma) y semántica (significado). Al verificar la

Que las cardinalidades de cada relación estén bien orientadas.

La existencia de una y solo una relación.

Las entidades que intervienen en la relación dentro de cada agregación.

La validez de cada atributo, entidad y relación.

Las categorías de entidades.

Establecer si la relación es binaria o múltiple.

Las cardinalidades y totalidades.

1.2.4. Expresividad del esquema

1.2.5. Explicitud del esquema

1.3. Mecanismos de abstracción

1.3.2. Agregación / descomposición

Llanta Chasís Silla Carrocería

Figura 11. Ejemplo de agregación / descomposición

1.3.3. Generalización / especialización

Avión de combate Jumbo Helicóptero

Figura 12. Ejemplo de generalización / especialización

2. Diseño lógico de la base de datos

2.1. Diagrama relacional (MER)

2.2.1. Relaciones y tuplas

Id_estudiante Nombres Apellidos Grado

Fuente: elaboración propia.

estudiante = (id_alumno:entero, apellidos:cadena, nombres:cadena, nacimiento:fecha)

2.3. Integridad referencial

Eliminar las tuplas de la tabla de referencia s y luego eliminar la tupla correpondiente en r.