Capítulo 4

4. Base de datos
A/P Gabriella Savoia, MsC.,PMP
Sistemas de Bases de datos
Bibliografía: Sistemas de Bases de Datos (Conceptos fundamentales) ELMASRI/NAVATHE
Una base de datos es...
• La representación de un aspecto del mundo real.
• Una colección de datos
– lógicamente coherentes,
– con algún significado inherente.
• Diseñada, construída y poblada de datos con algún fin específico.
• De interés para
– algún grupo de usuarios,
– algunas aplicaciones concebidas.
• Es un conjunto de datos relacionados entre sí.
Definición
Un sistema de base de datos es el conjunto formado por la base de datos y el software
para la manipulación (SGBD).
Construir una BD es...
El proceso de guardar los datos en algún medio de almacenamiento controlado por el
SGBD.
Manipular una BD es...
• Obtener datos específicos a través de una consulta.
• Modificar datos, es decir: agregar, modificar o borrar datos de una BD.
Base de datos
209
A tener en cuenta…
Para definir una base de datos hay que especificar los tipos, las estructuras y las restricciones de datos que se almacenarán en ella. Construir una base de datos es el proceso de guardar
los datos en algún medio controlado por el sistema de gestión de base de datos.
Evitando…
• La inconsistencia de los datos.
• La dificultad para acceso a la información.
• El aislamiento de los datos.
Brindando…
• Control de la concurrencia.
• Seguridad de los datos.
Aportes del uso de tecnologías de Base de Datos
Desde el punto de vista de la organización de la información permite, de los datos:
• Mantener una definición central.
• Manejar abstracción.
• Manejar múltiples vistas.
Desde el punto de vista de la programación de la base de datos:
• Separación entre datos y programas.
• Control de restricciones de integridad y concurrencia.
• Estandarización de modelos y lenguajes.
Base de datos
Los sistemas de bases de datos engloban:
210
• Modelo de datos.
• Arquitectura de los SGBD.
• Lenguajes de los SGBD.
• Clasificación de los SGBD.
• Funciones de los SGBD.
• Componentes de los SGBD.
¿Qué es un Modelo de Datos ?
Conjunto de conceptos que sirven para describir la estructura de una base de datos.
La estructura de una base de datos contiene:
• Tipos de datos.
• Vínculos/Relaciones.
• Restricciones de Consistencia.
Categorías de Modelo de Datos
Se reconocen modelos:
De alto nivel o conceptuales
• Describen cómo los percibe el usuario y manejan conceptos de:
• Entidad.
• Atributo.
• Vínculo.
De Representación o Implementación
• Basados en registros, orientados a objetos.
Fases en el diseño de Bases de Datos
Base de datos
De Bajo Nivel o Físicos
• Describen cómo se almacenan los datos en el computador.
211
Análisis de requerimientos
• Descripción operacional.
• Fase de adquisición de conocimiento.
• Entrevistas con los usuarios del sistema.
• Identificación de necesidades.
• Asegurar que se tengan los datos necesarios para las funciones y aplicaciones donde se
usará la BD.
• Salida: requerimientos del sistema.
Base de datos
Diseño Conceptual (Modelo Conceptual)
212
• Los modelos conceptuales:
- Modelos de datos de muy alto nivel.
- En general, se concentran en estructuras y restricciones de integridad. Se concentran en definir el dominio del problema.
- Suelen tener una representación gráfica asociada.
• Algunos modelos conceptuales
- Modelo Entidad-Relación [1976].
- Modelos ER Extendidos [‘80s y ‘90s].
Diseño Lógico
• Diseño que se acerca más a la implementación en un Sistema Manejador de Base de
Datos.
• Transforma el modelo Entidad-Relación en tablas que podrán ser implementadas en un
un sistema manejador de base de datos particular.
• Se eliminan ciertas anomalías debidas a la redundancia. Normalización.
Diseño Físico
• Decide la estructura de almacenamiento y las estrategias de acceso.
- Estructura de almacenamiento: Archivos planos, comprimidos, codificados y formatos
específicos.
- Estrategia de acceso: Acceso secuencial, acceso binario y acceso usando Btress.
• Generalmente se reduce a la selección de los INDICES para acelerar el acceso. También
selecciona los tipos de datos.
Base de datos
213
Modelo de datos conceptual
Modelado de datos
• Los modelos de datos son herramientas para describir la realidad.
• Los programadores utilizan los modelos de datos para construir esquemas.
• La calidad de los esquemas resultantes depende, no solamente de la habilidad de los
programadores sino también de las características del modelo de datos seleccionado.
• Es común a todos los modelos de datos los “mecanismos de abstracción de la realidad”
que ayudan a entender, clasificar y modelar la realidad.
Abstracciones en el diseño conceptual
• La abstracción es un proceso mental que se aplica al seleccionar algunas características
y propiedades de un conjunto de objetos y excluir otras no tan importantes.
• En otras palabras, se hace una abstracción al fijar la atención en las propiedades consideradas esenciales de un conjunto de cosas y desechar sus diferencias.
• En el diseño conceptual se utilizan tres tipos de abstracciones:
1. Clasificación.
2. Agregación.
3. Generalización.
Base de datos
Clasificación
214
Se usa para definir un concepto como una clase de objetos de la realidad caracterizados
por propiedades comunes.
Ejemplo:
El concepto de MES es la clase cuyos miembros son Enero, Febrero..., Diciembre.
Cuando se piensa en un mes se hace una abstracción de las características específicas de
cada mes (por ejemplo, número de días) y se destacan los aspectos comunes de todos los
meses.
Un mismo objeto real puede clasificarse de varias maneras.
Por ejemplo, consideremos los siguientes grupos de objetos:
- silla negra
- mesa negra
- silla blanca
- mesa blanca
Se pueden clasificar los objetos anteriores como MESAS y SILLAS o considerar, en cambio, su color y clasificarlos como MUEBLES BLANCOS y MUEBLES NEGROS.
Agregación
Define una nueva clase a partir de un conjunto de otras clases que representan sus partes
componentes.
Ejemplo: Abstraer la clase PERSONAS a partir de las clases Nombre, Sexo, Domicilio.
Generalización
Define una relación de subconjunto entre los elementos de dos o más clases.
Ejemplo: La clase PERSONA es una generalización de las clases HOMBRE y MUJER.
Modelo Entidad Relación
Entidades
• Las entidades representan clases de objetos de la realidad.
• PERSONA, HOMBRE, MUJER, EMPLEADO y CUIDAD son ejemplos de entidades para una base de datos de PERSONAL.
• En el MER las entidades se representan gráficamente por medio de un rectángulo.
EMPLEADOS
SECCIONES
Base de datos
• En 1976 se publicó el modelo entidad relación, el cual tuvo gran aceptación, principalmente por su expresividad gráfica.
• Sobre esta primera versión han trabajado numerosos autores, generando distintas extensiones de mayor o menor utilidad y de aceptación variable en el medio académico y profesional.
• Muchas de estas extensiones son muy útiles pero poco difundidas, debido principalmente a la ausencia de herramientas automatizadas que apoyen su uso.
• A continuación se definen los elementos del modelo entidad relación básico.
215
Atributos simples de entidades
A cada entidad se le asocia la información que deseamos “almacenar” sobre ella. A esta
información se las denomina atributos de la entidad.
Atributos compuestos
Frecuentemente vamos a representar atributos que pueden estar compuestos de subatributos. Por ejemplo, el domicilio de los funcionarios podría formarse con el país, cuidad y
calle donde viven.
Atributos determinantes (claves)
Base de datos
Los atributos determinantes de una entidad son un grupo de atributos que tienen la propiedad de identificar en forma única todos los casos de una entidad. Los representaremos
gráficamente subrayando el atributo.
216
Cardinalidad de los atributos
Los atributos se caracterizan por su cardinalidad mínima y máxima.
La cardinalidad mínima indica el número mínimo de valores de atributos asociados con
cada caso de entidad.
Si la cardinalidad mínima de un atributo es 0 significa que el atributo es opcional y puede estar no especificado (nulo) en algunos casos de la entidad.
Si, por el contrario, la cardinalidad es 1, el atributo es obligatorio y al menos un valor del
atributo debe especificarse para todos los casos de la entidad.
La cardinalidad máxima indica el número máximo de valores de atributos asociados
con cada entidad.
Si la cardinalidad máxima de un atributo es 1, entonces el atributo es monovaluado; si
la cardinalidad máxima es mayor a 1, entonces el atributo es multivaluado y se representa
gráficamente con un asterisco (*) al lado del atributo.
Categorías de entidades
En muchos casos prácticos las entidades representan a elementos del mundo real que se
subdividen en categorías con atributos en parte distintos.
Conjunto (o tipo) de entidades
Ejemplo:
COMPAÑÍA (Nombre, Ubicación, Presidente).
EMPLEADO (Nombre, Edad, Salario).
Atributos clave:
Dominio de los atributos
(ej. Edad del empleado entre 18 y 80 años)
Base de datos
Ejemplo: Base de datos COMPAÑÍA
217
Relaciones entre entidades
Una relación binaria es una correspondencia que se establece entre dos entidades. Las
relaciones se representan gráficamente por rombos y se les asigna un nombre significativo.
Clases de relaciones
Clase 1 a N
Una relación de clase de 1 a N, o 1:N, o de uno a muchos se puede ver en la siguiente
figura, en donde se expresa que cada empleado trabaja en una única sección o que en cada
sección trabajan varios empleados.
Base de datos
Clase 1 a 1
Una relación de clase de 1 a 1 se puede ver en la siguiente figura, en donde se expresa que
cada sección tiene un único empleado (jefe) a cargo.
218
Clase N a N
Una relación de clase de N a N se puede ver en la siguiente figura, donde se expresa que
cada empleado puede estar asignado en varias secciones a la vez y que cada proyecto esta
formado por varios empleados.
Clase c a N
Se puede colocar una constante numérica en vez de la “N” cuando se desee expresar que
hay ciertas restricciones de cardinalidad conocidas de antemano. Por ejemplo, si sabemos que
un empleado no puede trabajar en más de tres secciones a la vez.
Relaciones totales
Una restricción muy común e importante en el modelado de casos prácticos impone que
todas las entidades de un conjunto de entidades E aparezcan obligatoriamente en un conjunto de relaciones R. En estos casos se dice que la relación R es total en E. Cuando una relación
no es total se dice que es parcial
Relaciones parciales
Un empleado trabaja en una sección, no puede haber empleados que no estén asignados
a alguna sección.
Atributos de relaciones
En muchos casos prácticos se tienen atributos que no dependen de una única entidad
sino de la relación existente entre conjuntos de entidades.
Base de datos
El 0 indica que un cliente puede o no poseer tarjeta. Puede haber clientes que no tengan
tarjeta.
219
Relación recursiva (autorrelación)
Una relación recursiva es una relación binaria que conecta una entidad consigo misma.
Para distinguir entre los dos papeles de la entidad en la relación se asocian dos rótulos con la
entidad. En el ejemplo los dos rótulos son Mandar y Es mandado.
Relación de grado mayor a 2
Son relaciones que conectan más de dos entidades.
La relación DICTA es una relación ternaria que une las entidades INSTRUCTOR, SEMESTRE y CURSOS.
Base de datos
Tipos de entidades
Las entidades pueden ser de dos tipos:
Entidad fuerte: aquella sobre la que se puede definir la clave primaria dentro de sus
propios atributos.
Entidad débil: aquellas que no puede utilizar sus propios atributos como clave al estar
asociada a otra entidad.
220
Agregaciones
Un banco trabaja con clientes que pueden tener varias cuentas corrientes. A pedido de los
clientes y bajo ciertos requisitos el banco les otorga tarjetas magnéticas para ser usadas en sus
cajeros automáticos. Una primera aproximación del MER sería la siguiente:
Este esquema establece que se emite una tarjeta por cada cuenta que tenga cada cliente:
A tales efectos, se debería considerar a las parejas (cliente, cuenta) como un conjunto de
entidades que se vinculan con las entidades del conjunto de tarjetas. Para ello se encierra a
los conjuntos Clientes, Cuentas, y la relación entre ellos, en un nuevo rectángulo que se va a
comportar como un nuevo conjunto de entidades. A esto se lo denomina Agregación. Los
elementos de esta agregación se relacionan con las tarjetas.
Ejemplo:
Se desea modelar una base de datos de una empresa de insumos de computación mediante MER.
La realidad de la empresa es la siguiente:
• La empresa tiene clientes cuyos datos son su número de cliente, nombre dirección y
teléfonos. La dirección se forma de un domicilio, ciudad y código postal.
• Los clientes hacen pedidos de compra. Cada pedido de un cliente hace referencia a un
conjunto de artículos en stock. Para cada artículo que hay en un pedido se indica la cantidad
unitaria pedida. Los pedidos tienen un número identificatorio, una fecha de envío y una tasa
de envío. Todos los pedidos tienen un monto total.
• Los artículos se identifican por un número y el código del fabricante, es decir, un mismo
artículo puede ser producido por varios fabricantes. De cada artículo se tiene su descripción
y su precio unitarios. Este precio depende el artículo en sí y del fabricante del mismo.
• Los fabricantes tienen un código y un nombre.
Base de datos
221
Modelo de datos relacional
Definiciones
Proceso de Diseño
Secuencia de pasos mediante la cual se pasa de un Concepto a una Base de Datos física
(implementación).
Niveles de Abstracción
Base de datos
Esquemas e Instancias
222
Esquema: Definición de las estructuras de la Base de Datos.
• = Entidades + Relaciones realmente implementados.
• No cambian a menudo.
• Se administran con DDL.
Instancia: Una configuración tomada en un cierto instante del tiempo del contenido de
la Base de Datos.
• Cambian constantemente.
• Manipuladas mediante el DML.
Un esquema permite generar una secuencia ilimitada de instancias.
El Modelo Relacional
Base de datos
223
Base de datos
Operaciones
224
Vistas
Pasaje MER - Relacional
Proceso de transformación de un concepto a una implementación:
• Entidades fuertes y Atributos
• Relaciones
• Agregaciones
• Entidades Débiles
• Categorizaciones
No existe un pasaje totalmente automatizado:
• Restricciones no-estructurales requieren implementación no-estructural (codificación
de programas).
Puede hacerse mediante software, pero:
• Puede depender de cada DBMS particular.
• Para mantener la correspondencia Modelo Conceptual – Modelo Físico deberíamos
utilizar siempre el mismo software, siempre y cuando soporte Ingeniería Reversa.
Todo buen esquema relacional debe:
1. Reflejar restricciones de la realidad.
2. No permitir inconsistencias o ambigüedades.
3. No imponer más restricciones que las de la especificación.
4. Carecer de redundancia.
(en ciertos casos, se admite siempre y cuando esté controlada.)
Otros objetivos deseables:
1. Minimizar restricciones no-estructurales, porque:
• Exigen crear código.
• Dificultan la comprensión del esquema.
2. Diseño correspondiente SIEMPRE con la implementación.
3. Diseño anticipado al cambio (generalizar).
Pasaje – Entidades Fuertes
Base de datos
• Cada atributo común se coloca como un atributo de la tabla.
• Atributos compuestos se colocan como un atributo separado por cada hoja.
• Atributos claves se colocan como subrayados (puede ser clave compuesta).
225
• Atributos multivaluados generan una nueva tabla:
1. Contiene un atributo por cada componente (similar a caso anterior).
2. Debe contener, además, la clave de la Entidad.
3. La clave es toda la tabla.
Pasaje – Relaciones
• Por regla general, se debe crear una nueva tabla conteniendo las claves de las entidades
que relaciona.
• Si contienen atributos propios se deben incluir.
• La clave dependerá de restricciones de la realidad. Por lo general, será la pareja de claves
de ambas entidades.
Base de datos
Ejemplo 1: (relación N:M, un alumno se puede inscribir a una materia varias veces).
226
Ejemplo 2: Un alumno se puede inscribir a una materia, pero una sola vez en para cada
fecha.
• Si la relación es 1:N puede NO CREARSE nueva tabla.
Se “incrustan” la clave (y atributos) en la entidad con cardinalidad N.
• Si contiene atributos propios es mejor crearla.
• Si la relación es PARCIAL sobre B, cuando un elemento de B no esté relacionado con
alguno de A Clave_a contendrá NULL.
• Si la relación es TOTAL sobre B, se debe definir una restricción de integridad (referencial) de B hacia A.
Ejemplo 1: Un empleado trabaja en una única sección.
Ejemplo 2: Un empleado trabaja en una única sección en un determinado período.
Mínimos y máximos definidos
• Cuando existen mínimos > 1, o cotas superiores, no se pueden definir mediante restricciones estáticas.
• Deben ser definidas por código. Ej: triggers.
• Se tratan como una relación.
• Independientemente de las cardinalidades se debe implementar como una tabla aparte
(pues van a ser nuevamente relacionadas con alguna otra Entidad).
Pasaje – Entidades Débiles
• Son casos particulares de relación 1:N.
• No se crea tabla adicional para la relación.
• Se agrega en la tabla correspondiente a la Entidad Débil la clave de la Entidad Fuerte.
• La nueva clave está formada entonces por este nuevo conjunto.
• Debe haber una clave foránea desde la Entidad Débil a la Fuerte.
Base de datos
Pasaje – Agregaciones
227
CLAVE FORÁNEA
Se dice que B posee clave foránea hacia A si todo elemento de tabla B debe tener su atributo clave dentro de un atributo clave de alguna tupla de tabla A.
Decimos que Fk(B) referencia Pk(A) y Pk(B) = Fk(B).
En nuestro ejemplo:
Toda tupla de SALAS debe tener una pareja <NomHosp, NroSala> en alguna tupla de
HOSPITALES con el mismo NomHosp.
Además:
NomHosp debe ser CLAVE en HOSPITALES.
NomHosp,NroSala es CLAVE en SALAS.
Base de datos
Pasaje – Categorizaciones
228
Existen diferentes implementaciones, dependiendo de la cantidad de atributos, solapamiento y completitud.
Caso 1: Relación No-total y C posee atributos propios.
1. Crear una tabla para C.
2. Crear una tabla para cada sub-categoría Si conteniendo sus atributos propios +
Clave(C).
3. Crear restricciones de integridad desde cada clave de Si a C.
Caso 2: Relación No-total y C no posee atributos propios (solo clave).
1. Crear una tabla para cada sub-categoría Si conteniendo sus atributos propios +
Clave(C).
2. No es necesario crear C pues es una abstracción.
C se puede implementar como una vista:
Caso 3: Relación Total y sub-categorias SIN atributos propios.
• Crear una tabla para C.
• Dos variantes :
a) Agregar a C un atributo para discriminante que indica la categoria a que pertenece cada
tupla.
b) Agregar a C tantos atributos booleanos como sub-categorias de C existan.
Ejemplo:
Base de datos
229
Ventajas y Desventajas:
Versión 1:
No permite implementar solapamiento (desventaja).
Permite fácil agregado de nuevas sub-categorías (ventaja).
Versión 2:
Permite solapamiento (ventaja).
Agregar nueva sub-categoría implica modificar esquema de Supertipo (desventaja).
Base de datos
Caso 4: Si todas las categorías poseen atributos propios.
Opción 1:
Implementar una única tabla conteniendo la unión de todos los atributos de C + Si utilizando una de las dos técnicas de caso anterior (tener en cuenta si hay o no solapamiento).
• Rápido de implementar.
• Genera gran cantidad de datos NULL.
• Exige correspondiencia entre atributos : implementar código.
Ej: Si Tipo=“ADMINISTRATIVO” (atributos que no correspondan a ADMINISTRATIVO deben valer NULL o ser ignorados).
• Implementación obscura, lejana de modelo conceptual.
Ej: (sin solapamiento).
230
Caso 4: Si todas las categorías poseen atributos propios.
Opción 2:
a) No implementar C.
b) Implementar cada subcategoria Si como una tabla independiente conteniendo sus atributos + atributos de C.
• Cubre solapamiento y totalidad.
• Fácil de implementar.
• Más prolijo que la versión anterior.
• Puede generar redundancia.
Ej: Si Ana es Docente y también Administrativo.
Caso 4: Si todas las categorías poseen atributos propios.
Opción 3:
a) Implementar C como una tabla independiente.
b) Implementar cada subcategoría Si como una tabla independiente + Clave( C ).
c) Incluir restricciones de integridad desde Si hacia C.
• Cubre solapamiento y totalidad.
• Luego se pueden definir vistas de cada Si para presentar una visión más cercana a la
conceptual.
Base de datos
• Evita redundancia.
• Prolijidad: más cercano al diseño conceptual.
• Exige más “inteligencia” para agregar registros.
• Costo de implementar/mantener las vistas.
231
Introducción
DBMS
Caso de estudio: Sistema de alquiler de Vehículos sin conductor.
1 – Tenemos las clases claras.
2 – Tenemos la implementación hecha.
3 – ¿Dónde almacenamos los datos?
Respuesta posible: archivos de texto
Arquitectura:
Problema 1: ¿Dónde almacenamos cada “Entidad” del mundo real?
Respuestas posibles:
1) Cada Clase en un archivo.
2) Todas las clases en un solo archivo.
3) Si una clase es muy compleja repartirla en
dos archivos.
ej. Factura = Cabezal + Detalle.
Base de datos
Problema 2: ¿Cómo se llamarán y dónde se ubicará cada archivo?
Respuestas posibles:
1) El mismo nombre de cada clase.
2) En un directorio por sub-módulo o uno para cada clase.
3) En un único directorio relativo a la aplicación.
232
Problema 3: ¿Quién tendrá derechos sobre qué parte de los datos?
Respuestas posibles:
1) Defino grupos y para cada uno defino derechos sobre:
directorios/carpetas/archivos.
2) Lo administro por programa, y cuando la aplicación lee un archivo chequea la
integridad de los datos.
¿Qué sucede si alguien altera un archivo?
¿Si tengo una instancia del programa en cada PC, cómo controlo el acceso simultáneo?
Problema 4: Si necesito alterar un dato en mis archivos, ¿cómo lo hago?
Respuestas posibles:
1) Se necesita saber la estructura, solo viendo la fuente de la aplicación.
2) No cualquier combinación de datos es válida
3) Altísima probabilidad de error humano: Copy&Paste indeseado, Save indeseado.
DBMS - Definición
DataBase Management System
Es un conjunto de programas que permiten crear, mantener y consultar bases de datos.
Es un sistema de software de uso general que facilita los procesos de:
• Definición (de una base de datos).
• Construcción.
• Manipulación.
Es UNIFICADO, ESTANDARIZADO, con API COMUNES (para todos los lenguajes), TRANSPARENTA todas las operaciones de forma de ocultar su implementación tanto
para los usuarios como para los lenguajes.
DBMS - Ventajas frente a Archivos
Procesamiento de archivos
• Cada usuario define sus archivos de datos.
• Cada usuario define sus programas de acceso a los datos.
• Seguridad extremadamente vulnerable.
• Interpretación de los datos dependen del programa
.
DBMSs
• Archivos de datos centralizados.
• Control de acceso centralizado e independiente del Sistema Operativo.
Componentes del DBMS (alto nivel)
Base de datos
233
Características del DBMS
Auto-descripción.
• Catálogos del sistema.
• Reglas de integridad.
Independencia y abstracción.
• Independencia programa-datos.
• Independencia programa-operaciones del DBMS.
• Set de operaciones, desconocemos como se implementan.
Múltiples vistas.
• Permiten implementar Datos virtuales (no duplican espacio).
Datos compartidos y transacciones multiusuario.
• Control de concurrencia.
• Integridad transaccional.
Funcionalidades de DBMS
Brindan como mínimo los siguientes servicios:
Base de datos
• Almacenamiento (persistente) de los datos.
• Acceso eficiente a los datos: Índices.
• Descripción centralizada de la BD.
• Lenguajes de alto nivel (SQL) y optimización de consultas.
• Facilidad para administrar estructuras (DDL).
• Acceso de múltiples usuarios a una BD:
Controles de Seguridad.
Controles de Concurrencia.
• Recuperación de la BD en caso de fallas:
Operaciones de BackUp y Restore.
234
Conceptos y Generalidades
Todo DBMS debe contener un catálogo inicial de donde lee los elementos que lo
componen (Bases de Datos del sistema o inicial, Base de Datos de usuario y otros archivos
necesarios).
El catálogo puede ser:
Una base inicial, administrada por el propio DBMS.
Un archivo de configuración.
Una base inicial + sub-catálogos dentro de cada Base de Datos (implementados todos
como TABLAS).
El DBMS es un programa que corre como un Servicio (Windows) o iniciado en el servidor al startup (Unix, Solaris, Linux, etc).
Los otros módulos componentes serán programas independientes. Ej. Servidor de Backup, Monitor de Performance, Auditorías.
Módulos que lo componen
Para proveer las funcionalidades vistas antes, un DBMS debe incluir módulos que resuelvan diferentes problemas:
1.
2.
3.
4.
5.
6.
Compiladores de DDL, DML y QL.
Manejador de datos físicos almacenados (MOTOR).
Runtime para aplicaciones.
Incluye subsistema de control de concurrencia.
Subsistema de respaldo.
Subsistema de recuperación.
1 - Manejador de datos físicos almacenados (MOTOR)
• Accede al catálogo y datos.
• Controla el uso de buffers (“memoria cache”).
• Utiliza servicios de E/S del sistema operativo.
• Manejo de la memoria (vía sistema operativo).
3 - Procesador de runtime (INTERNO)
• Maneja accesos a la BD en tiempo de ejecución.
• Recibe operaciones de consulta o actualización.
• Accede a los datos a través del Motor de almacenamiento.
• Manejo de concurrencia.
• Manejo de threads o procesos (vía S.O.).
• Administración de permisos.
4 - Compilador del lenguaje de consulta: Query Language (QL)
• Maneja las consultas interactivas de alto nivel.
• Analiza sintáctica y semánticamente cada consulta.
• Ejecuta la consulta a través del procesador de runtime.
Base de datos
2 - Compilador de Data Definition Language (DDL)
• Procesa las definiciones del esquema conceptual.
• Almacena las definiciones en el catálogo.
235
5 - Precompilador
• Extrae comandos de manipulación embebidos en un lenguaje de programación host.
• Los envía al compilador del DML.
• El código objeto generado es linkeditado con el código objeto del lenguaje de programación.
Otros componentes
• Compiladores de lenguajes de desarrollo (C, C++, Cobol, Pascal, etc).
• Interfaces gráficas de consulta.
• Utilitarios de administración:
- Exportación/importación de datos.
- Herramientas de respaldo.
- Reorganizadores de archivos.
- Monitoreo de performance.
- Sistema de manejo del diccionario de datos.
• Facilidades de comunicación:
- Comunicación remota (x ej. entre servidores).
- Arquitectura cliente/servidor.
Base de datos
Clasificación de DBMSs
236
Según el modelo de datos
• Relacional.
• De red.
• Jerárquico.
• Orientado a objetos.
• Hoy: Híbridos Relacional/OO/XML.
Según la distribución de datos
• Centralizados (programas y datos en el mismo pc).
• Distribuídos (programas y datos en distintos pc):
- Homogéneos (mismos programas en cada sitio).
- Heterogéneos (distintos programas en cada sitio).
- Federados (varios DBMSs distintos).
Algunos ejemplos (relacionales)
Open Source
• MySQL (última versión 5.1)
• PostgreSQL (última versión 8.4)
• Etc.
Propietarios
• SQL-Server (Microsoft, última versión 2008).
• Access (Microsoft).
• Oracle (Oracle).
• Sybase ASE (Sybase Inc.).
• Informix (Informix, a partir de 2001 IBM).
• DB2 (IBM).
Seguridad - Conceptos
• Todo acceso a bases de datos debe ser controlado.
• Todo DBMS trae incorporado un usuario administrador (root, sa, sysadmin, etc.).
• Luego se definen usuarios o grupos de usuarios a los que se les otorgan derechos
sobre objetos.
• El control de accesos más normal es el basado en las tareas de Asignar/Revocar privilegios.
Dos niveles clásicos de asignación de privilegios:
• Por Usuario: Privilegios particulares de un usuario de la BD.
• Por Objetos: Se especifican por objeto los privilegios.
Seguridad – Por Usuario
Dado un usuario (o grupo de usuarios) se le otorgan derechos:
Referente a ESQUEMAS:
• CREATE SCHEMA o CREATE TABLE.
• CREATE VIEW.
• ALTER tablas/vistas/etc.
• DROP.
Referente a INSTANCIAS (datos):
• SELECT.
• MODIFY.
Seguridad – Por Objeto
Para cada usuario se pueden especificar qué acciones puede realizar con el objeto o qué
grupos de usuarios pueden realizarlo.
Modelo de Matriz de Accesos:
M(i,j) filas –> usuarios, columnas –> objetos
• Representa los privilegios (lectura, escritura, actualización) que posee el usuario i para
el objeto j.
• Por defecto, el usuario con que se crea es quien posee todos los privilegios (“owner”) .
Base de datos
Algunos ejemplos
• El administrador crea cuatro cuentas de usuario: User1, User2, User3 y User4.
• Desea que el usuario User1 pueda crear tablas:
GRANT CREATE TO User1;
• El User1 (luego de crear las tablas Empleados y Departamentos) quiere que el usuario
User2 puede ingresar y eliminar datos de las mismas:
GRANT INSERT, DELETE ON EMPLEADOS, DEPARTARMENTOS TO
User2;
• Y desea que el User3 pueda consultar estos datos:
GRANT SELECT ON EMPLEADOS, DEPARTAMENTOS TO User3;
• Luego necesita revocar los privilegios del User3 sobre Empleados:
REVOKE SELECT ON EMPLEADOS FROM User3;
237
Seguridad – Por Objeto
Tipos de privilegios:
• SELECT: Permite consultar datos de una tabla.
• MODIFY: Permite modificar las tuplas de las tablas, se subdivide en:
INSERT
UPDATE
DELETE
• REFERENCES: Permite que un usuario pueda crear claves foráneas.
• REVOKE: Quita privilegios previamente otorgados a un usuario.
Otra forma de especificar autorizaciones es utilizando VISTAS:
No le otorgo derechos de SELECT sobre las tablas pero sí sobre alguna Vista que consulte esas tablas.
Seguridad - Niveles
Se definen usuarios (o grupos) a nivel de:
• Servidor.
• Base de Datos.
Luego, cada grupo o usuario se puede asociar a un usuario o grupo del sistema operativo (si DBMS y S.O. soportan LDAP).
Dependiendo del DBMS se pueden definir ROLES a los cuales se les pueden asignar (o
negar) derechos específicos.
• Ej: Rol Desarrollador, Rol Usuario Final, Rol Administrador.
Base de datos
Roles
• Data Administrator (DA): quienes son las personas encargadas de lidiar con los aspectos comerciales o profesionales de los datos.
• Database Administrator (DBA): encargado de los aspectos técnicos.
En pequeñas organizaciones ambos roles son ejecutados por la misma persona (DBA).
238
Tareas del DBA
Diseño lógico y físico de las bases de datos: a pesar de no ser obligaciones de un administrador de bases de datos es, a veces, parte del trabajo. Esas funciones, por lo general,
están asignadas a los analistas de bases de datos o a los diseñadores de bases de datos.
• Estimar espacio a ocupar.
• Definir DÓNDE se ubican los archivos.
• Estimar crecimiento en base a monitoreo periódico.
Recuperabilidad - Crear y probar validez de respaldos.
Integridad - Verificar o ayudar a la verificación en la integridad de datos.
Seguridad - Definir o implementar controles de acceso a los datos.
Disponibilidad - Asegurarse del mayor tiempo de motor funcionando (de acuerdo a
nivel exigido por la empresa).
Desempeño - Asegurarse el buen desempeño, incluso con las limitaciones existentes.
Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar
eficientemente la base de datos.
Otros Roles
• System Administrator (SA): quien se encarga de toda la infraestructura de servidores,
discos, firewalls, etc.
• Analistas y programadores: Desarrollan y mantienen aplicaciones que acceden a las
Bases de Datos.
• Gerentes: Encargados de las decisiones, deben ser bien asesorados por SA’s, DBA’s y
Analistas.
• Clientes / Usuarios: Personas que usan los programas y que acceden a las Bases.
Eventualmente se les puede conceder derechos de consulta directa mediante algún software
limitado.
• Operadores: Tareas más simples: colocar o quitar cintas de respaldo, enviar archivos de
spool a impresoras, controlar jobs fallidos.
Esquemas de trabajo
En ambientes muy pequeños: los roles suelen estar colapsados en muy pocas personas.
En estos casos no existen ambientes separados de trabajo.
Base de datos
239
En ambientes empresariales:
• Existen dos o tres ambientes: Producción, Desarrollo, Testing.
• Los Desarrolladores/Analistas no poseen derechos sobre Producción (excepcionalmente derecho READ).
• Solo DBA’s poseen derechos sobre todos los ambientes.
Base de datos
1.
2.
3.
4.
240
El DBA trae réplicas de la Base de Producción a Desarrollo.
Los Desarrolladores efectuan cambios y pruebas sobre estas bases.
Una vez aprobados se pasan a la Base de Testing.
Si los aprueba el DBA aplica cambios en las Bases de Producción (backups, scripts).
Lenguaje SQL
Fundamentos
Structured Query Language.
Diseñado e implementado por IBM Research.
• Versión standard ANSI 1986: SQL-86 o SQL1.
• Versión standard revisada: SQL-92 o SQL2.
Ventajas:
• Conjunto de comandos único y con sintaxis conocida.
• Independencia de cómo se implementan las funciones.
Considerado el standard en las bases relacionales.
Se está extendiendo con los conceptos de OO y otros conceptos recientes de Bases de
Datos.
Algunas desventajas:
• No todos los DBMS’s implementan exactamente la misma sintaxis para todo comando.
• Algunos DBMS’s implementan comandos adicionales propios que agregan funcionalidad pero quitan portabilidad.
Comandos SQL
DDL
• CREATE
• DROP
• ALTER
DML
• SELECT
• INSERT
• UPDATE
• DELETE
CREATE DATABASE
Crea una nueva base y los archivos utilizados para almacenarla.
Dependiendo del DBMS exigirá ubicación fisica de los archivos Ejemplos:
• SQL-Server
CREATE DATABASE CLUB
ON ‘C:\BASES\CLUB_DATOS.MDF’
LOG ON ‘C:\BASES\CLUB_LOG.LDF’
• PostgreSQL y MySQL
CREATE DATABASE CLUB
• Ubicación de los archivos:
PostgreSQL: Fija, relativa a la ubicación del motor.
MySQL: Directorio definido en My.ini.
Base de datos
DDL – Bases de Datos
241
ALTER DATABASE
Modificación de las características de definición de la base:
• Modificar permisos.
• Agregar o quitar archivos de datos (SQL-Server).
• Cambiar motor de almacenamiento (MySQL).
• Etc.
Ejemplos:
• SQL-Server
ALTER DATABASE CLUB SET AUTO_SHRINK OFF
• PostgreSQL
ALTER DATABASE “CLUB” SET password_encryption=on;
• MySQL
ALTER DATABASE CHARACTER SET = ‘ascii’
DROP DATABASE
Remueve una base del Servidor de Base de Datos.
Elimina la base y los archivos utilizados para su almacenamiento.
• DROP DATABASE CLUB
Base de datos
DDL – Tablas
242
Restricciones de Integridad
• Propiedades asignadas a una columna o conjunto de columnas en una tabla.
• Utilizadas para reforzar la integridad de los datos, previenen inconsistencias: aseguran
la confiabilidad y exactitud de los datos.
• Permiten reflejar la realidad declarativamente (reglas estáticas).
Categorías:
- Entity Integrity: Asegura la no existencia de filas duplicadas en una tabla.
- Domain Integrity: Asegura entradas válidas para una determinada columna, restringiendo el tipo, la forma o el rango de los posibles valores.
- Referential Integrity: Asegura que ciertas filas no pueden ser borradas, las cuales
son utilizadas por registros de otras tablas.
- User-Defined Integrity: Refuerza ciertas reglas específicas del negocio que no
están incluidas en las anteriores.
• Las siguientes restricciones implementan las categorías mencionadas:
- PRIMARY KEY
- UNIQUE
- FOREIGN KEY
- CHECK
- NOT NULL
• Observaciones:
- Constraints son mecanismos ya implementados en el DBMS para proveer integridad sobre los datos.
- Su uso es preferible a usar triggers o rules.
- Utilizar triggers o rules sólo si la funcionalidad no puede ser obtenida con constraints.
Base de datos
243
244
Base de datos
Ejemplo 1
CREATE TABLE Empleados(
IdEmp
INT NOT NULL,
Apellido VARCHAR(30) NOT NULL,
Nombre VARCHAR(30) NOT NULL,
Direcció n VARCHAR(100) NOT NULL,
FecNac
DATETIME NOT NULL,
Salario
MONEY NOT NULL CONSTRAINT check_salario CHECK (Salario >
0))
Ejemplo 2
ALTER TABLE Empleados
ADD CONSTRAINT pk_empleado PRIMARY KEY (IdEmp)
Ejemplo 3
ALTER TABLE Empleados
DROP CONSTRAINT pk_empleado
Ejemplo 4
Dependiendo del DBMS, se pueden habilitar o deshabilitar (sin eliminarlas):
-- deshabilitar la restricción check_salario en la tabla.
ALTER TABLE Empleados
NOCHECK CONSTRAINT check_salario
-- habilitar la restricción check_salario en la tabla.
ALTER TABLE Empleados
CHECK CONSTRAINT check_salario
CREATE TABLE Autores (
idAutor INT NOT NULL PRIMARY KEY,
Nombre VARCHAR(100) NOT NULL);
ALTER TABLE Libros
ADD CONSTRAINT fk_autor FOREIGN KEY (idAutor )
REFERENCES Autores (idAutor )
ON DELETE CASCADE;
Base de datos
Ejemplo 5
“Todo libro se identifica por un ISBN. Todo libro es escrito por al menos UN autor.”
CREATE TABLE Libros (
ISBN INT NOT NULL PRIMARY KEY,
idAutor INT NOT NULL,
Nombre VARCHAR(100) NOT NULL,
Precio MONEY NOT NULL);
245
CREATE TABLE
Crea una nueva tabla.
Dependiendo del DBMS, exigirá crearla bajo un Esquema determinado.
Sintaxis:
CREATE TABLE table_name
( { < column_definition >
| < table_constraint > } [ ,...n ]
)
< column_definition > ::= column_name data_type
[ DEFAULT constant_expression ]
[ < column_constraint > ] [ ...n ]
Definición de restricciones por COLUMNA
< column_constraint >::= [CONSTRAINT constraint_name]
{ [ NULL | NOT NULL ] | [{PRIMARY KEY | UNIQUE }]
| [[ FOREIGN KEY ]
REFERENCES ref_table [ ( ref_column ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
]
| CHECK ( logical_expression ) }
Base de datos
Definición de restricciones a nivel de TABLA
< table_constraint > ::= [ CONSTRAINT constraint_name ]
{ [ { PRIMARY KEY | UNIQUE } { ( column [ ASC | DESC ] [ ,...n ] ) } ]
| FOREIGN KEY [ ( column [ ,...n ] ) ]
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE| NO ACTION } ] }
246
Ejemplo:
PostgreSQL:
CREATE TABLE “Empleados” (
“CI” character(8) PRIMARY KEY ,
“Nombre” character varying(100),
“Direccion” character varying(200),
“Fec_Nacimiento” date )
WITH ( OIDS=FALSE);
MS-SQLServer:
CREATE TABLE Empleados (
CI character(8) PRIMARY KEY ,
Nombre varchar(100),
Direccion varchar(200),
Fec_Nacimiento smalldatetime);
MySQL:
CREATE TABLE Empleados (
CI character(8) PRIMARY KEY ,
Nombre varchar(100),
Direccion varchar(200),
Fec_Nacimiento date);
Ejemplos con constraints:
CREATE TABLE PuestosDeTrabajo(
Id_puesto smallint
PRIMARY KEY,
Descripcion
varchar(50) NOT NULL
DEFAULT ‘Nueva posición’,
Nivel_Min
tinyint
NOT NULL
CHECK (min_lvl >= 10),
Nivel_Max
tinyint
NOT NULL
CHECK (max_lvl <= 250)
)
Estas restricciones son a nivel de COLUMNA.
CREATE TABLE Empleados (
Id_emp int PRIMARY KEY,
Id_puesto smallint NOT NULL ,
id_seccion smallint NOT NULL
Base de datos
FOREIGN KEY (Id_puesto ) REFERENCES PuestosDeTrabajo(Id_Puesto)
CHECK (id_seccion IN (‘1389’, ‘0736’, ‘0877’, ‘1622’, ‘1756’)
OR id_seccion LIKE ‘99[0-9][0-9]’)
)
Contiene restricciones a nivel de COLUMNA y TABLA.
247
ALTER TABLE
Modifica la definición de una tabla. Permite:
• Alterar, agregar o eliminar: columnas o restricciones.
• Habilitar o deshabilitar constraints y triggers.
No puede aplicarse a tablas del sistema.
Sintaxis:
ALTER TABLE table
{ [ ALTER COLUMN column_name { new_data_type [ ( precision [ , scale ] )] [ NULL | NOT NULL ] } ]
| ADD { [ < column_definition > ]
| column_name AS computed_column_expression ej: cost AS price * qty} [ ,...n ]
| [ WITH CHECK | WITH NOCHECK ] { < table_constraint > } [ ,...n ]
WITH CHECK :
Indica si la nueva constraint será chequeda o no sobre los datos ya existentes en la tabla
(al momento de crear el constraint).
Base de datos
ALTER TABLE
| DROP
{ [ CONSTRAINT ] constraint_name
| COLUMN column } [ ,...n ]
| { [ WITH CHECK | WITH NOCHECK ] CHECK | CONSTRAINT
| { ENABLE | DISABLE } TRIGGER
}
248
NOCHECK }
Ejemplos
• Agregar una nueva columna:
CREATE TABLE doc_exa ( column_a INT);
ALTER TABLE doc_exa ADD column_b VARCHAR(20) NULL ;
• Eliminar una columna:
CREATE TABLE doc_exb ( colA INT, colB VARCHAR(20) NULL) ;
ALTER TABLE doc_exb DROP COLUMN colB;
• Agregar columna con restricción de integridad UNIQUE:
CREATE TABLE doc_exc ( column_a INT);
ALTER TABLE doc_exc ADD column_b VARCHAR(20) NULL
CONSTRAINT exb_unique UNIQUE;
Usos de ALTER
1 - Crear claves foráneas.
“La ciudad se identifica por un codigo, pero un codigo de ciudad puede repetirse en
diferentes departamentos (entidad débil Ciudad).”
CREATE TABLE DEPARTAMENTOS (
IdDep int primary key,
NomDep varchar(100) not null);
CREATE TABLE CIUDADES (
IdDep int,
IdCiud int,
NomCiud varchar(100) not null
CONSTRAINT PK_CIUDADES PRIMARY KEY (IdDep,IdCiud) );
ALTER TABLE CIUDADES ADD CONSTRAINT FK_DEPTOS
FOREIGN KEY(IdDep)
REFERENCES DEPARTAMENTOS (IdDep);
2 - Agregar una columna con valores por defecto.
WITH VALUES provee valores para las filas ya existentes en la tabla (sino cada fila quedaría con el valor NULL).
ALTER TABLE MyTable
ADD AddDate smalldatetime NULL
CONSTRAINT AddDateDflt
DEFAULT getdate() WITH VALUES ;
DROP TABLE
• Elimina:
La definición de la tabla:
Todos sus datos.
Objetos asociados: índices, triggers, constraints, especificaciones de permisos.
• No siempre pueden eliminarse: solo cuando no existen constraints de otras tablas
hacia ella.
• Cualquier vista o stored procedure referenciado deben ser explícitamente eliminados
antes con DROP VIEW o DROP PROCEDURE.
• No pueden eliminarse tablas del sistema.
Sintaxis:
DROP TABLE table_name
Base de datos
3 - Agregar constraints en tablas que ya lo violan.
Se agrega una constraint para una columna existente.
Si la columna actualmente posee un valor que viola la constraint, se puede usar WITH
NOCHECK para evitar el chequeo contra las filas existentes y permitir agregar la restricción de todos modos.
CREATE TABLE T1 ( column_a INT) ;
INSERT INTO T1 VALUES (-1);
ALTER TABLE T1 WITH NOCHECK
ADD CONSTRAINT exd_check CHECK (column_a > 1);
249
Comparativo: Restricciones estáticas vs. dinámicas
Consejos:
• Usar Constraints porque son ANSI-Compliant.
• CON CUIDADO: usar integridad referencial en cascada en lugar de Triggers (siempre
que se pueda).
• Siempre generar SCRIPTS con los objetos de cada base al mayor detalle posible (incluir indices, restricciones, etc.).
DML – SELECT
Base de datos
SELECT
• Sentencia única de consulta en bases de datos relacionales.
• Implementación de operaciones vistas en Algebra Relacional (selección, proyección,
join, etc.).
• Permite obtener datos de varias tablas simultáneamente.
• Los resultados siempre serán conjuntos de tuplas: No necesariamente se devuelven en
orden.
• La ejecución de esta sentencia NO MODIFICA dato alguno ni genera cambios en las
bases.
Puede afectar el rendimiento general del DBMS si se hace descuidadamente.
250
Formato de la sentencia:
SELECT [ALL|DISTINCT] columnas deseadas
FROM tablas
[WHERE condición]
[GROUP BY lista-nombre-columna o lista-posición]
[HAVING condición de grupo]
[ORDER BY nombre-columna o posición]
Seleccionando todas las columnas
Ejemplo:
SELECT * FROM SECCIONES
Seleccionando columnas específicas (proyección)
Ejemplo:
SELECT NomEmp, Dirección FROM EMPLEADOS
Seleccionando valores únicos:
Ejemplo:
La cláusula WHERE:
Especifica un criterio de selección de registros a ver (selección).
SELECT lista_de_columnas
FROM nombre_de_tablas
WHERE condición
Base de datos
Delimitadores
• En Strings o Fechas, suelen ser comillas dobles o apóstrofes.
• Se usan para delimitar los literales usados en el SELECT y evitar la confusión entre el
nombre de una columna y su contenido:
Ejemplo:
FecNacimiento = ’01/01/2001’
apellido = ‘PEREZ’
CI >= “1000000-0”
251
Operadores Relacionales
Base de datos
DML – Uso del NULL
DML – Operadores Lógicos
252
IMPORTANTE:
Los operadores poseen prioridad de asociación.
• El AND posee la más alta prioridad.
• Si necesitamos condiciones complejas con AND y OR debemos utilizar PARÉNTESIS.
1) Listar las personas que viven en “La Paloma” (en el departamento de Rocha).
SELECT persona, nombre
FROM personas
WHERE ciudad = “La Paloma”
AND departamento = “Rocha”
2) Listar las personas que viven en Rocha o Durazno.
SELECT persona, nombre
FROM personas
WHERE departamento = “Rocha”
OR departamento = “Durazno”
3) Ejemplo combinado de AND y OR.
¿Cuáles son los títulos de las películas del estudio “MGM” que fueron filmadas luego de
1970 o cuya duración es menor a 90 minutos?
Incorrecto:
SELECT NomPelicula
FROM Peliculas
WHERE anio > 1970 OR duracion < 90 AND NomEstudio = ‘MGM’
Error: el AND tiene mayor precedencia, el compilador entiende
anio > 1970 OR (duracion < 90 AND NomEstudio = ‘MGM’)
Correcto:
SELECT NomPelicula
FROM Peliculas
WHERE (anio > 1970 OR duracion < 90) AND NomEstudio = ‘MGM’
Base de datos
253
DML – Más búsquedas
Buscando en un rango de valores (BETWEEN).
Dos ejemplos equivalentes:
SELECT fecha,cuenta,importe
FROM movimientos
WHERE sucursal = 1 AND
(importe >= 10000 AND
importe <= 20000)
SELECT fecha,cuenta,importe
FROM movimientos
WHERE sucursal = 1 AND
importe BETWEEN 10000 AND 20000
Buscando en un conjunto de valores (IN).
Dos ejemplos equivalentes:
SELECT cliente,nombre
FROM clientes
WHERE cliente = 10052
OR cliente = 10035
OR cliente = 10028
OR cliente = 10068
SELECT cliente,nombre
FROM clientes
WHERE cliente IN (10052,10035,10028,10068)
Base de datos
Uso del operador LIKE.
254
Búsquedas por caracteres
o patrones.
Búsquedas en Strings
(char, varchar, char varying, etc.)
Ejemplo: Nombres que finalizan en Pérez.
Búsquedas en Strings (char, varchar, char varying, etc.)
Nombres que terminan en Pere y el último carácter es cualquiera:
Otros ejemplos:
La cláusula ORDER BY
Ej.:
Base de datos
SELECT no devuelve los registros en algún orden preestablecido.
• ORDER BY indica en qué orden quiero que muestre el resultado.
• Pueden ser varias columnas, en ese caso se respeta el orden de izquierda a derecha.
• ASC o DESC indican Ascendente o Descendente, ASC es el default.
Sintaxis:
SELECT campos
FROM tablas
[WHERE condición]
...
ORDER BY nombre-columnas o posiciones [ASC | DESC]
255
Operadores Aritméticos
Permiten formar expresiones complejas.
Utilidad:
• Devolver valores calculados (no incluidos en campos).
• Expresar condiciones (en WHERE o HAVING).
• Nuevos campos en Vistas.
Operadores:
• +suma.
• -resta.
• * multiplicación.
• / división.
• %módulo (resto).
Ejemplo 1
“Necesitaría ver la cotizacion de las monedas y cuánto sería si subieran todas un 5%.”
Base de datos
Ejemplo 2
“Quiero todos los artículos cuyo precio de compra sea menor al 80% del precio de venta”
Select *
From ARTICULOS
Where precio_compra < (precio_venta * 0.8).
256
Etiquetas
Los campos calculados devueltos en SELECT no poseen nombre: se les puede inventar
un nombre “on-the-fly”.
select moneda, cotización,
‘nueva_cotizacion’ = cotización * 1.05
from cotizaciones
where moneda <> moneda_val
ORDER BY nueva_cotizacion DESC
También pueden utilizarse para presentar otro nombre para el campo:
select “Codigo Articulo” = IdArt, “Nombre Articulo” = NomArt
from ARTICULOS
where….
Joins
• Permite recuperar información de varias tablas vinculadas lógicamente entre si.
• Implementa la operación Join del Álgebra Relacional.
Ej: “Quiero saber todos los datos de los Clientes más sus Nº de cuenta.”
Tengo las tablas:
CLIENTES (nro_cliente, nom_cliente, direccion).
CUENTAS (nro_cliente,nro_cuenta, cod_moneda).
Joins: ¿Qué son?
• Es la implementación del Producto Cartesiano (T1 x T2) + Selección.
• Si no se especifica una condición, el conjunto resultante no posee sentido práctico.
Base de datos
Aplicando la condición de Join:
257
El campo Nro_cliente aparece dos veces: uno por cada tabla donde aparece.
Solución:
1. Exponer en el SELECT solo los campos que queremos ver.
2. Utilizar ALIAS.
Joins: Alias
• Son un modo de “renombrar” las tablas para mayor comodidad.
• Permite hacer más legible joins de varias tablas.
Ejemplo: “Listado de todos los Clientes con su Nº de cuenta y moneda.”
SELECT CLI.nom_cliente, CU.nro_cuenta, M.nom_moneda
FROM Clientes CLI, Cuentas CU, Monedas M
WHERE
CLI.nro_cliente = CU.nro_cliente
AND CU.cod_moneda = M.cod_moneda
Sintaxis ANSI del Join
SELECT CU.*, CLI.nro_cliente, CLI.nom_cliente
FROM
Cuentas
AS CU JOIN Clientes AS CLI
ON CU.nro_cliente = CU.nro_cliente
WHERE CLI.nom_cliente like ‘%PEREZ%’ ;
Equivalente más compacto:
SELECT CU.*, CLI.nro_cliente, CLI.nom_cliente
FROM Clientes CLI , Cuentas CU
WHERE CU.nro_cliente = CU.nro_cliente
and CLI.nom_cliente like ‘%PEREZ%’;
Creando un JOIN:
Base de datos
Usualmente se desea recuperar información de más de una tabla. Por ejemplo:
258
• Creación de JOINs.
1. Creación del Producto Cartesiano.
2. Refinamiento aplicando restricciones y eliminando filas sin significado relevante
incluyendo una claúsula WHERE válida.
• Tipos:
3. Equi-Join, Natural-Join and Join Multi-Tabla.
4. Outer-Joins.
• Información adicional en las cláusulas de la sentencia Select:
SELECT Indicar qué columnas se quiere seleccionar de cada una de las tablas.
FROM
Especificar las tablas de las que se está seleccionando informacion en la SELECT.
WHERE Indicar las columnas de las tablas seleccionadas que se igualarán para establecer el join.
• Consideraciones:
Clave Primaria (Primary Key)
Se define como el conjunto de uno o más campos de un registro que conforman su
clave, determinando la unicidad de cada fila en la tabla.
Clave Externa (Foreign Key)
Asocia los campos de una tabla con un conjunto idéntico de campos, definidos como
Clave Primaria en otra tabla. Esta asociación permite el chequeo de integridad referencial y
actualizaciones automáticas.
• Algunas particularidades:
Primary Key – Foreign Key
Es muy común realizar joins entre tablas que se encuentran en una Relación de uno a
muchos.
Las columnas que se igualarán para establecer el join no tienen porque tener el mismo
nombre.
NOTA: Recordemos que el valor null significa sin valor o desconocido. A traves de él
no se puede hacer un join.
El orden en el que se escriben las condiciones del join no afecta el significado del mismo.
Equi-Join:
Theta-Join basado en
condición de igualdad:
Resultado con
duplicado de
información:
Base de datos
Equi-Join: Join en el cual la condición de selección está basada en la igualdad de valores entre columnas, las que pueden aparecer como información redundante en el resultado.
Obs: los nombres de las columnas en las diferentes tablas no necesariamente debe ser el
mismo.
SELECT * FROM Clientes, Cuentas
WHERE Clientes.cliente = Cuentas.cliente
¿Recupera?
259
SELECT clientes.cliente, clientes.nombre,
cuenta, moneda, saldo
FROM clientes, cuentas
WHERE clientes.cliente = cuentas.cliente;
¿Problema?
Si el cliente No tiene cuenta, no figura en el resultado.
Base de datos
Un error común:
SELECT cliente, clientes.nombre, cuenta,
moneda, saldo
FROM clientes, cuentas
WHERE clientes.cliente = cuentas.cliente;
Columna ambigua, existe en ambas tablas.
260
Natural Join
Natural Join es un Equi-Join en el cual una de las columnas duplicadas es eliminada de la
tabla resultante, usualmente utilizadas en la condición de Join.
SELECT monedas.*, fecha, cotizacion
FROM monedas, cotizaciones
WHERE monedas.moneda = cotizaciones.moneda;
Resultado:
se evita la
información
redundante.
Join con muchas tablas:
SELECT clientes.nombre,
productos.nombre, monedas.nombre
FROM clientes, cuentas, productos, monedas
WHERE cuentas.cliente = clientes.cliente
AND
cuentas.producto = productos.producto AND cuentas.moneda = monedas.moneda
Resultado:
Los ALIAS:
CE.nombre cliente,
P.nombre producto,
M.nombre moneda
clientes CE, cuentas CU,
productos P, monedas M
CU.cliente = CE.cliente
CU.producto = P.producto
CU.moneda = M.moneda
Base de datos
SELECT
FROM WHERE AND AND Resultado:
261
Sintaxis ANSI del Join:
SELECT M.*, fecha, cotización
FROM
monedas AS M JOIN cotizaciones AS C
ON M.moneda = C.moneda
WHERE fecha < “01/05/2002” ;
Base de datos
El OUTER Join:
262
El Join común (INNER Join) trae solamente los registros de ambas tablas que cumplan
con las condiciones del JOIN. Por ejemplo, cuando recuperamos los clientes con sus cuentas NO trae los clientes sin cuentas.
Es por ello que existe el OUTER Join que trae todos los registros de la tabla principal.
Si no existen registros de la otra que cumplan la condición de Join pone sus campos en
NULO (Null) y, en caso, contrario los trae.
Existen tres tipos: left, right, o full, según cuál se considere la tabla “dominante”.
Left Outer Join
Ejemplo de Left OUTER Join:
SELECT C.cliente, C.nombre,U.cuenta
FROM clientes C LEFTOUTER JOIN
cuentas U ON (c.cliente = u.cliente)
Resultado Outer Join Simple:
Base de datos
Right Outer Join
263
Full Outer Join
Nested Simple Join:
SELECT C.cliente, C.nombre, U.cuenta, P.nombre
FROM clientes C LEFT OUTER JOIN
(cuentas U JOIN productos P ON U.producto = P.producto)
ON (C.cliente = U.cliente)
1. Realiza un join simple entre las tablas cuentas y productos.
2. Luego realiza un outer join para combinar la información con la tabla clientes.
Base de datos
Resultado Nested Simple Join:
Self Join
na.
264
Utilidad: comparación de valores en una columna con otros valores en la misma columSELECT
FROM
WHERE
X.cod_orden, X.peso, X.fecha_envio,
Y.cod_orden, Y.peso, Y.fecha_envio
Ordenes X, Ordenes Y
X.peso >= 5*Y.peso AND
X.fecha_envio IS NOT NULL AND
Y.fecha_envio IS NOT NULL
Resultado: Este SELECT encuentra pares de órdenes cuyo peso difiere en, por lo menos, un factor de 5 y cuyas fechas de envío no son nulas.
cod_orden
1004
1004
1007
1007
1007
peso
95.8
95.8
125.9
125.9
125.9
fecha_envio
05/03/1991
05/03/1991
06/03/1991
06/03/1991
06/03/1991
cod_orden
1011
1020
1015
1020
1022
peso
10.4
14.0
20.6
14.0
15.0
fecha_envio
07/03/1991
07/16/1991
07/30/1991
07/16/1991
07/16/1991
Funciones de Agregación
Toman valores que dependen de las columnas y retornan información respecto a las columnas (no las columnas propiamente):
• COUNT (*)
• COUNT (DISTINCT nombre_columna)
• SUM (columna/expresión)
• AVG (columna/expresión)
• MAX (columna/expresión)
• MIN (columna/expresión)
COUNT
Devuelve la cantidad de tuplas que cumplen la condición de WHERE o HAVING.
Ejemplo 1: ¿Cuántos movimientos se han hecho en el banco?
SELECT COUNT (*) FROM Movimientos;
Ejemplo 2: ¿Cuántos alumnos hay Inscriptos a una materia?
SELECT COUNT (DISTINCT cod_alumno)
FROM Inscripciones;
SUM
Suma los contenidos de un campo numérico.
Ej: ¿Cuánto dinero se ha depositado en la cuenta 100101?
Se les puede aplicar Etiquetas:
SELECT SUM(importe) AS ‘Total Depositos’
FROM Movimientos
WHERE importe>0 AND cuenta=100101;
AVG
Devuelve el promedio de los contenidos de un campo numérico.
AVG = SUM() / COUNT()
¿Cuál es el monto promedio depositado en la cuenta 100101?
SELECT AVG(importe) as Promedio
FROM Movimientos
WHERE importe>0 AND cuenta=100101;
Base de datos
SELECT SUM(importe)
FROM Movimientos
WHERE importe>0 AND cuenta=100101;
265
MAX, MIN
Devuelven el mayor o menor valor del conjunto seleccionado.
Ej. 1: ¿Cuál fue el depósito más alto en la cuenta 100101?
SELECT MAX(importe)
FROM Movimientos
WHERE cuenta = 100101;
Ej. 2: ¿Cuál fue el depósito más pequeño en la cuenta 100101?
SELECT MIN(importe)
FROM Movimientos
WHERE cuenta=100101 AND importe>0;
Las funciones de Agregación se pueden aplicar simultáneamente.
En este caso, se aplican al MISMO conjunto de tuplas.
SELECT MAX(importe), MIN(importe), AVG(importe)
FROM Movimientos
WHERE cuenta = 100101 and importe > 0;
En este ejemplo, devuelve una tupla con tres campos.
Agrupamientos
Base de datos
GROUP BY
• Permite agrupar los registros por un campo (o más de uno).
• Produce un solo registro por cada grupo de registros.
266
Su utilidad es combinarlo con las Funciones Agregadas:
Ejemplo 1: “Quiero saber cantidad de movimientos y el importe por Cuenta.”
Ejemplo 2: “Quiero saber cantidad de personas por Departamento y luego por Ciudad.”
SELECT departamento, ciudad, COUNT(*)
FROM clientes
GROUP BY departamento, ciudad.
Nota: No necesariamente se ordenan por ese criterio.
Ordenando el GROUP BY:
Ejemplo 1:
Ordenado por departamento y luego ciudad.
SELECT
departamento, ciudad, COUNT(*)
FROM
Clientes
GROUP BY departamento, ciudad
ORDER BY departamento, ciudad
Ejemplo 2: Ordenado por Cantidad (descendente) y luego por ciudad y departamento.
SELECT
departamento, ciudad, COUNT(*)
FROM
Clientes
GROUP BY departamento, ciudad
ORDER BY 3 DESC, 2, 1
Base de datos
IMPORTANTE:
Todas las columnas en la lista del SELECT que no estén en funciones de agregación,
deben figurar en los campos de GROUP BY.
Esto es porque el GROUP BY solo puede retornar una fila por grupo y para esas filas
se aplica la función de agregación.
HAVING
• La claúsula HAVING usualmente complementa a GROUP BY aplicando condiciones
a los grupos (especificados por el GROUP BY) luego de que éstos están formados.
• Ventajas: se pueden incluir funciones de agregación como condición de búsqueda,
facilidad que no está permitida en:
WHERE.
267
Ejemplo:
“Quiero saber el total de dinero (por cuenta) de las cuentas > 10.000, pero solo de los
que tengan un total positivo.”
SELECT cuenta, SUM(importe) AS Total
FROM
Movimientos
WHERE cuenta > 10000
GROUP BY cuenta
HAVING SUM(importe) > 0;
Ejemplo de agrupamientos:
SELECT cuenta,
MAX(importe) Maximo,
MIN (importe) Minimo,
AVG(importe) Promedio
FROM Movimientos
WHERE cuenta > 10000
GROUP BY cuenta
HAVING COUNT(*) > 2 AND SUM(importe) > 0
Base de datos
Funciones Escalares
268
• Funciones de String.
• Funciones Aritméticas.
• Funciones de Fecha.
• Funciones del Sistema.
Se pueden componer, siempre que se respeten, los dominios de Entrada y Salida.
Funciones de String
• LEN
• STR
• SUBSTRING
• LOWER • UPPER
• LTRIM • CHARINDEX
• PATINDEX • SPACE
• CHAR • REPLICATE • REVERSE • STUFF
• DIFFERENCE • RIGHT LEN (campo/valor)
Devuelve el largo del string pasado como argumento.
len(‘HOLA’) Resultado : 4
len(‘’) Resultado : 0
STR (valor_numerico[, largo[, pos_decimales]])
SELECT str(-165.8768, 7, 2)
Resultado: ‘-165.88’
LOWER (<char_expr>) Devuelve el mismo string pasado a minúsculas.
UPPER (<char_expr>) Devuelve el mismo string pasado a mayúsculas.
SELECT upper(‘Bob Smith1234*&^’), lower(‘Bob Smith1234*&^’)
---------------
---------------BOB SMITH1234*&^
bob smith1234*&^
LTRIM (<char_expr>) Remueve espacios en blanco a la izq.
SELECT ltrim(‘
-------------valor
valor ‘)
Base de datos
SUBSTRING (campo/valor, posición inicial, largo).
Devuelve un fragmento del String (parametro 1).
Los caracteres comienzan en la posición 1.
SELECT substring(“ROBERTO MARTINEZ DELGADO”,8,7).
Resultado: ‘ MARTIN’.
269
CHARINDEX retorna la posición de comienzo de una determinada cadena en una
expresión, donde expresión usualmente es el nombre de una columna.
CHARINDEX (<’char_expr’>, <expression>)
SELECT charindex (‘de’, ‘Un pequeño texto de muestra’)
Resultado: 18
Funciones Aritméticas
FunciónParámetrosSemántica
• ABS
(N)
Devuelve el valor absoluto de N
• SIGN
(N)
Devuelve -1 si N<0 , 1 si N>0 o 0
• CEILING
(N)
Entero inmediato siguiente a N
• FLOOR
(N)
Entero inmediato anterior a N
• EXP
(N) EXP(N) = eN
• LOG
(N)
LOG(N) = Loge(N)
• POWER
(x,y) POWER(x,y) = xy
• ROUND
(N, d) Redondea N a d dígitos
• SQRT
(N)
Raíz cuadrada de N
• Trigonométricas
Funciones de Fecha
Base de datos
DATEPART (<date_part>, d)
Devuelve un componente de la fecha d: year, month, day, hour, minute, second
select datepart(day, getdate() )
14
select datepart(year, ’25/07/2009’ )
2009
270
DATENAME (<date part>, d)
Devuelve el nombre de una parte de la fecha d:
select datename(month,’25/07/2009’)
‘July’
select datename(weekday,’25/07/2009’)
‘Saturday’
DATEADD (<date part>, <number>, <date>)
Suma o resta intervalos a una fecha (días, meses, años, etc.):
select dateadd(day, 10, ’25/07/2009’)
‘4/8/2009’
select dateadd(month, 2, ’25/07/2009’)
‘25/9/2009’
select dateadd(month, -9, ’25/07/2009’)
‘25/10/2008’
DATEDIFF(<date part>, <date1>, <date2>)
Calcula diferencia entre dos fechas (en días, meses, años, etc.):
select datediff(day, ‘25/07/2009’, ‘25/08/2009’)
31
select datediff(month, ‘25/07/2009’, ‘25/08/2009’)
1
Funciones del Sistema
Permiten obtener información del entorno.
Devuelven información del sistema, usuario, BD y objetos de la BD.
Suelen depender del DBMS.
• getdate(), CURRENT_DATE(), CURRENT_TIME()
Devuelven fecha/hora actual.
• host_name()
Nombre del equipo desde donde se conectó.
• db_name(), DATABASE()
Nombre de la base en que estamos posicionados.
• user_name(), CURRENT_USER()
Devuelve el nombre del usuario del DBMS actualmente conectado.
• @@VERSION, VERSION()
Devuelven la versión del DBMS
Subqueries
Base de datos
• Son sentencias SELECT anidadas dentro de otra sentencia SELECT.
• Devuelven información a la principal y deben figurar siempre entre paréntesis.
• Permiten implementar la operación DIFERENCIA del Algebra Relacional.
Ejemplo: “Necesito listar personas que viven en la misma ciudad que
‘CLIENTE
10010’”
SELECT
persona,
nombre,
ciudad,
departamento
FROM Personas
WHERE ciudad = (SELECT ciudad
FROM Personas
WHERE nombre = ‘CLIENTE 10010’)
Las subqueries son evaluadas primero y su(s) valor(es) son sustituido(s) en la consulta
principal.
Una subquery puede retornar:
• Ningún valor.
Consecuencias: Dicha subquery es equivalente a un valor Nulo.
La query general no retona ningún valor.
• Un valor.
Consecuencia: La subquery es equivalente a un número o valor carácter.
• Un conjunto de valores.
Consecuencia: La subquery retorna o una fila o una columna.
Restricciones:
• Solo si el subquery devuelve UN valor puede preguntarse por =.
• Si el subquery devuelve UN campo se puede preguntar por IN.
• En caso contrario, se debe preguntar por EXISTS.
Ejemplo 1: Listar las personas que viven en la misma ciudad que ‘ JUAN PEREZ’.
SELECT persona, nombre, ciudad, departamento
FROM Personas
WHERE ciudad = (select ciudad
from personas
where nombre = ‘JUAN PEREZ’ )
271
Ejemplo 2: Listar personas que viven en la misma ciudad y departamento que ‘JUAN
PEREZ’.
SELECT persona, nombre, ciudad, departamento
FROM Personas P
WHERE EXISTS (select *
from personas P2
where P2.nombre = ‘JUAN PEREZ’
and P.ciudad = P2.ciudad
and P.departamento = P2.departamento)
Tipo de Subqueries
• Correlacionadas
• No-Correlacionadas
Correlacionadas (o inner SELECT): el valor producido por ella depende de un valor
producido por el SELECT externo. En cualquier otro caso son No-Correlacionadas.
Base de datos
Subqueries Correlacionados
Listar los Empleados cuyo sueldo está por debajo del promedio de su Sección:
SELECT nro_emp, nom_emp, seccion, sueldo
FROM Empleados E1
WHERE sueldo < (SELECT AVG (sueldo)
FROM Empleados E2
WHERE E2.seccion = E1.seccion)
ORDER BY 1, 2, 3
La subquery es ejecutada por cada fila considerada por el SELECT externo.
272
Negación
Permiten implementar DIFERENCIA de tablas.
Ej: Qué clientes no tienen cuentas.
SELECT
*
FROM
Clientes
WHERE
cod_cliente NOT IN
(SELECT cod_cliente FROM Cuentas)
Sentencia equivalente (correlacionada):
SELECT
*
FROM
Clientes
WHERE
NOT EXISTS
(SELECT *
FROM Cuentas
WHERE Cuentas.cod_cliente = Clientes.cod_cliente)
Se utiliza NOT EXISTS cuando se desea evaluar un NOT IN con más de una columna.
Ej: “Movimientos para los cuales no se ha ingresado una cotización aún (están en tabla
MOVIMIENTOS pero NO en COTIZACIONES).”
SELECT M.id_mov, M.fecha, M.cuenta, C.moneda
FROM movimientos M, cuentas C
WHERE M.cuenta = C.cuenta
AND NOT EXISTS
( SELECT *
FROM Cotizaciones COT
WHERE COT.moneda = C.moneda
AND COT.fecha = M.fecha )
ORDER BY 1, 2, 3
Uso en HAVING
Se pueden utilizar en la cláusula HAVING para mayor expresividad.
“Clientes con un saldo en plazo fijo igual al más alto de todos los plazos fijos.”
SELECT cliente, sum(saldo)
FROM Cuentas
WHERE producto = 3 and moneda = 1
GROUP BY cliente
HAVING sum (saldo) = (SELECT max (saldo)
FROM cuentas
WHERE producto = 3 AND
moneda = 1)
UNION
• Combina múltiples consultas en una sola.
• Facilita ordenamiento no posible con una consulta simple.
• UNION: Operador que une el resultado de dos o más Consultas en una Consulta Simple.
Dos tipos:
UNION: Excluye los resultados repetidos de las consultas unidas.
UNION ALL: Incluye TODAS las tuplas de las consultas unidas (aún con repetición).
SELECT lista de columnas
FROM tablas
[WHERE condición]
UNION [ALL]
SELECT lista de columnas
FROM tablas
[WHERE condició n]
[Order By lista de columnas]
Condiciones y Requisitos:
• La cantidad de columnas en cada sentencia SELECT debe ser la misma.
• El tipo de datos de cada columna entre los dos SELECT’s debe coincidir. No se exige
que sea la misma columna, ni siquiera que posea el mismo nombre.
• Si deseo ordenar la salida, debo ubicar la sentencia ORDER BY al final de la consulta.
Referencio las columnas por sus posiciones.
Base de datos
Sintaxis:
273
Base de datos
Ejemplo:
SELECT unique cuentas.cuenta, cuentas.producto
FROM
movimientos, cuentas
WHERE movimientos.cuenta = cuentas.cuenta
and sucursal = 4
and importe > 3000000
UNION
SELECT unique cuentas.cuenta, cuentas.producto
FROM
cuentas, cuentas_intereses
WHERE cuentas.cuenta =cuentas_intereses.cuenta
and cuentas_intereses.interes = 0;
274
Ejemplos Válidos:
1) SELECT
cod_cliente, nro_cuenta, cod_moneda, ‘Cliente 102’ as Grupo
FROM Cuentas
WHERE
cod_cliente = 102
UNION
SELECT
cod_cliente, nro_cuenta, cod_moneda , ‘Euros’ as Grupo
FROM Cuentas
WHERE
cod_moneda = 3 and cod_cliente <> 102
ORDER BY 3,1,2
2) SELECT
E.id_persona, P.nombre
FROM Personas P, Empleados E
WHERE P.id_persona = E.id_persona
UNION
SELECT C.cod_cliente, P.nombre
FROM Personas P, Clientes C
WHERE P.id_persona = C.id_persona
Ejemplos Incorrectos:
1) SELECT
cod_cliente, fec_apertura
FROM Cuentas
WHERE
cod_cliente = 102
UNION
SELECT
cod_cliente, nro_cuenta
FROM Cuentas
WHERE
cod_moneda = 3 and cod_cliente <> 102
2) SELECT
E.id_persona, P.nombre, E.fec_ingreso
FROM Personas P, Empleados E
WHERE P.id_persona = E.id_persona
UNION
SELECT C.cod_cliente, P.nombre, ???????
FROM Personas P, Clientes C
WHERE P.id_persona = C.id_persona
Modificación de Datos (INSERT, UPDATE, DELETE)
INSERT
Única forma de agregar nuevos registros a una tabla.
Se pueden insertar valores NULL explícitamente, siempre que la definición de la columna lo permita.
Dos variantes:
1. INSERT con valores explícitos (una tupla a la vez).
2. INSERT con valores tomados de otra tabla.
En ambos tipos se pueden especificar los campos EXPLICITAMENTE o NO:
INSERT INTO T ……
INSERT INTO T (campo1, campo2, ……) ……..
Se recomienda poner siempre los campos a insertar EXPLÍCITAMENTE.
INSERT Tipo 2: Trayendo datos de otra tabla
Si una sola tupla fallara no se insertará NINGUNA: es una sola sentencia.
Sintaxis:
INSERT INTO <tabla> [ (columnas) ] SELECT <campos> FROM …..
Ej: INSERT INTO MovCta545 (fecha, sucursal, importe)
SELECT fecha, sucursal, importe
FROM movimientos
WHERE cuenta = 545;
Base de datos
INSERT Tipo 1: Valores dados explícitamente.
Sintaxis:
INSERT INTO <tabla> [ (columnas) ] VALUES (v1, v2,… , vn).
Ej: (dos modos equivalentes de escribirlo):
1. Tabla : EMPLEADOS(nro_emp, nombre, direccion).
INSERT INTO EMPLEADOS VALUES (1,’Juan’,’Colonia 6499’);
2. INSERT INTO EMPLEADOS(nro_emp, nombre, direccion)
VALUES (1,’Juan’,’Colonia 6499’);
275
UPDATE
Actualiza datos de una Tabla.
Sintaxis:
UPDATE <tabla>
SET <campo1> = <valor1>, <campo2> = <valor2>, ….. ,
<campoN> = <valorN>
[ WHERE <condicion> ]
IMPORTANTE:
1. Si no se especifica WHERE el cambio se aplica a TODA LA TABLA.
2. Si el WHERE no es por un campo clave se corre el riesgo de actualizar tuplas que no
se deseaba.
3. El UPDATE puede fallar si:
a) Se intentan asignar valores NULL a columnas que no lo permiten.
b) Se violan CHECKS.
c) Se viola una PRIMARY KEY.
Ejemplo 1:
UPDATE EMPLEADOS
SET nombre = ‘Juan Martínez’, dirección = ’Colonia 6401’
WHERE nro_emp = 1;
Modifica nombre y dirección del empleado con codigo = 1
Base de datos
Ejemplo 2:
UPDATE EMPLEADOS
SET dirección= ‘Mercedes 3423’
WHERE nombre like ’%Perez%’
Atención: modifica TODOS los Perez, pueden modificarse más de los que deseábamos.
Sugerencia: hacer antes un SELECT COUNT(*) …. .
276
Ejemplo 3:
UPDATE EMPLEADOS
SET dirección = ’’
Deja en blanco TODAS las direcciones de la tabla EMPLEADOS.
Variante: UPDATE con subquery relacionado.
Ejemplo:
Recalcular el saldo de todas las cuentas.
UPDATE Cuentas
SET saldo = (SELECT SUM (importe)
FROM Movimientos
WHERE Cuentas.cuenta = Movimientos.cuenta
)
DELETE
Elimina filas de una Tabla.
• Al igual que UPDATE se debe especificar con WHERE cuales tuplas se desean borrar.
• Puede fallar si se violaran restricciones de integridad.
Caso típico: se borran tuplas de tabla referenciada por FOREIGN KEYS desde otras.
Si ese fuera el caso no se borra NINGUNA tupla.
Sintaxis:
DELETE FROM <tabla> WHERE <condición>
Ejemplos:
1) DELETE FROM Clientes WHERE cliente = 10001;
2) DELETE FROM Empleados;
Borra el contenido de TODA la tabla Empleados.
3) Quiero eliminar las personas del departamento de MALDONADO.
DELETE FROM Personas
WHERE departamento LIKE “M%O”;
Atención: No se usó la Clave primaria y obtengo:
Hemos eliminado también los clientes de “MONTEVIDEO”.
Modelos de Datos y DBMS
Modelos de Datos:
CLASIFICACIÓN
Según el nivel de abstracción:
• Conceptuales
Representan la realidad, independientemente de cualquier implementación de BD.
Usado en etapa de Análisis.
Base de datos
¿QUÉ SON?
Lenguajes usados para especificar BDs.
Un Modelo de Datos permite expresar:
• Estructuras
Objetos de los problemas:
Por ejemplo: CURSOS(nro_curso, nombre, horas).
• Restricciones
Reglas que deben cumplir los datos.
Por ejemplo: (
) (c.horas < 120)
• Operaciones.
Insertar, borrar y consultar la BD.
Por ejemplo: Insert into CURSOS (303,”BD”,90).
277
• Lógicos
Implementados en DBMSs.
Usado en etapas de Diseño e Implementación.
• Físicos
Implementación de estructuras de datos.
Ej.: Á rboles B, Hash.
APLICACIÓN
Base de datos
Esquema de una BD:
• Tipos de datos existentes.
Por ejemplo:
CURSOS(nro_curso, nombre, horas).
ESTUDIANTES(CI, nombre, fecha_nacimiento).
TOMA_CURSO(nro_curso, CI).
• Muy estables.
278
Instancia de una BD
• Datos almacenados.
• Muy volátiles.
Arquitectura lógica de DBMS
Propiedades importantes de DBMSs:
• Control global único de la BD.
• Separación entre esquema y aplicaciones.
Esquema: visión global de los datos de la realidad.
Aplicaciones: programas sobre la BD.
• Soporte a diferentes visiones de los datos.
Usuarios/aplicaciones ven subconjuntos de la BD.
• Independencia de datos.
Esquema lógico independiente de implementación.
ARQUITECTURA EN TRES NIVELES
Independencia de datos
• Independencia Lógica.
- Independencia entre especificaciones de nivel Lógico y Externo.
- Cambiar partes de esquema lógico sin afectar a los esquemas externos o a las
aplicaciones.
• Independencia Física.
- Independencia entre especif. de nivel Lógico y Físico.
- Cambiar implementaciones sin afectar esq. Lógico.
• Tipos de QL:
- Declarativos.
- Se especifica qué propiedad cumplen los datos.
- No se especifica cómo se recuperan de la BD.
- Suelen recuperar conjuntos de items (registros).
- Es el DBMS que define el plan de ejecución.
- Procedurales.
- Se especifica un algoritmo que accede a estructuras del esquema lógico y
recupera los datos ítem por ítem (registro a registro).
Base de datos
Lenguajes e Interfaces en ambientes BD
• Provistos por DBMS:
- Definición de esquema:
- VDL (o SSDL) - View Definition Language.
- SDL - Storage Definition Language.
- DDL - Data Definition Language.
- Suele englobar estos tres lenguajes.
- Manipulación de la BD:
- DML - Data Manipulation Language.
- Modificaciones en instancias.
- QL - Query Language.
- Subconjunto del DML, sólo para consultas.
279
• Lenguajes de programación:
- Lenguajes host (anfitrión):
- Lenguajes de uso general (C, COBOL, etc.) en el cual se embeben sentencias
de DML.
- Se tiene un pre-procesador que traduce el programa con DML embebido en un programa puro.
- PROBLEMAS: impedance-mismatch.
- Lenguajes 4GL:
- Lenguajes procedurales orientados a acceso a BDs.
- Conexión privilegiada con DMLs, reduce el impedance-mismatch.
• Interfaces especializadas:
- Interfaces gráficas de consulta.
- Se visualizan las estructuras en forma gráfica.
- Resultados como gráficas (torta, lineas, etc.).
- Interfaces de Lenguaje Natural.
- Se procesan frases y se traducen al QL.
- Interfaces para Administración.
- Ambientes especializados.
Base de datos
ESTRUCTURA DE DBMS
280
Diferentes tipos de DBMS
• Según el Modelo de Datos:
- Relacional.
- Orientado a Objetos.
- Otros: Redes, Jerárquico, Deductivo, ...
• Según el porte:
- Desktop (escritorio) / mono-usuario.
- Servidor / multi-usuario.
• Según distribución de la BD:
- Centralizado.
- Distribuido.
RESUMEN DE LOS ELEMENTOS DE BASES DE DATOS
MODELOS DE DATOS
Calidad de Esquemas Conceptuales
Para asegurar la calidad de los esquemas conceptuales se define un conjunto de propiedades que se deben chequear durante y al final de su desarrollo:
Base de datos
• Completitud
Un esquema es completo cuando representa todas las características relevantes del
problema.
Chequeo:
- Controlar que todos los conceptos del problema estén representados en alguna parte del esquema.
- Controlar que todos los requerimientos sean realizables con el esquema.
- Leer el resultado y compararlo con la descripción original.
281
• Correctitud
Hay dos tipos:
- Sintáctica: Habla de la forma en que se especifica el esquema con respecto al lenguaje usado para hacer esa especificación.
- Semántica: Habla de la forma en que la especificación representa el
problema.
Correctitud Sintáctica:
Un esquema es correcto sintácticamente cuando las distintas partes de éste están
construidas correctamente con respecto al lenguaje utilizado.
Ej.: Las agregaciones se construyen sobre una relación, no sobre dos entidades
cualesquiera u otra cosa.
Base de datos
Chequear:
- Existencia de cardinalidades en cada relación.
- Existencia de atributos determinantes en cada entidad. Si no existen, entonces verificar
que sea entidad débil con respecto a otra.
- Existencia de una y sólo una relación y todas las entidades que intervienen en la misma
dentro de cada agregación.
282
Correctitud Semántica:
Un esquema es correcto semánticamente si cada elemento del problema se representa
utilizando estructuras adecuadas.
- Chequear o Responder para cada concepto del problema (de la realidad):
- ¿Atributo, Entidad o Relación?
- ¿Una sola categoría de entidades o más de una?
- ¿Una Relación es binaria o múltiple?
- ¿Cuál es el mecanismo de determinación del conjunto de entidades?
- Las cardinalidades y totalidades, ¿tienen sentido?
- En general: la representación, ¿tiene sentido con respecto a la realidad?
Minimalidad:
Un esquema es minimal si cualquier elemento de la realidad aparece sólo una vez en el
esquema.
- Chequear:
- Dónde está representado en el esquema cada elemento de la realidad.
- A qué elemento de la realidad corresponde cada elemento del esquema.
- Controlar atributos calculados.
Expresividad:
Un esquema es expresivo si representa la realidad en una forma natural que puede ser
fácilmente comprensible usando sólo la semántica del modelo.
Explicitud:
Un esquema es explícito si no utiliza más formalismos que el diagrama E-R.
Base de datos
Resumen:
Hay cinco propiedades fundamentales a controlar:
- Completitud
- Correctitud
- Minimalidad
- Expresividad
- Explicitud
Para las tres primeras propiedades se definieron criterios elementales de Chequeo.
Todas las propiedades se deben balancear, buscando un buen diseño:
- Hay que buscar esquemas completos y correctos, minimales, expresivos y
explícitos.
283
Diseño de Base de Datos Relacional
Pautas informales para el diseño.
Cuatro medidas informales de la calidad:
– Semántica de los atributos.
– Reducción de los valores redundantes en las tuplas.
– Reducción de los valores nulos en las tuplas.
– No generación de tuplas erróneas.
Base de datos
• Semántica de los atributos:
Ejemplos:
284
Pauta 1:
Diseñe un esquema de relación de modo que sea fácil explicar su significado. No combine atributos de varios tipos de entidades y tipos de vínculos en una sola relación.
• Reducción de los valores redundantes:
Información redundante en las tuplas.
Anomalías de actualización:
– Anomalías de inserción.
– Anomalías de eliminación.
– Anomalías de modificación.
Pauta 2
Diseñe los esquemas de las relaciones de modo que no haya anomalías de inserción, eliminación o modificación en las relaciones. Si hay anomalías señálelas con claridad a fin de que los programas que actualicen la BD operen correctamente.
Base de datos
• Valores nulos en las tuplas
Posibles problemas:
– Desperdicio de espacio.
– Dificultad para entender el significado.
– Aplicación de funciones agregadas (count,sum).
– Múltiples interpretaciones.
Pauta 3
Hasta donde sea posible, evite incluir en una relación atributos cuyos valores pueden ser
nulos. Si no es posible, asegúrese de que se apliquen solo en casos excepcionales y no a
la mayoría de las tuplas de una relación.
285
• Tuplas erróneas
Ejemplo 1: Se aplica proyección a EMP-PROY.
Base de datos
286
Ejemplo 2: Se aplica join natural a EMP-PROY1 y LUGARES-EMP.
Pauta 4
Diseñe los esquemas de modo que puedan reunirse por condición de igualdad sobre atributos claves, para garantizar que no se formen tuplas erróneas.
Resumen
Problemas a evitar:
– Anomalías en inserción, modificación y eliminación de tuplas por
redundancia.
– Desperdicio de espacio y dificultad para operaciones por valores nulos.
– Generación de datos erróneos por joins hechos relacionando mal las
relaciones.
Entonces se presentarán…
– Conceptos y teorías formales para detectar y evitar estos problemas.
Dependencias Funcionales
Definición:
Ejemplo 1 – Deducir atributos y dfs.
Base de datos
• Clausura de F - F+
Definición:
F - conjunto de dfs que se especifican sobre el esquema relación R.
F+ - conjunto de todas las dfs que se cumplen en todas las instancias que
satisfacen a F.
Inferencia de dfs
Ejemplo:
287
Base de datos
Reglas de inferencias para las dfs:
288
Base de datos
289
290
Base de datos