1

UNIVERSIDAD TECNOLOGICA DE HONDURAS

DISEO BASE DE DATOS

TAREA INVESTIGACION CONCEPTOS SQL

ING HECTOR CASTILO

ALUMNO: KENNETH ELVIR

CUENTA#: 200760530006

III PERIODO 2016

Kenneth Elvir

200760530006

Ing. Castillo

I
NDICE

Portada.1

ndice2

Introduccin.3

SQL constraints..4

Vistas SQL...9

ndices SQL...13

Comandos DROP, TRUNCATE16

Normalizacin Base Datos.18

Kenneth Elvir

200760530006

Ing. Castillo

INTRODUCCION

El siguiente trabajo consiste en profundizar ms en el conocimiento

sobre base de datos orientado a MICROSOFT SQL al igual esta
investigacin abarcara otros motores de base datos, aprenderemos
sobre el uso correcto de las restricciones en base de datos para
obtener el mejor desarrollo de nuestras tablas, al igual que las
vistas que son un aspecto muy importante en el rea de la base
datos, normalizacin para el mejor control y orden de datos, ndices
y comandos necesarios para la manipulacin perfecta de nuestros
datos.

Kenneth Elvir

200760530006

Ing. Castillo

CONSTRAINTS O RESTRICCIONES

Para asegurar la integridad de los datos almacenados en nuestras tablas, podemos

crear restricciones, algunos los hemos utilizado sin querer o simplemente
desconocemos que lo que hicimos fue una restriccin, por ejemplo, una llave primaria.
Estas restricciones las podemos implementar al momento de crear nuestras tablas o
de modificarlas, tambin es necesario sealar que dichas restricciones son objetos
propios de la base de datos y por lo tanto requieren de un nombre nico compuesto
del nombre del esquema al que pertenece y el nombre que lo identifica, un ejemplo
sera nombreEsquema.nombreRestriccion.

Los diferentes tipos de restriccin que existen son:

PRIMARY KEY
UNIQUE
FOREIGN KEY
CHECK
DEFAULT

PRIMARY KEY

Es la ms comn de todas debido a que cada una de nuestras tablas debe ser
completamente relacional y para lograr esto siempre debe existir una llave primaria
dentro de cada tabla que identifique cada fila como nica.

Para generar una llave primaria desde la creacin de una tabla:

Modificando una tabla:

Kenneth Elvir

200760530006

Ing. Castillo

Es posible agregar ms columnas como parte de una llave primaria, se recomienda

como buena prctica utilizar una nomenclatura en el nombre de la restriccin que
ayude a identificar de que tipo es, adems de tener especial cuidado en nombrar las
columnas que forman parte de la llave primaria ya que ests mismas sern utilizadas
como referencia en una llave fornea en otra tabla. Cada vez que generamos una llave
primaria, esta crea un ndice tipo de clustered automticamente.

Existen ciertos requerimientos para la creacin de una llave primaria:

La o las columnas utilizadas en una restriccin PRIMARY KEY, no pueden aceptar
NULL.
No se pueden repetir valores en la o las columnas, deben ser nicos.
Solamente puede existir una restriccin de tipo PRIMARY KEY por cada tabla.
Para verificar las llaves primarias contenidas en nuestra base de datos podemos
utilizar el siguiente cdigo:

UNIQUE

Este tipo de restriccin es muy parecida a PRIMARY KEY, las diferencias son las
siguientes:
Tambin genera un ndice automticamente pero es de tipo de NON CLUSTERED.
La tabla puede tener ms de una restriccin de tipo UNIQUE.
Si puede aceptar NULL, pero solo una fila puede contenerlo ya que como su nombre lo
indica, es de tipo UNIQUE o nico.

Kenneth Elvir

200760530006

Ing. Castillo

FOREIGN KEY

Se forma de una columna o la combinacin de varias columnas de una tabla que sirve
como enlace hacia otra tabla donde en esta ltima, dicho enlace son la o las columnas
que forman la PRIMARY KEY. En la primera tabla donde creamos la llave fornea es
posible que existan valores duplicados de la/las columnas que conforman la llave
primaria de la segunda tabla, adems las columnas involucradas en la llave fornea
deben tener el mismo tipo de datos que la llave primaria de la segunda tabla. Una llave
fornea no crea un ndice automticamente, por lo que se recomienda generar uno
para incrementar el rendimiento de la consulta.

Algunos requerimientos para la restriccin FOREIGN KEY:

Los valores ingresados en la o las columnas de la llave fornea, deben existir en la
tabla a la que se hace referencia en la o las columnas de la llave primaria.
Solo se pueden hacer referencia a llaves primaria de tablas que se encuentren dentro
de la misma base de datos.
Puede hacer referencia a otra columnas de la misma tabla.

Kenneth Elvir

200760530006

Ing. Castillo

7
Solo puede hacer referencia a columnas de restricciones PRIMARY KEY o UNIQUE.
No se puede utilizar en tablas temporales.
Para consultar las restricciones FOREIGN KEY, se puede utilizar:

CHECK

Con este tipo de restriccin, se especifica que los valores ingresados en la columna
deben cumplir la regla o formula especificada. Por ejemplo:

Kenneth Elvir

200760530006

Ing. Castillo

8
Algunos requerimientos son:
Una columna puede tener cualquier nmero de restricciones CHECK.
La condicin de bsqueda debe evaluarse como una expresin booleana y no puede
hacer referencia a otra tabla.
No se pueden definir restricciones CHECK en columnas de tipo text, ntext o image.
Ventajas:
Las expresiones utilizadas son similares a las que se usan en la clausula WHERE.
Pueden llegar a ser una mejor alternativa que los TRIGGERS o disparadores.
Tener siempre en mente:
Al momento de crear nuestra expresin, tomar en cuenta si la columna acepta valores
NULL, por ejemplo si definimos nuestra restriccin que acepte solo valores positivos
( nombreColumna1>=0), NULL es un valor desconocido por lo tanto se insertar en la
columna.
No es posible obtener el valor previo despus de realizar un UPDATE, si esto es
necesario se recomienda usar un TRIGGER.
Para consultar las restricciones CHECK se puede utilizar:

DEFAULT

Se puede decir que no es una restriccin, ya que solo se ingresa un valor en caso de
que ninguno otro sea especificado. Si una columna permite NULL y el valor a insertar
no se especifica, se puede sustituir con un valor predeterminado.

Kenneth Elvir

200760530006

Ing. Castillo

VISTAS SQL

Una vista es una alternativa para mostrar datos de varias tablas. Una vista es
como una tabla virtual que almacena una consulta. Los datos accesibles a
travs de la vista no estn almacenados en la base de datos como un objeto.
Entonces, una vista almacena una consulta como un objeto para utilizarse
posteriormente. Las tablas consultadas en una vista se llaman tablas base. En
general, se puede dar un nombre a cualquier consulta y almacenarla como una
vista.
Una vista suele llamarse tambin tabla virtual porque los resultados que retorna
y la manera de referenciarlas es la misma que para una tabla.

Kenneth Elvir

200760530006

Ing. Castillo

10

Las vistas permiten:

- ocultar informacin: permitiendo el acceso a algunos datos y manteniendo
oculto el resto de la informacin que no se incluye en la vista. El usuario opera
con los datos de una vista como si se tratara de una tabla, pudiendo modificar
tales datos.
- simplificar la administracin de los permisos de usuario: se pueden dar al
usuario permisos para que solamente pueda acceder a los datos a travs de
vistas, en lugar de concederle permisos para acceder a ciertos campos, as se
protegen las tablas base de cambios en su estructura.
- mejorar el rendimiento: se puede evitar tipear instrucciones repetidamente
almacenando en una vista el resultado de una consulta compleja que incluya
informacin de varias tablas.
Podemos crear vistas con: un subconjunto de registros y campos de una tabla;
una unin de varias tablas; una combinacin de varias tablas; un resumen
estadstico de una tabla; un subconjunto de otra vista, combinacin de vistas y
tablas.
Una vista se define usando un "select".
La sintaxis bsica parcial para crear una vista es la siguiente:
create view NOMBREVISTA as
SENTENCIASSELECT
from TABLA;

El contenido de una vista se muestra con un "select":

select *from NOMBREVISTA;

En el siguiente ejemplo creamos la vista "vista_empleados", que es resultado
de una combinacin en la cual se muestran 4 campos:

create view vista_empleados as

select (apellido+' '+e.nombre) as nombre,sexo,
s.nombre as seccion, cantidadhijos
from empleados as e
join secciones as s

Kenneth Elvir

200760530006

Ing. Castillo

11

on codigo=seccion

Para ver la informacin contenida en la vista creada anteriormente tipeamos:

select *from vista_empleados;
Podemos realizar consultas a una vista como si se tratara de una tabla:
select seccion,count(*) as cantidad
from vista_empleados;
Los nombres para vistas deben seguir las mismas reglas que cualquier
identificador. Para distinguir una tabla de una vista podemos fijar una
convencin para darle nombres, por ejemplo, colocar el sufijo ?vista? y luego el
nombre de las tablas consultadas en ellas.
Los campos y expresiones de la consulta que define una vista DEBEN tener un
nombre. Se debe colocar nombre de campo cuando es un campo calculado o si
hay 2 campos con el mismo nombre. Note que en el ejemplo, al concatenar los
campos "apellido" y "nombre" colocamos un alias; si no lo hubisemos hecho
aparecera un mensaje de error porque dicha expresin DEBE tener un
encabezado, SQL Server no lo coloca por defecto.
Los nombres de los campos y expresiones de la consulta que define una vista
DEBEN ser nicos (no puede haber dos campos o encabezados con igual
nombre). Note que en la vista definida en el ejemplo, al campo "s.nombre" le
colocamos un alias porque ya haba un encabezado (el alias de la
concatenacin) llamado "nombre" y no pueden repetirse, si sucediera,
aparecera un mensaje de error.

Otra sintaxis es la siguiente:

create view NOMBREVISTA (NOMBRESDEENCABEZADOS)
as
SENTENCIASSELECT
from TABLA;
Creamos otra vista de "empleados" denominada "vista_empleados_ingreso"
que almacena la cantidad de empleados por ao:

create view vista_empleados_ingreso (fecha,cantidad)

as

Kenneth Elvir

200760530006

Ing. Castillo

12

select datepart(year,fechaingreso),count(*)
from empleados
group by datepart(year,fechaingreso)
La diferencia es que se colocan entre parntesis los encabezados de las
columnas que aparecern en la vista. Si no los colocamos y empleamos la
sintaxis vista anteriormente, se emplean los nombres de los campos o alias
(que en este caso habra que agregar) colocados en el "select" que define la
vista. Los nombres que se colocan entre parntesis deben ser tantos como los
campos o expresiones que se definen en la vista.
Las vistas se crean en la base de datos activa.
Al crear una vista, SQL Server verifica que existan las tablas a las que se
hacen referencia en ella.
Se aconseja probar la sentencia "select" con la cual definiremos la vista antes
de crearla para asegurarnos que el resultado que retorna es el imaginado.
Existen algunas restricciones para el uso de "create view", a saber:
- no puede incluir las clusulas "compute" ni "compute by" ni la palabra clave
"into";
- no se pueden crear vistas temporales ni crear vistas sobre tablas temporales.
- no se pueden asociar reglas ni valores por defecto a las vistas.
- no puede combinarse con otras instrucciones en un mismo lote.
Se pueden construir vistas sobre otras vistas.

Kenneth Elvir

200760530006

Ing. Castillo

13

INDICES SQL

Un ndice es una estructura de disco asociada con una tabla o una vista que
acelera la recuperacin de filas de la tabla o de la vista. Un ndice contiene
claves generadas a partir de una o varias columnas de la tabla o la vista.
Dichas claves estn almacenadas en una estructura (rbol b) que permite que
SQL Server busque de forma rpida y eficiente la fila o filas asociadas a los
valores de cada clave.
Una tabla o una vista puede contener los siguientes tipos de ndices:
Agrupado
Los ndices agrupados ordenan y almacenan las filas de los datos de la tabla o
vista de acuerdo con los valores de la clave del ndice. Son columnas incluidas
en la definicin del ndice. Slo puede haber un ndice clster por cada tabla,
porque las filas de datos slo pueden estar ordenadas de una forma.
La nica ocasin en la que las filas de datos de una tabla estn ordenadas es
cuando la tabla contiene un ndice clster. Cuando una tabla tiene un ndice
clster, la tabla se denomina tabla agrupada. Si una tabla no tiene un ndice
clster, sus filas de datos estn almacenadas en una estructura sin ordenar
denominada montn.
No agrupado
Los ndices no agrupados tienen una estructura separada de las filas de datos.
Un ndice no agrupado contiene los valores de clave de ndice no agrupado y
cada entrada de valor de clave tiene un puntero a la fila de datos que contiene
el valor clave.
El puntero de una fila de ndice no agrupado hacia una fila de datos se
denomina localizador de fila. La estructura del localizador de filas depende de
si las pginas de datos estn almacenadas en un montn o en una tabla
agrupada. Si estn en un montn, el localizador de filas es un puntero hacia la
fila. Si estn en una tabla agrupada, el localizador de fila es la clave de ndice
agrupada.
Puede agregar columnas sin clave al nivel hoja de un ndice no agrupado con
el fin de eludir los lmites existentes para las claves de ndice, 900 bytes y
columnas de 16 claves, as como para ejecutar consultas indizadas y
totalmente cubiertas. Para obtener ms informacin, vea ndice con columnas
incluidas.
Para obtener ms informacin acerca de la arquitectura de ndices, vea
Arquitectura de estructuras de tablas y datos de ndices.
Kenneth Elvir

200760530006

Ing. Castillo

14

Tanto los ndices agrupados como los no agrupados pueden ser nicos. Esto
significa que dos filas no pueden tener el mismo valor para la clave de ndice.
De lo contrario, el ndice no es nico y varias filas pueden compartir el mismo
valor de clave. Para obtener ms informacin, vea Directrices para disear
ndices nicos.
Los ndices se mantienen automticamente para una tabla o vista cuando se
modifican los datos de la tabla.
ndices y restricciones
Los ndices se crean automticamente cuando las restricciones PRIMARY KEY
y UNIQUE se definen en las columnas de tabla. Por ejemplo, cuando cree una
tabla e identifique una determinada columna como la clave primaria, Motor de
base de datos crea automticamente una restriccin PRIMARY KEY y un ndice
en esa columna. Para obtener ms informacin, vea Crear ndices (motor de
base de datos).
Cmo utiliza los ndices el optimizador de consultas
Los ndices bien diseados pueden reducir las operaciones de E/S de disco y
consumen menos recursos del sistema, con lo que mejoran el rendimiento de la
consulta. Los ndices pueden ser tiles para diversas consultas que contienen
instrucciones SELECT, UPDATE, DELETE o MERGE. Fjese en la consulta
SELECT Title, HireDate FROM HumanResources.Employee WHERE
EmployeeID = 250 en la base de datos AdventureWorks2008R2. Cuando se
ejecuta la consulta, el optimizador de consultas evala cada mtodo disponible
para recuperar datos y selecciona el mtodo ms eficiente. El mtodo puede
ser un recorrido de la tabla o puede ser recorrer uno o ms ndices si existen.
Al realizar un recorrido de la tabla, el optimizador de consultas leer todas las
filas de la tabla y extraer las filas que cumplen con los criterios de la consulta.
Un recorrido de la tabla genera muchas operaciones de E/S de disco y puede
consumir recursos. No obstante, puede ser el mtodo ms eficaz si, por
ejemplo, el conjunto de resultados de la consulta es un porcentaje elevado de
filas de la tabla.
Cuando el optimizador de consultas utiliza un ndice, busca en las columnas de
clave de ndice, busca la ubicacin de almacenamiento de las filas que necesita
la consulta y extrae las filas coincidentes de esa ubicacin. Generalmente, la
bsqueda del ndice es mucho ms rpida que la bsqueda de la tabla porque,
a diferencia de la tabla, un ndice frecuentemente contiene muy pocas
columnas por fila y las filas estn ordenadas.
El optimizador de consultas normalmente selecciona el mtodo ms eficaz
cuando ejecuta consultas. No obstante, si no hay ndices disponibles, el
optimizador de consultas debe utilizar un recorrido de la tabla. Su tarea
consiste en disear y crear los ndices ms apropiados para su entorno de
Kenneth Elvir

200760530006

Ing. Castillo

15

forma que el optimizador de consultas disponga de una seleccin de ndices

eficaces entre los que elegir. SQL Server proporciona el Asistente para la
optimizacin de motor de base de datos como ayuda en el anlisis del entorno
de la base de datos y en la seleccin de los ndices adecuados.

Kenneth Elvir

200760530006

Ing. Castillo

16

MANIPULACIONES SQL ELIMINAR TABLAS, BASE DATOS, COMANDO

TRUNCATE

Kenneth Elvir

200760530006

Ing. Castillo

17

Eliminar una base de datos DROP DATABASE

Para eliminar una base de datos tenemos la instruccin DROP DATABASE.

DROP DATABASE { nbBasedeDatos } [ ,...n ]

[;]

La base de datos puede ser una base de datos normal o una instantnea de
base de datos.
Para poder ejecutar la sentencia el usuario debe tener permiso de CONTROL y
se debe de ejecutar en un contexto diferente del de la base de datos a eliminar,
por ejemplo:
use b1

DROP DATABASE b1

Falla porque con el use estamos en el contexto de la base de datos a eliminar.

Como se ve en la sintaxis podemos eliminar varias bases de datos con una
sla sentencia DROP DATABASE.

Por ejemplo:
DROP DATABASE b1,b2
Elimina las bases de datos b1 y b2.

Kenneth Elvir

200760530006

Ing. Castillo

18

Normalizacin de Bases de Datos y Tcnicas de diseo

Uno de los factores mas importantes en la creacin de pginas web dinmicas
es el diseo de las Bases de Datos (BD). Si tus tablas no estan correctamente
diseadas, te pueden causar un montn de dolores de cabeza cuando tengas
de realizar complicadsimas llamadas SQL en el cdigo PHP para extraer los
datos que necesitas.Si conoces como establecer las relaciones entre los datos
y la normalizacin de estos,estars preparado para comenzar a desarrollar tu
aplicacin en PHP.Si trabajas con MySQL o con Oracle, debes conocer los
mtodos de normalizacin deldiseo de las tablas en tu sistema de BD
relacional. Estos mtodos pueden ayudarte a hacer tu cdigo PHP mas fcil de
comprender, ampliar, y en determinados casos,incluso hacer tu aplicacin mas
rpida.
Bsicamente, las reglas de Normalizacin estn encaminadas a eliminar
redundancias e inconsistencias de dependencia en el diseo de las tablas. Ms
tarde explicar lo que esto significa mientras vemos los cinco pasos
progresivos para normalizar, tienes que
tener en cuenta que debes crear una BD funcional y eficiente. Tambien
detallar los tipos de relaciones que tu estructura de datos puede tener.
Digamos que queremos crear una tabla con la informacin de usuarios, y los
datos a guardar son el nombre, la empresa, la direccin de la empresa y algun
e-mail, o bien URL si las tienen. En principio comenzarias definiendo la
estructura de una tabla como esta:

Formalizacin CERO

Diramos que la anterior tabla esta en nivel de Formalizacion Cero porque

ninguna de nuestras reglas de normalizacin ha sido aplicada. Observa los
campos url1 y url2 --

Kenneth Elvir

200760530006

Ing. Castillo

19

Qu haremos cuando en nuestra aplicacin necesitemos una tercera url ?

Quieres tener que aadir otro campo/columna a tu tabla y tener que
reprogramar toda la entrada de datos de tu cdigo PHP ? Obviamente no, tu
quieres crear un sistema funcional que pueda crecer y adaptarse fcilmente a
los nuevos requisitos. Hechemos un vistazo a las reglas del Primer Nivel de
Formalizacin-Normalizacin, y las aplicaremos a nuestra tabla.

Primer nivel de Formalizacin/Normalizacin. (F/N)

1. Eliminar los grupos repetitivos de la tablas individuales.

2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
Ves que estamos rompiendo la primera regla cuando repetimos los campos
url1 y url2 ? Y que pasa con la tercera regla, la clave primaria ? La regla tres
bsicamente significa que tenemos que poner una campo tipo contador
autoincrementable para cada registro. De otra forma, Qu pasaria si
tuvieramos
dos usuarios llamados Joe y queremos diferenciarlos. Una vez que aplicaramos
el primer nivel de F/N nos encontrariamos con la siguiente tabla:

Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos
solucionado el problema de la limitacin del campo url. Pero sin embargo
vemos
otros problemas....Cada vez que introducimos un nuevo registro en la tabla

Kenneth Elvir

200760530006

Ing. Castillo

20

usuarios, tenemos que duplicar el nombre de la empresa y del usuario. No slo

nuestra BD crecer muchsimo, sino que ser muy facil que la BD se corrompa
si escribimos mal alguno de los datos redundantes.
Aplicaremos pues el segundo nivel de F/N:

Segundo nivel de F/N

1. Crear tablas separadas para aquellos grupos de datos que se aplican a
varios
registros.
2. Relacionar estas tablas mediante una clave externa.
Hemos separado el campo url en otra tabla, de forma que podemos aadir ms
en el futuro si tener que duplicar los dems datos. Tambien vamos a usar
nuestra clave primaria para relacionar estos campos:

Vale, hemos creado tablas separadas y la clave primaria en la tabla usuarios,

userId, esta relacionada ahora con la clave externa en la tabla urls, relUserId.
Esto esta mejor. Pero que ocurre cuando queremos aadir otro empleado a la

Kenneth Elvir

200760530006

Ing. Castillo

21

empresa ABC ? o 200 empleados ? Ahora tenemos el nombre de la empresa

y su direccin duplicandose, otra situacin que puede inducirnos a introducir
errores en nuestros datos. As que tendrmos que aplicar el tercer nivel de F/N:

Tercer nivel de F/N.

1. Eliminar aquellos campos que no dependan de la clave.
Nuestro nombre de empresa y su direccin no tienen nada que ver con el
campo
userId, asi que tienen que tener su propio empresaId:

Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con

la clave externa recEmpresaId en la tabla usuarios, y podemos aadir 200
usuarios mientras que slo tenemos que insertar el nombre 'ABC' una vez.
Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin
duplicacin ni corrupcin de datos. La mayoria de los desarrolladores dicen que

Kenneth Elvir

200760530006

Ing. Castillo

22

el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede

manejar facilmente los datos obtenidos de una cualquier empresa en su
totalidad, y en la mayoria de los casos esto ser cierto.
Pero hechemos un vistazo a nuestro campo urls - Ves duplicacin de datos ?
Esto es perfectamente aceptable si la entrada de datos de este campo es
solicitada al usuario en nuestra apliacin para que teclee libremente su url, y
por
lo tanto es slo una coincidencia que Joe y Jill teclearon la misma url. Pero
que
pasa si en lugar de entrada libre de texto usramos un men desplegable con
20
o incluso ms urls predefinidas ? Entonces tendramos que llevar nuestro
diseo
de BD al siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por
alto porque depende mucho de un tipo muy especfico de relacin, la relacin
'varios-con-varios', la cual an no hemos encontrado en nuestra aplicacin.
Relaciones entre los Datos Antes de definir el cuarto nivel de F/N, veremos tres
tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varios-convarios. Mira la tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba.
Por un momento imaginmos que ponemos el campo url en una tabla
separada, y cada vez que introducimos un registro en la tabla usuarios tambien
introducimos una sola fila en la tabla urls. Entonces tendramos una relacion
uno-a-uno: cada fila en la tabla usuarios tendra exactamente una fila
correspondiente en la tabla urls. Para los propsitos de nuestra aplicacin no
sera til la normalizacin.

Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas
permiten a un slo usuario tener asociadas varias urls. Esta es una relacin
unocon-varios, el tipo de relacin ms comn, y hasta que se nos present el
dilema del Tercer Nivel de F/N. la nica clase de relacin que necesitamos.
La relacin varios-con-varios, sin embargo, es ligeramente ms compleja.
Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario
relacionado con varias urls. Como dijmos, vamos a cambiar la estructura para
permitir que varios usuarios esten relacionados con varias urls y as tendremos

Kenneth Elvir

200760530006

Ing. Castillo

23

una relacin varios-con-varios. Veamos como quedaran nuestras tablas antes

de seguir con este planteamiento:

Kenneth Elvir

200760530006

Ing. Castillo