Está en la página 1de 68

¿Qué es una arquitectura Cliente-Servidor?

Printer
Databas
Server
e Server

Mail
Server

Servidor Cliente
o
Server
¿Qué es un motor de base de datos?

Modific Borr
ar ar ar
Actualiz

Cre DBM
DB
ar S
MS
Mapeo externo
conceptual

DDL
DML

Mapeo conceptual
interno
Base de
Dato Datos Datos

Nivel de
aplicación/diseño
Clase de
Clase de Entidades
Atributo Objeto y sus
Objetos
Asociacione
s
Clase de
Entidade Esquema de
Entidad
la base de
s datos

Nivel
diseño/construcción
Archivo
Campo Registro Archivo s

Nivel interno
Vist
a
                   
                   
  Cliente           Fecha: mm/dd/yyyy  
                   
                   
                   
                   
                   
                   
                   
  ID DESCRIPCION PU CANTIDAD TOTAL  
             
             
             
             
             
  CANTIDAD EN LETRA   SUBTOTA    
L
    IVA    
    TOTAL    
       
                   
¿Cuál es el problema?

¿Cuáles son las alternativas de


solución?

¿Cuál es la mejor solución?


Sistema automatizado Sistema en papel Idea
1 Identificar las necesidades básicas de la base de datos

Definir las pretensiones funcionales y de ejecución de la


2 base de datos.

3 Identificar los datos elementales.

Separar los datos elementales y agruparlos en clases de


4 entidades.

5 Construir el diccionario de datos.

6 Identificar la relación entre las clases de entidades.

7 Desarrollar el esquema de la base de datos.

Identificar las características de recuperación de la


8 información.
Repetir los pasos anteriores con la finalidad de revisar y
9 refinar el diseño.
1 Identificar las necesidades básicas de la base de datos

Una de las áreas de un instituto de investigación, desea mantener


un control automatizado sobre los libros que ahí se encuentran.

Se requiere de un control automatizado de las fuentes de


información (se utilizó el término fuentes de información o
simplemente fuentes, para agrupar los libros,
revistas, artículos, videos o tesis existentes en la biblioteca del
instituto) que auxilie para saber:
• Qué libros, revistas, artículos, videos o tesis se tienen.
• Qué fuentes están prestadas.
• Quién tiene las fuentes.
• Qué fuentes han sido recomendadas y no han comprado.
• Qué fuentes hay sobre un tema.
• Qué fuentes hay de un autor.
1 Identificar las necesidades básicas de la base de datos

Todo el mundo (investigadores y administrativos) desea tener


acceso al programa
Recursos (equipo con que se cuenta)
• 15 computadoras personales de modelos recientes.
• Una LAN Basada en Servidor, con sistema operativo ®MS Windows
2003 y suficiente espacio en disco.
• Dos impresoras, laser .
• Ninguna licencia para algún motor de base de datos.
• Un archivo en Excell con nombres y direcciones del personal del
instituto.

Limitaciones
• No existe un procedimiento estándar para la creación de fichas
bibliográficas (en
la institución se usan tres métodos diferentes).
• No se cuenta con una lista actualizada de los libros existentes.
• En algunos casos se realizan préstamos a personal externo al
instituto.
Definir las pretensiones funcionales y de ejecución de la
2 base de datos.
Funcionales
De seguridad de la información:
• El sistema deberá contar con un proceso de identificación
mediante usuario y password.
• Cualquier usuario puede:
• Registrar fuentes para recomendar su compra.
•Consultar qué fuentes hay sobre un tema
•Consultar qué fuentes hay de un autor.
•Consultar qué fuentes hay de una editorial
• Solo los usuarios administradores pueden realizar:
•El préstamo o asignación de las fuentes (por diferentes
cuestiones, se denominó asignación al préstamo al personal
interno del instituto, y
•préstamo para el personal externo a la institución).
•Obtener reporte de las fuentes que han sido recomendadas
para su compra y la prioridad de adquisición de los mismos.
•Obtener reporte de las fuentes que han sido recomendadas
para su compra por prioridad, nombre, autor y editorial.
Todos las consultas y reportes deberán tener la opción de
presentarse en pantalla o por impresora.
Definir las pretensiones funcionales y de ejecución de la
2 base de datos.
Funcionales
El sistema reportará:
• A quien lo solicite, la lista de fuentes existentes en el área,
bajo cualquiera de los tres formatos utilizados, según lo requiera
el usuario.

Desempeño
• El sistema deberá soportar un número indeterminado de
fuentes.
• El sistema deberá soportar un número indeterminado de
préstamos.
• Aun y cuando no es de vital importancia el tiempo de
respuesta, se requiere que lo haga en un tiempo razonable,
máximo 1 minutos por pantalla y de 5 minutos por impresora.
3 Identificar los datos elementales.

ISBN del libro, Nombre del libro, nombre(s) del (de los) autor(es),
nombre de la revista, número de la revista, nombre del artículo,
nombre del video, director del video, nombre del usuario, edición,
editorial, año de edición, costo, fecha de compra, tema, proyecto,
prioridad (urgente, normal, baja u opcional), estado (comprado,
recomendado para compra, prestado o asignado), dirección del
usuario, teléfono del usuario, fecha de préstamo, días de préstamo,
nombre de la tesis, fecha de realización, carrera para la cual se
realizó, Año de edición, Edición, Volumen, Formato, Tiempo
duración, Director, Tema
Separar los datos elementales y agruparlos en clases de
4 entidades.

• Libro: ISBN, Nombre, edición, año de edición, editorial, estado,


prioridad, costo.
• Revista: Nombre, editorial, año de edición, volumen, número.
• Video: Nombre, tiempo de duración, formato, nombre del director.
• Artículo: Nombre, revista, número de páginas.
• Tesis: Nombre, fecha, carrera.
• Autor: Nombre.
• Préstamos: Nombre de la fuente, nombre del usuario, fecha de
préstamo, días de
préstamo.
• Usuarios: Nombre, apellido paterno, apellido materno, dirección,
teléfono.
• Temas: Nombre
• Acceso: Usuario, clave, Nivel
5 Construir el diccionario de datos.

                      
 
 
Diccionario de datos  
 
                      
  Entidad Atributo Tipo Tamaño Obligatorio Rango Valor por Notas  
Omisión
  máximo mínimo  
  Libros ISBN String 20 SI       Lllave primaria  
  Nombre String 80 SI            
  Edicion String 3 SI     1a     
  Año String 4 NO Actual 1900       
  Costo Numérico 5.2 NO            
  Editorial String 30 SI            
  Estado Caracter 1 SI      R comprado,  
recomendado para
compra, prestado o
asignado 
  Prioridad Caracter 1 SI      N urgente, normal, baja  
u opcional 
                    
6 Identificar la relación entre las clases de entidades.
!ADVERTENCIA!
Es necesario hacer hincapié en esta característica, ya que los humanos
generalmente pensamos en las asociaciones en un solo sentido.

Usualmente, los padres acostumbran responder a los cuestionamientos de los


hijos con la expresión: “¡Porque soy tu padre (o madre)!” Sin embargo, la
asociación existe de ambos lados y la contraparte sería: “Y yo tu hijo, además,
nos graduamos el mismo día.”

Solemos lamentarnos de las faltas de cumplimiento en alguna de las partes de


una asociación (nuestros derechos), sin observar cómo correspondemos en ella
(nuestras obligaciones).

De igual forma, un maestro se queja de los alumnos y viceversa.

Es por ello la dificultad implícita en la comprensión de esta fase, aun cuando es


muy sencilla. El mejor consejo que le podemos dar es: juegue el papel de una
entidad a en la clase de entidades A y observe cómo se asocia con B;
posteriormente, después juegue el papel de una entidad b en la clase de
entidades B y observe cómo se asocia con A.

El análisis de cada asociación no estará completo si no toma ambos roles, y muy


posiblemente su apreciación de la cardinalidad o dependencia en la asociación,
e inclusive ambas, pueden estar incorrectas..
1:1 Dependencia Total.
Cada objeto de la clase A deberá estar asociado con solamente un
objeto de B y viceversa. Por ejemplo: la asociación matrimonio entre
maridos:esposas. Bajo esta asociación, si deseara registrar A, se vería
en la necesidad de registrar B y viceversa. Por el contrario, si
necesitara borrar A, requeriría borrar B para mantener la integridad.

1:1 Dependencia Parcial.


Cada objeto de la clase A deberá estar asociado con solo un objeto de la clase B, pero los objetos de la
clase B pueden existir sin estar asociados con un objeto de la clase A. Por ejemplo: una asociación entre
gerentes: departamentos. Cada gerente deberá relacionarse con solo un departamento, pero en periodos
cortos, un departamento pudiese no tener gerente. Bajo esta asociación, si deseara registrar A, se vería en
la necesidad de asociarlo con un objeto de B o bien registrar B, mientras que si quisiera registrar B no es
necesario asociarlo con un objeto de la clase A. En cambio, si necesitara borrar un objeto de la clase B,
requeriría borrar el objeto de la case A con la que se asocia, mientras que si requiere borra un objeto de la
clase A, bastará desligarlo de del objeto en la clase B para borrarlo.

1:1 No dependiente.
Los objetos pueden existir en ambas clases de entidades sin estar asociados con objetos de
la otra clase. Por ejemplo: una asociación entre gerentes:autos. Existen gerentes que no
cuentan con autos asignados para su uso, mientras que existen autos que no están
asignados a nadie (aun cuando sea por espacios cortos de tiempo). Se pueden registrar
objetos en ambas clases de entidades sin mayor problema, pero previo a borrarlos, habrá
que ver si se encuentran relacionados, si lo están habrá que desligarlos primero, antes de
proceder al borrado.
1:N
CadaDependencia
objeto de la claseTotal.
A deberá estar asociado con al menos un objeto de la clase B, y cada objeto de la
clase B deberá estar asociado con exactamente un objeto de la clase A. Por ejemplo:
departamentos:empleados. En cada departamento trabajan n personas (al menos una),pero cada
empleado debe trabajar en un solo departamento. Para mantener la integridad en una asociación de este
tipo, se requerirá, al registrar A, hacer el registro de N de B (al menos uno). Al registrar B, se deberá
verificar la existencia de A; si no existe, registrarlo. Al borrar A se deberán borrar los N de B que se asocien
con él. Al borrar B se necesitará contabilizar los objetos de B que tengan la misma asociación que éste con
A; si N > 1 se hará el borrado de B simplemente; si N = 1 se hará el borrado de B y el borrado de A, para
mantener la integridad.

1:N Dependencia Parcial.


Cada objeto de la clase A podrá estar asociado N objetos de la clase B, y cada objeto de la clase B deberá
estar asociado con uno y solo un objeto de la clase A. Por ejemplo Productos:Detalle de Venta, un producto
puede estar relacionado a N detalles de venta (cada vez que se vende), pero si nadie lo ha comprado no se
encuentra relacionado a ningún detalle de venta, mientras que todo detalle del venta deberá estar ligado a
uno y un solo producto. Si desea borrar el detalle, solo habrá que borrarlo (cabe hacer la aclaración que
dependiendo de la situación esto pudiera implicar otras operaciones como regresar a las existencias del
producto la cantidad a borrar), mientras que si desea borrar el producto, tendría que borrar los detalles de
venta con los cuales se relaciona.

1:N No dependiente.
Cada objeto de la clase A puede estar asociado con varios objetos de la clase B. Un objeto de la clase B
puede estar asociado con solo un objeto de la clase A. Por ejemplo: empleados: equipos de seguridad. Un
empleado puede tener asignado para su seguridad N equipos (lentes, casco, etc.), y habrá equipo sobrante
que no esté asignado a nadie;. Pero si el equipo está asignado, sólo lo podrá estar a un empleado. Al borrar
al empleado únicamente se tendrán que borrar las asignaciones del o los equipos a éste sin borrar el
equipo. Al borrar el equipo, sólo se realiza esta operación.
M:N Dependencia Total.
Cada objeto de la clase A deberá estar asociado con al menos un objeto de la clase B. Un
objeto de la clase B deberá estar asociado con al menos un objeto de la clase A. Por
ejemplo: autores:publicaciones. Cada autor puede tener más de una publicación (al menos
una), y una publicación puede tener más de un autor (al menos uno). Al borrar el autor se
deberán borrar las publicaciones en las cuales sea autor único, y al borrar una publicación
se deberá borrar el autor si era la única publicación que tenía.

1:N Dependencia Parcial.

Cada objeto de la clase A deberá estar asociado con al menos un objeto de la clase B. Un
objeto de la clase B puede estar asociado con j objetos de la clase A. Por ejemplo:
clases:alumnos. Cada clase deberá tener al menos cinco alumnos para que sea impartida.
Sin embargo, habrá alumnos que no tomen ninguna clase.

1:N No dependiente.

Los objetos pueden existir en ambas clases de entidades sin estar asociados con
objetos de la otra clase, pero en todo momento pueden asociarse con varios
objetos de la otra clase de entidades.
Dependencia Total.
Se lee:
a.A  debe  b.B y
a.A  debe  b.B

Dependencia
Se lee: Parcial.
a.A  puede  b.B y a.A  debe  b.B dependencia parcial de A
en B,
a.A  debe  b.B y a.A  puede  b.B dependencia parcial de B
en A.
No dependiente.
Se lee:
a.A  puede  b.B y a.A  puede  b.B

Esquematización genérica de una asociación.


Se esquematiza mediante una línea que une a las dos clases de
entidades colocando en los extremos de la línea la expresión
“mínimo:máximo” de objetos que se pueden o deben asociar. Si es 0:N
se lee pueden, si es 1:N se lee deben. Si es 0:1 se lee puede máximo
uno, si es 1:1 deberá con uno y solo uno.
Recomendación: En el enfoque relacional.

1:
N
1: 1:
N
1 1

1: 1:
N N

Una
Se descompone en dos 1:N,
asociació
n M:N requiriendo una tercera
clase de entidades para
enlazarlas
(
)

Una clase de entidades se representa mediante un rectángulo , en cuya


esquina inferior izquierda, enmarcado se encuentra el identificador de la
case de entidades.
Los atributos se factorizan como los nombres de las columnas de una
tabla y los valores de los atributos de cada entidad forman los renglones.

Si los renglones de los valores se borran de la tabla y solo aparecen los


nombres de los atributos y el nombre de la clase de entidades se dice que
se tiene un esquema de la clase.
Si la llave de la entidad esta formado por un solo atributo, este se
subraya. Si es más de un atributo, los atributos que lo forman se encierran
entre paréntesis.
(
)

Cuando una relación se da entre dos clases de entidades, ésta se representa por
una línea. La relación ocasiona que la llave primaria de una clase de entidades
emigre hacia la otra con la que cual asocia.
El atributo heredado en la clase de entidades B, es llave primaria en la clase de
entidades A, se convierte en el atributo de enlace entre ambas. Este atributo es
denominado llave referencial.
La regla del dominio de la llave referencial. Si la dependencia de B en A es parcial
o total, el atributo deberá tener un valor que obligatoriamente este definido
dentro de los objetos en A, si no hay dependencia en la relación la llave
referencial puede tener valores nulos.
(
)

Relación 1:1, para cada objeto A existe un objeto B y viceversa. Se utiliza una
flecha en el centro de la línea.

Relación 1:N débil, para cada objeto A pueden existir N objeto de B y pero cada
objeto en B deberá relacionarse con solo un objeto de A. Se utiliza un rombo vacio
del lado N de la asociación, si N esta delimitado se especifica debajo o a un
costado del rombo.
Relación 1:N fuerte, para cada objeto A deberán existir N objetos de B y para
cada objeto en B existe uno objeto en A. Se utiliza un rombo relleno del lado N de
la asociación, si N esta delimitado se especifica debajo o a un costado del rombo.
7 Desarrollar el esquema de la base de datos.
ClaveF, TipoF no están en ninguna clase de entidades ¿cómo llegaron a Contenidos,
Referencias y Prestamos?
ClaveF = ISBN TipoF=L; ClaveF = IDArticulo TipoF=A; ClaveF = IDTesis TipoF=T; ClaveF =
IDVideo TipoF=V
Esto obliga a que los atributos ClaveF, ISBN, IDArticulo, IDTesis e IDVideo compartan el
mismo tipo de datos y la misma dimesión (por ejemplo, cadena de caracteres de una
longitud de 20)
Un poco de formalidad “Normalización”

Definición.

El proceso de normalización de una base de datos, es el conjunto de pasos que se siguen


para maximizar la flexibilidad y controlar la redundancia de la información.

Existen N formas normales, pero se dice que un diseño es operable a partir de la tercera
forma normal.

Es por ello que deberemos revisar nuestro esquema para asegurar que al menos, se
encuentra en 3ª. Forma normal.

El proceso se realiza sobre los atributos que describen una clase de entidades. O utilizando
el nivel del programador, las columnas que describen una tabla.

Se analizan las dependencias de los atributos que describen la clase de entidades respecto
a su llave primaria. O utilizando el nivel del programador, las columnas que describen una
tabla en base a su identificador.
Un poco de formalidad “Normalización”

1ª. Forma Normal.


Dada su llave primaria, para cada atributo que forma la clase de entidades tiene uno y solo
un valor. Los campos multivaluados no son validos. Por ejemplo: Dado un ISBN de un
libro, el atributo Autor para el objeto Libro es multivaluado en algunos casos, cuando el
libro fue escrito por más de un autor.

Esto ocasiona que el atributo que muestra múltiples valores, sea retirado de la tabla.
Normalmente formará otra tabla y se relacionará con la que estamos analizando.

Si cada atributo en la clase de entidades cumple con esta condición, se dice que la clase de
entidades, se encuentra en primera forma normal. Así repetimos los pasos para todas las
clases de entidades, hasta asegurar que el esquema se encuentra en 1ª. Forma normal.
Un poco de formalidad “Normalización”

2ª. Forma Normal (retirar la dependencia funcional).

Específicamente: una tabla 1NF está en 2NF si y solo si, dada cualquier llave primaria y
cualquier atributo que no sea un constituyente de la llave primaria, el atributo no llave
depende de toda la llave primaria en vez de solo una parte de ella.

En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno de
sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto
propio) de la llave primaria. (Un atributo no-principal es uno que no pertenece a ninguna
llave primaria o alterna).

Observe que cuando una tabla 1NF no tiene ninguna llave primaria (llaves primarias
consistiendo de más de un atributo), la tabla está automáticamente en 2NF

Si cada atributo en la clase de entidades cumple con esta condición, se dice que la clase de
entidades, se encuentra en 2ª. forma normal. Así repetimos los pasos para todas las clases
de entidades, hasta asegurar que el esquema se encuentra en 2ª. Forma normal.
Un poco de formalidad “Normalización”

3ª. Forma Normal (retirar la dependencia transitiva).


Una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:
1.La tabla está en la segunda forma normal (2NF) y 2. Ningún atributo no-primario de la
tabla es dependiente transitivamente de una llave primaria.

Un atributo no-primario es un atributo que no pertenece a ninguna llave primaria. Una


dependencia transitiva es una dependencia funcional X → Z en la cual Z no es
inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su
vez depende de X. Es decir, X → Z por virtud de X → Y e Y → Z.

Esto ocasiona que el atributo que muestra dependencia transitiva, sea retirado de la tabla.
Normalmente formara otra tabla y se relacionará con la que estamos analizando.

Si cada atributo en la clase de entidades no muestra dependencia transitiva, se dice que la


clase de entidades, se encuentra en tercera forma normal. Así repetimos los pasos para
todas las clases de entidades, hasta asegurar que el esquema se encuentra en 3ª. Forma
normal.
Un poco de formalidad “Normalización”

Torneo Año Ganador Fecha de nacimiento del ganador


Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Llave Atributos no
primaria primarios

(Torneo, → Ganad
año) or
(Torneo, → Fecha de nacimiento del
año) ganador
Ganad → Fecha de nacimiento del
or ganador
Un poco de formalidad “Normalización”

Aun cuando la normalización es conjunto de pasos que se siguen para maximizar la


flexibilidad y controlar la redundancia de la información.

Al final se tendremos que buscar un balance o equilibrio entre la flexibilidad y control de


redundancia contra desempeño, ya que subrayar los dos primeros principios, nos cuestan
recursos importantes como tiempo de procesamiento y tiempo de desarrollo.

1ª. Forma normal. Nos dice que son inadecuados los atributos multivaluados. En este
apartado entran los arreglos (un conjunto de elementos contiguos del mismo tipo). Esta
regla de normalización, nos da en la practica versatilidad para no bloquear espacio de
almacenamiento de antemano y quedarnos con espacio desperdiciado o insuficiente.
                 
  # …. Telefono Teléfono Nextel Bipper Otro  
Emplead Casa Celular Aributo
o
  11789AAAAA1-23-45-67       XXXX  

  11790BBBBB  1-23-45-67     YYYY  

  11791CCCCC1-23-45-67 1-23-45-67     ZZZZZ  

  11792DDDD 1-23-45-67 1-23-45-67 1-23-45- 1-23-45- XXXX  


D 67 67
  11793EEEEE 1-23-45-67 1-23-45-67     YYYY  
  11794FFFFF 1-23-45-67 1-23-45-67     ZZZZZ  
  11795GGGG 1-23-45-67 1-23-45-67 1-23-45- 1-23-45- XXXX  
G 67 67
Un poco de formalidad “Normalización”

                 
  # Empleado …. Telefono Casa Teléfono Celular Nextel Bipper Otro Aributo  
  11789AAAAA 1-23-45-67       XXXX  
  11790BBBBB   1-23-45-67     YYYY  
  11791CCCCC 1-23-45-67 1-23-45-67     ZZZZZ  
  11792DDDDD 1-23-45-67 1-23-45-67 1-23-45-67 1-23-45-67 XXXX  
  11793EEEEE 1-23-45-67 1-23-45-67     YYYY  
  11794FFFFF 1-23-45-67 1-23-45-67     ZZZZZ  
  11795GGGGG 1-23-45-67 1-23-45-67 1-23-45-67 1-23-45-67 XXXX  
                 
                 
¿Qué pasaría si alguien tiene dos teléfonos en casa? ¿o dos celulares? Y en el
peor de los casos tiene todos y cada uno de los tipos de teléfonos, pero algunos
de ellos cuenta con más de una línea.
Por ello, al extraer los atributos multivaluados de una tabla, colocarlos en otra y
relacionar la primera con la segunda, resolvemos este tipo de problemas.
Un poco de formalidad “Normalización”

Sin embargo esto no es gratis, subrayar la flexibilidad tendrá el costo de una tabla adicional,
un índice para la llave primaria, un índice para la llave relacional y la verificación de las
reglas de integridad correspondientes para la correcta operación.

Además de los recursos para obtener los teléfonos de un empleado o de los empleados,
requeriremos de operaciones y manipulación adicional, para su formateo y despliegue.
Características mucho más simples que si lo tenemos todo en una sola tabla.

Y en este caso, las ventajas son mayores que las desventajas, pero no siempre es así.

Uno de los casos que la practica nos indica tener mayores ventajas para mantener un
campo multivaluado
Cortes por periodo son:
de tiempo.
•Hora (un día siempre tiene 24 horas),
•Anual (un año siempre tiene 12 meses),
•Trimestrales (un trimestre siempre tiene tres meses y un año siempre tiene 4
trimestres).

Observe que no fue incluido el mes, ya que hay meses de 28 (febrero),29 (febrero de un año
bisiesto), 30 y 31 días de duración.
Identificar las características de recuperación de la
8 información.
Identificar las características de recuperación de la
8 información.

Proyección.

Proyección. Operador relacional que afecta la intensión de una tabla.

SELECT Cliente.Id_de_cliente, Cliente.Nombre_de_compañía,


Cliente.Nombre_del_contacto, Cliente.Cargo FROM Clientes;
Identificar las características de recuperación de la
8 información.

Selección.

Selección. Operador relacional que afecta la extensión de una tabla.

SELECT * FROM Clientes WHERE Cliente.Cargo = ‘Propietario’;


Identificar las características de recuperación de la
8 información.

Unión.
Unión. Operador relacional que une dos o más tablas mediante un
atributo en común (generalmente una llave primaria y una referencial).
La tabla resultante tiene la suma de las intensiones de las tablas
implicadas y los tuples coincidentes por el valor de unión.

SELECT * FROM libros, contenidos, temas


WHERE libros.ID = Contenidos.ID_Libro AND Contenidos.ID_Tema = Temas.ID;
Repetir los pasos anteriores con la finalidad de revisar y
9 refinar el diseño.
Structured Query Language (SQL)

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones. Estos elementos se
combinan en las instrucciones para crear, actualizar y manipular las bases de datos.

Existen dos tipos de comandos SQL:

•los DDL que permiten crear y definir nuevas bases de datos, campos e índices.
•los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Comandos DDL
Comando Descripción

CREATE Utilizado para crear nuevas tablas, campos e índices

DROP Empleado para eliminar tablas e índices

ALTER Utilizado para modificar las tablas agregando campos o cambiando


la definición de los campos.
Structured Query Language (SQL) - DDL

Con la finalidad de ejemplificar el uso del DDL de SQL, implementaremos en siguiente esquema:
Structured Query Language (SQL) - DDL

El esquema muestra 9 clases de entidades y 8 asociaciones.

• Libros-autores. Asociación M:N. La clase de entidades referencias es de enlace.


Representa que un libro deberá tener al menos un autor, aunque podrá tener varios, y
todo autor deberá serlo de al menos un libro, y podrá serlo de varios.
• Libros-préstamos. Un libro podrá estar prestado, asignado a uno y sólo un préstamo
y todo préstamo deberá tener un libro asignado (asociación 1:1 en dependencia parcial
de libros en préstamos).
• Usuarios-préstamos. Un usuario podrá tener préstamos (varios), y todo préstamo
deberá asociarse a un usuario (asociación 1:N en dependencia parcial de usuario en
préstamos).
• Libros-temas. Asociación M:N, la clase de entidades contenido es de enlace.
Representa que un libro deberá contener al menos un tema, aunque podrá contener
varios, y todo tema podrá ser abordado en al menos un libro, y podrá serlo de varios.
• Libros-compras. Un libro pudo haberse comprado, y toda compra deberá asociarse
con un libro (asociación 1:1 en dependencia parcial de libros en compras).
• Proyectos-compras. En un proyecto se pueden hacer N compras y toda compra
deberá asociarse a un proyecto.
Structured Query Language (SQL) - DDL

Instancia de la base de datos


Structured Query Language (SQL) - DDL

Construcción de la base de datos, tabla de autores

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL)
-- DATABASE DEFINITION

CREATE DATABASE IF NOT EXISTS Example_mybook;


USE Example_mybook;

DROP TABLE IF EXISTS `Autores`;


CREATE TABLE `Autores` (
`ID` int(11) NOT NULL auto_increment,
`Nombre` char(20) NOT NULL default "Desconocido",
`Apellido` char(20) NOT NULL default '',
`Alias` char(20) NOT NULL default '',
PRIMARY KEY (`ID`), -- define primary key (created by methodology)
UNIQUE(`Nombre`,`Apellido`) -- define altern key (the elementary primary key)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DDL

Construcción de la base de datos, tabla de libros

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL)
-- DATABASE DEFINITION

DROP TABLE IF EXISTS `Libros`;


CREATE TABLE `Libros` (
`ID` int(11) NOT NULL auto_increment,
`Nombre` char(80) NOT NULL default '',
`Edicion` char(3) NOT NULL default "1a",
`Ano` int(4) NOT NULL default 1950,
`Editorial` char(30) NOT NULL default '',
`Estado` enum('Comprado','Recomendado','Prestado') NOT NULL default 'Recomendado',
`Prioridad` enum('Urgente','Normal','Baja','Opcional') NOT NULL default 'Opcional',
PRIMARY KEY (`ID`),
UNIQUE (`Nombre`,`Edicion`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DDL

Construcción de la base de datos, tabla refeferencias

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL)
-- DATABASE DEFINITION

DROP TABLE IF EXISTS `Referencias`;


CREATE TABLE `Referencias` (
`ID_Libro` int(11) NOT NULL default 0,
`ID_Autor` int(11) NOT NULL default 0,
PRIMARY KEY (`ID_Libro`,`ID_Autor`),
INDEX (`ID_Libro`),
INDEX (`ID_Autor`),
FOREIGN KEY(`ID_Libro`) REFERENCES Libros(`ID`),
-- define relational key (primary key in libros)
FOREIGN KEY(`ID_Autor`) REFERENCES Autores(`ID`)
-– define relational key (primary key in
autores)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DDL

Construcción de la base de datos, tabla Usuarios y prestamos


-- Example_mybook.sql -- for MYSQL
-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL)
-- DATABASE DEFINITION

DROP TABLE IF EXISTS `Usuarios`;


CREATE TABLE `Usuarios` (
`ID` int(11) NOT NULL auto_increment,
`Nombre` char(25) NOT NULL default '',
`Apellidos` char(50) NOT NULL default '',
`Direccion` char(80) NOT NULL default '',
`Telefono` char(11) NOT NULL default '',
PRIMARY KEY (`ID`),
UNIQUE (`Nombre`,`Apellidos`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

DROP TABLE IF EXISTS `Prestamos` ;


CREATE TABLE `Prestamos` (
`ID_Usuario` int(11) NOT NULL default 0,
`ID_Libro` int(11) NOT NULL default 0,
`Fecha` Date NOT NULL,
`Vencimiento` Date NOT NULL,
PRIMARY KEY (`ID_Usuario`, `ID_Libro`),
INDEX(`ID_Usuario`),
INDEX(`ID_Libro`),
FOREIGN KEY(`ID_Usuario`) REFERENCES Usuarios(`ID`) ON DELETE CASCADE,
FOREIGN KEY(`ID_Libro`) REFERENCES Libros(`ID`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DDL

Construcción de la base de datos, tabla Temas, Contenidos, Proyectos, Compras

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- Example_mybook.sql -- for MYSQL -- for FCA-UABC course DATABASE DESIGN ESSENTIALS
-- prepared by Jose L. Cisneros -- DATABASE DEFINITION
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS
-- DATABASE DEFINITION DROP TABLE IF EXISTS `Proyectos` ;
CREATE TABLE `Proyectos` (
DROP TABLE IF EXISTS `Temas` ; `ID` int(11) NOT NULL auto_increment,
CREATE TABLE `Temas` ( `Nombre` char(50) NOT NULL default '',
`ID` int(11) NOT NULL auto_increment, `Presupuesto` decimal(10.2) default 0.0,
`Nombre` char(50) NOT NULL default '', PRIMARY KEY (`ID`),
PRIMARY KEY (`ID`), UNIQUE (`Nombre`)
UNIQUE (`Nombre`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS `Compras` ;
DROP TABLE IF EXISTS `Contenidos` ; CREATE TABLE `Compras` (
CREATE TABLE `Contenidos` ( `ID_Libro` int(11) NOT NULL default 0,
`ID_Libro` int(11) NOT NULL default 0, `ID_Proyecto` int(11) NOT NULL default 0,
`ID_Tema` int(11) NOT NULL default 0, `Fecha` Date NOT NULL,
PRIMARY KEY (`ID_Libro`,`ID_Tema`), `Costo` decimal(10.2) default 0.0,
INDEX(`ID_Libro`), `Factura` char(25) NOT NULL default '',
INDEX(`ID_Tema`), PRIMARY KEY (`ID_Libro`,`ID_Proyecto`),
FOREIGN KEY(`ID_Libro`) REFERENCES Libros(`ID`), UNIQUE(`ID_Libro`),
FOREIGN KEY(`ID_Tema`) REFERENCES Temas(`ID`) INDEX(`ID_Libro`),
) ENGINE=InnoDB DEFAULT CHARSET=latin1; INDEX(`ID_Proyecto`),
FOREIGN KEY(`ID_Libro`) REFERENCES Libros(`ID`),
FOREIGN KEY(`ID_Proyecto`) REFERENCES Proyectos(`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DML

Usando DML para probar definición de la base de datos:

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL for examples)
-- DATALOAD

USE Example_mybook;
INSERT INTO `Autores` VALUES (1,'C.J.','Date','Date');

-- TRY INSERT INCORRECT DATA (DUPLICATE PRIMARY KEY)


INSERT INTO `Autores` VALUES (1,'C.J.','Date','Date');

-- TRY INSERT INCORRECT DATA (DUPLICATE ALTERN KEY)


INSERT INTO `Autores` VALUES (2,'C.J.','Date','Date');

INSERT INTO `Autores` VALUES (18,'Kernan D.','Bharucha','Bharucha');


INSERT INTO `Autores` VALUES (41,'Niclaus','Wirt','Wirth');
INSERT INTO `Autores` VALUES (45,'Nell','Dale','Dale');
INSERT INTO `Autores` VALUES (33,'Susan C.','Lilly','Lilly');
INSERT INTO `Autores` VALUES (9,'Mark L.','Guillerson','Guillerson');
INSERT INTO `Autores` VALUES (19,'James','Martin','Martin');
Structured Query Language (SQL) - DML

Usando DML para probar definición de la base de datos:

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL for examples)
-- DATALOAD

USE Example_mybook;

INSERT INTO `Libros` VALUES (8,'Computer Database


Organization','1a',1975,'Prentice-Hall','Comprado','Opcional');
INSERT INTO `Libros` VALUES (10,'Database step by step','1a',1988,'Mc. Graw-
Hill','Recomendado','Urgente');
INSERT INTO `Libros` VALUES (2,'Algorithms + Data Structures =
Programs','3a',1976, 'Prentice-Hall','Comprado','Normal');
INSERT INTO `Libros` VALUES (1,'An Introduction to Database Systems Vol.
I','6a',1995, 'Addison-Wesley','Comprado','Urgente');
INSERT INTO `Libros` VALUES (4,'An Introduction to Database Systems Vol.
II','1a',1987, 'Addison-Wesley','Comprado','Urgente');
INSERT INTO `Libros` VALUES (16,'Pascal y Estructura de Datos','1a',1986, 'Mc. Graw-
Hill','Comprado','Normal');
INSERT INTO `Libros` VALUES (7,'dBase iV A Comprehensive Manual','1a',1989,
'Windcrest Books','Recomendado','Urgente');
Structured Query Language (SQL) - DML

Usando DML para probar definición de la base de datos:

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL for examples)
-- DATALOAD

USE Example_mybook;
INSERT INTO `Referencias` VALUES (1,1);
INSERT INTO `Referencias` VALUES (4,1);
INSERT INTO `Referencias` VALUES (8,19);
INSERT INTO `Referencias` VALUES (10,9);
INSERT INTO `Referencias` VALUES (2,41);
INSERT INTO `Referencias` VALUES (16,45);
INSERT INTO `Referencias` VALUES (16,33);
INSERT INTO `Referencias` VALUES (7,18);

-- TRY TO INSERT INVALID DATA (LIBRO DOESN’T EXIST)


INSERT INTO `Referencias` VALUES (100,1);

-- TRY TO INSERT INVALID DATA (AUTOR DOESN’T EXIST)


INSERT INTO `Referencias` VALUES (4,100);
Structured Query Language (SQL) - DML

Usando DML para probar definición de la base de datos:

-- Example_mybook.sql -- for MYSQL


-- prepared by Jose L. Cisneros
-- for FCA-UABC course DATABASE DESIGN ESSENTIALS (using MYSQL for examples)
-- DATALOAD

USE Example_mybook;
INSERT INTO `Referencias` VALUES (1,1);
INSERT INTO `Referencias` VALUES (4,1);
INSERT INTO `Referencias` VALUES (8,19);
INSERT INTO `Referencias` VALUES (10,9);
INSERT INTO `Referencias` VALUES (2,41);
INSERT INTO `Referencias` VALUES (16,45);
INSERT INTO `Referencias` VALUES (16,33);
INSERT INTO `Referencias` VALUES (7,18);

-- TRY TO INSERT INVALID DATA (LIBRO DOESN’T EXIST)


INSERT INTO `Referencias` VALUES (100,1);

-- TRY TO INSERT INVALID DATA (AUTOR DOESN’T EXIST)


INSERT INTO `Referencias` VALUES (4,100);
Structured Query Language (SQL) - DDL

Usando DDL creación de otros objetos:

Un Trigger o disparador es un es un procedimiento que se ejecuta cuando se


cumple una condición establecida al realizar una operación. Se asocia a una
tabla.

Insertar
Antes Actualizar
Borrar
Trigger

Insertar
Después Actualizar
Borrar

DELIMITER $$
CREATE TRIGGER `example_mybook`.`Example_trigger` BEFORE
INSERT on `example_mybook`.`autores`
FOR EACH ROW BEGIN
SET NEW.Alias = 'patito';
END$$
DELIMITER ;
Structured Query Language (SQL) - DML

Triggers o disparadores

INSERT INTO `Autores` VALUES (5,’Ejemplo’,’Trigger’,’Trigger’)

DELIMITER $$
CREATE TRIGGER `example_mybook`.`Example_trigger` BEFORE
INSERT on `example_mybook`.`autores`
FOR EACH ROW BEGIN
SET NEW.Alias = 'patito';
END$$
DELIMITER ;
Structured Query Language (SQL) - DDL

Usando DDL creación de otros objetos:

Una vista de base de datos es un resultado de una consulta SQL de una o


varias tablas; también se le puede considerar una tabla virtual.

Las vistas tienen la misma estructura que una tabla: filas y columnas. La
única diferencia es que sólo se almacena de ellas la definición, no los datos.
Los datos que se recuperan mediante una consulta a una vista se
presentarán igual que los de una tabla. De hecho, si no se sabe que se está
trabajando con una vista, nada hace suponer que es así.

DROP VIEW IF EXISTS `example_mybook`.`Test`;

CREATE VIEW `example_mybook`.`Test` AS


(SELECT Libros.ID, Libros.Nombre, Libros.Edicion, Libros.Ano,
Libros.Editorial, Autores.Nombre AS Anombre, Autores.Apellido
FROM libros, referencias, autores
WHERE Libros.Estado = 'Comprado' AND (Libros.id =
Referencias.ID_Libro AND Referencias.ID_Autor = Autores.ID))
Structured Query Language (SQL) - DML

Vista:

SELECT * FROM Test;

CREATE VIEW `example_mybook`.`Test` AS


(SELECT Libros.ID, Libros.Nombre, Libros.Edicion, Libros.Ano,
Libros.Editorial, Autores.Nombre AS Anombre, Autores.Apellido
FROM libros, referencias, autores
WHERE Libros.Estado = 'Comprado' AND (Libros.id =
Referencias.ID_Libro AND Referencias.ID_Autor = Autores.ID))
Structured Query Language (SQL) - DML

Transacciones:

Una transacción es una interacción compuesta por varios procesos que se han de aplicar
uno después del otro. La transacción debe ser equivalente a una interacción atómica. Es
decir, que se realice de una sola vez y que la estructura a medio manipular no sea jamás
alcanzable por el resto del sistema hasta que haya finalizado todos sus procesos.

START TRANSACTION;
DELETE FROM Usuarios WHERE Id = 25;
ROLLBACK;

CREATE TABLE `Prestamos` (


`ID_Usuario` int(11) NOT NULL default 0,
`ID_Libro` int(11) NOT NULL default 0,
`Fecha` Date NOT NULL,
`Vencimiento` Date NOT NULL,
PRIMARY KEY (`ID_Usuario`, `ID_Libro`),
INDEX(`ID_Usuario`),
INDEX(`ID_Libro`),
FOREIGN KEY(`ID_Usuario`) REFERENCES Usuarios(`ID`) ON DELETE
CASCADE,
FOREIGN KEY(`ID_Libro`) REFERENCES Libros(`ID`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Structured Query Language (SQL) - DML

Transacción:

START TRANSACTION;
SELECT * FROM Usuarios;

SELECT * FROM Prestamos;

DELETE FROM Usuarios WHERE Id = 25;


(1 row(s) affected)

SELECT * FROM Usuarios;

SELECT * FROM Prestamos;

ROLLBACK;
Integridad y consistencia de la información

Manejo de valores nulos.


Se refiere a la verificación de que cualquier valor que tome una pieza de información, sea
consistente y su valor se encuentre dentro del dominio correcto.

Integridad de la llave primaria.


Verificar que un objeto no se repita en una clase de entidades, y que el o los atributos que
forman el identificador, no contengan valores nulos.

Integridad de la llave referencial.


Cuando un(os) atributo(s) se encuentra(n) en una clase de entidades y a la vez es(son) llave primaria en
otra, sirve(n) como referencia del segundo en el primero. Así, cuando tales atributos tienen un valor
determinado, dicho valor deberá estar dentro del conjunto
definido por el de todos los valores, donde el atributo es llave primaria. En caso contrario, se estaría
relacionando un objeto con otro inexistente, y podría aceptar valores nulos en los casos de asociaciones no
dependientes.

Restricciones de cardinalidad y dependencia.


Restricciones de cardinalidad y dependencia por el manejo de las asociaciones planteadas
por el esquema.

Reglas del negocio.


Este apartado hace referencia a las restricciones que no son manejadas directamente por
el esquema, sino que son dependientes de la aplicación que se esté analizando.
Integridad y consistencia de la información

Manejo y control de las transacciones.


Se refiere a salvaguardar la propiedad ACID de las transacciones.

Serialización de todo conjunto concurrente de transacciones.


Controlar o eliminar los conflictos potenciales que se dan por transacciones que solicitan el
mismo recurso al mismo tiempo.

De las cinco primeras hemos hablado en las secciones anteriores, y


ahora nos
concentraremos en la penúltima. De la última hablaremos en la
siguiente sección.
Concepto de transacción

Una transacción es una interacción compuesta por varias operaciones básicas que se han
de aplicar una después de otra. La transacción debe ser equivalente a una interacción
atómica. Es decir, que se realice de una sola vez y que la estructura a medio manipular no
sea jamás alcanzable por el resto del sistema hasta que haya finalizado todas sus
operaciones básicas.

Las operaciones básicas que conforman una transacción están definidas por la lógica del
esquema de la base de datos.

CONSULTA CONSULTA
CONSULTA
CAMBIO
CAMBIO

REGISTRO
REGISTRO
Concepto y propiedades de las transacciones.

Una transacción toma la base de datos en estado integro y consistente y al terminar la


entrega en estado integro y consistente.

Transacción

Una transacción es una transformación de estado correcta. Las


acciones consideradas en su conjunto no violan ninguna de las Una vez que una transacción ha finalizado
restricciones de integridad asociadas al estado. Esto implica con éxito (compromiso), cambia hacia un
que la transacción debe ser un programa correcto. estado estable a prueba de fallos.

Atomicidad Consistencia Aislamiento Durabilidad

Los cambios de estado provocados por una Incluso cuando varias transacciones se ejecuten de
transacción son atómicos: o bien ocurren todos o forma concurrente, para cada transacción T debe
bien no ocurre ninguno. Estos cambios incluyen parecer que el resto de transacciones se han
tanto modificaciones de la base de datos, como ejecutado antes o después de T, pero no antes y
envío de mensajes. después.
Estado de una transacción.
Marco de la transacción.

Marco Altas y Modificaciones Clientes.


Bajo este marco solo se requiere la clase de entidades, Clientes.

Marco Baja de Clientes.


Bajo este marco requieren las clases de entidades Clientes, Ventas y Detalles_Ventas

También podría gustarte