Módulo 2.

Diseño de bases de datos

Diseño e implementación de Bases de datos relacionales utilizando el modelo Entidad-Relación.

Temas a tratar:

El proceso de diseño de la base de datos.

Modelo Entidad-Relación.
Modelo Relacional.
Transformación de diagramas E-R a diagrama Relacional.
Definición del esquema de la Base de datos Relacional.

El proceso de diseño de la base de datos

El proceso de diseño de la base de datos se puede dividir en seis pasos.

(1) Análisis de requisitos: para diseñar una aplicación de base de datos es comprender qué datos
se almacenarán en la base de datos, qué aplicaciones se deben construir sobre ella y qué
operaciones son las más frecuentes y están sujetas a los requisitos de rendimiento. En otras
palabras, debemos averiguar qué quieren los usuarios de la base de datos. Este suele ser un
proceso informal que involucra discusiones con grupos de usuarios, un estudio del entorno
operativo actual y cómo se espera que cambie, análisis de cualquier documentación
disponible sobre las aplicaciones existentes que se espera que sean reemplazadas o
complementadas por la base de datos, etc. Se han propuesto varias metodologías para
organizar y presentar la información recopilada en este paso, y se han desarrollado algunas
herramientas automatizadas para respaldar este proceso.

(2) Diseño conceptual de la base de datos: la información recopilada en el paso de análisis de

requisitos se utiliza para desarrollar una descripción de alto nivel de los datos que se
almacenarán en la base de datos, junto con las restricciones que se sabe que tienen sobre
estos datos. Este paso a menudo se lleva a cabo utilizando el modelo ER.

(3) Diseño de la base de datos lógica: debemos elegir un DBMS para implementar el diseño de
nuestra base de datos y convertir el diseño conceptual de la base de datos en un esquema de
base de datos de acuerdo con el DBMS elegido (en nuestro caso será relacional).

(4) Tratamiento de esquemas: se analizan las relaciones en el esquema de la base de datos

relacional para identificar posibles problemas y reestructurarlas de ser necesario para
asegurar algunas propiedades deseables, la teoría de normalización de relaciones nos sirve
para realizar este proceso.
(5) Diseño físico de la base de datos: se deben considerar las cargas de trabajo que nuestra base
de datos debe admitir y seguir mejorando el diseño de la base de datos para garantizar que
cumpla con los criterios de rendimiento deseados. Esto puede implicar simplemente la
creación de índices en algunas tablas y agrupar algunas tablas, o puede implicar un rediseño
de partes del esquema de base de datos obtenido de los pasos de diseño anteriores.

(6) Diseño de seguridad: identificamos diferentes grupos de usuarios y diferentes roles

desempeñados por estos usuarios (por ejemplo, el equipo de desarrollo de un producto, los
representantes de atención al cliente, el gerente de producto). Para cada rol y grupo de
usuarios, debemos identificar las partes de la base de datos a las que deben poder acceder y
las partes de la base de datos a la que no se les debe permitir el acceso, y tomar medidas para
garantizar que solo puedan acceder a las partes necesarias. Como ya se comentó en el
módulo anterior Un DBMS nos proporciona varios mecanismos para ayudar en esta tarea.

Para el análisis de requisitos y el diseño conceptual de la base de datos, pasos (1) y (2)
utilizaremos el modelo Entidad-Relación, en el diseño de la base de datos lógica, paso (3), para el
modelo relacional, la tarea es convertir un esquema ER en esquema de base de datos relacional,
para lo que es indispensable conocer las características de este modelo, en el paso (4) tratamiento
de esquemas, como ya se comentó se utiliza la normalización, la cual se discute en el último
módulo del curso, es conveniente comentar que si se realiza adecuadamente el diseño con el
modelo entidad-relación al aplicar normalización confirmamos que el esquema obtenido es el
adecuado, los siguientes pasos se discuten en las materias de administración de bases de datos
(5) y taller de base de datos (6).

2.1 Modelo Entidad-Relación.

El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real en
términos de objetos básicos llamados entidades y sus relaciones. Se desarrolló para facilitar el
diseño de una base de datos permitiendo la especificación de un esquema empresarial, que
representa la estructura lógica global la base de datos y es ampliamente utilizado para efectuar el
diseño inicial de la misma.

Nos proporciona conceptos útiles que nos permiten pasar de una descripción informal de lo que
los usuarios desean de su base de datos a una descripción más detallada y precisa que se puede
implementar.

2.1.1 Entidades y conjuntos de entidades.

Entidad: es un objeto que existe y es distinguible de otros objetos, por ejemplo Juan Robles, con
número de control 17030210, es una entidad, ya que indica un alumno especifico. Una entidad
puede ser concreta, como un libro, o abstracta, como un concepto.
Atributo: Una entidad tiene un conjunto de propiedades o atributos, y los valores de estos
atributos identifican y/o describen a cada entidad de forma unívoca, por ejemplo, el número de
control identifica a la entidad y el nombre lo describe, una entidad tiene un valor para cada uno
de sus atributos.

Conjuntos de Entidades: es un conjunto de entidades del mismo tipo, es decir entidades que
tienen los mismos atributos, por ejemplo: un conjunto de entidades alumno.

Las entidades compartiendo las mismas propiedades se agrupan en conjuntos, los atributos que
describen un conjunto de entidades definen su tipo

Figura 2.1.1 Conjuntos de entidades Materias y Alumnos.

Los conjuntos de entidades no son necesariamente disjuntos, Por ejemplo, es posible definir el
conjunto de entidades de todos los maestros del tecnológico (maestros) y el conjunto de
entidades de todos los alumnos (alumnos), y una entidad persona puede ser una entidad maestro,
una entidad alumno, ambas cosas, o ninguna.

2.1.2 Relaciones y conjuntos de relaciones.

Relación: Una relación es una asociación entre dos o más entidades que pueden pertenecer a dos
o más conjuntos de entidades no necesariamente distintos, por ejemplo se puede definir una
relación entre la materia Matemáticas con el alumno Rubí Martínez, esta relación especifica que el
alumno Rubí Martínez cursó la materia Matemáticas.

Conjunto de Relaciones: Un conjunto de relaciones es un grupo de relaciones del mismo tipo, por
ejemplo el conjunto de relaciones Cursó entre Alumnos y Materias:
 Figura 2.1.2a Conjunto de relaciones cursó entre los
conjuntos de entidades Materias y Alumnos.

Una relación también puede tener atributos descriptivos. Los atributos descriptivos se utilizan
para registrar información sobre la relación, en lugar de sobre cualquiera de las entidades
participantes; por ejemplo, podríamos indicar la calificación que cada alumno obtuvo al cursar la
materia

Figura 2.1.2b Conjunto de relaciones cursó con el atributo calificación.

Los conjuntos de entidades que participan en un conjunto de relaciones no son necesariamente

distintos; a veces una relación puede involucrar dos entidades en el mismo conjunto de entidades.
Por ejemplo, en el conjunto de relaciones prerrequisito, que se muestra en la figura 2.1.2c entre
entidades del conjunto de entidades materias:
 Figura 2.1.2c Conjunto de relaciones prerrequisitos entre entidades
del conjunto de entidades materias.

Grado de una Relación: Es el número de entidades que participan en cada relación, la relación
Cursó entre alumnos y materias es binaria o de grado 2, ya que en cada relación participa
únicamente una entidad Alumno y una entidad Materia, el grado de la relación prerrequisitos
también es 2 (binaria), ya que en cada relación participan 2 entidades materia, es posible tener
relaciones que asocien a más de dos entidades aunque es raro en la práctica.

Restricciones: Nos indican la forma como están asociadas las diferentes entidades en una relación,
estas son:

A) Cardinalidad.- expresa el número de entidades a las que una entidad puede estar asociada
en un conjunto de relaciones, aunque existen conjuntos de relaciones que asocian entre sí
a tres o más conjuntos de entidades, la gran mayoría de ellas son binarias por lo que en
este momento nos vamos a enfocar en este tipo de relaciones. Para un conjunto de
relaciones binarias R entre los conjuntos de entidades A y B, cardinalidad debe ser:

 Una a una. Una entidad en A está asociada a lo sumo con una entidad en B, y una de B
a lo sumo con una de A.

 Una a muchos. Una entidad en A está asociada con un número cualquiera de entidades
de B, pero una de B sólo puede estar asociada a una de A.
  Muchas a muchas. Una entidad en A está asociada con un número cualquiera en B, y
una en B está asociada con un número cualquiera en A.

La cardinalidad adecuada para un conjunto de relaciones determinado es dependiente del

mundo real que el conjunto de relaciones está modelando.

B) Membresía o participación.- La participación de un conjunto de entidades E en un

conjunto de relaciones R se dice que es total si cada entidad en E participa al menos en
una relación en R. Si sólo algunas entidades en E participan en relaciones en R, la
participación del conjunto de entidades E en la relación R se llama parcial.

En esta relación, la participación de la entidad A es parcial porque hay algunas entidades

de A que no participan en la relación, y la participación de la entidad B es total por que
todas las entidades en B están asociadas con alguna entidad en A.

2.1.3 Claves (Llaves).

Por definición una entidad es un objeto que existe y es distinguible de otros objetos, desde la
perspectiva de una BD, la diferencia entre éstas debe expresarse en términos de sus atributos.
Para lo cual se deben identificar las siguientes claves:

Superclave (superllave): es un conjunto de uno o más atributos que, considerados

conjuntamente, nos permiten identificar de forma única a una entidad dentro del conjunto de
entidades. Por ejemplo, el atributo número de control, del conjunto de entidades Alumno es una
superclave, y así como el CURP. La combinación de nombre y número de control también lo es y
cualquier combinación de atributos con el número de control y/o el CURP lo será. El concepto de
una superclave no es suficiente para lo que aquí se propone, ya que una superclave puede
contener atributos innecesarios. Si K es una superclave, entonces también lo es cualquier
superconjunto de K.

Llave Candidata: son superllaves mínimas para las cuales ningún subconjunto propio es una
superllave, por ejemplo: el número de control, la CURP y el número de seguridad social (NSS) del
alumno y la clave de la materia de Materias.

Llave Primaria: es la clave candidata que elige el diseñador de la BD como el medio principal de
identificar entidades dentro de un conjunto de entidades, por ejemplo: de entre el número de
control, la CURP y número de seguridad social (NSS) del alumno podríamos tomar como llave
primaria el número de control, de hecho podría ser cualquiera de las llaves candidatas, sin
embargo podríamos tomar como criterio decidir de acuerdo con la forma como identifican más
fácilmente los usuarios a las entidades.

Entidades Débiles: son entidades que no tienen suficientes atributos para formar una llave
primaria. Una entidad que tiene una clave primaria propia se denomina entidad fuerte. Una
entidad fuerte es por definición una entidad dominante, mientras una entidad débil es una
entidad subordinada, cuya existencia depende de otra entidad, por ejemplo en la empresa la
entidad familiar depende de la entidad empleado y la desaparición de un empleado de la base de
datos hace que no sea necesario mantener el registro de sus familiares, así como también en el
caso del tecnológico en donde el grupo depende de la materia y si se elimina la materia de la
retícula, el grupo ya no tiene razón de ser.

Discriminante: Aunque un conjunto de entidades débiles no tiene clave primaria, solamente se

necesita conocer los atributos que permiten distinguir entre sí a todas aquellas entidades del
conjunto de entidades que dependen de una entidad fuerte en particular. El discriminante de una
entidad débil es un atributo o conjunto de atributos que permite que esta distinción se haga.

La llave primaria de una entidad débil se forma mediante la llave primaria de la entidad fuerte de
cuya existencia depende la entidad débil, más el discriminante de la entidad débil.
En esta figura se puede observar que el conjunto de entidades Materia tiene como clave primaria
la clave de la materia, ya que esta no se repite, y el conjunto de entidades grupos cuya existencia
depende de las materias no tiene suficientes atributos para formar una llave primaria, si
agrupamos las entidades grupo que dependen de la misma entidad dominante materia como se
observa, se puede identificar al conjunto de atributos o discriminador que identifica entre sí a los
grupos que dependen de la misma materia, en este caso el discriminador es el número de grupo,
por lo que la llave primaria de este conjunto de entidades estará formada por la clave de la
materia y el número de grupo.

2.1.4 Diagrama Entidad-Relación.

En adelante usaremos el término Entidades para referirnos al conjunto de Entidades y
Relaciones para el conjunto de relaciones y se usará la siguiente notación para
describirlas:

Entidad(atributo-1,atributo-2,atributo-3,…atributo-n) para Entidades fuertes y

Entidad(atributo-1,atributo-2,atributo-3,…atributo-n) para entidades débiles

Relación(Entidad-1 [papel-1], Entidad-2 [papel-2],…) cardinalidad, atributo-1,atributo-2…

La cardinalidad puede ser: 1-1, 1-N, N-N o 1=N si es de dependencia (para Relaciones
Binarias)

2.1.5 Problemas:

Problema 1

Descripción:

Se quiere elaborar una base de datos para una aplicación de ventas en donde se registre
información sobre los clientes, de los que se tiene un número de cliente, su nombre y el
estatus del cliente, las productos se les envían a los clientes por mensajería al estado
donde viven y se les cobra una cantidad (cargoxEnvio) dependiendo su estado, de los
estados se tiene además la clave del estado y su nombre, la compañía maneja un catálogo
de productos donde se indica un numero de producto, su nombre, color y precio, cuando
un cliente ordena un producto determinado se indica la cantidad, los clientes pueden
realizar ordenes de varios productos y a su vez un producto puede ser ordenado por
varios clientes, algunos clientes manejan cuentas de crédito, de estas se maneja el
número de cuenta y el saldo, sobre las cuentas se registran movimientos de los que se
tiene un numero de movimiento (el cual es consecutivo por cuenta) y el importe, estos
movimientos son de diferentes tipos (compras, pagos, cargos x interés, IVA, etc.), de los
tipos de movimiento se tiene la clave y una descripción.

Identificar las entidades y relaciones y elaborar el diagrama Entidad-Relación

correspondiente.
Solución problema 1

Vamos a iniciar el proceso identificando las entidades, relaciones y atributos sobre el

texto, utilizando colores, las Entidades se identifican como sustantivos dentro de la
narrativa del problema y las Relaciones como verbos.

Se quiere elaborar una base de datos para una aplicación de ventas en donde se registre
información sobre los clientes, de los que se tiene un número de cliente, su nombre y el
estatus del cliente, las productos se les envían a los clientes por mensajería al estado
donde viven y se les cobra una cantidad (cargoxEnvio) dependiendo su estado, de los
estados se tiene además la clave del estado y su nombre, la compañía maneja un catálogo
de productos donde se indica un numero de producto, su nombre, color y precio, cuando
un cliente ordena un producto determinado se indica la cantidad, los clientes pueden
realizar ordenes de varios productos y a su vez un producto puede ser ordenado por
varios clientes, algunos clientes manejan cuentas de crédito, de estas se maneja el
número de cuenta y el saldo, sobre las cuentas se registran movimientos de los que se
tiene un numero de movimiento (el cual es consecutivo por cuenta) y el importe, estos
movimientos son de diferentes tipos (compras, pagos, cargos x interés, IVA, etc.), de los
tipos de movimiento se tiene la clave y una descripción.

Identificar las Entidades con sus atributos así como su llave primaria y/o discriminador e
Identificar las Relaciones y su cardinalidad

Entidades:
Cliente(noCte,nombre,estatus)
Estado(cveEdo,nombre,cargoXEnvio)
Producto(noProd,nombre,color,precio)
Movimiento(noMovto,importe)
tipoMovtos(cveTipo,descripcion)

Relaciones:
viveEn(cliente,Estado) N-1
orden(cliente,producto) N-N, cantidad
manejan(cliente,cuenta) 1-1
registra(cuenta,movimiento) 1=N
esDe(movimiento,tipoMovto) N-1
Notas:
1) En el caso de la entidad mensajería, solo se indica para aclarar que la compañía
hace los envíos por ese medio, pero como no se registra información de estas no
se incluye en la lista.
2) La cardinalidad de la relación manejan, entre cliente y cuenta es de 1 a 1, la
membresía del cliente en la relación es parcial, y de la cuenta es total, ya que hay
clientes que no tienen cuenta, pero todas las cuentas deben estar asociadas a un
cliente, esto se indica subrayando el 1 del lado de cliente, es importante indicar la
membresía en las relaciones de 1-1, en las relaciones de 1-N o N-N realmente no
es necesaria.
3) La entidad Movimiento no tiene llave primaria, el atributo noMovto es un número
consecutivo que se repite de una cuenta a otra, pero no se repite en cada cuenta,
por lo que se define como discriminador, movimiento es una entidad débil y su
existencia depende de las cuentas, esto último se indica en la relación registra,
donde se indica la cardinalidad 1=N.

A partir del listado de Entidades y Relaciones se procede a elaborar el diagrama, que

queda como sigue:

Diagrama Entidad-Relación para el diseño de la base de datos Órdenes

La siguiente figura incluye una muestra de las entidades y relaciones, para una mejor
comprensión del proceso.

Muestra de Entidades y Relaciones para el diseño de la base de datos Ordenes

Problema 2

Se quiere diseñar una base de datos para el sistema integrado de información del
Tecnológico de Celaya bajo las siguientes reglas: se tienen varias carreras de las que se
maneja una clave, su nombre y la clave oficial, tanto la clave como la clave oficial son
únicas, cada carrera está formada por varias materias y hay materias que son comunes a
varias carreras, una materia se describe por la clave de la materia, su nombre, el número
de horas teóricas, horas prácticas y créditos, para impartir cada materia se organizan
grupos cada semestre, los grupos se identifican por el número de grupo, el cual es un
numero consecutivo por materia y se indica para cada grupo el salón, horario, a cada
grupo se le asigna un maestro, el cual puede atender a varios de éstos, los datos del
maestro son clave del maestro y nombre, los maestros están asignados a una carrera, al
igual que los alumnos, para cursar sus materias un alumno se inscribe en varios grupos, y
cada grupo tiene un máximo de 30 alumnos, de los alumnos se registra un número de
control, nombre, Genero y Fecha de Nacimiento, un alumnos puede cursar cada materia
hasta por 3 ocasiones (oportunidades), y se quiere llevar un historial o Kardex en donde se
indique la calificación que el alumno obtuvo en cada materia por cada oportunidad que la
haya cursado, de las oportunidades se tiene un número que la identifica y su descripción,
algunas materias son prerrequisitos de otras materias y es necesario indicarlo.
Identificar las entidades y relaciones y elaborar el diagrama Entidad-Relación
correspondiente.

Solución problema 2

De igual manera que en problema anterior, vamos a iniciar el proceso identificando las
entidades, relaciones y atributos sobre el texto, utilizando colores, las Entidades se
identifican como sustantivos dentro de la narrativa del problema y las Relaciones como
verbos.

Se quiere diseñar una base de datos para el sistema integrado de información del
Tecnológico de Celaya bajo las siguientes reglas: se tienen varias carreras de las que se
maneja una clave, su nombre y la clave oficial, tanto la clave como la clave oficial son
únicas, cada carrera está formada por varias materias y hay materias que son comunes a
varias carreras, una materia se describe por la clave de la materia, su nombre, el número
de horas teóricas, horas prácticas y créditos, para impartir cada materia se organizan
grupos cada semestre, los grupos se identifican por el número de grupo, el cual es un
numero consecutivo por materia y se indica para cada grupo el salón, horario, a cada
grupo se le asigna un maestro, el cual puede atender a varios de éstos, los datos del
maestro son clave del maestro y nombre, los maestros están asignados a una carrera, al
igual que los alumnos, para cursar sus materias un alumno se inscribe en varios grupos, y
cada grupo tiene un máximo de 30 alumnos, de los alumnos se registra un número de
control, nombre, Genero y Fecha de Nacimiento, un alumnos puede cursar cada materia
hasta por 3 ocasiones (oportunidades), y se quiere llevar un historial o Kardex en donde se
indique la calificación que el alumno obtuvo en cada materia por cada oportunidad que la
haya cursado, de las oportunidades se tiene un número que la identifica y su descripción,
algunas materias son prerrequisitos de otras materias y es necesario indicarlo.

Identificar las Entidades con sus atributos así como su llave primaria y/o discriminador e
Identificar las Relaciones y su cardinalidad

Entidades:
Carrera(cveCarrera,nombre,cveOficial)
Materia(cveMat,nombre,horasTeo,horasPrac,créditos)
Grupo(noGpo,salon,horario)
Maestro(cveMaestro,nombre)
 Alumno(noCont,nombre,genero,fechaNac)
Oportunidad(noOpor,descripción)

Relaciones:
Formada(carrera,materia) N-N
SeImparte(materia,grupo) 1=N
Imparte(maestro,grupo) 1-N
Asignado(carrera,maestro) 1-N
estaEn(carrera,alumno) 1-N
inscrito(grupo,alumno) N-N
Kardex(alumno,materia,oportunidad) N-N-N, calificación
Prerrequisitos(materia prerequisitada, materia prerrequisito) N-N

Notas:
1) Originalmente se marcó semestre como una entidad, pero no tendría atributos,
por lo que se descarta, si interesara saber el semestre en que curso una materia el
alumno, se podría incluir en la relación Kardex.
2) La entidad grupo es débil ya que depende de la materia el número de grupo es
consecutivo por materia, por lo que se toma como discriminador, y se indica en la
relación SeImparte(materia, grupo) que la relación es de dependencia (1=N).
3) Aunque se marcó historial o kardex originalmente como una entidad, en realidad
es una relación terciaria entre alumnos, materia y oportunidad con cardinalidad N-
N-N y que tiene como atributo descriptivo la calificación.
4) La relación prerrequisitos, relaciona entre sí a entidades materia, por lo que es
necesario especificar el papel o rol que juega la cada materia en la relación, la
primera es la materia prequisitada y la segunda el prerrequisito.

A partir del listado de Entidades y Relaciones se procede a elaborar el diagrama, que

queda como sigue:
 Diagrama Entidad-Relación para el diseño de la base de datos del SII (alumnos)

Problema 3

Se quiere elaborar un diagrama entidad-relación que permita representar una jerarquía

de empleados dentro de una empresa, de los empleados se tiene su número de
empleado, nombre y RFC, y se muestra una jerarquía de ejemplo a continuación, aunque
el número de niveles debe ser variable.

E1

E3 E25 E17

E18 E2 E5 E23 E18 E12

E55 E56 E10 E11 E35 E26 E14

E67 E4
 Jerarquía de empleados en la empresa

Solución problema 3

Como ya se había comentado los conjuntos de entidades que participan en un conjunto de

relaciones no necesitan ser distintos; a veces una relación puede involucrar dos entidades
en el mismo conjunto de entidades, en este caso solo se utiliza un conjunto de entidades y
solo existe un conjunto de relaciones

De igual manera que en problema anterior, vamos a iniciar el proceso identificando las
entidades, relaciones y atributos sobre el texto, utilizando colores, las Entidades se
identifican como sustantivos dentro de la narrativa del problema y las Relaciones como
verbos.

Se quiere elaborar un diagrama entidad-relación que permita representar una jerarquía

de empleados dentro de una empresa, de los empleados se tiene su número de
empleado, nombre y RFC, y se muestra una jerarquía de ejemplo a continuación, aunque
el número de niveles debe ser variable.

Aunque originalmente se puede considerar jerarquía como una relación, realmente es una
asociación entre empleados, por lo que se le considera una relación.

Identificar las Entidades con sus atributos así como su llave primaria y/o discriminador e
Identificar las Relaciones y su cardinalidad

Entidades:
Empleado(noEmp,nombre,RFC)

Relaciones:
Jerarquía(empleado jefe, empleado subordinado) 1-N

Notas:
 1) Aunque a primera vista Jerarquía parece una entidad, en realidad es una relación
que asocia entre sí a entidades Empleado, como en esta relación solo participan
entidades empleado, es necesario especificar el papel que juega cada empleado en
la relación, de tal manera que se indica que el primero que aparece tiene el papel
de jefe (1) y el segundo de subordinado (N), este tipo de relaciones se consideran
como recursivas, ya que la estructura se mantiene en los diferentes niveles de la
jerarquía.
2) Si un conjunto de entidades juega más de un rol en una relación, el indicador de rol
concatenado con un nombre de atributo del conjunto de entidades nos da un
nombre único para cada atributo en el conjunto de relaciones.

A partir del listado de Entidades y Relaciones se procede a elaborar el diagrama, que

queda como sigue:

Diagrama Entidad-Relación

2.1.6 GENERALIZACIÓN Y ESPECIALIZACION:

Un conjunto de entidades puede incluir subgrupos de entidades que se diferencian de alguna

forma de las otras entidades del conjunto. Por ejemplo, un subconjunto de entidades en un
conjunto de entidades puede tener atributos y/o relaciones que no son compartidos por todas las
entidades del conjunto de entidades. El modelo E-R proporciona una forma de representación de
estos grupos de entidades distintos.
Considérese el conjunto de entidades persona con atributos CURP, nombre, calle y ciudad. Una
persona puede clasificarse además como cliente o empleado, Cada uno de estos tipos de persona
se describen mediante un conjunto de atributos que incluyen los atributos del conjunto de
entidades persona más otros posibles atributos adicionales. Por ejemplo, las entidades cliente se
pueden describir además mediante el atributo descuento, mientras que las entidades empleado se
pueden describir además mediante los atributos puesto y sueldo, también una entidad empleado
puede estar asociado con una entidad departamento, mientras una entidad clientes puede estar
asociado con los productos que compra, y la entidad persona se asocia con la ciudad en que vive.
El proceso de designación de subgrupos dentro de un conjunto de entidades se denomina
especialización. La especialización de persona permite distinguir entre las personas basándose en
si son empleados o clientes.

En términos de un diagrama E-R, la especialización se representa mediante un componente

triangular etiquetado ES, como se muestra en la Figura 2.1.6.1. La etiqueta ES representa, por
ejemplo, que un cliente «es» una persona. La relación ES se puede llamar también relación
superclase-subclase. Los conjuntos de entidades de nivel más alto y más bajo se representan como
conjuntos de entidades regulares, es decir, como rectángulos que contienen el nombre del
conjunto de entidades. Es(persona,Cliente,Empleado)

La generalización es el proceso de abstracción inverso a la especialización. Se quitan las diferencias

entre varios tipos de entidades y generalizamos sus características comunes para formar una
entidad superclase. Dependiendo de si las subclases pueden aparecer en más de una subclase
podemos observar dos tipos:

 Subclases disjuntas
  Subclases solapadas

La jerarquía es el proceso de subdividir una entidad en varias subentidades relacionándolas con la

entidad a la que se refieren. Puede haber dos tipos:

 Total: que significa que no hay otro subtipo.

 Parcial: significa que pueden haber otros subtipos.

Y los dos tipos de subentidades que puede haber, se dividen en dos también:

 Exclusiva: que significa que una subentidad no puede ser otra.

 Solapada: significa que una subentidad también puede ser otra.

Por ejemplo, en una empresa la entidad EMPLEADO con atributos Nombre, DNI, Dirección,
Teléfono, fecha de nacimiento, Salario y Puesto se divide en:

 Arquitectos con atributos COMISIONES Y NUMERO DE PROYECTOS.

 Administrativos con atributos PULSACIONES Y NIVEL
 Ingenieros: con atributos ESPECIALIDAD Y AÑOS DE EXPERIENCIA

En el diagrama Entidad-Relación quedaría de la siguiente forma:

CONSIDERACIONES:

 Generalización Total: todos los elementos de un tipo pertenecen a un subtipo, es decir,

que no hay otro subtipo.
 Generalización Parcial: significa todo lo contrario, que si hay otros subtipos, muchas veces
no aparecen en la jerarquía pero lo tienes que suponer.
  Generalización exclusiva: significa que un subtipo no puede ser otro, simplemente puede
ser el mismo sin tener otra segunda opción.
 Generalización solapada: un subtipo puede tener la opción de ser otro subtipo, es decir,
que no es único.
 Por tanto: generalizaciones totales y exclusivas, totales y solapadas, parciales y exclusivas,
parciales y solapadas pueden ser las opciones que podemos tener a la hora de hacer una
jerarquía.

Por ejemplo:

Veamos un último ejemplo para aclarar los conceptos

El Ayuntamiento quiere una BD de las personas de la ciudad. Se distinguen los trabajadores, los
estudiantes y los parados. De los trabajadores queremos conocer el número de la Seguridad
Social, la empresa y el salario. De los estudiantes, el número de matrícula y el centro educativo. De
los parados la fecha desde que está parado.
Una posible solución sería:
2.2 Modelo Relacional.

Edgar F. Codd propuso el modelo de datos relacional en 1970. En ese momento, la mayoría de los
sistemas de bases de datos se basaban en uno de los dos modelos de datos más antiguos (el
modelo jerárquico y el modelo de red); el modelo relacional revolucionó el campo de la base de
datos y remplazó en gran medida a estos modelos anteriores. Hoy en día, el modelo relacional es,
con mucho, el modelo de datos dominante y es la base de los productos DBMS líderes, que
incluyen la familia DB2 de IBM, Informix, Oracle, Sybase, Access y SQLServer de Microsoft,
FoxBase, Paradox, MySQL, PostgreSQL entre otros. Los sistemas de bases de datos relacionales son
omnipresentes en el mercado y representan una industria multimillonaria.

El modelo relacional es muy simple y elegante; una base de datos es una colección de una o más
relaciones, donde cada relación es una tabla con filas y columnas. Esta simple representación
tabular permite que incluso los usuarios novatos comprendan el contenido de una base de datos,
y permite el uso de lenguajes simples y de alto nivel para consultar los datos. Las principales
ventajas del modelo relacional sobre los modelos anteriores son su simple representación de
datos y la facilidad con la que se pueden expresar incluso las consultas complejas.

La estructura del modelo relacional es realmente muy sencilla, los elementos que la forman son
Dominios, relaciones, atributos, llaves candidatas, primarias, foráneas y reglas de integridad., las
cuales se explican a continuación:

2. 2. 1. Dominios, atributos y relaciones

Dominio: Un dominio es un conjunto finito de valores homogéneos y atómicos caracterizados por

un nombre; se dice que son homogéneos porque estos valores son todos del mismo tipo y
atómicos porque son indivisibles. Los tipos de datos en programación definen dominios, como los
números enteros, fechas, etc., es decir en programación un dominio es un tipo de datos, ya sea
definido por el sistema o por el usuario. En bases de datos un dominio puede definir además un
conjunto de valores, es decir, todos los valores posibles del tipo en cuestión.

Ejemplos de dominios son:

 Colores: Es el conjunto de los colores, por ejemplo: {rojo, verde, azul, amarillo, blanco,
negro, morado}.
 Edad: Edades posibles de los empleados entre 18 y 80 años.
 Teléfono: Es el conjunto de números de teléfono válidos, formados por diez dígitos.

Cada atributo de una base de datos relacional se define sobre un dominio, los cuales solo podrán
tomar los valores del dominio, puede haber varios atributos definidos sobre el mismo dominio.
Relaciones: Es La construcción principal para representar los datos en el modelo relacional, este
modelo se basa en el concepto matemático de relación, el cual nos dice:

Dados n dominios D1, D2, …,Dn, una relación sobre esos n dominios debe
contener un conjunto de n-tuplas, con atributos a1, a2, …, an donde a1 pertenece
D1, a2 a D2 y así sucesivamente, y este conjunto o relación será a su vez
subconjunto del producto cartesiano de D1 x D2 x…. x Dn.

Como ya se comentó, En el modelo relacional, las relaciones se utilizan para almacenar

información sobre los objetos que se representan en la base de datos. Y se representa
gráficamente como una tabla bidimensional con filas y columnas, en la que las filas corresponden
a tuplas o registros individuales y las columnas corresponden a los campos o atributos de esas
tuplas, a diferencia del Modelo E / R en el cual una relación es una asociación existente entre
entidades.

Por ejemplo, en la relación Alumno, se encuentran los dominios noControl, nombre, género,
CURP, Número de Seguridad Social y Clave de la Carrera. Esto se puede detallar de la siguiente
manera:
Alumno(noControl, nombre, genero, CURP,NSS,cveCarrera)

Y gráficamente se puede ver como se muestra:

Relación de alumnos representada de manera gráfica.

En la relación alumnos, cada tupla tiene 6 valores, uno para cada atributo. Las tuplas de una
relación no siguen ningún orden.

El grado de una relación es el número de atributos que contiene. La relación alumnos es de grado
seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con seis
valores.
La cardinalidad de una relación es el número de tuplas que contiene, en el caso de la relación
alumnos es 5.

Propiedades de las relaciones

 No existen tuplas duplicadas: debe ser obvio que el concepto de “tuplas duplicadas” no existe
puesto que no tendría sentido tener insertado un valor dos veces en una relación. Suponga que
la relación contiene una tupla que muestra un “hecho verdadero” con respecto a cierta
información. Si la relación contuviera un duplicado de esa tupla, simplemente nos estaría
diciendo, por segunda vez, el mismo “hecho verdadero”.

 No hay orden para las tuplas: en la Tabla alumnos, las tuplas también pudieron haber sido
mostradas en secuencia inversa, y seguiría siendo la misma relación.

 No hay un orden para los atributos: en la Tabla alumnos. Los atributos también podrían haber
sido mostrados en el orden NSS, nombre, cveCarrera, noControl, CURP y género y seguiría
siendo la misma relación.

 No existe el término “primer atributo” o “siguiente atributo”, es decir, siempre se hace

referencia al atributo por su nombre, no por su posición.

 Cada tupla contiene solo un valor para cada atributo, los valores son atómicos.

2. 2. 2 Claves (Llaves)

Las tuplas se pueden distinguir unas de otras, puesto que en una relación no hay tuplas repetidas y
éstas se pueden identificar por medio del valor de sus atributos.

Superllave: Es un atributo o un conjunto de atributos que identifican de modo único las tuplas de
una relación. Por ejemplo, tomando como base la relación Alumnos, el atributo NoControl es una
superclave, porque ayuda a distinguir una tupla de otra, puesto que un noControl no puede ser
igual a otro. En el modelo relacional podemos señalar tres tipos de Llaves: Llaves candidatas,
primarias y externas.
 Relación Alumnos

Llave candidata: Es un atributo o conjunto de atributos que pueden identificar de manera única a
una tupla de todas las demás y tiene como requisito que ningún subconjunto de una llave
candidata debe ser a su vez una llave candidata. Las claves candidatas deben ser seleccionadas de
manera cuidadosa, ya que, retomando el ejemplo, el nombre de una persona no es suficiente para
distinguir una tupla de otra, puesto que puede haber más de una persona con el mismo nombre.
El único modo de identificar las claves candidatas es conociendo el significado real de los
atributos, ya que esto permite saber si es posible que aparezcan duplicados, en el ejemplo, las
llaves candidatas son NoControl, CURP y NSS.

Llave primaria: Es posible que una relación tenga más de una llave candidata. El modelo relacional
requiere que sólo una de esas llaves se elija como llave primaria, y a las demás se les denominará
llaves alternas. La llave primaria de una relación es aquella llave candidata que escoge el diseñador
como la forma principal de identificar las tuplas de modo único. En el ejemplo de la relación
alumnos, se escoge el noControl como llave primaria.

Llave externa o foránea: Es un conjunto de atributos de una relación R1 cuyos valores coinciden
con los valores de la llave primaria de otra relación R2. Una llave externa puede ser simple o
compuesta ya que debe ser igual con la llave primaria con la que coincide. Cada atributo de la
llave externa de R1 debe del mismo tipo que los componentes de la clave primaria de R2.

En la siguiente figura se muestran dos relaciones (Alumnos y Carreras) y estas relaciones se

asocian entre sí por el atributo cveCarrera, el cual es llave primaria en la relación carrera y foránea
en la relación alumnos.

Asociación entre las relaciones alumnos y carrera por medio de la llave foránea

2. 2. 3 Valores nulos

Cuando en una tupla el valor de un atributo es nulo (Ω), se dice que es desconocido. El nulo
implica la ausencia de información y no un valor de cero ni una cadena vacía. La necesidad de
valores nulos es evidente por diversas razones:
 Existencia de tuplas con ciertos atributos desconocidos en ese momento.
 Necesidad de añadir un nuevo atributo a una tabla ya existente; atributo que en el momento
de introducirse no tendrá ningún valor para las tuplas de la relación.
 Posibilidad de atributos que no son aplicables a ciertas tuplas, como la editorial para un
artículo.

2. 2. 4 Reglas de Integridad

Existen 3 tipos de reglas

1.- Regla de integridad de entidades: Esta regla de integridad se aplica a las llaves primarias de las
relaciones, y se debe cumplir con lo siguiente:

 No puede haber valores duplicados de llave primaria en una relación.

 ningún componente de la llave primaria de una relación debe tener valores nulos.

2.- Regla de integridad referencial: Esta regla se aplica a las llaves foráneas y dice que el valor de la
llave foránea de una relación debe ser:

 Nulo o
 Igual al valor de la llave primaria de alguna tupla de la relación a la que hace referencia.

Por ejemplo el valor de la cveCarrera de la relación alumnos puede ser nulo, lo que significa que el
alumno aun no escoge su carrera o igual a {S, E, A, Q}, ya que éstos son los valores de las llaves
primarias de las tuplas de la relación carreras.

3.- Reglas de negocio: Además de las dos reglas de integridad anteriores, los usuarios o los
administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los
datos, denominadas reglas de negocio. Por ejemplo, si en una oficina de cierta empresa sólo
puede haber hasta quince empleados, el SGBD debe dar la posibilidad al usuario de definir una
regla al respecto y debe hacerla respetar. En este caso, no debería permitir dar de alta un
empleado en una oficina que ya tiene los quince permitidos. O por ejemplo si un alumnos solo
puede cursar durante 12 semestres su carrera, no debe permitirle inscribirse a un 13vo semestre.
Otra regla podría indicar que el alumno debe escoger su carrera al inscribirse, lo que significa que
la cveCarrera de la relación alumnos no debe aceptar valores nulos.
2. 2. 5. Diagrama del modelo relacional

Para elaborar este diagrama se utiliza la siguiente notación:

Por ejemplo: Elaborar un diagrama de modelo relacional que represente esta BD

El diagrama quedaría como sigue:

2.3 Transformación de Modelo Entidad-Relación a Modelo Relacional.

2.3.1 El proceso de transformación

Los modelos Entidad-Relación y el de bases de datos relacionales son representaciones abstractas

y lógicas de datos del mundo real. Debido a que los dos modelos emplean principios de diseño
similares, se puede convertir fácilmente un diseño Entidad-Relación en un diseño relacional.

Convertir los elementos del modelo Entidad-Relación a un grupo de tablas es la base para elaborar
un diseño de bases de datos relacional a partir de un diagrama E-R. Aunque existen diferencias
importantes entre una relación y una tabla, una relación se puede considerar informalmente como
una tabla de valores. Las restricciones que se especifican en un diagrama E-R, tales como las claves
primarias y cardinalidad y membresía también tienen su correspondencia con las restricciones del
modelo relacional.
De A
2. 3. 2 Transformación de entidades

En el proceso de transformación, cada entidad fuerte se convierte en una tabla, con todos sus
atributos, y conservando su llave primaria.

Las entidades débiles también se convierten en tablas, pero como éstas no tienen llave primaria,
se debe identificar la entidad fuerte de la que depende su existencia, de forma que la llave
primaria de la tabla resultante se compone de la llave primaria de esa entidad dominante y el
discriminador de la entidad débil. La llave primaria de la entidad dominante al pasar como atributo
de la entidad débil se considera llave foránea.
2. 3. 3 Transformación de Relaciones.

Relaciones Binarias: en este tipo de relaciones tenemos 3 casos 1-N, N-N y 1-1, en las de
cardinalidad 1-N y N-N, no importa la membresía de las entidades en la relación, en las de
1-1 la membresía si es importante.

Transformación de relaciones 1-N

Transformación de relaciones N-N
Transformación de relaciones 1-1

Transformación de Relaciones terciarias

El proceso es similar al de las relaciones binarias, si se trata de una relación 1-1-1 con membresía
total, la llave primaria de dos de ellas pasa como llave foránea de la tercera, no importa a cuál de
ellas, en el caso de que una o dos de ellas tengan membresía parcial, se elige alguna de las que
tengan membresía total, en relaciones 1-1-N la tabla de la relación con cardinalidad N recibe como
foránea las llaves primarias de las dos con membresía 1, y si la relación tiene 2 o más N, se crea
una tabla nueva y las llaves primarias de las tres entidades que asocia pasan como llave primaria y
foránea de la nueva tabla.

Transformación de relaciones de generalización y especialización.

Ejemplos:

Problema 1

Convertir el diagrama entidad-relación del problema 1 (ordenes) a diagrama de modelo

relacional
Transforma entidades fuertes y débiles

Transforma Relaciones N-N

Transforma relaciones 1-N y 1-1

Diagrama final
Problema 2

Convertir el diagrama entidad-relación del problema 2 (alumnos) a diagrama de modelo

relacional

Solución
Problema 3

Convertir el diagrama entidad-relación del problema 3 (Jerarquía de empleados a

diagrama de modelo relacional

Diagrama Entidad-Relación Jerarquía de empleados

Solución:

Diagrama relacional Jerarquía de empleados

2.4 Definición del esquema de la Base de datos Relacional.

El esquema de la base de datos relacional describe los objetos que forman la base de datos a nivel
conceptual, este incluye la definición de las tablas, sus columnas, así como la definición de llaves
primarias, foráneas y de las reglas de negocio aplicables para cuidar la integridad de los datos. Este
esquema se define utilizando el sublenguaje de datos que se incluye con el manejador de bases de
datos, en este caso por tratarse de un manejador de bases de datos relacional, el sublenguaje de
datos utilizado es el SQL (structured Query Languaje) o lenguaje estructurado de consulta.

Como ya se vio en el módulo anterior, los manejadores de bases de datos tienen entre sus
componentes un Sublenguaje de datos (DSL), el cual es una combinación de varios lenguajes:

 Lenguaje de definición de datos DDL: Se usa para definir cómo estará estructurado el
esquema de la base de datos.

 Lenguaje de manipulación de datos DML: Sirve para describir las operaciones que se
aplicarán a la base de datos como son la inserción, borrado, recuperación y
actualización de los datos.

 Lenguaje de control de datos DCL: Se usa para expresar el código que controlará el acceso
de usuarios y sus privilegios.

2.4.1 Lenguaje estructurado de consulta (SQL).

El lenguaje estructurado de consulta (SQL) es el lenguaje de base de datos relacional comercial y

libre más utilizado. Fue desarrollado originalmente en IBM en los proyectos SEQUEL-XRM y
System-R (1974-1977). Casi inmediatamente, otros proveedores introdujeron productos DBMS
basados en SQL, y ahora se ha convertido en el sublenguaje de datos más utilizado para crear,
manipular y consultar DBMS relacionales, dado que existen muchos proveedores de productos
SQL fue necesario definir un estándar, El primer estándar de SQL fue desarrollado en 1986 por el
American National Standards Institute (ANSI) y se denominó SQL-86. Hubo una revisión menor en
1989 llamada SQL-89, y una revisión importante en 1992 llamada ANSI/ISO SQL-92, en la que
colaboró la Organización Internacional de Normalización (ISO). La mayoría de DBMS comerciales y
libres lo soportan. Por lo que la sintaxis utilizada en este curso se basa en éste.

El lenguaje estructurado de consulta (SQL) tiene varios componentes:

  El lenguaje de definición de datos (DDL): este subconjunto de SQL admite la creación,
eliminación y modificación de las definiciones de bases de datos, tablas y vistas, el cual se
cubre en este módulo.

 El lenguaje de manipulación de datos (DML): este subconjunto de SQL permite a los

usuarios plantear consultas, insertar, eliminar y modificar datos en la base de datos. Que
se cubrirá en el módulo 3.

2.4.2 Lenguaje de definición de datos (DDL)

Como se comentó anteriormente, el lenguaje de definición de datos de SQL permite la creación,

eliminación y modificación de las definiciones de bases de datos, tablas y vistas, restricciones de
integridad que se pueden definir en las tablas, ya sea cuando se crea la tabla o más adelante. El
DDL también proporciona comandos para especificar derechos de acceso o privilegios a tablas y
vistas.

Para crear el esquema de la base de datos relacional, se utilizan básicamente 4 cláusulas de su

lenguaje de definición de datos, estas son:

 Creación de la base de datos (create database)

 Creación de tablas (Create table)
 Modificación de tablas (Alter table)
 Elimina tabla o base de datos (Drop)

2.4.3 Creación de la base de datos (create database)

Sintaxis:

CREATE DATABASE nombreBase;

Por ejemplo:

Create database Alumnos;

Notas:

1. Bajo Linux o Unix, los nombres de los objetos definidos por el usuario (en este caso la base de
datos Alumnos) distinguen entre mayúsculas y minúsculas (a diferencia de las palabras clave de
SQL), por lo que siempre debe referirse a su base de datos como Alumnos, no como alumnos,
ALUMNOS o alguna otra variante. Esto también es cierto para los nombres de tablas,
 columnas, etc. (esta restricción no se aplica bajo Windows. Sin embargo, la mejor práctica
recomendada es usar el mismo tipo de letra que se usó cuando se creó la base de datos).

2. La creación de una base de datos no la selecciona para su uso; se debe hacer explícitamente.
Para hacer que Alumnos sea la base de datos actual, use esta declaración: USE Alumnos

3. La base de datos solo debe crearse una vez, pero se debe seleccionarla para su uso cada vez
que comience una sesión. Puede hacerlo emitiendo una declaración USE como se muestra en el
ejemplo.

Una vez creada la base de datos, se puede observar que está vacía ya que se creó la estructura
para iniciar el trabajo, como se puede observar si ejecutamos las siguientes clausulas:

2.4.4 Creación de tablas (Create table)

Esta cláusula nos permite crear las tablas o relaciones que forman la base de datos, definiendo sus
columnas, llaves primarias y foráneas así como las reglas de negocio correspondiente

Sintaxis:
Tipos de dato más comunes:

Integer Entero, 4 bytes El rango es de –2,147,483,648 a 2,147,483,647

Smallint Entero, 2 bytes el rango es de -32,768 a 32,767.
Tinyint Entero, 1 byte El rango es de 0 a 255.
Float[(n)] Numérico de punto flotante, 8 bytes. Con un valor comprendido entre - 1,79E + 308 y
1,79E + 308. n es el número de bits que se utilizan para almacenar la mantisa del
número float en notación científica y por tanto dicta su precisión y el tamaño de
almacenamiento. n tiene que ser un valor entre 1 y 53.
Real Numérico de punto flotante, 4 bytes. Similar al Float. Tiene una precisión de 7 dígitos.
Entre –3.40E + 38 y 3.40E + 38.
Decimal[(p[, s])] Números de precisión y escala fijas. los valores permitidos están entre - 10^38 -1 y
Numeric[(p[, s])] 10^38 - 1. p especifica el número máximo total de dígitos decimales a la izquierda del
punto y s especifica el número máximo de dígitos decimales a la derecha del punto.
Text Tipo de dato de longitud variable, puede almacenar 2,147,483,674 caracteres.
ntext Datos Unicode de longitud variable con una longitud máxima de 1,073,741,823)
caracteres. El
Char[(n)] Datos de caracteres longitud fija, con n caracteres. n tiene que estar comprendido
entre 1 y 8,000.
Varchar(n) Datos de caracteres longitud variable, con una longitud máxima de n caracteres. n
tiene que ser un valor comprendido entre 1 y 8,000
DateTime Datos de fecha y hora comprendidos entre el 1 de enero de 1753 y el 31 de diciembre
de 9999
Date Datos de fecha en formato 'YYYY-MM-DD'. El rango admitido es '1000-01-01' a
'9999-12-31'.
Time Datos de tiempo en formato 'HH: MM: SS' (o el formato 'HHH: MM: SS' para valores
de horas grandes).
Bit Es un tipo de dato especial, puede almacenar solo 1 , 0
Definición de Restricciones (constraint):

Llaves primarias:

Constraint nombreConstraint primary key (lista de columnas)

Nota: La lista de columnas es el nombre de la columna que forma la llave primaria

de la tabla o los nombres de las columnas que forman la llave primaria
separadas por comas, si ésta es compuesta.

Llaves foráneas:

Constraint nombreConstraint foreign key (lista de columnas 1)

References nombreTabla(lista de columnas 2)

Nota:
1. La lista de columnas 1 es la llave foránea de la tabla.
2. la lista de columnas 2 es la llave primaria de la tabla (nombreTabla) a la que se
hace referencia.
3. los nombres de las columnas que forman una llave foránea no necesariamente
deben ser iguales a los nombres de las columnas de la llave primaria a la cual
hacen referencia, pero deben estar en el mismo orden y ser del mismo tipo.

Reglas de negocio:

Constraint nombreConstraint check (condición)

Nota: la condición es cualquier condición valida en SQL que actué solamente sobre las
columnas de la tabla.

Para seguir un estándar con los nombres de las restricciones, los nombraremos con el nombre de
la tabla y concatenándole la terminación PK para la llave primaria, FK1. FK2,.., FKn para llaves
foráneas y CK1, Ck2,…, CKn para las reglas de negocio.

Por ejemplo, del diagrama relacional de la base de datos de ordenes

La definición de la tabla Estado quedaría de la siguiente forma:

Para definir el orden en que aparecen las tablas en el esquema se debe considerar las llaves
foráneas de las mismas, por ejemplo en este esquema no se puede crear la tabla de cliente si no
se crea antes la de estado, de igual manera antes de crear la tabla de órdenes, se debe haber
creado clientes y productos.

Problema 1

Definir el esquema de la base de datos de órdenes a partir el diagrama de modelo

relacional.
Para hacer más interesante el ejercicio, se la añadirán las siguientes reglas de negocio:

1. El cargo por entrega debe tener valores entre 10 y 100.

2. El status de los clientes solo puede tomar valores 10, 20, 30 y 40.
3. La cantidad ordenada de un producto no puede ser menor a 0
4. Los colores de los productos solo pueden ser amarillo, verde, azul, rojo, negro y
blanco
5. El saldo de las cuentas no puede ser negativo
6. El importe de los movimientos debe ser mayor a 0

Solución:

El esquema de la base de datos quedaría de la siguiente manera:

Problema 2

Definir el esquema de la base de datos de Alumnos a partir del diagrama de modelo relacional
obtenido anteriormente.
Para la creación del esquema de la base de datos se tomarán los tipos de datos y reglas de negocio
que se muestran a continuación:
El esquema quedaría como sigue:

Como se puede observar la llave primaria de la tabla formadaPor está compuesta por los atributos
clave de carrera y clave de materia (cveCarrera,cveMat) y la clave de carrera (cveCarrera) es llave
foránea (FK1) que referencia a la llave primaria (cveCarrera) de la tabla carrera, y la clave de
materia (cveMat) también es llave foránea (FK2) que referencia a la llave primaria (cveMat) de la
tabla materia.
Las tablas de alumno y maestro tienen la clave de carrera (CveCarrera) como llave foránea que
referencian a clave de carrera (cveCarrera) de la tabla carrera.

La tabla grupo, se genera a partir de una entidad débil dependiente de materia, por lo que tiene
llave primaria compuesta con la clave de materia (que a su vez es llave primaria de materia) y el
número de grupo (cveMat,noGpo), esta dependencia hace necesario tener la llave foránea (FK1)
donde la clave de la materia (cveMat) referencie a la tabla de materias.

La tabla lista de acuerdo con el diagrama relacional, asocia entre sí a las tablas grupo y alumno, y
su llave primaria está compuesta por 3 columnas, dos que hereda (la llave primaria) de la tabla
grupo (cveMat,noGpo) y el otro por la llave primaria de la tabla alumno (noCont). Algo que es
importante hacer notar es que solo tiene dos llaves foráneas, la primera (FK1), es compuesta, ya
que debe corresponder con la llave primaria de grupo, y la segunda corresponde a la llave primaria
de alumno.
La tabla de Kardex, resultante de una asociación entre materia, alumno y oportunidad, tiene su
llave primaria compuesta por las llaves primarias de las tres tablas y su correspondiente llave
foránea para cada una de ellas.

Y por último, la tabla preRequistos, que asocia a una materia con sus prerrequisitos, tiene como
llave primaria la combinación de clave de materia y clave de materia, como no es posible repetir el
nombre de las columnas en una tabla, se les agregó el papel al nombre de la columna para
diferenciarlas, en este caso el nombre de las llaves foráneas es diferente al de la llave primaria a la
cual hace referencia.

Problema 3

Definir el esquema de la base de datos para representar la jerarquía de Empleados que se muestra
en el siguiente diagrama de modelo relacional.
La llave foránea noEmpJefe hace referencia a la llave primaria de la misma tabla empleado
(noEmp).

2.4.5 Modificación de tablas (Alter table)

Con esta cláusula se pueden adicionar y/o eliminas columnas y restricciones (constraint)

Adicionar columna y/o constraint:

Alter table nombreTabla add {definición de columna| definicion de constraint}

Por ejemplo:
Eliminar columna y/o constraint:

Alter table nombreTabla drop {column nombreColumna | constraint nombreConstraint}

Por ejemplo:

No se puede modificar la definición de una columna o constraint directamente, por ejemplo si se

quiere cambiar el tipo o tamaño de una columna, se debe eliminar la columna y volver a
adicionarla.

2.4.6 Elimina tabla o base de datos (Drop)

Elimina una base de datos – Drop database nombreBase

Elimina una tabla – Drop table nombreTabla

Nota: al eliminar una tabla se deben respetar las llaves foráneas, no se puede eliminar una tabla si
alguna otra tabla tiene una llave foránea que referencia a esta tabla.