Conceptos de bases de

datos y Transact-SQL

Ing. Danilo Rodríguez Guerrero

 Contenido
Tablas, registros y campos
Relaciones y cardinalidad
Integridad referencial
Formas normales
Lenguaje estructurado de consultas: SQL
 Cláusulas Select, From y Where
 Cláusulas de agrupamiento y ordenamiento
 Consultas multitablas: Join
Tablas
 Tablas
Una tabla es un recipiente de datos. La idea del modelo
relacional y la normalización es que los datos en una tabla
específica están asociados de alguna forma a los otros
elementos dentro de esta
Registros
 Registros
Los términos registro, fila o tupla son intercambiables, ellos hacen
referencia a un registro en una tabla. Lo único que hay que tener
presente es que una tabla puede tener múltiples registros. El
número de tuplas es variable y por lo general crece a medida que
transcurre el tiempo, la cantidad de campos de una tabla tiende a
mantenerse sin cambios una vez que el base de datos se vuelve
operacional.
Campos
 Campos
Los términos campo, columna o atributo significan lo mismo. Un
campo le imprime estructura y definición a un conjunto de datos
en cada fila o registro. Los datos de hecho no se repiten
necesariamente en cada registro, pero la estructura de campos
si. Los datos pueden ser diferentes en cada fila.
Identificación de relaciones
Relaciones entre entidades
Una interrelación enlaza a dos conjuntos de entidades u
objetos. Considere la relación Profesor IMPARTE
Asignatura, la interrelación IMPARTE consiste de un
conjunto de parejas de Profesor/Asignatura.

Profesor IMPARTE Asignatura

Relaciones entre entidades
Una vez que dos entidades han sido relacionadas. Al
conjunto que ambos conforman se le pueden detectar
nuevas propiedades o bien nuevas relaciones. Por
ejemplo en cual aula se imparte esa asignatura. O bien a
cual grupo de clase.

Profesor IMPARTE Asignatura

RECIBEN Grupo
Cardinalidad
 Cardinalidad
La cardinalidad de una relación se refiere al máximo de
instancias de un conjunto de entidades que está relacionado
con una única instancia en el otro conjunto de objetos.

Entre los tipos de cardinalidad tenemos a los siguientes:

Uno a Uno
Uno a Muchos
Muchos a Muchos

ESTÁ
Hombre Mujer
CASADO

¿Qué tipo de cardinalidad existe en esta relación?

 Uno a Uno
Uno a Uno: Una entidad relaciona únicamente con otra.

Docente ES UN Trabajador

Si un Docente es un trabajador, ¿Por qué no colocar

en la misma tabla ambas entidades?
 Uno a Muchos
Uno a Muchos: Una entidad se relaciona con más una
entidad de otro conjunto.

Carrera POSEE GrupoClase

1 *

En la figura inferior se muestra una vista del diagra de MS SQL Server de

ambas tablas.
 Muchos a Muchos
Muchos a muchos: Una o más entidades de un conjunto se
relacionan con una o más entidades de
otro.

Profesor IMPARTE Asignatura

* *

Tal como se observa se utilizó la figura de la

diapositiva anterior, pero está ejemplificando una
relación con una cardinalidad diferente. ¿De qué
dependería este cambio en la cardinalidad de la
relación?
 Muchos a Muchos

Debido a que el modelo relacional no permite las relaciones directas

en la cardinalidad de Muchos a Muchos. Se requiere dividir esta
relación en dos uniones de 1 a Muchos. En la figura se aprecia que
las Tablas TipoTrabajador y Trabajador son las que están enlazadas
en realidad, mientras que la tabla Rel_Trabajador_TipoTrabajador es
un mediador debido a la limitación del modelo relacional.
Restricciones de integridad
 Integridad referencial
Las funciones de integridad referencial, tal como lo dice su nombre,
se encargan que dada una relación entre dos tablas. Una posee la
llave primaria y la otra la llave foránea. Ambas llaves se verifican
una contra la otra.

Las primaria se encarga que no existan registros con valores

duplicados en los campos que la conforman. O sea, dos números
de cédula idénticos.

La llave foránea se encarga de garantizar que todos los valores que

contiene en la tabla hijo existan previamente en la tabla padre. Por
ejemplo, una tabla que muestra el detalle de una factura, no puede
hacer referencia a un número de factura que no existe en la tabla
Padre. Ya que sería ilógico tener un detalle de una compra que
nunca se facturó.
 Integridad referencial
Puntualizando lo ya mencionado

1-Cuando se agrega un nuevo registro a la tabla Hijo, el valor en el

campo de la llave foránea, deberá existir en el campo de la llave
primaria de la tabla Padre.

2-Las llaves foráneas podrían contener en algún momento valores

Nulos, pero las llaves primarias nunca, ya que esto no las haría ser
únicas.

3- Cuando se modifique un registro en una tabla Padre, si la llave

primaria es cambiada, el cambio se debe realizar en cascada a
todas las llaves foráneas de las tablas Hijo. De otra forma el cambio
debería ser prohibido.
Formas normales
Cero Forma normal
 Cero forma normal

Para un sistema extremadamente pequeño y estable esta tabla

podría funcionar exitosamente, sin embargo es observable que
los datos están mezclados y cualquier cambio para mejorar su
estructura implicaría destruir esta tabla.
Intentar obtener el número de uno de los edificios conlleva un
engorroso trabajo con cadenas. Y a pesar de ser una cosa tan
elemental en bases de datos, este servidor tuvo la desdicha de
ver ese mismo error en la base de datos de dos empresas
aseguradoras.
Primera forma normal
 Primera forma normal
 Asegúrese que no existen grupos de datos
repetidos.

 Asegúrese que existe una llave primaria.

 La información de los campos debe ser

atómica
 Primera forma normal

Los valores de los campos son atómicos y se posee un llave

primaria, sin embargo la redundancia es notoria.
Segunda forma normal
 Segunda forma normal
 No deberán existir dependencias parciales
hacia ninguno de los campos de la llave
primaria.

 Cuando la llave está compuesta por dos o

más campos, se puede dar el caso que un
subconjunto de los atributos de la tabla
dependa directamente de tan sólo uno de
los campos de la llave primaria.
 Segunda forma normal

Observe como ciertos campos dependen de el campo

TrabajadorID, mientras que no tienen relación con EdificioID.
 Segunda forma normal

La tabla anterior se ha descompuesto de tal forma que la llave

principal está formada por un solo campo, lo que implica que no
puede violar la 2da forma normal.
Tercera forma normal
 Tercera forma normal
 Una tabla está en tercera forma normal si
no tiene dependencias transitivas.

 Una dependencia transitiva aparece

cuando un atributo no clave es
funcionalmente dependiente de uno o
más no claves.
 Dependencia transitiva

Existe dependencia transitiva entre Tipo de oficio y el riesgo

Forma normal de
Boyce-Codd
Forma normal de Boyce-Codd
 Si se verifica que cada determinante sea
una clave entonces la tabla está en FNBC.
Cuarta forma normal
 Cuarta forma normal
 Una tabla debe estar en 3FN o FNBC con 3FN.
 Las dependencias multivaluadas deben ser
transformadas en dependencias funcionales.
Esto implica que un valor deberá depender de
la llave primaria, no múltiples.

 Eliminar los múltiples conjuntos de

dependencias multivaluadas, a veces
descritas como dependencias multivaluadas
no triviales.
 Cuarta forma normal

La configuración del atributo TipoDeOficio no es permitida por la

4FN, por lo que deberá ser transformada una dependencia
multivaluada trivial. Para lograrlo es necesario dividir esta tabla en
dos.
 Cuarta forma normal

El tener atributos multivaluados, o

bien listas de valores en un solo
campo es una violación a la 4FN,
por lo que la tabla se divide de la
siguiente forma.
¿Cree usted que la tabla que
relaciona al trabajador con sus
oficios es adecuada para evitar
errores de digitación o para
corregirlos fácilmente?
Quinta forma normal
 Quinta forma normal

 La tabla deberá de estar en 4FN

 Las dependencias cíclicas deberán ser
eliminadas.
 Quinta forma normal

La relación cíclica se hace visible debido a que un proyecto tiene

empleados, los empleados tienen un jefe, en este caso el director,
quien a su vez dirige un proyecto. A pesar que en apariencia todo
está repetido el número de veces indispensable, realmente no se
necesita repetir a Jimmy dos veces como director del proyecto
Análisis.
Quinta forma normal

Observe que los valores repetidos

como el caso del par
Proyecto/Director ha desaparecido
al dividir la tabla anterior. A simple
vista podría parecer trivial hacer la
división, sin embargo es
recomendable separar las
entidades que no tiene vínculos
directos.
 Recomendación
Los campos deberán tener valores
atómicos
Evite la repetición de información tanto
como pueda. Si un dato ya se encuentra un
tabla no existe entonces la necesidad de
repetirlo en otra.
Cree llaves primarias sencillas,
preferiblemente de dos o un campo.
Considere utilizar tablas maestro que
contendrán valores comunes, evitando así
que el usuario mal digite estos datos.
Lenguaje estructurado de
consultas
 Cláusula Select
La cláusula Select lista las columnas que se desean en el
resultado de la consulta.

En la figura superior se observa la sentencia SQL y su

resultado, en este caso se decidió especificar directamente
los campos a mostrar, en la siguiente diapositiva se hará uso
del comodín *
 Cláusula Select

En apariencia el resultado es el mismo. Sin embargo, si

agregamos otro campo a la tabla, con en esta sentencia sería
presentado . Mientras que con la anterior siempre se
mostrarían los mismo campos, sin importar que la tabla
tuviese nuevos atributos. ¿Cuales desventajas podría tener
uno u otro enfoque?
Cláusula From
 Cláusula From
La cláusula From lista una o más tablas que van a ser referidas
en la consulta. Todas las columnas relacionadas en la cláusula
Select o Where se deben encontrar en una de las tablas de esta
sentencia.
Cláusula Where
 Cláusula Where
La cláusula Where contiene una condición para seleccionar las
filas de las tablas que se dan en la sentencia From.
Where es una cláusula muy versátil y puede contener una gran
variedad de condiciones.
 Cláusula Where
En la figura de la
derecha se aprecia una
solicitud donde se filtran
a todos los trabajadores
cuyo primer apellido sea
Matinez.
 Cláusula Where

En la figura superior se ve como se pueden utilizar operadores

lógicos como AND y OR para crear condiciones un poco más
complejas.
Cláusula Group by
 Cláusula Group by
La gerencia está a menudo interesada en conocer información
estadística que se aplique a cada grupo de un conjunto de
grupos.

En la figura superior, se decidió agrupar a todos los trabajadores

por su primer apellido. Note que en el Select aparece la palabra
“count” que se utiliza para contar la cantidad de campos con
apellidos iguales. La palabra “as” es un modificador del nombre del
campo para adecuarlo a presentación de los datos.
 Cláusula Group by

En la figura superior se muestra una agrupación de los

trabajadores por su nombre completo. Además se continúa
utilizando la función count para determinar el número de
trabajadores que poseen los mismos nombres y apellidos.
¿Cuál sería el objetivo de hacer esto?
 Cláusula Group by

Observe esta consulta, no retorna ningún registro como

resultado. No quiere decir que esté mala, simplemente en
la tabla Trabajador no existen trabajadores que tengan los
mismos nombres y apellidos. La clausula Having es el
equivalente del Where, sólo que para las agrupaciones. O
sea que Having actúa una vez que ya se ha realizado la
agrupación.
Cláusula Inner Join
 Cláusula Inner Join
Combina registros de dos tablas siempre que haya valores
coincidentes en un campo común.

En la figura superior se muestra un Inner join entre la tabla

Trabajador y la tabla Docente a través de los valores
coincidentes en los campos TrabajadorId y objTrabajadorId
 Cláusula Inner Join

Imagine tener un diagrama de tablas como el mostrado por la

figura superior. Si usted hiciera una consulta para mostrar la
información de un docente y sus cargas horarias tendría que
recurrir a varios Inner Joins. A continuación mostraremos un
ejemplo.
 Cláusula Inner Join

Si se hiciera una consulta directa a la tabla AsignacionGMD

sólo códigos numéricos se verían. Tal como se aprecia en la
figura superior. Por lo que se tiene que traducir esos códigos
palabras que el usuario pueda comprender.
 Cláusula Inner Join

Un ejemplo algo complejo, pero es bastante común el

tener que escribir consultas de esta longitud. Ya que la
base de datos está completamente normalizada. De cierta
forma es como ir saltando entre las llaves foráneas para
recopilar la información a presentar.
Cláusula Left Join
 Cláusula Left Join
Las combinaciones externas por la izquierda incluyen todos
los registros desde la primera de dos tablas (izquierda),
incluso si no hay valores coincidentes para los registros en la
segunda tabla (derecha).

Por ejemplo, podría utilizar LEFT JOIN con las tablas

TipoTrabajador (izquierda) y Trabajador (derecha) para
seleccionar todos los Tipos de trabajador, incluyendo aquellos
que no tienen asignados ningún trabajador.
 Cláusula Left Join

En la figura superior se observa una consulta donde se

pide que se presenten los tipos de trabajador y sus
trabajadores asociados. Note como el tipo de trabajador
Administrativo no tiene más que NULL en los campos que
corresponden al trabajador. ¿Qué significa esto?
Cláusula Right Join
 Cláusula Right Join
Las combinaciones externas por la derecha incluyen todos los
registros desde la segunda de dos tablas (derecha), incluso si
no hay valores coincidentes para los registros en la primera
tabla (izquierda).

Para seleccionar todos los Trabajadores, incluyendo los que no

están asignados a ningún tipo de trabajador, podría utilizar
RIGHT JOIN.
 Cláusula Right Join

En lo particular, encontrar valores de NULL en los campos del

tipo de trabajador es incorrecto. El Rigth join permite entonces
detectar errores como este. O bien, detectar problemas de
otras índoles, tal como vendedores que no han hecho nunca
una venta, ya sea porque hace tiempo ya no laboran para la
empresa o bien porque fue un registro introducido
erróneamente.
 ¡Muchas gracias!

Ing. Danilo Rodríguez Guerrero

danilo.rodriguez@fec.uni.edu.ni