CREATE TABLE - SQL (Comando)

Visual Studio .NET 2003

Personas que lo han encontrado til: 3 de 10 - Valorar este tema
Crea una tabla que tiene los campos especificados.
CREATE TABLE | DBF TableName1 [NAME LongTableName] [FREE]
(FieldName1 FieldType [(nFieldWidth [, nPrecision])]
[NULL | NOT NULL] [CHECK lExpression1 [ERROR cMessageText1]]
[DEFAULT eExpression1] [PRIMARY KEY | UNIQUE]
[REFERENCES TableName2 [TAG TagName1]] [NOCPTRANS]
[, FieldName2 ...] [, PRIMARY KEY eExpression2 TAG TagName2
|, UNIQUE eExpression3 TAG TagName3]
[, FOREIGN KEY eExpression4 TAG TagName4 [NODUP] REFERENCES TableName3 [TAG
TagName5]]
[, CHECK lExpression2 [ERROR cMessageText2]])| FROM ARRAY ArrayName
Parmetros
TableName1
Especifica el nombre de la tabla que desea crear. Las opciones TABLE y DBF son
idnticas.
NAME LongTableName
Especifica un nombre largo para la tabla. Este nombre largo solamente se puede
especificar cuando hay una base de datos abierta, porque los nombres largos de tabla se
almacenan en bases de datos.
Los nombres largos pueden contener un mximo de 128 caracteres y se pueden utilizar en
lugar de nombres de archivo cortos en la base de datos.
FREE
Especifica que la tabla no se agregar a ninguna base de datos abierta. No es necesario
incluir FREE si no hay ninguna base de datos abierta.
(FieldName1 FieldType [(nFieldWidth [, nPrecision])]
Especifica el nombre, el tipo, el ancho y la precisin del campo (el nmero de lugares
decimales), respectivamente.
Una tabla puede contener hasta 255 campos. Si uno o ms de los campos permiten
valores nulos, el lmite se reduce en uno, a 254 campos.
FieldType es una sola letra que indica el tipo de datos del campo. Algunos tipos de datos
de campo necesitan que especifique nFieldWidth o nPrecision, o ambos.
La siguiente tabla enumera los valores para FieldType y si se necesita
indicar nFieldWidth y nPrecision.
nFieldWidth y nPrecision se pasan por alto para los tipos D, T, I, Y, L, M, G y
P. nPrecision tiene como valor predeterminado cero (ninguna posicin decimal) si no se
incluyenPrecision para los tipos N o F. nPrecision tiene, de forma predeterminada, el
nmero de posiciones decimales especificado por el valor SET DECIMAL si no est
incluidanPrecision para el tipo B.
NULL
Admite valores nulos en el campo. Si uno o ms campos pueden contener valores NULL,
el nmero mximo de campos que la tabla puede contener se reduce en una unidad, de
255 a 254.
NOT NULL
Impide escribir valores nulos en el campo.
Si omite NULL y NOT NULL, la configuracin actual de SET NULL determinar si se
admiten valores nulos en el campo. No obstante, si omite NULL y NOT NULL, e incluye la
clusula PRIMARY KEY o UNIQUE, se pasar por alto la configuracin actual de SET
NULL y el campo tomar el valor predeterminado NOT NULL.
CHECK lExpression1
Especifica una regla de validacin para el campo. lExpression1 puede ser una funcin
definida por el usuario. Observe que cuando se agrega un registro en blanco, se
comprueba la regla de validacin. Se generar un error si la regla de validacin no permite
un valor de campo en blanco en un registro anexado.
ERROR cMessageText1
Especifica el mensaje de error que Visual FoxPro mostrar cuando la regla de validacin
especificada con CHECK genere un error. El mensaje solamente se muestra cuando se
modifican los datos en una ventana Examinar o en una ventana Editar.
DEFAULT eExpression1
Especifica un valor predeterminado para el campo. El tipo de datos de eExpression1 debe
ser el mismo que el del campo.
PRIMARY KEY
Crea un ndice principal para el campo. La etiqueta de ndice principal tiene el mismo
nombre que el campo.
UNIQUE
Crea un ndice candidato para el campo. La etiqueta de ndice candidato tiene el mismo
nombre que el campo. Si desea obtener ms informacin acerca de los ndices candidatos,
vea Establecer un ndice principal o candidato.
Nota Los ndices candidatos (que se crean al incluir la opcin UNIQUE en CREATE
TABLE o ALTER TABLE - SQL) no son iguales que los ndices creados con la opcin
UNIQUE del comando INDEX. Un ndice creado con la opcin UNIQUE del comando
INDEX admite claves de ndice duplicadas, mientras que los ndices candidatos no las
admiten. Vea INDEX para obtener informacin adicional acerca de su opcin UNIQUE.
Los valores nulos y los registros duplicados no se permiten en un campo utilizado para un
ndice principal o candidato. No obstante, Visual FoxPro no generar ningn error si crea
un ndice principal o candidato para un campo que admita valores nulos. Visual FoxPro
generar un error si intenta introducir un valor nulo o duplicado en un campo utilizado para
un ndice principal o candidato.
REFERENCES TableName2 [TAG TagName1]
Especifica la tabla primaria con la cual se establece una relacin permanente. Si omite
TAG TagName1, la relacin se establecer mediante la clave de ndice principal de la tabla
primaria. Si la tabla primaria no tiene ningn ndice principal, Visual FoxPro generar un
error.
Incluya TAG TagName1 para establecer una relacin basada en una etiqueta de ndice
existente para la tabla primaria. Los nombres de etiqueta de ndice pueden contener hasta
10 caracteres.
La tabla primaria no puede ser una tabla libre.
NOCPTRANS
Impide la conversin a otra pgina de cdigos distinta para los campos de tipo carcter y
memo. Si la tabla se convierte a otra pgina de cdigos, los campos para los que se haya
especificado NOCPTRANS no se convertirn. NOCPTRANS solamente se puede
especificar para los campos de tipo carcter y memo. Esto crear lo que aparece en el
Diseador de tablas como tipos de datos Character (binario) y Memo (binario).
El ejemplo siguiente crea una tabla denominada MYTABLE con dos campos de caracteres
y dos campos memo. El segundo campo de caracteres, CHAR2, y el segundo campo
memo, MEMO2, incluyen NOCPTRANS para impedir la conversin.
CREATE TABLE mytable (char1 C(10), char2 C(10) NOCPTRANS,;
memo1 M, memo2 M NOCPTRANS)
PRIMARY KEY eExpression2 TAG TagName2
Especifica un ndice principal que se desea crear. eExpression2 especifica cualquier
campo o combinacin de campos de la tabla. TAG TagName2 especifica el nombre de la
etiqueta de ndice principal que se desea crear. Los nombres de etiqueta de ndice pueden
contener hasta 10 caracteres.
Puesto que una tabla solamente puede tener un ndice principal, no es posible incluir esta
clusula si ya ha creado un ndice principal para un campo. Visual FoxPro generar un
error si incluye dos o ms clusulas PRIMARY KEY en CREATE TABLE.
UNIQUE eExpression3 TAG TagName3
Crea un ndice candidato. eExpression3 especifica cualquier campo o combinacin de
campos de la tabla. No obstante, si ha creado un ndice principal con una de las opciones
de PRIMARY KEY, no podr incluir el campo especificado para el ndice principal.
TAG TagName3 especifica un nombre de etiqueta para la etiqueta de ndice candidato que
se desea crear. Los nombres de etiqueta de ndice pueden contener hasta 10 caracteres.
Una tabla puede tener mltiples ndices candidatos.
FOREIGN KEY eExpression4 TAG TagName4 [NODUP]
Crea un ndice externo (no principal) y establece una relacin con una tabla
primaria. eExpression4 especifica la expresin de clave de ndice externo
y TagName4 especifica el nombre de la etiqueta de clave de ndice externo que se desea
crear. Los nombres de etiqueta de ndice pueden contener hasta 10 caracteres. Incluya
NODUP para crear un ndice externo candidato.
Puede crear mltiples ndices externos para la tabla, pero sus expresiones deben
especificar campos distintos de la tabla.
REFERENCES TagName3 [TAG TagName5]
Especifica la tabla primaria con la cual se establece una relacin permanente. Incluya
TAG TagName5 para establecer una relacin basada en una etiqueta de ndice para la
tabla primaria. Los nombres de etiqueta de ndice pueden contener hasta 10 caracteres. Si
omite TAG TagName5, la relacin se establecer, de forma predeterminada, mediante la
clave de ndice principal de la tabla primaria.
CHECK eExpression2 [ERROR cMessageText2]
Especifica la regla de validacin de tabla. ERROR cMessageText2 especifica el mensaje
de error que Visual FoxPro mostrar cuando se ejecute la regla de validacin de tabla. El
mensaje solamente se muestra cuando se modifican los datos en una ventana Examinar o
en una ventana Editar.
FROM ARRAY ArrayName
Especifica el nombre de una matriz existente cuyo contenido es el nombre, el tipo, la precisin y la
escala para cada campo de la tabla. El contenido de la matriz se puede definir con la funcin
AFIELDS( ).
Observaciones
La nueva tabla se abre en la menor rea de trabajo disponible y se puede tener acceso a ella por
su alias. La nueva tabla se abre de forma exclusiva, cualquiera que sea la configuracin actual de
SET EXCLUSIVE.
Si hay una base de datos abierta y no incluye la clusula FREE, la nueva tabla se agregar a la
base de datos. No puede crear una tabla nueva con el mismo nombre que otra ya existente en la
base de datos.
Si no hay ninguna base de datos abierta al crear la nueva tabla, se generar un error si se incluyen
las clusulas NAME, CHECK, DEFAULT, FOREIGN KEY, PRIMARY KEY o REFERENCES.
Observe que la sintaxis de CREATE TABLE utiliza comas para separar determinadas opciones de
CREATE TABLE. Adems, las clusulas NULL, NOT NULL, CHECK, DEFAULT, PRIMARY KEY y
UNIQUE deben estar incluidas entre los parntesis que contienen las definiciones de columnas.
Ejemplo
El ejemplo siguiente crea una nueva base de datos llamada Mydata1. CREATE TABLE se usa para
crear tres tablas llamadas Salesman, Customer y Orders. Las clusulas FOREIGN KEY y
REFERENCES del segundo comando CREATE TABLE crean una relacin persistente uno a varios
entre las tablas Salesman y Customer. Las clusulas DEFAULT del tercer comando CREATE
TABLE establecen valores predeterminados, y las clusulas CHECK y ERROR establecen reglas
de empresa para escribir datos en campos especficos. MODIFY DATABASE se usa para mostrar
la relacin entre las tres tablas.
CLOSE DATABASES
CLEAR

* Create mydata database in the current directory or folder
CREATE DATABASE mydata1

* Create a salesman table with a primary key
CREATE TABLE salesman ;
(SalesID c(6) PRIMARY KEY, ;
SaleName C(20))

* Create a customer table and relate it to the salesman table.
CREATE TABLE customer ;
(SalesID c(6), ;
CustId i PRIMARY KEY, ;
CustName c(20) UNIQUE, ;
SalesBranch c(3), ;
FOREIGN KEY SalesId TAG SalesId REFERENCES salesman)

* Create an orders table related to customer with its own primary
* key and some business rules such as defaults & checks.
CREATE TABLE orders ;
(OrderId i PRIMARY KEY, ;
CustId i REFERENCES customer TAG CustId, ;
OrderAmt y(4), ;
OrderQty i ;
DEFAULT 10 ;
CHECK (OrderQty > 9) ;
ERROR "Order Quantity must be at least 10", ;
DiscPercent n(6,2) NULL ;
DEFAULT .NULL., ;
CHECK (OrderAmt > 0) ERROR "Order Amount Must be > 0" )

* Display new database, tables, and relationships
MODIFY DATABASE

* Delete example files
SET SAFETY OFF && To suppress verification message
CLOSE DATABASES && Close database before deleting
DELETE DATABASE mydata1 DELETETABLES
Diferencias Entre Clustered Y Non Clustered Index En SQL Server
Una pregunta muy comn para los iniciados en el mundo de SQL Server, es cul es la diferencia
entre un ndice clustered y un ndice non-clustered y en qu caso conviene usar un ndice u otro.
Bueno, empecemos a describir las caractersticas generales de un ndice y luego de estos tipos de
ndices y las conclusiones van a ser evidentes.
Los ndices son objetos de la bases de datos, cuya funcin es optimizar el acceso a datos. A
medida que las tablas se van haciendo ms grandes y se desea hacer consultar sobre estas
tablas, los ndices son indispensables.
Internamente un ndice normal es una estructura de rbol, que cuenta con una pgina principal y
luego esta con paginas hijas, que a su vez tiene ms paginas hijas hasta llegar a la pagina final del
ndice (leaf level).
La clave del ndice est repartida en las pginas del ndice, de modo tal que la bsqueda se haga
leyendo la menor cantidad posible de datos.
Estructura interna de un ndice:

Despus de esta brevsima introduccin, donde est la diferencia entre un ndice clustered y uno
non-clustered? En la leaf level (la ultima pagina) del ndice. En un ndice non-clustered, la clave
por la que buscamos tiene un puntero a la pgina de datos donde se encuentra el registro.
Mientras que en ndice clustered, la leaf level es la pagina de datos!. Con lo cual, el SQL
Server, se ahorra hacer un salto para leer los datos del registro (Bookmark lookup). La
diferencia es importante, ya que el uso de este tipo de ndices al evitar tener que hacer lecturas
adicionales para traer el registro, son ms performantes.
Bsqueda por clustered index:


Bsqueda por non-clustered index:


SQL Server 2005 incorpora una nueva feature interesante en los ndices non-
clustered. Ahora es posible incluir dentro de la leaf page del ndice, campos que en
s, no son parte de la clave. Esto nos permitir en algunos casos, evitar el salto a la
pgina de datos (Bookmark Lookup) que habamos hablado anteriormente. Aunque
hay que tener cuidado de seleccionar bien que campos se desean incluir al ndice,
porque de poner demasiados se expandera mucho el ndice, haciendo ineficiente.
Por ejemplo, si tenemos una tabla Personas cuyo campo DNI es un ndice non-
clustered y queremos hacer una consulta que solo traiga el Apellido y DNI,
entonces si incluimos el campo Apellido , nos ahorraramos tener que ir a la pgina
de datos para buscar el valor. Es importante recalcar que el campo Apellido no
sera parte de la tabla, sino un campo mas en pagina final del ndice.
Ahora bien, entonces porque no siempre usar ndices clustered? Bueno, en primer lugar,
lamentablemente solo puede haber 1 solo ndice clustered por tabla. La razn es muy sencilla y
lgica: Los registros de la tabla fsicamente son las paginas leaf-level del ndice clustered. Los
datos de la tabla esta ordenados segn el ndice. Y obviamente una tabla no puede
simultneamente estar fsicamente ordenada de 2 maneras diferentes.
Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y analizar a que
campos vamos a seleccionar para ser llaves del ndice clustered. Tenemos 1 solo ndice de este
tipo por tabla, no hay que desperdiciarlo!!!
Este ltimo punto es importante para saber en qu situaciones y para que campos se debe utilizar
un clustered index o un non-clustered.
Gua general de uso de ndices:
Campos autoincrementales (Identitys, newsequentialid, etc), deben convenientemente ser
del tipo clustered index. La razn es reducir el page split (fragmentacin) de la tabla.
Los clustered index son convenientes si se va seleccionar un rango de valores, ordenar
(ORDER BY) o agrupar (GROUP BY).
La PK es un buen candidato para un clustered index. Pero no siempre. Por ejemplo, si
tenemos una tabla de ventas, cuya PK es un identity en donde se efectan muchas
consultar por rangos de fecha, el campo Fecha seria un mejor candidato para el clustered
que la PK.
Para bsquedas de valores especficos, conviene utilizar un non-clustered index.
Para ndices compuestos, mejor utilizar non-clustered index (generalmente).
as Relaciones es lo que, aparte de dar el nombre a las BD relacionales, hacen de este modelo una
potente herramienta de reunin de datos. Para abordar las relaciones debemos tratar primero el
concepto de clave primaria y clave fornea, puesto que son estas claves las que establecen las
relaciones en una BD, y realizan la reunin de datos mediante consultas SQL.

Clave primaria
Si usted recuerda como su profesor de enseanza bsica pasaba lista a la clase, recordar que
nombraba a los alumnos bien por su apellido, bien por su nombre, dependiendo del caso, e incluso
por nombre y apellido si era necesario evitar ambigedades. El propsito era dejar claro a quien se
estaba haciendo mencin y no dar lugar a dudas entre dos alumnos de igual nombre o apellido.
Podramos decir que el profesor asignaba una clave primaria a cada alumno, y con ello todo el
mundo saba que clave identificar como propia y responder: presente, al orla.

Podemos considerar que una tabla es como una clase, y el conjunto de registros que contiene son
los alumnos de esta clase. Para identificar cada registro es necesario establecer, de igual modo
que hace el profesor, una clave primaria, con el propsito de identificar cada registro de forma
nica, por lo que el valor, o valores que ejercen de clave en un registro no se pueden repetir en el
resto de registros de la tabla, ni en futuros registros que puedan existir. De esto ya se encarga el
SGBD al especificarle que campos de la tabla forman la clave primaria, devolviendo un error
cuando se intenta duplicar una clave primaria al insertar un nuevo registro en la tabla.

Un error comn, a mi entender, al establecer la clave primaria de una tabla es intentar aprovechar
algn campo de datos para que ejerza de clave, por ejemplo el DNI(documento nacional de
identidad) de una persona. Aparentemente es un campo que no se puede repetir y, por tanto, es un
buen candidato para ejercer de clave primaria en, por ejemplo , una tabla de empleados o de
alumnos. Sin embargo no tenemos control sobre l, es decir, no podemos garantizar que no se
repita. En ocasiones se asigna un DNI que perteneci a una persona ya fallecida, a un nuevo
ciudadano de modo que aunque sea una posibilidad remota, puede dar problemas. Eso sin
considerar que en ocasiones pueda resultar una clave poco prctica de manejar.

Otro error comn es pretender que el campo clave guarde informacin implcita en la propia clave.
Por ejemplo, a un vehculo de nuestra flota le asignamos la clave 1100456, donde el 11 est
indicando que es marca SEAT y el 00456 es el resto de la clave.

Mi consejo es que no se empee, ni en aprovechar datos para que ejerzan de clave, ni en
aprovechar claves para que implcitamente contengan informacin relevante. Las claves son claves
y deben disearse nicamente para identificar registros. Los nmeros naturales (1, 2 , 3 , etc...) son
excelentes candidatos para ejercer de clave, se pueden ordenar (el SGBD crear ndices sobre los
campos clave que agilizarn las consultas) y son infinitos (siempre dispondremos de un valor para
no repetir claves).

Clave fornea
La clave o claves forneas de una tabla son referencias a registros de otra tabla, formndose entre
ambas tablas una relacin. Una registro de la tabla que tiene la clave fornea, llamemoslo registro
hijo, apunta a un solo registro de la tabla a la que hace referencia, llamemoslo registro padre. Por
tanto, una clave fornea apuntar siempre a la clave primaria de otra tabla.
De hecho el nombre ya nos indica que es una clave externa, es decir, el valor que contiene un
registro en el campo, o campos, que ejercen de clave fornea, deber contenerlo algn
registro(uno solo) en el campo, o campos, que ejercen de clave primaria en la tabla a la que hace
referencia dicha clave fornea.

Es tambin el SGBD quien garantiza esto, no dejando armar una clave fornea si pretendemos
montarla sobre el campo, o campos, que no son clave primaria en la tabla con la que se pretende
relacionar.
Tampoco permitir, devolviendo un error, insertar valores que no existen como clave primaria en la
tabla padre, o tabla a la que se hace referencia. A esto se le llama integridad referencial. El SGBD
no permite incoherencias referenciales, de modo que si por ejemplo se intenta eliminar un registro
padre el cual dejara hijos hurfanos en otras tablas, es decir, tiene referencias o claves forneas
de l, el SGBD devuelve un error y no se realiza la operacin.

Relaciones
El modo de relacionar registros entre tablas es por tanto mediante referencias, para lo cual se usan
los identificadores definidos como claves primarias y forneas.

Supongamos una academia donde se imparten clases, en consecuencia habr cursos, profesores
y alumnos. En nuestra base de datos diseamos una tabla para cada entidad, es decir, para
alumnos, profesores y cursos. Veamos como se relacionan entre si estas tres entidades y como se
establecen estas relaciones en la base de datos.

Intuitivamente usted puede resolver la siguiente relacin: La academia oferta cursos que imparten
los profesores a los alumnos matriculados, y est en lo cierto, pero para relacionar esto en una BD
debemos conocer en que medida se relacionan entre si estas tres entidades, es lo que se llama
cardinalidad de una relacin. Veamos primero el diseo de las tablas, los datos que contienen, y
que campo, o campos, juegan el papel de identificador o clave primaria.
Los campos clave se han bautizado con el prefijo ID, abreviacin de identificador.

TABLA CURSOS


TABLA PROFESORES


TABLA ALUMNOS


A estas tablas se las llama "maestros", dado que contienen informacin relevante y concreta de
cada entidad, as hablaremos del maestro de profesores o del maestro de alumnos. Bien, para
establecer las relaciones entre estas tres tablas necesitamos conocer con algo ms de detalle la
actividad en la academia, de modo que despus de investigar un poco sacamos las siguientes
conclusiones:


Cada curso lo imparte un nico profesor, sin embargo algn profesor imparte ms de un
curso.
Cada curso tiene varios alumnos, y algunos alumnos cursan dos o ms cursos.

Relacin de cardinalidad 1 a N

Establezcamos la siguiente relacin:

Cada curso lo imparte un nico profesor, sin embargo algn profesor imparte ms de un curso.

Para ello basta con crear un campo en la tabla CURSOS que informe que profesor lo imparte. Este
dato es una clave primaria de la tabla PROFESORES alojada en la tabla CURSOS, de ah lo de
clave fornea, por tanto el campo que ejercer de clave fornea en la tabla CURSOS debe ser
forzosamente una referencia a la clave primaria de la tabla PROFESORES.
Este tipo de relacin se denomina de uno a varios, tambin denominada de 1 a N: un profesor
imparte varios cursos, pero un curso es impartido por un nico profesor. En estos casos siempre se
disea una clave fornea en la tabla hijo(CURSOS) que apunta a la tabla padre(PROFESORES).

Debemos disear entonces una clave fornea en la tabla CURSOS para alojar valores que son
clave primaria de la tabla PROFESORES. En este caso disearemos un campo que llamaremos
ID_PROFE, aunque se podra llamar de cualquier otro modo, que contendr el identificador de
profesor que imparte el curso que representa cada registro. Veamos como queda la tabla
CURSOS:



Observando los datos de la tabla se aprecia como efectivamente cada curso lo imparte un nico
profesor, y que algn profesor imparte ms de un curso. Tambin se observa como uno de los
curso no se le ha asignado profesor, dado que el campo ID_PROFE esta a nulo. Por lo tanto una
clave fornea apuntar a un solo registro de la tabla padre o no apuntar a ninguno, en cuyo caso
guardar un valor indeterminado o nulo, pero jams contendr un valor que no exista en la tabla
padre.

A usted se le puede ocurrir que es mucho ms prctico y simple guardar para cada curso el
nombre del profesor en lugar de claves que apenas nos dicen nada a simple vista. Esto sera
transgredir la filosofa de las BD relacionales, que defienden la no duplicidad de informacin. El
nombre de un profesor debe estar en el maestro de profesores, y cualquier referencia a ellos debe
hacerse mediante su identificador. Con ello conseguimos tres cosas destacables:


No se duplica informacin en la BD.
Cualquier cambio o correccin de esa informacin solo debe realizarse en un nico lugar.
Evitamos la ambigedad al no llamar la misma cosas de mil formas distintas en mil
ubicaciones posibles.

Veamos la consulta que reune el nombre de cada profesor junto al curso que imparte.


CDIGO: SELECCIONAR TODO
select *
from CURSOS C, PROFESORES P
where C.ID_PROFE = P.ID_PROFE
llevar cdigo al banco de pruebas




Observe como si omitimos la clusula WHERE de la anterior consulta, el SGBD realizara el
producto cartesiano entre los cursos y los profesores, es decir, asociara todos los profesores con
todos los cursos. El hecho de disponer de un indicador por cada curso que informa que profesor lo
imparte, permite filtrar el producto cartesiano y solicitar aquellas filas que la columna ID_PROFE
procedente de la tabla cursos es igual a la columna ID_PROFE procedente de la tabla
PROFESORES, discriminando as las filas del producto cartesiano que carecen de sentido y
obteniendo aquellas que guardan una relacin.


Una lista de esto mismo mejor presentada:

CDIGO: SELECCIONAR TODO
select concat('Curso de ',C.TITULO,', impartido por ',P.NOMBRE,' ',P.APELLIDOS) CURS
OS
from CURSOS C, PROFESORES P
where C.ID_PROFE = P.ID_PROFE
llevar cdigo al banco de pruebas



Las relaciones de 1 a N son quizs las ms comunes en una BD y pueden verse como un padre,
tabla referenciada, con muchos hijos, tabla que hace referencia a este padre. En el caso que se
acaba de tratar el padre es el profesor y los hijos son los cursos que imparte dicho profesor. Todo
hijo tiene forzosamente un padre, a no ser que la clave fornea pueda contener valores nulos,
mientras que un padre puede tener de cero a muchos hijos.


Relacin de cardinalidad N a M
Establezcamos la siguiente relacin:

Cada curso tiene varios alumnos, y algunos alumnos cursan dos o ms cursos.

Esta relacin es un poco ms laboriosa de establecer en la base de datos, puesto que un alumno
cursa varios cursos, y a su vez, un curso es cursado por varios alumnos. Este tipo de relacin se
denomina de varios a varios, o bien, de N a M. Necesitamos crear una nueva tabla denominada
tabla de relacin, y que tiene como propsito definir la relacin de N a M. La nueva tabla:
ALUMNOS_CURSOS, contendr como mnimo las claves primarias de ambas tablas: ID_ALUMNO
e ID_CURSO. La clave primaria de la nueva tabla la formaran ambos campos conjuntamente, y a
su vez cada uno de ellos por separado ser clave fornea de la tabla ALUMNOS y CURSOS
respectivamente.

Echemos un vistazo a la tabla ALUMNOS_CURSOS:


Fijese que esta tabla contiene nicamente referencias. Cada registro establece una relacin, est
relacionando un registro de la tabla CURSOS con un registro de la tabla ALUMNOS.

Veamos la consulta que realiza la reunin de los alumnos con los cursos que cursa cada uno:

CDIGO: SELECCIONAR TODO
select *
from ALUMNOS_CURSOS AC, ALUMNOS A, CURSOS C
where AC.ID_ALUMNO = A.ID_ALUMNO
and AC.ID_CURSO = C.ID_CURSO
llevar cdigo al banco de pruebas



Una lista de esto mismo mejor presentada:

CDIGO: SELECCIONAR TODO
select C.TITULO CURSO , concat(A.APELLIDOS,', ',A.NOMBRE ) ALUMNO
from ALUMNOS_CURSOS AC, ALUMNOS A, CURSOS C
where AC.ID_ALUMNO = A.ID_ALUMNO
and AC.ID_CURSO = C.ID_CURSO
order by C.TITULO , A.NOMBRE , A.APELLIDOS
llevar cdigo al banco de pruebas




En este caso tambin podemos hacer el ejercicio de considerar el producto cartesiano entre estas
tres tablas y como la clusula WHERE permite ignorar aquellos registros del producto cartesiano
que carecen de sentido y filtrar aquellos que guardan una relacin.


La tabla de relacin puede contener ms informacin si es necesario, siempre y cuando la
informacin sea vinculante tanto para el curso como para el alumno del registro en cuestin. No se
tercia guardar aqu datos referentes al alumno que no tengan que ver con el curso, o datos del
curso que no tengan que ver con el alumno. Por tanto registrar aqu cosas como la fecha de
matrcula de un alumno en un curso, o la nota que el alumno ha sacado en un curso, tiene sentido,
mientras que no lo tiene guardar aqu la fecha en que empieza un curso que nada tiene que ver
con un alumno, o la veterana del alumno en la academia que nada tiene que ver con un curso.


Relacin de cardinalidad 1 a 1
No vamos a extendernos en esta tipo de relacin puesto que no suelen darse mucho. En cualquier
caso estas relaciones pueden verse como una relacin 1 a N donde la N vale uno, es decir como
una relacin padre hijos donde el hijo es hijo nico. En estos casos, cuando slo se espera un hijo
por registro padre, podemos montar la clave fornea en cualquiera de las dos tablas, aunque lo
ms correcto es establecerla en la tabla que NO es maestro. A efectos prcticos lo mismo da que
el padre a punte al hijo que, a la inversa, es decir, que el hijo apunte al padre, o si usted quiere,
cual de las dos tablas juega el papel de padre y cual de hijo. Lo importante es saber como se ha
establecido la relacin para atacarla mediante SQL al construir las consultas, pero siempre es
preferible que la tabla maestro juegue el papel de padre.


Resumen
La clave primaria de una tabla permiten identificar registros de forma nica, estas pueden ser
simples: de un solo campo, o bien compuestas: formadas por dos o ms campos. En cualquier
caso los valores que toman estas claves no se pueden repetir en dos o ms registros de la tabla,
puesto que se perdera la funcionalidad de identificar un registro de forma nica. De esto se
encarga el SGBD si se ha especificado debidamente que campos son la clave primaria de la tabla.

Las claves forneas de una tabla permiten establecer relaciones con otras tablas, puesto que
contienen valores que encontramos como clave primaria en la tabla con la que se relaciona. Una
clave fornea ser simple o compuesta dependiendo de si lo es la clave primaria de la tabla a la
que apunta o hace referencia.

Si al disear una tabla el campo o campos que forman una clave fornea pueden contener valores
nulos, entonces el registro hijo puede no tener registro padre asociado. Esto es muy comn que
ocurra cuando un registro se ha creando en previsin y ser en un futuro, despus de que ocurra
alguna cosa, que se le asignar un padre. Por ejemplo el curso sin profesor definido de la tabla
CURSOS. El curso est previsto que se imparta, pero no se ha decidido o no se conoce aun que
profesor lo impartir, de ah que el campo ID_PROFE de dicho registro contenga un valor nulo.

Las relaciones de 1 a N son quizs las que ms se dan en una BD, en estos casos siempre
encontraremos la clave fornea en el registro hijo apuntando al registro padre.

Las relaciones de N a M, entre por ejemplo dos tablas maestras, siempre necesitar una estructura
auxiliar para establecer la relacin. Esta tabla auxiliar se denomina tabla de relacin, y contendr
como mnimo los campos que son clave primaria en ambos maestros. La clave primaria de la
nueva tabla ser siempre compuesta y estar formada por todos estos campos que son clave
primaria en los maestros. A su vez estos campos por separado sern clave fornea de sus
respectivos maestros. Por tanto los registros hijos se hallarn en la tabla de relacin.

El modo de obtener la reunin de tablas relacionadas es mediante filtros sobre el producto
cartesiano de dichas tablas, excluyendo con ayuda de la clusula WHERE aquellos registros del
producto cartesiano que carecen de sentido y obteniendo los que guardan una relacin. Para ello
debemos igualar la clave primaria de la tabla padre con la clave fornea de la tabla hijo.

Ejercicio 1
Construya una consulta que devuelva los cursos en que se ha matriculado el alumno con
identificador 1.

Modifique la anterior consulta para que devuelva los nombres y apellidos de los alumnos, y los
cursos en que se han matriculado, tales que el nombre de pila del alumno contenga un E.

Ejercicio 2
Cuantos cursos imparte cada profesor? Construya una consulta que responda a esta cuestin de
modo que el resultado muestre el nombre completo del profesor acompaado del nmero de
cursos que imparte.

Ejercicio 3
Cuantos alumnos hay matriculados en cada uno de los cursos? Construya una consulta que
responda a esta cuestin de modo que el resultado muestre el titulo del curso acompaado de el
nmero de alumnos matriculados.

Modifique la anterior consulta de modo que muestre aquellos cursos que el nmero de alumnos
matriculados sea exactamente de dos alumnos.

Ejercicio 4
Si ahora a usted le pidiesen que adaptara la BD, que consta de las tres tablas presentadas en esta
leccin, a la siguiente necesidad: A todo alumno se le asignara un profesor que lo tutele. Que
cambios realizara en la BD?
En MySQL existe un operador -is null- o is not null- que te puede dar todos los registros que son
null o los que no lo son. Se utiliza de esta manera:

select * from cliente where telefono is not null.