Bases de Datos by Olga Patricia Vásquez

Vicerrectoría Académica Proyecto P.A.V. Plataforma de Aprendizaje Virtual

MÓDULO VIRTUAL BASES DE DATOS

ORALIA CORTÉS GRAJALES

VICERRECTORÍA ACADÉMICA PROYECTO P.A.V. PLATAFORMA DE APRENDIZAJE VIRTUAL

TECNOLÓGICO DE ANTIOQUIA INSTITUCIÓN UNIVERSITARIA MEDELLÍN 2008

Realización

Vicerrector Académico John Harvey Garavito Londoño Docente (Autor) Oralia Cortés Grajales Equipo Técnico P.A.V. Nubia Amparo Giraldo García Jhonatan Arroyave Jaramillo Giselle Andrea Tamayo Mármol

Tecnológico de Antioquia Institución Universitaria Plataforma de Aprendizaje Virtual Proyecto P.A.V. 2008

Unidad 1

Introducci贸n a los Sistemas de Bases de Datos En esta unidad se da a conocer globalmente los conceptos de lo que es un sistemas de de bases de datos, ya que estas proporcionan la infraestructura requerida para los sistemas de apoyo a la toma de decisiones y para los sistemas de informaci贸n estrat茅gicos, es muy importante tener claros los conceptos generales de bases de datos antes de empezar a estudiar las diferentes etapas que permiten desarrollar una base de datos.

1. Historia 1.1. Historia El término base de datos fue acuñado por primera vez en 1963, en un simposio celebrado en California. De forma sencilla podemos indicar que una base de datos no es más que un conjunto de información relacionada que se encuentra agrupada o estructurada. El archivo por sí mismo, no constituye una base de datos, sino más bien la forma en que está organizada la información es la que da origen a la base de datos. Las bases de datos manuales, pueden ser difíciles de gestionar y modificar. Por ejemplo, en una guía de teléfonos no es posible encontrar el número de un individuo si no sabemos su apellido, aunque conozcamos su domicilio. Del mismo modo, en un archivo de pacientes en el que la información esté desordenada por el nombre de los mismos, será una tarea bastante engorrosa encontrar todos los pacientes que viven en una zona determinada. Los problemas expuestos anteriormente se pueden resolver creando una base de datos informatizada. Desde el punto de vista informático, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista más formal, podríamos definir una base de datos como un conjunto de datos estructurados, fiables y homogéneos, organizados independientemente en máquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de información diferente y no predecible en el tiempo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Conceptos Básicos de bases de datos 2.1. Conceptos Básicos de bases de datos

Bit: 0 o 1 Byte: conjunto de bits Campo: Conjunto de bytes la unidad más pequeña a la cual uno puede referirse en un programa. Registro: Colección de campos de iguales o de diferentes tipos. Archivo: Colección de registros almacenados siguiendo una estructura homogénea. Base de datos: Es una colección de archivos interrelacionados Campo clave: Es un campo particular dentro del registro, que permite la identificación exclusiva y unívoca de cada registro. La clave debe ser un valor que no se repita, como por ejemplo, el número de cédula de identidad, número de identificación, el número de carné en una universidad o el número de seguro social. Enlace: Relación entre una secuencia de nodos, en los que se guardan campos de datos Estructura de datos de árbol: Es una forma de organizar un conjunto de datos elementales con el objetivo de facilitar su manipulación la organización solo sigue una jerarquía un nodo proviene de un solo nodo. Estructura de datos en red: Es igual a la estructura de datos en árbol, su diferencia está en que un nodo proviene de varios nodos. Diagramas de estructura de datos: Es una descripción de la relación entre entidades (personas, lugares, eventos y objetos) de un sistema y el conjunto de información relacionado con la entidad. Algoritmo: Un algoritmo es el conjunto de operaciones y procedimientos que deben seguirse para resolver un problema

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Definiciones de Base de datos 3.1. Definiciones de Base de datos 1. Conjunto de archivos interrelacionados entre ellos. 2. Sistema para archivar en computador, cuyo propósito es mantener la información y hacer que esté disponible cuando se necesite. 3. Conjunto de información (conjunto de datos) que se encuentra agrupada o estructurada. 4. Instrumento que supone un enfoque distinto en la gestión de datos. 5. Un conjunto de información almacenada en memoria auxiliar que permite acceso directo y un conjunto de programas que manipulan esos datos. 6. Conjunto exhaustivo no redundante de datos estructurados organizados independientemente de su utilización y su implementación en máquina accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de información diferente y no predicable en tiempo . 7. Una base de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su uso posterior. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta . 8. conjunto de registros, homogéneos, ordenados de una forma determinada, almacenados en soporte magnético u óptico y accesibles por ordenador 9. Se refiere a la estructura y la forma en que se guardará la información de una empresa. Las bases de datos reflejan la organización de la información de la empresa y por lo general se encuentran centralizadas físicamente en él o los servidores principales_.

. Ibid., p. 6. . Bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm. http://www.icapax.com/ASP/bases_de_datos.asp .PÉREZ ÁLVAREZ-OSSORIO, J.R. Introducción a la información y documentación científica. Madrid: Alambra, 1988. p.39 . Términos de naturaleza comunicativa e informática. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm. http://www.colombiestad.gov.co/index.php?option=com_glossary&func=display&Itemid=25 &catid=114

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Tipos de bases de datos

4.1. Tipos de bases de datos Existen varias alternativas para diseñar las bases de datos: JERARQUÍA O ÁRBOL: Puede representar dos tipos de relaciones entre los datos: relaciones de uno a uno y relaciones de uno a muchos. RED O GRAFO: Este modelo permite la representación de muchos a muchos, de tal forma que cualquier registro dentro de la base de datos puede tener varias ocurrencias superiores a él. El modelo de red evita redundancia en la información, a través de la incorporación de un tipo de registro denominado el conector. MODELO RELACIONAL: Este modelo se está empleando con más frecuencia en la práctica, debido a las ventajas que ofrece sobre los dos modelos anteriores, entre ellas, el rápido entendimiento por parte de usuarios que no tienen conocimientos profundos sobre Sistemas de Bases de Datos. BASES DE DATOS ORIENTADAS A OBJETOS (BDOO): Las BDOO almacenan y manipulan información que puede ser digitalizada (representada) por objetos, proporcionan una estructura flexible con acceso ágil, rápido, con gran capacidad de modificación. Además combina las mejores cualidades de los archivos planos, las bases jerárquicas y relacionales. BASES DE DATOS DISTRIBUIDAS. Las bases de datos distribuidas se están utilizando cada vez más en la misma medida en que se usan las arquitecturas de cliente-servidor y groupware. Los principales problemas que se generan por el uso de la tecnología de bases de datos distribuidas son en lo referente a duplicidad de datos y a su integridad al momento de realizar actualizaciones a los mismos. Además, el control de la información puede constituir una desventaja, debido a que se encuentra diseminada en diferentes localidades geográficas. TENDENCIAS FUTURAS. En el futuro la mayoría de las organizaciones cambiarán la forma convencional de manejo de la información a la arquitectura de base de datos a las ventajas derivadas de su uso. El uso de las bases de datos distribuidas se incrementará de manera considerable en la medida en que la tecnología de comunicación de datos brinde más facilidades para ello. El uso de bases de datos facilitará y soportará en gran medida a los Sistemas de Información para la Toma de decisiones.

. Ibíd., p. 6.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Componentes que integran un sistema de base de datos 5.1. Componentes que integran un sistema de base de datos

1. Datos: cualquier cosa. 2. Información: Son los datos organizados y presentados de tal manera que resulten de utilidad para la toma de decisiones en la empresa en la cual debe servir el sistema. 3. Equipo: Donde se conservan los datos almacenados, el procesador y la memoria principal hacen posible la ejecución de los programas del sistema de base de datos. 4. Programas: Permiten la implantación, acceso y mantenimiento del sistema de base de datos. Así como la definición, actualización y recuperación de los datos estructurados. Estos programas componen el DBMS sistema manejador de base de datos (Data Base Management System) o también SGBD (Sistema Gestor de Base de Datos). 5. Usuarios: Son las personas que interactúan con la base de datos Hay dos clases de usuarios: Informáticos: Tienen a su cargo las tareas de creación y mantenimiento de la base de datos así como la realización de los procedimientos y programas que necesitan los usuarios finales estos son:

o o o

Diseñador: Recoge y organiza los datos en un modelo Programadores de aplicaciones: son los que desarrollan los programas de interfase con los usuarios finales y acceden a la base de datos usando DML. Administrador de base de datos (DBA): Es un experto que gestiona la base de datos. Es la persona encargada de la administración de las bases de datos y tiene las siguientes funciones:

Instala y actualiza el software Saca copias de seguridad Da soporte a todos los usuarios Revisa las tareas diarias sobre la base de datos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Definición del esquema: es decir la creación del esquema original de la base de datos. Esto lo hace escribiendo una serie de definiciones en lenguaje DDL lo que genera las tablas y lo graba en el diccionario de datos. Definición de la estructura de almacenamiento y del método de acceso: esto se lleva a cabo escribiendo una serie de definiciones con el mismo DDL Modificación del esquema y de la organización física: ya sea la modificación del esquema de la base de datos o de la descripción de la organización física del almacenamiento. Estos cambios, aunque son poco frecuentes, se hacen usando DDL, compilándolas y aplicándolas al diccionario de datos. Concesión de autorización para el acceso de datos: es decir administrar la seguridad de la base de datos, o sea conceder acceso o denegarlo a un usuario en particular. Especificación de las limitantes de integridad: estas limitantes se conservan en una estructura especial del sistema que consulta el manejador de bases de datos cada vez que se lleva a cabo una actualización a un dato de la base de datos.

Finales: Su interés está centrado en el contenido da la base de datos estos pueden ser: o o

Sofisticados: utilizan lenguajes de consulta de base de datos Ingenuos: Utilizan interfaces y menús creados por los usuarios especializados

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

6. Ventajas y desventajas de una base de datos 6.1. Ventajas de las bases de datos

Disminuir redundancia e inconsistencia de los datos: Puesto que los archivos y los programas de aplicaciones fueron creados por distintos programadores en un periodo largo, es posible que un mismo dato este repetido en varios sitios. Esta redundancia aumenta los costos de almacenamiento y acceso, además incrementa la posibilidad que exista inconsistencia en la información, es decir que las distintas copias de la información no concuerden entre sí. Por ejemplo: si un sistema graba información de sus clientes en el archivo de facturación y también maneja datos de clientes en un archivo de servicio postventa, entonces un cliente podría tener sus datos en dos archivos diferentes. Esto genera dos problemas: el primero es que estamos gastando el doble de espacio en disco para grabar la misma información y el otro es que si ese cliente cambia de domicilio y solo se cambia en el archivo de facturación entonces la información será inconsistente pues en el archivo de servicio postventa estará la información anterior, o sea que se tienen dos datos diferentes para el mismo individuo. Facilidad para tener acceso a los datos: suponga que el gerente de la empresa llamada Aceites Esenciales S.A. desea saber la información de todos los clientes que consumieron Extracto de manzanilla durante los primeros tres meses del año en curso, ordenados por municipio. Ante un requerimiento de estos que no estaba contemplado en el sistema original, tocaba hacer dos cosas; sacar el listado completo de todos los clientes y extraerlos manualmente o sentar a un programador por una semana o más para que haga el programa para hacer la consulta. La pregunta esencial es y que se va a hacer la siguiente vez que se requiera una consulta que no estaba inicialmente prevista? Aislamiento o independencia de los datos: puesto que los datos están repartidos en varios archivos, y estos pueden tener diferentes formatos, es difícil escribir nuevos programas para obtener los datos apropiados. Usuarios múltiples: Para mejorar el funcionamiento general del sistema y obtener un tiempo de respuesta más corto, muchos sistemas son multiusuario o sea que permiten el uso de diferentes usuarios en forma simultánea o concurrente. En un ambiente de este tipo, las diferentes actualizaciones sobre el mismo dato pueden resultar en dejar los datos inconsistentes. Por ejemplo: un cuentahabiente del banco XXX tiene un saldo de $1000 y en forma simultánea el cliente hace un retiro y el banco hace el descuento por compra de chequera. Como las dos transacciones se hacen al mismo tiempo el dato que leen ambas transacciones es $1000. Supongamos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

que la chequera cuesta $100 y el retiro es por $200, entonces el modulo de descuento de chequeras escribirá el valor $900 en el archivo, y el modulo de retiros de los clientes escribe $800, luego el saldo final será $800 que fue el ultimo datos escrito en el archivo. Será este dato correcto? Seguridad: el empleado de nomina debe tener acceso a los datos de los empleados y no de los clientes, y a la vez un cajero debe tener acceso a la información de clientes y no a la de los empleados. Integridad: será lógico un precio de un producto que sea menor que cero? Para esto se imponen ciertos limitantes de consistencia pero que pasara cuando resulten nuevos limitantes?

6.2. Desventajas de las bases de datos Complejidad: Los SGBD son conjuntos de programas que pueden llegar a ser complejos con una gran funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder realizar un buen uso de ellos. Coste del equipamiento adicional: Tanto el SGBD, como la propia base de datos, pueden hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación de un sistema de bases de datos sea más cara. Vulnerable a los fallos: El hecho de que todo esté centralizado en el SGBD hace que el sistema sea más vulnerable ante los fallos que puedan producirse. Es por ello que deben tenerse copias de seguridad (Backup). Tipos de Campos: Cada Sistema de Base de Datos posee tipos de campos que pueden ser similares o diferentes. Entre los más comunes podemos nombrar: • • • • •

Numérico: entre los diferentes tipos de campos numéricos podemos encontrar enteros “sin decimales” y reales “decimales”. Booleanos: poseen dos estados: Verdadero “Si” y Falso “No”. Memos: son campos alfanuméricos de longitud ilimitada. Presentan el inconveniente de no poder ser indexados. Fechas: almacenan fechas facilitando posteriormente su explotación. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los días entre una fecha y otra. Alfanuméricos: contienen cifras y letras. Presentan una longitud limitada (255 caracteres).

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Autoincrementables: son campos numéricos enteros que incrementan en una unidad su valor para cada registro incorporado. Su utilidad resulta: Servir de identificador ya que resultan exclusivos de un registro .

. Bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm. http://html.rincondelvago.com/bases-de-datos_9.html . ¿Qué son las bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm http://www.maestrosdelweb.com/principiantes/%C2%BFque-son-las-bases-de-datos/ . Ibíd. . Ibíd. P. 6

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

7. Abstracción de los datos Una base de datos es en esencia una colección de archivos relacionados entre sí, de la cual los usuarios pueden extraer información sin considerar las fronteras de los archivos. Los niveles de abstracción son la forma de esconder la complejidad de los datos para que usuarios no familiarizados con las computadoras puedan manipular los datos. Existen diferentes niveles de abstracción para simplificar la interacción de los usuarios con el sistema; Interno, conceptual y externo, específicamente el de almacenamiento físico, el del usuario y el del programador.

7.1. Nivel físico. Es la representación del nivel más bajo de abstracción, en éste se describe en detalle la forma en cómo de almacenan los datos en los dispositivos de almacenamiento (por ejemplo, mediante señaladores o índices para el acceso aleatorio a los datos).

7.2. Nivel conceptual El siguiente nivel más alto de abstracción, describe que datos son almacenados realmente en la base de datos y las relaciones que existen entre los mismos, describe la base de datos completa en términos de su estructura de diseño. El nivel conceptual de abstracción lo usan los administradores de bases de datos, quienes deben decidir qué información se va a guardar en la base de datos. Consta de las siguientes definiciones: 1. Definición de los datos: Se describen el tipo de datos y la longitud de campo todos los elementos direccionales en la base. Los elementos por definir incluyen artículos elementales (atributos), totales de datos y registros conceptuales (entidades). 2. Relaciones entre datos: Se definen las relaciones entre datos para enlazar tipos de registros relacionados para el procesamiento de archivos múltiples. En el nivel conceptual la base de datos aparece como una colección de registros lógicos, sin descriptores de almacenamiento. En realidad los archivos conceptuales no existen físicamente. La transformación de registros conceptuales a registros físicos para el almacenamiento se lleva a cabo por el sistema y es transparente al usuario .

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1. Nivel de visión. Nivel más alto de abstracción, es lo que el usuario final puede visualizar del sistema terminado, describe sólo una parte de la base de datos al usuario acreditado para verla. El sistema puede proporcionar muchas visiones para la misma base de datos. La interrelación entre estos tres niveles de abstracción se ilustra en la siguiente figura 1. Figura 1

Basada en la dirección:: http://www.temas-estudio.com/base-de-datos/ Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008

. Abstracción de la información. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_3.htm

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

8. Sistema Manejador de Bases de Datos – DBMS 8.1. Sistema Manejador de Bases de Datos – DBMS Es el corazón de la base de datos ya que se encarga del control total de los posibles aspectos que la puedan afectar. Es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea específica .

8.2. Las funciones principales de un DBMS son: 1. Crear y organizar la Base de datos. 2. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que los datos puedan ser accesados rápidamente. 3. Manejar los datos de acuerdo a las peticiones de los usuarios. 4. Registrar el uso de las bases de datos. 5. Interacción con el manejador de archivos. 6. Respaldo y recuperación. 7. Control de concurrencia. 8. Seguridad e integridad.

El DBMS también conocido como el Gestor de Base de Datos, es como la interfase entre la base de datos física y las peticiones del usuario. El DBMS interpreta las peticiones de entrada/salida del usuario y las manda al sistema operativo para la transferencia de datos entre la unidad de memoria secundaria y la memoria principal. El siguiente grafico ilustra mejor este funcionamiento:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Figura 2

Basada en la dirección:: http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_9.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008

Algunos ejemplos de manejadores de bases de datos son: Dbase, Fox, Access, Informix, Unify, Oracle, Internase

. Ibíd., pg. 14. . Ibíd., pg. 14.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

9. Lenguaje de consulta estructurado (SQL) 9.1. Lenguaje de consulta estructurado (SQL)

Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. SQL es considerado actualmente como un lenguaje estándar. Los DBMS están compuestos por el lenguaje de definición de datos y el lenguaje de manipulación de datos 1. Lenguaje de Definición de Datos Denominado por sus siglas como: DDL(Data definition Language), permite definir un esquema de base de datos por medio de una serie de definiciones que se expresan en un lenguaje especial, el resultado de estas definiciones se almacena en un archivo especial llamado diccionario de datos. El resultado de la compilación de las sentencias DDL es un conjunto de tablas que se almacena en un archivo especial llamado diccionario o directorio de datos. 2. Lenguaje de Manipulación de Datos La manipulación de datos se refiere a las operaciones de insertar, recuperar, eliminar o modificar datos; dichas operaciones son realizadas a través del lenguaje de manipulación de datos (DML, Data Manipulation Language), que es quién permite el acceso de los usuarios a los datos.

Existen básicamente 2 tipos de lenguajes de manipulación de datos: Procedimentales en los que los LMD requieren que el usuario especifique que datos se necesitan y cómo obtenerlos y No procedimentales, donde los LMD requieren que el usuario especifique que datos se necesitan y sin especificar cómo obtenerlos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

10.Estructura General del Sistema 10.1. Estructura General del Sistema Un sistema de base de datos se encuentra dividido en módulos cada uno de los cuales controla una parte de la responsabilidad total de sistema. En la mayoría de los casos, el sistema operativo proporciona únicamente los servicios más básicos y el sistema de la base de datos debe partir de esa base y controlar además el manejo correcto de los datos. Así el diseño de un sistema de base de datos debe incluir la interfaz entre el sistema de base de datos y el sistema operativo. Los componentes funcionales de un sistema de base de datos, son: 1. Gestor de archivos: Gestiona la asignación de espacio en la memoria del disco y de las estructuras de datos usadas para representar información. 2. Manejador de base de datos: Sirve de interfaz entre los datos y los programas de aplicación. 3. Procesador de consultas: Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Además convierte la solicitud del usuario en una forma más eficiente. 4. Compilador de DDL: Convierte las proposiciones DDL en un conjunto de tablas que contienen metadatos, estas se almacenan en el diccionario de datos. 5. Archivo de datos: En él se encuentran almacenados físicamente los datos de una organización. 6. Diccionario de datos: Contiene la información referente a la estructura de la base de datos. 7. Índices: Permiten un rápido acceso a registros que contienen valores específicos. Una forma gráfica de representar los componentes antes mencionados y la relación que existe entre ellos sería la siguiente.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Figura 3

Estructura Global del Sistema Basada en la dirección: http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_12.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Diseño: Equipo Técnico P.A.V. Agosto del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

11.Modelo de datos Un Modelo es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica. Un Modelo de Datos es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia. 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.

11.1. Modelos lógicos basados en objetos 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 como el entidad relación y el orientado a objetos, pero el más utilizado por su sencillez y eficiencia es el modelo EntidadRelación. El Modelo Entidad-Relación: Denominado por sus siglas como: 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.

11.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 (ligas) o apuntadores. 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:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

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 ligas. La diferencia radica en que están organizados por conjuntos de árboles en lugar de gráficas arbitrarias.

Figura 4

Modelo Jerárquico de Bases de Datos Basada en la dirección: http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Modelo de Red: Este modelo representa los datos mediante colecciones de registros y sus relaciones se representan por medio de ligas o enlaces, los cuales pueden verse como punteros. Los registros se organizan en un conjunto de gráficas arbitrarias. Un modelo jerárquico presenta una estructura como la que se muestra en la figura 5.

Figura 5

Ejemplo Modelo Jerárquico Basada en la dirección: http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008

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 renglones (tuplas) equivalen a los 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. Es el tipo de base de datos más difundido y utilizado en la actualidad y el cual veremos en detalle en el segundo encuentro. Un modelo de datos relacional, presenta una estructura como la que se muestra en la figura 6.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Figura 6

Ejemplo del Modelo Relacional Basada en la dirección: http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008

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 .

. Ibid., p 23 . Ibíd., pg. 23 . Modelos de datos. Obtenida en Internet el 22 agosto de 2008. Hora: 10.42 pm http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_4.htm

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

12. Ciclo de vida de una base de datos Bases de datos-Modelo de datos-Ciclo de vida El ciclo de vida de un desarrollo de una base de datos consta de siete pasos: 1. 2. 3. 4. 5. 6.

Análisis de las necesidades Estudio de viabilidad Definición de requisitos Diseño conceptual / lógico Implementación Evaluación y Mantenimiento

12.1. Análisis de las necesidades En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en la introducción de la guía, las necesidades de información de cada uno de ellos, así como los informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta más precisión exista en estos requisitos iniciales más preciso será el desarrollo de la base de datos. En esta reunión también debe quedar documentados los niveles de seguridad de los grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicación de los usuarios. No hay que olvidar que normalmente en las empresas existen ya sistemas de almacenamiento de datos, por tanto es conveniente analizar los datos ya existentes y analizar las posibles relaciones con la base de datos a desarrollar. Un cuestionario muy sencillo pero muy útil para el administrador es el siguiente (a rellenar por todos los usuarios): Nombre Cargo Área de Responsabilidad Obligaciones principales que requieren información de la base datos ¿De qué aplicaciones recibe información? ¿Con cuánta frecuencia recibe información? ¿Qué hace con esta información? ¿Qué precauciones de seguridad debe tomar con respecto a la información? ¿Para qué aplicación proporciona datos?

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

¿Están contemplados cambios para alguna de sus actividades actuales que involucren alguna de las informaciones anteriores?

12.2. Estudio de viabilidad Un estudio de viabilidad implica la preparación de un informe con las características siguientes: 1. Viabilidad tecnológica. ¿Hay tecnología suficiente para el desarrollo? 2. Viabilidad operacional. ¿Existen suficientes recursos humanos, presupuesto, experiencia y formación para el desarrollo? 3. Viabilidad económica. ¿Se pueden identificar los beneficios? ¿Los beneficios costearían el desarrollo del sistema? ¿Se pueden medir los costes y los beneficios?

12.3. Definición de requisitos Los requisitos de desarrollo involucran el software y hardware necesario para la implementación, los recursos humanos necesarios (tanto internos como externos), la formación al personal. Aunque un poco al margen del tema es conveniente parar en este momento y planificar las acciones a realizar elaborando un cronograma del proyecto y un organigrama con las responsabilidades de cada miembro del equipo. Conviene señalar quienes van a ser los interlocutores y fijar un calendario de reuniones de seguimiento del proyecto. Hay que definir la figura del validador, esta persona será la encargada de velar en cada momento que no se está rebasando el alcance del proyecto, así como asegurar que la implementación está encaminada a subsanar las necesidades del cliente.

12.4. Diseño En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementación. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulación de los diferentes grupos de usuarios.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Si parte de la información necesaria para crear algún elemento establecido ya se encuentra implementado en otro sistema de almacenamiento hay que documentar que relación existirá entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos. El diseño consta, como se vio anteriormente, de tres fases: el diseño global o conceptual, el diseño lógico y el modelo físico.

12.5. Implementación Una vez totalmente detallado el modelo conceptual se comienza con la implementación física del modelo de datos, a medida que se va avanzando en el modelo el administrador del sistema va asegurando la corrección del modelo y el validador la utilidad del mismo. La implementación consiste en el desarrollo de las tablas, los índices de los mismos, las condiciones de validación de los datos, la relación entre las diferentes tablas. Por otro lado, la definición de las consultas y los parámetros a utilizar por cada una de ellas. Una vez finalizada la implementación física, se asignan las correspondientes medidas de seguridad y se ubica la base de datos en el lugar correspondiente.

12.6. Evaluación y Perfeccionamiento En esta última etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposición cuanta información necesiten. También deberán asegurarse que el acceso a los datos es cómodo, práctico, seguro y que se han eliminado, en la medida de lo posible, las posibilidades de error. El administrador se asegura que todos los derechos y todas las restricciones han sido implementadas correctamente y que se ha seguido en Tutorial de estilo en la totalidad de la implementación. El validador se asegurará que todas las necesidades del cliente han sido satisfechas.

El contenido del tema 12: Ciclo de Vida de una base de datos ha sido íntegramente elaborado por Claudio Casares www.lobocom.es/~claudio Tomado de http://www.solorecursos.com/manuales/sql/moddat003.htm. Septiembre 20 de 2008.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Unidad 2

Modelo Entidad Relación (E/R) El diseño conceptual es el proceso por el cual se construye un modelo de la información que se utiliza en una empresa u organización, el objetivo más esencial de la fase de requerimientos es crear un modelo de los datos del usuario. Tal modelo identifica las cosas que se van a almacenar en la base de datos y define sus estructuras y las relaciones, es el modelo entidad relación uno de los modelos más conocidos, simples y claros donde se puede expresar gráficamente toda la estructura de la base de datos.

1. Modelo Entidad Relación Definición: Es la percepción del mundo real. Colección de objetos básicos llamados entidades y relaciones. El modelo contiene ciertas restricciones a la que debe de ajustarse los datos. Lo que hace al modelo entidad relación universal es que no está enfocado al diseño de un modelo de bases de datos particular. Se emplea para interpretar, especificar y documentar los requerimientos para un sistema de bases de datos ya que proporciona estructuras que muestran el diseño general de los requerimientos de datos de los usuarios. El modelo debe estar compuesto por: Entidades Atributos Relaciones Cardinalidad Claves

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Ventajas del modelo entidad relación Constituye la base del modelo conceptual de datos. Es el modelo semántico más popular encontrado en los libros.. Proporciona estructuras que muestran el diseño general de los requerimientos de datos de los usuarios. Va de lo particular a lo general Es muy flexible está enfocado al diseño de muchas situaciones.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Pasos Para Construir El Modelo Entidad Relación Identificación de entidades. Identificación de relaciones. Elaborar el modelo. Identificar atributos. Refinar modelo. Pasar el modelo entidad relación a un modelo implementable (modelo relacional).

3.1. Primer Paso: Reconocer Entidades Es toda cosa u objeto significativo (real ó imaginario) del cual se requiere conocer ó almacenar información.

3.1.1. REPRESENTACIÓN DE ENTIDADES Toda entidad se representa por medio de un rectángulo con el nombre de la entidad dentro del rectángulo en mayúsculas. Ejemplo

3.1.2. Cómo Identificar Las Entidades Es el paso central del proceso de modelo entidad relación. Los diversos tipos de entidades son: PERSONAS: Jurídicas o naturales como: cliente, alumno, vendedor, profesor, empleado etc. OBJETOS: Tangibles y no tangibles como: artículo, cuenta etc. LUGARES: Bodega, ciudad, aula. TRANSACCIONES: Compra, venta, evaluación. CONCEPTOS O ABSTRACCIONES: Tipo crédito, Tipo servicio, Tipo cliente etc.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Toda persona realiza una transacción y que la acción de esta recae siempre sobre un objeto dado. Todas las personas y los objetos residen y se almacenan en un lugar

3.2. Segundo Paso: Relaciones O Reglas Relación: Es una asociación nómbrale, significativa y estable entre dos entidades. Ejemplo Se tienen dos entidades estudiante, clase. La relación entre estudiante y clase es:

Cada estudiante debe tener una ó más clases y cada clase debe de estar compuesta por uno ó más estudiantes.

3.2.1. Representación De Las Relaciones O Reglas Toda relación tiene dos extremos y para cada uno de los cuales existen:

1. Una leyenda: generalmente es un verbo. •

Un grado de cardinalidad

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1:1 uno a uno

Ejemplo tomado de: http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm. Fecha Septiembre 27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

1:N uno a muchos

Tomado de: http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm. Fecha Septiembre 27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

N:M muchos a muchos

Ejemplo tomado de: http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm. Fecha Septiembre 27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

3.2.2. Cardinalidad o multiplicidad de las relaciones:

Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.2.3. Una condición opcional ó mandatoria Mandatoria: Se representa con línea continua y se utiliza la palabra debe_____________________Toma desde 1, 2, .., N Opcional: Se representa con línea discontinua y se utiliza la palabra puede_ _ _ _ _ _ _ _ _ _ _ _ Toma desde 0, 1, 2,..,N

Al hacer la unión de estas dos partes de la relación queda:

La relación ó regla se escribe de la siguiente forma:

Cada estudiante debe inscribirse en uno ó más club Y cada club puede tener uno ó más estudiantes.

Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.2.4. RELACIONES RECURSIVAS Es una jerarquía definida sobre una misma entidad. Para este tipo de relaciones también se tiene en cuenta las reglas anteriores como: La leyenda, la cardinalidad y la condición.

3.2.5. La regla ó relación se escribe: Cada cliente puede recomendar uno y solo un cliente y cada cliente puede ser recomendado por uno y solo un cliente.

3.3. Tercer Paso: Elaborar El Modelo Para elaborar el modelo entidad relación se tienen en cuenta las entidades que tengo relacionadas sin repetir entidades. Ejemplos:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.4. Cuarto Paso: Reconocer Atributos Cualquier detalle que sirve para identificar, describir, cualificar, clasificar ó expresar el estado de una entidad. Un atributo puede ser: Texto, número, figuras ó sonidos.

3.4.1. TIPOS DE ATRIBUTOS Atributos clave primaria: Toda entidad debe ser identificada con unicidad mediante uno de sus atributos ó una combinación de los mismos, denominado clave primaria ó identificador único. Así todos los atributos de una entidad deben depender únicamente del valor de la clave primaria. Su representación para el modelo entidad relación se hace colocando el símbolo # antepuesto al nombre del atributo. Ejemplo:

Atributos mandatarios u obligatorios: Cuando el valor de un atributo debe ser siempre conocido, este se representa mediante un símbolo * antepuesto al nombre del atributo. Ejemplo

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Atributos opcionales: Son aquellos que pueden ser desconocidos, estos se representan por punto antepuesto al nombre del atributo. Ejemplo

3.4.2. Reglas Para La Identificación De Atributos Durante este proceso es posible identificar nuevas entidades y relaciones ocultas en el modelo. 1. Toda entidad debe tener un identificador único ó clave primaria en caso de que no la tenga puede asignar una. 2. Un atributo debe escribirse siempre en singular y en minúscula, un nombre de atributo en plural coincide con el problema de repetición esta repetición de atributos puede revelar la existencia de entidades faltantes en el modelo. Ejemplo:

Aquí podemos ver que un cliente puede tener varios teléfonos lo que me está indicando la presencia de una nueva entidad llamada teléfono. Ejemplo:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Un atributo se transforma en una entidad cuando tiene significado completo en sí mismo, con relaciones y atributos propios.

Podemos observar que área que es un atributo y este también tiene atributos propios como número del área y nombre del área y se pude relacionar con la materia.

Toda entidad debe tener al menos dos atributos una clave primaria y un descriptor. Las únicas entidades que pueden tener solo la clave primaria son las entidades de intersección que tienen clave primaria compuesta por dos atributos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.4.3. Como Identificar Claves: Clave candidatas: Es un grupo de atributos que identifican de forma única un registro en una tabla. Clave primaria: Es una de las claves candidatas que se selecciona para que sea clave primaria. Clave secundaria ó alterna: Es la clave que queda después de escoger la clave primaria. Clave compuesta: Es una clave con más de un atributo, es el caso de las entidades de intersección. Clave sustituta: Es una columna de valores únicos que puede mantener una aplicación ó el DBMS. Clave Ajena: Es un atributo que es una clave primaria en una entidad y que está en otras entidades fuera de aquella a donde pertenece, estas clave son muy importantes ya que por medio de estas hace la relación el modelo relacional

3.5. Quinto Paso: Refinar Modelo Para refinar el modelo entidad relación: 1. Se destruye toda relación N:M que tenga el modelo para que quede 1:N.

3.5.1. COMO ELIMINAR LAS RELACIONES DE N:M Se crea una nueva entidad que intersecta a las entidades participantes y donde el identificador único (clave primaria) se forma mediante la combinación de las claves primarias de dichas entidades.

Esta es la relación que debo eliminar para que queden relaciones 1:N

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

La relación queda de la siguiente manera:

Las entidades estudiante y club son las entidades participantes y la entidad est_club es la entidad de intersección ó entidad débil y toda la relación se llama relación de dependencia. La entidad de intersección puede tener únicamente la clave primaria como se dijo en el reconocimiento de claves y en caso de colocarle otros atributos hay que tener en cuenta que este dependa de los dos atributos que forman la clave primaria. Ejemplo: Un atributo para la entidad EST_CLUB sería el horario en que un estudiante está inscrito en un club.

3.5.2. Reglas para ubicar la clave foráneas: 1. Si la relación es de 1: 1 cualquiera de las dos entidades le pasa la clave primaria a la otra 2. Si la relación es de 1: N: la entidad lado 1 le pasa la clave primaria al lado N •

Otros puntos importantes para tener en cuenta al momento de refinar el modelo Revisar para ver que hace falta ó que es redundante en el modelo acuerdo a las condiciones o requerimientos que se pidieron.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Otros conceptos para el modelo entidad relación

4.1. SUPERCLASES Y SUBCLASES DE ENTIDADES En el modelo entidad relación, una entidad agrupa un conjunto de ocurrencias de entidad del mismo tipo. En muchos casos, estas ocurrencias se pueden agrupar a su vez en otros subconjuntos que tienen un significado propio para los propósitos de la Base de Datos y, por tanto, deberían representarse de forma explícita. Por ejemplo, la entidad EMPLEADO puede a su vez subdividirse en SECRETARIA, INGENIERO, JEFE, TÉCNICO, ASALARIADO, SUBCONTRATADO, etc. El conjunto de ocurrencias de entidad en cada una de estas entidades será un subconjunto de las ocurrencias de entidad de EMPLEADO, ya que por ejemplo, un ingeniero también es un empleado. Llamaremos a cada uno de estos subconjuntos Subclases de la entidad EMPLEADO y a EMPLEADO una Superclase de cada uno de estos subconjuntos. Llamaremos a la relación existente entre las Superclases y las Subclases como relación Clase/Subclase. En el ejemplo anterior, EMPLEADO/SECRETARIA y EMPLEADO/TÉCNICO son dos relaciones Clase/Subclase. Hay que tener en cuenta que una ocurrencia de una Subclase representa el mismo objeto real que alguna correspondiente a su Superclase, por ejemplo la SECRETARIA "Concha Leco" será también la EMPLEADO "Concha Leco". Por tanto, la ocurrencia de Subclase es la misma que en la Superclase pero con un rol específico. Una ocurrencia de Subclase no tienen sentido si no es a su vez ocurrencia de Superclase. Por otro lado, una ocurrencia de superclase puede ser a su vez ocurrencia de varias subclases o de ninguna. Por ejemplo, "Roberto Mate" como ocurrencia de EMPLEADO puede a su vez pertenecer a subclases INGENIERO y ASALARIADO.

4.2. HERENCIA DE ATRIBUTOS EN LA RELACIÓN CLASE/SUBCLASE. Debido a que una subclase es a su vez parte se una superclase, la subclase tendrá sus atributos específicos así como los atributos correspondientes a la superclase a la que pertenece. Esto quiere decir que la ocurrencia de entidad de una subclase hereda los atributos correspondientes a la superclase a la que pertenece. De la misma manera hereda las relaciones en las que su correspondiente superclase participa.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4.3. ESPECIALIZACIÓN. El proceso por el que se definen las diferentes subclases de una superclase se conoce como especialización. El conjunto de subclases se define basándonos en características diferenciadores de las ocurrencias de entidad de la superclase. Por ejemplo, el conjunto se subclases {SECRETARIA, INGENIERO, TÉCNICO} es una especialización de la superclase EMPLEADO mediante la distinción del tipo de trabajo en cada ocurrencia de entidad. Podemos tener varias especializaciones de una misma entidad basándonos en distintos criterios. Por ejemplo, otra especialización de EMPLEADO podría dar lugar a las subclases ASALARIADO y SUBCONTRATADO, dependiendo del tipo de contrato. DIAGRAMAS ENTIDAD RELACIÓN

http://www.galeon.com/konnan2001/ERE.htm Ibíd. Ibíd. Ibíd., p. 18

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Ejercicios resueltos de modelo entidad relación Deseamos diseñar una base de datos para una universidad, se dispone de la siguiente información: Los departamentos pueden estar en una sola facultad. Un profesor está siempre asignado a un sólo departamento y adscrito a una o varias cátedras, pudiendo cambiar de cátedra pero no de departamento; interesa la fecha en que un profesor es adscrito a una cátedra. Tenga en cuenta que una cátedra puede ser asignada a varios profesores

2. Se desea diseñar una base de datos que contenga información relativa a las carreteras de determinado país. sabiendo que:

Se pide realizar el diseño en el modelo E/R,

En dicho país las carreteras se encuentran dividas en tramos. Un tramo siempre pertenece a una única carretera y no puede cambiar de carretera. Un tramo puede pasar por varios términos municipales, siendo de interés el kilómetro del tramo por el que entra en dicho término municipal y el kilómetro por el que sale. Existen una serie de áreas en las que se agrupan los tramos y cada uno de ellos no puede pertenecer a más de un área.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Se desea diseñar una base de datos sobre la información de las reservas de una empresa dedicada al alquiler de automóviles. Se dispone de la siguiente información: Un determinado cliente puede tener en un momento dado varias reservas. Una reserva la realiza un único cliente, pero puede involucrar a varios coches. Es importante registrar la fecha de comienzo de la reserva y la de terminación. Todo coche tiene siempre asignado un determinado garaje, que no puede cambiar. Cada reserva se realiza en una determinada agencia. En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Video club: En una tienda de video se necesita mantener información de alrededor de 3000 casetas cada uno de los casetes tiene asignado un número por cada película se necesita conocer un titulo y categoría por ejemplo: comedia, suspenso, drama, acción, ciencia ficción, etc. Se mantienen algunas copias de muchas películas. Se le da a cada película una identificación y se mantiene seguimiento de lo que contiene cada casete.

Un casete puede venir en varios formatos y una película es grabada en un solo casete; frecuentemente las películas son pedidas de acuerdo a un actor especifico Tom Cruise y Demi More son los más populares es por esto que se debe mantener información de los actores que pertenecen a cada película. No en todas las películas actúan artistas famosos, a los clientes de la tienda le gusta conocer datos como el nombre real del actor, y su fecha de nacimiento. En la tienda se mantienen información solo d los actores que aparecen en las películas y que se tiene a disposición. Solo se alquila videos a aquellos que pertenecen al club de videos. Para pertenecer al club se debe tener un buen crédito. Por cada miembro del club se mantiene una ficha con su nombre, teléfono y dirección, cada miembro del club tiene asignado un número de membresía. Se desea mantener información de todos los casetes que un cliente alquila, cuando un cliente alquila un casete se debería conocer el nombre de la película, la fecha en la que se alquila y la fecha de devolución.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

ENTIDAD CLIENTE PELÍCULAS TIPO_PEL ACTORES CASETE ALQUILER

Ejemplo tomado de: http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml Fecha Septiembre 27 de 2008 hora: 10 pm Diseño esquema: Equipo Técnico P.A.V.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Un modelo ER de Propietarios de Taxis Conductores y Empresas

•

¿Un Taxi cuantos propietarios tiene? R/ uno

•

(El uno se pone en PROPIETARIOS)

¿Un Propietario cuantos Taxis tiene? R/ Varios (La N se pone en TAXIS) ¿Un taxi cuantos Conductores tiene? R/ Uno (el 1 se pone en CONDUCTORES)

•

¿Un conductor Cuantos taxis maneja? R/ Uno

•

(El Uno se pone En TAXIS)

¿Un PROPIETARIO a cuantas EMPRESAS está afiliado? R/ Varias

•

(La N se pone en EMPRESAS)

¿Una empresa cuantos propietarios tiene afiliados? R/ Varias

(La N se pone en Propietarios)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Ejemplo tomado de: http://www.calasanz-pereira.edu.co/prueba/html/modules/Access/normalizacion.htm. Fecha Septiembre 27 de 2008 hora: 10 pm . Diseño esquema: Equipo Técnico P.A.V.

Nota: Este modelo no tiene destruidas las relaciones N:M. que hay entre cassette y alquiler y la de actor películas

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Unidad 3

Modelo Relacional El modelo relacional es un modelo lógico basado en registros que vino después de que los modelos jerárquico y de red estuvieran en uso. Este modelo relacional, no se puede decir que sea en sí un modelo semántico de datos. Su enorme éxito no se debe a que permite de forma implícita operaciones conceptualmente abstractas sobre los datos, sino a los altos niveles de fiabilidad e integridad que aporta en el manejo de grandes cantidades de datos.

1. Definición El modelo de datos relacional fue introducido por Edgar F. Codd (1970). Se basa en una estructura de datos simple y uniforme la relación y tiene fundamentos teóricos sólidos El modelo relacional representa la base de datos como una colección de relaciones. En términos mínimos informales, cada relación semeja una tabla o, hasta cierto punto, un archivo simple. Codd daba 12 reglas que debe cumplir cualquier base de datos que desee considerarse relacional:

1.1. Las Doce Reglas De Codd

1. Regla de información: Todos los datos de una base de datos relacional se representan explícitamente (al nivel lógico) como valores de tablas. 2. Reglas de acceso garantizado: Todos y cada uno de los datos (valor indisoluble, único o atómico) de una base de datos relacional se garantiza que sean lógicamente accesible recurriendo a una combinación de nombres de tabla, valor de clave primaria y nombre de columna. 3. Tratamiento sistemático de valores Nulos: Los valores nulos (distinto de cadena de caracteres vacías o de una cadena de caracteres en blanco y distinta de cero o de cualquier otro número) se soporta en los SGBD completamente relacionales para representar la falta de información y la información inaplicable de un modo sistemático e independiente del tipo de datos. 4. Catálogo en línea dinámico basado en el modelo relacional: La descripción de la base de datos o Catalogo se representa (o almacena) a nivel lógico como valores en tablas, del mismo modo que los datos ordinarios, de modo que los usuarios autorizados pueden aplicar a los datos regulares. 5. Regla de sublenguaje completo de datos: un sistema relacional puede soportar varios lenguajes de manipulación de datos (DMI) y varios modos de uso terminal (por ejemplo, el modo de rellenar con blancos), sin embargo

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

debe haber al menos un lenguaje cuyas sentencias sean expresables, mediante alguna sintaxis bien definida, como cadenas de caracteres, y que sea completa en cuanto al soporte de todos los puntos siguientes: Definición de datos y Definición de vistas Manipulación de datos (interactiva y por programa) Restricciones de integridad Autorización Fronteras de transacciones (comienzo, complementación y vuelta atrás) 6.

Regla de actualización de vistas:

Todas las vistas que puedan utilizarse son también actualizables por el sistema. 7. Inserción, Modificación y Borrado de alto nivel: Un SGBDR debe hacer más que recuperar conjuntos relacionales de datos, también debe ser capaz de insertar, actualizar y eliminar datos como un conjunto relacional. 8. Independencia física de los datos: Los datos deben ser físicamente independiente de los programas de aplicación. Los programas de aplicación y las actividades terminales permanecen lógicamente inalterados cualquiera que sean los cambios efectuados ya sea las representaciones de almacenamiento o a los métodos de acceso. 9. Independencia lógica de los datos: Cada vez que sea posible, el Software de aplicación debe ser independiente de los cambios hechos a las tablas Base. Los programas de aplicación y las actividades terminales permanecen lógicamente inalterados cuando se efectúan sobre las tablas de base de cambios preservadores de la información de cualquier tipo que teóricamente permita alteraciones. 10. Independencia de integridad: La integridad de los datos debe ser definible en el lenguaje relacional y almacenarse en el Catálogo. Las restricciones de integridad específicas para una base de datos relacional y almacenables en el catálogo, no en los programas de aplicación. 11. Regla de no subversión: Si un sistema relacional tiene un lenguaje de bajo nivel (un solo registro cada vez), ese bajo nivel no puede ser utilizado para subvertir o suprimir las reglas de integridad y las restricciones expresadas en el lenguaje relacional de nivel superior (múltiples registros a la vez)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

12. Un sistema de bases de datos relacionla(SGBDR) tiene independencia distributiva.

Las 12 reglas de Codd. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.atpsoftware.net/Public/Articulos.php

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

2. Estructura Del Modelo Relacional La definición de relación desde el punto de vista matemático es: Una relación es un subconjunto de un producto cartesiano de un listado de dominios. El producto cartesiano son todas las combinaciones posibles entre conjuntos. Ejemplo: Dados los conjuntos A y B, donde:

Esquema diseñado por: Equipo Técnico P.A.V. Octubre del 2008

Esta relación es un subconjunto del producto cartesiano. Ejemplo de una relación o tabla de una BD relacional:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Para cada atributo existe un conjunto de valores permitidos llamado dominio de ese atributo. Los dominios corresponden a los tipos de datos primitivos de los lenguajes de programación. Cada fila representa una tupla y una tupla es un conjunto ordenado de valores (atributos). Por tanto una relación es un conjunto de tuplas filas o registros. Cada atributo, columna o campo sólo puede tomar un único valor del dominio. El grado de una tabla = número de columnas La cardinalidad = número de registros Debido a que las tablas son básicamente relaciones se utilizan los términos matemáticos relación y tupla en lugar de los de tabla y fila. Cuando se habla de una BD debe diferenciarse entre el esquema de la BD, es decir, el diseño lógico de la BD y una instancia de la BD que está constituida con la información contenida en la BD en un momento determinado. El esquema de una relación es en general una lista de atributos y sus correspondientes dominios; la notación para ello sería: Producto= (cod_prd: string, nom_prd: string, valor: numérico) Sin embargo, no es necesario hacer una definición precisa del dominio de cada atributo, sino hasta el momento de la implementación. Por tanto la notación puede ser: Producto= (cod_prd, nom_prd, valor) El esquema de la BD en este modelo, es el conjunto de definiciones de sus esquemas. Ejemplo: Para una empresa productora de partes, supondremos el siguiente conjunto de esquemas de relaciones:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Parte= (nro_pte, nom_pte, color, peso, ciudad) Proveedor= (nro_prv, nom_prv, ciudad_prv) Suministro= ( nro_prv,nro_pte,cantidad_sum) La característica fundamental de este modelo de datos es que las asociaciones entre tuplas (entidades) se representan únicamente por valores de datos en columnas, sacados de un dominio común. Ejemplo: La asociación entre PROVEEDOR y SUMINISTRO se da por el campo nro_prv que debe ser igual en ambas relaciones cuando se refieren a un PROVEEDOR determinado.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Transformación Del Modelo E-R En Tablas Relacionales Si la BD se ajusta a un diagrama E-R, estas son las reglas de transformación: 1. Las entidades se representan en tablas (relaciones) y los atributos en columnas. 2. Las asociaciones 1:N se representan replicando la llave primaria de la tabla del lado 1, como columna externa en la tabla del lado muchos. A esta columna se le denomina llave foránea. 3. Las asociaciones 1:1 se representan replicando la llave primaria en una de las dos tablas como columna externa de la otra. 4. Las asociaciones M:N deben resolverse generando una tercera entidad denominada de intersección la cual tendrá como llave primaria la combinación de las llaves primarias de las entidades que intersecta, mas los atributos resultantes de la asociación, si existen. Las asociaciones 1:M resultantes se resuelven de acuerdo con la regla de representación de entidades (es decir, en tablas independientes).

Esquema diseñado por: Equipo Técnico P.A.V. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Reglas De Integridad (RI) Los datos contenidos en la base de datos deben ser correctos confiables y consistentes. Las RI se pueden ser:

1. Semánticas: En el mundo real existen ciertas restricciones que deben cumplir los elementos en él existentes; por ejemplo, una persona sólo puede tener un número de DNI y una única dirección oficial. Cuando se diseña una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es lo mismo, reflejar las restricciones existentes en el mundo real. Tienen que ser definidas por los diseñadores en el modelo entidad relación.

Reglas de negocio

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.

Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su dominio, por ejemplo EDAD >= 18 and EDAD<= 65. Una nota>=0 and nota<=5 3.

Reglas de la entidad Tipos de datos: Al momento de definir la tabla se deben definir correctamente los tipos de datos de los atributos o columnas. Permitir valores NULL

La nulabilidad de una columna determina si las filas de una tabla pueden contener un valor NULL en esa columna. Un valor NULL no es lo mismo que cero (0), en blanco o que una cadena de caracteres de longitud cero, como "". NULL significa que no hay ninguna entrada. La presencia de un valor NULL suele implicar que el valor es desconocido o no está definido. Por ejemplo, un valor NULL en la columna fecha_venta de la tabla Producto no implica que el artículo no tenga una fecha de venta final. El valor NULL significa que se desconoce la fecha o que no se ha establecido.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Restricciones UNIQUE Puede utilizar restricciones UNIQUE para garantizar que no se escriben valores duplicados en columnas específicas que no forman parte de una clave principal. Tanto la restricción UNIQUE como la restricción PRIMARY KEY exigen la unicidad; sin embargo, debe utilizar la restricción UNIQUE y no PRIMARY KEY si desea exigir la unicidad de una columna o una combinación de columnas que no forman la clave principal. En una tabla se pueden definir varias restricciones UNIQUE, pero sólo una restricción PRIMARY KEY. Además, a diferencia de las restricciones PRIMARY KEY, las restricciones UNIQUE admiten valores NULL. Sin embargo, de la misma forma que cualquier valor incluido en una restricción UNIQUE, sólo se admite un valor NULL por columna. Es posible hacer referencia a una restricción UNIQUE con una restricción FOREIGN KEY. Definiciones DEFAULT Cada columna de un registro debe contener un valor, aunque sea un valor NULL. Puede haber situaciones en las que deba cargar una fila de datos en una tabla, pero no conozca el valor de una columna o el valor ya no exista. Si la columna acepta valores NULL, puede cargar la fila con un valor NULL. Pero, dado que puede no resultar conveniente utilizar columnas que acepten valores NULL, una mejor solución podría ser establecer una definición DEFAULT para la columna siempre que sea necesario. Por ejemplo, es habitual especificar el valor cero como valor predeterminado para las columnas numéricas, o N/D (no disponible) como valor predeterminado para las columnas de cadenas cuando no se especifica ningún valor. Ejemplo fecha datetime default getdate() indica que el valor predeterminado de fecha es la fecha actual del sistema.

Regla de integridad referencial

Son reglas de integridad controladas por el DBGS Restricciones PRIMARY KEY Una tabla suele tener una columna o una combinación de columnas cuyos valores identifican de forma única cada fila de la tabla. Estas columnas se denominan claves principales de la tabla y exigen la integridad de entidad de la tabla. Puede crear una clave principal mediante la definición de una restricción PRIMARY KEY cuando cree o modifique una tabla. Una tabla sólo puede tener una restricción PRIMARY KEY y ninguna columna a la que se aplique una restricción PRIMARY KEY puede aceptar valores NULL. Debido a que las restricciones PRIMARY KEY garantizan datos únicos, con frecuencia se definen en una columna de identidad. Cuando especifica una restricción PRIMARY KEY en una tabla, Database Engine (Motor de base de datos) exige la unicidad de los datos mediante la creación de un índice único para las columnas de clave principal. Este índice también permite un acceso rápido a los datos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

cuando se utiliza la clave principal en las consultas. De esta forma, las claves principales que se eligen deben seguir las reglas para crear índices únicos. Si se define una restricción PRIMARY KEY para más de una columna, puede haber valores duplicados dentro de la misma columna, pero cada combinación de valores de todas las columnas de la definición de la restricción PRIMARY KEY debe ser única. Como se muestra en la siguiente ilustración, las columnas ProductID y VendorID de la tabla ProductVendor forman una restricción PRIMARY KEY compuesta para esta tabla. Así se garantiza que la combinación de ProductID y VendorID es única.

Cuando trabaja con combinaciones, las restricciones PRIMARY KEY relacionan una tabla con otra. Por ejemplo, para determinar los proveedores que suministran determinados productos, puede utilizar una combinación de tres elementos entre las tablas Vendedor, Production.Product y ProductVendor. Puesto que ProductVendor contiene las columnas de ProductID y VendorID, se puede obtener acceso a las tablas Product y Vendor mediante su relación con ProductVendor. Restricciones FOREIGN KEY Una clave externa (FK) es una columna o combinación de columnas que se utiliza para establecer y exigir un vínculo entre los datos de dos tablas. Puede crear una clave externa mediante la definición de una restricción FOREIGN KEY cuando cree o modifique una tabla. En una referencia de clave externa, se crea un vínculo entre dos tablas cuando las columnas de una de ellas hacen referencia a las columnas de la otra que contienen el valor de clave principal. Esta columna se convierte en una clave externa para la segunda tabla. Por ejemplo, la tabla Sales.SalesOrderHeader de la base de datos AdventureWorks tiene un vínculo a la tabla Sales.SalesPerson porque existe una relación lógica entre pedidos de ventas y personal de ventas. La columna SalesPersonID de la tabla SalesOrderHeader coincide con la columna de clave principal de la tabla SalesPerson. La

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

columna SalesPersonID de la tabla SalesOrderHeader es la clave externa para la tabla SalesPerson.

No es necesario que una restricción FOREIGN KEY esté vinculada únicamente a una restricción PRIMARY KEY de otra tabla; también puede definirse para que haga referencia a las columnas de una restricción UNIQUE de otra tabla. Una restricción FOREIGN KEY puede contener valores NULL, pero si alguna columna de una restricción FOREIGN KEY compuesta contiene valores NULL, se omitirá la comprobación de los valores que componen la restricción FOREIGN KEY. Para asegurarse de que todos los valores de la restricción FOREIGN KEY compuesta se comprueben, especifique NOT NULL en todas las columnas que participan.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

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. Actualización y borrado de registros 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? Restringir: no se permite borrar la tupla referenciada. Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena. 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? Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada. 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. Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

Otras reglas de integridad

•

Disparadores o triggers Combinan los enfoques declarativo (en la condición) y procedimental (en la acción), Pueden ser tan complejas como imponga la semántica del mundo real en cuanto a la acción, y bastantes complejas en la condición (todo lo que permite la proposición

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

lógica mediante la que se expresa la El cumplimiento de la condición dispara Son más flexibles que las restricciones de acción específica.

condición), acción,

SQL Server TechCenter. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://technet.microsoft.com/es-es/library/ms191236.aspx

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Teoría De La Normalización La primera aproximación del diccionario de datos (el diccionario de datos es la definición de los campos o atributos contenidos en las tablas y se define usando DDL), presenta ciertos problemas de redundancia, dependencia, etc. Es necesario optimizar el diseño para conservar la consistencia e integridad de los datos y a la vez optimizar el espacio de almacenamiento eliminando la redundancia. Para esto se lleva a cabo un proceso que se llama NORMALIZACIÓN y comprende varias Formas Normales. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. De esta forma la normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender, además de otras ventajas destacables como la disminución de espacio en disco.

5.1. El concepto de dependencia funcional Es el concepto más importante en el diseño de esquemas relacionales. Una dependencia funcional es una restricción entre dos conjuntos de atributos de la base de datos. Para entender el concepto vamos a hacer una serie de suposiciones: Vamos a suponer que el esquema de base de datos relacional tiene una serie de atributos A1, A2, A3, ..., An.. y que la base de datos se describe como un solo esquema de relación universal R={A1, A2, A2,....,An}; es como si tuviéramos una sola tabla, pero solo para explicar el concepto. La dependencia funcional es una restricción , que vamos a denotar como X->Y, donde X e Y son dos subconjuntos de R, sobre las posibles tuplas, registros o filas que podrían formar un ejemplar de relación en R. La restricción dice que para cualesquier dos tuplas t1 y t2 tales que el valor t1[X] = t2[X], debemos tener t1[Y] = t2[Y]; es decir, que los valores del componente Y de una tupla dependen de los valores del componente X. En otras palabras podríamos decir que los valores del componente X (Que denominaremos Miembro izquierdo) determinan de manera única los valores del componente Y (que denominaremos Miembro derecho). Así que si una restricción de R dice que no puede haber más de una tupla con un valor X, se dice que X es una clave candidata. Esto implica que para todo subconjunto de atributos Y de R X->Y. Ejemplo: Veamos la siguiente definición o esquema funcional: TERCERO {Tercero, Nombre, NSS, Apellidos, Dirección, Es_Cliente, Es_Proveedor, Fecha} Veamos las dependencias funcionales: Tercero-> Nombre. NSS ->Nombre

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Tercero -> NSS {Tercero,NSS} -> Nombre

5.2. Qué es la normalización? Se entiende por normalización la descomposición o subdivisión de una relación en dos o más relaciones para evitar la redundancia; en definitiva, que "cada hecho esté en su lugar". La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos. La normalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo, desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos más simple agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de referencia para simplificar una estructura de datos compleja. Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera.

5.3. Proceso de normalización El proceso de normalización es un estándar que consiste, básicamente, en un proceso de conversión de las relaciones entre las entidades, evitando: La redundancia de los datos: repetición de datos en un sistema. Anomalías de actualización: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales. Anomalías de borrado: pérdidas no intencionadas de datos debido a que se han borrado otros datos. Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5.4. Grados de normalización Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalización. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización. En la tabla siguiente se describe brevemente en qué consiste cada una de las reglas, y posteriormente se explican con más detalle. Regla

Primera Forma Normal (1FN)

Segunda Forma Normal (2FN)

Tercera Forma Normal (3FN)

Descripción Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos. Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando cumple lo siguiente: Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Cada columna debe tener un nombre único. Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.

Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s). Una relación se encuentra en segunda forma normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave . De acuerdo con esta definición, cada tabla que tiene un atributo único como clave, está en segunda forma normal.

Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

(A,B,C) en donde A determina a B, B determina a C entonces A determina a C.

Una relación R esta en FNBC si y solo si cada determinante es una llave candidato. Forma Normal de Boyce Codd

Cuarta forma normal

Otras formas normales

Ejemplo nombre, cargo, prima) Trabajador(cedula, Pero el cargo determina la prima Existe una dependencia de valores múltiples cuando una afinidad tiene por lo menos tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen solo del tercer atributo, en otras palabras en la afinidad R (A,B,C) existe una dependencia de valores múltiples si A determina valores múltiples de B, A determina valores múltiples de C, y B y C son independientes entre sí. Para entender mejor aún esto consideremos una afinidad (tabla) llamada estudiante que contiene los siguientes atributos: Claves, estudiante, Especialidad y Curso En la tabla anterior Clave estudiante determina valores múltiples de especialidad y clave estudiante determina valores múltiples de curso, pero especialidad y curso son independientes entre sí. Las dependencias de valores múltiples se definen de la siguiente manera: Clave ->->Especialidad y Clave->->Curso; Esto se lee "Clave multidetermina a Especialidad, y clave multidetermina a Curso Existen otras dos formas normales, la llamada quinta forma normal (5FN) que no detallo por su dudoso valor práctico ya que conduce a una gran división de tablas, pero que no pueden reconstruirse. y la forma normal dominio / clave (FNDLL) de la que no existe método alguno para su implantación.

5.5. ¿Qué tan lejos debe llevar la normalización? La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de nosotros. Si nuestra base de datos va a proveer información a un solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

exagerado. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel más alto no tenga sentido. ¿Se están dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas?. Éstas son el tipo de cosas que nosotros como diseñadores de la base de datos, necesitamos decidir, y la experiencia y el sentido común nos pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta, más bien subjetiva. Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesitamos. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales. Para complementar este tema ver video (CD de Actividades). Ejemplo Primera forma normal (1NF)

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de los campos contiene un único valor para un registro determinado. Supongamos que deseamos realizar una tabla para guardar los cursos que están realizando los alumnos de un determinado centro de estudios, podríamos considerar el siguiente diseño:

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Podemos observar que el registro de código 1 si cumple la primera forma normal, cada campo del registro contiene un único dato, pero no ocurre así con los registros 2 y 3 ya que

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

en el campo cursos contiene más de un dato cada uno. La solución en este caso es crear dos tablas del siguiente modo:

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores únicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal. Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal. Ejemplo Segunda forma normal (2NF) La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave definida. Si todos los campos dependen directamente de la clave se dice que la tabla está es segunda forma normal (2NF). Supongamos que construimos una tabla con los años que cada empleado ha estado trabajando en cada departamento de una empresa:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Tomando como punto de partida que la clave de esta tabla está formada por los campos código de empleado y código de departamento, podemos decir que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la segunda: 1. El campo nombre no depende funcionalmente de toda la clave, sólo depende del código del empleado. 2. El campo departamento no depende funcionalmente de toda la clave, sólo del código del departamento. 3. El campo años si que depende funcionalmente de la clave ya que depende del código del empleado y del código del departamento (representa el número de años que cada empleado ha trabajado en cada departamento) Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no está en segunda forma normal, la solución es la siguiente:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Podemos observar que ahora si se encuentras las tres tabla en segunda forma normal, considerando que la tabla A tiene como índice el campo Código Empleado, la tabla B Código Departamento y la tabla C una clave compuesta por los campos Código Empleado y Código Departamento. Ejemplo Tercera forma normal (3NF) Se dice que una tabla está en tercera forma normal si y solo si los campos de la tabla dependen únicamente de la clave, dicho en otras palabras los campos de las tablas no dependen unos de otros. Tomando como referencia el ejemplo anterior, supongamos que cada alumno sólo puede realizar un único curso a la vez y que deseamos guardar en que aula se imparte el curso. A voz de pronto podemos plantear la siguiente estructura:

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Estudiemos la dependencia de cada campo con respecto a la clave código: Nombre depende directamente del código del alumno. Curso depende de igual modo del código del alumno. El aula, aunque en parte también depende del alumno, está más ligado al curso que el alumno está realizando. Por esta última razón se dice que la tabla no está en 3NF. La solución sería la siguiente:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Una vez conseguida la segunda forma normal, se puede estudiar la cuarta forma normal. Ejemplo Cuarta forma normal (4NF) Una tabla está en cuarta forma normal si y sólo si para cualquier combinación clave - campo no existen valores duplicados. Veámoslo con un ejemplo:

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Comparemos ahora la clave (Figura) con el atributo Tamaño, podemos observar que Cuadrado Grande está repetido; igual pasa con Círculo Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF. La solución en este caso sería la siguiente:

Imagen basada en la dirección: http://perso.wanadoo.es/aldomartin1/noreyalre.htm Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.

Ahora si tenemos nuestra base de datos en 4NF.

ibid, pg, 23 Normalización de Bases de Datos. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm.. http://www.trucostecnicos.com/trucos/ver.php?id_art=278 Dependencia funcional e independencia, manual de la Universidad de Málaga. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://ftp.medprev.uma.es/libro/node33.htm Normalización de base de datos, Prof. Manuel Torres Remon. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.monografias.com/trabajos5/norbad/norbad.shtml

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

6. Lenguaje Sql SQL: Lenguaje de consulta estructurado, Permite definir y manipular la base de datos, este lenguaje se compone de: DDL: Lenguaje de definición de datos

6.1. Comandos DDL Comando CREATE DROP ALTER

Descripción Utilizado para crear nuevas tablas, campos e índices. Empleado para eliminar tablas e índices Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

DML: Lenguaje de manipulación de datos

6.2. Comandos DML Comando SELECT INSERT UPDATE DELETE

Descripción Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado Utilizado para cargar lotes de datos en la base de datos en una única operación. Utilizado para modificar los valores de los campos y registros especificados Utilizado para eliminar registros de una tabla de una base de datos

6.3. Cláusulas Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular. Comando FROM WHERE GROUP BY

Descripción Utilizada para especificar la tabla de la cual se van a seleccionar los registros Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar Utilizada para separar los registros seleccionados en grupos específicos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

HAVING ORDER BY

Utilizada para expresar la condición que debe satisfacer cada grupo Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

6.4. Operadores Lógicos Operador AND OR NOT

Uso Es el “y” lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas. Es el “o” lógico. Evalúa dos condiciones y devuelve un valor de verdad si alguna de las dos es cierta. Negación lógica. Devuelve el valor contrario de la expresión.

6.5. Operadores de Comparación Operador < > <> <= >= BETWEEN LIKE In

Uso Menor que Mayor que Distinto de Menor ó Igual que Mayor ó Igual que Utilizado para especificar un intervalo de valores. Utilizado en la comparación de un modelo Utilizado para especificar registros de una base de datos

6.6. Funciones de Agregado Las unciones de agregado en grupos de registros para grupo de registros. Comando AVG COUNT SUM MAX MIN

se usan dentro devolver un único

de una cláusula SELECT valor que se aplica a un

Descripción Utilizada para calcular el promedio de los valores de un campo determinado Utilizada para devolver el número de registros de la selección Utilizada para devolver la suma de todos los valores de un campo determinado Utilizada para devolver el valor más alto de un campo especificado Utilizada para devolver el valor más bajo de un campo especificado

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Unidad 4

Manipulación De Una Base De Datos Relacional Una vez diseñada y estandarizada la base de datos esta se puede implementar y manipular utilizando un DBGS, estos tienen herramientas que permiten la definición y la manipulación de la base de datos, además incluyen un lenguaje llamado el SQL (Structured Query Language) es un lenguaje de programación diseñado para almacenar, manipular y recuperar datos almacenados en bases de datos relacionales.

1. Reconocimiento Del Sistema Gestor De Bases De Datos Relaciónales Sql Server es un servidor de bases de datos. Iniciar a sql server Inicio > programas >

Clic en Enterprise Manager Ya con los objetos, vamos a abrir local, y vemos que ya existen varias bases de datos, lo que significa que existen bases de datos para el sistema y otras son modelos de ejemplos para el aprendizaje.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Este es el símbolo de la base de datos:

Desplegar la opción data transformation que son los DTS (Transformación de datos entre sistemas: entre Excel – Access, etc transforma un formato de una base de datos en otro ósea importación y exportación de datos entre diferentes bases de datos. Con un dts coge un archivo plano y lo transforma)

En manager.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Dentro del grupo de trabajo tengo un servidor (local, pero pueden existir muchos más como para cartera, contabilidad, etc) y dentro de los servidores hay varios objetos y dentro de los objetos hay database (bases de datos). Esto suple la limitante que tenia Access.

1.1. Crear Una Base De Datos Cuando se crea una base de datos, es importante comprender cómo SQL Server almacena los datos para poder calcular y especificar la cantidad de espacio en disco que hay que asignar a los archivos de datos y registros de transacciones. Aunque SQL Server automáticamente incrementa el tamaño asignado a los ficheros de bases de datos dinámicamente, para tener un rendimiento óptimo del sistema (evitar fragmentación de los ficheros), se recomienda ser "precisos" a la hora de definir el tamaño de la base de datos.

1.2. Ficheros de la base de datos Todas las bases de datos tienen un archivo de datos principal (.mdf), y uno o varios archivos de registro de transacciones (.ldf). Una base de datos también puede tener archivos de datos secundarios (.ndf). La extensión definida para cada tipo de archivos es libre, pero como buenas prácticas se suele seguir el modelo de extensiones recomendado por Microsoft (mdf, ldf, y ndf). El proceso de creación de la base de datos, consiste en hacer una copia de la base de datos model, que incluye las tablas del sistema. La ubicación predeterminada para todos los archivos de datos y registros de transacciones es C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data. La base de datos puede configurarse con tres modelos de recuperación en caso de fallo del sistema (FULL, BULK_LOGGED, y SIMPLE); evalúa cada modelo en base a las necesidades del sistema que estés implementando.

1.3. Creación de base de datos desde SQL Server 2005 Management Studio Express SQL Server Management Studio Express es la herramienta de administración incluida con SQL Server Express; la herramienta no fue incluida en la primera distribución de SQL Server Express, y se puede descargar de forma gratuita de la siguiente url: Microsoft SQL Server Management Studio Express - Community Technology Preview (CTP) November 2005: Para crear una base de datos desde SQL Server 2005 Management Studio, expande la lista de bases de datos, de la lista de instancias de SQL Server 2005 registradas, y selecciona la opción "New database":

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Deberás rellenar el nombre de base de datos, nombres lógico y físico de los archivos relacionados, y tamaño de los ficheros, así como su crecimiento:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Y deberás establecer el modo de recuperación de la base de datos; en la versión Express al crear una base de datos por defecto se establece como recuperación SIMPLE:

Para famializarte con la sintaxis del lenguaje T-SQL, te recomiendo que utilices la opción de menú script (en recuadro verde en las dos imágenes anteriores), que mostrará la instrucción T-SQL correspondiente a las operaciones que has ido configurando en las distintas opciones.

1.4. Consideraciones Dependiendo de las necesidades a cubrir del sistema de base de datos a desarrollar, deberás configurar los archivos de una forma u otra; por ejemplo, en grandes sistemas llegarás a configurar niveles de redundancia de discos (RAID), y repartirás la información de las tablas en distintos ficheros. Aunque no está soportado en la versión Express, funcionalidades del producto como Particionado de datos, llegan a ser primordiales, y es un factor a considerar desde el momento de diseño del sistema.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Por otro lado, para familiarizarte con SQL Server, recomendaría entender las opciones de configuración de base de datos que aparecen en la pestaña opciones, que aunque no son necesarias para comenzar a diseñar bases de datos SQL Server, si ayudan a comprender un poco el funcionamiento interno de SQL Server (shrink, statistics, etc.):

1.5. Tipos de datos Empezaremos por los tipos de datos. Las tablas tienen columnas, y las columnas se definen en base a un tipo de datos; los tipos de datos acotan el tipo y tamaño de la información que se guardará en una columna. La importancia de la elección de los tipos de datos reside en el almacenamiento que ocupa; para varios cientos de filas, el tamaño no es tan crucial, pero cuantas más filas se añadan a la tabla, mayor será la repercusión en el rendimiento de las operaciones de E/S. Como veremos, habrá tipos de datos en los que habrá que seleccionar el tamaño, e incluso algunos tendrán la posibilidad de ofrecer tamaño variable; vamos a analizar los más significativos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1.5.1. Tipos de datos numéricos Los tipos de datos numéricos se utilizan para guardar valores numéricos enteros, o decimales. Los dividiremos en dos grandes grupos: enteros, y decimales. Tipos de datos numéricos enteros Tipo de datos bigint int smallint tinyint bit

Intervalo

Almacenamiento

De -2^63 (-9.223.372.036.854.775.808) a 2^63-1 (9.223.372.036.854.775.807)

8 bytes

De -2^31 (-2.147.483.648) a 2^31-1 (2.147.483.647)

4 bytes

De -2^15 (-32.768) a 2^15-1 (32.767)

2 bytes

De 0 a 255

1 bytes

0,1

1 bit, mímino 1 bytes

Tradicionalmente el tipo de datos más usado es el int; el tipo de datos bigint apareció en SQL Server 2000, y es la alternativa al tipo de datos int, cuando los valores son muy grandes. Tipos de datos numéricos decimales Decimal, numeric: Tipo de datos numérico con precisión y escala fijas. decimal[ (p[ ,s] )] y numeric[ (p[ ,s] )] Números de precisión y escala fijas. Cuando se utiliza la precisión máxima, los valores permitidos están comprendidos entre - 10^38 +1 y 10^38 - 1. Numeric equivale funcionalmente a decimal p (precisión) El número total máximo de dígitos enteros que se puede almacenar, tanto a la izquierda como a la derecha del separador decimal. La precisión debe ser un valor comprendido entre 1 y la precisión máxima de 38. La precisión predeterminada es 18. s (escala)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

El número máximo de dígitos decimales que se puede almacenar a la derecha del separador decimal. La escala debe ser un valor comprendido entre 0 y p. Para especificar la escala es necesario haber especificado la precisión. Y la relación entre precisión y almacenamiento es: Precisión Almacenamiento 1-9

10-19

20-28

29-38

Money, smallmoney Tipos de datos que representan valores monetarios o de moneda.

Tipo de datos

Precisión

Almacenamiento

money

De -922,337,203,685.477,5808 a 922,337,203,685.477,5807

8 bytes

smallmoney

De - 214.748,3648 a 214.748,3647

4 bytes

Float(n), single Tipos de datos numéricos y aproximados que se utilizan con datos numéricos de coma flotante. Los datos de coma flotante son aproximados; por tanto, no todos los valores del intervalo del tipo de datos se pueden representar con exactitud. Tipo de datos

Precisión

Almacenamiento

float

De - 1,79E+308 a -2,23E-308, 0 y de 2,23E308 a 1,79E+308

Depende del valor de n (4 u 8 bytes)

real

De - 3,40E + 38 a -1,18E - 38, 0 y de 1,18E 38 a 3,40E + 38

4 bytes

1.5.2. Tipos de datos de caracteres Los tipos de datos caracter se puede definir de longitud fija y de longitud variable. Los de longitud fija son char(n) y su tamaño lo define el valor que tenga n. Por ejemplo, una columna char(15) ocupa 15 bytes.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Los de longitud variable son varchar(n), y su tamaño lo define la longitud de la columna guardada; por ejemplo una columna varchar(250), que guarda el valor "columna variable" el almacenamiento que ocupa es 16 bytes. En caso de desear valores Unicode, deberás anteponer al tipo de datos la letra n, siendo los tipos nchar, o nvarchar. La principal diferencia con los tipos de datos no-unicode, es que utilizan el doble de bytes. Por ejemplo, el texto "Tutorial", en una columna varchar(100) ocuparía 8 bytes, mientras que siendo unicode ocuparía 16 bytes. El tamaño de las columnas char, varchar, nchar, nvarchar está limitado a 8000 bytes de almacenamiento; en caso de necesitar mayor longitud puedes usar el tipo de datos varchar(max) o nvarchar(max), que es nuevo en SQL Server 2005.

1.5.3. Tipos de datos fecha Smalldatetime, datetime Son los tipos de datos utilizados para representar la fecha y la hora. El valor internamente se almacena como un valor integer, y dependiendo de la precisión utilizará 4 u 8 bytes. Tipo de datos

Precisión

smalldatetime Del 1 de enero de 1900 hasta el 6 de junio de 2079 datetime

Almacenamiento 4 u 8 bytes

Del 1 de enero de 1753 hasta el 31 de diciembre de 9999 8 bytes

El tipo de datos smalldatetime almacena las fechas y horas del día con menor precisión que datetime. El Database Engine (Motor de base de datos) almacena los valores smalldatetime como dos enteros de 2 bytes. Los dos primeros bytes almacenan el número de días después del 1 de enero de 1900. Los otros dos, almacenan el número de minutos desde medianoche. Los valores datetime se redondean con incrementos de 0,000; 0,003 o 0,007 segundos, como se muestra en la siguiente tabla. Crear tablas Las tablas son objetos que contienen la información guardada en la base de datos. Una tabla es una colección de columnas; cada columna tendrá un tipo de dato y una serie de propiedades. La información está guardada fila por fila de forma similar a lo que gráficamente representa una hoja Excel: una colección de filas por columnas. Diseñar y crear de tablas Para crear tablas podremos utilizar SQL Server 2005 Management Studio Express, o Visual Basic Express Edition; la forma es muy similar en ambas herramientas, y esta vez también utilizaremos SQL Server 2005 Management Studio Express.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Expandiendo la base de datos "DemoMSDN", vemos una lista de tipos de objetos entre las que se encuentra "tables"; pulsando el botón derecho del ratón, y selecciona "New Table" como aparecen en la siguiente imagen:

Aparecerá una ventana como la siguiente que describimos a continuación:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

En el cuadro marcado en rojo, se añaden cada una de las columnas que forman parte de la tabla a crear; se pone nombre a la columna (debe comenzar por un caracter alfabético), se selecciona el tipo de datos y precisión (ver lección anterior para más información), y se establece si la columna aceptará valores nulos o no. En el cuadro de debajo (en color azul), se podrán establecer las propiedades de cada columna de la tabla; se podrán modificar las propiedades vistas anteriormente, si la columna es calculada o no, si tiene propiedad identidad (que veremos más adelante en el capítulo), etc. A la derecha, en el cuadro verde, se podrán establecer propiedades de la tabla; como esquema al que pertenece la tabla, nombre de la tabla, descripción de la tabla, y grupo de ficheros donde se almacenará la tabla. Además toda tabla debe tener una columna o conjunto de columnas que identifique de manera única cada fila de la tabla; para ello selecciona la columna que deseas como clave primaria, y después de hacer click en el botón derecho del ratón, selecciona "Primary Key" como se muestra en la imagen (también se puede hacer sobre el botón marcado en rojo en la imagen):

A continuación, para grabar los cambios, es decir, para generar la tabla, pulsarás sobre la zona en color verde de la siguiente imagen, y seleccionarás la opción Save Clientes (que es el nombre de la tabla):

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Propiedad identity en las columnas La propiedad identity, establece que una columna numérica genere automáticamente valores consecutivos partiendo de una semilla inicial, y un incremento definido. Se suele utilizar como clave primaria, en lugar de establecer claves primarias de columnas o conjuntos de columnas muy grandes. Lo importante de esta propiedad es que "convierte" automáticamente el valor de una columna a un valor numérico siguiente al anteriormente insertado. Por ejemplo, si definimos la columna Id de la tabla clientes como identity, a la hora de insertar filas, de esa columna nos "olvidaremos" porque SQL Server lo hace por nosotros. Luego ese valor lo podremos usar como referencia principal (clave primaria), para identificar la fila insertada. Para establecer la propiedad identity, debes seleccionar la columna a la que deseas establecer la propiedad, y hacerlo desde la ventana de propiedades de columna (cuadro rojo de la siguiente imagen):

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Relacionar tablas Las tablas se relacionan entre sí; podría decirse que existe información de la fila que está guardada en varias tablas. El nexo de unión de las filas es la clave primaria en la tabla padre, y la clave primaria en la tabla hija. Por ejemplo, una relación entre clientes y pedidos; en la tabla pedidos existirá un identificador de cliente que está asociado a un identificador de cliente en la tabla clientes. La información estaría repartida como sigue: Tabla Clientes ID Nombre Apellidos ... 1

Julia

Herrera

...

Javier

Alonso

...

Tabla Pedidos IDPedido IDCliente Importe ... 1

1200

...

1300

...

12000

...

1000

...

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Fijate que el cliente 1 (Julia Herrera), tiene los pedidos del 1 al 3, y el cliente 2 el pedido 4. La información la "interpretamos" como si las filas de cliente en "embebiera dentro de la tabla pedidos: Nuestra interpretación de la relación Pedidos-Clientes IDPedido IDCliente Nombre-Cli Apellido-Cli Importe ... 1

Julia

Herrera

1200

...

Julia

Herrera

1300

...

Julia

Herrera

12000

...

Javier

Alonso

1000

...

Visto el esquema, vamos a implementar la tabla Pedidos, definiendo la clave ajena a la tabla clientes. Para ello, después de haber añadido las columnas que definen la tabla pedidos (ID, IDCliente, y Cantidad), pulsaremos en el botón habilitado para establecer relaciones, o seleccionaremos la opción "Relationships...":

Aparecerá una ventana como la que se muestra a continuación, en la que expandirás la opción "Tables and columns specifications", y pulsarás en el botón encuadrado con bordes azules, para establecer la relación entre las tablas:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

A continuación, rellenarás los combos que aparecen para establecer la relación entre las tablas clientes y pedidos (columnas ID de clientes, e IDCliente de Pedidos):

Para finalizar pulsa en aceptar, y expandes la opción "Insert and Update Expecifications", en la que se podrá especificar cómo establecer el valor de la columna en caso de que la fila padre haya sido borrada o modificada. En SQL Server 2005, se permiten dos opciones:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

No Action. Que indica que no actual, que se deja la columna como estaba. Cascade. Que se realiza la misma operación que se hizo en la fila de la tabla padre. Set Null. Que establece a nulo el valor de las columnas afectadas. Set Default. Que establece la columna a un valor por defecto.

Con un ejemplo se verá más claro; digamos que se borra el cliente 2 (Javier Alonso); al borrar al cliente, las opciones que acabamos de comentar se activarán, y actuarán según las hayamos configurado; Veamos cómo se comportaría en cada uno de los casos: No Action. El pedido se quedaría igual, es decir, el pedido número 4 se quedaría con referencia al cliente 2, que en realidad ya no existe. Cascade. Como se trataba de una operación de borrado de clientes, al borrar al cliente, también se borrarían los pedidos asociados al cliente 2; en nuestro ejemplo, el pedido número 4, se eliminaría. Set Null. Al realizar el borrado, el pedido número 4 se quedaría con identificador de cliente a un valor nulo; es decir, el pedido seguiría existiendo, pero no estaría asociado a ningún cliente. Set Default. Se establecería un valor por defecto; en nuestro caso no hemos definido ningún valor por defecto, pero podríamos establecer un valor por defecto para identificar los pedidos cuyos clientes han sido eliminados. Todas estas operaciones que hemos realizado desde las herramientas gráficas, también se pueden hacer con sentencias T-SQL; de hecho, llegará un momento en que tu experiencia será tan profunda que te resultará más sencillo realizar gran parte de las operaciones mediante sentencias T-SQL. En concreto, las palabras clave para definir este tipo de sentencias son ALTER TABLE, CREATE TABLE, CONSTRAINT, FOREIGN KEY, PRIMARY KEY.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Otras restricciones (UNIQUE, CHECK, DEFAULT) Además, existen restricciones que "acotan", limitan, o establecen el valor de una columna en ciertas condiciones. Se llaman restricciones (CONSTRAINTS), y forman parte del estandard SQL-99. Estas restricciones que vamos a ver son: restricción UNIQUE, restricción CHECK, y restricción DEFAULT. Restricción UNIQUE La restricción UNIQUE establece que el valor de cada columna de una fila sea único, Por ejemplo, en la tabla clientes podemos tener una clave primaria como ID, y además tener una columna NIF que establecemos que sea única: lo que internamente implementa SQL Server, es que cada vez que se intente hacer una modificación, o inserción de un valor para esa columna, antes de realizar la operación, se asegura que el nuevo/modificado valor es único en el conjunto de filas de la tabla. La restricción UNIQUE se implementa en T-SQL con la palabra clave UNIQUE; por ejemplo, si queremos que la columna Nombre de la tabla Clientes sea única, podríamos ejecutar el siguiente código T-SQL: ALTER TABLE dbo.Clientes ADD CONSTRAINT RestriccionNombreUnico UNIQUE (Nombre). Restricción CHECK La restricción CHECK establece que el valor de la columna se ajuste a ciertas condiciones. Se define para limitar el valor que pueda tener la columna; por ejemplo, se puede definir que la columna Importe sea de un valor positivo mayor que cero. SQL Server, se encargará de "validar" el valor que tendrá la columna cuando se intente hacer una modificación, o inserción de un valor para esa columna. En caso de que el valor no cumpla la restricción, se generará una excepción y se cancelará la operación en curso. La restricción CHECK se implementa en T-SQL con la palabra clave CHECK; por ejemplo, si queremos que la columna Cantidad de la tabla Pedidos sea un valor mayor que cero, podríamos ejecutar el siguiente código T-SQL: ALTER TABLE dbo.Pedidos ADD CONSTRAINT RestriccionCantidad CHECK (Cantidad>0). Restricción DEFAULT La restricción DEFAULT establece el valor para una columna cuando no se ha especificado valor en la sentencia de inserción. SQL Server, comprobará si la sentencia de inserción establece un valor para la columna, y en caso negativo, establecerá el valor por defecto.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

La restricción DEFAULT se implementa en T-SQL con la palabra clave DEFAULT; por ejemplo, si queremos añadir una columna Importe a la tabla Pedidos, y su valor por defecto sea cero, podríamos ejecutar el siguiente código T-SQL: ALTER TABLE dbo.Pedidos ADD Importe DEFAULT (0). Creación de índices Los índices son "estructuras" alternativa a la organización de los datos en una tabla. El propósito de los índices es acelerar el acceso a los datos mediante operaciones físicas más rápidas y efectivas. Para entender mejor la importancia de un índice pongamos un ejemplo; imagínate que tienes delante las páginas amarillas, y deseas buscar el teléfono de Manuel Salazar que vive en Alicante. Lo que harás será buscar en ese pesado libro la población Alicante, y guiándote por la cabecera de las páginas buscarás los apellidos que empiezan por S de Salazar. De esa forma localizarás más rápido el apellido Salazar. Pues bien, enhorabuena, has estado usando un índice. Pues el objetivo de definir índices en SQL Server es exactamente para conseguir el mismo objetivo: acceder más rápido a los datos. Consideraciones para usar índices

Columnas selectivas Columnas afectadas en consultas de rangos: BETWEEN, mayor que, menor que, etc. Columnas accedidas "secuencialmente" Columnas implicadas en JOIN, GROUP BY Acceso muy rápido a filas: lookups

1.6. Ejemplo: /*Crear índice único*/ CREATE UNIQUE INDEX nom_indce ON nom_tabla(campo) /*Crear índice con duplicado*/ CREATE INDEX nom_indce ON nom_tabla(campo) /*borrar indice*/ DROP INDEX nom_tabla. Nom_indice

Ibid, pg,7 Microsoft SQL Server 2005, Express edition, Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.desarrollaconmsdn.com/msdn/CursosOnline/Curso_SQL_Server/inde x.html

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Identificar Las Sentencias De DDL Y DML 2.1. DDL Comando CREATE DROP ALTER

Descripción Utilizado para crear objetos como nuevas tablas, campos e índices Empleado para eliminar objetos como tablas e índices Utilizado para modificar objetos como las tablas agregando campos o cambiando la definición de los campos.

2.2. DML. Cláusula SELECT FROM WHERE GROUP BY HAVING ORDER BY

Descripción Utilizada para especificar los campos y datos que se van a mostrar Utilizada para especificar la tabla de la cual se van a seleccionar los registros Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar Utilizada para separar los registros seleccionados en grupos específicos Utilizada para expresar la condición que debe satisfacer cada grupo Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

2.3. Operadores Lógicos Uso

Operador AND OR NOT

Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas. Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdero si alguna de las dos es cierta. Negación lógica. Devuelve el valor contrario de la expresión.

2.4. Operadores De Comparación Operador < Menor que > Mayor que <> Distinto de

Uso

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

<= 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 Durante la primera parte de la lección se introducirán distintas cláusulas que a pesar de estar en la sección de consultas de selección, también serán válidas para sentencias de modificación; por ejemplo, dentro de una operación de borrado se podrán usar cláusulas JOIN, WHERE, TOP, etc.

2.5. Consultas de selección Selección de columnas y cláusula FROM Cláusula WHERE Cláusula JOIN Cláusula GROUP BY Cláusula TOP Cláusula Having Cláusula Order by

2.6. Consultas de modificación Sentencia INSERT Sentencia UPDATE Sentencia DELETE

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Utilizar Adecuadamente El Sql Para La Implementación Y Manipulación De Las Bases De Datos Para Casos Reales Del Medio Que Nos Rodea. En esta lección, conocerás los conceptos básicos para poder realizar, consultar y modificar la base de datos utilizando comandos sql. Ejemplo de una base de datos creada por medo de comandos /* Crear la base de datos*/ create database Construccion /* activa la base de datos construccion*/ use Construccion /* Crear tabla oficio mirar el comando abajo*/ create table tblOficio(Tipo_Oficio varchar(30), Bonificacion int, check(Bonificacion >= 30000 and Bonificacion <= 80000), Horas_Semana int, check(Horas_Semana >= 30 and Horas_Semana <= 60), Primary key (Tipo_Oficio)) /*Crear tabla Trabajador*/ create table tblTrabajador(Cedula int, Nombre varchar(50) not null, Valor_Hora int, /*check es el comando que se utiliza para hacer las validaciones*/ check(Valor_Hora >= 7000 and Valor_Hora <= 20000), Tipo_Oficio varchar(30), primary key (Cedula), foreign key (Tipo_Oficio)references tblOficio(Tipo_Oficio)) /*Crear tabla Area*/ create table tblArea(Cod_Area varchar(10), Nom_Area Varchar(30), Estrato int,

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

check(Estrato >= 1 and Estrato <= 7), primary key (Cod_Area)) /*Crear tabla edificio*/ create table tblEdificio(Iden_Edif int, Direccion varchar(30), Tipo varchar (30), Calidad int, check (Calidad >= 1 and Calidad <= 5), Categoria int, check(Categoria >= 1 and Calidad <= 5), Cod_Area varchar (10) primary key (Iden_Edif), foreign key(Cod_Area)references tblArea(Cod_Area)) /*Crear tabla Asignar*/ create table tblAsignar(Cedula int, Iden_Edif int, Fecha_I datetime, Num_Dias int, check (Num_Dias > 0), Primary key(Cedula,Iden_edif), foreign key(Cedula) references tbltrabajador(cedula), foreign key(Iden_edif) references tblEdificio(Iden_Edif))

/* insertamos datos en cada tabla*/ Insert Insert Insert Insert Insert

into into into into into

tbloficio tbloficio tbloficio tbloficio tbloficio

values('Decorador',30000,35) values('Albañil',35000,37) values('Carpintero',31000,40) values('Electrico',35000,35) values('Arquitecto',40000,30)

Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert

into into into into into into into into into into into into

tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador tbltrabajador

values(1235,'Annie',12500,'Electrico') values(1311,'Roberto',15750,'Decorador') values(1412,'Carlos',13700,'Decorador') values(1415,'Lina',12500,'Decorador') values(1418,'Pedro',10000,'Carpintero') values(1520,'Luis',11750,'Electrico') values(1525,'Juan',20000,'Arquitecto') values(2920,'Raul',10000,'Carpintero') values(3001,'Gabriel',15500,'Decorador') values(3231,'Alvaro',17400,'Decorador') values(4446,'Mario',8200,'Albañil') values(8520,'Bernardo',8500,'Albañil')

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Insert Insert Insert Insert

into into into into

tblarea tblarea tblarea tblarea

values('a10','Sur',2) values('a11','Sur',4) values('a12','Norte',3) values('a13','Norte',2)

Insert Insert Insert Insert Insert Insert Insert Insert

into into into into into into into into

tbledificio tbledificio tbledificio tbledificio tbledificio tbledificio tbledificio tbledificio

values(111,'calle1213','Oficina',3,2,'a10') values(210,'calle1222','Oficina',4,3,'a10') values(215,'calle1215','Comercio',5,3,'a11') values(312,'calle1313','Oficina',5,2,'a13') values(435,'calle1513','Comercio',2,4,'a13') values(460,'calle1263','Almacen',4,4,'a12') values(520,'calle1223','Residencia',3,5,'a10') values(820,'calle1245','Almacen',3,5,'a10')

Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert Insert

into into into into into into into into into into into into into into into

tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar tblasignar

values(1235,111,'02/02/02',25) values(1235,210,'01/03/02',5) values(1235,520,'02/02/02',25) values(1235,820,'01/03/02',5) values(1235,215,'02/07/02',10) values(1235,312,'02/02/02',10) values(1235,435,'01/02/04',22) values(1235,460,'02/02/05',21) values(1412,210,'02/02/02',22) values(1412,312,'02/02/02',14) values(1418,435,'02/02/02',23) values(1418,460,'02/02/02',10) values(3231,312,'02/02/02',25) values(3231,111,'02/02/02',13) values(4446,111,'02/02/02',18)

Este es el digrama correspondiente a la base de datos que acbamos de crear.

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

Ya podemos manipular la base de datos

3.1. Consultas de Selección En esta lección veremos mecanismos para recuperar información de la base de datos. Veremos cómo elegir las columnas de las tablas a recuperar, y cómo aplicar distintos tipos de cláusulas como WHERE, JOIN, GROUP BY, y TOP. Además veremos dos novedades de la versión 2005 de SQL Server: funciones de Ranking, en las que se devuelve la posición relativa de las filas respecto al conjunto total, y Expresiones de tablas comunes que son una nueva funcionalidad para implementar consultas de una forma si cabe más sencilla, y a la ver aporta la posibilidad de realizar consultas recursivas que hasta la versión 2000 no era posible.

3.2. Selección de columnas y cláusula FROM Usando la cláusula FROM cuáles son las tablas, vistas, funciones, tablas derivadas o expresiones de tablas comunes que se utilizan en la instrucción SELECT. A su vez, se deberá indicar las columnas a recuperar de la consulta. Si se quiere recuperar todas las columnas se puede usar el comodín * (asterisco), aunque deberemos ser cuidadosos con ello.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Como recomendación, deberás intentar ser lo más selectivo posible en las columnas a incluir en la cláusula SELECT. ¿Por qué razón? ¿Recuerdas la estructura de los índices? Si deseamos todas las columnas de una tabla, estaremos "forzando" a SQL Server a acceder al nivel de datos de las páginas (recuerda: abajo del todo), y estaremos limitando la efectividad de los índices diseñados en las tablas. El contrapunto de éste comentario es la parte de desarrollo, si generamos código "genérico" que recupera todas las columnas porque las columnas serán necesarias unas veces sí y otras no, estaremos penalizando el rendimiento del servidor SQL Server Express pero estaremos ganando tiempo de desarrollo... Para ejecutar una consulta desde SQL Server 2005 Management Studio Express, conectaremos a la base de datos DemoMSDN, desde una de las opciones marcada en la siguiente imagen en recuadro rojo:

A continuación deberás escribir el siguiente texto para rellenar unas cuantas filas en la tabla clientes (veremos luego la sentencia INSERT): INSERT Clientes SELECT 'Julia Herrera', 'Alicante'; INSERT Clientes SELECT 'Javier Álvarez', 'Madrid';

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

100

Para ello, copia el texto en la ventana de texto, y pulsa F5, o el botón Execute para ejecutar la sentencia. Borra el texto de la sentencia, y escribe el siguiente texto: SELECT Id AS Identificador, Nombre FROM Clientes; Ejecuta la instrucción y verás como resultado todas las filas de la tabla Clientes. Fíjate que la columna de base de datos Id, ahora parece que se llama Identificador. Esto es un alias de columna; habrá ocasiones en las que necesites personalizar el nombre de columna que se muestra. Desde Management Studio, también se puede ver la información de la tabla de forma similar a como se presenta en Access; para ello, deberás seleccionar la tabla que quieres editar, botón derecho del ratón, y elegir la opción "Open Table" como aparece en la siguiente imagen:

Y como resultado tendremos:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

101

Deberás tener cuidado con abrir tablas muy grandes, porque el proceso de carga es más costoso cuanto mayor sea el tamaño de la tabla. Sin embargo, en la versión 2005 de las herramientas administrativas, tenemos la posibilidad de cancelar consultas mientras se está realizando la petición; fíjate en el botón marcado en color rojo en la siguiente imagen; pulsando dicho botón se solicita al servidor que se cancele la consulta.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

102

Claúsula WHERE La cláusula WHERE se utiliza para aplicar filtros al conjunto de resultados; para ello existen operadores lógicos AND, OR, NOT, EXISTS con los condicionantes <, >, =, y BETWEEN. No hay límite para el número de condiciones a establecer. El orden de prioridad de los operadores lógicos es NOT, seguido de AND y OR. Se pueden utilizar paréntesis para suplantar esta prioridad en una condición de búsqueda. Cuando se necesita recuperar información de más de una tabla, se suele especificar cuáles son las filas coincidentes entre ambas tablas (columnas Clave Ajena / Clave Primaria que vimos en la lección anterior). Para ello, hay una serie de operadores que condicionan dicho filtro. INNER JOIN Específica que se devuelvan todos los pares de filas coincidentes. Las filas no coincidentes se descartan del resultado. Si no se especifica ningún tipo de combinación, éste es el tipo por defecto. FULL [ OUTER ] JOIN Especifica que una fila de la tabla de la derecha o de la izquierda, que no cumpla la condición de combinación, se incluya en el conjunto de resultados y que las columnas que correspondan a la otra tabla se establezcan en NULL. LEFT [ OUTER ] JOIN Especifica que todas las filas de la tabla izquierda que no cumplan la condición de combinación se incluyan en el conjunto de resultados, con las columnas de resultados de la otra tabla establecidas en NULL, además de todas las filas devueltas por la combinación interna. RIGHT [OUTER] JOIN Especifica que todas las filas de la tabla derecha que no cumplan la condición de combinación se incluyan en el conjunto de resultados, con las columnas de resultados de la otra tabla establecidas en NULL, además de todas las filas devueltas por la combinación interna. ON <search_condition> Especifica la condición en la que se basa la combinación; se puede referenciar más de una columna, por ejemplo, tablas con claves primarias compuestas. Un ejemplo de consulta podría ser el siguiente: SELECT sh.SalesOrderID, sh.OrderDate, sh.CustomerID, sd.OrderQty, sd.ProductID, sd.UnitPrice FROM Sales.SalesOrderHeader sh INNER JOIN Sales.SalesOrderDetail sd ON sh.SalesOrderID = sd.SalesOrderID Claúsula GROUP BY El lenguaje T-SQL permite devolver la información agregada usando la cláusula GROUP BY; los condicionantes de la agregación se colocan después de la cláusula. Existen las siguientes funciones de agregado: AVG, MIN, CHECKSUM, SUM, CHECKSUM_AGG, STDEV, COUNT, STDEVP, COUNT_BIG, VAR,

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

103

GROUPING, VARP, MAX. Por ejemplo, la siguiente sentencia T-SQL devolvería la cantidad de productos pedidos por cliente en la base de datos MSDN: SELECT Id, COUNT(*) AS Cantidad FROM Pedidos GROUP BY Id Claúsula having: Selecciona o filtra grupos Por ejemplo, la siguiente sentencia T-SQL devolvería la cantidad de productos pedidos por cliente mayor que 5 en la base de datos MSDN: SELECT Id, COUNT(*) AS Cantidad FROM Pedidos GROUP BY Id Having COUNT (*)>5 Cláusula TOP (n) [PERCENT] Cuando se necesita recuperar los n primeros elementos que cumplen una condición, se puede utilizar la función TOP. La función TOP tiene un argumento que puede representar un número o un porcentaje. La única forma de garantizar que la sentencia TOP devuelva los n primeros elementos que cumplen una condición es usando la cláusula ORDER BY. Además, SQL Server 2005, incorpora nuevas funciones de RANKING que devuelven posiciones relativas de las filas; las funciones son RANK, DENSERANK, TILE , y NTILE. Aprovechando la consulta anterior, un ejemplo de CTE podría ser el siguiente: WITH PedidosAgrupados (Id, Cantidad) AS ( SELECT Id, COUNT(*) AS Cantidad FROM Pedidos GROUP BY Id ) SELECT Id, Nombre FROM Clientes INNER JOIN PedidosAgrupados ON Clientes.Id = PedidosAgrupados.I

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

104

3.3. Consultas de modificación Sentencia INSERT La sentencia INSERT, inserta filas en una tabla; tiene dos formatos: INSERT INTO <tabla> VALUES ( <lista de columnas> ) En la que se insertan la lista de valores en una tabla; corresponde a una inserción de una fila en la tabla. INSERT INTO <tabla> <sentencia select> Donde la sentencia select será un conjunto de filas que se insertará en la tabla destino. Cuando una de las columnas de la tabla tenga establecidas la propidade IDENTITY, no será necesario especifica el valor de la columna porque SQL Server automáticamente lo hará por nosotros. En realidad, si se intenta insertar un valor, se generará una excepción porque la propiedad IDENTITY, no admite especificar valores para las columnas a menos que se use la opción SET IDENTITY_INSERT. La sentencia INSERT se puede utilizar en combinación con las expresiones de tablas comunes; adicionalmente, existe una opción (OUTPUT), que devuelve Cuando una de las columnas de la tabla tenga establecidas la propidade IDENTITY, no será necesario especifica el valor de la columna porque SQL Server automáticamente lo hará por nosotros. En realidad, si se intenta insertar un valor, se generará una excepción porque la propiedad IDENTITY, no admite especificar valores para las columnas a menos que se use la opción SET IDENTITY_INSERT. Sentencia UPDATE, y DELETE La sentencia UPDATE/DELETE, actualizan/borran filas de una tabla. Normalmente se le aplican filtros a la sentencia para que filtre las filas que se van a modificar. Se puede hacer la operación UPDATE/DELETE de dos formas, que explicaremos con un ejemplo: DELETE Sales.SalesOrderDetail WHERE SalesOrderID = 3443 En el que se borran las filas de la tabla Sales.SalesOrderDetail cuyo identificador es el 3443. La otra posibilidad es hacer la operación con un JOIN (no todos los gestores de bases de datos lo permiten); el ejemplo sería el siguiente: UPDATE t SET AcumuladoImporte = t2.SumaImporte FROM TablaAcumulados t INNER JOIN (

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

105

SELECT Pedidos.Id, SUM (LineasPedido.Importe) AS SumaImporte FROM Pedidos JOIN LineasPedido ON Pedidos.Id = LineasPedido.Id Pedidos.Fecha BETWEEN '20050101' AND '20060101' GROUP BY Pedidos.Id ) t2 ON t.Id = t2.Id WHERE Fecha BETWEEN '20050101' AND '20060101'

Para leer esta consulta es mejor que empieces por el final; mira la consulta que representa el alias t2: obtiene los en importe total de cada pedido del año 2005. A continuación, ese resultado se va a cruzar (JOIN) con la tabla TablaAcumulados para actualizar la columna Acumulado pedidos, reemplazándolo por el valor de SumaImporte de la consulta anterior. Antes de aplicarlo, deberá acotar la actualización a los pedidos realizados en el año 2005.

3.4. Ejemplos de consulta de selección en la base de datos construcción /*distinct: Mostra los tipos de oficios de los trabajadores */ SELECT DISTINCT tipo_oficio FROM tbltrabajador /*Hallar el total el maximo de los valores hora*/ SELECT SUM(valor_hora) AS total, MAX(valor_hora) AS maximo FROM tbltrabajador /*Hallar los nombres de los trabajadores que tienen un valor hora mayor que 10000*/ select nombre from tbltrabajador where valor_hora>10000 /*HALLAR EL NOMBRE DEL TRABAJADOR CON EL VALOR HORA AUMENTADO EL 3%*/ SELECT NOMBRE,valor_hora + valor_hora * 0.3 AS PORCENTAJE FROM tbltrabajador /*Hallar los nombres de los trabajadores que tienen un valor hora entre 10000 y 30000*/ SELECT nombre, valor_hora FROM tbltrabajador WHERE (valor_hora BETWEEN 10000 AND 30000)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

106

/* Hallar el nombre del trabajador que el nombre tenga la cadena ar en el nombre*/ select * from tbltrabajador where nombre like '%ar%' /*Hallar la cantidad de trabajadores por cada oficio*/ select tipo_oficio,count(*)as total from tbltrabajador group by tipo_oficio /*hallar el total de dias asignado a cada trabajador si este es mayor que 20*/ SELECT cedula, SUM(num_dias) AS total FROM tblasignar GROUP BY cedula HAVING (SUM(num_dias) > 20) /*Hallar los nombres de los trabajadores y el numero de dias asignado si es mayor que 15*/ SELECT tbltrabajador.nombre, tblasignar.num_dias FROM tbltrabajador INNER JOIN tblasignar ON tbltrabajador.cedula =tblasignar.cedula WHERE tblasignar.num_dias > 15 /*Hallar el tipo la direccion y la fecha que se inicio*/ SELECT tbledificio.tipo,tbledificio.direccion,asignacion.fecha_inicio FROM tblasignar INNER JOIN tbledificio ON asignacion.iden_edif = tbledificio.iden_edif WHERE tbledificio.tipo = 'oficina' /*hallar el nombre de los trabajadores y la bonificación si esta es mayor que 15000*/ Select tbltrabajador.nombre from tbltrabajador inner join tbloficio on tbltrabajador.tipo_oficio=tbloficio.tipo_oficio where oficio.bonificacion>15000 /*Hallar la cantidad de trabajadores por oficio con la bonificación correspondiente*/ select tbltrabajador.tipo_oficio,tbloficio.bonificacion,count(*)as total from tbltrabajador inner join tbloficio on tbltrabajador.tipo_oficio=tbloficio.tipo_oficio group by tbltrabajador.tipo_oficio,tbloficio.bonificacion /*Hallar la cantidad de trabajadores por oficio con la bonificacion correspondinte Mostrar si la cantidad de trabajadores es mayor que 2*/ select tbltrabajador.tipo_oficio,tbloficio.bonificacion,count(*)as total

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

107

from tbltrabajador inner join tbloficio on tbltrabajador.tipo_oficio=tbloficio.tipo_oficio group by tbltrabajador.tipo_oficio,tbloficio.bonificacion having count(*)>2 /*Hallar los trabajadores que son decoradores o trabajan en los edificios 435*/ select cedula from tbltrabajador where tipo_oficio in('decorador') union all (select cedula from tblasignar where id_edificio in ('435')) /*Hallar el número de trabajadores por oficio y mostrar si número de trabajadores por oficio está entre 1 y 2*/ select tbltrabajador.tipo_oficio,count(*) as numero_dias from tbloficio inner join tbltrabajador on Tbloficio.tipo_oficio = Tbltrabajador.tipo_oficio group by Tbltrabajador.tipo_oficio having count(*) between 1 and 2 /*Hallar el nombre y el total de dias asignado a cada trabajador mostrar si el total de días Es mayor que el mínimo valor de num_horas*/ SELECT tblasignar.cedula,tbltrabajador.nombre,sum(num_dias) FROM tblasignar inner join Tbltrabajador on tblasignar.cedula=Tbltrabajador.cedula GROUP BY tblasignar.cedula,tbltrabajador.nombre having sum(num_dias)> (select min(num_horas) from tbloficio) /*Consulta tres tablas*/ SELECT tbltrabajador.*, tbledificio.* FROM tbltrabajador INNER JOIN asignacion ON tbltrabajador.cedula = tblasignar.cedula INNER JOIN tbledificio ON tblasignar.iden_edif =tbledificio.iden_edif WHERE tbltrabajador.valor_hora > 10000 /*Consulta con dos tablas y having*/ SELECT tblasignar.iden_edif, tbledificio.direccion, tbledificio.tipo,tbledificio.calidad, SUM(dbo.asignacion.num_dias) AS total FROM tblasignar INNER JOIN tbledificio ON tblasignar.iden_edif = tbledificio.iden_edif

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

108

GROUP BY tblasignar.iden_edif, tbledificio.direccion, dtbledificio.tipo, tbledificio.calidad HAVING (SUM(tbl.asignacion.num_dias) BETWEEN 20 AND 50) /*Hallar el nombre los nombres de los trabajadores que tienen un valor hora mayor que el Valor hora de Nelson fernando o Gabriel*/ SELECT nombre FROM tbltrabajador where valor_hora>all (select valor_hora from tbltrabajador where nombre in('nelson','fernando','gabriel')) /*Mostrar los nombres de los trabajadores que tienen un número e días asignado mayor que 20*/ SELECT nombre FROM tbltrabajador WHERE (NOT EXISTS (SELECT * FROM tblasignar WHERE tbltrabajador.cedula = tblasignar.cedula AND num_dias > 20)) /*Hallar el nombre y valor hora de los trabajadores asignados a algún edificio*/ SELECT nombre,valor_hora FROM tbltrabajador where cedula in (select cedula from tblasignar) /*hallar el nombre y valor hora de los trabajadores que no están asignados a ningún edificio*/ SELECT nombre,valor_hora FROM tbltrabajador where cedula not in (select cedula from tblasignar) /*TODAS LAS CLAUSULAS Hallar los nombres de los trabajadores que tienen una bonificación mayor que 30000 y tienen más de un edificio asignado ordenado por nombre.*/ SELECT tbltrabajador.nombre,count(*) as total,tbloficio.bonificacion from tbloficio inner join tbltrabajador on tbloficio.tipo_oficio=tbltrabajador.tipo_oficio inner join tblasignar on tbltrabajador.cedula=tblasignar.cedula where tbloficio.bonificacion>30000

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

109

group by tblasignar.cedula,tbltrabajador.nombre,tbloficio.bonificacion having count(*)>1 order by nombre /*Hallar */ SELECT FROM WHERE

los nombres de los trabajadores que no se han asignado a ningún edificio nombre tbltrabajador (NOT EXISTS (SELECT FROM WHERE

* tblasignar tbltrabajador.cedula = tblasignar.cedula ))

/*Hallar los datos de los trabajadores y los datos de los edificios en que trabajan si el valor hora es mayor que 10000*/ select tbltrabajador.*,tbledificio.* from tbltrabajador inner join tblasignar on tbltrabajador.cedula=tblasignar.cedula inner join tbledificio on tblasignar.iden_edif=tbledificio.iden_edif where tbltrabajador.valor_hora>10000 /*Subconsultas hallar los nombres de los trabajadores que ganan más que fernando o raul*/ select nombre,valor_hora from tbltrabajador where valor_hora>all (select valor_hora from tbltrabajador where nombre in('fernando','raul')) /*Consulta para los trabajadores que tienen todos los edificios asignados.*/ SELECT FROM WHERE

* .tbltrabajador (cedula IN (SELECT cedula FROM tblasignar GROUP BY tblasignar.cedula HAVING COUNT(*) = (SELECT COUNT(*) FROM tbledificio))) Hallar los datos de los trabajadores y los datos de los edificios en que trabajan si el valor hora es mayor que 10000 select tbltrabajador.*,tbledificio.*

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

110

from tbltrabajador inner join tblasignar on tbltrabajador.cedula=tblasignar.cedula inner join tbledificio on tblasignar.iden_edif=tbledificio.iden_edif where tbltrabajador.valor_hora>10000

ibid, pg, 7

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

111

4. Procedimientos almacenados Los procedimientos almacenados (stored procedures) no son más que una sucesion ordenada de instrucciones T-SQL que pueden recibir y devolver parametros provistos por el usuario y se pueden guardar en el servidor con un nombre, para luego poder invocarlos y ejecutarlos. En esta nueva versión (2005), tambien es posible utiliza procedimientos almacenados usando CLR. Un procedimiento almacenado CLR es una referencia a un método de un ensamble de .NET Framework que puede aceptar y devolver parámetros suministrados por el usuario.

4.1. Algunas de las ventajas de usar procedimientos almacenados Compilación: La primera vez que se invoca un procedimiento almacenado, el motor lo compila y a partir de ahí, se sigue usando la versión compilada del mismo, hasta que se modifique o se reinicie el servicio de SQL. Esto hace que tengan un mejor rendimiento que las consultas directas que usan cadenas con instrucciones T-SQL, que el motor compila cada vez que se invoca. Automatización: Si tenemos un conjunto de instrucciones T-SQL que queremos ejecutar en un orden, los stored procedures son el espacio ideal para hacerlo. Administración: Si hacemos buen uso de los procedimientos almacenados, muchas veces algún cambio en nuestra aplicación, solo implica modificar un stored procedure y no toda la aplicación. Si nuestra aplicación llama a los stored procedures, con solo cambiarlo en el servidor, ya tenemos todo funcionado sin la necesidad de actualizar la aplicación en todos los equipos cliente. Seguridad: Otra ventaja que tienen es que permiten aplicar un esquema de seguridad más potente, haciendo que los usuarios que usen nuestra aplicación, solo tengan permisos para ejecutar procedimientos almacenados y no a todos los objetos de la base. De esta forma si un hacker encuentra una vulnerabilidad (SQL Injection) en nuestra aplicación, no podrá explotarla ejecutando comandos SQL directamente sobre la base, ya que el usuario con el cual se ejecuta la aplicación solo tiene derecho a la ejecución de los procedimientos almacenados en la base de datos. Programabilidad: Los procedimientos almacenados admiten el uso de variables y estructuras de control como IF, Bucles, Case, etc.. además de el manejo de transacciones, que permiten que los stored procedures sean aplicables para escribir lógica del negocio en los mismos. Depende el modelo de programación que se utilice esto puede ser tanto una buena práctica como una mala práctica, pero la posibilidad de incluir las reglas del negocio en los mismos existe. Como explicábamos más arriba a partir de esta versión de SQL (2005), podemos utilizar CLR esto es (cualquier leguaje .NET como C# o Visual Basic) para escribir los stored procedures (además del tradicional T-SQL). Tráfico de Red: Pueden reducir el tráfico de la red, debido a que se trabaja sobre el motor (en el servidor), y si una operación incluye hacer un trabajo de lectura primero y en base a eso realizar algunas operaciones, esos datos que se obtienen no viajan por la red.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

112

4.2. Crear procedimientos almacenados Para crear un procedimiento almacenado es necesario ejecutar la instrucción CREATE PROCEDURE, como se muestra en el ejemplo: CREATE PROCEDURE Clientes_GetAll AS SELECT Id, Nombre FROM dbo.Clientes Si el procedimiento almacenado ya existe se debe usar la instrucción ALTER PROCEDURE, de la misma manera que si se estuviera creando. En el ejemplo, el stored procedure devuelve todos los registros de la tabla Clientes. La creación de procedimientos almacenados basados en .NET Framework lo veremos en la lección 4 del módulo 4 (Conceptos avanzados -- Integración del CLR).

4.3. Ejecutar procedimientos almacenados La ejecucion de los procedimientos almacenados es muy simple. Desde T-SQL hay que utilizar la instrucción EXEC, para ejecutar los dos procedimientos almacenados que creamos arriba deberia escribirse esto: EXEC Clientes_GetAll ¿Y cómo se haría la llamada desde una aplicación .NET?; para ello deberemos definir un objeto conexión que conecta a la base de datos, y un objeto command que ejecute el comando: 'Creamos una nueva conexion. Dim myConn As SqlClient.SqlConnection = New SqlClient.SqlConnection("Data Source=(localhost)\SQLEXPRESS;Initial Catalog=DemoMSDN;Integrated Security=True") 'Creamos un nuevo comando Dim myComm As SqlClient.SqlCommand = New SqlClient.SqlCommand() 'Le asignamos la conexion. myComm.Connection = myConn 'especificamos que el comando es un stored procedure myComm.CommandType = CommandType.StoredProcedure

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

113

'y escribimos el nombre del stored procedure a invocar myComm.CommandText = "Clientes_GetAll" 'Creamos un nuevo DataAdapter con nuestro comando. Dim myDA As SqlClient.SqlDataAdapter = New SqlClient.SqlDataAdapter(myComm) 'Creamos un dataset para soportar los datos devueltos por el stored procedure Dim ClientesDs As DataSet = New DataSet 'Pedimos al Data Adapter que llene el dataset (Esto llama a nuestro comando) myDA.Fill(ClientesDs) 'Y lo mostramos por pantalla For Each row As Data.DataRow In ClientesDs.Tables(0).Rows Console.WriteLine(row!Id.ToString() + " " + row!Nombre) Next

4.4. Argumentos en procedimientos almacenados Los procedimientos almacenados pueden recibir y devolver datos a quien lo llame. Supongamos que ahora necesitamos obtener una sola categoría y no todas como el ejemplo anterior. Podemos crear un nuevo stored procedure llamado Clientes_GetOne que reciba como parámetro el Id y devuelva solo ese registro. CREATE PROCEDURE Clientes_GetOne @Id int AS SELECT Id, Nombre FROM dbo.Clientes WHERE Id = @Id Como se puede ver, ahora este stored procedure espera un parámetro que luego se usa para hacer la consulta en el select. Para llamar a este store procedure se usa la misma sintaxis pero solo agregando el valor del parámetro. (En este caso, queremos obtener el registro cuyo Id = 4). EXEC Clientes_GetOne 4

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

114

4.5. Desde ADO.NET

'Creamos una nueva conexion. Dim myConn As SqlClient.SqlConnection = New SqlClient.SqlConnection("Data Source=(localhost)\SQLEXPRESS;Initial Catalog=DemoMSDN;Integrated Security=True") 'Creamos un nuevo comando Dim myComm As SqlClient.SqlCommand = New SqlClient.SqlCommand() 'Le asignamos la conexion. myComm.Connection = myConn 'especificamos que el comando es un stored procedure myComm.CommandType = CommandType.StoredProcedure 'y escribimos el nombre del stored procedure a invocar myComm.CommandText = "Clientes_GetOne" 'Creamos un nuevo parámetro Dim myParam As SqlClient.SqlParameter = New SqlClient.SqlParameter() myParam.ParameterName = "@Id" myParam.SqlDbType = SqlDbType.Int myParam.Value = 4 'Y se lo agregamos a la colección de parametros del comando myComm.Parameters.Add(myParam) 'Creamos un nuevo DataAdapter con nuestro comando. Dim myDA As SqlClient.SqlDataAdapter = New SqlClient.SqlDataAdapter(myComm) 'Creamos un dataset para soportar los datos devueltos por el stored procedure Dim ClientesDs As DataSet = New DataSet 'Pedimos al Data Adapter que llene el dataset (Esto llama a nuestro comando) myDA.Fill(ClientesDs) 'Y lo mostramos por pantalla For Each row As Data.DataRow In ClientesDs.Tables(0).Rows Console.WriteLine(row!Id.ToString() + " " + row!Nombre) Next Los TRIGGERS o disparadores son muy similares en su concepto a los procedimientos almacenados, es decir son piezas de código Transact-SQL, sin embargo son radicalmente distintas en la ejecución, mientras un procedimiento almacenado se ejecuta por la petición de un cliente, un TRIGGER responde a un evento, ya sea de manipulación de datos como los TRIGGERS DML o por la manipulación de esquemas como los TRIGGERS DDL.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

115

Los TRIGGERS son un tipo de objetos muy especiales en SQL Server 2005, ya que realmente son muy parecidos a lo que las rutinas de atención a eventos en código en cualquier lenguaje de programación como por ejemplo .NET. Como objetos especiales que son también reciben parámetros de una forma muy especial, en forma de unas tablas virtuales, llamadas inserted y deleted. Estas tablas especiales (inserted y deleted) contienen la información de los registros que se han eliminado o insertado, con exactamente las mismas columnas que la tabla base que está sufriendo esa modificación. Las tablas inserted y deleted estarán o no rellenas de datos en función de cuál sea el tipo de operación que ha dado lugar a su ejecución. Por ejemplo, un TRIGGER que se dispare por la inserción en una tabla tendrá tantos registros en la tabla virtual inserted como registros estén siendo insertados y cero registros en la tabla deleted; un TRIGGER que se dispare por la eliminación de registros en una tabla tendrá cero registros en la tabla inserted y tantos registros en la tabla deleted como registros estén siendo eliminados, y un TRIGGER que responda a una operación de update, tendrá el mismo número de registros en la tabla inserted y en la tabla deleted que además coincidirá con el número de registros actualizados en la tabla que da lugar al evento. Uno de los errores más comunes cuando se desarrollan TRIGGERS está relacionado con esta arquitectura que acabamos de describir, un TRIGGER no se dispara una vez para cada fila modificada, sino que se dispara una sola vez por cada operación, independientemente del número de registros afectados por la operación, y todos los registros afectados están contenidos en las tablas inserted y deleted dentro del TRIGGER. Muchos desarrolladores parten de la premisa de que las tablas inserted y deleted contendrán solamente un registro a lo sumo y como acabamos de explicar esto no es cierto. El segundo error más común tiene que ver este primero y con el rendimiento, muchos desarrolladores para solventar este problema crean cursores dentro de los TRIGGERS, los cursores como tal están fuera del alcance de este capítulo, pero en general un cursor dentro de un TRIGGER es casi un garantía de obtener problemas de rendimiento, por lo que deberíamos intentar evitarlos lo más posible. Los TRIGGERS son usados para añadir lógica o restricciones a la base de datos, por ejemplo pueden ser usados para establecer reglas de integridad con bases de datos externas (no grabar un pedido en la base de datos de pedidos si el cliente indicado no está dado de alta en la base de datos de pedidos por ejemplo); también son usados para mantener tablas de acumulados como por ejemplo la tabla que mantienen el stock de una determinada compañía o para guardar el acumulado de ventas en la ficha de un cliente. DML es el acrónimo de Data Manipulation Language (Lenguaje de Manipulación de datos), los TRIGGERS DML son como indica su nombre aquellos que responden a operaciones de manipulación de datos, tales como sentencias INSERT, UPDATE o DELETE mientras que DDL es el acrónimo de Data Definition Language (Lenguaje de definición de datos) los TRIGGERS DDL se dispararán por operaciones que impliquen cambios en los esquemas (en la definición de los objetos).

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

116

4.6. Triggers DML: INSTEAD OF Los TRIGGERS de tipo Instead OF son TRIGGERS que se disparan en lugar de la operación que los produce, es decir, una operación de borrado de registros con la instrucción delete sobre una tabla que tiene un TRIGGER de tipo INSTEAD OF no se llega a realizar realmente, sino que SQL Server 2005 cuando detecta esta operación invoca al TRIGGER que es el responsable de actuar sobre los registros afectados, en el ejemplo que estamos siguiendo, el TRIGGER sería el responsable de borrar los registros de la tabla que ha disparado el evento. Si el TRIGGER no se encarga de esta tarea, el usuario tendrá la sensación de que SQL Server no hace caso a sus comandos ya que por ejemplo una instrucción DELETE no borrará los registros. Como ejemplo de TRIGGER de tipo INSTEAD OF vamos a ver como se implementaría la siguiente regla: ”no se pueden borrar los clientes cuyo Crédito Total sea mayor que cero, sin embargo si dentro de una operación de borrado hay clientes con Riesgo Total cero y otros con Riesgo Total distinto de cero, los que tengan cero si deben resultar eliminados”. El TRIGGER que implementaría esa regla sería el siguiente. CREATE TRIGGER TR_BorradoSelectivo on Clientes INSTEAD OF DELETE AS BEGIN DELETE c FROM Clientes C INNER JOIN DELETED d ON C.idCliente=D.idCliente WHERE C.CreditoTotal=0 END Repasando el código podemos ve que estamos utilizando una sintaxis de JOIN para un DELETE, esta sintaxis es perfectamente válida y lo que hará será borrar todos los registros de C (Clientes) que existan también en D (DELETED) uniendo estas tablas por el código de cliente en donde el Crédito Total sea 0. El resto de los registros solicitados para borrar (es decir todos los que su campo crédito total no sea cero) simplemente no se borrarán, ya que como hemos mencionado los triggers de tipo INSTEAD OF delegan la responsabilidad de la operación en el cuerpo del TRIGGER. En algunos escenarios los TRIGGERS de tipo INSTEAD OF pueden usarse como mecanismo para evitar operaciones no controladas en tablas, por ejemplo si queremos prevenir que se borren datos de una tabla, basta con crear un INSTEAD OF TRIGGER y no poner ningún código en su cuerpo, de esta forma, a menos que el usuario deshabilite el TRIGGER, no podrá borrar ningún dato, sin embargo sea cuidadoso y documente bien este tipo de operaciones ya que pueden dar la falsa sensación de que la base de datos no se está comportando adecuadamente.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

117

4.7. Triggers DML: AFTER Todos los TRIGGERS sirven en general para implementar restricciones de negocio avanzadas, como ejemplo vamos a ver como se construiría un TRIGGER que impidiese que se aumentase el Crédito total de un cliente que tenga pagos pendientes, para ello vamos a suponer una tabla de clientes con identificador idCliente y con un campo llamado CreditoTotal y una tabla de recibos conteniendo el idcliente y el estado del recibo (estos son solamente los campos que son relevantes para nuestro ejemplo). CREATE TRIGGER TR_CompruebaCreditoTotal ON Clientes AFTER UPDATE AS BEGIN IF UPDATE(CreditoTotal) -- Se está actualizando el campo crédito total, comprobemos -- las restricciones. BEGIN IF EXISTS( SELECT IdCliente FROM RECIBOS WHERE Estado=’PEN’ AND idCliente IN (SELECT idCliente FROM DELETED) ) BEGIN ROLLBACK -- Deshacemos la transacción impidiendo que se actualize RAISERROR (‘No se pueden actualizar el crédito de clientes con recibos pendientes’,16,1) END END END Veamos algunas particularidades sobre el código del TRIGGER, la cláusula UPDATE, permite comprobar si se está actualizando una columna en particular, de esta forma nuestro TRIGGER resultará inocuo para el resto de operaciones de actualización. En la segunda parte se comprueba que el cliente tenga recibos pendientes con una cláusula EXISTS y con una cláusula in. La cláusula IN permite comprobar que el código de cliente esté en la lista de códigos de cliente borrados (todos ellos), la cláusula EXISTS permite comprobar si existen recibos pendientes en esos clientes. Algunos administradores de base de datos prefieren implementar estas reglas de negocio en procedimientos almacenados e impedir el acceso de los usuarios directamente a la modificación de tablas. Ambas alternativas son perfectamente válidas y el usar unas u otras dependerá de las políticas que se establecen en el desarrollo. Lo que en cualquier caso suele ser buena idea es manipular las restricciones de los datos en la base de datos, porque esta es la única forma de garantizar totalmente la consistencia de la información.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

118

4.8. Triggers DDL: a nivel de base de datos Los TRIGGERS DML (Data Manipulation Language) responden a la necesidad de garantizar la integridad y consistencia de los datos dentro de nuestras tablas de usuario, sin embargo no ayudan a mantener las reglas de diseño de nuestra base de datos. El nombre coincide pero el propósito es distinto, los triggers DDL (Data Definition Language) nos proporcionarán mecanismos para garantizar que nuestra base de datos está diseñada e implementada de acuerdo a los estándares que hayamos definido. Los TRIGGERS DDL tienen dos alcances diferenciados, a nivel de servidor y a nivel de base de datos. Estos alcances están enlazados con el tipo de evento que los dispare, en esta primera parte los eventos que vamos a ver son a nivel de Base de datos y algunos ejemplos de ellos son: CREATE / ALTER /DROP View CREATE / ALTER /DROP Table CREATE / ALTER /DROP Schema

Aunque hay muchos más, relacionados con estadísticas, sinónimos, usuarios (no confundir con logins que son a nivel de servidor), procedimientos, etc. Puede consultar los libros en pantalla de SQL Server 2005 para obtener una relación completa de todos los eventos a los que puede responder. Los TRIGGERS DDL tiene una particularidad adicional sobre los de tipo DML y es que no tiene mucho sentido las tablas inserted y deleted ya que el tipo de operaciones que disparan los triggers son radicalmente diferentes. Sin embargo, como ellos necesitan recibir información acerca del evento que ha ocasionado que el trigger se dispare, para ello existe la función EVENTDATA(), esta función devuelve un valor XML que responde al siguiente esquema: <EVENT_INSTANCE> <EventType>type</EventType> <PostTime>date-time</PostTime> <SPID>spid</ SPID> <ServerName>name</ServerName> <LoginName>name</LoginName> <UserName>name</UserName> <DatabaseName>name</DatabaseName> <SchemaName>name</SchemaName> <ObjectName>name</ObjectName> <ObjectType>type</ObjectType> <TSQLCommand>command</TSQLCommand> </EVENT_INSTANCE>

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

119

Utilizando las funciones XML para manipular esa función podemos obtener toda la información necesaria para crear TRIGGERS que garanticen que en nuestras bases de datos se siguen los estándares marcados. Supongamos que uno de esos estándares indica que todas las tablas deben estar documentadas, su propósito, la fecha de creación etc en una tabla llamada “TablasDocumentadas”, podríamos crear un TRIGGER DDL a nivel de base de datos que nos garantizase que antes de crear la tabla, ésta , ya ha sido documentada. El código que lo hace es el siguiente: CREATE TRIGGER TablasDocumentadas ON DATABASE FOR CREATE_TABLE AS BEGIN DECLARE @TabName Sysname SELECT @TabName=EventData().value(‘(/EVENT_INSTANCE/ObjectName)[1]’,’sysname’) IF NOT EXISTS(SELECT * FROM TablasDocumentadas WHERE TableName=@TabName) BEGIN ROLLBACK -- Deshacemos la transacción impidiendo que se actualize RAISERROR (‘No se pueden crear tablas indocumentadas en nuestro sistema’,16,1) END END Si lo miramos en detalle tan solo estamos obteniendo el nombre del objeto que se ha insertado (en nuestro caso la tabla que se acaba de crear) y estamos comprobando que existe un registro con ese nombre en la tabla TablasDocumentadas, sin embargo este procedimiento podría tener mucha más complejidad y garantizar no solamente que existe sino que los datos que contiene esa tabla son de cierta calidad.

4.9. Funciones Una herramienta adicional dentro de la programación de base de datos son las funciones definidas por el usuario. Estas funciones, que pueden ser de tres tipos, reciben parámetros como los procedimientos almacenados, y además pueden ser usadas como valores escalares o como tablas dentro de cláusulas from, lo que las hace tremendamente útiles en determinadas circunstancias.

4.10. Funciones Escalares Las funciones escalares son aquellas que devuelven un único valor en función de los parámetros que reciben. Pueden servir en múltiples circunstancias haciendo de la

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

120

programación una experiencia más agradable. Un ejemplo de función escalar podría ser la siguiente: CREATE FUNCTION Rangos (@id tinyint) RETURNS nvarchar(10) AS BEGIN DECLARE @Valor nvarchar(10) SELECT @Valor = CASE WHEN @id<20 THEN '1-19' WHEN @id>=20 AND @id<40 THEN '20-39' WHEN @id>=40 AND @id<60 THEN '40-59' WHEN @id>=60 AND @id<80 THEN '60-79' WHEN @id>=80 AND @id<100 THEN '80-99' ELSE '>100' END RETURN @Valor END Esta función devolverá un string que contiene el rango al que pertenece el número que recibe como parámetro. Desde las funciones se puede acceder a tablas también, pero siempre cuando se hace hay que ser muy cuidadoso para no implementar lo que se llaman “lookups” dentro de las udfs por que eso puede ser muy peligroso para el rendimiento ya que por cada fila devuelta se ejecutará una sentencia sin que el optimizador de consultas pueda hacer nada para mejorar la forma de ejecutarse.

4.11. Funciones de tabla en línea Las funciones de tabla en línea son muy parecidas a las vistas, con la excepción de que admiten parámetros de tal forma que pueden resultar tremendamente útiles en determinadas circunstancias. Veamos un ejemplo: CREATE FUNCTION ClientesPorTipo (@Tipo tinyint) RETURNS TABLE AS RETURN (SELECT * FROM Clientes WHERE Tipo=@tipo)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

121

Esta función puede ser usada en sentencias más complejas, un ejemplo de uso podría ser el siguiente: SELECT * FROM ClientesPorTipo(1) Cl INNER JOIN Facturas F ON CL.idcliente=F.IdCliente De esta forma podemos parametrizar consultas que vamos a usar en cláusulas FROM, de esta forma escribir código T-SQL resulta más sencillo y el resultado es más comprensible. Si además combinamos esta funcionalidad con las nuevas funciones APPLY podemos obtener funcionalidades aún más interesantes, ya que podemos conseguir que las funciones en línea o de tipo tabla reciban los parámetros desde los valores de otra tabla, la sintaxis sería algo así: SELECT * FROM ClientesSeleccionados C CROSS APPLY ClientesPorTipo(C.tipo) Esta consulta devolverá todos los registros de la tabla Clientes Seleccionados y los registros de la vista ClientesPortipo para cada Tipo de la tabla primaria.

ibid, pg, 7 ibid, pg,7

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

122

Unidad 5

Nuevas tendencias de bases de Datos Con el avance de la tecnología en las comunicaciones y en la programación se hace necesario tener conocimientos de lo que son las bases de datos orientadas a objetos ya esta serán utilizados a un mismo nivel que las Bases de datos relacionales de la actualidad y las bases de datos distribuidas que se están utilizando cada vez más en la misma medida en que se usa la arquitectura centralizada y clienteservidor y que se seguirá incrementando de manera considerable en la medida en que la tecnología de comunicación de datos brinde más facilidades para ello.

1. Bases de datos Orientadas a objetos(BDOO) Definición: Una Base de Datos Orientada a Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un depósito persistente listo para su explotación. Una BDOO almacena datos, las relaciones entre los datos y su comportamiento, es decir la forma cómo interactúan unos datos con otros.

1.1. Ventajas de la tecnología orientada a objetos. Flexibilidad. Si partimos del hecho que mediante la definición de clases establecemos módulos independientes, a partir de los cuales podemos definir nuevas clases, entonces podemos pensar en estos módulos como bloques con los cuales podemos construir diferentes programas. Reusabilidad. Una vez que hemos definido a la entidad persona para utilizarla en una aplicación de negocios, por mencionar un ejemplo, y deseamos construir a continuación una aplicación, digamos de deportes, en donde requerimos definir a la misma entidad persona, no es deseable volver a escribir la definición para la entidad persona. Por medio de la reusabilidad podemos utilizar una clase definida previamente en las aplicaciones que nos sea conveniente. Es claro que la flexibilidad con la que se definió la clase va a ser fundamental para su reutilización. Mantenibilidad. Las clases que conforman una aplicación, vistas como módulos independientes entre sí, son fáciles de mantener sin afectar a los demás componentes de la aplicación. Extensibilidad. Gracias a la modularidad y a la herencia una aplicación diseñada bajo el paradigma de la orientación a objetos puede ser fácilmente extensible para cubrir necesidades de crecimiento de la aplicación.

1.2. Desventajas objetos.

tecnología

orientada

A pesar de que las ventajas de la programación orientada a objetos superan a las limitaciones de la misma, podemos encontrar algunas características no deseables en ésta. Limitaciones para el programador. No obstante que la tecnología orientada a objetos no es nueva, un gran porcentaje de programadores no están familiarizados con los conceptos de dicha tecnología. En otras palabras, la lógica de la programación estructurada sigue siendo predominante en la mayoría de los desarrolladores de software, después de haber revisado de forma breve los principios de la programación orientada a objetos, nos es claro que en ésta se requiere una lógica de pensamiento totalmente diferente a la lógica comúnmente utilizada para la programación estructurada.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

124

Tamaño excesivo en las aplicaciones resultantes. La gran mayoría de los equipos de cómputo cuentan con capacidades tanto de almacenamiento como de memoria lo suficientemente buena como para ejecutar la mayoría de las aplicaciones que puedan desarrollarse con la tecnología orientada a objetos, sin embargo existen casos en los que lo anterior no se cumple. Una de las desventajas de la programación orientada a objetos es que cuando se heredan clases a partir de clases existentes se heredan de forma implícita todos los miembros de dicha clase aun cuando no todos se necesiten, lo que produce aplicaciones muy grandes que no siempre encajan en los sistemas con los que se disponga. Velocidad de ejecución. Esto tiene que ver, en cierto modo, con el punto anterior, una aplicación innecesariamente pesada en muchas ocasiones es más lenta de ejecutar que una aplicación conformada únicamente por los módulos necesarios.

1.3. Conceptos de la orientación a Objetos 1.3.1. Abstracción La abstracción es el proceso en el cual separamos las propiedades más importantes de un objeto, de las que no lo son. Es decir, por medio de la abstracción definimos las características esenciales de un objeto del mundo real, los atributos y comportamientos que lo definen como tal, para después modelarlo en un objeto de software. En el proceso de abstracción no debemos preocuparnos por la implementación de cada método o atributo, solamente debemos definirlo de forma general. Por ejemplo, supongamos que deseamos escribir un programa para representar el sistema solar, por medio de la abstracción, podemos ver a éste sistema como un conjunto de objetos, algunos de estos objetos son los planetas, que tienen un estado, dado por sus características físicas, digamos, tamaño, masa, entre otras, estos objetos tendrán también comportamientos: la translación y la rotación, pueden mencionarse como los más evidentes. Visualizar las entidades que deseamos trasladar a nuestros programas, en términos abstractos, resulta de gran utilidad para un diseño optimo de nuestro software, ya que nos permite comprender más fácilmente la programación requerida. En la tecnología orientada a objetos la herramienta principal para soportar la abstracción es la clase. Podemos definir a una clase como una descripción genérica de un grupo de objetos que comparten características comunes, dichas características se especificadas en sus atributos y comportamientos. En otras palabras, una clase es un molde o modelo en donde se especifican las características que definen a un objeto de manera general, a partir de una clase pedemos definir objetos particulares. En programación orientada a objetos se dice que un objeto es una instancia de la clase, es decir un objeto, es un caso particular del conjunto de objetos que comparten características similares, definidas en la clase. Un ejemplo servirá para clarificar estos conceptos. Definamos a la clase persona, esta clase tendrá ciertos atributos, por ejemplo edad, sexo y nombre entre otros. Las acciones o comportamientos que podemos definir para esta clase son, por ejemplo, respirar, caminar, comer, etcétera. Estas son, para nuestro caso, las características que definen a nuestra

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

125

clase persona. Un objeto instanciado de esta clase podría ser Juan Pérez, de sexo masculino y de 35 años de edad, quién se encuentra caminando. Estos atributos son conocidos formalmente en programación orientada a objetos como variables de instancia por que contienen el estado de un objeto particular en un momento dado, en este caso Juan Pérez. Así mismo, los comportamientos son llamados métodos de instancia porque nos muestran el comportamiento de un objeto particular de la clase.

1.3.2. Modularidad Dentro de la programación orientada a objetos, la modularidad juega un papel muy importante. Una vez que hemos representado una situación del mundo real en un programa, tenemos regularmente como resultado, un conjunto de objetos de software que constituyen la aplicación. La modularidad, nos permite poder modificar las características de la clase que definen a un objeto, de forma independiente de las demás clases en la aplicación. En otras palabras, si nuestra aplicación puede dividirse en módulos separados, normalmente clases, y estos módulos pueden compilarse y modificarse sin afectar a los demás, entonces dicha aplicación ha sido implementada en un lenguaje de programación que soporta la modularidad. La tecnología orientada a objetos nos brinda esta propiedad para hacer uso de ella en el software que desarrollemos.

1.3.3. Encapsulamiento También referido como ocultamiento de la información, el encapsulamiento es la propiedad de la orientación a objetos que nos permite asegurar que la información de un objeto le es desconocida a los demás objetos en la aplicación. Es muy frecuente referirse a los objetos de software como cajas negras, esto se debe principalmente a que no necesitamos, dentro de la programación orientada a objetos, saber cómo esta instrumentado un objeto para que este interactúe con los demás objetos. Generalmente una clase se define en dos partes, una interfaz por medio de la cual los objetos que son instanciados de la misma interactúan con los demás objetos en la aplicación, y la implementación de los miembros de dicha clase (métodos y atributos). Retomando dos de los ejemplos anteriores, supongamos que deseamos realizar una aplicación en donde deben interactuar el objeto Mercedes Benz, instancia de la clase automóvil y el objeto Juan Pérez, instancia de la clase Persona. Ambos objetos pueden ser vistos como cajas negras las cuales se comunican por medio de una interfaz. El objeto Mercedes no sabe como esta implementado el objeto Juan Pérez y viceversa. Concretamente, el encapsulamiento permite a un objeto ocultar información al mundo exterior, o bien restringir el acceso a la misma. Una aplicación orientada a objetos está constituida, como mencionamos anteriormente, por módulos. Estos módulos se implementan mediante clases, las cuales representan, generalmente, abstracciones de objetos del mundo real. Es por medio del encapsulamiento que podemos definir los atributos y los métodos de una clase para que los objetos que se instancian de ésta trabajen como unidades independientes de los demás objetos con los que interactúan. En otras palabras, con el encapsulamiento ganamos modularidad, y además protegemos a los objetos de ser manipulados de forma inadecuada por objetos externos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

126

1.3.4. Jerarquía o herencia Una vez que hemos definido una clase, por ejemplo la clase bicicleta, con sus atributos y métodos, tal vez necesitemos definir una nueva clase específica para las bicicletas de carreras. Es obvio que ésta nueva clases compartirá elementos en común con la clase bicicleta, es decir, la clase bicicleta de carreras será un subconjunto de la clase bicicleta. La tecnología orientada a objetos nos permite definir jerarquías entre clases y jerarquías entre objetos. Las dos jerarquías más importantes que existen son la jerarquía “es un” que precisa la generalización y especificación entre clases y la jerarquía “es parte de” en la cual se delimita la agregación de objetos. Comúnmente, a la jerarquía “es un” se le conoce como herencia. La herencia simple es la propiedad que nos permite definir una clase nueva en términos de una clase ya existente. Regresando al ejemplo, si podemos decir que una bicicleta de carreras “es una” bicicleta, entonces podemos definir a la clase bicicleta de carreras a partir de la clase bicicleta. Existirán casos en los cuales se necesite definir una clase a partir de dos o más clases preexistentes, en este caso estaremos hablando de herencia múltiple. En cuanto a la jerarquía de agregación, también conocida como inclusión, podemos decir que se trata del agrupamiento lógico de objetos relacionados entre sí dentro de una clase. Supongamos que tenemos que definir a la clase automóvil, pero además hemos definido ya a la clase volante. Si podemos expresar la oración, un volante “es parte de” un automóvil, entonces podemos instanciar un objeto de la clase volante, para definir a la clase automóvil. En este caso, se dice que automóvil es una agregación y volante es un agregado de automóvil.

1.4. Polimorfismo Muchas veces es necesario que un mismo comportamiento o acción se realice de diferentes maneras, por ejemplo, supongamos que deseamos implementar a la clase mamíferos, supongamos también que uno de los métodos que deseamos implementar para esta clase, es el que permita a tales mamíferos desplazarse de forma natural. Nos encontraremos entonces con que para algunos mamíferos el desplazamiento se realizará por medio de caminar, como es en el caso de las personas, para otros el desplazamiento natural será nadar, como en el caso de los delfines e inclusive para otros, el desplazamiento se logrará por medio de volar, como sucede con los murciélagos. En otras palabras, un mismo comportamiento, en este caso el desplazamiento, puede tomar diferentes formas. Dentro de la programación orientada a objetos puede modelarse esta situación del mundo real, en objetos de software, gracias al polimorfismo. El polimorfismo es la propiedad por la cual una entidad puede tomar diferentes formas. Generalmente está entidad es una clase, y la forma en que se consigue que tome diferentes formas es por medio de nombrar a los métodos de dicha clase con un mismo nombre pero con diferentes implementaciones. Para complementar este tema ver presentación. http://download.microsoft.com/download/F/A/C/FAC370F4-7D37-4899-A461D27ABC99C615/DCE0_ProgramacionOO_C%23_VBNET.ppt Obtenido en Internet el 16 de noviembre de 2008. Hora: 9.50 am.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

127

Luís Ibid Ibid Luís Ibid Ibid Ibid

Joyanes, Programación orientada a objetos, pág. 18 Mc Grow Hill 1998. pg. 5 pg. 5 Joyanes A. Programación Orientada a Objetos, página 28. Mc Grow Hill, 1998 pg. 7 pg. 7 pg. 7

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

128

2. Diseño de un diagrama de clases Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

2.1. Elementos de un diagrama de clases 2.1.1. Clase Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general. En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.

Representación visual de una clase en UML Imagen extraída de la dirección: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

2.1.2. Atributos En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente: + Indica atributos públicos # Indica atributos protegidos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

129

- Indica atributos privados

2.1.3. Operaciones Las operaciones (métodos) también se muestran al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente: + Indica operaciones públicas # Indica operaciones protegidas - Indica operaciones privadas

2.1.4. Plantillas Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirán en Java 1.5 con el nombre de Genéricos. Ejemplo de clase

2.1.5. Asociaciones de clases Las clases se puede relaciones (estar asociadas) con otras de diferentes maneras: Generalización

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

130

La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias. En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.

Representación visual de una generalización en UML Imagen extraída de la dirección: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

2.1.6. Asociaciones Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de «conexiones» entre objetos. Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace). Las asociaciones pueden tener una papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario. En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el infinito en el lado máximo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

131

Representación visual de una asociación en UML Imagen extraída de la dirección: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

2.1.7. Agregación Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación «completa». Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno. En UML, las agregaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa.

Representación visual de una relación de acumulación en UML Imagen extraída de la dirección: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

2.1.8. Composición Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son. En UML, las composiciones están representadas por un rombo sólido al lado del conjunto.

Imagen extraída de la dirección: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

132

Ejemplo 1

Ejemplo 2

Nos muestra una vista de la aplicación en un determinado momento, es decir, en un instante en que el sistema está detenido. Las clases son la plantilla de los objetos, y aquí podemos ver representados estos con sus atributos o características y su comportamiento o métodos, así como la relación entre ellas.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

133

Imagen extraída de la dirección: http://www.elguille.info/colabora/puntoNET/canchala_UML.htm Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

134

Ejemplo: 3 Una empresa desea crear una base de datos para el manejo de sus ventas Este maneja las siguientes condiciones: Del personal involucrado en las ventas se conoce la cedula el nombre y la dirección. Los empleados y los vendedores pueden ser clientes ya que estos pueden comprar los productos de la empresa con la que trabajan teniendo un descuento especial por ser de la empresa. De los empleados se tiene un salario, horario y retención. De los vendedores conocemos la comisión y área de venta. De los clientes también se tiene un crédito máximo. De los proveedores se tiene el tiempo de servicio. Una factura para un cliente atendida por un empleado debe tener un vendedor y varios productos. Los proveedores despachan materiales utilizados para los productos siendo posible que un material sea despachado por varios proveedores. Completar los demás supuestos semánticos que hacen falta para construir el modelo orientado a objetos o el diagrama de clases. Ubicando las clases, subclases, objetos, herencia simple y herencia múltiple si la hay. Solución en un diagrama de clases

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

135

Para complementar este tema de cómo construir un diagrama de clases visitar esta dirección. http://cesar.crbyte.com/apuntes/2_tecnicas_modelado.pdf Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am

Colabora.net, Ejemplo sencillo sobre el modelado de un proyecto, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am http://www.elguille.info/colabora/puntoNET/canchala_UML.htm Ibid pg. 10 Ibid pg. 10 Ibid pg. 10 Ibid pg. 10 8 http://es.wikipedia.org/wiki/Diagrama_de_clases, Obtenido en Internet el 16 de Noviembre de 2008. Hora: 9.50 am. Elementos de UM, Obtenido en Internet el 16 de Noviembre de 2008. Hora: 9.50 am. http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html,

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

136

Glosario GLOSARIO

Actualización en cascada: actualización automática de las entidades, en una relación externa, cuando se modifica la correspondiente entidad de la relación principal. ADO: Objetos de acceso a datos.

lógicamente y localizadas sobre una red de computadores. Base de datos orientadas a objetos: Almacena datos y relaciones con el paradigma de la orientación a objetos.

Base de datos relacionales: Conjunto Algebra relacional: Lenguaje de consulta para lade s tablas relacionadas entre ellas. bases de datos. Base de datos: Combinación del Anomalía de actualización: Problemas esquema de y los datos almacenados. con la manipulación de los datos de un modelo pobremente diseñado. Bit: Digito binario o elemento mínimo de información Aplicación de bases de datos: Formularios e informes con los que Byte: Conjunto de bits que se tratan como interactúa el usuario. unidad, generalmente se componen de 8 bits. Archivo maestro: Archivos creados por medio de programación. Cabecera de una relación: La definición de atributos y dominios en la parte Asociación binaria: Una asociación entre superior de una relación. dos entidades participantes. CAD: Diseño asistido por computador. Asociación ternaria: Una asociación que tiene tres participantes. Campo: Área de trabajo que puede almacenar uno o varios datos. Asociación unaria: Una asociación Ejemplo: En el campo NOMBRE se establecida con una misma entidad. almacena: “Carlos Alberto García". Asociación: Una relación entre dos entidades.

establecida

Atributo: Una cualidad de la entidad o una columna para una tabla. Base de datos distribuidas: Colección de varias bases de datos interrelacionadas

Carácter: Es información.

menor

unidad

Cardinalidad de una asociación: El número máximo de ejemplares de una entidad que puede participar en una relación.

Cardinalidad de una relación: Número de filas de una relación.

derecha que coinciden con la condición de combinación.

CASE: Ingeniería del software asistida por computador.

Combinación interna: Incluye todos los registros de ambas tablas que coinciden con la condición de combinación.

Clase derivada: Clase que características de otra clase.

hereda

Clase: Representación abstracta, plantilla de un conjunto de objetos. Cláusula: Comandos del SQL para la manipulación de la base de datos. Clave alterna o secundaria: Una clave que no se utiliza como clave principal. Clave candidata: Uno o mas atributos que identifican de forma única una relación Clave compuesta: Una clave candidata compuesta por dos o mas atributos. Clave foránea: Es una clave primaria que esta en otras tablas fuera de aquella a donde corresponde. Clave primaria: Clave candidata de una relación que se utiliza para identificar de forma inequívoca los registros de una tabla. Combinación externa completa: Devuelve todos los registros de ambas tablas y combina en un solo registro aquellos que coinciden con la condición de Combinación externa derecha: Incluye todos los registros de la tabla de la derecha y los registros de la tabla de la izquierda que coinciden con la condición de combinación. Combinación externa izquierda: Incluye todos los registros de la tabla de la izquierda y los registros de la tabla de la

Combinación natural: Si las columnas se llaman igual y se elimina una de ellas el operador de comparación debe ser el igual. Combinación teta-Join: Unión basada en un operador lógico diferente al igual Combinación. Combinación: Concatenación de o mas tablas en la manipulación de la base de datos. Conjunto de registros: Representación física de una relación. Consulta: Resultado que se obtiene de la base de datos. DBA: Administrador de bases de datos. DBGS o DBMS: Sistema Gestor de Bases de datos. DDBMS: Sistema manejador de bases de datos distribuidas. DDL: Lenguaje de definición de datos. Dependencia funcional: Es la relación que hay entre los atributos. Descomposición sin pérdidas: La capacidad de dividir relaciones de tal forma que se puedan recombinar sin pérdida de información. Diferencia relacional: Son los registros que esta en una primera tabla y no están en la segunda tabla.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

138

DML: Lenguaje de manipulación de datos. Dominio: Intervalo de valores del que se puede obtener un atributo. Dominios compatibles en tipo: Dominios que se pueden comparar lógicamente. Entidad débil: Es aquella que solo puede existir de la destrucción de una relación de muchos a muchos. Entidad participante: Son las entidades que relacionan las entidades débiles. Entidad: Cualquier cosa sobre la que el sistema debe almacenar información. Equi-unión: Una unión entre dos tablas basadas en la igualdad. Espacio del problema: La parte del mundo real que se modela en una aplicación de bases de datos.

Grado de una relación o tabla: Es el número de columnas que tiene una tabla o relación. Herencia múltiple: Cuando la clase proviene de varios padres. Herencia simple: Cuando proviene de un solo padre.

clase

Herencia: Características que se heredan. Información: Son los datos organizados de tal forma que son útiles para la toma de desiciones. Informe ad hoc: Informe configurado por el usuario después de la implementación de una base de datos. Integridad de los datos: Son las reglas utilizadas por una base de datos para asegurar que los datos son correctos.

Esquema de bases de datos: La disposición física en las tablas de la base de datos.

Integridad referencial: Aseguran que las asociaciones entre las tablas son validas. Intersección relacional: Una operación relacional que devuelve los registros comunes que hay entre dos tablas.

Evento: Cosas que suceden al ejecutar una acción.

Mensajes: funciones.

Fragmentación horizontal: Es la división de la tabla por registros dada una condición.

Métodos: Son procedimientos.

Fragmentación mixta: Es la división de la tabla por campos y luego por registros o viceversa. Fragmentación vertical: Es la división de la tabla por campos. Fragmentación: División de una tabla en varias fracciones.

Son

las

llamadas funciones

las o

Modelo de red: Representación de la información Cuando un registro proviene de varios padres y las relaciones son por medio de apuntadores y enlaces. Modelo entidad relación: Representación visual de la información en entidades y relaciones. Modelo jerárquico: Representación de la información Cuando un registro proviene de un solo padre y las relaciones son por medio de apuntadores y enlaces.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

139

Modelo orientado a objetos: Representación visual de la información con orientación a objetos.

Proyección relacional: Una operación relacional que separa columnas de una tabla.

Modelo relacional: Representación de la información en tablas relacionadas.

RDO: Objetos de datos remotos.

Modelos de datos: Descripción conceptual de un espacio del problema. Modelos lógicos basados en objetos: La información se representa con objetos. Modelos lógicos basados en registros: La información se representa en registros. MOO: Modelo orientado a objetos Normalización: Es la división sucesiva de tablas a una forma mas agradable y entendible y no se pierde información. Objeto conceptual: Representa cosa en forma general. Objeto físico: Representa cosa en forma específica. Objeto: Conjunto de atributos describen con eficacia una entidad.

que

Registro: Es un conjunto de campos relacionados. Relación base: Tabla de la base de datos. Relación: Es la asociación nombrable y significativa que hay entre dos entidades. a una tabla también se le conoce como relación. Restricción de base de datos: Condición que debe cumplir la base de datos. Restricción de negocios: Una condición dada por el espacio del problema. Selección relacional: Una operación relacional que separa registros de una tabla dada una condición. Sistema de bases de datos: Es todo el conjunto que se utiliza para crear la base de datos.

ODBC: Conexión abierta de bases de datos.

Sistema multidatabase: operaciones sobre múltiples datos.

OODB: Bases objetos.

SQL: Lenguaje de consulta estructurado.

datos

orientadas

OODBMS: Sistema manejador de bases de datos orientadas a objetos. POO: Programación orientadas a objetos. Producto cartesiano: Una operación relacional que combina cada registro de una tabla con cada registro de la segunda tabla.

Soporta bases de

Tabla de fragmentación: Es el número de veces que una transacción se da un determinado sitio. Tabla de polarización: Es la probabilidad que hay de que una transacción se de un determinado sitio sobre un fragmento. Tabla: Ejemplificación física de una relación en el esquema da la base de datos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

140

Tipos de datos: Son los diferentes datos que se pueden almacenar. Tupla: Son los registros de una tabla. UML: modelo de datos unificado. Valores nulos: Son los campos que se dejan sin valor y son diferentes de 0 y cadena vacía. Vista: Son tablas virtuales de la base de datos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

141

Bibliografía

Documento editado por Oralia Cortés apoyada en la siguiente bibliografía: 1. C.J Date. Addison-Wesley. Introducción a los Sistemas de Bases de Datos. 2. De Miguel, Adoración; Piattini, Mario. Fundamentos y modelos de Bases de Datos. 3. Gary W,Hansen; James V,Hansen. Diseño y administración de Bases de Datos. Prentice Hall, 1997. 834 p. 4. Henry F. Korth, Abraham Silberschatz. Fundamentos de Bases de Datos. McGrawHill. Segunda Edición. 5. Joyanes Luís, Programación orientada a objetos, Mc Graw Hill 1998 6. Korth, Henry ; Siberschatz, Abram. Fundamentos de Bases de datos. Mc Graw Hill. 7. Rocha, Mario. Modelo entidad relación. Documento

Cibergrafía

Análisis comparativo de bases de datos de Código abierto vs. Código cerrado Obtenida en la Fecha: Noviembre 16 de 2008 hora: 14.36 http://www.monografias.com/trabajos35/comparativa-bases-datos/comparativa-basesdatos.shtml#tendenc Circuitos Electrónicos, practicas mías, Bases de datos y normas de Calidad. Obtenido en Internet el Fecha Septiembre 27 de 2008 hora: 10 pm http://www.galeon.com/konnan2001/ERE.htm Colabora.net, Ejemplo sencillo sobre el modelado de un proyecto, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am http://www.elguille.info/colabora/puntoNET/canchala_UML.htm Dependencia funcional e independencia, manual de la Universidad de Málaga. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://ftp.medprev.uma.es/libro/node33.htm Diseño de base de datos distribuida, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_3.html Diseño de una base de datos distribuida, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am http://usuarios.lycos.es/jrodr35/tipos.htm Documentación de SQL Server 2005. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://msdn.microsoft.com/es-es/library/ms203721(sql.90).aspx Elementos de UML, Obtenido en Internet el 16 de Noviembre de 2008. Hora: 9.50 am. http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html, ESCOM, fundamentos teóricas de bases de datos distribuidas, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 14.36 http://www.geocities.com/ddbqp/#_1.1_Introducción http://es.wikipedia.org/wiki/Diagrama_de_clases, Obtenido en Internet el 16 de Noviembre de 2008. Hora: 9.50 am. http://www.calasanz-pereira.edu.co/prueba/html/modules/Access/normalizacion.htm http://www.monografias.com/trabajos11/basda/basda.shtml Instituto tecnológico de Colima. Obtenido en Internet el Fecha Septiembre 27 de 2008 hora: 10 pm http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm Introducción a los conceptos de Bases de Datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_12.htm Introducción a los Sistemas de Base de Datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://www.temas-estudio.com/base-de-datos/ Introducción a los Sistemas de Base de Datos. Obtenido en Internet el Fecha Septiembre 27 de 2008 hora: 10 pm http://www.temas-estudio.com/base-de-datos/ Introducción a los Sistemas de Base de Datos. Obtenido en Internet el Fecha Septiembre 27 de 2008 hora: 10 pm http://www.monografias.com/trabajos34/base-de-datos/basede-datos.shtml

Las 12 reglas de Codd. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.atpsoftware.net/Public/Articulos.php Marqués Andrés, María Mercedes. Ciclo de vida de las aplicaciones de bases de datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://www3.uji.es/~mmarques/f47/apun/node67.html Microsoft SQL Server 2005, Express edition, Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.desarrollaconmsdn.com/msdn/CursosOnline/Curso_SQL_Server/index.html Normalización de base de datos, Prof. Manuel Torres Remon. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.monografias.com/trabajos5/norbad/norbad.shtml Normalización de Bases de Datos. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://www.trucostecnicos.com/trucos/ver.php?id_art=278 Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 http://perso.wanadoo.es/aldomartin1/noreyalre.htm Programa Microsoft desarrollador de software cinco estrellas, estrella 0 introducción a la programación orientación a objetos en C# y visual Basic.Net Obtenido en Internet el 16 de Noviembre de 2008. Hora: 9.50 am. http://download.microsoft.com/download/F/A/C/FAC370F4-7D37-4899-A461D27ABC99C615/DCE0_ProgramacionOO_C%23_VBNET.ppt Sistema de bases de datos distribuidas, Obtenida en la Fecha: Noviembre 16 de 208 hora: 14.36 http://docente.ucol.mx/vpc1052/public_html/Expo%20SBDD.doc SQL Server TechCenter. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://technet.microsoft.com/es-es/library/ms191236.aspx Tecnicas básicas del modelado de objetos, Obtenida en la Fecha: Noviembre 16 de 2008 hora: 9.30 am http://cesar.crbyte.com/apuntes/2_tecnicas_modelado.pdf Trejo Martínez, Janhil Aurora. Bases de datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. Universidad Calasanz de Pereira. Normalización. Obtenido en Internet el Fecha Septiembre 27 de 2008 hora: 10 pm Universidad Distrital francisco José de Caldas. De Base de Datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://groups.msn.com/elch/modelosdedatos.msnw Universidad Distrital francisco José de Caldas. Modelo entidad Relación. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Universidad Nacional de Colombia. Visión de los Datos. Obtenido en Internet el 22 de agosto de 2008. Hora: 10.05 pm. http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html You Tobe ideos, Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://es.youtube.com/watch?v=IPKl19SbiYQ You Tobe ideos, Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm. http://es.youtube.com/watch?v=AIn8inZInAQ

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

144