Diseño de bases de datos: conceptual, lógico y físico en Politécnico Grancolombiano

Documento del Politécnico Grancolombiano sobre el diseño de bases de datos. El Pdf explora las fases conceptuales, lógicas y físicas, operaciones relacionales, claves e integridad referencial, con un ejemplo práctico para estudiantes universitarios de Informática.

Ver más

22 páginas

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.
Contenido
1
2
3
Diseño conceptual de bases de datos
Modelo físico de una base de datos
Diseño lógico de la base de datos
Diseño de bases de datos
Unidad 1 / Escenario 2
Lectura fundamental
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 GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO
2
POLITÉCNICO GRANCOLOMBIANO
2

Visualiza gratis el PDF completo

Regístrate para acceder al documento completo y transformarlo con la IA.

Vista previa

POLITÉCNICO GRANCOLOMBIANO

FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN

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).

Ciclo de vida de un sistema de base de datos

Monitorización y
mantenimiento

Definición
del sistema

Puesta en
marcha

Diseño

Prueba y
validación

Implementación

Conversión de
aplicaciones

Carga y
conversión
de datos

Figura 1. Ciclo de vida de un sistema de base de datos
Fuente: elaboración propia

POLITÉCNICO GRANCOLOMBIANO
2En 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.}

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.

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.

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
3E

Figura 2. Símbolo de entidad regular en el diagrama ER
Fuente: elaboración propia

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).

E

Figura 3. Símbolo de entidad regular en el diagrama ER
Fuente: elaboración propia

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

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).

A

Figura 4. Símbolo de atributo en el diagrama ER
Fuente: elaboración propia

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.

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
Fuente: elaboración propia

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. Simbolo de atributo con discriminador en el diagrama ER
Fuente: elaboración propia

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).

E,
R
E2

Figura 7. Representación de relación binaria en el diagrama ER
Fuente: elaboración propia

POLITÉCNICO GRANCOLOMBIANO
6

R
E2
E3

Figura 8. Representación de relación ternaria en el diagrama ER
Fuente: elaboración propia

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).

R

Figura 9. Simbolo de relacion de identificación en el diagrama ER
Fuente: elaboración propia

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
7La 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 otra 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

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.

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.

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

¿Non has encontrado lo que buscabas?

Explora otros temas en la Algor library o crea directamente tus materiales con la IA.