BASE DE DATOS.

ING. LUIS ARMIJOS VALAREZO

INTRODUCCIÓN A LOS SISTEMAS DE GESTIÓN DE
BASES DE DATOS

2
HISTORIA

El término Base de Datos se usó por primera vez en un simposio

celebrado en California, en el año 1963. Su origen se remonta a la
antigüedad, cuando ya existían bibliotecas y registros acumulados
de hechos y situaciones, de forma escrita y gráfica. Obviamente,
por falta de recursos tecnológicos, la búsqueda y recopilación de
información era mucho más lenta que hoy día. No había máquinas
que ayudaran y pudieran reemplazar el trabajo manual.

Pero mucho ayudaron nuestros antepasados, ya que guardaron

información muy valiosa, que sin ella sería muy difícil explicar
nuestra existencia desde aquellos tiempos remotos.

3
HISTORIA

En 1884, los censos se realizaban de forma manual, hasta que

Herman Hollerith inventó la máquina automática de perforación
de tarjetas, que se usó en el censo de los Estados Unidos,
mejorando significativamente el proceso de terminación, de siete
años a dos años y medio.

Mientras que en la década de 1950, se cambia a un sistema de

lectura secuencial y ordenada. El inglés Oberlin Smith, con este
mecanismo, dio inicio a la automatización de la información
referente a las nóminas, a través de cintas magnéticas, que a su
vez respaldaban dicha información.

4
EVOLUCIÓN DE LA BASE DE DATOS

Una década después, en 1960, las empresas pudieron adquirir

computadoras para facilitar sus gestiones. Las empresas
informáticas habían bajado los precios de las mismas, para
popularizar el uso de los discos, adelanto muy valioso y útil para
esa época, ya que se ubicaba la información de manera directa,
sin necesidad de saber la ubicación exacta de los datos.

También se inició la primera generación de bases de datos de red

(CODASYL) y las jerárquicas (IMS), que consistían en guardar las
estructuras de datos en listas y árboles, además de que permitió
crear un estándar en las bases de datos, gracias a los nuevos
lenguajes implementados en los sistemas de información.
5
EVOLUCIÓN DE LA BASE DE DATOS

CODASYL
Conference on Data Systems Languages, como
consorcio de industrias del área informática, tenía
como objeto regular el lenguaje de programación
estándar, para que pudiera usarse en multitud de
ordenadores.

El sistema SABRE se convirtió en un éxito

comercial, fue utilizado por IBM en la firma
American Airlines, para gestionar sus datos de
reservas de vuelos, transacciones e
informaciones referidas a los pasajeros.
6
EVOLUCIÓN DE LA BASE DE DATOS

Década del 70

Hay valiosos aportes, como los de Edgar Frank Codd, científico informático inglés,
quien definió el modelo relacional. El multimillonario Lawrence “Larry” Ellison, pudo
desarrollar el Relational Software System o sistema de datos ORACLE, aprovechando
esa información de Codd. Este consistió en un sistema de administración de Base de
Datos relacionados, el cual se destacaba por su estabilidad, escalabilidad,
transacciones y multiplataforma.

IBM desarrolló unas técnicas para construir un sistema de bases de datos

relacionales eficientes, las cuales llamó System R; por otro lado Ingres se desarrolló
en la UBC en los años de 1974 a 1977.

7
EVOLUCIÓN DE LA BASE DE DATOS

Ingres utilizaba un lenguaje de consulta, llamado QUEL, dando pie a la

creación de sistemas como Ingres Corporación, MS SQL Server, Sybase,
PACE Wang, y Britton Lee-. Por su parte, el Sistema R utilizó el lenguaje de
consulta Secuela, el cual ha contribuido al desarrollo de SQL / DS, DB2,
Allbase, Oracle y SQL Non-Stop. En esta década el término Relational
Database Management System, o RDBMS, fue ampliamente reconocido.
Con esto se abrió paso al nacimiento de la segunda generación de los
Sistemas Gestores de Bases de Datos.

8
EVOLUCIÓN DE LA BASE DE DATOS

Años 80’: Comercialización de sistemas relacionales

En la década de los años 80’, se desarrolló el SQL (Structured Query Language), un
lenguaje de consultas que permite consultar, con el fin de recuperar información de
una base de datos y a su vez, hacer cambios sobre esa misma base, de forma
sencilla.

Permitía analizar gran cantidad de información y especificar varios tipos de

operaciones con la misma información, a diferencia de los años anteriores, cuando
se diseñaron aplicaciones de procesamientos de transacciones.

SQL comenzó a ser el modelo estándar de las industrias, con su base de datos bajo
un sistema de tablas (filas y columnas), pudo competir con las bases jerárquicas y
de redes, ya que su nivel de programación era sencillo y el nivel era relativamente
bajo.

9
EVOLUCIÓN DE LA BASE DE DATOS

10
ESTRUCTURA DE LA BASE DE DATOS

La base de datos y la estructura de base de datos se definen en el proceso de

instalación. .
Base de datos que se puede percibir como un conjunto de tablas y se puede
manipular según el modelo relacional de los datos.

Cada base de datos incluye:

1. Conjunto de tablas de catálogo de sistema que describe la estructura lógica y

física de los datos.
2. Archivo de configuración que contiene los valores de parámetro asignados a la
base de datos.
3. Registro de recuperación con transacciones en curso y transacciones
archivables.

11
ESTRUCTURA DE LA BASE DE DATOS

12
ESTRUCTURA DE LA BASE DE DATOS

El siguiente paso es organizar la representación visual de tu base

de datos. Para ello, debes comprender exactamente cómo se
estructuran las bases de datos relacionales.

Dentro de una base de datos, los datos relacionados se agrupan

en tablas, cada una de ellas consiste en filas (también llamadas
"tuplas") y columnas, como una hoja de cálculo.

Para convertir tus listas de datos en tablas, comienza creando

una tabla para cada tipo de entidad, como productos, ventas,
clientes y pedidos. Te mostramos un ejemplo a continuación:

Cada fila de una tabla se llama "registro". Los registros incluyen

datos sobre algo o alguien, como un cliente específico. En
cambio, las columnas (también conocidas como "campos" o
"atributos") contienen un único tipo de información que aparece
en cada registro, como las direcciones de todos los clientes
enumerados en la tabla.
13
ESTRUCTURA DE LA BASE DE DATOS

Con el fin de que los datos sean consistentes de un registro al siguiente, asigna el
tipo de datos apropiado a cada columna. Los tipos de datos comunes incluyen:

CHAR - una longitud específica de texto.

VARCHAR - texto de longitudes variables.
TEXT - grandes cantidades de texto.
INT - número entero positivo o negativo.
FLOAT, DOUBLE - también puede almacenar números de punto flotante.
BLOB - datos binarios.

Algunos sistemas de gestión de bases de datos también ofrecen el tipo de datos

denominado "Autonumeración", que genera automáticamente un número único en
cada fila.

A los efectos de crear una visión general de la base de datos, conocida como un
diagrama entidad-relación, no incluiremos las tablas reales, sino que cada tabla se
convertirá en un recuadro del diagrama. El título de cada recuadro debería indicar
qué describen los datos en la tabla, mientras que los atributos están enumerados a
continuación, del siguiente modo: 14
ESTRUCTURA DE LA BASE DE DATOS

Por último, deberías decidir qué atributo o atributos funcionarán como clave primaria para cada
tabla, si procede. Una clave primaria (PK) es un identificador único para una entidad determinada,
esto significa que puedes seleccionar un cliente concreto incluso si solo conoces ese valor.

Los atributos seleccionados como claves primarias deben ser únicos, inalterables y estar siempre
presentes (nunca NULL o vacíos). Por este motivo, los números de pedido y los nombres de
usuario son excelentes claves primarias, mientras que los números de teléfono o direcciones
postales no lo son. También puedes usar múltiples campos conjuntamente como la clave primaria
(esto se denomina "clave compuesta").

Cuando llegue el momento de crear la base de datos real, ubicarás la estructura de datos lógicos y
la estructura de datos físicos en el lenguaje de definición de datos admitido por nuestro sistema de
gestión de base de datos.

15
 FUNCIONES DE LA BASE DE DATOS

A continuación detallamos una forma diferente de clasificar las funciones y los requisitos de un
sistema de gestión de bases de datos:
Almacenar datos Las bases de datos almacenan textos, documentos, contraseñas, etc., en formato electrónico,
a los que puede accederse mediante consultas.
Editar datos Según de qué permisos se disponga, la mayoría de bases de datos permiten editar in situ los
datos que salvaguardan.
Borrar datos Los registros de las bases de datos pueden borrarse por completo, sin dejar espacios en
blanco. En algunos casos los datos que se han borrado pueden restablecerse, pero en otros,
se eliminan definitivamente.
Gestionar los metadatos Normalmente, la información se guarda con metadatos o metaetiquetas que mantienen el
orden dentro de la base de datos y hacen posible la función de búsqueda. Los metadatos
también suelen utilizarse para regular los permisos.
La gestión de datos comprende cuatro operaciones fundamentales: crear (create),
leer/recuperar (read/retrieve), actualizar (update) y borrar (delete). Este concepto, conocido por
su acrónimo CRUD, constituye la base de la gestión de datos.

Seguridad de los datos Las bases de datos han de ser seguras para evitar que sujetos no autorizados puedan acceder
a la información que guardan. Además de un solvente método de cifrado, para mantener la
seguridad de los datos es esencial poner esmero en su administración, sobre todo su
administrador principal. La seguridad de los datos implica tomar las precauciones técnicas
necesarias para impedir la manipulación o la pérdida de datos.

16
 FUNCIONES DE LA BASE DE DATOS

Integridad de los datos La integridad de los datos significa que los datos han de cumplir con ciertas reglas para
asegurar su corrección y definir la lógica de negocio del banco de datos. Solo así, puede
asegurarse que la base de datos ,al completo, funciona de forma constante y coherente. En los
modelos relacionales se dan cuatro de estas reglas: integridad de campo, integridad de
entidad, integridad referencial y consistencia lógica.
Función multiusuario Las aplicaciones de base de datos permiten acceder a las bases de datos desde diferentes
dispositivos. El reparto de permisos y la seguridad de los datos son elementales en el uso
multiusuario. También constituye un reto, mantener la consistencia de los datos sin dificultar el
rendimiento, cuando varios usuarios leen y escriben a la vez.
Optimizar las consultas Técnicamente, una base de datos ha de poder procesar las consultas de la mejor manera
posible para garantizar una buena performance. Si utiliza demasiadas rutas diferentes para
solucionar una consulta, el rendimiento global del sistema se verá perjudicado.
Triggers y stored procedures Estos dos procedimientos son miniaplicaciones guardadas en los SGBD que se activan con
ciertos eventos. Con ellos se pretende, entre otras cosas, mejorar la integridad de los datos.
Los disparadores (triggers) y los procedimientos almacenados (stored procedures) son
procesos típicos de las bases de datos relacionales. Los segundos contribuyen a la seguridad
del sistema si los usuarios solo ejecutan las acciones con procedimientos predefinidos.
Transparencia del sistema La transparencia del sistema es relevante, sobre todo, en los sistemas distribuidos; privando al
usuario de la distribución y la implementación de los datos, la utilización de una base de datos
distribuida se asemeja al de una centralizada. Los procesos que corren en segundo plano se
muestran u ocultan en diversos niveles de transparencia. La función principal es, no obstante,
simplificar su uso todo lo posible.

17
CARACTERÍSTICAS DE LOS SGBD

Independencia:

La independencia lógica es la capacidad de modificar el esquema conceptual sin

tener que alterar los esquemas externos ni los programas de aplicación. Se puede
modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si,
por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas
externos que no se refieran a ella no deberán verse afectados.

La independencia física es la capacidad de modificar el esquema interno sin tener

que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario
reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las
OPERACIONES de consulta o de actualización de datos. Dado que la independencia
física se refiere sólo a la separación entre las aplicaciones y las ESTRUCTURAS
físicas de almacenamiento, es más fácil de conseguir que la independencia LOGICA.

18
CARACTERÍSTICAS DE LOS SGBD

Integridad:

La integridad de los datos se refiere a la información almacenada en cualquier tipo

de base de datos o centro de datos que sea precisa, completa, consistente y
confiable, sin importar cuánto tiempo se almacene o con qué frecuencia se acceda a
ella. Mantener la integridad de los datos significa garantizar que los datos
permanezcan intactos, que se puedan buscar y recuperar durante el transcurso de su
ciclo de vida. El trabajo de las soluciones de protección de datos es garantizar la
integridad de los datos mediante la protección de la información confidencial y
crítica para el negocio de las amenazas externas e internas.

19
CARACTERÍSTICAS DE LOS SGBD

Seguridad:

La seguridad de los datos se refiere a las medidas de protección empleadas para

proteger los datos contra accesos no autorizados y para preservar la
confidencialidad, la integridad y la disponibilidad de la base de datos.

20
CARACTERÍSTICAS DE LOS SGBD

Recuperación:

La recuperación es la reconstrucción de una base de datos o espacio de tabla

después de un problema como, por ejemplo, anomalía de almacenamiento,
interrupción de alimentación o anomalía de la aplicación. Si ha realizado una copia
de seguridad de la base de datos o de espacios de tabla individuales, puede
reconstruirlos en caso de que se dañen de alguna manera.

21
CARACTERÍSTICAS DE LOS SGBD

Atomicidad:

En una transacción atómica, una serie de operaciones en la base de datos ocurren

todas, o no ocurre ninguna. La atomicidad previene que las actualizaciones a la base
ocurren de forma parcial, lo cual podría ocasionar mayores problemas que rechazar
la transacción entera.

22
CARACTERÍSTICAS DE LOS SGBD

Concurrencia:

La concurrencia de bases de datos es la capacidad de una base de datos para

permitir que varios usuarios afecten a varias transacciones. Esta es una de las
principales propiedades que separa una base de datos de otras formas de
almacenamiento de datos, como las hojas de cálculo.

23
CRITERIOS DE SELECCIÓN DE UN SGBD

Presupuesto disponible: es uno de los factores más importantes, la cuantía que se desee
invertir marcará en gran medida todo el proceso de elección.

Nivel de soporte proporcionado por el fabricante del SGBD: este factor es la principal
desventaja que presenta el software gratuito en un entorno profesional, ya que el hecho de
no contar con ningún tipo de soporte puede llegar a ser un hándicap.

Compatibilidad con software y hardware existente: factor también muy importante. Conlleva
realizar un detallado análisis para evitar futuros problemas, que además podrían llegar a
tener soluciones de gran impacto.

Bases de datos que soportará (Relacional-No relacional): no es un parámetro determinante,

pero sí a tener en cuenta, sobre todo si ya está definida la base de datos.

Volumen de datos: un estudio sobre el volumen de datos actual y una estimación del futuro
a largo plazo pueden llegar a ser también factores importantes a la hora de seleccionar un
SGBD.
24
CRITERIOS DE SELECCIÓN DE UN SGBD

Rendimiento: es clave no solo en la selección del SGBD, sino que también en la versión o
configuración del mismo.

Gestión de transacciones: fundamental realizar un análisis sobre el tipo de transacciones

que gestionará, número de usuarios, etc. para poder seleccionar la solución más eficiente.

Accesibilidad: aunque generalmente este parámetro varía poco de un fabricante a otro,

siempre será positivo un pequeño análisis para evitar sorpresas futuras.

Seguridad: podría llegar a ser un factor vital, aunque si ese fuese el caso, lo más
recomendable sería invertir en software o hardware de terceros.

Otros parámetros: analizar cualquier otro parámetro que el administrador considere

oportuno.

25
CICLO DE VIDA DE UNA BASE DE DATOS

Planeación.
Análisis.
Diseño.
Implementación.
Mantenimiento.

26
BASES DE DATOS NO RELACIONALES NOSQL

Son muchas las aplicaciones web que utilizan algún tipo de bases de datos para funcionar. Hasta
ahora estábamos acostumbrados a utilizar bases de datos SQL como son MySQL, Oracle o MS
SQL, pero desde hace ya algún tiempo han aparecido otras que reciben el nombre de NoSQL (Not
only SQL – No sólo SQL) y que han llegado con la intención de hacer frente a las bases relacionales
utilizadas por la mayoría de los usuarios.

Se puede decir que la aparición del término NoSQL aparece con la llegada de la web 2.0 ya que
hasta ese momento sólo subían contenido a la red aquellas empresas que tenían un portal, pero
con la llegada de aplicaciones como Facebook, Twitter o Youtube, cualquier usuario podía subir
contenido, provocando así un crecimiento exponencial de los datos.

Es en este momento cuando empiezan a aparecer los primeros problemas de la gestión de toda
esa información almacenada en bases de datos relacionales. En un principio, para solucionar estos
problemas de accesibilidad, las empresas optaron por utilizar un mayor número de máquinas pero
pronto se dieron cuenta de que esto no solucionaba el problema, además de ser una solución muy
cara. La otra solución era la creación de sistemas pensados para un uso específico que con el
paso del tiempo han dado lugar a soluciones robustas, apareciendo así el movimiento NoSQL.

27
BASES DE DATOS NO RELACIONALES NOSQL

Por lo tanto hablar de bases de datos NoSQL es hablar de estructuras que nos permiten
almacenar información en aquellas situaciones en las que las bases de datos relacionales
generan ciertos problemas debido principalmente a problemas de escalabilidad y
rendimiento de las bases de datos relacionales donde se dan cita miles de usuarios
concurrentes y con millones de consultas diarias.

Además de lo comentado anteriormente, las bases de datos NoSQL son sistemas de

almacenamiento de información que no cumplen con el esquema entidad–relación.
Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los
datos sino que para el almacenamiento hacen uso de otros formatos como clave–valor,
mapeo de columnas o grafos (ver epígrafe ‘Tipos de bases de datos
NoSQL’).

28
BASES DE DATOS NO RELACIONALES NOSQL

VENTAJAS

Esta forma de almacenar la información ofrece ciertas ventajas sobre los modelos relacionales.
Entre las ventajas más significativas podemos destacar:

▪ Se ejecutan en máquinas con pocos recursos: Estos sistemas, a diferencia de los sistemas
basados en SQL, no requieren de apenas computación, por lo que se pueden montar en
máquinas de un coste más reducido.
▪ Escalabilidad horizontal: Para mejorar el rendimiento de estos sistemas simplemente se
consigue añadiendo más nodos, con la única operación de indicar al sistema cuáles son los
nodos que están disponibles.
▪ Pueden manejar gran cantidad de datos: Esto es debido a que utiliza una estructura
distribuida, en muchos casos mediante tablas Hash.
▪ No genera cuellos de botella: El principal problema de los sistemas SQL es que necesitan
transcribir cada sentencia para poder ser ejecutada, y cada sentencia compleja requiere
además de un nivel de ejecución aún más complejo, lo que constituye un punto de entrada
en común, que ante muchas peticiones puede ralentizar el sistema.

29
BASES DE DATOS NO RELACIONALES NOSQL

DIFERENCIAS

Algunas de las diferencias más destacables que nos podemos encontrar entre los sistemas NoSQL y
los sistemas SQL están:

▪ No utilizan SQL como lenguaje de consultas. La mayoría de las bases de datos NoSQL evitan
utilizar este tipo de lenguaje o lo utilizan como un lenguaje de apoyo. Por poner algunos
ejemplos,
▪ Cassandra utiliza el lenguaje CQL, MongoDB utiliza JSON o BigTable hace uso de GQL.
▪ No utilizan estructuras fijas como tablas para el almacenamiento de los datos. Permiten hacer
uso de otros tipos de modelos de almacenamiento de información como sistemas de clave–
valor, objetos o grafos.
▪ No suelen permitir operaciones JOIN. Al disponer de un volumen de datos tan extremadamente
grande suele resultar deseable evitar los JOIN. Esto se debe a que, cuando la operación no es la
búsqueda de una clave, la sobrecarga puede llegar a ser muy costosa. Las soluciones más
directas consisten en desnormalizar los datos, o bien realizar el JOIN mediante software, en la
capa de aplicación.
▪ Arquitectura distribuida. Las bases de datos relacionales suelen estar centralizadas en una única
máquina o bien en una estructura máster–esclavo, sin embargo en los casos NoSQL la
información puede estar compartida en varias máquinas mediante mecanismos de tablas Hash 30
distribuidas.
BASES DE DATOS NO RELACIONALES NOSQL

TIPOS DE BASES DE DATOS NOSQL

Dependiendo de la forma en la que almacenen la información, nos

podemos encontrar varios tipos distintos de bases de datos NoSQL.
Veamos los tipos más utilizados.

Bases de datos clave – valor

Son el modelo de base de datos NoSQL más popular, además de ser

la más sencilla en cuanto a funcionalidad. En este tipo de sistema,
cada elemento está identificado por una llave única, lo que permite la
recuperación de la información de forma muy rápida, información
que habitualmente está almacenada como un objeto binario (BLOB).
Se caracterizan por ser muy eficientes tanto para las lecturas como
para las escrituras.

Algunos ejemplos de este tipo son Cassandra, BigTable o HBase.

31
BASES DE DATOS NO RELACIONALES NOSQL

Bases de datos documentales

Este tipo almacena la información como un documento,

generalmente utilizando para ello una estructura simple como JSON
o XML y donde se utiliza una clave única para cada registro. Este tipo
de implementación permite, además de realizar búsquedas por
clave–valor, realizar consultas más avanzadas sobre el contenido del
documento.

Son las bases de datos NoSQL más versátiles. Se pueden utilizar en

gran cantidad de proyectos, incluyendo muchos que tradicionalmente
funcionarían sobre bases de datos relacionales.

Algunos ejemplos de este tipo son MongoDB o CouchDB.

32
BASES DE DATOS NO RELACIONALES NOSQL

Bases de datos en grafo

En este tipo de bases de datos, la información se representa como

nodos de un grafo y sus relaciones con las aristas del mismo, de
manera que se puede hacer uso de la teoría de grafos para
recorrerla. Para sacar el máximo rendimiento a este tipo de bases de
datos, su estructura debe estar totalmente normalizada, de forma
que cada tabla tenga una sola columna y cada relación dos.

Este tipo de bases de datos ofrece una navegación más eficiente

entre relaciones que en un modelo relacional.

Algunos ejemplos de este tipo son Neo4j, InfoGrid o Virtuoso.

33
BASES DE DATOS NO RELACIONALES NOSQL

Bases de datos orientadas a objetos

En este tipo, la información se representa mediante objetos, de la

misma forma que son representados enlos lenguajes de
programación orientada a objetos (POO) como ocurre en JAVA, C# o
Visual Basic .NET.

Algunos ejemplos de este tipo de bases de datos son Zope,

Gemstone o Db4o.

34
BASES DE DATOS NO RELACIONALES NOSQL

Ejemplos

35
BASES DE DATOS NO RELACIONALES NOSQL

Algunas de las razones que nos pueden llevar a decantarnos por el uso de las bases de datos
NoSQL en lugar de las clásicas SQL son:

▪ Cuando el volumen de los datos crece muy rápidamente en momentos puntuales, pudiendo
llegar a superar el Terabyte de información.
▪ Cuando la escalabilidad de la solución relacional no es viable tanto a nivel de costes como a
nivel técnico.
▪ Cuando tenemos elevados picos de uso del sistema por parte de los usuarios en múltiples
ocasiones.
▪ Cuando el esquema de la base de datos no es homogéneo, es decir, cuando en cada
inserción de datos la información que se almacena puede tener campos distintos.

36
BASES DE DATOS NO RELACIONALES NOSQL

Grandes compañías que utilizan este tipo de bases de datos:

Son muchas las grandes empresas que hacen uso de este tipo de bases de datos no relacionales,
como:
▪ Cassandra: Facebook, Twitter…
▪ HBase: Yahoo, Adobe…
▪ Redis: Flickr, Instagram, Github…
▪ Neo4j: Infojobs…
▪ MongoDB: FourSquare, SourceForge, CERN…

37
ANÁLISIS DE REQUERIMIENTOS

Para poder arribar con éxito a un buen diseño de Base de Datos es necesario hacer un detallado análisis de los
requerimientos del sistema al cual nos enfrentamos. Pero qué implica exactamente este análisis?

▪ Consiste en especificar lo que se requiere que haga el sistema o la aplicación.

▪ Permite que las personas observen los elementos lógicos separados de los componentes físico. Después de
lo cual se podrá desarrollar un modelo físico eficiente para la situación donde será utilizado.

¿Porque no analizamos requisitos al mismo tiempo que diseñamos e implementamos el sistema ?

La respuesta es que el Diseño e Implementación son mucho más que el análisis (refinamiento y estructuración de
los requisitos) por lo que se requiere una separación de intereses.
▪ El Análisis: prepara y simplifica la siguiente actividad de diseño e implementación, delimitando los temas
que deben resolverse y las decisiones que deben tomarse en esas actividades.
▪ En el Diseño: debemos modelar el sistema y encontrar su forma incluyendo su arquitectura: una forma que
de vida a todos los requisitos incorporados en el sistema.

Es necesario recabar toda la información posible sobre la realidad, para luego analizarla con detenimiento, desde
distintos puntos de vista con el fin de lograr diseñar un modelo que la represente de manera abstracta lo más
fielmente posible.
38
ANÁLISIS DE REQUERIMIENTOS

Debemos efectuarnos algunas preguntas con el fin de analizar nuestro sistema:

¿Qué? ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?

Preguntas básicas y simples que nos permitirán luego realizar otras más puntuales:
▪ ¿Cuáles son los objetos de datos primarios que va a procesar el sistema?
▪ ¿Cuál es la composición de cada uno de estos objetos y qué atributos los describen?
▪ ¿Cuál son las relaciones entre dichos objetos?
▪ ¿Qué Procesos realiza nuestro sistema? ¿Cuándo se realizan? ¿Quién los hace?
▪ ¿Qué intercambio de información existe dentro de los componentes del sistema? ¿Y con el exterior?
▪ ¿Cuáles son los límites del sistema?
▪ ¿Existen excepciones a tener en cuenta para la realización de los procesos?
▪ ¿Cómo se almacena la información actualmente? ¿Qué datos se registran? ¿Quién lo hace?

39
ANÁLISIS DE REQUERIMIENTOS

De allí surgirán:

Entidades
▪ Abstracciones de un objeto del mundo real.
▪ Representación una colección de objetos que tienen propiedades comunes. Ejemplo: CLIENTE
Atributos
▪ Propiedades de una entidad. Ejemplo: Nombre y apellido, edad, dirección, etc.
Relaciones o Flujo de datos
▪ Intercambio de información entre entidades
▪ Representan datos en movimiento lógicamente relacionados.
▪ Describen el movimiento de paquetes de datos de una parte del sistema a otra.
Procesos
▪ Una actividad, tarea, proceso, función, etc.
▪ Transforma entradas en salidas
Almacenes
▪ Colección de datos en reposo.
▪ archivo en disco
▪ datos en un fichero de papel. Ejemplo: una FACTURA

40
ANÁLISIS DE REQUERIMIENTOS

El análisis de requerimientos solicita entendimiento, clasificación, organización, priorización y

validación.
En todo momento debemos considerar los límites del sistema, teniendo en claro cuál es su
objetivo primario ¿Qué es lo que queremos que el sistema haga? ¿Qué salidas de información
queremos obtener? Sólo de esta manera se podrá diferenciar qué de toda la información
recolectada debemos almacenar y cómo deberá ser el diseño que se ajuste a ella.

41
ANÁLISIS DE REQUERIMIENTOS

El análisis de requerimientos solicita entendimiento, clasificación, organización, priorización y

validación.
En todo momento debemos considerar los límites del sistema, teniendo en claro cuál es su
objetivo primario ¿Qué es lo que queremos que el sistema haga? ¿Qué salidas de información
queremos obtener? Sólo de esta manera se podrá diferenciar qué de toda la información
recolectada debemos almacenar y cómo deberá ser el diseño que se ajuste a ella.

42
ELEMENTOS DEL MODELAMIENTO DE BASES DE
DATOS.

Al igual que los arquitectos realizan sus planos para construir casas,
los diseñadores de base de datos necesitan realizar modelos para
construir sus base de datos. Los modelos facilitan la comunicación
entre el diseñador de base de datos y los usuarios finales. Los
modelos son fáciles de utilizar y cambiar, ya que son sólo una imagen
muy simplificada del sistema de información que se desea
desarrollar.

Actualmente en la participación de la construcción del modelo de

datos se involucran muchos actores

43
ELEMENTOS DEL MODELAMIENTO DE BASES DE
DATOS.

Conceptual: esta fase incluye la identificación de las entidades del sistema y

empresariales clave de nivel superior y sus relaciones, que definen el ámbito del
problema que tratará el sistema. Estas entidades clave del sistema y
empresariales se definen mediante la utilización de elementos de modelado del
perfil UML para el modelado empresarial, incluidos los elementos del modelo de
análisis empresarial y el modelo de clase de análisis del modelo de análisis.

Lógica: esta fase incluye el perfeccionamiento de las entidades del sistema y

empresariales de alto nivel de la fase conceptual en entidades lógicas más
detalladas. Estas entidades lógicas y sus relaciones se pueden definir,
opcionalmente, en un modelo lógico de datos mediante la utilización de los
elementos de modelado del perfil UML para el diseño de bases de datos, como se
describe en la Directriz: Modelo de datos. Este modelo lógico de datos forma
parte del Producto de trabajo: Modelo de datos.

Física: esta fase incluye la transformación de los diseños de la clase lógica en

diseños de tablas de bases de datos físicas detalladas y optimizadas. La fase
física también incluye la correlación de los diseños de tablas de base de datos
con espacios de tablas y con el componente de base de datos en el diseño de 44
almacenamiento de bases de datos.
ELEMENTOS DEL MODELAMIENTO DE BASES DE
DATOS.

Los componentes básicos de un MER (Modelo Entidad-Relación) son: Entidades, Atributos y Relaciones. Las
entidades representan abstracciones con atributos que almacenan datos; las relaciones son las asociaciones que
existen entre entidades y permiten generar información al combinar diferentes entidades.

ENTIDAD
Se denomina entidad a todo ente (conceptual o físico) del cual se desea establecer su participación dentro de un
sistema de información. Una entidad concreta o física es aquella con existencia física, representa un objeto del
mundo real (persona o elemento). Unaentidad abstracta no tiene una representación física concreta (posición
laboral, asignatura).

ATRIBUTO
El atributo es elementos de información que caracteriza a una entidad, identificándola, calificándola,
cuantificándola, o declarando su estado. Por lo general una entidad se compone de uno o más atributos (edad,
genero, estatura, nombre, etc.). Los atributos permiten diferenciar elementos dentro de un conjunto de entidades.
Dentro de una entidad de tipo persona es muy raro el caso que existan dos con exactamente los mismos
atributos.

RELACIONES
Las relaciones identifican la interacción que existe entre dos o más entidades. Establecen el coportamiento del 45
sistema de información.
ELEMENTOS DEL MODELAMIENTO DE BASES DE
DATOS.

46
RESTRICCIONES DE INTEGRIDAD.

▪ Son condiciones que garantizan que las modificaciones realizadas en la base de datos por
los usuarios autorizados no den lugar a una pérdida de la consistencia de los datos.
▪ Protegen contra daños accidentales a las bases de datos.

Clave Primaria

La clave principal o primaria proporciona un valor único para cada fila de la tabla y nos sirve de
identificador de registros de forma que con esta clave podamos saber sin ningún tipo de
equivocación el registro al cuál identifica. No podemos definir más de una clave principal, pero
podemos tener una clave principal compuesta por más de un campo. Además, ésta nos
permitirá, en futuras unidades, acceder a los datos de otras tablas.

Por ejemplo, si tenemos una tabla con los datos de contactos de nuestros amigos, podríamos
estar seguros que, usando su número del Documento de Identidad (CI), ninguno de ellos tendría
el mismo valor en dicho campo. En cambio, el campo nombre para nuestros amigos podría
repetirse. 47
RESTRICCIONES DE INTEGRIDAD.

Clave Foránea

Una clave foránea es un campo común y corriente que tiene la particularidad de corresponderse con la
clave primaria de otra tabla, una columna en una tabla que contiene los mismos valores.
Una clave foránea denota la relación entre las dos tablas. Se puede crear una clave foránea en una
columna o un grupo de columnas en una tabla y usarla para hacer referencia a una columna o grupo de
columnas de otra tabla.

Campo Único

Un campo único simplemente no acepta datos repetidos.

Por ejemplo, el campo "email" suele ser único para que tu lista no tenga direcciones de email repetidas
cuando las importes, las añadas manualmente o cuando se den de alta contactos a través de tu
formulario de suscripción.

48
RESTRICCIONES DE INTEGRIDAD.

Campo Nulo

El valor NULL representa a un valor desconocido.

Este valor NULL puede ser asignado como valor a cualquier columna de una tabla.

Si el valor de una columna es opcional, quiere decir, que podemos insertar una fila en la tabla sin
asignarle ningún valor a esa columna opcional, así que esa columna tomará el valor NULL.

49
DIAGRAMA ENTIDAD-RELACION.

El modelo entidad relación es una herramienta que permite representar de manera simplificada los
componentes que participan en un proceso de negocio y el modo en el que estos se relacionan entre sí.

El modelo entidad relación tiene tres elementos principales:

Entidades: El modelo contará con una entidad por cada uno de los componentes del proceso de negocio.
Así, en un negocio de venta de suscripciones a revistas, podemos tener entidades “Cliente”, “Dirección”,
“Factura”, “Producto”, o “Incidencias”, entre otras.
Atributos: Los atributos, componente fundamental de cada modelo entidad-relación, nos permiten
describir las propiedades que tiene cada entidad. “Nombre”, “Primer Apellido”, “Segundo Apellido”, ”Fecha
de nacimiento”, “Género” o “Segmento de valor” serán atributos de la entidad “Cliente”.
Relaciones: Con las relaciones se establecen vínculos entre parejas de entidades. Cada “Cliente” tendrá
una “Dirección” de envío en la que recibirá la suscripción, podrá estar suscrito a uno o varios “Productos”,
y recibirá una “Factura” con la periodicidad acordada.

50
DIAGRAMA ENTIDAD-RELACION.

El diagrama entidad relación es la expresión gráfica del modelo entidad relación. En él las entidades se
representan utilizando rectángulos, los atributos por medio de círculos o elipses y las relaciones como
líneas que conectan las entidades que tienen algún tipo de vínculo. También es muy común el formato
de diagrama en el que los atributos de una entidad aparecen listados en filas dentro del rectángulo que
representa a esa entidad.

Además, es común que, en el modelo entidad-relación, los conectores que indican que dos entidades A y
B están relacionadas entre sí tengan una apariencia gráfica diferente dependiendo del tipo de relación
que exista entre ellas.

51
DIAGRAMA ENTIDAD-RELACION.

Los tipos de relaciones posibles entre dos entidades en un modelo entidad relación son:

▪ Relación uno a uno: Un “individuo” de la entidad A solamente puede estar relacionado con un
“individuo” de la entidad B, y ese “individuo” de la entidad B no puede estar relacionado con otros
“individuos” de la entidad A. Por ejemplo, cada miembro de la entidad País se relaciona únicamente
con un miembro de la entidad “Ciudad capital de un país”. Cada país puede tener una única capital
y cada ciudad capital puede serlo únicamente de un país.
▪ Relación uno a muchos: Un “individuo” de la entidad A puede estar relacionado con uno o varios
“individuos” de la entidad B, y esos “individuos” de la entidad B no pueden estar relacionados con
otros “individuos” de la entidad A. Por ejemplo, cada miembro de la entidad “Padre” puede estar
relacionado con uno o varios miembros de la entidad “Hijo”, y cada miembro de la entidad “Hijo”
solamente puede tener vínculo con un miembro de la entidad “Padre”.
▪ Relación muchos a muchos: Cada “individuo” de la entidad A puede estar relacionado con uno o
varios “individuos” de la entidad B, y cada “individuo” de la entidad B puede estar relacionado con
varios “individuos” de la entidad A. Por ejemplo, cada miembro de la entidad “Cliente” puede estar
relacionado con uno o varios miembros de la entidad “Producto”, y cada miembro de la entidad
“Producto” puede tener vínculo con varios miembros de la entidad “Cliente”.
52
DIAGRAMA ENTIDAD-RELACION.

Ejercicio:

Le contratan para hacer una BD que permita apoyar la gestión de un sistema de

ventas. La empresa necesita llevar un control de proveedores, clientes, productos y
ventas.
Un proveedor tiene un RUC, nombre, dirección, teléfono y página web. Un cliente
también tiene RUC, nombre, dirección, pero puede tener varios teléfonos de
contacto. La dirección se entiende por calle, número, provincia y ciudad.
Un producto tiene un id único, nombre, precio actual, stock y nombre del proveedor.
Además se organizan en categorías, y cada producto va sólo en una categoría. Una
categoría tiene id, nombre y descripción.
Por razones de contabilidad, se debe registrar la información de cada venta con un
id, fecha, cliente, descuento y monto final. Además se debe guardar el precio al
momento de la venta, la cantidad vendida y el monto total por el producto. 53
NORMALIZACION DE BASE DE DATOS.

Es el proceso de organizar los datos de una base de datos. Debemos tener en cuenta
la creación de tablas y las reglas que se usan para definir las relaciones, estas reglas
son diseñadas para proteger los datos, y para que la base de datos sea flexible con
el fin de eliminar redundancias y dependencias incoherentes.

Las bases de datos relacionales se normalizan para:

▪ Evitar la redundancia de los datos.

▪ Disminuir problemas de actualización de los datos en las tablas.
▪ Proteger la integridad de los datos.
▪ Facilitar el acceso e interpretación de los datos.
▪ Reducir el tiempo y complejidad de revisión de las bases de datos.
▪ Optimizar el espacio de almacenamiento.
▪ Prevenir borrados indeseados de datos. 54
NORMALIZACION DE BASE DE DATOS.

Requisitos de la normalización
Para que las tablas de nuestra BD estén normalizadas deben cumplir las siguientes
reglas:

▪ Cada tabla debe tener su nombre único.

▪ No puede haber dos filas iguales.
▪ No se permiten los duplicados.
▪ Todos los datos en una columna deben ser del mismo tipo.

55
NORMALIZACION DE BASE DE DATOS.

Reglas o niveles de normalización

Para normalizar una base de datos existen principalmente 3 reglas, las cuales se
deberían cumplir para evitar redundancias e incoherencias en las dependencias. A
estas reglas se les conoce como "Forma normal" qué va de la 1 a la 3 y si la base de
datos cumple con cada regla se dice que está en la "primera o segunda o tercera
forma normal"

“Aunque son posibles otros niveles de normalización, la tercera forma normal se

considera el máximo nivel necesario para la mayoría de las aplicaciones.”

56
NORMALIZACION DE BASE DE DATOS.

Primera Forma Normal 1FN

Una tabla está en primera forma normal si y sólo si:

▪ No existen filas repetidas.

▪ Todos los atributos son atómicos. Un atributo es atómico si los elementos del
dominio son simples e indivisibles.

57
NORMALIZACION DE BASE DE DATOS.

Consideremos el siguiente ejemplo de una sábana de datos de atención a pacientes

¿Puede identificar su cumple las reglas 1FN?

58
NORMALIZACION DE BASE DE DATOS.

En la siguiente imagen se ve que está mal con la sábana

Las filas en rojo están repetidas, por lo cual es necesario dejar solamente 1 de ellas. Por otro lado,

las celdas en naranjo cuentan con datos divisibles (no atómicos), para arreglar esto se identifica
que estos número y correos están relacionados al rut de una persona por lo que se separan en una
tabla independiente que mantenga una relación con los pacientes.
59
NORMALIZACION DE BASE DE DATOS.

El resultado final de 1FN es:

60
NORMALIZACION DE BASE DE DATOS.

Segunda Forma Normal 2FN

Una tabla está en segunda forma normal si y sólo si:

▪ Cumple con las reglas de 1FN.

▪ Todos los atributos que no forman parte de la Clave Principal tienen dependencia
funcional completa de ella. (Cuando se estable una relación muchos a muchos
(N:M) se genera una relación como tabla adicional. En este caso alumno_curso.)

61
NORMALIZACION DE BASE DE DATOS.

Segunda Forma Normal 2FN

62
NORMALIZACION DE BASE DE DATOS.

Tercera Forma Normal 3FN

Una tabla está en tercera forma normal si y sólo si:

▪ Cumple con las reglas de 2FN.

▪ No existen dependencias transitivas. (Eliminar aquellos campos que no dependan
de la clave. Carrera no depende directamente de la clave primaria en alumnos, por
tanto debe sacarse de la tabla alumnos.)

63
NORMALIZACION DE BASE DE DATOS.

Tercera Forma Normal 3FN

64
DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

DDL son las siglas de: "Data Definition Language" (es decir, Lenguaje de definición de
datos).

Es un lenguaje de programación que los sistemas gestores de bases de datos

implementan para que el usuario pueda realizar el CRUD definiendo así la estructura de
una base de datos donde se almacenarán los datos/información. También permite la
implementación de procedimientos o funciones que permitan al usuario consultar
dichos datos almacenados en la estructura anteriormente creada.

El DDL de SQL, es el más usado entre los gestores de bases de datos.

65
DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

Tipos de datos: Datos para guardar cadenas de caracteres (alfanuméricos)

CHAR
Datos numéricos VARCHAR
TINYINT BINARY
SMALLINT VARBINARY
MEDIUMINT TINYBLOB
INT o INTEGER TINYTEXT
BIGINT BLOB
DECIMAL TEXT
FLOAT MEDIUMBLOB
DOUBLE MEDIUMTEXT
BIT (BOOLEAN): LONGBLOB
LONGTEX
Atributos de los campos ENUM
NULL SET
DEFAULT
BINARY Datos para almacenar fechas y horas
INDEX DATE
PRIMARY KEY DATETIME
AUTO_INCREMENT TIME
UNIQUE TIMESTAMP 66
FULLTEXT YEAR
DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

Los elementos que conforman el "Lenguaje de definición de datos" son los siguientes:

CREATE:

Permite crear una nueva base de datos, tablas, índices o procedimientos almacenados.

DROP:

Se utiliza para borrar rápidamente y eficazmente bases de datos, índices,

procedimientos almacenados y demás.

ALTER:

Nos permite insertar, eliminar o actualizar columnas en una tabla ya existente. 67

DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

Ejemplo de CREATE:
CREATE DATABASE [nombre]
CREATE TABLE [tabla] (columna tipo-de-dato(10), columna tipo-de-dato(10));
CREATE TABLE usuarios (nombre varchar(25), apellidos (25));

CREATE TABLE Persons (

ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
CONSTRAINT PK_Person PRIMARY KEY (ID,LastName)
);

CREATE TABLE Orders (

OrderID int NOT NULL,
OrderNumber int NOT NULL,
PersonID int,
PRIMARY KEY (OrderID),
CONSTRAINT FK_PersonOrder FOREIGN KEY (PersonID)
68
REFERENCES Persons(PersonID)
);
DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

Ejemplos de DROP:

DROP DATABASE nombre;

DROP TABLE usuarios;
DROP SEQUENCE secuencia1;
DROP INDEX índice1;

69
DDL (LENGUAJE DE DEFINICIÓN DE DATOS)

Ejemplo de ALTER: Modificar clave foranea

ALTER TABLE Orders

Agregar una nueva columna en la tabla: ADD FOREIGN KEY (PersonID) REFERENCES
ALTER TABLE usuarios ADD email varchar(20); Persons(PersonID);

Renombrar una columna ya creada de nuestra tabla: ALTER TABLE Orders

ALTER TABLE usuarios CHANGE email correo varchar(50); ADD CONSTRAINT FK_PersonOrder
FOREIGN KEY (PersonID) REFERENCES Persons(PersonID);
Modificar el tipo de dato de la columna de nuestra tabla:
ALTER TABLE usuarios MODIFY correo varchar(30);

Eliminar una columna de nuestra tabla:

ALTER TABLE usuarios DROP COLUMN correo;

Agregar clave primaria

ALTER TABLE Persons
ADD CONSTRAINT PK_Person PRIMARY KEY (ID,LastName);

Eliminar clave primaria

ALTER TABLE Persons 70
DROP CONSTRAINT PK_Person;
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Lenguaje de Manipulación de Datos (Data Manipulation Language, DML) es un idioma

proporcionado por los sistemas gestores de bases de datos que permite a los usuarios
de la misma llevar a cabo las tareas de consulta o modificación de los datos
contenidos en las Bases de Datos del Sistema Gestor de Bases de Datos. El lenguaje
de manipulación de datos más popular hoy día es SQL, usado para recuperar y
manipular datos en una base de datos relacional.

Elementos del lenguaje de manipulación de datos

▪ Select
▪ Insert
▪ Delete
▪ Update
71
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

INSERT
Una sentencia INSERT de SQL agrega uno o más registros a una (y sólo una) tabla en
una base de datos relacional.

Forma básica:

INSERT INTO tabla(campos) VALUES (valores)

INSERT INTO tabla VALUES (valores)

Ejemplo:

INSERT INTO cursada (alumno, materia) VALUES (''pepe'', ''spd2‘’)

INSERT INTO cursada VALUES (''pepe'', ''spd2'')
72
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

DELETE
Una sentencia DELETE de SQL borra uno o más registros existentes en una tabla.

Forma básica:

DELETE FROM tabla WHERE columna1 = valor1

Ejemplo:

DELETE FROM My_table WHERE field2 = 'N';

73
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

UPDATE
Una sentencia UPDATE de SQL es utilizada para modificar los valores de un conjunto
de registros existentes en una tabla.

Forma básica:

UPDATE tabla SET campo1 = 'valor1’, campo2 = 'valor2’ WHERE campo2 = 'N';

Ejemplo:

UPDATE mi_tabla SET campo1 = 'nuevo valor campo1' WHERE campo2 = 'N';

74
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Consultas

Las consultas de selección se utilizan para indicar al motor de datos que devuelva
información de las bases de datos, esta información es devuelta en forma de conjunto
de registros. Este conjunto de registros es modificable.

Básicas
La sintaxis básica de una consulta de selección es:

SELECT * FROM Tabla;

SELECT Campos FROM Tabla;
SELECT Nombre, Telefono FROM Clientes;

75
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Clausula WHERE

La cláusula WHERE puede usarse para determinar qué registros de las tablas
enumeradas en la cláusula FROM aparecerán en los resultados de la instrucción SELECT.
WHERE es opcional, pero cuando aparece debe ir a continuación de FROM:

SELECT Apellidos, Salario FROM Empleados WHERE Salario > 21000;

SELECT Id_Producto, Existencias FROM Productos WHERE Existencias <= Nuevo_Pedido;

76
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Operadores Lógicos
Los operadores lógicos soportados por SQL son:

AND, OR, XOR, Eqv, Imp, Is y Not.

A excepción de los dos últimos todos poseen la siguiente sintaxis:

<expresión1> operador <expresión2>

En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado de la
operación varía en función del operador lógico:

# SELECT * FROM Empleados WHERE Edad > 25 AND Edad < 50;
# SELECT * FROM Empleados WHERE (Edad > 25 AND Edad < 50) OR Sueldo = 100;
# SELECT * FROM Empleados WHERE NOT Estado = 'Soltero';
# SELECT * FROM Empleados WHERE (Sueldo > 100 AND Sueldo < 500) OR (Provincia = 77
'Madrid' AND Estado = 'Casado');
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Operador BETWEEN
Para indicar que deseamos recuperar los registros según el intervalo de valores de un
campo emplearemos el operador Between:

# SELECT * FROM Pedidos WHERE CodPostal Between 28000 And 28999;

(Devuelve los pedidos realizados en la provincia de Madrid)

# SELECT IIf(CodPostal Between 28000 And 28999, 'Provincial', 'Nacional') FROM

Editores;
(Devuelve el valor 'Provincial' si el código postal se encuentra en el intervalo,'Nacional' en
caso contrario)

78
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

Operador LIKE
Se utiliza para comparar una expresión de cadena con un modelo en una expresión SQL.
Su sintaxis es:

expresión LIKE modelo

Operador IN
Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de
los indicados en una lista. Su sintaxis es:

expresión [Not] In(valor1, valor2, . . .)

# SELECT * FROM Pedidos WHERE Provincia In ('Madrid', 'Barcelona', 'Sevilla');

79
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo
especificado de una consulta:

Avg(expr)
La función Avg no incluye ningún campo Null en el cálculo. Un ejemplo del
funcionamiento de AVG:

# SELECT Avg(Gastos) AS Promedio FROM

Pedidos WHERE Gastos > 100;

80
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

MAX, MIN
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo
especifico de una consulta. Su sintaxis es:

Min(expr)
Max(expr)
Un ejemplo de su uso:

# SELECT Min(Gastos) AS ElMin FROM Pedidos

WHERE Pais = 'Costa Rica';
# SELECT Max(Gastos) AS ElMax FROM Pedidos
WHERE Pais = 'Costa Rica';

81
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

SUM
Devuelve la suma del conjunto de valores contenido en un campo especifico de una
consulta. Su sintaxis es:

Sum(expr)
Por ejemplo:

# SELECT Sum(PrecioUnidad * Cantidad)

AS Total FROM DetallePedido;

82
DML (LENGUAJE DE MANIPULACIÓN DE DATOS)

GROUP BY
Combina los registros con valores idénticos, en la lista de campos especificados, en un único registro:

# SELECT campos FROM tabla WHERE criterio

GROUP BY campos del grupo
Todos los campos de la lista de campos de SELECT deben o bien incluirse en la cláusula GROUP BY o
como argumentos de una función SQL agregada:

# SELECT Id_Familia, Sum(Stock)

FROM Productos GROUP BY Id_Familia;
HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los registros se
han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a mostrar.

# SELECT Id_Familia Sum(Stock) FROM Productos GROUP BY Id_Familia HAVING Sum(Stock) > 100
AND NombreProducto Like BOS*;
83