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

E18

E55 E56

E2

E25

E5

E10 E11

E67 E4

E23

E17

E18 E12

E35 E26 E14

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])] Numeric[(p[, s])]

Números de precisión y escala fijas. los valores permitidos están entre - 10^38 -1 y 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.