MANUALGESTION INFORMATICA II.pdf

UNIVERSIDAD PERUANA LOS ANDES

FACULTAD DE CIENCIAS ADMINISTRATIVAS

CONTABLES

CARRERA PROFESIONAL: CONTABILIDAD Y

FINANZAS

GESTION INFORMATICA II

Huancayo – 2013

“Material sujeto a modificaciones y actualizaciones durante el desarrollo del curso”

Ing. Elvis Guillermo Huarcaya Quispe Pág.

2

Gestión de informática II

PRESENTACIÓN

En un mundo donde se cambia constantemente la tecnología y la información su tratamiento automatizado no sólo es necesaria para el eficiente funcionamiento de toda organización, sino que se ha convertido en uno de los principales elementos de competitividad. En este contexto, el almacenamiento de la información (en forma de datos) y su disponibilidad para las aplicaciones de negocio se hace indispensable para la normal operación y funcionamiento de cualquier empresa. El personal que opera las diferentes aplicaciones rutinarias interactúa con "Base de datos". La Gerencia, que evalúa y controla la eficiencia de estas operaciones también requerirá de información, de manera de planificar nuevas tareas y/o corregir aquellas que no vayan con la estrategia de negocio

planteada. A su vez, las personas que deciden las estrategias de negocio (nuevos mercados, nuevas líneas de negocio, simple supervivencia, etc.) también requieren información para toma de decisiones. Se dice que el principal activo de una organización es su personal. Entonces podría decirse que el segundo en importancia sería su información, aunque probablemente y en muchos casos ésta última sea más difícil de reemplazar que el primero. Ya sea que la base de datos sea usada para apoyar alguno de los niveles organizacionales comentados o todos, debe elegirse la tecnología adecuada que garantice su permanente y eficiente disponibilidad, así como que facilite el desarrollo de aplicaciones y la administración de la base de datos.

El autor


3


ÍNDICE

PRESENTACIÓN

ÍNDICE

COMPETENCIAS DE LA ASIGNATURA

PRIMERA UNIDAD

Definición de sistema de base de datos

Modelo Relacional

Dominio y Atributo

Transformación del Modelo Entidad-Relación al modelo relacional

Algebra Relacional

Modelo Entidad-Relación

SEGUNDA UNIDAD

Diseño de Base de Datos

Dependencias Funcionales

Normalización

Lenguaje de Consulta de Base de Datos Structured Query Language. TSQL (DDL)

Manipulación de datos (DML)

Administración de bases de datos, Gestión de Base de Datos y seguridad

Programación en SQL (Procedimientos Almacenados, funciones y desencadenantes etc.)

BIBLIOGRAFÍA


4


COMPETENCIAS DE LA ASIGNATURA

Analiza y diseña e implementa una base de datos, utilizando el modelo entidad-relación, modelo relacional, modelo distribuido de una organización Pública o Privada con creatividad y responsabilidad.

Implementa en un gestor de bases de datos basados en arquitectura Cliente/Servidor y Administra base de datos corporativa


5


PRIMERA UNIDAD

SISTEMA DE BASE DE DATOS 1. Introducción

En una empresa, las entidades están representadas por los operarios, los empleados, los clientes, los proveedores, las facturas. En este tipo de organización y otras se ha de trabajar con una gran cantidad de datos, lo cual hace surgir la necesidad de almacenarlos de manera que nos resulten de fácil acceso en cada momento y, por consiguiente, útiles a nuestras actividades. Si por ejemplo cada día debemos gestionar varias decenas de clientes y facturas, utilizaremos un sistema para memorizar los datos como, por ejemplo, un fichero, más bien antes que recurrir únicamente a la memoria. Las fichas aparecen reagrupadas en archivos, cada uno de los cuales contiene en general las fichas de un sólo tipo, las de los proveedores o las de los productos. Este sistema recibe el nombre de base de datos, que no es ninguna otra cosa más que una colección de informaciones tales como el catálogo de los ficheros de una biblioteca, un listado telefónico o una enciclopedia. El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California – USA. La idea de base de datos surge como una necesidad de mantener datos relacionados. Para entender mejor el concepto de Base de datos empezaremos con las definiciones siguientes: - Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o alfanuméricos.

- Información: Es un conjunto ordenado de datos los cuales son manejados según la necesidad del usuario, para que un

conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a información, primero se debe guardar lógicamente en archivo

2. Definiciones de BD

Todas las definiciones coinciden en que es un conjunto de datos almacenados

Un conjunto de información relacionada que se encuentra agrupada ó estructurada.

Un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos (punto de vista informático)

“Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una o más aplicaciones de la mejor forma posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados”. Martin, 1975.

“Colección integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios”. Deen, 1985.

“Colección de datos integrados, con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y descripción, únicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualización y recuperación, comunes y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos”. A.de Miguel, 1993.

“Una base de datos consiste en alguna colección de datos persistentes e independientes usados por una organización determinada”. (Date, 1995)

3. Análisis del concepto de Base de Datos

El concepto de Base de Datos determina algunas características propias, por ejemplo:

El mundo real considera interrelaciones entre datos y restricciones semánticas que deben estar presentes en una base de datos. Una base de datos no solo debe almacenar entidades y atributos, sino que también debe almacenar

COMPETENCIA Analiza y diseña e implementa una base de datos, utilizando el modelo entidad-relación, modelo relacional, modelo distribuido de una organización Pública o Privada con creatividad y

responsabilidad


6


interrelaciones entre datos. Por otro lado, actualmente se le está dando mucha importancia a las restricciones semánticas, de manera que éstas se almacenan junto con los datos.

La redundancia de datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni innecesarias.

Las bases de datos pretenden servir a toda la organización, es decir a múltiples usuarios y a diferentes aplicaciones.

La definición y descripción del conjunto de datos contenido en la base debe ser única e integrada con los mismos datos. En las bases de datos, la descripción, y en algunos casos, también una definición y documentación completas (metadatos) se almacenan junto con los datos, de modo que éstos están documentados, y cualquier cambio que se produzca en la documentación debe quedar recogido en el sistema.

La actualización y recuperación de las bases de datos debe realizarse mediante procesos bien determinados, incluidos en el SGBD; procedimientos que han de estar diseñados de modo que se mantenga la integridad, seguridad y confidencialidad de la base.

4. Características elementales de una Base de Datos

El objetivo de disminuir la redundancia de un conjunto de datos determina dos características fundamentales que poseerá cualquier sistema de Bases de Datos: a) Integrada

Una base de datos puede considerarse como una unificación de varios archivos de datos independientes, donde se elimina parcial o totalmente cualquier redundancia entre los mismos. Ejm: Una BD específica puede contener registros de ALUMNO, que incluyen el nombre, dirección, teléfono, fecha de nacimiento, etc. y, existir registros de INSCRIPCION que representan inscripciones de alumnos en cursos de capacitación. En el caso de llevar acabo el proceso de administración de los cursos se necesita conocer la dirección de cada estudiante inscrito, para lo cual, no hay necesidad de incluir este dato (redundante) en los registro de INSCRIPCION, siempre se podría obtener recurriendo a los registros de ALUMNO correspondiente.

b) Compartida Las partes individuales de la Base de Datos pueden compartirse entre varios usuarios distintos, en el sentido que cada uno de ellos puede tener acceso a la misma parte de la Base de Datos y utilizarla con propósitos diferentes. Tal comportamiento es en verdad consecuencia del hecho de que la Base de Datos es integrada. En el caso del ejemplo anterior se tiene que los datos de los registros de ALUMNO es compartido por usuarios del departamento de personal y capacitación. Lo cual implica que, diferentes usuarios percibirán de modos muy distintos una base de datos.

5. Ventajas de las Bases de Datos Referidas a:

Referidas a: Ventajas

Los datos Independencia de estos respecto de los tratamientos y viceversa

Mejor disponibilidad de los mismos para los usuarios

Mayor eficiencia en la recogida, codificación y entrada

Los resultados Mayor coherencia

Mayor valor informativo

Mejor y más normalizada documentación de la información

Los usuarios Acceso más rápido y sencillo de los usuarios finales

Más facilidades para compartir los datos por el conjunto de los usuarios

Mayor flexibilidad para atender a demandas cambiantes.

Análisis cuadro anterior Los datos:

Independencia de los datos respecto a los tratamientos y viceversa: Esto supone que un cambio en los tratamientos no imponga un nuevo diseño lógico y/o físico de la base de datos. Por otro lado, cambios en la incorporación, desaparición de datos, cambios en la estructura física o caminos de acceso no deben obligar a alterar los programas. Así se evita la reprogramación de las aplicaciones.

Mejor disponibilidad de los datos para el conjunto de los usuarios: En una base de datos ningún usuario es propietario de los datos, pues éstos se comparten entre las aplicaciones, existiendo una mayor disponibilidad.

Mayor eficiencia en la recogida, codificación y entrada de datos: Al no existir la redundancia, los datos se recogen y validan una sola vez, aumentando así la eficiencia.

Los resultados:

Coherencia de los resultados: Debido a que la información de la base de datos se recoge y se almacena una sola vez, en todos los tratamientos se utilizan los mismos datos, por lo que los resultados de estos son coherentes y comparables. Así, se evitan las divergencias en los resultados.

Mayor valor informativo: Esto se refiere al concepto de sinergia, en donde el valor informativo del conjunto de datos es superior a la suma del valor informativo de los elementos individuales.


7


Mejor y más normalizada documentación: La mayoría de los SGBD proporcionan herramientas para reflejar el contenido semántico de los datos, es decir, incluyen una descripción de los datos dentro del sistema.

Mayor eficiencia en la captura, validación e ingreso de datos al sistema: al no existir redundancias, los datos se capturan y validan una sola vez aumentando el rendimiento del proceso previo al almacenamiento

Reducción del espacio de almacenamiento: por un lado, la disminución de redundancias y las técnicas de compactación hacen que disminuya el espacio en disco. Sin embargo, los diccionarios, referencias, punteros, listas invertidas también ocupan espacio.

6. Desventajas de las bases de datos

Las desventajas de una base de datos relativas a:

Referidas a: Desventajas:

La implantación

Costosa en equipos (lógico y físico)

Implantación larga y difícil

Falta de rentabilidad a corto plazo

Escasa estandarización

Los usuarios Personal especializado

Desfase entre teoría y práctica

Análisis del cuadro anterior

Instalación costosa: Puede implicar el coste elevado en equipos físicos (adquisición de nuevas instalaciones, o ampliaciones de las existentes), como en el lógico (sistemas operativos, programas, compiladores, etc.) así como el coste de adquisición o mantenimiento del SGBD.

Implantación larga y difícil: Debido a las causas mencionadas en la instalación costosa la implantación de un sistema de base de datos puede convertirse en una tarea larga y complicada.

Falta de rentabilidad a corto plazo: Los amplios costes que conlleva la implantación, implica una rentabilidad no a corto, sino a medio, o incluso a largo plazo.

Escasa estandarización: Esto supone una dificultad añadida a los usuarios de la base de datos.

Personal especializado: Es clave la administración de la base de datos, se requiere de conocimientos específicos.

Desfase entre teoría y práctica: muchos ejecutivos asumen que ciertas funcionalidades son ya un hecho, cuando en realidad son estudios teóricos

7. Componentes de la BD

Un sistema de Base de Datos contempla los siguientes componentes:

La base de datos

El Sistema de Gestión de Bases de Datos (SGBD, DBMS) o motor, tal como Oracle, Sybase, SQL Server, Ms-Acces, etc.

Programas de aplicación (Visual Basic, Visual Fox Pro, Power Builder, etc.)

Un conjunto de usuarios (finales, DBA, programadores de aplicaciones, etc.)

Máquinas o PC‟s

Programas utilitarios (generadores de informes, de interfaces, herramientas de desarrollo, de administración, etc.) DBMS: Es la sigla en inglés de Sistema de Administración de Bases de Datos, que corresponde al Software que maneja todos los accesos a la Base de Datos.

8. ¿Para qué sirve una Base de Datos?

Una base de datos permite la realización de consultas, informes filtrado de información, entre otros. Formatos personalizados Cálculos estadísticos Búsquedas de datos Clasificación Resumen y Reportes impresos Páginas web

9. Sistemas de Gestión de Base de Datos (SGBD o DBMS) Un sistema de gestión de bases de datos consiste de una colección de datos interrelacionados y un conjunto de programas para acceder a esos datos. La colección de datos es la base de datos, y es la que contiene información por ejemplo acerca de una empresa determinada. El objetivo principal de un SGBD es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar información en la base de datos. Toda organización puede verse en tres niveles de gestión: operacional, táctico y estratégico. Muchas veces se produce una desconexión de los sistemas que caracterizan a estos niveles, pues constituyen sistemas aislados, sin relación entre ellos. Esto produce un aumento del costo global de creación y mantenimiento del sistema de información, produce redundancias e incoherencias. Esto impide una gestión racional de los datos.


8


La base de datos es un depósito único de datos para toda la organización, por lo que debe ser capaz de integrar los distintos sistemas y aplicaciones, atendiendo a las necesidades de los usuarios en los tres niveles. El objetivo del SGBD es suministrar la interfaz entre el conjunto de los datos y dichos usuarios. El SGBD también debe proporcionar a los otros usuarios (analistas, programadores, administradores) las correspondientes herramientas que les permitan un adecuado desarrollo de sus funciones.

La gestión y las bases de datos. a) Definición del SGBD

El SGBD es un conjunto coordinado de programas, procedimientos, lenguajes, etc. que suministra, tanto a usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.

b) Funciones del SGBD

De Descripción o Definición Debe permitir al administrador de la base especificar los datos que la integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semántica, los controles a efectuar antes de autorizar el acceso a la base, etc., así como las características de tipo físico y las vistas lógicas de los usuarios. Esta función la realiza el lenguaje de definición de datos (LDD), y debe ser capaz de definir las estructuras de datos a los tres niveles (nivel externo, nivel lógico global o conceptual y nivel interno). A nivel interno se define:

o Espacio reservado para la base( volúmenes, cilindros y pistas) o Longitud de los campos o Modo de representación de los datos (binario, decimal, alfanúmerico, etc.) o Caminos de acceso como punteros e índices.

A nivel externo y conceptual, la función de descripción proporciona los instrumentos para la definición de entidades, su identificación, atributos, interrelaciones entre ellas, autorizaciones de acceso, restricciones de integridad, etc. El SGBD, además de describir, debe permitir la correspondencia o mapping entre estos niveles.

De Manipulación Permite a los usuarios de la base (todos) buscar, eliminar o modificar los datos de la base, de acuerdo a las especificaciones y normas de seguridad dadas por el administrador. Esto se realiza mediante el lenguaje de manipulación de datos (LMD), mediante un conjunto de instrucciones (lenguaje huésped) que son admitidas por un lenguaje de programación (lenguaje anfitrión), o bien, mediante un lenguaje autocontenido, que posee todas las instrucciones necesarias para llevar a cabo estas tareas.

De Utilización Reúne todas las interfaces que necesitan los diferentes tipos de usuarios para comunicarse con la base y proporciona un conjunto de procedimientos para el administrador. Algunas de estas funciones de servicio son:

o Cambiar capacidades de los archivos o Obtener estadísticas de utilización respaldos o Cargar y descarga de la base o Seguridad, etc.


9


MODELO RELACIONAL INTRODUCCIÓN. El modelo relacional es un modelo de datos basado en la teoría de las relaciones, en donde los datos se estructuran lógicamente en forma de relaciones (tablas), siendo un objetivo fundamental del modelo mantener la independencia de esta estructura lógica respecto al modo de almacenamiento y a otras características de tipo físico.

Este modelo persigue una serie de objetivos, que se pueden resumir en los siguientes:

Independencia física: es decir, el modo en el que se almacenan los datos no influya en su manipulación lógica y, por

tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento físico.

Independencia lógica: esto es, que el añadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que están accediendo a subconjuntos parciales de los mismos (vistas).

Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en que éste prefiera.

Uniformidad: las estructuras lógicas de los datos presentan un aspecto uniforme, lo que facilita la concepción y manipulación de la base de datos por parte de los usuarios.

Sencillez: las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fácil de comprender y de utilizar por parte del usuario final.

Para conseguir los objetivos citados, Codd introduce el concepto de "relación" (tabla) como una estructura básica del modelo. Todos los datos de la BD se representan en forma de relaciones cuyo contenido varía en el tiempo. ESTRUCTURA DEL MODELO RELACIONAL

RELACION

La relación es el elemento básico en el modelo relacional. Las relaciones se definen de la siguiente manera: DIPLOMATICO(Codigo,Nombre,Nacionalidad,Institución) y se puede representar como una tabla, como vemos en el siguiente ejemplo:

DIPLOMATICO

Codigo Nombre Nacionalidad Institucion

01 Pepe España O.N.U.

02 John EE.UU. O.M.S.

03 Pierre Francia O.N.U.

En ella podemos distinguir un conjunto de columnas, denominadas atributos o campos, que representan propiedades de la misma y que están caracterizadas por un nombre; y un conjunto de filas llamadas túplas que son las ocurrencias de la relación. Existen también unos dominios donde los atributos toman sus valores.

El número de filas de una relación se denomina cardinalidad de la relación y el número de columnas es el grado de la relación. Una relación va a tener una serie de elementos característicos: 1.- No puede haber filas duplicadas, es decir, todas las túplas tienen que ser distintas.

2.-No puede haber nombre de atributos repetidos. 3.- El orden de las filas es irrelevante. 4.-El orden de las columnas es irrelevante. 5.- La tabla es plana, es decir, en el cruce de una fila y una columna sólo puede haber un valor (no se admiten

atributos multivaluados).

DOMINIO Y ATRIBUTO Un dominio D es un conjunto finito de valores homogéneos y atómicos caracterizados por un nombre; decimos homogéneos porque son todos del mismo tipo y atómicos porque son indivisibles.

Todo dominio ha de tener un nombre por el cual nos podamos referir a él y un tipo de datos; así el tipo de datos del dominio "nacionalidades" es una cadena de caracteres de longitud 10.

El dominio "nacionalidades" tiene valores: Española, Francés, Italiana,...


10


Un atributo es el papel que tiene un determinado dominio en una relación.

Es muy usual dar el mismo nombre al atributo y al dominio. En el caso de que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre.

Por ejemplo los atributos „precio_compra‟ y „precio_venta‟ pueden estar definidos sobre el mismo dominio de enteros de longitud 5.

Claves Una clave candidata de una relación es un conjunto no vacío de atributos que identifican unívocamente cada tupla. Una relación puede tener más de una clave candidata. Una clave primaria es aquella clave candidata mínima que identifica de forma unívoca a la relación.( ser indica la clave primaria

subrayando el/los atributos; otra notación es usando el símbolo almohadilla ) Una clave alternativa es aquella clave candidata que no ha sido elegida para ser primaria. Se denomina clave ajena (externa, foránea, secundaria) de una relación R2 al conjunto no vacío de atributos que forman la clave primaria de otra relación R1. Que un atributo sea clave ajena en una tabla significa que para introducir datos en ese atributo, previamente han debido introducirse en la tabla origen. (se indica la clave ajena mediante una línea discontinua o marejada; otra notación es usando el subrayado)

TERMINOLOGÍA DEL MODELO RELACIONAL

• Una base de datos relacional tiene el aspecto de un conjunto de tablas. • Tupla. Es una fila de la tabla que se corresponde con cada ocurrencia de la relación. • Atributo: Igual que en el esquema ER. También se le llaman columnas de la relación. • Grado. Es el número de atributos de la tabla. Todas las tuplas tienen el mismo número de atributos. • Cardinalidad:. Es el número de filas de la tabla. • Dominio: El dominio de los atributos tiene que ser simple: no se admiten atributos multivaluados ni compuestos. a) Relación

Una relación es una tabla con columnas y filas. Un SGBD sólo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles).

ALUMNO matricula nombre Apellidos curso nota

3456 José Pérez 1 15.25 0101 María Antúnez 2 17.80 8743 Lourdes Sánchez 1 14.50 1234 Antonio Soria 3 16.35 5674 Luis Madrid 1 13.20

Ejemplo de relación

En este ejemplo se trata de una tabla denominada ALUMNO, en cuyo ejemplo están presentes cinco tuplas.

La relación es de grado cinco.

Los cinco dominios son conjuntos de valores que representan respectivamente: el número de matrícula, el nombre, los

apellidos, curso y las notas obtenidas por los alumnos. Ejemplo: el Dominio correspondiente a la nota es el conjunto de todas

las notas posibles

La relación Alumno tiene una cardinalidad de cinco

INTENSIÓN Y EXTENSIÓN DE UNA RELACIÓN

tuplas


11


• Intensión de una relación Parte definitoria y estática (invariante en el tiempo) de la relación, es lo que llamaremos esquema de relación

Ejemplo:

CURSO (Cód_curso: Códigos, Nombre: Nombres, N_Horas: Horas, Materia: Materias)

• Extensión Conjunto de tuplas que, en un instante determinado satisfacen el esquema de relación y se encuentran almacenadas en

la base de datos; es lo que se suele llamar, simplemente relación. La extensión varía en el transcurso del tiempo.

Ejemplo:

CURSO

Cód_curso Nombre N_Horas Materias

00012 DISEÑO DE BASE DE DATOS 50 Base de Datos 00034 BASE DE DATOS ORIENTADAS A OBJETOS 30 Base de Datos 00167 SISTEMAS OPERATIVOS 30 Sis. Operativos 01521 ALMACENES DE DATOS 25 Base de Datos 00514 INTRODUCCIÓN AL C++ 25 Lenguajes

ELEMENTOS NO PERMITIDOS: RESTRICCIONES

Son de dos tipos: restricciones inherentes y restricciones semánticas

a) RESTRICCIONES INHERENTES

Son las restricciones derivadas de la misma estructura del modelo, que no tienen que ser definida por el usuario

o No permite la existencia de tuplas duplicadas y de ahí la obligatoriedad de una clave primaria o Integridad de Entidad: Ningún atributo que forme parte de la clave primaria puede tomar valores nulos

b) RESTRICCIONES SEMÁNTICAS

Son restricciones que tiene que definir el diseñador a fin de que el esquema sea un reflejo lo más fiel posible del mundo real: de ahí la importancia de las restricciones en el diseñote la Base de Datos

Por tanto, un Sistema de Gestión de Base de Datos Realacional (SGBDR), al igual que otros sistemas no relacionales, debe incluir facilidades que permitan:

En la fase de definición:

- Describir las restricciones con precisión y sencillez - Las acciones ante una posible violación de una restricción - Verificar la consistencia de las restricciones entre sí mismas

En la fase de manipulación:

- Comprobar que las actualizaciones cumplen las restricciones de integridad - Poner en marcha las acciones indicadas en el caso de que las restricciones non se cumplan

REGLAS DE INTEGRIDAD

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios. Hay además dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial. A


12


a) Regla de integridad de entidades

La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de modo único las tuplas. Que es irreducible significa que ningún subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad.

b) Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas:

Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?

Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena? o Restringir: no se permite borrar la tupla referenciada. o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian

mediante la clave ajena. o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena

(sólo si acepta nulos).

Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena?

o Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada. o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la

modificación a las tuplas que la referencian mediante la clave ajena. o Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena

(sólo si acepta nulos).

c) Reglas de negocio

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio.

Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya tiene los veinte permitidos.

TRANSFORMACIÓN DEL MODELO ENTIDAD-RELACIÓN AL MODELO RELACIONAL

En el proceso de diseño de una base de datos el primer paso consistía en realizar el diseño conceptual para, posteriormente, abordar el diseño lógico que generaba el esquema de la base de datos en el modelo lógico elegido (relacional, jerárquico, de redes u orientado a objetos). Este apartado presenta un procedimiento sistemático para transformar el esquema conceptual resultante de aplicar el modelo entidad-relación al problema de diseño de una base de datos en un esquema relacional. Para poder llevar a cabo esta transformación, es necesario realizar previamente determinadas conversiones que eliminen elementos del modelo entidad-relación no representables en el modelo relacional.

Antes de pasar al modelo relacional, es conveniente analizar el diagrama entidad-relación y comprobar que no existen elementos que no puedan ser representados directamente en el modelo relacional. Para ello pueden seguirse los siguientes pasos:

Preparación de los esquemas conceptuales


13


a) Eliminación de atributos múltiples o multivaluados Todos los atributos múltiples; es decir, los atributos que pueden tomar más de un valor en el dominio en el cual están definidos, se transformarán en un tipo de entidad débil por existencia en la cual mantendrá relación

LIBRO

IdLibroEdición

EditorialPaginas

Fecha

Autor

LIBRO

IdLibroEdición

EditorialPaginas

Fecha

Autor

AUTORESCRIBEM N

IdAutor Nombre

b) Eliminación de atributos compuestos Todos los atributos compuestos asociados con los tipos de entidad y los tipos de interrelación deben ser descompuestos en los atributos simples que formen parte o intervengan en los atributos compuestos correspondientes. En este proceso se eliminará el atributo compuesto correspondiente, quedando los atributos simples definidos

Nombre_completo

EMPLEADO

NombrePila Apellido1 Apellido2

dni

direccion

calle

numerodistrito

provincia

departamento


14


EMPLEADO

NombrePila Apellido1

Apellido2dni

calle

numerodistrito

provincia

departamento

c) Eliminación de jerarquías de generalización. Al hacerlo hay que tener en cuenta que no debe existir pérdida de información. Existen tres posibilidades para realizar la conversión:

c.1 Englobar todos los atributos de la entidad y subtipos en una sola relación. En general se adoptará esta

solución cuando los subtipos se diferencien en muy pocos atributos y las interrelaciones que los asocian con el resto de las entidades del esquema sean las mismas para todos (o casi todos los subtipos), lo cual implica que los subtipos no sean excluyentes

Esta alternativa presenta el inconveniente de generar demasiados valores nulos en los atributos opcionales. También ralentiza el proceso de búsqueda al tener en cuenta todas las tuplas en vez de las que pertenecen a la subentidad deseada. Su única ventaja es que el acceso a una fila que refleje toda la información de una determinada entidad es mucho más rápido (no hace falta combinar varias relaciones).

c.2 Considerar cada subentidad como entidad. Para ello, se añaden los atributos de la entidad genérica a la

subentidad; y la clave primaria de la genérica pasa a serlo de las nuevas entidades creadas. Esta opción es adecuada en el caso de que existan muchos atributos distintos entre los subtipos, además los subtipos sean excluyentes Sus inconvenientes son varios:

a) Se pierde el concepto de la entidad genérica. b) Los accesos a la entidad genérica deben convertirse en accesos a todas las subentidades. c) Los atributos de la entidad genérica son repetidos en cada subentidad. d) Sólo es válida para jerarquías totales y exclusivas. e) Si la entidad genérica tiene alguna relación, ésta debe propagarse a cada subentidad. f) En consecuencia, esta alternativa es válida cuando la jerarquía es total o exclusiva, no importa

el concepto de la entidad genérica en las operaciones y no hay relación entre la entidad genérica y otras entidades.

c.3 Considerar relaciones distintas para cada subtipo, que contengan, además de los atributos propios, los

atributos comunes. Se elegiría esta opción en el caso de que existan muchos atributos distintos entre los subtipos


15


Transformación de los esquemas conceptuales 1. Transformación de atributos de entidades

Cada atributo de una entidad se transforma en una columna de la relación a la que ha dado lugar la entidad. Pero teniendo en cuenta que tenemos atributos identificador principal, otros que son identificadores alternativos y el resto de atributos que no son identificadores

1.1 Atributos identificadores

Los identificadores principales pasan a ser la clave primaria de la relación. Ejemplo: La relación PROFESOR, fruto de la transformación de la entidad del mismo nombre, con su identificador principal (Cod_prof) que pasa a ser la clave primaria

PROFESOR

1.2 Atributos identificadores alternativos

Respecto a los identificadores alternativos, recoge por medio de la cláusula UNIQUE estos objetos, los cuales son soportados por el modelo relacional

1.3 Atributos no identificadores Estos atributos pasan a ser columnas, como los anteriores, de la relación, las cuales tienen permitido tomar valores nulos a no ser que se indique lo contrario

Aplicando la regla 1.1 y 1.2, la transformación de la entidad PROFESOR es la siguiente:

CREATE TABLE profesor (Cód_Profesor, Nombre, DNI NOT NULL , Dirección, Teléfono, Materia, PRIMARY KEY (Cód_Profesor), UNIQUE (DNI))

DNI Nombre Dirección

PROFESOR

DOCTOR NO DOCTOR

(1,1)

(0,1) (0,1)

IdProf

Nombre

Tipo

Año_doc

Materia_doc

c.1 PROFESOR (IdProf, Nombre, …, Tipo, Año_doc, Materia_doc)

c.2 PROFESOR ( IdProf, Nombre, …)

DOCTOR (IdProf, …, Año_doc,Materia¨_doc)

NO_DOCTOR( IdProf, …)

c.3 DOCTOR (IdProf, Nombre,…, Año_doc, Materia_doc)

NO _DOCTOR (IdProf, Nombre,…)

PROFESOR (Cód_prof, Nombre, DNI, dirección, Teléfono, Materia) Esquema

relacional

Diagrama

relacional

PROFESOR

Cód_prof

Nombre

DNI

Dirección

Teléfono

Materia


16


2. Transformación de interrelaciones

2.1 Interrelaciones N:M

Este tipo de interrelación se transforma en una relación que tendrá como clave primaria la concatenación de los Identificadores principales de los tipos de entidad que asocia

En SQL obtendríamos:

CREATE TABLE Imparte (Cód_Profesor , Cód_curso, primary key(Cód_Profesor,Cód_curso), foreign key (Cód_Profesor) references Profesor ON DELETE CASCADE ON UPDATE CASCADE, foreign key(Cód_curso) references Curso ON DELETE CASCADE ON UPDATE CASCADE )

2.2 Interrelaciones 1:N

Existen dos soluciones para la transformación de una interrelación 1:N a) Obligatorio - Obligatorio

Se propaga los identificadores principales del tipo de entidad que tiene de cardinalidad máxima 1 a la que tiene N, desapareciendo el nombre de la interrelación. Este caso se da en la relación es del tipo

DEPARTAMENTO

PROFESOR

Cód_prof

Nombre

DNI

Dirección

Teléfono

Fecha

Cód_dpto

Nombre_dpto

pertenece

(1,n) PROFESOR ( Cód_prof, Nombre, …, Cód_dpto)

DEPARTAMENTO ( Cód_dpto, Nombre_dpto, fecha)

ME/R MR

(1,1)

PROFESOR

PROFESOR

Cód_prof

Nombre

DNI

Dirección

Teléfono

Materia

Cód_curso

Nombre_curso

imparte

(1,n)

(1,n)

PROFESOR ( Cód_prof, Nombre, DNI, dirección, Teléfono, Materia )

IMPARTE ( Cód_curso, Cód_prof )

CURSO ( Cód_curso, Nombre_curso )

ME/R MR

1:N

No admite

valores

nulos (1,1)


17


b) Obligatorio - Opcional

Se transforma en una relación, como si se tratara de una interrelación N:M ; sin embargo en este caso, la clave primaria de la relación creada es sólo la clave primaria de la tabla a la que le corresponde la cardinalidad N.

Es recomendable esta opción si el número de departamentos es de gran cantidad y no se admitan valores nulos

c) Opcional-opcional: Este caso se reduce al de relación obligatoria-opcional.

2.3 Interrelación 1:1

Una interrelación de tipo 1:1 es un caso particular de una N:M o también de una 1:N, por lo que no hay regla fija para la transformación de este tipo de interrelación al modelo relacional, pudiéndose aplicar la regla 2.1 ( con lo que crearíamos una relación) o aplicar la regla 2.2 (esto es, propagar la clave correspondiente) En este último caso, la propagación de la clave puede efectuarse en ambos sentidos. Los criterios para aplicar una u otra regla se basan en la cardinalidades mínimas: a) Obligatoria – Obligatoria

Se integran las dos entidades en una tabla que contiene los atributos y la clave primaria es cualquiera de las de E1 y E2. Si coincidiera, sólo se incluiría una vez en la nueva relación.

DNI Nombre (1,1) (1,1) DNI

Denominación

b) Obligatoria – Opcional

ESTUDIANTE

REALIZA

PROYECTO

DEPARTAMENTO

PROFESOR

Cód_prof

Nombre

DNI

Dirección

Teléfono

Materia

Cód_dpto

Nombre_dpto

pertenece

( 1, n ) PROFESOR ( Cód_prof, Nombre, DNI, dirección, Teléfono, Materia )

DEPARTAMENTO_ PROFESOR ( Cód_dpto, Cod_prof, fecha )

DEPARTAMENTO ( Cód_dpto, Nombre_dpto)

ME/R MR

( 0, 1 )

1:N

Admite valores nulos,

la claúsula NOT NULL

resuelve el problema

ESTUDIANTE ( DNI , Nombre, Denominación )

ME/R

MR

1:1

Fecha


18


Cada entidad se convierte en una relación representada por una tabla, y a la que tiene participación obligatoria se añadiría la clave primaria de la opcional. Las claves primarias de ambas relaciones se mantienen. Suponiendo ESTUDIANTE opcional, el ejemplo resultaría:

Cod_prof Nombre_prof (1,1) (0,1) Cod_dpto

nombre_dpto

c) Opcional-opcional En este caso, se generarán tres relaciones: una para cada entidad y otra para la correspondencia entre ambas. Las entidades no sufriría cambios y la nueva relación incluirá las claves primarias de E1 y E2, así como los atributos de R, si los hubiera. La clave primaria de esta relación recién creada será cualquiera de las de E1 o E2. El ejemplo, sería:

Cod_hombre Nombre (0,1) (0,1) Cod_mujer

nombre

PROFESOR

responsable

DEPARTAMENTO

ME/R

MR

1:1

PROFESOR ( Cód_prof, Nombre )

DEPARTAMENTO ( Cod_dpto, nombre_dpto, Cod_prof)

HOMBRE

matrimoni

o

MUJER

ME/R

MR

1:1

HOMBRE ( Cod_hombre, Nombre)

MATRIMONIO ( Cod_mujer, Cod_hombre, fecha )

MUJER ( Cod_mujer, Nombre)

fecha


19


3. Transformación de dependencias en identificación y en existencia

4. Transformación de tipos y subtipos

En lo que respecta a los tipos y subtipo, no son objetos que se puedan representar explícitamente en el modelo relacional. Ante un tipo de entidad y subtipos caben varias soluciones de transformación al modelo relacional.

5. Transformación de relaciones recursivas

5.1 Relaciones Reflexivas 1:N

Empleado (dni, nombre, dni_supervisor)

dni_supervisor es una clave foránea de dni (de la misma tabla), refleja quien es el jefe y no admite NULL.

CORRIDA

TORO

IdGanadería

Año_nac

Numero

Feria

estoqueado

( 0, 1 )

CORRIDA ( N_orden, Feria, Año, NombrePlaza )

TORO ( IdGanadería, Año_nac, Número , NombreToro, Color, N_orden, Feria, Año)

GANADERÍA (IdGanadería, NombreGan)

ME/R

MR

( 6, n )

N_orden

Año

NombreToro

NombrePlaza

GANADERÍA IdGanadería NombreGan

pertenece

( 1, n )

( 1, 1 )

Color

(1,1)

(1,N)

1:N

supervisa EMPLEADO

DNI

nombre


20


Empleado (dni, nombre)

Supervisa (dni, dni_supervisor)

5.2 Relaciones Reflexivas M:N

Empleado (dni, nombre)

Supervisa (dni, dni_supervisor)

6. Relaciones n-arias. Tienen el mismo tratamiento que las relaciones N:M. Cada entidad se transforma en tabla y se añade una tabla para la asociación que incluya las claves primarias de las entidades participantes en la correspondencia y los atributos de la asociación. La composición de las claves primarias de las entidades es la clave primaria de la nueva relación. Por ejemplo, la siguiente relación ternaria quedaría del modo que muestra la figura:

(1,N)

(1,N)

M:N

supervisa EMPLEADO

DNI

nombre

(1,1)

(1,N)

1:N

supervisa EMPLEADO

DNI

nombre


21


CASOS GESTIÓN DE UNA BIBLIOTECA Desarrolle el modelo Entidad Relación que permita la gestión de una biblioteca con las siguientes características: • El préstamo sólo considera libros ( no incluye: CD‟S, revistas, o cualquier otro medio) • Para efectos del préstamos todos los libros son iguales • De un mismo libro pueden existir varios ejemplares • Los ejemplares de un libro pueden ser de diferentes ediciones (por ejemplo: del libro Fundamentos de Bases de datos de

Korth, pueden existir cinco ejemplares, uno de la segunda edición y cuatro de la tercera edición) • Todos los libros están en español • Un libro puede tener varios autores • Todos los usuarios son iguales y se identifican con un código • Cada usuario tiene derecho a tener prestados hasta 5 libros • Todos los libros prestados deben ser entregados como máximo dos días después del préstamo. Los usuarios que incumplan

esta regla, quedan suspendidos por una semana • Un libro puede tratar de varios temas (Ejemplo: Base de datos, programación orientada a objetos, SQL, etc.) Las consultas más comunes son: • Cuáles libros tienen un usuario, y cuando deben regresarlos • Quien tiene un libro determinado • Libros por tema (Ejemplo: Satélites, microondas, telefonía celular, etc.) • Historia de los libros prestados por un usuario • Historia de los usuarios que prestan un libro • Información general de un libro Desarrolle el esquema conceptual (Modelo Entidad – Relación) , y el esquema lógico (Modelo Relacional) ALQUILER Y COMPRA DE INMUEBLES Se trata de diseñar una base de datos para una red de agencias franquiciadas a TECHNOHOUSE, empresa especializada en el alquiler y compra de inmuebles

Cada agencia tiene un titular propio y un conjunto de vendedores. Tanto el titular como los vendedores sólo pueden pertenecer a una agencia. Sobre las agencias interesa almacenar su dirección, teléfonos (que pueden ser varios), fax, etc. Además, cada agencia tiene asignada una zona de actuación que es única

Las agencias disponen de inmuebles tanto para alquilar como para comprar (incluso ambas cosas), en el primer caso figurará el precio de alquiler y la fianza a depositar, mientras que en el segundo caso, además del precio de venta, se indica si el inmuebles está o no hipotecado

Por otro lado, los inmuebles pueden ser locales comerciales, o pisos. En ambos casos se identifican por un código, e interesa conocer el propietario, la dirección en m2.

Además, en el caso de pisos interesa conocer el número de habitaciones (incluyendo el salón), el número de cuartos de baño,

CONDUCTOR (NCarnet, Nombre, experiencia)

AUTOBUS (matricula, licencia, categoria)

LUGAR ( Provincia, Distrito, actividad)

CON_AUT_LUG ( NCarnet, Matricula, Provincia, Distrito, Fecha)

CONDUCTOR

LUGAR

Provincia Distrito

actividad

NCarnet

Nombre

conduce

( 1, n )

( 1, n )

Fecha AUTOBUS

experiencia

Matricula

Licencia

categoria

( 1, n )

N:N:N


22


el tipo de gas (natural, butano), y si es interior o exterior. Para los locales comerciales se debe conocer si dispone de licencia de apertura

Un cliente puede acudir a varias agencias, en cada una se le asigna un vendedor, que es el encargado de seleccionar los inmuebles que cumplen las características deseadas, y en caso de estar interesado, el cliente debe dar una señal para reservar el inmueble ( o los inmuebles) que desea

Complete los atributos que faltan del modelo Entidad / Relación y transforme al esquema Lógico empleando el Modelo Relacional

GIMNASIO ”Siempre en forma” En el gimnasio se quiere implantar una base de datos para llevar el control de los socios, recursos utilizados, etc. Las especificaciones son las siguientes:

Existen varias salas, de las cuales se quiere guardar información, como los metros cuadrados que ocupa, ubicación y el tipo de sala (cardio, general, muscular). Cada sala se identifica por un número

Hay salas que tienen aparatos y salas que no. En las salas se pueden o no impartir clases

Cada aparato está asignado a una única sala, y de cada uno de ellos se quiere tener almacenado su código, descripción y estado de conservación

También se quiere mantener información relacionada con las clases que se imparten (descripción y día / hora en la que se imparten); cada clase se identifica por un código de clase. Cada clase tiene asignada una sala en la que se imparte y un monitor

De cada monitor se quiere conocer el DNI, nombre, teléfono, si tienen o no titulación y experiencia profesional, así como las clases que pueden impartir (preparación como monitor de aerobic, step, streching, etc.)

De cada socio se quiere conocer el número de socio, nombre, dirección, teléfono, profesión y datos bancarios, así como las clases a las que asiste

El gimnasio dispone también de pistas de squash, de las que se quiere conocer el número de pistas, ubicación y estado. Las pistas de squash pueden ser utilizadas por socios, y existe un servicio de reserva de pista ( en una fecha y a una hora)

Complete los atributos que faltan del modelo Entidad / Relación y transforme al esquema Lógico empleando el Modelo Relacional


23


CASOS DE DESARROLLO Realizar el esquema relacional en base a los siguientes modelos de Entidad Relación 1. El Gimnasio “Siempre en forma” del caso anterior impone las siguientes restricciones:

Las pistas de Squash se consideran salas

Las clases sólo se imparten en salas sin aparatos. Las salas con aparatos siguen clasificándose en sala de cardio, general, etc,


24


2. Colecciones de Mariposas

3. - Gestión de Biblioteca

4.- Gestión de CD‟S Desarrollar un modelo E-R que permita representar el siguiente enunciado El Señor Juan Pérez tiene en su discoteca privada una cantidad considerable de CD‟S y tiene problemas al acceder a una canción en particular dado que emplea mucho tiempo en la búsqueda de esta. A continuación una serie de preguntas y respuestas que entregan más información acerca del problema.

¿Cuántas canciones tiene un CD? Cada CD puede tener una o más canciones Una canción puede aparecer en varios CD‟s Sí, además puede ser interpretada por varios artistas (Grupos o Solistas)


25


Un CD puede tener canciones de varios artistas? Si, existen CD variados.

A cuántos géneros puede pertenecer una canción? Un solo género Por ejemplo: Balada, Rock, Latinoamericanos, etc.

Cómo se identifican los CD‟s? Cada CD tiene un nombre único que lo identifica de los demás CD‟s. En el caso de un álbum con varios CD‟s, suponga que el álbum tiene un nombre y cada CD se referencia como Vol1, Vol2, VOl3, etc. Cada CD pertenece a una casa disquera.

En el caso de CD‟s variados cómo se maneja? Cada canción tiene su intérprete, duración y género

Otros datos: Una canción, por ejemplo “Valio la pena ” puede existir en varios CD‟s interpretada por varios artistas. Una canción tiene un solo autor , y para efectos del ejercicio es una sola persona No hay prestamos de CD‟s Todos los CD‟s son únicamente de música Un CD puede tener la misma canción interpretada por diferentes artistas Caso extremo: Un CD donde aparezca dos o más veces la misma canción interpretada por el mismo artista, Ejemplo: una versión grabada en estudio, otra grabada en vivo y otra un desconectado


26


ALGEBRA RELACIONAL 1.- CONSULTA Y MANIPULACIÓN DE DATOS Existen dos tipos de operaciones que se realizan sobre una base de datos:

Actualizar la base de datos.

Consultar la base de datos. Actualizar la Base de Datos Se entiende por actualizar una base de datos como todas aquellas operaciones que cambian, de alguna manera, la información contenida en la BD. Estas operaciones son tres:

· Inserción de nuevos datos (nueva tupla). · Modificación de datos que ya existían. · Borrado de datos que ya existía.

Consultar la Base de Datos Incluye todas las operaciones que realizan consultas (preguntas) a la información contenida en la base de datos (BD). Al realizar una consulta no se pueden modificar los datos. Las consultas pueden ser más o menos complejas y pueden afectar a una o varias tablas. El álgebra relacional es la técnica que se utiliza para realizar las consultas de una base de datos relacional. En la fase de Diseño de Datos, además de diseñar las estructuras (tablas) en las que se guardará la información, también se deben diseñar las consultas que se realizarán sobre esas tablas. .2.- OPERACIONES DEL ÁLGEBRA RELACIONAL. Las operaciones de álgebra relacional manipulan relaciones. Esto significa que estas operaciones usan una o dos relaciones existentes para crear una nueva relación. Esta nueva relación puede entonces usarse como entrada para una nueva operación. Esto hace más fácil la solución de las consultas, debido a que se puede experimentar con soluciones parciales hasta encontrar la proposición con la que se trabajará. El álgebra relacional define un conjunto cerrado de operaciones que:

- Actúan sobre relaciones. - Producen relaciones como resultados. - Pueden combinarse para construir expresiones más complejas

El álgebra relacional consta de nueve operaciones:

1. Unión 2. Intersección 3. Diferencia 4. Producto 5. Selección 6. Proyección 7. Reunión 8. División 9. Asignación

Las cuatro primeras se toman de la teoría de conjunto de las matemáticas; las cuatro siguientes son operaciones propias del álgebra relacional y la última es la operación de dar un valor a un elemento. 3-OPERADORES DE CONJUNTOS 3.1. compatibilidad respeto a la unión o unión compatible. Se dice que una operación es compatible respecto a la unión o es unión-compatible si Para la definición de las operaciones de conjuntos usaremos las siguientes relaciones R y S:

S=

A B

a1 b1

a2 b2

a5 b5

R=

A B

a1 b1

a2 b2

a3 b2

a4 b4


27


3.2.-Unión. (R S) La unión de dos relaciones R y S, es otra relación que contiene las tuplas que están en R, o en S, o en ambas, eliminándose las tuplas duplicadas. R y S deben ser compatibles respecto a la unión. Intersección (R S). La intersección de dos relaciones R y S, es otra relación que contiene las tuplas que están en R y en S a la vez. R y S deben ser compatibles respecto a la union. DIFERENCIA (R-S). La diferencia de dos relaciones R y S, es otra relación que contiene las túplas que están en R y no está en S. R y S deben ser compatibles respecto a la unión. 3.5.- PRODUCTO (R x S). El producto de dos relaciones R y S, es otra relación que es la concatenación de cada una de las filas de la relación R con cada una de las filas de la relación S. Las relaciones han de ser compatibles respecto al producto.

R S =

A B

a1 b1

a2 b2

a3 b2

a4 b4

a5 b5

R S =

A B

a1 b1

a2 b2

R-S= A B

a3 b2

a4 b4

A B

a1 b1

a2 b2

a3 b2

a4 b4

D d1

d2

d3

A B

D a1 b1 d1

a1 b1 d2

a1 b1 d3

a2 b2 d1

a2 b2 d2

a2 b2 d3

a3 b3 d1

a3 b3 d2

a3 b3 d3

a4 b4 d1

a4 b4 d2

a4 b4 d3

=

R S

R X S


28


.4.-OPERADORES RELACIONALES. 4.1.-Selección ( Predicado( R)) Es un operador unario. Define una relación con los mimos atributos que R y que contiene solo aquellas filas de R que satisfacen la condición especificada (predicado). El predicado está formado por Nombres de atributos.

.4.- Proyección ( x(R)). Es un operador unario. Define una relación que contiene un subconjunto vertical de R con los valores de los atributos especificados en x, eliminando las tuplas duplicadas en el resultado.

.4.- Define una relación que tiene como columnas los campos de R que no está en S y como tuplas, las de R (sólo los campos correspondientes) que están combinadas con todas las tuplas de S. Deben cumplirse las siguientes condiciones:

- grado(R) > grado (S) - - R debe tener, al menos, una tupla. -

El cociente se utiliza cuando se quiere relacionar un elemento (tupla) de una lista con todos los elementos de otra lista. Ejemplo: Lo primero que hacemos es extraer en una tabla todos los códigos de todos los productos, a esta tabla la denominamos A.

R =

Codigo Nombre Ciudad Status

S1 Juan Lopez Granada 20

S2 Jose Sanchez Jaen 15

S3 Antonio Perez Cadiz 20

S4 Jose Lopez Sevilla 25

S6 Carmen Lopez Cordoba 30

S7 Julia Sanchez Granada 25

S8 Juana Perez Jaen 10

S9 Luis Gomez Almeria 35

S10 Maria Galvez Sevilla 30

Codigo Nombre Ciudad Status

S4 Jose Lopez Sevilla 25

S6 Carmen Lopez Cordoba 30

S7 Julia Sanchez Granada 25

S9 Luis Gomez Almeria 35

S10 Maria Galvez Sevilla 30

status>=25

®(r)=

Ciudad Status Granada 20

Jaen 15

Cadiz 20

Sevilla 25

Cordoba 30

Granada 25

Jaen 10

Almeria 35

Sevilla 30

ciudad,status(r)=


29


Tabla A

Código Producto

1035

2241

2249

5818

En una segunda tabla extraemos, de la tabla de ventas, el código del producto y el comercial que lo ha vendido, lo hacemos con una proyección y evitamos traer valores duplicados. El resultado podría ser el siguiente:

Tabla B

Código Comercial Código Producto

10 2241

23 2518

23 1035

39 2518

37 2518

10 2249

23 2249

23 2241

Si dividimos la tabla B entre la tabla A obtendremos como resultado una tercera tabla que: 1. Los campos que contiene son aquellos de la tabla B que no existen en la tabla A. En este caso el campo Código Comercial

es el único de la tabla B que no existen en la tabla A. 2. Un registro se encuentra en la tabla resultado si y sólo si está asociado en tabla B con cada fila de la tabla A

Tabla Resultado

Código Comercial

23

El comercial 23 es el único de la tabla B que tiene asociados todos los posibles códigos de producto de la tabla A. Unión natural (natural join: R * S o R |x| S): El resultado es una relación con los atributos de ambas relaciones y se obtiene combinando las tuplas de ambas relaciones que tengan el mismo valor en los atributos comunes. Normalmente la operación de join se realiza entre los atributos comunes de dos tablas que corresponden a la clave primaria de una tabla y la clave foránea correspondiente de la otra tabla. Método: - Se realiza el producto cartesiano R x S. - Se seleccionan aquellas filas del producto cartesiano para las que los atributos comunes tengan el mismo valor. - Se elimina del resultado una ocurrencia (columna) de cada uno de losatributos comunes Equivalencia con operadores básicos: R |x|P S = P(RxS). En este caso Casos Resuelva el ejercicio propuesto

EJERCICIOS

Consideremos la instancia siguiente de una BD:

Cuál es el resultado de cada una de las siguientes consultas?

1. R S

2. T R


30


3. R T

4. R U

5. R R

6. U – T

7. R – S

8. S – R

9. S – T

10. R – T

11. T – R

12. R – R

13. A,B (R)

14. A (R)

15. C (R)

16. A (S)

17. C (U)

18. A>=2 (R)

19. A<1 (R)


31


MODELO ENTIDAD-RELACIÓN El modelo Entidad Relación fue propuesto por Meter Chen a mediados de los años setenta para la representación conceptual de los problemas y como un medio para representar la visión de un sistema global. Las características actuales de este modelo permiten la representación de cualquier tipo de sistema y a cualquier nivel de abstracción. Este modelo maneja los siguientes conceptos: PRINCIPALES ELEMENTOS DEL MODELO 1. ENTIDAD

Una entidad es una "cosa" u "objeto" del mundo real, con existencia independiente y distinguible de los demás objetos. Cada entidad tiene un conjunto de propiedades y valores que la identifican de forma unívoca. Esta puede ser tanto tangible (existencia física) Ejemplo: Un carro, como intangible (existencia conceptual), ejemplo: Un curso universitario. Fig. Representación de entidades fuertes Fig. Representación de una entidad débil TIPOS DE ENTIDADES: a) Entidades Fuertes: Son independientes no necesitan la existencia de otras entidades.

Ejemplo: la entidad PERSONA, EMPLEADO b) Entidades Débiles: Su existencia depende de otra entidad. Ejemplo: la entidad ocupacion depende la

existencia de una entidad persona, ya que sin esta no tendría sentido.

2. INTERRELACIÓN Se entiende por interrelación una asociación, vinculación o correspondencia entre entidades

Fig. Representación la relación imparte entre PROFESOR y CURSO

Fig. Dos tipos de entidad entre los que existen dos tipos de interrelación

3. ATRIBUTO

Las propiedades que califican y le dan vida a la entidad se denominan atributos. Ejemplo: la entidad persona se puede describir por las siguientes propiedades: cédula, nombre, dirección, sexo, peso, altura, color, tipo de sangre, salario

CURSO PROFESOR Imparte

Imparte

CURSO PROFESOR

Recibee

CURSO PROFESOR EDICIÓN


32


TIPOS DE ATRIBUTOS Simples: No divisible, es decir es un atributo atómico. Ejemplo: El atributo DNI, su propiedad no tiene sentido dividirla, no tendrá significado para la entidad, ya que la concepción de este es un número indivisible. A continuación se muestra dos formas de representar los atributos simples:

Compuesto: Está conformado por un conjunto de partes que en el momento de dividirlas pueden formar otros atributos sin perder el sentido básico de la propiedad que está calificando la entidad. Ejemplo: los atributos nombre, dirección pueden estar conformados en su naturaleza funcional por varias partes. Si tomáramos el atributo nombre con un valor de: JUAN PEREZ CORREA, sin perder la propiedad del mismo, se podrán crear otros dos atributos simples tales como: primer_apellido, segundo_apellido. Así se tendrá: (nombre, JUAN), (primer_apellido, PEREZ), (segundo_apellido, CORREA).

CURSO

PROFESOR

Imparte

Cod_prof Nombre DNI Dirección Fecha_nac

Cod_curso Nombre_curso Núm_horas

Fecha_inicio

Fecha_terminación

dni dni

nPila

pApellido

sApellido

PERSONA

nombre

nombre direccion

PERSONA

telefono

nPila pApellido sApellido

direccion

telefono


33


Monovaluados (univalorados): Son atributos que en el transcurso del tiempo sólo toman un valor para una entidad en particular. Ejemplo: El atributo dni, solo toma un valor para una entidad persona en particular.

Multivaluados (multivalorados): Son atributos que en el transcurso del tiempo pueden tener un conjunto de valores para una entidad en particular. Ejemplo: El atributo Grado_Academico para el conjunto de entidades persona puede tomar diferentes valores desde 0 o primaria o medio, entre otros.

Almacenado Son atributos cuyo valor no depende de los valores de otros atributos o entidades

Derivado: Son atributos cuyo valor depende de los valores de otros atributos o entidades. Ejemplo: el atributo salario puede derivarse a partir del cálculo de los siguientes valores: PARAMETROS (salario_base, 5000), NOVEDADES (nro_horas_trabajadas, 240), el valor que tendría el atributo en un instante en el tiempo será: PERSONA (salario,1200000).

4. REPRESENTACIÓN DE LOS ATRIBUTOS EN LOS TIPOS DE ENTIDAD

1era. Representación:

Grado_aca

d

Grado_acad

dni dni

edad Fech_nac

Fech_nac Fech_nac

Año

Num_Matricula

ESTUDIANTE

Cod_Estudiante

Nombre

ESTUDIANTE Nombre

Dirección

Año

Num_Matricula

Cod_Estudiante

Dirección

atributo simple

Identificador principal o atributo clave


34


2da. Representación

Cod_estudiante

ESTUDIANTE

NombreDireccion

Año Num_Matricula

5. DOMINIO

Es el conjunto de todos los valores posibles que puede tomar un atributo. Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. Por ejemplo, "matrícula" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres

6. RELACIÓN

Una relación se puede definir como una asociación entre entidades. Por ejemplo:

La entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relación "está pedido".

La entidad "alumno" puede estar relacionada con la entidad "curso" por la relación "está inscrito".

Una relación también puede tener atributos. Por ejemplo:

La relación "está inscrito" puede tener los atributos "semestre" y "nota de aprobación". Usando esta notación, podemos ahora hacer el diagrama E-R del ejemplo anterior de los alumnos y los cursos matriculados.

6.1 GRADO

El grado de una relación es el número de tipos de entidad que participan Ejemplo: Grado 2 (binario) y grado 3 (ternario)

6.2 CARDINALIDAD

Uno a uno, y se representa 1:1, si a cada ocurrencia de A le corresponde como máximo una ocurrencia de B, y viceversa

Atributo simple

clave


35


Uno a muchos, y se representa 1:M, si a cada ocurrencia de A le pueden corresponder varias de B, pero a cada ocurrencia de B sólo le corresponde una de A como máximo. Si la asociación se entendiera de B con A, la relación sería M:1.

Muchos a muchos y se representa M:M, si a cada ocurrencia de A le pueden corresponder varias de B, y viceversa.

7. TIPOS DE INTERRELACIÓN INTERRELACIÓN REFLEXIVA (RECURSIVA)

Son relaciones unarias y, por tanto, consideran que en el tipo de interrelación se ve involucrado un único tipo de entidad

INTERRELACIÓN EXCLUSIVA

Existe una interrelación exclusiva con respecto a un tipo de entidad que participa en ambas interrelaciones cuando cada ejemplar de dicho tipo de entidad sólo puede pertenecer a uno de los tipos de la interrelación, pero en el momento en que pertenezca a uno ya no podrá pertenecer a otro.

CASOS COMPAÑÍA: Suponga que estamos modelando los datos de una COMPAÑIA. La base de datos COMPAÑIA debe mantener información sobre los empleados de la compañía, los departamentos y los proyectos. La descripción del mini-mundo (la parte de la compañía a ser representada en la base de datos) es la siguiente:

La compañía está organizada en departamentos. Cada departamento tiene un nombre único. un número único, y un empleado particular quien lo administra. Se quiere saber la fecha en que el empleado administrador empezó a hacerse cargo del departamento. Un departamento puede tener varios locales.

Cada departamento controla un cierto número de proyectos. Cada proyecto tiene un nombre y número únicos, y un local.

Para cada empleado se desea tener su nombre, dni, dirección, salario, sexo y año de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios proyectos, los que no son necesariamente controlados por el mismo departamento. Se quiere saber el número de horas semanales que un empleado trabaja en cada proyecto. Se quiere además saber cuál es el supervisor directo de cada empleado.

Se desea conocer las personas dependientes de cada empleado para propósitos de seguros. De cada dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relación con el empleado.

La siguiente figura muestra el esquema de esta base de datos, a través de una notación gráfica llamada diagrama ER. LOS RESIDUOS TÓXICOS Se desea abordar la problemática ambiental de los residuos tóxicos y peligrosos cuya incorrecta gestión produce daños de gran importancia en el medio ambiente y en la salud del ser humano. La información a contemplar es la que corresponde desde que es producido el residuo por un centro o una empresa productora hasta que éste se encuentre en un lugar seguro, en donde recibe un tratamiento especial que puede ser la incineración, almacenamiento en depósitos de seguridad, etc. En el sistema de información se desea considerar la información de los productores de residuos, los residuos, las empresas que transportan los residuos hasta los lugares seguros y el traslado de los residuos teniendo en cuenta el tipo de transporte, el envase, etc. Es conveniente tener los siguientes supuestos semánticos: SUPUESTO1: Una empresa productora produce un número amplio de residuos constituido por un número variable de constituyentes químicos

Imparte

CURSO PROFESOR

Recibee

TEMA

consta

M N

N M


36


SUPUESTO2: Más de una empresa productora puede producir residuos con igual número de constituyentes químicos y con las mismas o distintas cantidades SUPUESTO3: Las empresas productoras asignan un código único a los residuos que producen, lo que les permite diferenciar distintas producciones de los mimos productos. Además más de una empresa puede asignar el mismo código a los residuos que produce SUPUESTO 4: Los residuos pueden ser trasladados en su totalidad (cantidad total del mismo) o en partes, o no ser trasladado nunca. SUPUESTO 5: En cada traslado de residuos la cantidad que se traslada de los mismos es enviada a un único destino SUPUESTO 6: En una misma fecha las empresas productoras pueden ordenar más de un traslado de un mismo o distinto residuo (cantidades parciales del mismo) a un mismo o distinto destino SUPUESTO 7: En cada traslado puede intervenir más de una empresa transportista usando el mismo o distinto transporte , por lo que resulta interesante conocer tanto tanto el medio de transporte utilizado como los kilómetros realizados, así como el coste de trabajo SUPUESTO8: El residuo se traslada en un tipo de envase determinado por la empresa productora y que no varía a lo largo de su traslado SUPÙESTO 9: Es interesante conocer la fecha de llegada a destino y el tratamiento a que se someten los residuos una vez alcanzado el mismo SUPUESTO10: por seguridad se considera que en un traslado sólo puede trasladarse un residuo de una empresa productora

Nombre

EMPLEADO

Sexo

Direccion

NombrePila Apellido1 Apellido2

Salario

NombrePila

FechN

DNI

TRABAJA_PARAN DEPARTAMENTO

Nombre

1

Número

Localizaci

ones

ADMINISTRA1 1

FechInicio

PROYECTO

CONTROLA

1

N

TRABAJA_PARA

Horas

M

N

SUPERVISA

1

N

DEPENDIENTE

TIENE

1

N

Nombre

Número

Localización

Nombre

Sexo

FechaN

Relación

En este diagrama los rectángulos representan conjuntos de entidades, los elipses representan atributos y los rombos representan conjuntos de relaciones


37


SEGUNDA UNIDAD

DISEÑO DE LA BASE DE DATOS Introducción

A finales de la década de 1960, cuando las bases de datos entraron por primera vez en el mercado de software, los diseñadores de software actuaban como artesanos, con herramientas muy primitivas: diagramas de bloques y estructuras de registros y el diseño de Base de datos se confundía frecuentemente con la implantación de la base de datos. Dicha situación ahora ha cambiado: los métodos y los modelos del diseño de datos han evolucionado paralelamente con el progreso de la tecnología en los sistemas de base de datos. Asimismo El diseño de la Base de datos es una actividad esencial en el desarrollo de Sistemas de Información

1. El diseño de la Base de Datos en el ciclo de vida de los sistemas de información

Sistema de Información: Es un grupo de personas, procedimientos y equipos diseñados, construidos, operados y mantenidos para recoger, registrar, procesar, almacenar, recuperar y visualizar información

Sistemas de gestión de Base de Datos: Son paquetes de software para la gestión de datos; en particular para almacenar, manipular y recuperar datos en un computador

Las Bases de datos son sólo uno de los componentes de los sistemas de información, que también incluyen programas de aplicación, interfaces para usuarios y otro tipo de paquetes de software. Sin embargo, las bases de datos son esenciales para la supervivencia de cualquier organización, porque los datos estructurados constituyen un recurso esencial para todas las organizaciones El típico ciclo de vida de un sistema de información se muestra en la Fig 2.1, a continuación se detalla las fases: 1. Estudio de Factibilidad: Trata de determinar la rentabilidad de las distintas alternativas de diseño de

sistemas de información y las prioridades de los diversos componentes del sistema.

COMPETENCIA Implementa en un gestor de bases de datos basados en arquitectura Cliente/Servidor y Administra base de datos corporativa


38


RECOLECCIÓN Y ANALISIS DE REQUERIMIENTOS

DISEÑO CONCEPTUAL

DISEÑO LÓGICO (TRANSFORMACIÓN DEL MODELO DE DATOS)

Mundo real

2. Recolección y análisis de requerimientos: Se ocupa de la misión del sistema de información, es decir las áreas de aplicación del sistema dentro de una empresa y los problemas a resolver. Los usuarios describen sus necesidades a los diseñadores y esas descripciones se le conoce como especificación de requerimientos.

3. Diseño: Se ocupa de la especificación de la estructura del sistema de información. Se distingue el diseño de la base de datos (estructura de la BD) y el diseño de las aplicaciones (programas de aplicación)

4. Creación de Prototipos: El prototipo permite a los usuarios verificar si el sistema de información satisface sus necesidades

5. Implantación: Se refiere la programación de la versión final y operativa del sistema de información 6. Validación y prueba: Procedimiento mediante el cual se garantiza que cada fase del desarrollo es de

calidad aceptable 7. Operación: Se empieza con la carga inicial de los datos y termina cuando el sistema se vuelve obsoleto y

tiene que ser reemplazado, además se necesita mantenimiento para mejorarlo.

2. Fases del diseño de la base de datos

El diseño de la Base de datos se descompone en diseño conceptual, diseño lógico y diseño físico como lo muestra la siguiente Fig. 2.2

Estudio de

factibilidad

Recolección y análisis

de requerimientos

Diseño

Creación de

prototipos

Implantación

Validación

y prueba

Operación

Fig. 2.1 Ciclo de vida de un Sistema de Información

Requerimientos de la base de datos

Esquema conceptual

en un modelo de datos de alto nivel

(por ejemplo: modelo E/R)

Independiente de

S.G.B.D.

Esquema lógico

(en el modelo de datos de S.G.B.D.)

Específico para

S.G.B.D.


39


DISEÑO FÍSICO

a) Recolección y análisis de requerimientos

Los diseñadores entrevistan a los futuros usuarios de la base de datos para recoger y documentar sus necesidades de información.

b) Diseño conceptual

Parte de la especificación de todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel. El esquema conceptual contiene una descripción detallada de los requerimientos de información de los usuarios (información de la base de datos), y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones. Para el curso utilizaremos diseño de esquemas conceptuales el modelo E-R (entidad-relación), que describe los datos cono entidades, vínculos (relaciones) y atributos.

c) Diseño lógico de la base de datos (transformación de modelo de datos)

El siguiente paso en el proceso de diseño consiste en implementar de hecho la base de datos con un S.G.B.D. comercial, transformando el modelo conceptual al modelo de datos empleados por el S.G.B.D. (jerárquico, red o relacional). En el desarrollo del curso haremos la implementación con un S.G.B.D. relacional, por ser el modelo más utilizado por las empresas en la actualidad.

d) Diseño físico de la base de datos

Parte del esquema lógico y da como resultado el esquema físico. El esquema físico especifica las estructuras de almacenamiento internas y los métodos usados para tener un acceso efectivo a los datos. Por esta razón el diseño físico se adapta a un sistema DBMS específico.

GESTORES DE BASES DE DATOS 1. DEFINICIÓN

Un Sistema Gestión de Bases de Datos –SGBD- (Data Base Management System DBMS) consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a esos datos. El Objetivo primordial de un SGBD es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar información de la base de datos. (KORTH, 1995) “El sistema de gestión de la base de datos (SGBD) es una aplicación que permite a los usuarios definir, crear y mantener la base de datos, y proporciona acceso controlado a la misma.” (MÁRQUES, 2001)

Esquema interno

(para el mismo S.G.B.D.)

Fig. 2.2 Enfoque orientado a los datos para el diseño de la BD


40


En el esquema se observa que los usuarios interactúan con una aplicación (por ej. un sistema integrado de gestión o un paquete contable) que utiliza un SGBD para procesar las consultas, el cual accede a los metadatos y a la base de datos correspondiente

Metadatos: Son datos acerca de los datos presentes en la base de datos.

Dato Tipo Longitud

Num Numérico 4

Nombre Alfabético 20

2. FUNCIONES BÁSICAS DE UN SGBD

Un SGBD debe incluir por lo menos las siguientes funciones (DATE, 1993): 2.1 Definición de los Datos. El SGBD debe ser capaz de aceptar las definiciones de datos en versión fuente

y convertirlas en la versión objeto. El SGBD debe incluir componentes procesadores para cada uno de los lenguajes de definición de datos (LDD). (DATE, 1993).

2.2 Manipulación de los Datos. El SGBD debe atender las solicitudes de los usuarios para extraer, actualizar, adicionar o suprimir datos. El SGBD debe incluir un componente procesador del Lenguaje de manipulación de datos (LMD). (DATE, 1993).

2.3 Seguridad e Integridad de los Datos. El SGBD debe supervisar las solicitudes de los usuarios y rechazar los intentos de violar las medidas de seguridad e integridad definidas por el Administrador de la Base de Datos DBA. (DATE, 1993).

2.4 Recuperación y concurrencia de los datos. El principal objetivo de la implantación de una base de datos es poner a disposición de un gran número de usuarios en conjunto integrado de datos, estos datos

El tipo de datos puede ser Numérico,

alfabético, fecha, lógico (Sï /NO).

La longitud indica la cantidad máxima

de caracteres que puede asumir el

dato.


41


podrán ser manipulados por los diferentes usuarios y es ahora cuando se debe garantizar la coherencia de los datos después de las diversas manipulaciones. (DATE, 1993).

3. EL MODELO DE ARQUITECTURA DE BASES DE DATOS.

Las bases de datos respetan la arquitectura de tres niveles definida, para cualquier tipo de base de datos, por el grupo ANSI/SPARC. En esta arquitectura la base de datos se divide en los niveles externo, conceptual e interno (KORTH y SILBERSCHATZ, 1994:5; MIGUEL y PIATTINI, 1993: 83-107; MOTA, CELMA y CASAMAYOR, 1994: 11-12):

Fig. Niveles de la arquitectura de bases de datos.

a) Nivel interno: Es el nivel más bajo de abstracción, y define cómo se almacenan los datos en el soporte físico, así como los métodos de acceso. Se describe la estructura física de la base de datos mediante un esquema interno, se especifica mediante un modelo físico y describe todos los detalles para el almacenamiento de la base de datos, así como los métodos de acceso.

Estructura física de almacenamiento

Todos los detalles de cómo el DBMS utiliza: el disco duro la memoria, etc.

Tema principal: El sistema debe ser rápido en responder y ser eficiente en el uso de espacio

Administrador de la base de datos

b) Nivel conceptual: Es el nivel medio de abstracción. Se trata de la representación de los datos realizada por la organización, que recoge las vistas parciales de los requerimientos de los diferentes usuarios y las aplicaciones posibles. Se configura como visión organizativa total, e incluye la definición de datos y las relaciones entre ellos.

En ocasiones puede encontrarse el nivel conceptual divido en dos niveles, conceptual y lógico. El primero de ellos corresponde a la visión del sistema global desde un punto de vista organizativo independiente, no informático. El segundo correspondería a la visión de la base de datos expresada en términos del sistema que se va a implantar con medios informáticos.

Estructura lógica de almacenamiento

Diseño conceptual de la base de datos: Tablas, columnas, etc.

Tema principal: El diseño debe reflejar conceptualmente el problema a modelar

Administradores de datos c) Nivel externo: Es el nivel de mayor abstracción. A este nivel corresponden las diferentes vistas parciales que

tienen de la base de datos los diferentes usuarios. En cierto modo, es la parte del modelo conceptual a la que tienen acceso.

Vistas sobre las tablas

Requiere sólo acceso parcial a los datos

Público objetivo: Desarrolladores de aplicaciones, Usuarios finales

Tema principal: Cada vista debe reflejar adecuadamente la parte de los datos que interesa a cada uno

El modelo de arquitectura propuesto permite establecer el principio de independencia de los datos. Esta independencia puede ser lógica y física. Por independencia lógica se entiende que los cambios en el esquema lógico no deben afectar a los esquemas externos que no utilicen los datos modificados. Por independencia física se entiende que el esquema lógico no se vea afectado por cambios realizados en el esquema interno, correspondientes a modos de acceso, etc.

4. LENGUAJES DEL SGBD El SGBD incorpora como herramienta fundamental dos lenguajes


42


El lenguaje de definición de datos (DDL, Data Definition Language) provee de los medios necesarios para definir los datos con precisión, especificando las distintas estructuras.

Acorde con el modelo de arquitectura de tres niveles, habrá un lenguaje de definición de la estructura lógica global, otro para la definición de la estructura interna, y un tercero para la definición de las estructuras externas.

El lenguaje de manipulación de datos (DML, Data Manipulation/ Management Language), que es el encargado de facilitar a los usuarios el acceso y manipulación de los datos. Pueden diferenciarse en procedimentales (aquellos que requieren qué datos se necesitan y cómo obtenerlos) y no procedimentales (que datos se necesitan, sin especificar como obtenerlos), y se encargan de la recuperación de los datos almacenados, de la inserción y supresión de datos en la base de datos, y de la modificación de los existentes.

5. COMPONENTES DE UN SISTEMA DE GESTIÓN DE BASE DE DATOS. Un Sistema de Gestión de Base de Datos se divide en módulos que tratan cada una de las responsabilidades del sistema general. Los componentes funcionales de un SGBD (KORTH, 1995) incluyen:

a) Procesador de Consultas. Traduce sentencias en un lenguaje de consultas a instrucciones de bajo nivel

que entiende el gestor de la base de datos. b) Gestor de la Base de Datos. Proporciona la interfase entre los datos de bajo nivel almacenados en la

base de datos y los programas de aplicación y las consultas que se hacen en el sistema. c) Gestor de Archivos. Gestiona la asignación de espacio en la memoria del disco y de las estructuras de

datos usadas para representar la información almacenada en disco. d) Pre compilador del Lenguaje de Manipulación de Datos DML. Convierte las sentencias en DML

incorporadas en un programa de aplicación en llamadas normales a procedimientos en el lenguaje principal. e) Compilador del Lenguaje de Definición de Datos DDL. Convierte sentencias en DDL en un conjunto de

tablas metadatos o “datos sobre datos”. f) Gestor del Diccionario de Datos. Almacena metadatos sobre la estructura de la base de datos.

6. COMPONENTES DEL GESTOR DE LA BASE DE DATOS Los principales componentes del gestor de la base de datos son los siguientes (MARQUÉS 2001): a) Control de autorización. Este módulo comprueba que el usuario tiene los permisos necesarios para llevar

a cabo la operación que solicita. b) Procesador de comandos. Una vez que el sistema ha comprobado los permisos del usuario, se pasa el

control al procesador de comandos.


43


c) Control de la integridad. Cuando una operación cambia los datos de la base de datos, este módulo debe comprobar que la operación a realizar satisface todas las restricciones de integridad necesarias.

d) Optimizador de consultas. Este módulo determina la estrategia óptima para la ejecución de las consultas. e) Gestor de transacciones. Este módulo realiza el procesamiento de las transacciones. f) Planificador (scheduler). Este módulo es el responsable de asegurar que las operaciones que se realizan

concurrentemente sobre la base de datos tienen lugar sin conflictos. g) Gestor de recuperación. Este módulo garantiza que la base de datos permanece en un estado consistente

en caso de que se produzca algún fallo. h) Gestor de buffers. Este módulo es el responsable de transferir los datos entre memoria principal y los

dispositivos de almacenamiento secundario. A este módulo también se le denomina gestor de datos.

CLASIFICACIÓN DE LOS SISTEMAS DE GESTIÓN DE BASE DE DATOS Los sistemas de Gestión de Base de Datos se clasifican según:

a) Modelo lógico en el que se basan:

Modelo Jerárquico.

Modelo de Red.

Modelo Relacional.

Modelo Orientado a Objetos. b) Número de usuarios

Monousuario.

Multiusuario. c) Número de sitios

Centralizados.

Distribuidos: Homogéneos, Heterogéneos. d) Ámbito de aplicación

Propósito General.

Propósito Específico ¿Qué diferencias hay entre los diferentes gestores de bases de datos ? Oracle:

Integridad referencial, rapidez en las consultas dada por el número de accesos concurrentes que soporta a una gran cantidad de información, se puede realizar una copia de seguridad sin necesidad de paralizar la web y es multiplataforma

Oracle para web puede salir por unos 5.000 euros

Para usarlo tendremos que disponer de un servidor exclusivo para nosotros con las implicaciones que supone a nivel técnico y objetivos a largo plazo. La web de una gran empresa, que se puede permitir disponer de técnicos para controlar la seguridad del servidor, que necesita soportar múltiples conexiones a su base de datos, cuyos visitantes interactúan con una importante cantidad de información, podría, desde luego, elegir Oracle como su gestor de base de datos.

SQL

Con SQL tendremos que alojar nuestra web en un servidor con entorno Windows,

Con SQL tendremos que adquirir la versión que utilicemos

MySql

MySql puede trabajar tanto con Windows como con Linux

MySql es un software gratuito

Consume muy pocos recursos de CPU y memoria. Muy buen rendimiento.

MySql se encuentra en el otro extremo de la oferta. Es la opción que nos plantean todos los servidores de hosting gratuito que soportan bases de datos y es casi impensable encontrar una empresa de hosting de pago que no lo soporte

Tamaño del registro sin límite

Buena integración con PHP

Utilidades de administración (phpMyAdmin)

Buen control de acceso usuarios-tablas-permisos MODELOS DE BASE DE DATOS 3.1 Introducción


44


Los modelos de datos son vehículos para describir la realidad, asimismo los programadores usan modelos de datos para construir esquemas, los cuales son representaciones de la realidad. Las abstracciones ayudan al programador a entender, clasificar y modelar la realidad. El modelo de Entidad – relación es una herramienta fundamental que se usa en el diseño de la Base de Datos.

3.2 Abstracciones en el diseño conceptual de bases de datos 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 pertinentes, es decir se fija la atención en las propiedades consideradas esenciales de un conjunto de cosas y desechar sus diferencias. Ejm: el concepto carro es un proceso de abstracción, lo que hace excluir todos los detalles de la estructura tales como: llantas, parabrisas, frenos, etc. El diseño conceptual de bases de datos se usan tres tipos de abstracciones: clasificación, agregación y generalización:

a) Abstracción de clasificación

La abstracción de clasificaciones usa para definir un concepto como una clase de objetos de la realidad caracterizados por propiedades comunes

Ejm: el concepto de bicicleta es la clase cuyos miembros son todas las bicicletas (la bicicleta roja, la bicicleta de Carla, etc.)

Ejm: Semana Lunes Martes ……. Viernes

b) Abstracción de agregación

Define una nueva clase a partir de un conjunto de clases que representan sus partes o componentes

Ejm: a partir de las clases RUEDA, PEDAL, MANILLAR, etc. se forma la clase BICICLETA

Ejm: MESA SILLA MUEBLE MARRÓN Mesa Mesa Silla Silla marrón blanca marrón verde

c) Abstracción de generalización La clase genérica es como la raíz y las subclases como hojas. La abstracción de generalización, a pesar de ser muy común no se usa en muchos modelos de datos, pero muy útil por la cualidad de herencia (todas as abstracciones para la clase genérica son heredadas por las clases sub – conjuntos

Ejm: PERSONA

HOMBRE MUJER

Ejm: PERSONA NOMBRE SEXO HOMBRE SITUACIÓN MILITAR

3.3 Modelos de datos

Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos. Los modelos de datos se dividen en tres grupos:

Modelos lógicos basados en objetos.

Modelos lógicos basados en registros.

Modelos físicos de datos.

3.3.1 Modelos lógicos basados en objetos


45


Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación. Modelo Entidad-Relación ( E – R )

Este modelo representa a la realidad a través de entidades, que son objetos que existen y que se distinguen de otros por sus características, por ejemplo: un alumno se distingue de otro por sus características particulares como lo es el nombre, o el numero de control asignado al entrar a una institución educativa, así mismo, un empleado, una materia, etc. El modelo Entidad – Relación, asimismo utiliza conceptos como atributos y relaciones.

Atributo: Representa alguna propiedad o característica de una entidad Ejm: el

nombre, dirección teléfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, número de seguro social, departamento, etc., son atributos de la entidad empleado

Relación: Describe una interacción entre dos o más entidades a través de una relación Ejm: la relación de un alumno y sus notas, trabajo entre un empleado y su oficina.

Caso: Consideremos una empresa que requiere controlar a los vendedores y las ventas que ellos realizan; de este problema determinamos que los objetos o entidades principales a estudiar son el empleado (vendedor) y el artículo (que es el producto en venta), y las características que los identifican son: Empleado: Artículo: Nombre Descripción Cargo Costo DNI Stock Dirección La relación entre ambas entidades la podemos establecer como Venta. Para representar gráficamente en un modelo E-R, se emplean símbolos:

Concepto Representación diagramática

Entidad

Interrelación

Atributo

Así nuestro ejemplo anterior quedaría representado de la siguiente forma:


46


Cardinalidades de relaciones

Relación Uno a Uno Es la relación de pertenencia de uno a uno Ejm: la relación entre un automóvil y tarjeta de circulación

Relación muchos a muchos. Es la relación que se da de muchos a muchos Ejm: la relación de factura producto

3.3.2 Modelos lógicos basados en registros Se utilizan para describir datos en los niveles conceptual y físico. Estos modelos utilizan registros e instancias para representar la realidad, así como las relaciones que existen entre estos registros. A diferencia de los modelos de datos basados en objetos, se usan para especificar la estructura lógica global de la base de datos y para proporcionar una descripción a nivel más alto de la implementación. Los tres modelos de datos más ampliamente aceptados son: - Modelo Relacional - Modelo de Red - Modelo Jerárquico

Modelo relacional En este modelo se representan los datos y las relaciones entre estos, a través de una colección de tablas, en las cuales los reglones (tuplas o filas) equivalen a cada uno de los registros que contendrá la base de datos y las columnas corresponden a las características (atributos) de cada registro localizado en la tupla; Considerando nuestro el caso anterior del empleado y el artículo:

Tabla: EMPLEADO

Nombre Cargo DNI Dirección

SALAS ARROYO María Vendedor 40950255 Av. Huancavelica No. 875 – Hyo

PÉREZ ALVAREZ Carlos Vendedor 40900055 Jr. Ayacucho No. 142 – Hyo

BELTRAN CHAVEZ Karen Vendedor 20802055 Av. Huancavelica No. 275 - Hyo

Tabla: ARTICULO

Codigo Descripcion Costo

A001 LAPICERO 3.00

A002 FOLDER 7.00

A003 HOJAS 15.00

Una vez descrito las tablas estableceremos las relaciones, para lo cual es necesario definir una llave primaria

Empleado Vende

Articulo

Descripción

Costo

Codigo

Nombre

Cargo

Dirección

DNI

Atributos


47


Llave primaria: Es un atributo el cual definimos como atributo principal, es una forma única de identificar a una entidad. Ahora si, las formas de representar las relaciones en este modelo son: Haciendo una tabla que contenga cada una de las llaves primarias de las entidades involucradas en la relación Vende. Tomando en cuenta que la llave primaria del empleado es su DNI, y la llave primaria del articulo es Codigo

DNI Codigo

40950255 A001

40950255 A002

40900055 A003

40900055 A001

20802055 A002

Modelo red

Este modelo representa los datos mediante colecciones de registros y sus relaciones se representan por medio de relaciones, los cuales pueden verse como registros. Los registros se organizan en un conjunto de gráficas arbitrarias. Ejemplo:

Juan Pérez Vendedor 5,000 PECJ500922XYZ C001

PECJ500922XYZ C00

1

Nora Pérez Vendedor 5,000 MEAN761014ABC B300

PECJ500922XYZ B30

0

Modelo jerárquico

Es similar al modelo de red en cuanto a las relaciones y datos, ya que estos se representan por medio de registros y sus relaciones. La diferencia radica en que están organizados por conjuntos de árboles en lugar de gráficas arbitrarias.

Juan Pérez Vendedor 5,000 PECJ500922XYZ

C001 PECJ500922XYZ

C001

Nora Pérez Vendedor 5,000 MEAN761014ABC B300

PECJ500922XYZ

B300

3.3.3 Modelos físicos de datos

Se usan para describir a los datos en el nivel más bajo, aunque existen muy pocos modelos de este tipo, básicamente capturan aspectos de la implementación de los sistemas de base de datos. Existen dos clasificaciones de este tipo que son:

Modelo unificador Memoria de elementos.

3.4 MODELO ENTIDAD RELACIÓN Este modelo se basa en una representación gráfica de una serie de entidades relacionadas entre sí, este modelo permite distinguir a simple vista, las relaciones existentes entre las distintas entidades Los elementos que lo componen son los siguientes:

Entidades Es cualquier objeto del mundo real con existencia propia, sobre el cual queremos tener información en una base de datos”. Una entidad puede ser un objeto con existencia física (PERSONA, CASA, CLIENTE, EMPLEADO, etc.) o un objeto con existencia conceptual (EMPRESA, CURSO, etc.) Tipos de entidades i) Fuertes (o regulares), Son aquellas que tienen existencia por si mismas (Por ejemplo, EMPLEADO).

Las entidades fuertes se representan como se ha dicho con un rectángulo con trazo simple.

Nodo

EMPLEADO DEPARTAMENTO

CLIENTE PROVEEDOR PRODUCTO Nota: Las entidades

se representan dentro

de un rectángulo


48


j) Débiles, cuya existencia depende de otro tipo de entidad (Por ejemplo, APODERADO depende de ALUMNO. La desaparición de un ALUMNO de la base de datos hace que desaparezcan también todos los familiares del mismo). Estos tipos de entidades se representan normalmente con un rectángulo con líneas de doble trazo. Estas entidades normalmente no tienen suficientes atributos para formar una clave primaria.

Atributos Son las propiedades específicas de las entidades. Por ejemplo, una entidad PROVEEDOR puede describirse por su Nº de Ruc, su nombre o razón social de la empresa, su teléfono, etc. Los.

Al conjunto de valores que puede tomar un atributo se le llama dominio del atributo.

Tipos de atributos: b) Simples y compuestos:

Los compuestos están formados por un conjunto de atributos, mientras que los simples no se pueden dividir.

c) Monovaluados y multivaluados Los monovaluados sólo pueden tener un valor para una entidad particular, mientras que los multivaluados pueden tener más de un valor. (Por ejemplo el atributo color de la entidad COCHE es un atributo multivaluado, pues un coche puede estar pintado de varios colores).

d) Almacenados o derivados: Los derivados son atributos cuyo valor para una entidad particular puede obtenerse en función de los valores almacenados en otros atributos. Se representan mediante una elipse con trazo discontinuo. (Por ejemplo el atributo edad de la entidad PERSONA es un atributo derivado porque se puede obtener en función del valor dela tributo fecha_nacimiento).

Clave La clave de una entidad es un atributo de dicha entidad que identifica unívocamente una ocurrencia de una entidad, es decir los valores de los atributos claves no se pueden repetir en una misma entidad y no toman nunca el mismo valor para dos entidades particulares diferentes, a estos atributos se les llaman claves. En el diagrama E-R los atributos clave deben aparecer destacados; por ejemplo, subrayando su nombre (por ejemplo, nruc de la entidad PROVEEDOR).

ALUMNO APODERADO

PROVEEDOR

nruc

nombre

telf

PROVEEDOR

nruc

nombre

telf

Entidad Fuerte Entidad Débil

Nota: Los atributos se

representan por elipses que

están conectadas a su

entidad o relación mediante

una línea recta

COCHE

matric

modelo

color

PERSONA

DNI

nombre

fecha_nac

edad

Nota: Los multivaluados

se representan mediante

una elipse con trazado

doble.


49


Relación o Vínculo Se puede definir como una correspondencia, asociación o conexión entre dos o más entidades. En los diagramas E-R se representa gráficamente como un rombo y sus nombres son verbos. Por ejemplo: VENDE, PERTENECE, etc. Una relación puede tener atributos descriptivos. Por ejemplo, en la relación anterior, podría tener como atributo descriptivo fecha_venta (la fecha en que se hace la venta).

Grado de una relación

Es el número de entidades que participan en la relación. Se puede restringir el modelo E-R para incluir solo conjuntos de relaciones binarias, es decir de grado 2 (es aconsejable).

Correspondencia de cardinalidad,

Expresa el número máximo de entidades que están relacionadas con una única entidad del otro conjunto de entidades que interviene en la relación. Aunque normalmente nos interesa sólo la cardinalidad máxima, a veces es útil especificar la cardinalidad mínima. Según su cardinalidad, podemos clasificar las relaciones de los siguientes tipos:

Tipo Relación Representación

1:1 Una a una : La cardinalidad máxima en ambas direcciones es 1

1:N Una a muchas: La cardinalidad máxima en una dirección es 1 y en la otra muchos.

N:M Muchas a muchas: La cardinalidad máxima en ambas direcciones en muchos

Caso I: Gestión de una biblioteca Se desea establecer un modelo conceptual para la gestión de una biblioteca, para lo cual se desea tener almacenados todos los libros que la componen Para este caso se considera los siguientes aspectos:

Para cada libro interesa conocer el Código del libro, el título, el autor o autores, la editorial, el año de publicación y la materia.

De cada autor se quiere conocer su nombre, apellidos y nacionalidad

Un autor podrá haber escrito varios libros, de la misma forma que en un libro pueden participar varios autores. De la editorial se desea saber el nombre y la ciudad

A dicha biblioteca pueden suscribirse varios socios. De ellos se quiere saber su DNI, número de socio, nombre, apellidos, dirección y teléfono.

Por cuestiones directivas se limita el número de ejemplares prestados a cada usuario a uno

Se dispone a su vez de un único ejemplar de cada libro, por lo que un libro prestado a un usuario, no podrá ser prestado a otro hasta que se devuelva.

Deberá quedar constancia de la fecha de préstamo de cada ejemplar

Se pide hacer el diagrama E - R para la base de datos que represente esta información.

Solución

PROVEEDOR

PRODUCTO

VENDE

PROVEEDOR

PRODUCTO

VENDE

fecha_venta

1 1

N 1

M N


50


3. 4. 5. Diseño Lógico

El diseño lógico de una base de datos consta de dos etapas: el diseño lógico estándar y el diseño lógico específico En el Diseño lógico estándar, se toma el esquema conceptual resultante de la fase del diseño conceptual Para el diseño lógico, se toma el esquema conceptual resultante de la fase de diseño conceptual, esta fase se apoya en un modelo lógico estándar, se construye el diseño lógico estándar, que se apoya en un modelo lógico estándar, que será el mismo modelo de datos soportado por el SGBD a utilizar (relacional, jerárquico, etc.), En el Diseño Lógico Específico, una vez obtenido el Esquema Lógico Estándar, y considerando el modelo específico propio del SGBD a usar (Ms-Acces, Oracle, SQL Server, etc.) se elabora el esquema lógico específico

Paso del esquema conceptual al esquema lógico Las reglas que permiten pasar del esquema conceptual (Modelo E/R) obtenido en la primera fase a la fase del diseño lógico son:

Cada entidad se transforma en una relación: esto es en cada entidad se genera un tabla, con sus mismos atributos, incluyendo las claves

Cada relación N- M genera una tabla, las relaciones entre entidades con cardinalidad N-M generan una tabla, con los atributos de la clave de ambas entidades.

Cada relación 1 –N importa las claves de la entidad con las que se relaciona: cada relación con cardinalidad 1- N importa los atributos clave que contiene la entidad con cardinalidad N

Cada relación dependiente importa la clave de la otra entidad, como clave

Ejemplo: Del caso anterior referido a una gestión de biblioteca, transformar el esquema conceptual al modelo lógico Solución El esquema de tablas resultantes es el siguiente de acuerdo a las reglas del esquema conceptual al lógico

Diseño Lógico estándar

LIBRO

cod_libro cod_edit titulo materia año

AUTOR

cod_autor apellidos nombre nacionalidad

LIBRO_AUTOR

cod_libro cod_autor

LIBRO

AUTOR

escribe

cod_libro

título año materia nombre nacionalidad

N M

EDITORIAL

nombre ciudad SOCIO

dni

direccion nombre

n_socio

apellidos telefono

prestamo

1

N Fecha_prestamo

apellidos

pertenece

N 1

cod_edit

cod_autor


51


PRESTAMO

cod_libro n_socio fecha_prestamo

SOCIO

n_socio apellidos nombre DNI telefono

Tipo interrelación reflexiva Llamadas recursivas, las cuales asocian un tipo de entidad consigo misma, en el siguiente ejemplo la entidad TEMA se asocia con TEMA

Tipo de interrelación de grado superior a dos Grado: E s el número de tipos de entidad que participan en un tipo de interrelación

Interrelación redundante Se dice que una interrelación es redundante, cuando su eliminación no implica pérdida semántica de los datos (significado de los datos) porque existe la posibilidad de realizar la misma asociación por medio de otras interrelaciones

EDITORIAL

cod_edit nombre ciudad

PROFESOR

imparte

CURSO DEPARTAMENTO

pertenece

adscrito

N

M

1 N

1

redundante

Ciclo en el que aparece una interrelación redundante

PROFESOR

imparte

TEMA

CURSO

TEMA

consta

s

N


52


Interrelación de grado superior a 2 Cuando se presenta un interrelación de grado superior a 2, es preciso analizar ya que a veces se puede descomponer en otras de menor grado Ejemplo: La interrelación Imparte que asocia tres entidades, se refiere a que un profesor imparte un tema en un curso, pero si sustituimos la interrelación por las tres Imparte1, Trata, Tema, de estas no se puede deducir los temas que trata un profesor en curso determinado

ESPECIALIZACIÓN Y GENERALIZACIÓN

Se crea una tabla para el conjunto de entidades del nivel más alto.

Para conjunto de entidades de nivel. mas bajo, se crea una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades, mas una columna que contendría la clave primaria del conjunto de entidades de nivel superior.

PROFESOR

imparte

CURSO ESTUDIANTE

Imparte1 Imparte1

asiste

1

N

N M

M

N M M

1

Un tipo de interrelación de grado 3 que puede ser descompuesta sinr pérdida semántica

PROFESOR

imparte

TEMA CURSO

trata Imparte1

entra

N

M

N M

M

N M M

N

Un tipo de interrelación de grado 3 que no puede ser descompuesta por pérdida semántica

PROFESOR

imparte

CURSO DEPARTAMENTO

pertenece

adscrito

N

M

M N

1

Ciclo en el que no aparece una interrelación redundante

N


53


EJERCICIOS DE MODELADO DE DATOS CASO I: Universidad En la secretaría de una universidad se desea gestionar la información acerca de los alumnos, profesores, las asignaturas y las carreras ofertadas. Hay que tener en cuenta que:

a) Un alumno puede estar matriculado en muchas asignaturas. b) Cada asignatura pertenece a una única carrera, aunque puede haber asignaturas de distintas

carreras con el mismo nombre. c) Una carrera tiene muchas asignaturas d) Cada asignatura puede estar impartida por uno o más profesores. e) Un profesor puede impartir más de una asignatura.

CASO II: Caso: Tienda de Accesorios de Computadoras “Computienda” COMPUTIENDA, es una empresa que brinda el servicio de ventas de accesorios respecto al área de computadoras, a continuación se muestra el proceso que sigue el cliente:

1. El cliente antes de hacer su pedido, es atendido por una vendedora, quien le muestra los productos que el cliente solicita

2. Una vez que el cliente determina que productos comprar, le dan un ticket de los productos que va a comprar, se acerca a caja, hace su pedido, da sus apellidos, nombres, dirección, teléfono, cancela y recibe una Boleta de Venta para recoger su pedido

VEHICULO

matric modelo

COCHE

matric

AUTOBUS

matric plazas

MOTO

matric CC

VEHICULO

matric

modelo

COCHE

AUTOBUS

MOTO

CC

plazas


54


Cantidad

Unid Descripción Precio Unit. S/.

Valor de

Venta

02 03 01

Cono x 100 Cono x 100 Cja x 1 Und

CD‟S SONY CD‟S MAXELL Disquette MAXELL

70.00 50.00

7.00

140.00 150.00

7.00

TOTAL 297.00

3. Luego de unos minutos de espera el cliente se acerca con su Boleta de Venta a recoger su pedido

En dicha Tienda todo el procedimiento de atención al cliente es en forma manual Para este caso desarrolle el Esquema Conceptual y el Esquema Lógico de la Base de Datos

CASO III: VIDEOCLUBS GLOB-GUSTERS La cadena de Videoclubs Glob-Gusters ha decidido, para mejorar su servicio, emplear una Base de Datos para almacenar la información referente a las películas que ofrece en alquiler. Esta información es la siguiente:

Una película se caracteriza por su título, nacionalidad, productora y fecha (Ejemplo: Quo Vadis, Estados Unidos, M.G.M. , 1955)

En una película pueden participar varios actores (nombre, nacionalidad, sexo), algunos de ellos como actores principales

Una película está dirigida por un director (nombre, nacionalidad)

De cada película se dispone de uno o varios ejemplares diferenciados por un número de ejemplar y caracterizados por sus estado de conservación

Un ejemplar se puede encontrar alquilado a algún cliente (nombre, dirección, teléfono). Se desea almacenar la fecha de comienzo de alquiler y la de la devolución

Cada socio puede alquilar como máximo 4 ejemplares

Un socio tiene que ser avalado por otro socio que responda de él en caso de tener problemas en el alquiler

CASO IV: GESTIÓN DE UNA FARMACIA La gestión de una farmacia requiere poder llevar el control de los medicamentos existentes, así como de los que van sirviendo, para lo cual se pretende diseñar un sistema acorde a las siguientes especificaciones:

En la farmacia se requiere una catalogación de todos los medicamentos existente, para lo cual se almacenará un código de medicamento, nombre del medicamento, tipo de medicamento (jarabe, comprimido, pomada, etc.), unidades de stock, unidades vendidas y precio. Existen medicamentos de venta libre y otros que sólo pueden dispensarse con receta médica

Nombre:

Dirección: Fecha de emisión: / /

RUC Nº 20485979043

Nº 0003948

factura


55


La farmacia compra cada medicamento a un laboratorio, o bien los fabrica ella misma. Se desea conocer el código del laboratorio, o bien los fabrica ella misma. Se desea conocer el código del laboratorio, nombre, teléfono, dirección y fax, así como el nombre de la persona de contacto

Los medicamentos se agrupan en familias, dependiendo del tipo de enfermedades a las que dicho medicamento se aplica. De este modo, si la farmacia no dispone un medicamento concreto, puede vender otro similar de distinto laboratorio

La farmacia tiene algunos clientes que realizan los pagos de sus pedidos a fin de cada mes (clientes con créditos). La farmacia quiere mantener las unidades de cada medicamento comprado (con o sin crédito) así como la fecha de compra . Además, es necesario conocer los datos bancarios de los clientes con crédito, así como la fecha de pago de las compras que realizan

1.

Diseño Conceptual


56


Diseño Lógico

PELICULA

IdPelicula IdDirector Titulo Nacionalidad Productora Fecha

ACTOR

IdActor Nomb Nacionalid Sexo

DIRECTOR

IdDirector Nombre Nacionalid

PARTICIPA

IdPelicula IdActor Tipo_partic

EJEMPLAR

IdPeliNumEjemp IdPelicula NumEjemp Estado_con

ALQUILADO

IdPeliNumEjemp DNI Fecha_alqui Fecha_devo

SOCIO

DNI Nombre Direcc Telf IdSocAval

PELÍCULA dirige DIRECTOR partcipa N

ACTOR

Título

Nacionalidad

Productora

Fecha IdPelicula

IdActor

Nombre Nacionalid

Sexo

M

IdDirector

Nacionalid

ad

Nombre

pertenece

1 N

EJEMPLAR

1

N NumEjemp

Estado_con

IdPeliNumEjemp

alquilado

SOCIO

M

N

Fecha_alqui

Fecha_devo

llu

Avalado_por 1

N

DNI

Nombre

Direcc

Telf

Tipo_partic


57


2. FARMACIA

CASO I: GESTIÓN DE CURSOS DE UNA EMPRESA

SOLUCIÓN a) Esquema Conceptual (Modelo E-R)

FAMILIA

…………….

…………….

LABORATORIO

…………….

…………….

…………….

…………….

…………….

…………….

MEDICAMENTO

…………….

…………….

…………….

…………….

…………….

…………….

…………….

…………….

COMP_CRE

D …………….

…………….

…………….

…………….

…………….

COMP_EFE

…………….

…………….

…………….

…………….

CLIENTE_CRED

…………….

…………….

CLIENTE

…………….

…………….

…………….

…………….

MEDICAMENTO

FAMILIA LABORATORIO

Pertenece

adquiere

CLIENTE

CLIENTE_CRED

Comp_efe Comp_cre

IdFamilia

NombreLab

TelefonoLab

DireccionLab

IdLaboratorio

……….

NombreMed

TipoMed

UnidStock

………..

Precio

………….

R……….

…………

… ……………

…………

…

…………

…

DNI


58


b) Esquema Lógico:

CURSO

cod_curso Desc_curso

PROFESOR

cod_prof apellidos nombre direccion despacho

PROFESOR_CURSO

cod_prof cod_curso

ALUMNO_CURSO

cod_curso cod_alumno

ALUMNO

cod_alumno cod_ciu apellidos nombres Direccion telefono

CIUDAD

cod_ciudad des_ciu

PROFESOR

CURSO

imparte

cod_prof

apellidos dirección nombres

Desc_curs

o

1 N

Des_ciu

ALUMNO

direccion nombre

Cod_alum

apellidos telefono

asiste

M

N

cod_ciu

cod_curso

CIUDAD

vive

1 N

despacho


59


NORMALIZACIÓN Los modelos de datos son instrumentos que ayudan a representar la realidad. Cuando se diseña una Base de Datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas opciones, es decir, podemos obtener diferentes esquema relacionales, y no todos ellos son equivalentes, ya que una va a representar la realidad mejor que otros. La normalización convierte una relación en varias sub-relaciones, cada una de las cuales obedece a reglas. Estas reglas se describen en términos de dependencia. Una vez que hayamos examinado las distintas formas de dependencia, encontraremos procedimientos a aplicar a las relaciones de modo tal que las mismas puedan descomponerse de acuerdo a la dependencia que prevalece. Esto no llevará indefectiblemente a formar varias subrelaciones a partir de la única relación preexistente. Con la teoría de normalización se consigue una formalización en el diseño lógico de bases de datos relacionales, NECESIDAD DE UN MÉTODO FORMAL DE DISEÑO RELACIONAL En el modelo relacional, como en los demás modelos de datos, el diseño de una base de datos se puede abordar de dos formas distintas:

a) Obteniendo el esquema relacional directamente a partir de la observación del universo, los cuales contendrán los atributos y restricciones de integridad que representan los objetos y reglas del mudo real

b) Realizando el proceso de diseño en dos fases, en la primera se lleva a cabo el diseño conceptual, por ejemplo en el modelo E/R, obteniéndose el correspondiente esquema conceptual; en la segunda, éste se transforma en un esquema relacional; siguiendo determinadas reglas de transformación

Estas relaciones que resultan en el diseño del esquema relacional se pueden presentar algunos problemas tales como:

- Incapacidad de almacenar cierto hechos - Redundancias y, por tanto, posibilidades de inconsistencias - Ambigüedades - Pérdida de información (aparición de tuplas espurias) - Existencia de valores nulos - Pérdida de dependencias funcionales es decir ciertas restricciones de integridad que dan lugar a dependencias entre los

datos - Aparición, en la base de datos, de estados que no son válidos en el mundo real (anomalías de inserción, borrado y

modificación) Ejemplo:

Cód_Estud Nombre_E Apellido_E DNI Dirección Cód_Beca Nombre Requisito Fecha

012323 763476 763476 763476 012323 987765 012323 987765 012323 232457

.

.

.

Roberto Luis Luis Luis Roberto Gregorio Roberto Gregorio Roberto Mercedes

.

.

.

Hens García García García Hens Celada Hens Celada Hens García

.

.

.

456367 345347 345347 345347 456367 885764 456367 885764 456367 809234

.

.

.

Jr. Libertad 452 Av. 13 de Noviembre 142 Av. 13 de Noviembre 142 Av. 13 de Noviembre 142 Jr. Libertad 452 Prol. Pachitea 189 Jr. Libertad 452 Prol. Pachitea 189 Jr. Libertad 452 Jr.Junín 1456

.

.

.

A22321 B56784 A22321 G65434 G65434 G65434 B56784 B56784 A22321 A22321

.

.

.

METRICA ERASMU METRICA HIMMPA HIMMPA HIMMPA ERASMU ERASMU METRICA METRICA

.

.

.

Ing. Téc. Ing. Téc Ing. Téc Ingenie. Ingenie. Ingenie. Ing. Téc Ing. Téc Ing. Téc Ing. Téc

.

.

.

10/10/2005 12/11/2005 14/10/2005 15/09/2005 17/09/2005 21/09/2005 11/11/2005 10/10/2005 12/11/2005 17/09/2005

.

.

.

Gran cantidad de redundancia

Anomalías de modificación

Anomalías de inserción

Anomalías de borrado

DEFINICIÓN DE LAS TRES PRIMERAS FORMAS NORMALES Los esquemas resultantes de un proceso de descomposición es que estas relaciones alcancen un nivel de normalización superior al del esquema de origen, a fin de eliminar en lo posible las redundancias y, por tanto, las anomalías de actualización

Se dice que un esquema de relación está en una determinada forma normal si satisface un cierto conjunto específico de restricciones

Cuánto más alta sea la forma normal, menores serán los problemas que aparecen en el mantenimiento de la base de datos

a) PRIMERA FORMA NORMAL (1FN)

La primera forma normal (1FN) es una restricción inherente al modelo relacional, por lo que su cumplimiento es obligatorio y afecta al número de valores que pueden tomar los atributos de una relación.

http://www.monografias.com/trabajos5/norbad/norbad.shtml

http://www.monografias.com/trabajos13/mapro/mapro.shtml


60


Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la intersección de cada fila con cada columna. Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas redundancias se eliminarán después mediante las restantes formas normales. La segunda forma de eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte, heredando la clave primaria de la relación en la que se encontraban. Definición: Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos Ejemplo La siguiente tabla EMPLEADO, no está en 1FN debido a las columnas NPROY, NOMPROY, y FECINICIO

EMPLEADO NEmp NomEmp NJefe NomJefe NDpto NomDpto NProy NomProy FecInicio

7369 Pérez Juan 7902 Navarro Luis 20 Investigación 15 Factibilidad 10/05/2005 35 Pruebas 20/05/2005 45 Control 20/06/2005

7499 Sedano Carlos 7698 Poma Carla 30 Ventas 15 Factibilidad 05/05/2005 25 Análisis 15/05/2005 45 Control 20/06/2005

La solución es “sacar” las columnas que dan problema y ponerlas en otra tabla acompañadas de su determinante:

EMPLEADO

NEmp NomEmp NJefe NomJefe NDpto NomDpto

7369 Pérez Juan 7902 Navarro Luis 20 Investigación 7499 Sedano Carlos 7698 Poma Carla 30 Ventas

ASIGNACIÓN

NEmp NProy NomProy FecIni

7369 15 Factibilidad 10/05/2005 7369 35 Pruebas 20/05/2005 7369 45 Control 20/06/2005 7499 15 Factibilidad 05/05/2005 7499 25 Análisis 15/05/2005 7499 45 Control 20/06/2005

b) SEGUNDA FORMA NORMAL (2FN)

La segunda forma normal (2FN) está basada en el concepto de dependencia plena y en las interrelaciones existentes entre los atributos principales (que se encuentran en alguna de las claves) y no principales (que no se encuentran en ninguna clave) de una relación

Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no está en la clave primaria es completamente dependiente de la clave primaria.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones.

Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Definición: Una tabla está en 2FN si está en 1FN y además se cumple que toda columna que no es parte de la llave de la tabla depende funcionalmente de toda la llave. En la tabla ASIGNACIÓN las dependencias funcionales son:


61


NPROY NOMBPROY (NEMP, NPROY) FECINI En la tabla ASIGNACIÓN la llave es (NEMP, NPROY) por lo tanto la tabla no está en 2FN, ya que, existe una columna que no es parte de la llave NOMPROY y que no depende de toda la llave.

La solución es “sacar” las columnas que dan problema y ponerlas en otra tabla acompañadas de su determinante. ASIGNACIÓN

NEmp NProy FecIni

7369 15 10/05/2001 7369 35 20/05/2001 7369 45 20/06/2001 7499 15 05/05/2001 7499 25 15/05/2001 7499 45 20/06/2001

PROYECTOS

NProy NomProy

15 Factibilidad 25 Análisis 35 Pruebas 45 Control

c) TERCERA FORMA NORMAL (3FN)

La tercera forma normal está basada en el concepto de dependencia transitiva Definición: Una tabla está en 3FN si está en 2FN y además se cumple que toda columna que no es parte de la llave de la tabla depende sólo de la llave (dependencia transitiva) EMPLEADO



Las dependencias funcionales son: NEMP NOMEMP NJEFE NOMJEFE NDPTO NOMDPTO NEMP NJEFE NEMP NDPTO NEMP NOMJEFE NEMP NOMDPTO La tabla está en 2FN, ya que, todas las columnas que no es parte de la llave dependen funcionalmente de toda la llave, es decir,

(NEMP) (NOMEMP, NJEFE, NOMJEFE, NDPTO, NOMDPTO) Pero no está en 3FN debido, por ejemplo, a que NOMDPTO además de depender de NEMP (que es parte de la llave) depende de NDPTO (que no es parte de la llave). En este caso, hablamos de que existe una dependencia transitiva.


62


La solución es “sacar” las columnas que dan problemas y ponerlas en otra tabla acompañadas de su determinante. EMPLEADO



Primero se soluciona el problema de la columna NOMDPTO: DEPARTAMENTO

NDpto NomDpto

20 Investigación 30 Ventas

Luego se soluciona el problema con la columna NOMJEFE JEFE

NJefe NomJefe

7902 Navarro Luis

7698 Poma Carla

Y la tabla EMPLEADO queda de la siguiente forma: EMPLEADO

NEmp NomEmp NJefe NDpto

7369 Pérez Juan 7902 20 7499 Sedano Carlos 7698 30

Al proceso de “sacar” las columnas que dan problemas y ponerlas en otra tabla aparte junto con su determinante se le llama descomposición. La descomposición de una tabla es correcta si al hacer el JOIN entre las tablas resultantes se vuelve a obtener la tabla original. Se le llama descomposición sin pérdida de información. Al “llevarnos” el determinante de las columnas que se están sacando de la tabla, nos aseguramos que la descomposición sea sin pérdida de información.

EJERCICIO: El centro de computación de la Facultad posee un grupo de Consultoría dedicado a la atención de usuarios. Dicho grupo está formado por alumnos regulares de la Facultad, los que tienen dominio de algún software específico. Para cada consultor existe un horario de atención preestablecido y el propio jefe del grupo está a cargo de controlar el funcionamiento del servicio. Se pide normalizar el modelo relacional hasta la 3FN. Una vez que haya normalizado el modelo relacional, infiera el modelo entidad-relación, identificando todas sus componentes.

HORARIO ASISTENCIA

Matricula num_dia cod_mod hora_inicio Hora_fin matricula cod_mod fecha

2039 1 1 08:50 10:00 2039 1 24/11/98

2039 2 2 10:25 11:00 2039 2 25/11/98


63


2020 3 1 08:50 10:00 2020 1 25/11/98

CONSULTOR

Cod_dpto Nom_dpto Nombre Matricula cod_soft descripcion

10 Computación Alfredo 2039 0001 Excel 5,0

0002 Word 6,0

0003 Pascal

0004 Turing

20 Matemáticas Claudia 2020 0005 C

0006 PL/SQL

0003 Pascal

SOLUCIÓN La tabla asistencia se encuentra en 3FN, ya que estando la llave primaria compuesta por los campos (fecha,matricula) se tiene la siguiente dependencia funcional: (fecha,matricula) cod_mod lo cual indica que todo campo que no pertenece a la llave primaria (en este caso solamente cod_mod) depende SOLO de la llave primaria. La tabla horario y consultor, no están en ninguna forma normal ya que ambas presentan columnas con valores vectoriales. (no atómicos) En la tabla horario, estas columnas son hora_inicio,hora_fin por lo tanto hay que llevarlas a otra tabla junto con su determinante que es cod_mod. Esto se traduce en:

HORARIO_DIARIO MODULO

Matricula num_dia cod_mod cod_mod hora_inicio hora_fin

2039 1 1 1 08:50 10:00

2039 2 2 2 10:25 11:00

2020 3 1

De esta manera ambas tablas quedan en 3FN, siendo sus dependencias funcionales las siguientes: horario_diario: Para soportar el caso de que un alumno pueda tener dos módulos distintos un mismo día, es necesario que la llave primaria esté formada por las tres columnas (matricula,num_dia,cod_mod). modulo:

Siendo cod_mod la llave primaria, se tienen las dependencias: cod_mod hora_inicio

cod_mod hora_fin Para la tabla consultor, primero debemos llevar a otra tabla la columna descripción con su determinante cod_soft:

CONSULTOR software

Cod_dpto nom_dpto nombre matricula cod_soft cod_soft Descripción

10 Computación Alfredo 2039 0001 0001 Excel

0002 0002 Word

0003 0003 Pascal


64


0004 0004 Turing

20 Matemáticas Claudia 2020 0005 0005 C

0006 0006 PL/SQL

0003 0003 Pascal

Así, la tabla software queda en 3FN. Pero la tabla consultor sigue sin ninguna forma normal, pues la columna cod_soft tiene datos repetidos. Luego se debe separar en otra tabla junto con su determinante que es matricula.

consultor conocimiento

Cod_dpto nom_dpto nombre matricula Matricula cod_soft

10 Computación Alfredo 2039 2039 0001

20 Matemáticas Claudia 2020 2039 0002

2039 0003

2039 0004

2020 0005

2020 0006

2020 0003

La tabla conocimiento está en 3FN si la llave primaria está formada por ambos campos (matricula,cod_soft). Las dependencias funcionales de la tabla consultor si la llave primaria es matricula, son:

matricula nombre matricula nom_dpto

matricula cod_dpto cod_dpto nom_dpto

esto nos dice que la tabla está en 2FN (todo campo que no pertenece a la llave primaria, depende funcionalmente de TODA la llave primaria), pero no está en 3FN ya que, nom_dpto además de depender de la llave primaria depende de cod_dpto. Luego la separamos en otra tabla junto con su determinante.

consultor departamento

matricula nombre cod_dpto cod_dpto nom_dpto

2039 Alfredo 10 10 Computación

2020 Claudia 20 20 Matemáticas

De esta forma todo queda en 3FN. Las dependencias funcionales de estas tablas son: consultor: matricula nombre departamento: cod_dpto nom_dpto matricula cod_dpto


65


BASE DE DATOS ORIENTADO A OBJETOS

Concepto: En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades 1.1 Estructuras de Objetos. El modelo orientado a objetos se basa en encapsular código y datos en una única entidad, llamada objeto. La interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. El motivo de este enfoque puede ilustrarse considerando una base de datos de documentos en la que los documentos se preparan usando uno entre varios paquetes de software con formateador de texto. Para imprimir un documento debe ejecutarse el formateador correcto en el documento. Bajo un enfoque orientado a objetos, cada documento es un objeto que contiene el texto de un documento y el código que opera sobre el objeto. Todos los objetos del documento responden al mensaje de imprimir pero lo hacen en formas diferentes. Cada documento responde ejecutando el código de formatear adecuado. Encapsulando dentro del objeto del documento la información acerca de cómo imprimir el documento, podemos tener todos los documentos con el mismo interfaz externo al usuario. En general, un objeto tiene asociado:

Un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.

Un conjunto de mensajes a los que el objeto responde.

Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje.

El termino de mensaje en un contexto orientado a objetos no implica el uso de un mensaje físico en una red de computadoras, sino que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación. Puesto que el único interfaz externo que presenta un objeto es el conjunto de mensajes al que responde, es posible modificar la definición de métodos y variables sin afectar otros objetos. También es posible sustituir una variable por un método que calcule un valor. Por ejemplo, un objeto de documento puede contener una variable de tamaño que contenga el numero de bytes de texto en el documento o bien un método de tamaño que calcule el tamaño del documento leyendo el documento y contando el numero de bytes. La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos. 1.2 Jerarquía de Clases Normalmente en una base de dato existen muchos objetos similares. Por similar queremos decir que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo. Sería un trabajo inútil definir cada uno de estos objetos por separado. Por tanto, agrupamos los objetos similares para que formen una clase. A cada uno de estos objetos se les llama instancias de su clase. Todos los objetos de una clase comparten una definición común. Aunque difieran en los valores asignados a las variables. Ejemplo de clases en las bases de datos del banco son los clientes, las cuentas y los préstamos. El concepto de clases es similar al concepto de tipos abstractos de datos. Sin embargo, en el concepto de clase existen varios aspectos adicionales más allá de los de los tipos abstractos de datos. Para representar estas propiedades adicionales, tratamos cada clase como si fuera un objeto. Un objeto clase incluye:

Una variable con valores es un conjunto cuyo valor es el conjunto de todos los objetos que son instancias de la clase.

Implementación de un método para el nuevo mensaje, el cual crea una nueva instancia de la clase. Un esquema de base de datos orientada a objetos normalmente requiere un gran numero de clases. Sin embargo, a menudo se da el caso de que varias clases son similares. Por ejemplo, supóngase que tenemos una base orientada a objetos para la aplicación bancaria. Sería de esperar que la clase de cliente del banco fuera similar a la clase de empleados del banco en la definición de variables de nombre, dirección, número de teléfono, etc. Sin embargo existen variables especificas para los empleados (por ejemplo tasa-credito). Sería deseable definir una representación para las variables comunes en un sitio. Esto puede hacerse sólo si los empleados y los clientes están combinados en una clase. Para permitir la representación directa de similaridades entre clases necesitamos colocar clases en una jerarquía de especialización como la que se definió en el modelo de datos Entidad - Relación. Los empleados y los clientes pueden representarse por clases que son especializaciones de una clase Persona. Las variables y los métodos específicos de los empleados se asocian a la clase Empleado. Las variables y los métodos específicos de los clientes se asocian a la clase Cliente. Las variables y los métodos que se aplican tanto a los empleados como a los clientes se asocian a la clase Persona. La siguiente figura muestra una jerarquía de clases que representan personas implicadas en la operación del ejemplo bancario. Las variables asociadas a cada clase del ejemplo son:

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n

http://es.wikipedia.org/wiki/Persistencia


66


Persona: numero-seguridad-social, nombre, dirección, numero-telefono-particular, fecha-de-nacimiento.

Cliente: tasa-de-credito, estado-retencion-impuestos, numero-de-telefono-trabajo.

Empleado: fecha-de-contrato, salario, numero-de-dependientes.

Director: titulo, numero-despacho, numero-cuenta-de-gastos Por brevedad no presentamos los métodos asociados a estas clases, aunque estarían incluidos en la definición completa de la base de datos bancaria. Un objeto que representa a un director contiene todas las variables de la clase Director, Empleado y Persona. Esto se refiere a la herencia de las propiedades de una clase mas general. Los métodos se heredan de manera idéntica a la herencia de las variables. Las especializaciones de una clase se denominan subclases. Así, por ejemplo, Empleado es una subclase de Persona; Cajero es una subclase de Empleado. A la inversa, Empleado es una superclase de Cajero y Persona es una superclase de Empleado. Anteriormente observamos que cada clase es ella misma un objeto y que ese objeto incluye una variable que contiene el conjunto de todas las instancias de la clase. Es fácil determinar qué objetos están asociados a clases en las hojas de jerarquía. Por ejemplo, asociamos a la clase Cliente, el conjunto de todos los clientes del banco. Sin embargo, para las clases que no son hojas, la cuestión es más complicada. En la figura anterior hay dos posibles formas de asociar objetos a clases.

Podríamos asociar a la clase Empleado todos los objetos de empleado, incluyendo aquellos que sean instancias de Director, Cajero y Secretaria.

Podríamos asociar a la clase Empleado solamente aquellos objetos de empleado que no sean instancias de Director, ni de Cajero, ni de Secretaria.

Normalmente, en sistemas orientados a objetos se elige la última forma. Es posible determinar el conjunto de todos los objetos de empleado en este caso tomando la unión de aquellos objetos asociados a todas las clases en el subárbol con raíz en Empleado. Como observamos anteriormente, la jerarquía de clase/subclase es similar al concepto de especialización en el modelo entidad – relación. Decimos que Cajero es una especialización de Empleado porque el conjunto de todos los cajeros es un subconjunto de todos los empleados. Es decir, cada cajero es un empleado. La especialización permite la posibilidad de que un empleado no sea un cajero, una secretaria, ni un director. Una forma alternativa de la relación es el concepto de generalización. En el modelo entidad - relación, la generalización es el resultado de tomar la unión de dos o mas conjunto de entidades (de nivel bajo) para producir un conjunto de entidades de nivel alto. Si aplicamos el concepto de generalización al modelo orientado a objetos, cada objeto debe ser una instancia de una clase hoja en la jerarquía. Esto requeriría la definición de una subclase de Empleado llamada Otro-Empleado para representar empleados que no fueran cajeros, secretarias ni directores. En la mayoría de los sistemas orientados a objetos suelen tener implícita la especialización en vez de la generalización. Así, en lo que sigue, supondremos que la jerarquía de clase/subclase está basada en la especialización. 1.3 Herencia Múltiple En la mayoría de los casos, una organización jerárquica de clases es la adecuada para describir aplicaciones. En tales casos, todas las superclases de una clase son antepasados de otra en la jerarquía. Sin embargo, existen situaciones que no pueden representarse bien en una jerarquía de clases. Supóngase que queremos distinguir entre cajeros y secretarias a tiempo completo y a tiempos partidos en el ejemplo de la figura ya mencionada. Además supóngase que necesitamos variables y métodos diferentes para representar estos dos tipos de empleados. Podemos crear las subclases: Cajero-tiempo-patido, Cajero-tiempo-completo, Secretaria-tiempo-partido, Secretaria-tiempo-completo. La jerarquía resultante que se muestra a continuación no proporciona un buen modelo de la empresa bancaria por varias razones:

Persona

Empleado Cliente

Director Cajero Secretaria

Persona

Empleado Cliente


67


Como observamos anteriormente, existen ciertas variables y métodos específicos de los empleados a tiempo completos y otros específicos de los de tiempo partido. En la figura anterior las variables y los métodos para los empleados a tiempo completo deben estar definidas dos veces, una para Secretaria-tiempo-completo y otra para Cajero-tiempo-completo. Para los empleados a tiempo partidos existe una redundancia parecida. Esta redundancia no es deseable, ya que cada cambio de las propiedades de los empleados a tiempo completo o partido debe hacerse en dos sitios, lo que puede conducir a inconsistencias.

La jerarquía no tiene forma de representar empleados que no sean cajeros ni secretarias, a menos que la ampliemos de manera que incluya las clases Empleado-tiempo-completo y empleados-tiempo-partido.

Si tuviéramos varias clasificaciones de trabajo en vez de las dos de este ejemplo sencillo, las limitaciones del modelo llegarían a ser más aparentes. El concepto de Herencia Múltiple trata los problemas que acabamos de observar en el modelo orientado a objetos; este concepto de refiere a la capacidad de las clases para heredar variables y métodos de múltiples superclases. La relación clase/subclase se representa por un grafo con raíz aciclica dirigido (DAG) en el que una clase puede tener más de una superclase. Volvamos al ejemplo bancario. Utilizando un DAG podemos definir propiedades de empleo a tiempo completo y a tiempo partido en un sitio. Como se muestra en la siguiente figura. Definimos una clase Tiempo-partido que define aquellas variables y métodos específicos del empleo a tiempo partido y una clase Tiempo-completo que define aquellas variables y métodos específicos del empleo a tiempo completo. Utilizando DAG en la figura mencionada, podemos representar los empleados a tiempo completo y a tiempo partido que no son cajeros ni secretarias como instancias de las clases Tiempo-completo y Tiempo-partido, respectivamente.


Cajero a tiempo

completo

Cajero a tiempo

Partido

Secretaria a

Tiempo

Completo

Secretaria a Tiempo Partido

Persona

Empleado

Cliente


Cajero a tiempo

completo

Cajero a tiempo

Partido

Secretaria a

Tiempo

completo

Secretaria a

Tiempo

partido

Persona

Empleado Cliente



68


Cuando se emplea la herencia múltiple es posible que se dé ambigüedad en el caso en que pueda heredarse la misma variable o método de más de una superclase. En el ejemplo bancario, supóngase que en vez de definir salario para la clase Empleado, definimos una variable pago para cada una de las clases Tiempo-completo, Tiempo-partido, Cajero y Secretaria como sigue:

Tiempo-completo: pago es un entero de 0 a 100 000 que contiene el salario anual.

Tiempo-partido: pago es un entero de 0 a 20 que contiene una fracción de pago por hora.

Cajero: pago es un entero de 0 a 20 000 que contiene el salario anual.

Secretaria: pago es un entero entre 0 a 25 000 que contiene el salario anual. Considérese la clase Secretaria-tiempo-partido. Podría heredar la definición de pago de Tiempo-partido o de Secretaria. El resultado es diferente, dependiendo de la elección que se haga. Entre las opciones que pueden elegir las diversas implementaciones del modelo orientado a objetos están las siguientes:

Incluir las dos variables, renombrarlas como Tiempo-partido.pago y Secretaria.pago.

Elegir una u otra basándose en el orden en el que se crearon las clases Tiempo-partido y Secretaria.

Obligar al usuario a que haga la elección en el momento en que se define la clase secretaria-tiempo-partido. No se ha aceptado ninguna solución simple como la mejor. Cabe mencionar que no todos los casos de herencia múltiple conducen a ambigüedad. Si en vez de definir pago, conservamos la definición de la variable salario en la clase empleado, y no la definición de la variable salario en la clase Empleado, y no la definición en ningún otro sitio, entonces las clases Tiempo-partido, Tiempo-completo, Secretaria Tiempo-partido, Tiempo-completo, Secretaria y Cajero heredan todas salario de Empleado. Puesto que las cuatro clases comparten la misma definición de salario, no resulta ninguna ambigüedad cuando la Secretaria-tiempo-partido, Seecretaria-tiempo-completo, etc., heredan salario. 1.4 Identidad de objetos Los objetos en una base de datos orientada a objetos, normalmente corresponden a una entidad de la empresa que está modelando la base de datos. Una entidad conserva su identidad aun cuando algunas de sus propiedades cambien con el tiempo. Igualmente, un objeto conserva su identidad aun cuando algunos o todos los valores de las variables o las definiciones de los métodos cambien con el tiempo. Este concepto de identidad no se aplica a las tuplas de una base de datos relacional. En los sistemas relacionales, las tuplas de una relación se distinguen únicamente por los valores que contienen. La identidad del objeto es una noción mas fuerte que la que se encuentra normalmente en los lenguajes de programación o en los modelos de datos que no están basados en la orientación a objetos. A continuación ilustramos varias formas de identidad.

Valor Se utiliza un valor de dato por identidad. Esta es la forma de identidad que se usa en los sistemas relacionales.

Nombre Se utiliza un nombre facilitado por el usuario por identidad. Esta es la forma de identidad que normalmente se usa para las variables en los procedimientos. A cada variable se le da un nombre que identifica de manera única a la variable sin importar el valor que contenga.

Incorporación Una noción de identidad es incorporar en el modelo de datos el lenguaje de programación, y no se requiere que el usuario proporcione ningún indentificador. Esta es la forma de identidad que se usa en los sistemas orientados a objetos.

Un tema relacionado con el tipo de identidad es la permanencia de identidad. Una forma sencilla de lograr incorporar la identidad es por medio de punteros a localizaciones en memoria. Sin embargo, la asociación de un objeto a una localización física en memoria puede cambiar con el tiempo. A continuación listamos varios grados de permanencia de identidad.

Intraprograma. La identidad permanece solamente durante la ejecución de un único programa o consulta. Ejemplo de identidad de interprograma son los nombres de la variable en los lenguajes de programación y los identificadores de tuplas en SQL.

Interprograma. La identidad permanece de una ejecución del programa a otra. Ejemplos de identidad de interprograma son los nombres de relaciones en un lenguaje de consulta relacional del tipo del SQL.

Persistente. La identidad permanente no sólo entre las operaciones del programa sino también entre las reorganizaciones estructurales de los datos. Las relaciones en SQL no tienen identidad persistente, ya que una reorganización de la base de datos puede resultar en un nuevo esquema de bases de datos con relaciones con nuevos nombres. La forma persistente de identidad es la que se requiere en los sistemas orientados a objetos.

Estas formas de identidad sirven para distinguir entre identidad en sistemas orientados a objetos y punteros en organización física de datos. Los punteros de la memoria principal o de la memoria virtual solamente ofrecen identidad de Intraprograma. Los punteros a datos de un sistema de archivos en disco solamente ofrecen identidad de interprograma. Así, la identidad de objetos – es decir, la identidad persistente es una noción más fuerte que la que proporcionan los punteros. 1.5 Contenido de Objetos Anteriormente observamos que el valor de una variable de un objeto es ella misma un objeto. Esto crea una jerarquía de contenido entre los objetos. Un objeto O2 es el hijo de un objeto O1 y si O1 contiene O2; es decir, O2 es el valor de una variable de O1. Los objetos que contienen otros objetos se denominan objetos complejos o compuestos. Para ilustrar el contenido considérese la base de datos simplificada de diseño de sistemas de computadoras de la siguiente figura. La base de datos contiene información en varios sistemas de computadoras. Cada sistema de computadoras contiene un conjunto de tarjetas, un conjunto de buses, un conjunto de dispositivos y un conjunto de chips y los buses proporcionan un conjunto de interfaces.

Sistema de computadoras


69


La jerarquía de la figura muestra la relación de contenido entre los objetos de una forma esquemática listando los nombres de las clases en vez de los objetos individuales. Considérese la clase Sistema-computadores. Puede incluir las variables nombre-computador, id-proyecto, gestor, fecha-terminación, las cuales contienen datos descriptivos acerca de una instancia de la clase. Aunque los valores de estas variables se consideran objetos, son instancias de tipos de datos estándar (como cadenas de caracteres) que se han implementado directamente a un nivel bajo por razones de rendimiento. La clase Sistema-computadores también incluyen las variables tarjeta, bus, dispositivo y conjunto-instrucciones. Estas variables toman como valores conjuntos de objetos de las clases Tarjeta, Bus, Dispositivo y Conjunto-instrucciones, respectivamente. En determinadas aplicaciones, un objeto puede estar contenido en varios objetos. En tales casos, la relación de contenido se representa por un DAG en vez de mediante una jerarquía. El contenido es un concepto importante en los sistemas orientados a objetos porque permite que distintos usuarios vean los datos en diferentes granualidades.

Tarjeta Bus Dispositivo Conjunto

Instrucciones Chips Interfaces


70


LENGUAJE DE CONSULTA DE BASE DE DATOS STRUCTURED QUERY LANGUAGE

EDICIONES DE SQL SERVER EDICIONES DE SQL SERVER 2005 Microsoft ha rediseñado la familia de productos SQL Server 2005 para satisfacer las necesidades de cada segmento de clientes con cuatro nuevas ediciones: Express, Workgroup, Standard y Enterprise. Como base de datos central de bajo coste, SQL Server 2005 aporta valor y funcionalidad sin precedentes en comparación con las soluciones competitivas. Las cuatro nuevas ediciones ofrecen una gama de características, desde alta disponibilidad y sólida escalabilidad hasta herramientas avanzadas de inteligencia comercial, diseñadas para ofrecer a los usuarios de una organización una plataforma productiva de gestión de datos más segura, fiable y productiva. Además, con el menor tiempo de inactividad de la aplicación, su escalabilidad y rendimiento sólidos y además los severos controles de seguridad, SQL Server 2005 representa un avance espectacular al ser compatible con los sistemas empresariales más exigentes del mundo. Debido a que SQL Server forma parte del Windows Server System, los clientes también reciben los beneficios adicionales de menor coste total de propiedad y mayor velocidad de desarrollo a través de una mejor administración y mayor integración que surgen de la estrategia común de ingeniería implementada en todos los productos Windows Server System. La tabla siguiente presenta detalles sobre cada una de las distintas ediciones. Notas: En la tabla siguiente, la columna "Comentarios" brinda comentarios sobre la característica específica. Los números al lado de las tildes indican las notas al pie que aparecen en la parte inferior de la página. SQL Server 2005 Developer Edition y Evaluation Edition no aparecen en las tablas. Estas ediciones tienen las mismas características que la Enterprise Edition; la única diferencia entre ellas radica en las políticas de otorgamiento de licencia.

Escalabilidad y rendimiento

Característica Express Workgroup Standard Enterprise Comentarios

Número de CPU

1 2 4 Ilimitado Es compatible con procesadores multinúcleo

RAM 1 GB 3 GB OS Max OS Max Memoria limitada a un máximo compatible con el sistema operativo

Admite 64 bits Windows on Windows (WOW)

WOW

Tamaño de la base de datos

4 GB Ilimitado Ilimitado Ilimitado

Partición

Compatibilidad para bases de datos a gran escala

Operaciones de índice paralelo

Procesamiento paralelo de operaciones de indexación

Vistas indizadas

Se admite la creación de vista indizada en todas las ediciones. La correspondencia de vista indizada por el procesador de consulta sólo se admite en la Enterprise Edition.

Alta disponibilidad


Reflejo de base de datos1

2

Solución avanzada de alta disponibilidad que incluye conmutación rápida por error y redireccionamiento automático del cliente

Organización en

3


71


Escalabilidad y rendimiento


clústeres de conmutación por error

Transmisión de registros de seguridad

Solución de copia de seguridad y recuperación de datos

Cambios del sistema en línea

Incluye Memoria Hot Add, conexión administrativa dedicada y otras operaciones en línea

Indización en línea

Restauración en línea

Recuperación rápida

Base de datos disponible cuando comienzan las operaciones para deshacer

1 Únicamente con fines de evaluación. Uso de producción programado para el primer semestre de 2006. 2 Siempre están activados el único subproceso REDO y la configuración de seguridad 3 Admite sólo dos nodos

http://www.microsoft.com/spain/sql/productinfo/features/compare-features.mspx

COMPARACIÓN ENTRE ENTERPRISE EDITION Y ESTÁNDARD EDITION SQL 2008

INTRODUCCIÓN A SQL SERVER

INTRODUCCION

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente - servidor. SQL es un lenguaje de consultas hacia bases de datos relacionales. Entre las características de SQL se tiene:

- Procesa conjuntos de datos como grupos, más que como unidades individuales. - Provee navegación automática sobre los datos. - Usa instrucciones que son complejas y poderosas individualmente. Las instrucciones de flujo de control de los otros

lenguajes de programación están ausentes en SQL. Sin embargo ellas se proveen por extensiones al SQL, dependientes de cada fabricante de bases de datos.

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

http://www.microsoft.com/spain/sql/productinfo/features/compare-features.mspx


72


Existen dos tipos de comandos SQL:

Los DLL que permiten crear y definir nuevas bases de datos, campos e índices.

Los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Comandos DLL

Comando Descripción

CREATE Utilizado para crear nuevas tablas, campos e índices

DROP Empleado para eliminar tablas e índices

ALTER Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

Comandos DML

Comando Descripción

SELECT Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado

INSERT Utilizado para cargar lotes de datos en la base de datos en una única operación.

UPDATE Utilizado para modificar los valores de los campos y registros especificados

DELETE Utilizado para eliminar registros de una tabla de una base de datos

b) Cláusulas Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.

Cláusula Descripción

FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros

WHERE Utilizada para especificar las condiciones que deben reunir los registros que se van a

seleccionar

GROUP BY Utilizada para separar los registros seleccionados en grupos específicos

HAVING Utilizada para expresar la condición que debe satisfacer cada grupo

ORDER BY Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

c) Operadores Operadores Lógicos:

Operador Uso

AND Es el "y" lógico. Evalua dos condiciones y devuelve un valor de verdad sólo si ambas son

ciertas.

OR Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdar si alguna de las dos es

cierta.

NOT Negación lógica. Devuelve el valor contrario de la expresión.

Operadores de Comparación

Operador Uso

< Menor que

> Mayor que

<> Distinto de

<= Menor ó Igual que

>= Mayor ó Igual que

= Igual que

BETWEEN Utilizado para especificar un intervalo de valores.

LIKE Utilizado en la comparación de un modelo

In Utilizado para especificar registros de una base de datos

d) Funciones de Agregado Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único valor que se aplica a un grupo de registros.

Función Descripción

AVG Utilizada para calcular el promedio de los valores de un campo determinado

COUNT Utilizada para devolver el número de registros de la selección

SUM Utilizada para devolver la suma de todos los valores de un campo determinado

MAX Utilizada para devolver el valor más alto de un campo especificado

MIN Utilizada para devolver el valor más bajo de un campo especificado

EL LENGUAJE DE DEFINICIÓNDE DATOS (DDL)

Introducción El Lenguaje de Definición de Datos (DDL); permite establecer y/o modificar el esquema relacional el esquema relacional, es decir, añadir, borrar o actualizar atributos, tablas, índices, etc. TIPOS DE DATOS


73


Antes de crear una tabla, debe definir los tipos de datos de la tabla. Los tipos de datos especifican el tipo de información

(caracteres, números o fechas) que se puede almacenar en una columna, así como la forma en que los datos están

almacenados. Microsoft® SQL Server™ 2000 proporciona varios tipos de datos del sistema. SQL Server también permite tipos

de datos definidos por el usuario que estén basados en los tipos de datos del sistema.

Los tipos de datos definen el valor de datos que se permite en cada columna. SQL Server proporciona varios tipos de datos

diferentes. Ciertos tipos de datos comunes tienen varios tipos de datos de SQL Server asociados. Debe elegir los tipos de datos

adecuados que le permitan optimizar el rendimiento y conservar espacio en el disco.

CREACIÓNDE TABLAS (CREATE TABLE …)

Después de definir todos los tipos de datos de la base de datos, puede crear tablas, agregar y quitar columnas, y generar los

valores de las columnas.

Al crear tablas en SQL Server, debe tener en cuenta los hechos siguientes. Puede tener hasta:

Dos mil millones de tablas en cada base de datos.

1.024 columnas por cada tabla.

8060 bytes por fila (esta longitud máxima aproximada no se aplica a los tipos de datos image, text y ntext). Sintaxis parcial:

CREATE TABLE nombreTabla (

Tipos de datos comunes

Tipos de datos del sistema de SQL Server.

Sinónimo ANSI Número de bytes

Entero

int

Desde -2 147 483 648 Hasta + 2 147 483 648

4

bigint 8

smallint Desde -32 768 Hasta +32 768

2

tinyint Desde 0 hasta 255 1

Numérico exacto

decimal[(p[, s])] numeric[(p[, s])]

Enteros y decimales desde -1.79E308 hasta +1.79E308, donde p es el conjunto de digitos de la parte entera (precisión) y s es la parte decimal (escala)−

2–17

Numérico aproximado

float[(n)] Redondeo de números desde -1.79E308 hasta +1.79E308 8

real Redondeo de números desde -340E38 hasta +340E38 4

Moneda

money, Números con una precisión de cuatro decimales 8

smallmoney Desde -9223372036854475508 hasta -+9223372036854475508

4

Fecha y hora

Datetime, Desde 1/01/1753 hasta 31/12/9999 8

smalldatetime Desde 01/01/1900 hasta 06/06/2079 4

Carácter

char[(n)]

Declarable hasta 255 caracteres 1 byte por carácter declarado

varchar[(n)]

Declarable hasta 255 caracteres 1 byte por carácter declarado

Binario

binary[(n)]

Máximo 255 bytes de longitud n bytes

varbinary[(n)] Máximo 255 bytes de longitud n bytes

Imagen image Máximo 2 GB de longitud 0 a 2 GB

Especial bit, cursor, uniqueidentifier timestamp sysname table sql_variant

− rowversion − − −

1, 0–8 8 256 0–8016


74


nombre_ columna1 tipo_dato1 [NULL] | NOT NULL] ,



…)

Ejemplo:

El siguiente ejemplo crea la tabla CURSO y se especifican las columnas de la tabla, el tipo de datos de cada columna y si cada

una de las columnas admite valores NULL.

CREATE TABLE Curso (

idCurso CHAR (4) NOT NULL,

nombreCurso VARCHAR (50) NOT NULL,

numVacantes SMALLINT NOT NULL,

numMatriculados SMALLINT NOT NULL,

profesor VARCHAR (50) NULL,

precioCurso MONEY NOT NULL)

Para verificar la definición de la tabla ejecute la siguiente instrucción:

SP_help Curso go

1. MODIFICACIÓN DE TABLAS ( ALTER TABLE …) En una tabla podemos añadir nuevas columnas, eliminar columnas, cambiar las propiedades de una columna, añadir ó eliminar restricciones Sintaxis parcial:

ALTER TABLE nombre_Tabla ADD nombre_columna propiedades_columna | DROP COLUMN nombre_columna | ALTER COLUMN nombre_columna | ADD CONSTRAINT nombre_restricción PRIMARY KEY …| UNIQUE… | FOREIGN KEY … | DEFAULT …| CHECK … | DROP CONSTRAINT nombre_restricción

ADD: Permite añadir una nueva columna a la tabla

DROP COLUMN: Se usa para eliminar una columna

ALTER COLUMN: Permite modificar la definición de una columna

ADD CONSTRAINT: Permite añadir una restricción PRIMARY KEY, UNIQUE, FOREIGN KEY, DEFAULT ó CHECK a la definición de una tabla

DROP CONSTRAINT: Se usa para eliminar una restricción Ejemplo: A continuación crearemos una tabla de prueba, en la cual agregaremos una nueva columna 1. Creamos la tabla

CREATE TABLE TablaPrueba ( columna1 INT NOT NULL, columna2 CHAR (10) NOT NULL, columna3 DATETIME NULL)

2. Le añadimos la columna de tipo MONEY con la propiedad NULL

ALTER TABLE TablaPrueba ADD columna4 MONEY NULL go

3. Revisamos la nueva definición de la tabal Tabla_Prueba

sp_help TablaPrueba go

2. BORRADO DE TABLAS La sentencia que borra una tabla es la siguiente: Sintaxis:

DROP TABLE Nombre_Tabla

Ejemplo: Eliminar la Tabla Tabla_Prueba

DROP TABLE TablaPrueba

3. INTEGRIDAD DE DATOS Un paso importante en el diseño de una base de datos es decidir la mejor forma de implementar la integridad de los datos. La

integridad de los datos hace referencia a la coherencia y la precisión de los datos que están almacenados en una base de

datos. Los diferentes tipos de integridad de datos son los siguientes.


75


Integridad de dominio: La integridad de dominio (o columna) especifica un conjunto de valores de datos que son válidos para una columna y determina

si se permiten valores nulos. La integridad de dominio se suele implementar mediante el uso de comprobaciones de validez y,

también, mediante la restricción del tipo de datos, el formato o el intervalo de los valores posibles permitidos en una columna.

Integridad de entidad: La integridad de entidad (o tabla) requiere que todas las filas de una tabla tengan un identificador exclusivo, conocido como

clave principal. El que se pueda modificar el valor de la clave principal o eliminar la fila entera depende del nivel de integridad

requerido entre la clave principal y cualquier otra tabla.

Integridad referencial: La integridad referencial asegura que siempre se mantienen las relaciones entre las claves principales (en la tabla a la que se

hace referencia) y las claves externas (en las tablas que hacen referencia). No se puede eliminar una fila de una tabla a la que

se hace referencia, ni se puede modificar la clave principal, si una clave externa hace referencia a la fila, salvo que se permita la

acción en cascada. Puede definir relaciones de integridad referencial dentro de la misma tabla o entre tablas diferentes

4. LAS RESTRICCIONES ( CONSTRAINTS …) Las restricciones son un método declarativo de definición de la integridad de datos ya que ellas definen al momento de crear la tabla o al momento de modificar la definición de la tabla La restricción forma parte de la definición de un tabla TIPOS DE RESTRICCIONES Garantizan que los datos ingresados en las columnas sean valore válidos y que se mantengan la relaciones entre las tablas

Creación de la clave primaria (PK) Sintaxis:

ALTER TABLE nombre_Tabla ADD CONSTRAINT PK_nombre_tabla

PRIMARY KEY (columnaX, columnaP, …)

Nota: Se utiliza la cláusula CONSTRAINT en las instrucciones ALTER TABLE y CREATE TABLE para crear o eliminar índices

PK_nombre_tabla: Es el nombre de la restricción clave primaria. Se recomienda definir como clave primaria, el nombre de la tabla con el prefijo PK_ . Si no se especifica el nombre de la restricción, SQL Server le asigna un nombre.

ColumnaX, columnaP, : Es la columna ó combinación de columnas que se define como clave primaria. Las columnas involucradas no deben permitir valores nulos, y además no deben tener valores duplicados. En el caso de una combinación de columnas, la combinación vista como una unidad no debe tener valores duplicados.

Ejercicio: Crear en la tabla CURSO definir la columna incurso como clave primaria ALTER TABLE Curso ADD CONSTRAINT PK_curso PRIMARY KEY(idCurso) Creación de una clave primaria compuesta Ejemplo: En la tabla MATRICULA la clave primaria está conformada por la columna idCurso e idAlumno, ya que para identificar una matrícula se necesita conocer al alumno matriculado y en qué curso se ha matriculado ALTER TABLE Matricula ADD CONSTRAINT PK_Matricula PRIMARY KEY(idCurso, idalumno)

Tipo de integridad Tipo de restricción Descripción

Dominio

DEFAULT Establece el valor predeterminado para una columna cuando al insertar una fila no se especifica el valor para dicha columna

CHECK Especifica los valores de los datos que se aceptan en una columna

REFERENTIAL Especifica los valores de datos que se aceptan como actualización en función de los valores de una columna de otra tabla.

Entidad

PRIMARY KEY Identifica de forma exclusiva cada una de las filas; asegura que los usuarios no escriban valores duplicados y que se cree un índice para aumentar el rendimiento. No se permiten valores nulos.

UNIQUE Impide la duplicación de claves alternativas (no principales) y asegura que se cree un índice para aumentar el rendimiento. Se permiten valores nulos.

Referencial

FOREIGN KEY Define una columna o combinación de columnas cuyos valores coinciden con la clave

CHECK Especifica los valores de los datos que se aceptan en una columna en función de los valores de otras columnas de la misma tabla.


76


Go Ejercicio: Escriba las instrucciones para crear la clave primaria de las tablas Alumno y Pago, notar de que la clave primaria de la tabla pago está compuesta por tres columnas Creación de la clave foránea Sintaxis:

ALTER TABLE nombre_Tabla ADD CONSTRAINT FK_nombre_tabla_tabla_referenciada

FOREIGN KEY (columnaX, columnaP, …) REFERENCES tabla_referenciada

FK_nombre_tabla_tabla_referenciada: Es el nombre de la restricción, clave foránea.

ColumnaX, columnaP, : Es la columna ó combinación de columnas que se define como clave foránea.

tabla referenciada: Es el nombre de la tabla primaria con la que se relaciona la tabla secundaria que tiene la clave foránea.

Ejemplo: Creación de clave foránea en la tabla MATRÍCULA que referencia a la tabla CURSO

ALTER TABLE Matricula ADD CONSTRAINT FK_Matricula_Curso FOREIGN KEY (idCurso) REFERENCES Curso go

Ejercicio:

Creación de la clave foránea en la tabla MATRICULA que referencia a la tabla ALUMNO Creación de restricción valor no duplicado (UNIQUE) Sintaxis:

ALTER TABLE nombre_Tabla ADD CONSTRAINT U_nombre_tabla_nombre_columna

UNIQUE (columnaX, columnaP, …)

U_nombre_tabla_nombre_columna: Es el nombre de la restricción valor no duplicado o ÚNIQUE.

ColumnaX, columnaP, : Es la columna ó combinación de columnas a la que se le aplica la restricción. Ejemplo: Creación de restricción UNIQUE para la columna nombreCurso en la tabla CURSO

ALTER TABLE CURSO ADD CONSTRAINT U_Curso_nombreCurso UNIQUE (nombreCurso) go

Creación de valor predeterminado (DEFAULT) Sintaxis:

ALTER TABLE nombre_Tabla ADD CONSTRAINT DF_nombre_tabla_nombre_columna

DEFAULT valor_predeterminado FOR columnaX

DF_nombre_tabla_nombre_columna: Es el nombre de la restricción valor predeterminado ó DEFAULT..

Valor_predeterminado: Es el valor que se almacena en columnaX cuando al insertar una fila no se especifica el valor para esa columna

ColumnaX: Es la columna a la que se le aplica la restricción. Ejemplo: Creación de restricción DEFAULT para la columna numVacantes en la tabla CURSO

ALTER TABLE CURSO ADD CONSTRAINT DF_Curso_numVacantes DEFAULT 15 FOR numVacantes go

Creación de regla de validación (CHECK) Sintaxis:

ALTER TABLE nombre_Tabla ADD CONSTRAINT CK_nombre_tabla_nombre_columna

CHECK (condicion)

CK_nombre_tabla_nombre_columna: Es el nombre de la restricción regla de validación ó CHECK.

condición: Es la expresión que determina cómo debe ser el valor a ingresar en la columna afectada por la restricción


77


Ejemplo: Creación de restricción CHECK para la columna precioCurso de la tabla CURSO

ALTER TABLE CURSO ADD CONSTRAINT CK_Curso_precioCurso CHECK (precioCurso >0) Go

Borrado de índices (DROP INDEX) La sentencia DROP INDEX sirve para eliminar un índice de una tabla. Se elimina el índice pero no las columnas que lo forman. Sintaxis:

DROP INDEX nombre_tabla.nombre_indice Ejemplo:

DROP INDEX curso.pk_curso EJEMPLOS PRÁCTICOS DEL USO DEL DDL ---------------------------------- -- Creación de la base de datos ---------------------------------- USE master go CREATE DATABASE MarketWANKA go USE MarketWANKA go ---------------------------- -- Creación de las tablas ---------------------------- CREATE TABLE GUIA_DETALLE ( IdGuia int NOT NULL, IdProducto int NOT NULL, PrecioVenta money NOT NULL, Cantidad smallint NOT NULL ) go ALTER TABLE GUIA_DETALLE ADD PRIMARY KEY (IdGuia, IdProducto) go CREATE TABLE ORDEN_DETALLE ( IdOrden int NOT NULL, IdProducto int NOT NULL, PrecioCompra money NOT NULL, CantidadSolicitada smallint NOT NULL, CantidadRecibida smallint NULL, Estado varchar(10) NULL ) go ALTER TABLE ORDEN_DETALLE ADD PRIMARY KEY (IdOrden, IdProducto) go CREATE TABLE PRODUCTO ( IdProducto int IDENTITY, IdCategoria int NOT NULL, IdProveedor int NOT NULL, Nombre varchar(40) NOT NULL, UnidadMedida varchar(30) NULL, PrecioProveedor money NULL, StockActual smallint NULL,


78


StockMinimo smallint NULL, Descontinuado bit ) go ALTER TABLE PRODUCTO ADD PRIMARY KEY (IdProducto) go ALTER TABLE PRODUCTO ADD UNIQUE (Nombre, UnidadMedida) Go CREATE TABLE PROVEEDOR ( IdProveedor int IDENTITY, Nombre varchar(40) NOT NULL, Representante varchar(30) NULL, Direccion varchar(60) NULL, Ciudad varchar(15) NULL, Departamento varchar(15) NULL, CodigoPostal varchar(15) NULL, Telefono varchar(15) NULL, Fax varchar(15) NULL ) go ALTER TABLE PROVEEDOR ADD PRIMARY KEY (IdProveedor) go CREATE TABLE CATEGORIA ( IdCategoria int IDENTITY, Categoria varchar(20) NOT NULL, Descripcion varchar(40) NULL ) go ALTER TABLE CATEGORIA ADD PRIMARY KEY (IdCategoria) go ALTER TABLE CATEGORIA ADD UNIQUE (Categoria) go CREATE TABLE GUIA ( IdGuia int NOT NULL, IdLocal int NOT NULL, FechaSalida datetime NOT NULL, Transportista varchar(30) NOT NULL ) go ALTER TABLE GUIA ADD PRIMARY KEY (IdGuia) go CREATE TABLE LOCAL ( IdLocal int NOT NULL, Direccion varchar(60) NULL, Distrito varchar(20) NULL, Telefono varchar(15) NULL, Fax varchar(15) NULL ) go ALTER TABLE LOCAL ADD PRIMARY KEY (IdLocal) go CREATE TABLE ORDEN ( IdOrden int NOT NULL,


79


FechaOrden datetime NOT NULL, FechaEntrada datetime NULL ) go ALTER TABLE ORDEN ADD PRIMARY KEY (IdOrden) go ALTER TABLE GUIA_DETALLE ADD FOREIGN KEY (IdProducto) REFERENCES PRODUCTO go ALTER TABLE GUIA_DETALLE ADD FOREIGN KEY (IdGuia) REFERENCES GUIA go ALTER TABLE ORDEN_DETALLE ADD FOREIGN KEY (IdOrden) REFERENCES ORDEN go ALTER TABLE ORDEN_DETALLE ADD FOREIGN KEY (IdProducto) REFERENCES PRODUCTO go ALTER TABLE PRODUCTO ADD FOREIGN KEY (IdProveedor) REFERENCES PROVEEDOR go ALTER TABLE PRODUCTO ADD FOREIGN KEY (IdCategoria) REFERENCES CATEGORIA go ALTER TABLE GUIA ADD FOREIGN KEY (IdLocal) REFERENCES LOCAL go CASO: Supermercados WANKA S.A.C. es una empresa que se dedica a la comercialización al detalle de diversos productos de consumo masivo. Cuenta con una cadena de locales de autoservicio en distintas zonas del Valle del Mantaro, y planea expandir su influencia a otras zonas de Jauja y Tarma. Todas las áreas de la empresa y sus diferentes locales se interconectarán mediante una red. Cada una de las áreas tiene requerimientos específicos y se pretende resolverlos utilizando aplicaciones ofimáticas. Para efectos del desarrollo del presente caso, delimitaremos el área de estudio a todas las operaciones que llevan a cabo en el Alamacén Central, y que tienen relación con él. La base de datos que se diseñará registrará todas las operaciones que se ejecutan en el Almacén Central, y estará habilitada para que todas las áreas de la organización puedan utilizarla Almacén Central podrá controlar las entradas y salidas de productos, y las demás áreas podrán efectuar consultas a las bases de datos Procesos principales en el Almacén Central de Supermercados WANKA S.A.C. Reposición de mercadería en un Local 1. Si en el Local X, existen productos que necesitan reponerse, el responsable del inventario genera un Pedido en el que

consigna los siguientes datos:

Número del Pedido

Fecha del Pedido

Código del Producto

Descripción del Producto

Unidad de Medida

Cantidad Solicitada

Cantidad de Ítems solicitados

Nota de Pedido No. 06845-03


80


Fecha: 27 diciembre 2005

Item Código Descripción Unidad Cantidad

1 P00003 CARAMELOS FRUTAS ARCOR Pqte. 520gr 300

2 P00007 CHOCOLATE DOÑA PEPA FIELD Pqte. X 6 Unidades 1000

3 P00010 WAFER CHOCOLATE FIELD Pqte. X 9 Unidades 500

4 P00012 CHOCOLATE MOSTRO FIELD Pqte. X 6 Unidades 500

5 P00015 CHOCOLATE BARRA MILK DOVE Unidad 100

6 P00016 CHOCOLATE BARRA DARK DOVE Unidad 100

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

20

Total de Ítems Solicitados: 06

Firma y Sello Autorización

El Número del Pedido es un correlativo seguido de un guión separador y dos dígitos adicionales. Estos últimos identifican al Local que hace el Pedido

2. El Pedido es enviado al Almacén Central Despacho de mercadería desde el Almacén hasta un Local 3. El Almacén Central recibe la solicitud de mercadería del Local X 4. El Almacén Central verifica el stock de los productos solicitados consultando a su Control de Inventarios. Actualmente el

Almacén Central controla el inventario utilizando una lista de Excel en la que se registra los siguientes datos:

Código de la Categoría del Producto



Unidad de Medida

Precio del Proveedor

Precio de Venta al Público

Stock Actual

Stock Mínimo

Estado del Producto (si descontinuado o no)

Nombre del Proveedor 5. El Almacén Central verifica el stock de los productos, y genera una Guía de Remisión en la que considera solo los productos

que tienen el nivel de inventario adecuado para cumplir con los requerimientos del local X. En la Guía de Remisión consigna los siguientes datos:

Número de la Guía de Remisión

Número del Pedido

Local de Destino

Fecha de Salida

Nombre del Transportista



Unidad de Medida

Cantidad despachada

Precio de venta al público (PVP)

Cantidad de ítems despachados 6. Si el Local X no recibe alguno de los productos solicitados debe reiterar su solicitud generando un nuevo Pedido con los

productos no recibidos

Guía de Remisión

No. Guía 001-08937

No. Pedido 06845-03

Fecha 28 diciembre 2005

Transportista Aliaga Vidal, Jeremías Local 03

Item Código Descripción Unidad Cantidad

1 P00003 CARAMELOS FRUTAS ARCOR Pqte. 520gr 300

2 P00007 CHOCOLATE DOÑA PEPA FIELD Pqte. X 6 Unidades 1000

3 P00010 WAFER CHOCOLATE FIELD Pqte. X 9 Unidades 500

4 P00012 CHOCOLATE MOSTRO FIELD Pqte. X 6 Unidades 500

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


81


19

20

Total de Ítems Despachados: 04


Solicitud de mercadería a un Proveedor 7. Cuando el Almacén Central detecta un bajo nivel de Inventario de algunos productos del Proveedor Z, genera una Orden de

Compra consignando los siguientes datos:

Número de la Orden de Compra

Fecha de la Orden

Nombre del Proveedor



Unidad de Medida

Precio del Proveedor

Cantidad a Solicitar

Orden de Compra No. 001-02787


Proveedor Golosinas y antojos Fecha Ingreso

Item Código Descripción Unidad Precio

Proveedor Precio

Compra Cantidad solicitada

Cantidad Recibida

Estado

1 P00013 CHOCOLATE BARRA MILKY WAY

Barra 2.15

onzas 0.30 2000

2 P00015 CHOCOLATE BARRA MILK DOVE

Unidad 1.30 5000

3 P00016 CHOCOLATE BARRA DARK DOVE

Unidad 1.30 5000

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

20



8. El Almacén Central le envía la Orden de Compra al Departamento de Compras 9. Compras se comunica con el Proveedor para verificar y negociar los precios 10. Compras le envía al Proveedor la Orden de Compra consignando en ella el Precio de Compra del Producto





Proveedor Precio


Cantidad Recibida

Estado


Barra 2.15

onzas 0.30 0.80 2000


Unidad 1.30 1.25 5000


Unidad 1.30 1.25 5000

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


82


19

20



Recepción en el Almacén Central de la mercadería enviada por el proveedor 11. El Proveedor despacha todo o parte de lo solicitado según lo acordado con Supermecados WANKA S.A.C. dependiendo de su

disponibilidad 12. El Almacén central recibe lo despachado por el Proveedor y actualiza la Orden de Compra registrando la siguiente información:

Fecha de ingreso de los productos

Cantidad recibida

Estado del Producto en la Orden de Compra





Proveedor Precio


Cantidad Recibida

Estado


Barra 2.15

onzas 0.30 0.80 2000 0 Agotado


Unidad 1.30 1.25 5000 5000 Entregado


Unidad 1.30 1.25 5000 5000 Entregado

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

20



13. El Almacén actualiza la siguiente información en su lista Excel para el Control de Inventarios:

Stock Actual del Producto

Precio del Proveedor 14. Almacén envía al Departamento de Compras, la Orden de Compras, y la Guía y Factura del Proveedor Se desea: Diseñar una base de datos que permita solucionar los requerimientos de información del Almacén Central

EL LENGUAJE DE MANIPULACIÓN DE DATOS (DML)

LA SENTENCIA SELECT LA CLÁUSULA WHERE LA CLÁUSULA GROUP BY LAS CLAÚSULA HAVING LA CLÁUSULA ORDER BY LA SENTENCIA INSERT LA SENTENCIA UPDATE LA SENTENCIA DELETE El lenguaje de Manipulación de Datos permite definir y modificar la estructura de un esquema 1. LA SENTENCIA SELECT

Se emplea en las consultas de selección y 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 que se pueden almacenar en un objeto recordset. Este conjunto de registros es modificable Sintaxis básica:

SELECT * | lista_columnas


83


FROM nombre_tabla [WHERE condición_filas]

lista_columnas: es la lista de columnas a mostrar en el resultado de la consulta. Si se especifica * se mostrarán todas las columnas de la tabla

condición_filas: Es una expresión lógica que indica que las filas a mostrar son aquellas para las que el valor de la expresión es verdadero

A continuación se muestra la sintaxis completa: Sintaxis completa:

SELECT [ ALL | DISTINCT] [ TOP n [ PERCENT ] [WITH TIES] ] lista_columnas [ INTO nueva_tabla ] FROM tabla_origen [ WHERE condición_filas ] [ GROUP BY [ ALL] expresión_agrupar_por… ] [ WITH CUBE | ROLLUP ] [ HAVING condición_grupos ] [ ORDER BY nombre_columna [ ASC | DESC ], …] [ COMPUTE AVG | COUNT | MAX | MIN | SUM (expresión) ]

Lectura de todos los datos de una tabla Ejemplo:

SELECT * FROM Producto

Lectura de campos o columnas seleccionadas de una tabla

Ejemplo:

SELECT idProducto, nombre, unidadMedida, precioProveedor FROM Producto


84


Definiendo alias para los nombres de columna Define títulos alternativos para los nombres de la columna. Si el alias es una frase debe escribirse entre comillas. Ejemplo:

SELECT idProducto AS Código, nombre AS Descripción, unidadMedida AS Unidad, precioProveedor AS 'Precio unitario' FROM Producto

Definiendo columnas computadas Una columna computada es una columna que se muestra en el resultado de una consulta, pero que no existe físicamente como tal en la tabla. La columna computada muestra el resultado de ejecutar alguna operación con las columnas de la tabla Ejemplo:

SELECT idProducto, nombre, precioProveedor, 'Precio con descuento' = precioProveedor * 0.85 FROM Producto

Concatenando cadenas Ejemplo:

SELECT nombre, Ubicación = ciudad + ' - ' + departamento FROM Proveedor

2. LA CLÁUSULA WHERE En la cláusula WHERE, condición_filas es una expresión lógica que establece la condición que deben cumplir las filas a mostrar en el resultado de la consulta. Para construir la expresión lógica puede emplear operadores lógicos SQL como LIKE, BETWEEN e IN.

Tipo de filtro Condición de búsqueda

Operadores de comparación =, >, <, >=, <= y <>

Comparaciones de cadenas LIKE y NOT LIKE

Operadores lógicos: combinación de condiciones AND, OR ,NOT

Intervalo de valores BETWEEN y NOT BETWEEN

Listas de valores IN y NOT IN


85


Valores desconocidos IS NULL e IS NOT NULL

Al especificar filas con la cláusula WHERE, tenga en cuenta los siguientes hechos e instrucciones:

Utilice comillas simples para todos los datos de tipo char, nchar, varchar, nvarchar, text, datetime y smalldatetime.

Utilice una cláusula WHERE para limitar el número de filas que se devuelven al utilizar la instrucción SELECT. 2.1. Operadores de comparación:

Ejemplo: Mostrar la lista de los productos de la categoría de higiene personal, cuyo código de categoría es 3

SELECT idProducto, nombre FROM Producto WHERE idCategoria = 3

Ejemplo: Mostrar la lista de las categorías de los productos con excepción de la categoría de Licores y gaseosas, cuyo código es 5

SELECT idCategoria, categoria FROM Categoria WHERE idCategoria <> 5

Ejemplo: Mostrar la lista de los productos cuyo precio es menor a 5.00

SELECT idCategoria, nombre, precioProveedor FROM Producto WHERE precioProveedor < 5

Ejemplo: Mostrar una lista de los productos cuyos nombres se encuentran después o en la posición de FRUNA SURTIDA DONOFRIO

SELECT idproducto, Nombre FROM Producto


86


WHERE nombre >= 'FRUNA SURTIDA DONOFRIO'

Ejemplo: Mostrar las guías cuyas fechas de salida sean anteriores al 30 de marzo del 2006

SELECT idGuia, fechaSalida FROM Guia WHERE fechaSalida <= '30/03/2006'

Nota: al ejecutar la consulta nótese de que la guías muestran con una fecha de salida anterior al 30/03/2006, pero las guías del 30/03/2006 no se muestran, esto es debido a que la fecha de salida de tipo fecha-hora, SQL asume por defecto „30/03/2006 00:00:00‟ Uso de la función CONVERT() con datos de tipo fecha-hora Sintaxis: CONVERT ( char ( n), expresión_fecha, estilo ) Convierte expresión_fecha a una cadena de formato de fecha. La cadena tiene longitud n, y el formato del dato se establece con el valor de estilo

char (n): Es el tipo y la longitud de la cadena con fomato de fecha resultante

expresión_fecha: Representa la fecha cuyo formato de presentación se desea cambiar

estilo: indica el formato de presentación de lacadena resultante El siguiente formato muestra algunos valores de estilo para la función CONVERT

Año con 2 dígitos Año con 4 dígitos Formato Salida

1 101 USA mm/dd/aa

2 102 ANSI aa.mm.dd

3 103 Británico/ Francés

dd/mm/aa

4 104 Alemán dd.mm.aa

5 105 Italiano dd-mm-aa

6 106 Dd mes aa

7 107 Mes dd, aa

Ejemplo: Se desea obtener el listado de las guías cuya fecha de salida es anterior o igual al 30 de marzo del 2006

SELECT idGuia, fechaSalida FROM Guia WHERE CONVERT( CHAR(10), fechaSalida, 102 ) <= '2006.03.30' ORDER BY fechaSalida

2.2. Comparaciones de cadena

El operador LIKE Sintaxis:

SELECT * | lista_columnas FROM nombre_tabla WHERE columna LIKE expresión_cadena_a_buscar

columna: es la olumna en la que se busca la cadena de caracteres

expresión_cadena_a_buscar: Indica como debe ser la cadena que se está buscando en columna. La expresión admite comodines


87


Comodines:

Comodín Descripción

% Indica que en la posición del comodín puede ir cualquier cadena de caracteres, incluso una cadena nula

- Indica que en la posición del comodín puede ir cualquier carácter no nulo

[abc] Establece el conjunto de caracteres válidos en la posición del comodín

[a-b] Establece el rango de caracteres válidos en la posición del comodín

^ Excluir. Indica que el carácter, conjunto de caracteres, ó rango de caracteres que sigue al símbolo ^ no debe figurar en el resultado de la consulta.

Ejemplo: Se desea obtener la relación de los productos que contienen la cadena „gloria‟ en su nombre

SELECT idProducto, nombre FROM Producto WHERE nombre LIKE 'gloria'

El resultado de este código mostrará 0 filas, dado que se especifica que el nombre sea exactamente la cadena „gloria‟.

SELECT idProducto, nombre FROM Producto WHERE nombre LIKE '%gloria%

Este código nos muestra fila como resultado dado que se indica que puede empezar con cualquier nombre seguido de la palabra gloria, y luego puede ser cualquier otra cadena de caracteres Ejemplo: Mostrar la lista de productos que contengan la palabra blanc antes del último carácter

SELECT idProducto, nombre FROM Producto WHERE nombre LIKE '%blanc_'

Ejemplo: Mostrar la lista de productos que empiecen con las letras p, ó d, ó f

SELECT idProducto, nombre FROM Producto WHERE nombre LIKE '[pdf]%' ORDER BY nombre

Ejemplo:

Mostrar la lista de productos que empiecen con el caracter d hasta el carácter p SELECT idProducto, nombre FROM Producto WHERE nombre LIKE '[d-p]%' ORDER BY nombre go

Ejemplo: Mostrar la lista de productos donde el primer carácter de la columna nombre puede ser cualquiera menos los caracteres : m, s, j

SELECT idProducto, nombre FROM Producto WHERE nombre LIKE '[^msjg]%' ORDER BY nombre Go

2.3. Operadores Lógicos: AND, OR, NOT


88


2.4. Intervalo de valores BETWEEN y NOT BETWEEN

El Operador BETWEEN Permite ejecutar consultas que ejecutan búsquedas basadas en el rango de valores numéricos, cadenas, o valores de fecha Sintaxis:

SELECT * | lista_columnas FROM nombre_tabla WHERE columna BETWEEN valor_inicial AND valor_final

Columna, es la columna en la que se busca según el rango especificado por valor_inicial y valor_final

Valor_inicial, vallor_final, establecen los límites del rango de valores en el que se basa la búsqueda Ejemplo: Mostrar la lista de PRODUCTOS donde el precio del Proveedor esté entre 13.00 y 17.00 Los campos a mostrar deben ser el código del producto, nombre y precio del proveedor; donde el precio del proveedor.

SELECT idProducto, nombre, precioProveedor FROM Producto WHERE precioProveedor BETWEEN 13.76 AND 17.00 ORDER BY precioProveedor

Ejemplo: Mostrar la lista de PRODUCTOS cuyos nombres se encuentren en el rango que va desde el carácter „C‟ hasta el carácter „F‟. Los campos a mostrar deben ser el código del producto, nombre y precio del proveedor; donde el precio del proveedor.

SELECT idProducto, nombre, precioProveedor FROM Producto WHERE nombre BETWEEN 'C' AND 'G' ORDER BY nombre

Ejemplo: Mostrar la lista de PRODUCTOS cuyos nombres se encuentren en el rango que va desde el carácter „C‟ hasta el carácter „F‟. Los campos a mostrar deben ser el código del producto, nombre y precio del proveedor; donde el precio del proveedor.

SELECT idProducto, nombre, precioProveedor FROM Producto WHERE nombre BETWEEN 'C' AND 'G' ORDER BY nombre

Ejemplo: Mostrar la GUÍAS que fueron emitidas respecto a la fecha de salida desde el 20 de marzo del 2006 al 23 de marzo del 2006

SELECT idGuia, fechaSalida FROM Guia WHERE fechaSalida BETWEEN '20/03/2006' AND '23/03/2006' ORDER BY fechaSalida

Esta instrucción mostrará desde 20/03/2006 hasta el 22/03/2006, dado que SQL por defecto considera 23/03/2006 00:00:00 lo cual cualquier guía emitida el días 23 después de las 00:00:00 estaría fuera del rango Para incluir el día 23 escribiríamos la siguiente consulta:

SELECT idGuia, fechaSalida FROM Guia WHERE fechaSalida BETWEEN '20/03/2006' AND '23/03/2006 23:59:59.999' ORDER BY fechaSalida

2.5. Lista de valores IN y NOT IN

El operador IN El operador IN permite ejecutar consultas que ejecutan búsquedas basadas en conjuntos de valores numéricos, valores de cadena, ó valores de fecha.


89


Sintaxis: SELECT * | lista_columnas FROM nombre_tabla WHERE columna [NOT ] IN (conjunto_de_valores)

columna, es la que se busca según el conjunto de valores especificado en conjunto_de_valores

conjunto_de_valores, establece el conjunto de valores en el que se basa la búsqueda Ejemplo: Mostrar el idProducto, nombre, idProveedor de la tabla PRODUCTO cuyos códigos de Proveedores sean 11, 7 y 13

SELECT idProducto, nombre, idProveedor FROM Producto WHERE idProveedor IN ( 11, 7, 13) ORDER BY idProveedor

2.6. Valores desconocidos IS NULL e IS NOT NULL

Un valor NULL indica que el valor es desconocido, no aplicable o simplemente se registrará posteriormente. Ejemplo: Crearemos una tabla EMPLEADO, lo cual contendrá una columna NULL, y en base a esta tabla realizaremos una consulta

CREATE TABLE Empleado( IdEmpleado int PRIMARY KEY, Apellido varchar(30) not null, HaberBasico money not null, PorcentajeComision decimal(3,1) null ) go INSERT INTO Empleado VALUES (1, 'CASTRO ARENAS', 1200, 5) INSERT INTO Empleado VALUES(2, 'LUNA ESPEJO', 1000, 10) INSERT INTO Empleado VALUES(3, 'SOTO BUENO', 1400, NULL) INSERT INTO Empleado VALUES(4, 'MARQUEZ ARIZAGA', 1500, NULL) INSERT INTO Empleado VALUES(5, 'DAVILA SANCHEZ', 1200, 7.5) go

Realizando una consulta que muestre todos los campos de la tabla EMPLEADO que tengan un porcentaje de comisión

SELECT idEmpleado, apellido, haberBasico, porcentajeComision FROM Empleado WHERE porcentajeComision IS NOT NULL

3. LA CLÁUSULA GROUP BY

3.1 GROUP BY La cláusula GROUP BY se utiliza para agrupar las filas en base a determinado criterio, y luego ejecutar una operación que resume un atributo para cada uno de los grupos así formados. Por ejemplo se puede agrupar las facturas por cliente, y luego calcular el monto total facturado de cada cliente. Sintaxis:

SELECT lista_columnas, función_agregación ( columna), función_agregación ( columna),…

FROM nombre_tabla [ WHERE condición_filas] GROUP BY lista_columnas [HAVING condición_grupos]

Las columnas presentes en lista_columnas de la cláusula GROUP BY deben necesariamente estar presentes en la lista_columnas de SELECT

Cualquier columna presente en SELECT, y que no se encuentre en la lista_columnas de GROUP BY debe estar afectada por una función_agregación

condición_grupos en la cláusula HAVING permite establecer una expresión lógica que los grupos a mostrar en el resultado son aquellos para los que el valor de la expresión es verdadero


90


Una consulta GROUP BY solo entrega una fila por cada grupo generado. Esta fila muestra el resultado de la función_agregación aplicada sobre el grupo. No muestra el contenido del grupo

Cuando se utiliza GROUP BY sobre una columna que contiene valores NULL, éstos se procesan como un grupo

Uso de la cláusula GROUP BY a) Cantidad de productos registrados para cada categoría

SELECT idCategoria, count(idProducto) as 'No Productos' FROM PRODUCTO GROUP BY idCategoria

b) Cantidad de productos por proveedor para las categorías 3 y 4

SELECT idCategoria, idProveedor,count(idProducto) as N_Productos FROM PRODUCTO where idCategoria IN (3,4) group by idCategoria, idProveedor order by idCategoria

c) Monto total despachado por producto

SELECT idproducto, SUM(precioVenta*cantidad) FROM GUIA_DETALLE GROUP BY Idproducto

d) Productos cuyo monto total despachado es mayor a 15,000 SELECT idproducto, SUM(precioVenta*cantidad)AS 'Monto Total' FROM GUIA_DETALLE GROUP BY IdProducto HAVING SUM(precioVenta*cantidad)>=15000

e) Stock Actual total de Productos registrados por cada categoría, donde el stock Actual total es mayor o igual a 5,000

SELECT idCategoria, SUM(stockActual)AS 'Stock Actual Total' FROM PRODUCTO GROUP BY IdCategoria HAVING SUM(stockActual)>=5000


91


3.2 Funciones de agregación

Son funciones que permiten efectuar una operación aritmética que resume los valores de una columna de toda la tabla, o que resume los valores de la columna agrupados según determinado criterio

Función Descripción

AVG Utilizada para calcular el promedio de los valores de un campo determinado

COUNT Utilizada para devolver el número de registros de la selección

SUM Utilizada para devolver la suma de todos los valores de un campo determinado

MAX Utilizada para devolver el valor más alto de un campo especificado

MIN Utilizada para devolver el valor más bajo de un campo especificado

Uso de la función AVG ( ) La media calculada por Avg es la media aritmética (la suma de los valores dividido por el número de valores). La función Avg no incluye ningún campo Null en el cálculo. Sintaxis: AVG ( [DISTINCT] expresión numérica) Donde:

DISTINCT: indica que debe eliminarse los valores duplicados de expresión numérica antes de evaluar la función

a) Ejercicio: Obtener el precio promedio de todos los productos en la tabla PRODUCTO SELECT AVG(precioProveedor) FROM PRODUCTO GO

b) Ejercicio: Obtener el precio unitario promedio de todos los productos de la categoría golosinas cuyo código es 1 SELECT AVG(PrecioProveedor) FROM PRODUCTO WHERE idcategoria=1 GO

c) Ejercicio: Obtener el stock promedio de los productos cuyo precio unitario se encuentren entre 10.00 y 20.00

SELECT AVG(PrecioProveedor) FROM PRODUCTO WHERE PrecioProveedor>=10 and PrecioProveedor<=20 GO

Uso de la función COUNT ( ) Sintaxis: COUNT ( [DISTINCT] expresión) COUNT(*) Donde:

DISTINCT: indica que debe eliminarse los valores duplicados de expresión antes de evaluar la función

COUNT (expresión): Ignora los valores NULL de expresión

COUNT (*) : Se utiliza para contar filas, por lo que no ignora los valores NULL f) Ejercicio: Cuenta la cantidad de productos registrados

SELECT COUNT(*) FROM Producto GO

g) Ejercicio: Determinar la cantidad de productos despachados a los diferentes locales de la empresa SELECT COUNT (DISTINCT idProducto) FROM GUIA_DETALLE GO

Uso de las funciones MAX( ) y MIN( ) Sintaxis: MAX(expresión) MIN( expresión)


92


Donde:

expresión: Indica los valores para los que debe hallar el máximo y el mínimo. Si expresión es de tipo fecha retorna la fecha final del rango de valores fecha ordenados y MIN retorna la fecha inicial.

Ejercicio: Obtener el precio más alto y más bajo de los productos registrados en la tabla producto SELECT max (PrecioProveedor), min(precioproveedor) FROM producto GO

Ejercicio: Obtener la guía de remisión más reciente y más antigua SELECT MAX (fechaSalida), MIN (fechaSalida) FROM GUIA GO

Ejercicio: Obtener el nombre del primer producto y del último producto si se ordenaran en base al nombre SELECT MIN (nombre) AS [Primer nombre], MAX (nombre) AS 'Último nombre' FROM PRODUCTO GO

Ejercicio: Obtener el menor y el mayor precio del proveedor LACTEOS DEL CENTRO (IdProveedor=1)

SELECT MIN (PrecioProveedor) AS 'Menor Precio', MAX (PrecioProveedor)AS 'Mayor Precio' FROM producto WHERE idproveedor=1 Go

Uso de la función SUM( ) Sintaxis: SUM ( [ DISTINCT] expresión )

DISTINCT: Indica que debe eliminarse los valores duplicados de expresión antes de evaluar la función a) Ejercicio: Obtener el monto total de los productos salidos del almacén

SELECT SUM (precioVenta*cantidad ) FROM GUIA_detalle go

b) Ejercicio: Obtener el Total de unidades despachadas del producto 5

SELECT SUM (cantidad) FROM GUIA_detalle where idproducto=10 go

4. LA CLÁUSULA ORDER BY

Adicionalmente se puede especificar el orden en que se desean recuperar los registros de las tablas mediante la claúsula ORDER BY Lista de Campos. En donde Lista de campos representa los campos a ordenar. Ejemplo: SELECT CodigoPostal, Nombre, Telefono

FROM Clientes ORDER BY Nombre; Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla Clientes ordenados por el campo Nombre. Se pueden ordenar los registros por mas de un campo, como por ejemplo:

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY CodigoPostal, Nombre;

Incluso se puede especificar el orden de los registros: ascendente mediante la claúsula (ASC -se toma este valor por defecto) ó descendente (DESC)

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY CodigoPostal DESC , Nombre ASC;

5. LA SENTENCIA INSERT

La sentencia de INSERT se utiliza para añadir registros a las tablas de la base de datos. Sintaxis:

INSERT INTO nombre_fichero [(nombre_columna, ...)] VALUES (expr, ...) Donde:

nombre_fichero puede ser únicamente el nombre del fichero o el nombre completo con su camino. Si se utiliza solo el nombre del fichero se utiliza el directorio donde se encuentran los ficheros de la aplicación (C:\geiwin\datos).


93


nombre_columna es una lista opcional de nombres de campo en los que se insertarán valores en el mismo número y orden que se especificarán en la cláusula VALUES. Si no se especifica la lista de campos, los valores de expr en la cláusula VALUES deben ser tantos como campos tenga la tabla y en el mismo orden que se definieron al crear la tabla. expr es una lista de expresiones o valores constantes, separados por comas, para dar valor a los distintos campos del registro que se añadirá a la tabla. Las cadenas de caracteres deberán estar encerradas entre comillas „ o " y las fechas entre llaves { }.

Ejemplo para añadir un registro a la tabla creada en el ejemplo de CREATE: INSERT INTO D:\LIBROS (TITULO, PAGINAS, FECHA) VALUES („Gestión Escolar Integrada‟, 234,{12/27/95})

Cada sentencia INSERT añade un único registro a la tabla. En el ejemplo solo se han especificado 3 campos con sus respectivos valores, el resto de campos quedaran a nulo. Un valor nulo NULL no significa blancos o ceros sino simplemente que el campo nunca ha tenido un valor.

6. LA SENTENCIA UPDATE La sentencia UPDATE se utiliza para cambiar el contenido de los registros de una tabla de la base de datos.

Sintaxis: UPDATE nombre_fichero SET nombre_columna = expr, ... [WHERE { condición }]

Donde: nombre_fichero puede ser únicamente el nombre del fichero o el nombre completo con su camino. Si se utiliza solo el nombre del fichero se utiliza el directorio donde se encuentran los ficheros de la aplicación (C:\geiwin\datos). nombre_columna es el nombre de columna o campo cuyo valor se desea cambiar. En una misma sentencia UPDATE pueden actualizarse varios campos de cada registro de la tabla. expr es el nuevo valor que se desea asignar al campo que le precede. La expresión puede ser un valor constante o una subconsulta. Las cadenas de caracteres deberán estar encerradas entre comillas „ o " y las fechas entre llaves { }. Las subconsultas entre paréntesis.

La cláusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y determina que registros se modificarán. Por ejemplo, subir el precio de compra de la tabla de libros un 10% de aquellos que tengan más de 250 páginas, sería:

UPDATE D:\LIBROS SET PRECIO = PRECIO * 1.1 WHERE PAGINAS > 250

Otro ejemplo, para fijar la fecha de matrícula de todos aquellos alumnos que la tienen vacía a la fecha de hoy, se pondría: UPDATE MATRICUL SET FECHA_MATRICULA = TODAY() WHERE FECHA_MATRICULA IS NULL

Ejemplo utilizando una subconsulta: UPDATE D:\LIBROS SET PRECIO = (SELECT AVG(PRECIO) FROM D:\LIBROS WHERE PRECIO IS NOT NULL) WHERE PRECIO IS NULL

Con esta última sentencia se ha puesto precio a todos los libros que no lo tenían. Ese precio ha sido el resultante de calcular la medía entre los libros que si lo tenían

7. LA SENTENCIA DELETE La sentencia DELETE se utiliza para borrar registros de una tabla de la base de datos.

Sintaxis: DELETE FROM nombre_fichero [WHERE { condición }]

En donde: nombre_fichero puede ser únicamente el nombre del fichero o el nombre completo con su camino. Si se utiliza solo el nombre del fichero se utiliza el directorio donde se encuentran los ficheros de la aplicación (C:\geiwin\datos).

La cláusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y determina que registros se borrarán. Cada sentencia DELETE borra los registros que cumplen la condición impuesta o todos si no se indica cláusula WHERE.

DELETE FROM D:\LIBROS WHERE MOD(TODAY - FECHA,365) > 20

Con el ejemplo anterior se borrarían todos los registros de la tabla libros cuya antigüedad, desde la fecha de adquisición, fuera mayor de 20 años. Para borrar las notas de evaluaciones que, no sean la Final, de los alumnos de años anteriores se utilizaría la sentencia:

DELETE FROM NOTAS WHERE ANNO < 1995 AND EVALUACION <> „F‟

CONSULTAS MULTITABLAS En la mayoría de los casos, la recuperación de los datos que los usuarios necesitan para trabajar implica la lectura de muchas tablas para que la información obtenida sea de utilidad. Consultas Correlacionadas Un join, combinación ó consulta correlacionada, es la consulta que selecciona columnas de dos tablas o conjuntos de filas, y las entrega en un único conjunto de resultados. Las filas de las tablas o conjuntos de filas se combinan relacionando valores comunes, tíìcamente valores de clave primaria y clave foránea. Sintaxis General:

SELECT lista_columnas


94


FROM tabla1 Tipo_join JOIN tabla2 ON condicion_del_join

lista_columnas: Es la lista de columnas a mostrar en el resultado de la consulta. Se recomienda que cada columna sea calificada con el alias de la tabla al cual pertenece

tipo_join: Indica si el join es interior (INNER), exterior (OUTER) o irrestricto (CROSS)

condicion_del_join: es una expresión que indica en base a qué columnas de cada una de las tablas se establece la relación entre ellas

Una combinación (join) puede ser de cualquiera de los siguientes tipos:

inner join - left outer join - right outer join - full outer join

outer join

cross join Inner Join Un inner join es la consulta correlacionada que combina todas las filas que están relacionadas de las dos tablas ó conjuntos de tablas Ejemplo: Obtener una lista de los productos que registran salida del almacén, los campos a mostrar de la lista deben ser el código del producto, y el nombre del producto

SELECT DISTINCT Guia_detalle.idproducto, nombre FROM Guia_detalle INNER JOIN Producto ON Guia_detalle.idProducto=Producto.IdProducto ORDER BY Guia_detalle.idproducto go Simplificando tenemos: SELECT DISTINCT gd.idproducto, p.nombre FROM Guia_detalle gd INNER JOIN Producto p ON gd.idProducto = p.IdProducto ORDER BY gd.idproducto go

Ejemplo: Escriba una consulta que lista el catálogo de productos de la empresa. Los campos a mostrar debe ser categoría, Improducto, Nombre, UnidadMedida, PrecioProveedor, además debe estar ordenado por categoría, y luego por el código del producto

Ejemplo: Escribir una consulta que muestre los datos de la cabecera de la guía de remisión de número 27, y además su monto total


95


SELECT Guia.IdGuia, Guia.IdLocal, Guia.FechaSalida, sum(Guia_detalle.PrecioVenta* Guia_detalle.Cantidad) AS „Monto Total‟ FROM Guia INNER JOIN Guia_detalle ON Guia.IdGuia = Guia_detalle.IdGuia GROUP BY Guia.IdGuia, Guia.IdLocal, Guia.FechaSalida HAVING Guia.IdGuia=15

Ejemplo: Escribir la consulta anterior que muestre la dirección del local al que se enviaron los productos registrados en la guía de remisión número 18

SELECT Guia.IdGuia, Local.Direccion,Guia.FechaSalida, sum(Guia_detalle.PrecioVenta* Guia_detalle.Cantidad) AS 'Monto Total' FROM Guia INNER JOIN Guia_detalle ON Guia.IdGuia = Guia_detalle.IdGuia INNER JOIN Local ON Guia.IdLocal=Local.IdLocal GROUP BY Guia.IdGuia, Local.Direccion, Guia.FechaSalida HAVING Guia.IdGuia=18

Ejemplo: Escribir la consulta que muestre el monto total enviado a cada Distrito

SELECT Local.Distrito, Monto = SUM(Guia_detalle.precioVenta * Guia_detalle.cantidad) FROM Local INNER JOIN Guia ON Local.idLocal = Guia.idLocal INNER JOIN Guia_detalle ON Guia.idGuia = Guia_detalle.idGuia GROUP BY Local.Distrito

Ejemplo: Escribir la consulta que muestre el total de Unidades despachados al mes del producto de Código 7

SELECT YEAR(Guia.fechaSalida) AS Año, MONTH(Guia.fechaSalida) AS Mes, SUM (Guia_detalle. cantidad) As Unidades FROM Guia INNER JOIN Guia_detalle ON Guia.idGuia = Guia_detalle.idGuia WHERE Guia_detalle.idProducto = 7 GROUP BY YEAR(Guia.fechaSalida) , MONTH(Guia.fechaSalida) ORDER BY Año, Mes

Ejemplo: Escribir la consulta que muestre el total de Unidades mensuales de cada producto

SELECT producto.idproducto, Producto. nombre, YEAR(Guia.fechaSalida) AS Año, MONTH(Guia.fechaSalida) AS Mes, SUM(Guia_detalle.cantidad) As Unidades FROM Guia INNER JOIN Guia_detalle ON Guia.idGuia = Guia_detalle.idGuia INNER JOIN Producto ON Guia_detalle.idProducto = producto.idproducto GROUP BY producto.idproducto, Producto. nombre, YEAR(Guia.fechaSalida), MONTH(Guia.fechaSalida)


96


ORDER BY producto.idproducto, Año, Mes

Outer Join Un outer join es la consulta correlacionada que entrega todas las filas que están relacionadas, y además:

las filas no relacionadas de la tabla izquierda (LEFT OUTER JOIN), ó

las filas no relacionadas de la tabla derecha (RIGHT OUTER JOIN), ó

las filas no relacionadas de ambas tablas (FULL OUTER JOIN) Se considera como la tabla izquierda, a aquella que se menciona primero en la cláusula FROM. Ejemplo: Escribir la consulta de los productos que NO registran salida del almacén. .

SELECT producto.idproducto, Producto. nombre FROM Producto LEFT OUTER JOIN Guia_detalle

ON producto.idproducto = Guia_detalle.idProducto ORDER BY Producto.idproducto

Al haber ejecutar la consulta se puede observar que el producto 4 aparece varias veces en el resultado. Esto indica que del producto 4 se tienen varias salidas registradas en la tabla Guia_detalle. Recuerde que una consulta OUTER JOIN entrega filas relacionadas y filas no relacionadas. La consulta es LEFT OUTER JOIN porque estamos buscando valores de idProducto que se encuentran en la tabla Producto, pero que no están en la tabla Guia_detalle. Añadimos a la consulta anterior la columna cantidad de la tabla Guia_detalle.

SELECT producto.idproducto, Producto. nombre, Guia_detalle.cantidad FROM Producto LEFT OUTER JOIN Guia_detalle ON producto.idproducto = Guia_detalle.idProducto ORDER BY producto.idproducto

Note que para el producto 5, el valor en cantidad es NULL. Este producto es uno de los productos que NO registra salida del almacén. Modifique la consulta anterior para que muestre solo los productos que NO registran salida del almacén.


97


SELECT producto.idproducto, producto.nombre FROM Producto LEFT OUTER JOIN Guia_detalle ON producto.idproducto = Guia_detalle.idProducto WHERE Guia_detalle.cantidad IS NULL ORDER BY Producto.idProducto

Hay 72 productos que NO tienen registrada salida del almacén, que sumados a los 66 productos que tienen salida registrada, nos da un total de 138 productos. Ejemplo: Escribir la consulta que muestre el reporte de unidades despachadas de cada producto

SELECT producto.idproducto, Producto. nombre, SUM(Guia_detalle.cantidad) AS Unidades FROM Producto INNER JOIN Guia_detalle ON producto.idproducto = Guia_detalle.idProducto GROUP BY producto.idproducto, Producto. nombre ORDER BY producto.idproducto

Note que el resultado no muestra todos los productos. Para que se muestren todos los productos convierta la consulta INNER JOIN en una consulta OUTER JOIN, y para los productos en los que cantidad es NULL que se muestre O (cero) como el valor en cantidad.

SELECT Producto.idProducto, Producto.nombre, ISNULL(SUM(Guia_detalle.cantidad) , 0) AS Unidades FROM Producto LEFT OUTER JOIN Guia_detalle ON producto.idProducto = Guia_detalle.idProducto GROUP BY producto.idproducto, Producto.nombre ORDER BY producto.idproducto

La instrucción SELECT...INTO Puede colocar el resultado de cualquier consulta en una nueva tabla usando la sentencia SELECT...INTO. Use la sentencia SELECT...INTO para crear nuevas tablas en la base de datos. También puede usar la sentencia SELECT INTO para solucionar problemas en los que requiere leer datos desde varias fuentes. Sintaxis:

SELECT lista_columnas INTO nombre_nueva_tabla FROM tabla WHERE condición_filas

SELECT...INTO siempre crea la tabla destino. Si el nombre especificado en nombre_nueva_tabla ya existe se produce un error.


98


Ejemplo: Escribir la consulta que cree una tabla de nombre Monto_guias que registre el monto de cada una de las guías de remisión.

SELECT Guia.idGuia, Guia.fechaSalida, SUM(Guia_detalle.precioVenta * Guia_detalle.cantidad) AS Monto

INTO Monto_guias FROM Guia INNER JOIN Guia_detalle

ON Guia.idGuia = Guia_detalle.idGuia GROUP BY Guia.idGuia, Guia.fechaSalida ORDER BY Guia.idGuia Go Revisando la tabla: SELECT * from Monto_guias Go

Ejemplo: Crear una tabla temporal que contenga los siguientes columnas: el código de Orden de Compra, y su fecha respectiva, además del monto por cada número de Orden Cuando en una instrucción que crea una tabla se especifica el nombre de la tabla precedido del símbolo #, el objeto se crea como una tabla temporal.

SELECT Orden.idOrden, Orden.fechaOrden, SUM(Orden_detalle.precioCompra *Orden_detalle.cantidadRecibida) AS Monto INTO #Monto_ordenes FROM Orden INNER JOIN Orden_detalle ON Orden.idOrden = Orden_detalle.idOrden GROUP BY Orden.idOrden, Orden.fechaOrden ORDER BY Orden.idOrden

Para consultar la tabla temporal, ejecute: SELECT * FROM #Monto_ordenes

Consulta autojoin Es una consulta correlacionada en la que una tabla se combina consigo misma para generar un nuevo conjunto de resultados. Ejemplo: Para ilustrar este tipo de consulta crearemos una tabla que tenga una autorelación. . Esta tabla contiene una clave foránea que apunta a la clave primaria en la misma tabla.


99


Ejecute las siguientes instrucciones para crear y cargar los datos en la tabla. -- Consulta autojoin, creación de la tabla con autorelación CREATE TABLE Trabajador ( idTrabajador int NOT NULL PRIMARY KEY, Apellidos varchar(30) NOT NULL, Jefe int NULL ) Go ALTER TABLE Trabajador ADD CONSTRAINT fk_Trabajador_Trabajador FOREIGN KEY(Jefe) REFERENCES Trabajador Go INSERT INTO Trabajador VALUES(102, 'Ardiles Soto', NULL) INSERT INTO Trabajador VALUES(101, 'Camacho Saravia',102) INSERT INTO Trabajador VALUES(105, 'Vilchez Santos',102) INSERT INTO Trabajador VALUES(103,'Sánchez Aliaga',101) INSERT INTO Trabajador VALUES(104,'Castro Avila',101) INSERT INTO Trabajador VALUES(107,'Urrunaga Tapia',101) INSERT INTO Trabajador VALUES(106,'Juárez Pinto',105) go SELECT * FROM Trabajador Go

La columna jefe de la tabla Trabajador registra el código del jefe de un trabajador. Por ejemplo, el trabajador 101 (Camacho Saravia) es el jefe de los trabajadores 103, 104 Y 107. Se desea crear una consulta que muestre una lista de trabajadores. La lista debe mostrar los apellidos del jefe de cada trabajador. SELECT Tr.idTrabajador, Tr.apellidos, Trj.apellidos AS Jefe FROM Trabajador Tr INNER JOIN Trabajador Trj ON Tr.jefe = Trj.idTrabajador


100


Note que el resultado muestra a todos los trabajadores con su respectivo jefe, pero el trabajador 102 (Ardiles Soto) no aparece en la lista porque él no tiene jefe. Modificar la consulta para que se muestre también el trabajador 102

SELECT Tr.idTrabajador, Tr.apellidos, Trj.apellidos AS Jefe FROM Trabajador Tr LEFT OUTER JOIN Trabajador Trj ON Tr.jefe = Trj.idTrabajador

SUBCONSULTAS Un subconsulta es una declaración SELECT anidada dentro una sentencia SELECT, INSERT, UPDATE o DELETE o dentro de otra subconsulta. Si la respuesta a un requerimiento de datos requiere la ejecución de una serie de pasos lógicos, utilice subconsultas para tratar de resolver el requerimiento con una sola sentencia. Las subconsultas son de los tipos siguientes:

Subconsulta que entrega un solo valor (1 fila, 1 columna)

Subconsulta que entrega un conjunto de valores (varias filas, 1 columna) Una subconsulta se especifica entre paréntesis, y se puede especificar en cualquier parte donde la sintáxis permite una expresión. Subconsulta que entrega un solo valor (1 fila, 1 columna) Cuando la subconsulta se especifica:

en la lista de columnas del SELECT externo, ó

en la cláusula WHERE del SELECT externo usando un operador relacional (test de comparación), la subconsulta debe ser una que entregue un solo valor. Ejemplo: Escribir una consulta que entregue la lista de precios de todos los productos, especificando en una columna adicional la diferencia entre el precio de cada producto y el precio promedio de todos los productos. Primero, especifique la consulta que entrega el precio promedio de todos los productos.

SELECT AVG(precioProveedor) FROM Producto go

Ahora, escriba la consulta que entrega la lista de precios solicitada teniendo en cuenta la fórmula que determina la diferencia entre el precio de cada producto y el precio promedio de todos los productos.

SELECT idproducto, nombre, precioProveedor, Diferencia = precioProveedor - (SELECT AVG(precioProveedor) FROM Producto) FROM Producto


101


Go

Ejemplo: Escribir una consulta que muestre el Porcentaje de unidades despachadas de cada producto de la categoría 4 respecto al total despachado de la categoría Primero, escriba la consulta que calcula el total despachado para la categoría 4.

SELECT SUM(cantidad) FROM Guia_detalle INNER JOIN Producto ON Guia_detalle.idProducto = producto.idproducto WHERE Producto.idCategoria = 4 Go

Ahora, escriba la consulta que, utilizando la consulta anterior, presente el listado requerido. SELECT producto.idproducto, Producto. nombre, Despachado = ISNULL(SUM(Guia_detalle.cantidad), 0), Porcentaje = CONVERT(float, ISNULL(SUM(Guia_detalle.cantidad), 0)) / (SELECT SUM(cantidad) FROM Guia_detalle INNER JOIN Producto ON Guia_detalle.idProducto = producto.idproducto WHERE Producto.idCategoria = 4) * 100 FROM Producto LEFT OUTER JOIN Guia_detalle ON producto.idproducto = Guia_detalle.idProducto WHERE Producto.idCategoria = 4 GROUP BY producto.idproducto, Producto. nombre go Ejemplo: Escriba una consulta que entregue una lista de los productos que se despacharon en la fecha que se despachó la última salida del almacén. Tenga en cuenta que en dicha fecha se puede haber registrado más de una salida. Primero, obtenga la fecha de la última salida

SELECT MAX(fechaSalida) FROM Guia go

Ahora, utilizando adecuadamente la consulta anterior, escriba la consulta que responde al requerimiento especificado. SELECT DISTINCT Guia_detalle.idProducto, Producto. nombre FROM Guia_detalle INNER JOIN Producto ON Guia_detalle.idProducto = Producto.idproducto INNER JOIN Guia ON Guia_detalle.idGuia = Guia.idGuia WHERE CONVERT(char(10), Guia.fechaSalida, 103) = (SELECT CONVERT(char(10), MAX(fechaSalida), 103) FROM Guia)


102


go

Subconsulta que entrega un conjunto de valores (varias filas, 1 columna) Cuando la subconsulta se define en la cláusula WHERE del SELECT externo utilizando el operador IN (test de pertenencia), puede ser una subconsulta que entrega un conjunto de valores. Ejemplo: Escriba una consulta que entregue una lista de los productos que no registran salida del almacén. Use la cláusula NOT IN

SELECT idProducto, nombre FROM Producto WHERE idProducto NOT IN (SELECT idproducto FROM Guia_detalle) ORDER BY idproducto go

Subconsulta correlacionada Se presenta cuando la consulta externa debe entregar datos a la consulta interna para que se pueda ejecutar. La consulta interna se evalúa repetidamente, una vez por cada fila de la consulta externa. Se puede definir en la cláusula WHERE de la consulta externa usando el operador EXISTS (Test de existencia). Ejemplo: Genere la lista de productos que registran salida del almacén.

SELECT producto.idproducto, Producto. nombre FROM Producto WHERE EXISTS (SELECT * FROM Guia_detalle WHERE producto.idproducto = Guia_detalle.idProducto) ORDER BY producto.idproducto go


103


ADMINISTRACIÓN DE BASES DE DATOS GESTIÓN DE BASE DE DATOS

Bases de datos predeterminadas en SQL Server

Archivos de una base de datos

Creación de una Base de Datos

Recopilación de información de la Base de Datos

Configuración de opciones de la Base de Datos

Administración de los archivos de la Base de Datos

Renombrar una Base de Datos

Trabajar con grupos de archivos de Base de Datos

Eliminación de una Base de Datos Una Base de datos es una colección de tablas que contienen datos y además otros objetos tales como vistas, índices, procedimientos almacenados, funciones definidas por el usuario, definidos para soportar las operaciones a ejecutar con los datos. Bases de datos Predeterminadas Después de instalar SQL Server 2000, se instalan las bases de datos siguientes

Bases de datos del Sistema Estas bases de datos del sistema no las puede quitar

- Master: Es la clave para ejecutar SQL Server - Model: Es como si fuera una plantilla para la creación de una nueva base de datos. Por lo tanto cualquier

objeto que exista en la base de datos model se copia a la nueva base de datos - Tempdb: Es el lugar donde se realizan los ordenamientos, las uniones y demás actividades que requieren un

espacio temporal

Base de Datos Ejemplos Las siguientes Bases de datos son ejemplos propios de SQL Server, si desea puede quitarles y no ocasionará problemas en sus servidores SQL Server

- Pubs: Es una herramienta de aprendizaje acerca de una editorial que incluye información acerca de los autores, libros y ventas

- Northwind (Neptuno): Ha sido la base de datos de ejemplo que se proporciona con Microsoft Access

Archivos de una Base de Datos Una Base de Datos SQL está formada por tres tipos de archivos:

a) Archivo primario Es el archivo de inicio de una base de datos. Almacena las tablas de sistema de la base de datos, y puede también almacenar las tablas de usuario y otros objetos de la base de datos. Cada base de datos tiene un solo archivo primario, siendo .mdf la extensión del archivo

b) Archivos secundarios Se usan para almacenar tablas de usuario y demás objetos de la base de datos. Si el archivo primario almacena todos los objetos, entonces el uso de los archivos secundarios no es necesario. Sin embargo en ocasiones, la base de datos es muy grande siendo necesario distribuir en múltiples archivos secundarios, pudiendo distribuirse en diferentes discos. La extensión de los archivos secundarios es .ndf

c) Archivo de registro de transacciones (transact log) Este archivo registra todas las transacciones a ejecutar sobre la base de datos y es un mecanismo de seguridad para recuperar la base de datos ante la eventualidad de una falla en el sistema. Toda Base de Datos debe tener por lo menos un archivo de transacciones. La extensión del archivo es .ldf ¿Cómo trabaja el registro de transacciones? El archivo de registro de transacciones almacena todas las transacciones llevadas a cabo con las sentencias INSERT, UPDATE, y DELETE; es decir graba todas las modificaciones de datos a medida que se producen


104


SQL Server graba todas las transacciones en un registro de transacciones para mantener la coherencia de la base de datos y facilitar la recuperación. El registro es un área de almacenamiento que efectúa automáticamente el seguimiento de todos los cambios en la base de datos. SQL Server graba las modificaciones al registro en disco cuando se ejecutan,

El proceso de registro es el siguiente: 1. La aplicación envía una modificación de datos. 2. Cuando la modificación se ejecuta, las páginas de datos afectadas se cargan en la caché del búfer desde el disco. 3. Cada instrucción de modificación de datos se graba en el registro mientras se ejecuta. El cambio siempre se graba en el

registro y se escribe en disco antes de hacer la modificación en la base de datos. Este tipo de registro se denomina registro de preescritura.

4. De forma repetitiva, el proceso de punto de comprobación escribe en disco todas las transacciones completadas en la base de datos.

Si se produce un error del sistema, el proceso automático de recuperación utiliza el registro de transacciones para aplicar todas las transacciones confirmadas y deshacer las transacciones incompletas.

CREACIÓN DE UNA BASE DE DATOS Puede definir una base de datos mediante el Administrador corporativo de SQL Server o mediante la instrucción CREATE DATABASE en el Analizador de consultas SQL. El proceso de definición de una base de datos crea también un registro de transacciones para esa base de datos.

Sintaxis: CREATE DATABASE nombre_base_datos ON [ PRIMARY] (

NAME = nombre_lógico_data, FILENAME = „ubicación _y_nombre_archivo_data‟, SIZE= tamaño [KB|MB|GB|TB], MAXSIZE= tamaño_máximo [KB|MB|GB|TB|UNLIMITED %], FILEGROWTH=incremento_crecimiento [KB|MB|%] )

LOG ON ( NAME = nombre_lógico_log, FILENAME = „ubicación _y_nombre_archivo_log‟, SIZE= tamaño [KB|MB|GB|TB], MAXSIZE= tamaño_máximo [KB|MB|GB|TB|UNLIMITED %] , FILEGROWTH=incremento_crecimiento [KB|MB|%] )

Donde:

ON PRIMARY: Define las propiedades del archivo primario. El grupo de archivos principal o primario contiene todas las tablas del sistema de la base de datos. Todas las bases de datos tienen un archivo de datos principal.

LOG ON: Define las propiedades del archivo de registro de transacciones

nombre_lógico_data, nombre_lógico_log: Es el nombre a utilizar cuando en una sentencia SQL se tiene que hacer referencia al archivo de datos o al archivo log respectivamente

ubicación _y_nombre_archivo: es una cadena que incluye la ruta y el nombre de archivo

tamaño: especifica el tamaño del archivo, el tamaño especificado para el archivo de datos principal debe ser, al menos, como el tamaño del archivo principal de la base de datos model


105


tamaño_máximo: es el máximo tamaño que puede alcanzar el archivo si se requiere de espacio adicional, Si no se especifica el tamaño, el archivo crece hasta que el disco esté lleno.

incremento_crecimiento: es la cantidad de espacio que se añade al archivo cada vez que se necesita espacio adicional. El valor de FILEGROWTH de un archivo no puede sobrepasar el valor de MAXSIZE. Un valor de 0 indica que no hay crecimiento.

Ejemplo: El siguiente ejemplo crea una base de datos denominada BDEjemplo con un archivo de datos principal de 10 MB con un 20 % de crecimiento, con tamaño máximo de 15 MB y un archivo de registro de 3 MB

CREATE DATABASE BDEjemplo ON PRIMARY ( NAME=BDEjemplo_Data,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\BDEjemplo_Data.mdf', SIZE=10 MB, MAXSIZE= 15MB, FILEGROWTH=20%

) LOG ON ( NAME=BDEjemplo_log,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\BDEjemplo_Log.ldf', SIZE=3MB, MAXSIZE=5MB, FILEGROWTH=1MB );

Nota: Cuando se crea una Base de Datos se añade una entrada con el nombre de la base de datos en la tabla de sistema sysdatabases de la base de datos master Ejemplo: Crear una Base de Datos de nombre AlquilerVideos que almacene dos archivos de datos, con tamaño normal de 8MB con un máximo tamaño de 15MB, y un crecimento del 18%. Debe almacenar también dos archivos de registros de tamaño normal de 4MB

CREATE DATABASE AlquilerVideos ON PRIMARY ( NAME=AlquilerVideos_Data1,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\AlquilerVideos_Data1.mdf', SIZE=8MB, MAXSIZE=15MB, FILEGROWTH=18% ), ( NAME=AlquilerVideos_Data2,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\AlquilerVideos_Data2.ndf', SIZE=8MB, MAXSIZE=15MB, FILEGROWTH=18% ) LOG ON ( NAME=AlquilerVideos_Log1,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\AlquilerVideos_Log1.ldf', SIZE=4MB, MAXSIZE=15MB, FILEGROWTH=1MB ), ( NAME=AlquilerVideos_Log2,

FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\AlquilerVideos_Log2.ldf', SIZE=4MB, MAXSIZE=10MB, FILEGROWTH=2MB ) GO

RECOPILACIÓN DE INFORMACIÓN DE LA BASE DE DATOS


106


Puede recopilar información de su base de datos de varias formas. Puede utilizar el Administrador Corporativo o el Analizador de Consultas de SQL Server y ejecutar algunos procedimientos almacenados del sistema.

Ejemplo:

EXEC sp_helpdb Go

Ejemplo:

EXEC sp_helpdb AlquilerVideos Go

CONFIGURACIÓN DE OPCIONES DE LA BASE DE DATOS Después de haber creado una base de datos, puede definir opciones de base de datos con el Administrador corporativo de SQL Server o por medio de la instrucción ALTER DATABASE. Puede configurar varias opciones de base de datos, pero sólo se puede hacer en una sola base de datos al mismo tiempo. Para que las opciones afecten a todas las bases de datos nuevas, cambie la base de datos model. Mediante el Administrador Corporativo

1. Ubicar la Base de Datos con la que desea trabajar (Emplearemos la Base de Datos Alquiler de Videos) 2. Hacer clic con el botón derecho y seleccionar la opción Propiedades del menú contextual 3. Luego se mostrará el cuadro de diálogo Propiedades 4. Hacer clic en la ficha opciones 5. Activar el acceso como un único usuario

EXEC sp_helpdb EXEC sp_helpdb baseDeDatos


107


ADMINISTRACIÓN DE LOS ARCHIVOS DE LA BASE DE DATOS ALTER DATABASE .. Permite añadir o eliminar archivos de una base de datos. Se puede utilizar también para modificar los atributos de los archivos, tales como el nombre o el tamaño de un archivo. También se puede usar para cambiar el nombre de una base de datos, y para configurar las opciones de configuración de una base de datos. Sintaxis: ALTER DATABASE nombre_base_datos ADD FILE especificación_archivo, …

| ADD LOG FILE especificación_archivo | REMOVE FILE nombre_lógico_archivo | MODIFY FILE especificación archivo

especificación_archivo: son los atributos del archivo de base de datos tal como se definieron en el comando CREATE DATABASE

opción_configuración_base_datos: es una de las opciones de configuración de base de datos definidas en el procedimiento sp_dboption

Ejemplo: Incrementar el tamaño de la Base de Datos BDEjemplo:

1. Visualizamos el tamaño de la Base de Datos USE Master go sp_helpdb BDEjemplo go


108


2. Cambiamos el tamaño del archivo primario ALTER DATABASE BDEjemplo MODIFY FILE ( NAME=BDEjemplo_Data, SIZE=20MB ) go sp_helpdb BDEjemplo go

Ejercicio: Incrementar el tamaño de la Base de Datos AlquilerVideos Ejemplo: Añadir un archivo secundario a la Base de Datos BDEjemplo

ALTER DATABASE BDEjemplo ADD FILE ( NAME=BDEjemplo_Data2, FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\BDEjemplo_Data2.ndf', SIZE=5MB, MAXSIZE=10MB, FILEGROWTH=1MB ) Go sp_helpdb BDEjemplo go

Ejemplo: Añadir un archivo de registro de tamaño 6MB a la base de datos BDEjemplo ALTER DATABASE BDEjemplo ADD LOG FILE ( NAME=BDEjemplo_Log2, FILENAME='C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\BDEjemplo_Log2.ldf', SIZE=6MB, MAXSIZE=10MB, FILEGROWTH=2MB


109


) sp_helpdb BDEjemplo go

Ejemplo: Eliminación de un archivo de la base de datos BDEjemplo

ALTER DATABASE BDEjemplo REMOVE FILE BDEjemplo_Data2 Go

RENOMBRAR UNA BASE DE DATOS Para cambiar el nombre de la base de datos deberá ejecutar el siguiente procedimiento almacenado del sistema llamado sp_renamedb Sintaxis:

EXEC sp_renamedb „nombre_anterior‟ , „nombre_nuevo‟ Previamente debe tomar en cuenta lo siguiente:

Algunas secuencia de comando de SQL podrían depender del nombre de la base de datos para ejecutarse correctamente

La base de datos debe encontrarse en modo de un único usuario

Si cambia el nombre de la base de datos los nombres de los archivos, así como los de los grupos de archivos no saldrán afectados

Para ejecutar el procedimiento almacenado del sistema llamado sp_renamedb, debe encontrarse en la base de datos Master

REDUCCIÓN DEL TAMAÑO DE UNA BASE DE DATOS La instrucción DBCC SHRINKFILE Reduce el tamaño de un archivo de base de datos para la base de datos activa Sintaxis: DBCC SHRINKFILE ( nombre_lógico_archivo, tamaño_final_en_MB) Solo pueden ejecutar esta instrucción los miembros del rol fijo de servidor sysadmin y del rol fijo de base de datos db_owner La instrucción DBCC SHRINKDATABASE Reduce el tamaño de los archivos de datos de la base de datos especificada Sintaxis:

DBCC SHRINKDATABASE (nombre_base_datos, porcentaje_espacio_libre_después_reducción)

Solo pueden ejecutar esta instrucción los miembros del rol fijo de servidor sysadmin y del rol fijo de base de datos db_owner Ejemplo: Reducir el tamaño del archivo primario de la base de datos BDEjemplo hasta 10MB

Use BDEjemplo Go DBCC SHRINKFILE(BDEjemplo_Data, 10) Go


110


Ejemplo: Reducir el tamaño de registros BDEjemplo_Log2 hasta 4MB

DBCC SHRINKFILE(BDEjemplo_Log2, 4) Go Sp_helpdbBDEJEMPLO Go

Ejemplo: Reducir toda la Base de Datos hasta que quede sólo 50% de espacio libre

DBCC SHRINKDATABASE (BDEjemplo, 50) ELIMINACIÓN DEL TAMAÑO DE UNA BASE DE DATOS Cuando eliminamos una base de datos, se eliminan los archivos que conforman la base de datos. Si no se dispone de copia de seguridad de estos archivos, la base de datos se pierde definitivamente La instrucción DROP DATABASE Elimina una o más bases de datos de un servidor SQL. La operación elimina los archivos que conforman la base de datos. Sintaxis: DROP DATABASE nombre_base_datos, …

GESTIÓN DE LA SEGURIDAD DE BASE DE DATOS

1. IMPLEMENTACIÓN DEL MODO DE AUTENTICACIÓN

Se puede proteger SQL Server 2000 mediante la implementación del Modo de autenticación o del Modo mixto de Windows.

Proceso de autenticación

SQL Server puede delegar en Windows la autenticación de las cuentas de inicio de sesión o puede autenticar las cuentas

de inicio de sesión por sí mismo.


111


¿Cómo procesa SQL Server las cuentas de inicio de sesión que autentica Windows?

A continuación se describe cómo procesa SQL Server las cuentas de inicio de sesión que autentica Windows :

Cuando un usuario se conecta con SQL Server, el cliente abre una conexión de confianza con SQL Server, que pasa las credenciales de seguridad de Windows del usuario a SQL Server.

Como el cliente tiene abierta una conexión de confianza, SQL Server sabe que Windows ya ha validado la cuenta de inicio de sesión.

Si SQL Server encuentra la cuenta de usuario o de grupo de Windows del usuario en la lista de cuentas de inicio de sesión de SQL Server que se encuentra en la tabla del sistema sysxlogins, acepta la conexión.

SQL Server no necesita volver a validar la contraseña porque Windows 2000 ya la ha validado.

¿Cómo procesa SQL Server las cuentas de inicio de sesión que él mismo autentica?

SQL Server emplea los siguientes pasos para procesar las cuentas de inicio de sesión que él mismo autentica:

Cuando un usuario conecta con una cuenta de inicio de sesión y contraseña de SQL Server, éste comprueba si existe la cuenta de inicio de sesión en la tabla sysxlogins y si la contraseña especificada coincide con la contraseña registrada.

Si SQL Server no tiene configurada una cuenta de inicio de sesión para el usuario, la autenticación falla y la conexión se rechaza.

Elección del modo de seguridad o autenticación de SQL Server

SQL Server proporciona dos modos de seguridad distintos:

a) El Modo Integrado de Windows

b) El Modo Mixto (Autenticación integrada de Windows como autenticación de SQL Server)

Los modos de seguridad determina si sólo Windows, o tanto Windows como SQL Server son responsables de validar

solicitudes de conexión de SQL Server

Modo de Autenticación SQL Server Es el modo en el cual acepta un ID de inicio de sesión y una contraseña de un usuario, y verifica la validación sin ayuda de Windows. Si se conecta por medio del inicio de sesión, entonces está utilizando el Modo de autenticación SQL Server. Por lo tanto la tabla de sistema sysxlogins contiene una entrada para el ID de inicio de sesión sa, junto con una contraseña

Contraseña: Las contraseñas de inicio de sesión en Modo autenticación de SQL Server se mantienen en la columna password de la tabla en la base de datos master Use Master


112


go SELECT name, password FROM sysxlogins Go

BUILTIN\ Administradores: Representa el grupo local de administradores de Windows sa: Se agrega de manera predeterminada en el momento de la instalación, para este caso la contraseña es nula (NULL) carla: tiene una contraseña representada por el texto cifrado

Ventajas del Modo de autenticación de Windows Utilice el modo de Autenticación de Windows en entornos de red en los que todos los clientes admiten conexiones de

confianza.

La autenticación de Windows ofrece varias ventajas frente a la autenticación de SQL Server, ya que:

Proporciona más características, como la validación y el cifrado seguros de contraseñas, la auditoria, la caducidad de las contraseñas, la longitud mínima de la contraseña y el bloqueo de las cuentas después de contraseñas no válidas.

Permite agregar grupos de usuarios a SQL Server con sólo agregar una única cuenta de inicio de sesión.

Permite que los usuarios tengan acceso a SQL Server rápidamente, sin necesidad de recordar otra cuenta de inicio de sesión y contraseña.

Ventajas del Modo mixto

Un usuario puede conectarse a SQL Server utilizando ya sea el Modo integrado de Windows, o el Modo de autenticación de SQL Server

Es la mejor selección para obtener compatibilidad con versiones anteriores de SQL Server.

Proporciona mayor conectividad con clientes que no utilicen Windows que estén conectados en red, como los usuarios Novell Netware

Cifrado

El cifrado es un método de protección de la información confidencial que se crea pasando los datos a un formato ilegible.

Garantiza la seguridad de los datos, incluso si se ven directamente.

Cifrado interno SQL Server puede cifrar:

Las contraseñas de inicio de sesión almacenadas en SQL Server.

Cifrado de red

SQL Server permite que se cifren los datos que se envían entre el cliente y el servidor. Esto garantiza que cualquier

aplicación o usuario que intercepte los paquetes de datos de la red no pueda ver los datos confidenciales, por ejemplo,

contraseñas enviadas a través de la red cuando los usuarios inician sesión en SQL Server, o datos personales que

contienen información acerca de los salarios.

Pasos para implementar un modo de autenticación


113


Creación de cuentas de inicio de sesión

Puede crear cuentas de inicio de sesión a partir de usuarios y grupos de Windows existentes, o puede crear nuevas

cuentas de inicio de sesión en SQL Server. También puede utilizar una de las cuentas de inicio de sesión

predeterminadas. Las cuentas de inicio de sesión están almacenadas en la tabla del sistema master.sysxlogins.

Cuentas de inicio de sesión predeterminadas SQL Server tiene dos cuentas de inicio de sesión predeterminadas:

BUILTIN\Administradores: Se proporciona como cuenta de inicio de sesión predeterminada para todos los administradores de Windows. Tiene todos los derechos sobre SQL Server y todas las bases de datos.

El administrador del sistema (sa): Es una cuenta de inicio de sesión especial que tiene todos los derechos sobre SQL Server y todas las bases de datos.

Configurar el modo de seguridad Para establecer qué modo de seguridad está utilizando su servidor, inicie el Administrador Corporativo ya haga clic con el botón derecho del Mouse en su servidor, el cual se encuentra en el panel izquierdo. Seleccione la opción Propiedades del menú contextual y haga clic en la ficha de seguridad

Agregar una cuenta de inicio de sesión de Windows XP a SQL Server

Puede utilizar el Administrador corporativo de SQL Server o el procedimiento almacenado del sistema sp_grantlogin para

permitir que una cuenta de usuario o de grupo de Windows se conecte con SQL Server. Sólo los administradores del

sistema o de seguridad pueden ejecutar sp_grantlogin.


114


El nombre especificado al crear una cuenta es el nombre del usuario o grupo de Windows que se va a agregar.

a) Configuración de grupos y usuarios de Windows XP

b) Otorgar permiso a las cuentas de Windows XP para iniciar sesión en SQL Server

Después de establecer los usuarios y grupos, se otorga a esos grupos el acceso a SQL Server. Hay dos formas

utilizando procedimientos almacenados y mediante el administrador corporativo

Utilizando procedimientos almacenados de sistema

sp_grantlogin „inicio_sesión‟ Otorga el derecho de iniciar sesión en SQL Server al grupo o usuarios

de de Windows

sp_revokelogin „inicio_sesión‟ Permite quitar el derecho de inicio de sesión en SQL Server a un

usuario o grupo de usuarios

Sp_denylogin „inicio_sesión‟ Niega el derecho de iniciar sesión en SQL Server a un usuario o grupo

de usuarios

Agregar una cuenta de inicio de sesión de SQL Server Puede utilizar el Administrador corporativo de SQL Server o el procedimiento almacenado del sistema sp_addlogin para

crear una cuenta de inicio de sesión de SQL Server. Sólo los administradores del sistema o de seguridad pueden ejecutar

sp_addlogin.

Al crear una nueva cuenta de inicio de sesión de SQL Server se agrega un registro a la tabla sysxlogins de la base de

datos master.

sp_addlogin „sunombre‟, „su_contraseña‟ Otorga el derecho de iniciar sesión en SQL Server

sp_password „anterior‟, „nueva‟, „ini_sesión‟ Cambia la contraseña de inicio sesión en SQL

Server

Los administradores del sistema pueden cambiar la contraseña de cualquier usuario mediante sp_password con NULL

como contraseña antigua. Los usuarios y administradores del sistema también pueden cambiar las contraseñas con

Propiedades de inicio de sesión.

SQL Server tiene dos tipos de inicio de sesión:

Inicios de sesión de Windows, ya sea por medio de ID‟s de usuarios individuales o grupos

Inicio de sesión de SQL Server, los cuales se guardarán en la tablas sysxlogins que se encuentra en la base de datos Master

2. ASIGNACIÓN DE CUENTAS DE INICIO DE SESIÓN A USUARIOS Y FUNCIONES

Después de agregar cuentas de inicio de sesión a SQL Server puede asignarlas a cuentas de usuarios o funciones de cada una

de las bases de datos a las que los usuarios tengan acceso


115


Después de agregar cuentas de inicio de sesión a SQL Server, puede asignarlas a cuentas de usuario o funciones en cada una

de las bases de datos a las que los usuarios tengan acceso.

La tabla del sistema sysusers de una base de datos contiene una fila por cada usuario de Windows, grupo de Windows,

usuario de SQL Server o función de la base de datos. Los permisos se aplican a las entradas de la tabla sysusers y se

almacenan en la tabla sysprotects de la base de datos actual.

2.1 ASIGNACIÓN DE CUENTAS DE INICIO DE SESIÓN A CUENTAS DE USUARIOS DE BASES DE DATOS

Una vez configurada la seguridad de inicio de sesión y establecidos los inicios de sesión, puede empezar a configurar el

acceso a las bases de datos. Tener un inicio de sesión en SQL Server no le proporciona acceso a ninguna base de datos

al servidor. Para ello debe tener un nombre de usuario de base de datos.

Para tener acceso a una base de datos, una cuenta de inicio de sesión puede ser utilizada a una cuenta de usuario

asignada o una predeterminada.

a) Agregar cuentas de usuario a una base de datos

Para agregar una cuenta de usuario a una base de datos, puede utilizar el Administrador corporativo de SQL Server o

ejecutar el procedimiento almacenado del sistema sp_grantdbaccess. También puede agregar cuentas de usuario a

bases de datos al crear cuentas de inicio de sesión. Sólo los propietarios de la base de datos o los administradores

del acceso a la base de datos pueden ejecutar el procedimiento sp_grantdbaccess.

En el árbol de consola del Administrador corporativo de SQL Server, cada base de datos tiene una carpeta Users.

Aquí se muestra la lista de usuarios actual de la base de datos y se le permite agregar y quitar usuarios y

personalizar sus propiedades.

En la tabla siguiente se enumeran otros procedimientos almacenados del sistema que se pueden utilizar para

administrar el acceso a la base de datos.

Procedimiento almacenado de sistema Descripción

sp_grantdbaccess „inicio_de_sesión‟ Otorga una cuenta de seguridad a la base de datos actual.

Sp_revokedbaccess „inicio_de_sesión‟ Quita una cuenta de seguridad de la base de datos actual.

sp_helpuser Visualiza la información de todos los usuarios que tienen acceso

a la Base de Datos

sp_helpuser [nombre_usuario] Obtiene un informe para un informe para un usuario específico

b) Cuenta de usuario dbo

Al crear una base de datos, ya se tiene un usuario. Uno de estos se llama dbo (propietario de la base de datos). El

usuario dbo asigna de manera predeterminada al inicio de sesión sa. Al instalar SQL Server, el inicio de sesión sa


116


considera como el propietario de todas las bases de datos. Si otro inicio de sesión crea una base de datos, ese inicio

de sesión es el propietario de base de datos

Cualquier objeto que cree un administrador del sistema pertenece automáticamente a dbo. El usuario dbo es una

cuenta predeterminada y no se puede eliminar.

c) Cuenta de usuario guest

La cuenta de usuario guest permite inicios de sesión sin cuentas de usuario para tener acceso a una base de datos.

Las cuentas de inicio de sesión asumen la identidad del usuario guest cuando se cumplen las dos condiciones

siguientes:

Se pueden aplicar permisos al usuario guest como si se tratara de cualquier otra cuenta de usuario. Puede eliminar y

agregar el usuario guest a cualquier base de datos excepto a las bases de datos master y tempdb.

Nota: Al iniciar una sesión puede acceder a todas las bases de datos del sistema, así como a las bases de datos

Pubs y Northwind, esto es gracias al nombre de usuario guest

2.2 ASIGNACIÓN DE CUENTAS DE INICIO DE SESIÓN A FUNCIONES

Las funciones proporcionan un medio para agrupar usuarios en una sola unidad a la que se pueden aplicar permisos.

SQL Server proporciona funciones de servidor y de base de datos predefinidas para las funciones administrativas

comunes, de forma que pueda conceder fácilmente una selección de permisos administrativos a un usuario específico.

a) Funciones fijas de servidor Las funciones fijas del servidor permiten agrupar los privilegios administrativos en el nivel del servidor. Se administran

de forma independiente de las bases de datos de usuario en el nivel del servidor y se almacenan en la tabla del

sistema master.sysxlogins.

b) Funciones fijas de base de datos Las funciones fijas de base de datos permiten agrupar los privilegios administrativos en el nivel de base de datos. Las

funciones fijas de base de datos están almacenadas en la tabla del sistema sysusers de cada base de datos.


117


La función public

La función public es una función de base de datos especial a la que pertenecen todos los usuarios de la base de

datos y que no se puede quitar. La función public:

Mantiene todos los permisos predeterminados de los usuarios de una base de datos.

No puede tener usuarios, grupos o funciones asignados, ya que los usuarios, grupos y funciones ya pertenecen a ella de forma predeterminada.

Se encuentra en todas las bases de datos, incluidas las bases de datos master, msdb, tempdb, model y todas las bases de datos de usuario.

No se puede eliminar.

Asignación de una cuenta de seguridad a una función fija de base de datos Para agregar una cuenta de seguridad como miembro de una función fija de base de datos, utilice el Administrador

corporativo de SQL Server o el procedimiento almacenado del sistema sp_addrolemember. Sólo los miembros de la

función db_owner pueden ejecutar el procedimiento almacenado del sistema sp_addrolemember para cualquier

función de la base de datos.

Al asignar cuentas de seguridad a una función fija de base de datos, tenga en cuenta los siguientes hechos:

Las funciones fijas de base de datos no se pueden agregar, modificar ni quitar.

Cualquier miembro de una función fija de base de datos puede agregar otras cuentas de inicio de sesión a esa función.

También puede utilizar el procedimiento almacenado del sistema sp_droprolemember para eliminar una cuenta de

seguridad de una función.

c) Funciones de base de datos definidas por el usuario La creación de una función de base de datos definida por el usuario permite crear un grupo de usuarios con un

conjunto de permisos comunes. Debe agregar una función definida por el usuario a la base de datos en los casos

siguientes:

Cuando un grupo de personas necesite realizar un conjunto de actividades especificado en SQL Server y no exista un grupo de Windows 2000 aplicable.

Si no tiene permisos para administrar las cuentas de usuario de Windows 2000.

Creación de una función de base de datos definida por el usuario

Para crear una nueva función de base de datos, utilice el Administrador corporativo de SQL Server o el procedimiento

almacenado del sistema sp_addrole. Por cada función definida por el usuario se agrega una entrada a la tabla

sysusers de la base de datos actual. Sólo los miembros de la función db_securityadmin o db_owner pueden

ejecutar sp_addrole.


118


Al crear una función de base de datos, tenga en cuenta lo siguiente:

Cuando aplique permisos a la función, todos los miembros de la función obtendrán el efecto del permiso, igual que si el permiso se hubiera aplicado directamente a las propias cuentas de los miembros.

Asignación de una cuenta de seguridad a una función de base de datos definida por el usuario Después de crear una función, utilice el Administrador corporativo de SQL Server o el procedimiento almacenado del

sistema sp_addrolemember para agregar usuarios o funciones como miembros de la función. Sólo los miembros de

la función fija del servidor sysadmin o de las funciones fijas de base de datos db_securityadmin y db_owner, o el

propietario de la función pueden ejecutar sp_addrolemember para agregar un miembro a una función de base de

datos definida por el usuario.

En la tabla siguiente se enumeran procedimientos almacenados del sistema adicionales que se pueden utilizar para

administrar funciones de base de datos.

Procedimiento almacenado de sistema Descripción

sp_addrole „función‟ Agrega una función de SQL Server de la base de datos

actual.

sp_droprole „función‟ Quita una función de SQL Server de la base de datos actual.

sp_addrolemember „función‟, „usuario‟ Agrega un miembro a una función de base de datos definida

por el usuario

sp_droprolemember „función‟, „usuario‟ Quita un miembro a una función de base de datos definida

por el usuario

3. ASIGNACIÓN DE PERMISOS A USUARIOS Y FUNCIONES

Después de haber asignado cuentas de inicio de sesión a cuentas de usuario y funciones, debe asignar permisos para exigir la

seguridad de la base de datos.

Los permisos especifican para qué objetos de la base de datos tienen autorización los usuarios y qué pueden hacer los usuarios

con esos objetos. Los permisos que un usuario tiene en una base de datos dependen de los permisos de la cuenta de usuario y

de las funciones a las que pertenezca el usuario. Es importante diseñar los permisos que vaya a conceder a cada usuario o

cada grupo. Todas las bases de datos tienen su propio sistema de permisos independiente.

Tipos de permisos

a) Permisos de instrucción

Las actividades relativas a la creación de bases de datos o de elementos en una base de datos requieren una

clase de permisos llamada permisos de instrucción. Los permisos de instrucción ofrecen a los usuarios el privilegio

de emitir ciertas instrucciones Transact-SQL. Los permisos de instrucción, como CREATE DATABASE, se aplican


119


a la misma instrucción, no al elemento específico que se define en la base de datos. Sólo los miembros de la

función sysadmin, db_owner o db_securityadmin pueden conceder permisos de instrucción.

b) Permisos de objeto

Las actividades relacionadas con los datos o la ejecución de procedimientos requieren una clase de permisos

conocida como permisos de objeto.

c) Permisos predefinidos

Sólo los miembros de funciones fijas o los propietarios de los objetos de base de datos pueden desempeñar

ciertas actividades. Los permisos que ejecutan dichas actividades se conocen como permisos predefinidos o

implícitos.

Concesión, denegación y revocación

Los permisos de un usuario o una función pueden estar en uno de tres estados: concedido, denegado o revocado. Los

permisos que no se han concedido ni denegado a un usuario son neutros, como si se hubieran revocado. Los permisos

se almacenan como entradas de la tabla del sistema sysprotects en cada base de datos.

En la tabla siguiente se describen los tres estados de un permiso.

Instrucción Estado de la entrada en la tabla

sysprotects

Descripción

GRANT Positivo Puede ejecutar una acción.

DENY Negativo No puede ejecutar una acción y no

puede ser sobrescrito por la

pertenencia a una función.

REVOKE Ninguno No puede ejecutar una acción, pero

puede ser sobrescrito por la

pertenencia a una función.

Los permisos concedidos son acumulativos; los usuarios pueden ejecutar todas las acciones para las que se les haya

concedido permiso individualmente y todas las acciones para las que se haya concedido permiso a las funciones a las

que pertenezcan.

La instrucción DENY impide que los usuarios realicen acciones. Sobrescribe un permiso de una función a la que el

usuario pertenece, tanto si se ha concedido el permiso al usuario directa como indirectamente.

Los usuarios tienen permiso para ejecutar una acción si se dan las dos condiciones siguientes:


120


Se les ha concedido el permiso directamente o pertenecen a una función a la que se ha concedido el permiso.

El permiso no se ha denegado directamente al usuario o a una de las funciones a las que el usuario pertenece.

Concesión de permisos para permitir el acceso

Puede conceder permisos a cuentas de seguridad y permitir que las cuentas realicen actividades o trabajen con los

datos de una base de datos.

Al conceder permisos, tenga en cuenta los siguientes hechos:

Sólo puede conceder permisos en la base de datos actual.

El derecho para conceder permisos corresponde de forma predeterminada a los miembros de las funciones sysadmin, db_owner y db_securityadmin, y a los propietarios de objetos.

Puede conceder permisos con el Administrador corporativo de SQL Server o con la instrucción GRANT.

Los permisos disponibles varían en función de los objetos seleccionados. Por ejemplo, un procedimiento almacenado

tiene permisos EXECUTE; una tabla o una vista tienen los permisos SELECT, INSERT, UPDATE, DELETE y permisos

de integridad referencial; y las columnas individuales de una tabla o vista tienen los permisos SELECT y UPDATE.

Denegación de permisos para impedir el acceso

Puede que, ocasionalmente, desee limitar los permisos de un usuario o una función; para ello, puede denegar los

permisos a esa cuenta de seguridad. La denegación de permisos de una cuenta de seguridad:

Quita los permisos previamente concedidos al usuario o función.

Desactiva los permisos heredados de otra función.

Asegura que el usuario o función no herede permisos de otra función en el futuro.

Al denegar permisos, tenga en cuenta los siguientes hechos:

Sólo puede denegar permisos en la base de datos actual.

El permiso para denegar permisos corresponde de forma predeterminada a los miembros de las funciones sysadmin, db_owner y db_securityadmin, y a los propietarios de los objetos.

Para denegar permisos, puede utilizar el Administrador corporativo de SQL Server o la instrucción DENY.

Revocación de permisos


121


Para desactivar un permiso concedido o denegado, puede revocarlo. La revocación de permisos es similar a la

denegación de permisos en que ambas acciones quitan un permiso concedido. La diferencia estriba en que mientras la

revocación de un permiso quita un permiso concedido, no impide que el usuario o la función hereden ese permiso en el

futuro.

Para quitar un permiso previamente concedido o denegado, puede utilizar el Administrador corporativo de SQL Server

o la instrucción REVOKE.


122


PROGRAMACIÓN EN SQL 1. Introducción a los procedimientos almacenados Definición de procedimientos almacenados

Un procedimiento almacenado son instrucciones precompiladas de Transact-SQL que se almacena en la base de datos del servidor. Debido a que los procedimientos almacenados son precompilados, por lo general ofrecen mejor desempeño que cualquier consulta. Los procedimientos almacenados en SQL Server son similares a los procedimientos de otros lenguajes de programación ya que pueden:

Contener instrucciones que realizan operaciones en la base de datos; incluso tienen la capacidad de llamar a otros procedimientos almacenados.

Aceptar parámetros de entrada.

Devolver un valor de estado a un procedimiento almacenado que realiza la llamada para indicar que se ha ejecutado correctamente o que se ha producido algún error

Devolver varios valores al procedimiento almacenado o al proceso por lotes que realiza la llamada en forma de parámetros de salida.

Procesamiento y ejecución de los procedimientos almacenados El procesamiento de un procedimiento almacenado conlleva crearlo y ejecutarlo la primera vez, lo que coloca su plan de consultas en la caché de procedimientos. La caché de procedimientos es un bloque de memoria que contiene los planes de ejecución de todas las instrucciones de Transact-SQL que se están ejecutando actualmente. El tamaño de la caché de procedimientos fluctúa dinámicamente de acuerdo con los grados de actividad. La caché de procedimientos se encuentra en el bloque de memoria que es la unidad principal de memoria de SQL Server. Contiene la mayor parte de las estructuras de datos que usan memoria en SQL Server.

Creación Cuando se crea un procedimiento almacenado, las instrucciones que hay en él se analizan para ver si son correctas desde el punto de vista sintáctico. A continuación, SQL Server almacena el nombre del procedimiento almacenado en la tabla del sistema sysobjects y su texto en la tabla del sistema syscomments en la base de datos activa. Si se detecta un error de sintaxis, se devuelve un error y no se crea el procedimiento almacenado. Ejecución (por primera vez o recompilación) La primera vez que se ejecuta un procedimiento almacenado o si el procedimiento almacenado se debe volver a compilar, el procesador de consultas lo lee en un proceso llamado resolución. Ciertos cambios en una base de datos pueden hacer que un plan de ejecución sea ineficaz o deje de ser válido. SQL Server detecta estos cambios y vuelve a compilarlo automáticamente cuando se produce alguna de las situaciones siguientes:

Se realiza algún cambio estructural en una tabla o vista a la que hace referencia la consulta (ALTER TABLE y ALTER VIEW).

Se quita un índice usado por el plan de ejecución.

Se realizan cambios importantes en las claves (la instrucción INSERT o DELETE) de una tabla a la que hace referencia una consulta.

Optimización Cuando un procedimiento almacenado pasa correctamente la etapa de resolución, el optimizador de consultas de SQL Server analiza las instrucciones de Transact-SQL del procedimiento almacenado y crea un plan que contiene el método más rápido para obtener acceso a los datos. Para ello, el optimizador de consultas tiene en cuenta lo siguiente:

La cantidad de datos de las tablas.

La presencia y naturaleza de los índices de las tablas, y la distribución de los datos en las columnas indizadas.

Los operadores de comparación y los valores de comparación que se usan en las condiciones de la cláusula WHERE.

La presencia de combinaciones y las cláusulas UNION, GROUP BY u ORDER BY.


123


Compilación La compilación hace referencia al proceso consistente en analizar el procedimiento almacenado y crear un plan de ejecución que se encuentra en la caché de procedimientos. La caché de procedimientos contiene los planes de ejecución de los procedimientos almacenados más importantes. Entre los factores que aumentan el valor de un plan se incluyen los siguientes:

Tiempo requerido para volver a compilar (costo de compilación alto)

Frecuencia de uso Ventajas de los procedimientos almacenados

Los procedimientos almacenados ofrecen varias ventajas. Pueden:

Compartir la lógica de la aplicación con las restantes aplicaciones, lo que asegura que el acceso y la modificación de los datos se hace de una forma coherente. Los procedimientos almacenados pueden encapsular la funcionalidad del negocio. Las reglas o directivas empresariales encapsuladas en los procedimientos almacenados se pueden cambiar en una sola ubicación. Todos los clientes pueden usar los mismos procedimientos almacenados para asegurar que el acceso y modificación de los datos es coherente.

Apartar a los usuarios de la exposición de los detalles de las tablas de la base de datos. Si un conjunto de procedimientos almacenados permite llevar a cabo todas las funciones de negocio que los usuarios necesitan, los usuarios no tienen que tener acceso a las tablas directamente.

Proporcionar mecanismos de seguridad. Los usuarios pueden obtener permiso para ejecutar un procedimiento almacenado incluso si no tienen permiso de acceso a las tablas o vistas a las que hace referencia.

Mejorar el rendimiento. Los procedimientos almacenados implementan muchas tareas como una serie de instrucciones de Transact-SQL. Se puede aplicar lógica condicional a los resultados de las primeras instrucciones de Transact-SQL para determinar cuáles son las siguientes que deben ejecutarse. Todas estas instrucciones de Transact-SQL y la lógica condicional pasa a ser parte de un único plan de ejecución del servidor.

Reducir el tráfico de red. En lugar de enviar cientos de instrucciones de Transact-SQL por la red, los usuarios pueden realizar una operación compleja mediante el envío de una única instrucción, lo que reduce el número de solicitudes que se pasan entre el cliente y el servidor.

Recomendaciones para la creación de procedimientos almacenados

Evitar situaciones en las que el dueño de un procedimiento almacenado y el dueño de las tablas referenciadas sean distintos, se recomienda que los usuarios estén mapeados como dbo, para todos los objetos de una base de datos Debe tener permisos apropiados en todas las tablas o vistas que son referenciadas Evite situaciones en las que el dueño de un procedimiento almacenado y el dueño de las tablas referenciadas

sean distintos

Diseñe el procedimiento almacenado de manera tal que ejecute una sola tarea

Cree, pruebe, y ponga a punto a su procedimiento almacenado en el servidor; luego pruébelo en el cliente

Para distinguir fácilmente a un procedimiento almacenado del sistema de un procedimiento creado por el usuario , evite el uso del prefijo sp_ al nombrar el procedimiento

Si no desea que los usuarios puedan ver el texto de sus procedimientos almacenados, debe crearlos con la opción WITH ENCRYPTION. Si no usa WITH ENCRYPTION, los usuarios pueden usar el procedimiento almacenado del sistema sp_helptext para ver el texto de procedimientos almacenados en la tabla de sistema syscomments

2. Creación, ejecución, definición, modificación y eliminación de procedimientos almacenados Creación y ejecución de procedimientos almacenados

Debe crear el procedimiento almacenado en la base de datos actual. La creación de un procedimiento almacenado es similar a la creación de una vista. Primero, escriba y pruebe las sentencias Transact-SQL que desea incluir en el procedimiento almacenado. A continuación, si recibe los resultados esperados, cree el procedimiento almacenado

Uso de CREATE PROCEDURE Los procedimientos almacenados se crean con la instrucción CREATE PROCEDURE. Considere los hechos siguientes cuando cree procedimientos almacenados:

Los procedimientos almacenados pueden hacer referencia a tablas, vistas, funciones definidas por el usuario y otros procedimientos almacenados, así como a tablas temporales.

Si un procedimiento almacenado crea una tabla local temporal, la tabla temporal sólo existe para atender al procedimiento almacenado y desaparece cuando finaliza la ejecución del mismo.

Una instrucción CREATE PROCEDURE no se puede combinar con otras instrucciones de Transact-SQL en un solo proceso por lotes.

La definición de CREATE PROCEDURE puede incluir cualquier número y tipo de instrucciones de Transact-SQL, con la excepción de las siguientes instrucciones de creación de objetos: CREATE DEFAULT, CREATE PROCEDURE, CREATE RULE, CREATE TRIGGER y CREATE VIEW. En un procedimiento almacenado se pueden crear otros objetos de la base de datos y deben calificarse con el nombre del propietario del objeto.

Para ejecutar la instrucción CREATE PROCEDURE, debe ser miembro de la función de administradores del sistema (sysadmin), de la función de propietario de la base de datos (db_owner) o de la función de administrador del lenguaje de definición de datos (db_ddladmin), o debe haber recibido el permiso CREATE PROCEDURE.

El tamaño máximo de un procedimiento almacenado es 128 megabytes (MB), según la memoria disponible


124


Procedimiento que no recibe ni devuelve parámetros Sintaxis:

CREATE PROCEDURE nombre_procedimiento [WITH ENCRYPTION] AS sentenciasSQL

Ejemplo: Crear un procedimiento almacenado que genere la lista de precios de los Productos de Minimarket

USE Minimarket go CREATE PROCEDURE usp_ListaPrecios AS SELECT c.Categoria,p.IdProducto, p.Nombre, p.UnidadMedida FROM PRODUCTO as p INNER JOIN CATEGORIA as c ON p.IdCategoria=c.IdCategoria ORDER BY 1,3 go

Para ejecutar el procedimiento:

EXEC usp_ListaPrecios go

Ejemplo: Crear un procedimiento almacenado que genere la lista de precios de los Productos de que registran salida del almacén, los campos a mostrar de la lista deben ser el código del producto, y el nombre del producto. El usuario no debe ver el texto del procedimiento

Use Minimarket go CREATE PROCEDURE usp_ListaProductosSalidaAlmacen WITH ENCRYPTION AS SELECT DISTINCT Guia_detalle.idproducto, nombre FROM Guia_detalle INNER JOIN Producto ON Guia_detalle.idProducto=Producto.IdProducto ORDER BY Guia_detalle.idproducto go

Para ejecutar el procedimiento:

EXEC usp_ListaProductosSalidaAlmacen go

Procedimientos que reciben parámetros Sintaxis:

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor], @parámetro2 tipo_dato [ = valor], …

AS sentenciasSQL

Ejemplo: Crear un procedimiento que entregue la lista de productos del proveedor X, respecto a una determinada categoría de producto Y, donde x es el código del proveedor e y es el código de la categoría del producto

USE Minimarket go CREATE PROCEDURE usp_ListaProveedorCategoria @proveedor int, @categoria int AS SELECT idProducto, nombre FROM PRODUCTO WHERE idProveedor=@proveedor AND idCategoria=@categoria go --Para ejecutar el procedimiento


125


DECLARE @codProv int, @codCat int SET @codProv =14 SET @codCat=1 EXEC usp_ListaProveedorCategoria @codProv,@codCat go

--Otra forma de ejecutar el procedimiento EXEC usp_ListaProveedorCategoria 14,1 go --También tenemos EXEC usp_ListaProveedorCategoria @categoria=1, @proveedor=14 go

Ejemplo: Crear un procedimiento que muestre el código de la Guía de remisión, la dirección del local, la fecha de salida, el monto total de la guía de remisión X, donde x es el código de la guía de remisión

CREATE PROCEDURE usp_Guia_direccion_fecha @nguia int AS SELECT Guia.IdGuia, Local.Direccion, Local.Distrito, Guia.FechaSalida, sum(Guia_detalle.PrecioVenta* Guia_detalle.Cantidad) AS 'Monto Total' FROM Guia INNER JOIN Guia_detalle ON Guia.IdGuia = Guia_detalle.IdGuia INNER JOIN Local ON Guia.IdLocal=Local.IdLocal GROUP BY Guia.IdGuia, Local.Direccion,Local.Distrito, Guia.FechaSalida HAVING Guia.IdGuia=@nguia --Para ejecutar el procedimiento DECLARE @n_guia int SET @n_guia=4 EXEC usp_Guia_direccion_fecha @n_guia go --Otra forma de ejecutar el procedimiento EXEC usp_Guia_direccion_fecha 4 go --También tenemos EXEC usp_Guia_direccion_fecha @nguia=4 Go

Procedimientos que recibe y entrega parámetros Sintaxis:

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor], @parámetro2 tipo_dato [ = valor], @parámetro3 tipo_dato [ = valor] OUTPUT, …

AS sentenciasSQL

Ejemplo: Crear un procedimiento que devuelva el monto mensual total de las guías de remisión correspondientes al año Y respecto al mes Z

USE Minimarket go CREATE PROCEDURE usp_MontoGuiasMes @año int, @mes int, @monto money OUTPUT AS SELECT @monto= ( SELECT sum(Guia_detalle.cantidad*Guia_detalle.precioVenta) FROM Guia_detalle INNER JOIN Guia ON Guia_detalle.idGuia=Guia.idGuia WHERE year(Guia.fechaSalida)=@año AND month(Guia.fechaSalida)=@mes) go


126


--Para ejecutar el procedimiento DECLARE @monto1 money EXEC usp_MontoGuiasMes 2006,03,@monto1 OUTPUT SELECT 'Monto Marzo 2005'=@monto1 go

Obtención de la definición de un procedimiento almacenado

Puede usar los procedimientos almacenados del sistema para obtener información sobre la definición de los procedimientos almacenados de la base de datos

Tabla del Sistema Almacena Procedimiento

sys.sysobjects Nombre del procedimiento almacenado sp_help nombre_procedimiento sp_stored_procedures

sys.sysdepends Nombre de los objetos dependientes al procedimiento almacenado

sp_depends nombre_procedimiento

sys.syscomments Sentencia que definió al procedimiento almacenado

sp_helptext nombre_procedimiento

Ejemplo: Obtener la información del procedimiento almacenado usp_MontoGuiasMes

Use Minimarket; EXEC sp_help usp_MontoGuiasMes;

Ejemplo: Obtener los nombres de los procedimientos almacenados de la base de datos Minimarket

Use Minimarket; EXEC sp_stored_procedures;

Ejemplo: Obtener los objetos dependientes del procedimientos almacenado usp_MontoGuiasMes de la base de datos Minimarket

Use Minimarket; EXEC sp_depends usp_MontoGuiasMes;

Ejemplo: Obtener la sentencia que definió el procedimiento almacenado usp_MontoGuiasMes de la base de datos Minimarket

Use Minimarket; EXEC sp_helptext usp_MontoGuiasMes;


127


Modificación y eliminación de procedimientos almacenados Modificación de un procedimiento almacenado Para modificar un procedimiento almacenado conservando su asignación de permisos, ejecute la sentencia ALTER PROCEDURE. La definición previa del procedimiento será reemplazada por la definición establecida en ALTER PROCEDURE

Sintaxis:

ALTER PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ =valor], @parámetro2 tipo_dato [ =valor],

@parámetro3 tipo_dato [ =valor] OUTPUT, … AS sentenciasSQL

Eliminación de un procedimiento almacenado (DROP PROCEDURE) Use la sentencia DROP PROCEDURE para eliminar los procedimientos almacenados definidos por el usuario de la base de datos actual Antes de eliminar un procedimiento almacenado, ejecute el procedimiento almacenado sp_depends para determinar los objetos que dependen del procedimiento almacenado

Sintaxis: DROP PROCEDURE nombreProcedimiento

DESENCADENADORES (TRIGGERS)

Definición de desencadenadores Funcionamiento de los desencadenadores Ejemplos de desencadenadores Consideraciones acerca del rendimiento 1. Introducción a los desencadenadores

Definición de desencadenadores Un desencadenador es una clase especial de procedimiento almacenado que se ejecuta siempre que se intenta modificar los datos de una tabla que el desencadenador protege. Los desencadenadores están asociados a tablas específicas. Asociación a una tabla Los desencadenadores se definen para una tabla específica, denominada tabla del desencadenador. Invocación automática Cuando se intenta insertar, actualizar o eliminar datos de una tabla en la que se ha definido un desencadenador para esa acción específica, el desencadenador se ejecuta automáticamente. No es posible evitar su ejecución. Imposibilidad de llamada directa A diferencia de los procedimientos almacenados del sistema normales, no es posible invocar directamente los desencadenadores, que tampoco pasan ni aceptan parámetros.

Uso de los desencadenadores

Consideraciones acerca de los desencadenadores Tipos de desencadenantes DML

a) Desencadenantes AFTER


128


Son disparados después que una acción INSERT, UPDATE ó DELETE es ejecutada. Este tipo de desencadenante sólo se puede especificar para tablas

b) Desencadenantes INSTEAD OF Son ejecutadas en lugar de la acción de disparo habitual. Este desencadenante se puede definir también sobre vistas que tienen una o más tablas subyacentes

Creación de desencadenadores DML Los desencadenantes son creados con la declaración CREATE TRIGGER. La declaración especifica la tabla en la que el desencadenante se define, los eventos que hacen que se ejecute, y las instrucciones particulares para el desencadenante Sintaxis:

CREATE TRIGGER nombre_desencadenante ON nombre_tabla | nombre_vista FOR [INSERT] [,] [UPDATE] [,][DELETE] | AFTER [INSERT] [,] [UPDATE] [,] [DELETE] | INSTEAD OF [INSERT] [,] [UPDATE] [,] [DELETE] AS sentenciasSQL

FOR y AFTER definen desencadenantes AFTER, FOR se conserva por compatibilidad con versiones anteriores de SQL Server

Los dueños de las tablas, así como los miembros de los roles db_owner y sysadmin, tienen permiso para crear un desencadenante

SQL Server no permite usar las declaraciones siguientes en una definición de desencadenante: - CREATE DATABASE, ALTER DATABASE y DROP DATABASE - LOAD DATABASE Y LOAD LOG - RESTORE DATABASE - RESTORE LOG - RECONFIGURE

Preparación de las tablas: Ejemplo: Crear una base de datos de Prueba que contendrá la tablas en la que diseñarán y probarán los desencadenantes

Luego actualice mediante las instrucciones transact SQL el monto de la tabla Factura Use Prueba go


129


UPDATE Factura SET MontoFactura = ( SELECT SUM (PrecioUnitario*Cantidad) FROM DetalleFactura WHERE DetalleFactura.IdFactura=Factura.IdFactura) Go

Al ejecutar tenemos:

Desencadenante AFTER INSERT Ejemplo: Crear un desencadenante AFTER INSERT que recalcule y actualice el monto de una factura cada vez que se inserta un detalle para dicha factura

Use Prueba go CREATE TRIGGER tg_insert_DetalleFactura ON DetalleFactura AFTER INSERT AS DECLARE @nfactura int DECLARE @nmonto money SET @nfactura=( SELECT IdFactura FROM inserted) SET @nmonto = ( SELECT sum(PrecioUnitario*Cantidad) FROM DetalleFactura WHERE DetalleFactura.IdFactura=@nfactura ) UPDATE Factura SET MontoFactura=@nmonto WHERE IdFactura=@nFactura go

Para probar el desencadenante codifique y ejecute los siguientes batch

-- Registrando la factura 3 SET DATEFORMAT dmy ; INSERT INTO Factura VALUES (3,‟06/07/2006‟, „C003‟, NULL) ; -- Insertando los valores para probar el desencadenante INSERT DetalleFactura VALUES (3, 1001, 12.5, 20); INSERT DetalleFactura VALUES (3, 1002, 20.5, 40); -- verificando la actualización del monto de la tabla factura SELECT * FROM factura;

Mecanismo de un desencadenante AFTER INSERT – La tabla INSERTED Cuando se ejecuta una declaración INSERT en una tabla que tiene definido un desencadenante AFTER INSERT, se crea automáticamente una tabla temporal INSERTED que tiene la misma estructura que la tabla con el desencadenante. La tabla temporal INSERTED contiene una copia de la fila insertada por la declaración INSERT ejecutada en la tabla con el desencadenante.

TABLA: INSERTED

Idfactura Improducto PrecioUnitario Cantidad

3 1001 12.5 20

Desencadenante AFTER DELETE


130


Crear un desencadenante AFTER DELETE que recalcule y actualice el monto de una factura cada vez que se elimina un detalle para dicha factura

Use Prueba go --Desencadenante por ELIMINACIÓN para Detallefactura --Recalcule el monto de la factura por cada detalle eliminado CREATE TRIGGER tg_delete_DetalleFactura ON DetalleFactura AFTER DELETE AS DECLARE @nfactura int DECLARE @nmonto money SET @nfactura=( SELECT IdFactura FROM deleted) SET @nmonto = ( SELECT sum(PrecioUnitario*Cantidad) FROM DetalleFactura WHERE DetalleFactura.IdFactura=@nfactura ) UPDATE Factura SET MontoFactura=@nmonto WHERE IdFactura=@nFactura go -- Prueba del desencadenante mediante la eliminación -- del primer detalle de la factura 1 DELETE FROM DetalleFactura WHERE IdFactura=1 AND IdProducto=1001; -- Verificando la data SELECT * FROM DetalleFactura; SELECT * FROM Factura;

Mecanismo de un desencadenante AFTER DELETE – La tabla DELETED Cuando se ejecuta una declaración DELETE en una tabla que tiene definido un desencadenante AFTER DELETE, se crea automáticamente una tabla temporal DELETED que tiene la misma estructura que la tabla con el desencadenante. La tabla temporal DELETED contiene a las filas que la declaración DELETE ejecutada en la tabla con el desencadenante ha eliminado.

TABLA: DELETED

Idfactura Improducto PrecioUnitario Cantidad

3 1001 12.5 20

Desencadenante AFTER UPDATE Crear un desencadenante AFTER UPDATE que recalcule el monto de una factura cada vez que se actualiza la cantidad o él precio de un detalle de dicha factura

Use Prueba go


131


--Desencadenante por ACTUALIZACIÓN para Detallefactura --Recalcule el monto de la factura por cada detalle actualizado respecto al --- --precio y a la cantidad CREATE TRIGGER tg_update_DetalleFactura ON DetalleFactura AFTER UPDATE AS IF UPDATE (PrecioUnitario) OR UPDATE(cantidad) BEGIN DECLARE @nfactura int DECLARE @nmonto money SET @nfactura=( SELECT IdFactura FROM inserted) SET @nmonto = ( SELECT sum(PrecioUnitario*Cantidad) FROM DetalleFactura WHERE DetalleFactura.IdFactura=@nfactura ) UPDATE Factura SET MontoFactura=@nmonto WHERE IdFactura=@nFactura END go --Probando el desencadenante triplicando la cantidad para --el segundo producto (1008) del detalle de la factura Nº2 UPDATE Detallefactura SET cantidad=cantidad*3 WHERE IdFactura =2 AND IdProducto=1008 go --Verificando la data SELECT * FROM DetalleFactura; SELECT * FROM Factura;

Mecanismo de un desencadenante AFTER UPDATE Cuando se ejecuta una declaración UPDATE en una tabla que tiene definido un desencadenante AFTER UPDATE, se crea automáticamente las tabla temporales INSERTED y DELETED que tiene la misma estructura que la tabla con el desencadenante. La tabla temporal DELETED contiene a las filas afectadas por la declaración UPDATE, pero con los valores anteriores a la ejecución de UPDATE. La tabla temporal INSERTED contiene las filas afectadas pero con los valores actualizados.


132


BIBLIOGRAFÍA

Date C.J. Introducción a los Sistemas de Base de Datos, Edición Pearson Education 7 .

Ed. México 2001

JHONSON, JAMES L. , Base de Datos. Ediciones Oxford University Press- Mexico 2000

LUQUE IRENE/ GOMEZ NIETO ÁNGEL / LOPEZ ENRIQUE / CERRUELA GONZALO,

Base de Datos desde Chen hasta Codd con Oracle. Edición AlfaOmega - España 2002

DE MIGUEL ADORACION /PIATTINI MARIO/ ESPERANZA MARCOS. Diseño de base

de datos relacional edición alfaomega España 2000.

RECURSOS DE INTERNET:

http://www.monografias.com

http://www.solocursos.net

http://www.programacion.com

http://www.monografias.com/

http://www.solocursos.net/

http://www.programacion.com/

Documents

MANUALGESTION INFORMATICA II.pdf