Universidad Tecnolgica de Puebla

Tcnico Superior Universitario en Tecnologas de la Informacin y Comunicacin

Materia:

Base de Datos

Enero Abril 2010

Colaboradores:
1. Mara Eva Prez Ramrez 2. Rosario Snchez Bauelos 3. Enrique Villa Ruano 4. Leticia Rodrguez Barrientos 5. Jos Cruz Salas Sols.

NDICE UNIDAD I FUNDAMENTOS DE BASES DE DATOS. 1 1 2 2 4 5 5 5 6 7 10 10 10 11 14 15 16 16 16 16 16 17 19 22 23 24 25 26 28 30 30 30 31 31 32 32 33 33 33 34 34 34

1.1 Conceptos bsicos. 1.1.1 Concepto de base de datos. 1.1.2 Objetivo de los sistemas de base de datos. 1.1.3 Modelos de bases de datos. 1.1.3.1 Relacional. 1.1.3.2 Jerrquico. 1.1.3.3 Orientado a Objetos. 1.1.3.4 De red 1.1.4 Terminologa de Bases de Datos. 1.1.5 Principios y Actores en Bases de Datos. 1.2 Anlisis de requerimientos de Bases de Datos. 1.2.1 Tcnicas de Recoleccin de datos. 1.2.1.1 Observacin. 1.2.1.2 Entrevista. 1.2.1.3 Cuestionarios. 1.2.2 Clasificacin y estructura bsica de datos. UNIDAD II MODELO ENTIDAD-RELACION (E-R)

2.1 El modelo Entidad-Relacin 2.1.1 Entidades 2.1.2 Relaciones 2.1.2.1 Atributos 2.2 Restricciones de Asignacin. 2.3 Claves 2.4 Modelo Entidad Relacin Extendido. 2.4.1 Clase y Superclase. 2.4.2 Herencia. 2.4.3 Especializacin. 2.4.4 Generalizacin. 2.4.5 Ejercicios UNIDAD III MODELO RELACIONAL. 3.1 Conceptos del modelo relacional. 3.1.1 Atributos. 3.1.2 Dominios. 3.1.3 Tuplas. 3.1.4 Relaciones. 3.2 Esquema de una Relacin. 3.2.1 Relaciones Nominadas. 3.2.2 Relaciones sin nombre 3.2.3 Concepto de clave 3.2.3.1 Clave Primaria y Alternativa. 3.2.3.2 Clave Fornea. 3.3 Transformacin de los modelos E-R a Modelo Relacional.

3.3.1 De los conjuntos Entidad a las Relaciones 3.3.2 De las relaciones E-R a las Relaciones 3.3.3 Traduccin del lenguaje de definicin de objetos a relaciones 3.3.4 Manejo de los conjuntos entidad dbiles 3.3.5 Transformacin de E-R extendido en Relaciones. 3.3.5.1 Interrelaciones Reflexivas. 3.3.5.2 Interrelaciones Exclusivas. 3.3.5.3 Generalizacin y Herencia en el modelo E-R 3.3.5.4 La cardinalidad en la jerarqua. 3.3.6 Representacin de las restricciones en el modelo EE-R 3.3.6.1 Sintaxis del Modelo EE-R 3.4 Algebra Relacional. 3.4.1 Operaciones del Algebra Relacional. 3.4.1.1 Operacin de seleccin o Restriccin. 3.4.1.2 Operacin de Proyeccin. 3.4.2 Composicin de operaciones relacionales 3.4.2.1 Operacin Unin 3.4.2.2 Operacin diferencia de conjuntos 3.4.3 Producto Cartesiano

35 35 35 35 36 36 37 37 41 42 42 43 44 44 45 45 46 47 48

UNIDAD IV DISEO DE BASES DE DATOS RELACIONALES. 4.1 Restricciones de Integridad. 4.1.1 Clasificacin de restricciones 4.1.1.1 Restricciones Inherentes 4.1.1.2 Restricciones Semnticas. 4.1.2 Integridad de Entidades y Referencial, claves externas. 4.1.2.1 Restricciones de Clave 4.1.2.2 Integridad de Entidad 4.1.2.3 Integridad Referencial 4.2 Normalizacin de una Base de Datos 4.2.1 Primer Nivel de Formalizacin/Normalizacin. 4.2.2 Segundo Nivel de F/N 4.2.3 Tercer Nivel de F/N 4.2.3.1 Relaciones entre datos 4.2.4 Cuarto nivel de F/N 4.2.5 Quinto nivel de F/N

50 50 50 50 51 53 53 54 55 55 56 57 57 58 59 60

UNIDAD 1 FUNDAMENTOS DE BASES DE DATOS. 1.1. CONCEPTOS BSICOS

El almacenamiento y control de informacin es una tarea comn que se realiza en las grandes empresas, instituciones, organizaciones, pequeas oficinas y hasta en nuestra vida personal. Anteriormente podamos ver los grandes archiveros con cientos de folders que una secretaria intentaba mantener organizados. Al tratar de automatizar el proceso de manejo de estos archivadores manuales, con objeto de proporcionar un acceso ms eficiente a la informacin surgi la idea de crear los sistemas de archivos como un conjunto de programas que manejaran sus propios datos de manera descentralizada; es decir; cada departamento manejaba su propia informacin. Esto hizo que existiera como primer inconveniente una gran cantidad de informacin repetida. 1.1.1. CONCEPTO DE BASE DE DATOS A raz de esto se comenz a descubrir una serie de inconvenientes que mostraban los sistemas de archivos:

Separacin y aislamiento de los datos. Cuando los datos se separan en distintos archivos, es ms complicado acceder a ellos, ya que el programador de aplicaciones debe sincronizar el procesamiento de los distintos archivos implicados para asegurar que se extraen los datos correctos. Duplicacin de datos. La redundancia de datos existente en los sistemas de archivos hace que se desperdicie espacio de almacenamiento y lo que es ms importante: puede llevar a que se pierda la consistencia de los datos. Se produce una inconsistencia cuando copias de los mismos datos no coinciden. Dependencia de datos. Ya que la estructura fsica de los datos (la definicin de los archivos y de los registros) se encuentra codificada en los programas de aplicacin, cualquier cambio en dicha estructura es difcil de realizar. El programador debe identificar todos los programas afectados por este cambio, modificarlos y volverlos a probar, lo que cuesta mucho tiempo y est sujeto a que se produzcan errores. A este problema, tan caracterstico de los sistemas de archivos, se le denomina tambin falta de independencia de datos lgica-fsica. Formatos de archivos incompatibles. Ya que la estructura de los archivos se define en los programas de aplicacin, es completamente dependiente del lenguaje de programacin. La incompatibilidad entre archivos generados por distintos lenguajes hace que los archivos sean difciles de procesar de modo conjunto. Consultas fijas y proliferacin de programas de aplicacin. Desde el punto de vista de los usuarios finales, los sistemas de archivos fueron un gran avance comparados a los sistemas manuales. A consecuencia de 1

esto, creci la necesidad de realizar distintos tipos de consultas de datos. Sin embargo, los sistemas de archivos son muy dependientes del programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser programado por l. Los inconvenientes de los sistemas de archivos se pueden atribuir a dos factores:

La definicin de los datos se encuentra codificada dentro de los programas de aplicacin, en lugar de estar almacenada aparte y de forma independiente. No hay control sobre el acceso y la manipulacin de los datos ms all de lo impuesto por los programas de aplicacin.

Por lo que surge el manejo de informacin en bases de datos. Una base de datos es una recopilacin de informacin relativa a un asunto o un propsito particular, como el seguimiento de pedidos de clientes o el mantenimiento de una coleccin de msica. 1.1.2. OBJETIVO DE LOS SISTEMAS DE BASE DE DATOS Para trabajar de un modo ms efectivo, surgieron las bases de datos y los sistemas de gestin de bases de datos (SGBD). La base de datos es un gran almacn de datos que se define una sola vez y que se utiliza al mismo tiempo por muchos departamentos y usuarios. En lugar de trabajar con archivos desconectados e informacin redundante, todos los datos se integran con una mnima cantidad de duplicidad. La base de datos no pertenece a un departamento, se comparte por toda la organizacin. Adems, la base de datos no slo contiene los datos de la organizacin, tambin almacena una descripcin de dichos datos. Esta descripcin es lo que se denomina metadatos, se almacena en el diccionario de datos o catlogo y es lo que permite que exista independencia de datos lgica-fsica. El modelo seguido en las Bases de datos separa la definicin de los datos de los programas de aplicacin. Si se aaden nuevas estructuras de datos o se modifican las ya existentes, los programas de aplicacin no se ven afectados ya que no dependen directamente de aquello que se ha modificado. 1.1.3. MODELOS DE BASES DE DATOS Para introducirnos en este tema, empezaremos definiendo que es un modelo. Modelo: Es una representacin de la realidad que contiene las caractersticas generales de algo que se va a realizar. En base de datos, esta representacin la elaboramos de forma grfica.

Es una coleccin de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semntica asociada a los datos y restricciones de consistencia. Los modelos de bases de datos son entonces, un conjunto de conceptos, reglas y convenciones que nos permiten describir y manipular (consultar y actualizar) los datos de un cierto mundo real que deseamos almacenar en una base de datos. Son un eficaz instrumento en el diseo de Bases de Datos, al proporcionar instrumentos que ayudan a la estructuracin, paso a paso, del mundo real hasta llegar a la base de Datos fsica.1 En el estado actual de la tcnica es conveniente, en el diseo de bases de datos distinguir la fase del modelado conceptual, que es la descripcin del mundo real (empresa o administracin) independiente del Sistema Gestor de Bases de Datos (SGBD) que se vaya a utilizar y la fase del diseo lgico, en la cual se ha de obtener un esquema que responda a la estructura lgica especifica del SGBD que se aplique en cada caso, por lo que dicho esquema est sometido a las restricciones del SGBD. La realizacin de modelos se considera importante porque sirve para: Mejorar la comprensin de un problema. Compartir informacin relevante y hacer trabajo de equipo. Elaborar conclusiones y tomar decisiones bien fundadas. Comunicar y plasmar nuestras percepciones de la realidad. Abordar con xito la solucin de un problema. Los componentes esenciales de un modelo de datos son: Componentes Estticos, que definen las estructuras de datos vlidas. Componentes Dinmicos, que definen las reglas de comportamiento y transformacin de los datos. CATEGORAS DE LOS MODELOS DE DATOS Los modelos de datos se dividen en tres grupos: Modelos fsicos de datos. Modelos lgicos basados en registros. Modelos lgicos basados en objetos MODELOS FISICOS DE DATOS Se usan para describir a los datos en el nivel ms bajo, aunque existen muy pocos modelos de este tipo, bsicamente capturan aspectos de la
1

Piattini Velthuis, Mario, Castrao,Miguel.(1999). Fundamentos y Modelos de Bases de Datos.AlfaOmega.

n de los sistemas s de base de e datos. Ex xisten dos clasificaciones implementaci e tipo qu ue son: de este Modelo unificador Memoria de d element tos. MOD DELOS L GICOS BA ASADOS EN E REGIS STROS Se utilizan u par ra describir datos en n los nivel les conce eptual y fs sico; se uti ilizan para a especific car la est tructura l gica com mpleta de las bases s de dato os y prop porcionan una desc cripcin de e alto niv vel de imp plementaci in, tienen n un nm mero fijo de e campos, , atributos s y longitud fija, entre estos e encontramo os el mod delo de red, modelo je errquico y modelo relacional: r

1.1.3 3.1.

Rela acional

En este modelo m se representan los dato os y las rel laciones en ntre estos, ,a trav s de una coleccin de d tablas, en las cua ales los ren nglones (tu uplas) equivalen a ca ada uno de e los regist tros que co ontendr la a base de d datos y las s columnas corre esponden a las caractersticas(atributos) de cada r registro localizado en la tupla; sideremos s una emp presa que requiere controlar a los ven ndedores y las Cons vent tas que ell los realiza an; de este e problema a determin namos que e los objet tos o entid dades principales a estudiar e so on el empleado (ven ndedor) y e el artculo (que es el producto en venta). .

1.1.3 3.2.

Jer rquico

Es simila ar al mode elo de red en e cuanto a las relac ciones y da atos, ya que estos se representan por r medio de e registros s y sus liga as. La difer rencia radica en que q estn organizado o os por conjuntos de rboles en lugar de g grficas arbit trarias.

1.1.3 3.3.

Orie entado a Objetos O

Se e usan par ra describir datos en n los nivele es concept tual y de v visin, es decir, d con este mod delo repres sentamos los datos s de tal fo orma como o nosotros s los capt tamos en el e mundo real, tiene en una cap pacidad de e estructur racin bast tante flexib ble y perm miten especificar rest tricciones de datos explcitamente. Entre los mod delos que encontram e mos de este e tipo son Modelo Entidad-Re E elacin, Mo odelo Entid dad-Relacin Extend dido y Modelo Orienta ado a Obje etos. Modelo Entidad-R Relacin.- Coleccin de obj jetos bs sicos llamados entid dades y se e pueden relacionar. r Una pers sona, cosa, etc. Cada a entidad tiene atrib butos. Tienen relacin n que es la a asociaci n entre va arias entida ades. Modelo Entidad Relacin n extendid do.- El Modelo M En ntidad-Rela acin Exte endido incl luye todos s los conc ceptos del Entidad-R Relacin e incorpora a los conc ceptos de e Subclase y Supe erclase co on los co onceptos asociados s de Espe ecializacin y Gener ralizacin. Otro nuev vo concept to incluido por el ER RE es el de e Categor a. Asociad do a estos conceptos s est el im mportante mecanism mo de Here encia de at tributos. Modelo 0rientado a 0bjetos.. Un objet to tiene fra agmentos de cdigo o que ran en el objeto, o llam mados m todos. Un n objeto pu uede acced der a los datos d oper de otro o median nte un paso o de mens saje. No requieren niv vel fsico. 1.1.3 3.4. De Red. R

Este mod delo representa los datos mediante m c colecciones s de registros y sus s relac ciones se represen ntan por medio de ligas s o enla aces, los cuales pueden p ve erse como o puntero os. Los registros se organ nizan en un u conjunto o de grfica as arbitrari ias. Ejem mplo:

1 1.1.4. TER RMINOLOG GA DE BA ASES DE DATOS D Para a disear una base de datos s debemos s establec cer un pro oceso que e nos perm mita plasmar el mund do real me ediante una a serie de datos. En primer lug gar la imag gen que obtenemos o del mund do real se denomina a modelo conceptu ual y cons siste en un na serie de e elemento os que def finen lo qu ue queremos plasma ar del mun ndo real en una base de datos. Com menzando con alguno os concep ptos bsico os para el mejor ent tendimiento o del mism mo, se ma anejaran de efiniciones s de trmin nos que in nvolucran a las base es de dato os: C de caracteres con n algn significado, s , pueden ser Datos: Conjunto numricos, alfabtic cos, o alfan numricos. cin: Es un conju unto orden nado de datos los s cuales son Informac manejado os segn la necesid dad del usuario, pa ara que un conjunto o de datos pu ueda ser procesad do eficientemente y pueda dar luga ar a informaci n, primer ro se debe guardar l gicamente e en archiv vos. Campo: Es la unid dad ms pequea a la cual un no puede r referirse en un a. Desde el punto de vista del progra amador re epresenta una programa caracters stica de un n individuo u objeto. Registro: Coleccin n de camp pos de igua ales o de diferentes d t tipos. n de registros almac cenados siguiendo s u una estruc ctura Archivo: Coleccin homogn nea. En otras o palab bras una base de dat tos es un conjunto c e exhaustivo no redund dante de datos d estru ucturados y organiza ados indep pendientem mente de s su utilizacin y su implement tacin. La as bases de datos s proporcionan la infraestructura requ uerida para a los siste emas de apoyo a a la toma de e decision nes y para a los siste emas de informaci n estratg gicos, ya que esto os sistema as explota an la infor rmacin co ontenida en n las base es de datos s de la org ganizacin para apoy yar el proc ceso de toma de dec cisiones o para logr rar ventaja as competi itivas. Por este motivo es impo ortante con nocer la forma en qu ue estn es structurado os las base es de dato os y su man nejo. En este e marco o se puede e definir un na base de e datos com mo: Co onjunto o colecci n de arc chivos interrelacion nados, cu uyo conte enido engl loba a la informaci n concer rniente de e una orga anizacin, de tal ma anera que los datos s estn dis sponibles s para los usuarios, , una de las finalida ades de las bases s de dato os es eliminar la redunda ancia o p por lo me enos mini imizarla.

1.1.5. PRINCIPIOS Y ACTORES EN BASES DE DATOS Las funciones principales de un sistema de base de datos es disminuir los siguientes aspectos: Redundancia e inconsistencia de datos. Puesto que los archivos que mantienen almacenada la informacin son creados por diferentes tipos de programas de aplicacin existe la posibilidad de que si no se controla detalladamente el almacenamiento, se pueda originar un duplicado de informacin, es decir que la misma informacin sea ms de una vez en un dispositivo de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos, adems de que puede originar la inconsistencia de los datos - es decir diversas copias de un mismo dato no concuerdan entre si -, por ejemplo: que se actualiza la direccin de un cliente en un archivo y que en otros archivos permanezca la anterior. Dificultad para tener acceso a los datos. Un sistema de base de datos debe contemplar un entorno de datos que le facilite al usuario el manejo de los mismos. Supngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos los clientes que viven dentro del cdigo postal 78733 de la ciudad. El gerente pide al departamento de procesamiento de datos que genere la lista correspondiente. Puesto que esta situacin no fue prevista en el diseo del sistema, no existe ninguna aplicacin de consulta que permita este tipo de solicitud, esto ocasiona una deficiencia del sistema. Aislamiento de los datos. Puesto que los datos estn repartidos en varios archivos, y estos no pueden tener diferentes formatos, es difcil escribir nuevos programas de aplicacin para obtener los datos apropiados. Anomalas del acceso concurrente. Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta ms rpido, muchos sistemas permiten que mltiples usuarios actualicen los datos simultneamente. En un entorno as la interaccin de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe mantenerse alguna forma de supervisin en el sistema. Problemas de seguridad. La informacin de toda empresa es importante, aunque unos datos lo son ms que otros, por tal motivo se debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna informacin, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado de seguridad que garantice la autentificacin y proteccin de los datos. En un 7

co por ejem mplo, el pe ersonal de nminas slo s necesi ita ver la p parte de la base banc de datos d que tiene t informacin ac cerca de lo os distintos s empleados del ban nco y no a otro tipo de d informacin. In nstancias y esquem mas Con el paso de el tiempo la l informac cin que se e va acum mulando y d desechand do en la ba ase de dato os, ocasiona que est t cambie. Insta ancia. Es el e estado que prese enta una base b de da atos en un n tiempo dado. d Vem moslo com mo una foto ografa que e tomamos s de la bas se de datos en un tie empo t, de espus de que q transc curre el tiem mpo t la ba ase de dato os ya no e es la misma a. Esqu uema. Es s la descr ripcin lg gica de la a base de e datos, p proporciona a los nom mbres de la as entidad des y sus atributos especifica ando las r relaciones que exist ten entre ellos. Es un u banco en el que e se inscrib ben los va alores que e irn form mando cada a uno de lo os atributo os. El esqu uema no ca ambia los que varan n son los datos d y con n esto tene emos una nueva n insta ancia. Ejem mplo: Cons siderando el ejemp plo del ve endedor que q vende e artculos s, esquem ma e insta ancia segn nuestro ejemplo, quedara: q Esqu uema: {V Vendedor: Nombre, puesto, p salario, RFC} } {A Articulo: Cla ave, costo, descripcin} Insta ancia:

Com mo podemo os observa ar el esque ema nos muestra m la estructura a en el cual se alma acenaran los datos, en este caso c en reg gistros cuy yos nombr res de cam mpos son: por parte e del vendedor (Nom mbre, pues sto, salario o, RFC) y por el art tculo (Clav ve, costo, , descripcin); La instancia representa r a a una s serie de datos d alma acenados en e los regi istros establecidos por p el esqu uema, esto os datos va aran, no permanece p en fijos en el e tiempo.

ACT TORES EN N LOS SIST TEMAS DE BASES DE DATO OS Adm ministrado or de Base es de Dato os. Deno ominado por sus siglas s com mo: DBA, Database e Adminis strator. Es E la pers sona encar rgada y que tiene el e control total t sobre e el sistem ma de bas se de dato os, sus func ciones prin ncipales so on:

nicin de esquema. e Define el esquema e original o de e la base de datos el cual Defin se crea c escrib biendo un conjunto de definic ciones que son trad ducidas por el compilador de DDL a un con njunto de e tablas que son almacenadas perm manenteme ente en el diccionario o de datos. Defin nicin de la estructura de almacena amiento del d mtodo de acc ceso. Estru ucturas de e almacena amiento y de acceso o adecuad dos se cre ean escribiendo un conjunto c de e definiciones que son traducidas por el compilado or del leng guaje de almacenam a miento y de efinicin de e datos. Con ncesin de e autorizaci in para el l acceso a los datos. Permite a al administr rador de la a base de e datos reg gular las partes p de las bases de datos que van a ser acce edidas por varios usu uarios. Espe ecificacin de limitan ntes de inte egridad. Es una serie e de restric cciones qu ue se encu uentran al lmacenado os en una a estructu ura especial del sis stema que e es cons sultada po or el gesto or de bas se de datos cada vez v que s se realice una actualizacin al a sistema.

Us suarios de e Bases de e Datos Pod demos def finir a los usuarios como c toda a persona que tenga todo tip po de cont tacto con el e sistema de base de d datos desde d que este se disea, elab bora, term mina y se us sa. Los s usuarios que q accedan una base de dato os pueden clasificarse como:

Program madores de aplicaciones. Los profes sionales en computa acin

que int teractan con el sistema s po or medio de llama adas en DML (Lengua aje de Man nipulacin de Datos) ), las cuale es estn in ncorporada as en un prog grama esc crito en un lenguaje e de prog gramacin (Por ejem mplo, COBOL L, PL/I, Pas scal, C, etc c.)

 Usuarios sofisticados. Los usuarios sofisticados interactan con el

sistema sin escribir programas. En cambio escriben sus preguntas en un lenguaje de consultas de base de datos. aplicaciones de base de datos especializadas que no encajan en el marco tradicional de procesamiento de datos.

Usuarios especializados. Algunos usuarios sofisticados escriben Usuarios ingenuos. Los usuarios no sofisticados interactan con el
sistema invocando a uno de los programas de aplicacin permanentes que se han escrito anteriormente en el sistema de base de datos, podemos mencionar al usuario ingenuo como el usuario final que utiliza el sistema de base de datos sin saber nada del diseo interno del mismo por ejemplo: un cajero.

1.2. ANALISIS DE REQUERIMIENTOS DE BASES DE DATOS La recoleccin de datos se refiere al uso de una gran diversidad de tcnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de informacin, los cuales pueden ser la observacin, la entrevistas, el cuestionario, la encuesta, el diagrama de flujo y el diccionario de datos. Estos instrumentos se aplican en un momento en particular, con la finalidad de buscar informacin que ser til.

1.2.1. TCNICAS DE RECOLECCION DE DATOS Los analistas utilizan una variedad de mtodos a fin de recopilar los datos sobre una situacin existente, como la observacin, entrevistas y cuestionarios entre otros. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigacin completa. 1.2.1.1. OBSERVACIN Como tcnica de investigacin, la observacin tiene amplia aceptacin cientfica. Los socilogos, siclogos e ingenieros industriales utilizan extensamente sta tcnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organizacin. El propsito de la organizacin es mltiple: permite al analista determinar que se est haciendo, como se est haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dnde se hace y por que se hace. Tipos de Observacin El analista de sistemas puede observar de tres maneras bsicas. Primero, puede observar a una persona o actitud sin que el observado se d cuenta y su interaccin por aparte del propio analista. Quiz esta alternativa tenga poca 10

importancia para el anlisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operacin sin intervenir para nada, pero estando la persona observada enteramente consciente de la observacin. Por ltimo, puede observar y a la vez estar en contacto con las personas observadas. La interaccin puede consistir simplemente en preguntar respecto a una tarea especfica, pedir una explicacin, etc. Preparacin para la observacin 1. 2. 3. 4. Determinar y definir aquella que va a observarse. Estimular el tiempo necesario de observacin. Obtener la autorizacin para llevar a cabo la observacin. Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello.

Conduccin de la observacin 1. Familiarizarse con los componentes fsicos del rea inmediata de observacin. 2. Mientras se observa, medir el tiempo en forma peridica. 3. Anotar lo que se observa lo ms especficamente posible, evitando las generalidades y las descripciones vagas. 4. Si se est en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o que impliquen un juicio de valores. 5. Observar las reglas de cortesa y seguridad. Secuela de la observacin 1. Documentar y organizar formalmente las notas, impresionistas, etc. 2. Revisar los resultados y conclusiones junto con la persona observada, el supervisar inmediato y posiblemente otro de sistemas.

1.2.1.2. ENTREVISTA Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarn datos o sern afectados por la aplicacin propuesta. El analista puede entrevistar al personal en forma individual o en grupos. Dentro de una organizacin, la entrevista es la tcnica ms significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevista es un intercambio de informacin que se efecta cara a cara. Es un canal de comunicacin entre el analista y la organizacin; sirve para obtener informacin acerca de las necesidades y la manera de satisfacerlas, as como consejo y comprensin por parte del usuario para toda idea o mtodo nuevos. Preparacin de la Entrevista 11

1. Determinar la posicin que ocupa de la organizacin el futuro entrevistado, sus responsabilidades bsicas, actividades, etc. 2. Preparar las preguntas que van a plantearse, y los documentos necesarios. 3. Fijar un lmite de tiempo y preparar la agenda para la entrevista. 4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad. 5. Hacer la cita con la debida anticipacin. Conduccin de la Entrevista 1. Explicar con toda amplitud el propsito y alcance del estudio. 2. Explicar la funcin propietaria como analista y la funcin que se espera conferir al entrevistado. 3. Hacer preguntas especficas para obtener respuestas cuantitativas. 4. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares. 5. Evitar el cuchicheo y las frases carentes de sentido. 6. Ser corts y comedio, abstenindose de emitir juicios de valores. 7. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestin. 8. Escuchar atentamente lo que se dice, guardndose de anticiparse a las respuestas. La entrevista es una forma de conversacin, no de interrogacin, al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no estn disponibles en ningn otra forma. Son valiosas las opiniones, comentarios, ideas o sugerencia en relacin a como se podra hacer el trabajo; la entrevista a veces es la mejor forma para conocer las actividades de las empresas. La entrevista pueden descubrir rpidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; ms an, a menudo es ms fcil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen cuestionario. Las entrevistas estructuradas utilizan pregunta estandarizada. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas para respuestas abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiado. Pueden contestar por completo con sus propias palabras. Con las preguntas para respuesta cerradas se proporcionan al usuario un conjunto de respuesta que se pueda seleccionar. Todas las personas que respondes se basan en un mismo conjunto de posibles respuestas. Los analistas tambin deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuestas. La entrevista no estructurada no requiere menos tiempos de preparacin, porque no necesita tener por anticipado las palabras precisas de las preguntas. Analizar las respuestas despus de la entrevista lleva ms tiempo que con la entrevista estructuradas. El mayor costo

12

radica en la preparacin, administracin y anlisis de las entrevistas estructuradas para pregunta cerradas. Ejemplos de las preguntas abiertas y cerradas en la entrevista estructurada FORMA DE PREGUNTA ABIERTA FORMA DE PREGUNTA CERRADA

Ejemplo: obtener la informacin sobre Ejemplo: obtener la informacin sobre las caractersticas de diseos crticas las para los empleados. Caractersticas de diseo crticas para " algunos empleados han sugerido que los empleados. la mejor forma para hacer eficiente el " La experiencia le ha proporcionado procesamiento de pedidos es instalar una amplia visin en cuanto a la forma un sistema de computadora que en la que la empresa maneja los maneje todos los clculos..." pedidos..." Me gustara que usted bajo estas circunstancias apoyara contestara algunas preguntas usted el desarrollo de un sistema de especficas en relacin en lo anterior: este tipo?. -Qu etapas trabajas bien?cules no -En donde se presenta la mayor parte del problema? - Cundo ocurre un atraso, cmo se maneja? Entre otros

La habilidad del entrevistador es vital para el xito en la bsqueda de hecho por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparacin del objetivo de una entrevista especfica como de las preguntas por realizar a una persona determinada. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. Por ejemplo, analista que trabaja en la aplicacin enfocada a la reduccin de errores (captado por la gerencia de alto nivel) probablemente no tendra xito si llegara a una oficina de gerencia de nivel medio con la presentacin equivocada, ejemplo "Estamos aqu para resolver su problema". A travs de la entrevista, los analistas deben preguntarse a s mismo las siguientes preguntas:
o o o o

Qu es lo que me est diciendo la persona? Por qu me lo est diciendo a m ? Qu est olvidando? Qu espera est persona que haga yo?

13

1.2.1.3. CUESTIONARIOS Los cuestionarios proporcionan una alternativa muy til para la entrevista; si embargo, existen ciertas caractersticas que pueden ser apropiadas en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben disearse cuidadosamente para una mxima efectividad. Recabacin de datos mediante cuestionarios Para los analistas los cuestionarios pueden ser la nica forma posible de relacionarse con un gran nmero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se pueden distribuir los cuestionarios a todas las personas apropiadas para recabar hechos en relacin al sistema. En la mayor parte de los casos, el analista no ver a los que responden; no obstante, tambin esto es una ventaja porque aplicar muchas entrevistas ayuda a asegurar que el interpelado cuenta con mayor anonimato y puedan darse respuestas mas honesta. Seleccin de formas para cuestionarios El desarrollo y distribucin de los cuestionarios; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. Tambin es importante el formato y contenido de las preguntas en la recopilacin de hechos significativos. Existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados, y se aplican dependiendo de que si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas. Con frecuencia se utilizan ambas formas en los estudios de sistemas. Cuestionario Abierto Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; tambin son tiles al explorar el problema bsico, por ejemplo, un analista que utiliza cuestionarios para estudiar los mtodos de verificacin de crdito, es un medio. El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin embargo, encuentran ms fcil escoger una de un conjunto de respuestas preparadas que pensar por s mismas. Cuestionario Cerrado El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mtodo para obtener informacin sobre los hechos.

14

1.2.2. CLASIFICACIN Y ESTRUCTURA BSICA DE DATOS Es importante ir clasificando informacin a medida que se va investigando para tenerla organizada. Una estructura de datos es una clase de datos que se puede caracterizar por su organizacin y operaciones definidas sobre ella. Algunas veces a estas estructuras se les llama tipos de datos. Entre ellas encontramos las siguientes: Estructuras lgicas de datos: En un programa, cada variable pertenece a alguna estructura de datos explcita o implcitamente definida, la cual determina el conjunto de operaciones validas para ella. Las estructuras de datos que se discuten aqu son estructuras de datos lgicas. Cada estructura de datos lgica puede tener varias representaciones fsicas diferentes para sus almacenamientos posibles. Estructuras primitivas y simples: Son primitivas aquellas que no estn compuestas por otras estructuras de datos por ejemplo, enteros, booleanos y caracteres. Otras estructuras de datos se pueden construir de una o mas primitivas. Las estructuras de datos simples que consideramos se construyen a partir de estructuras primitivas y son: cadenas, arreglos y registros. A estas estructuras de datos las respaldan muchos lenguajes de programacin. Estructuras lineales y no lineales: Las estructuras de datos simples se pueden combinar de varias maneras para formar estructuras ms complejas. Las dos cases principales de estructuras de datos son las lineales y las no lineales, dependiendo de la complejidad de las relaciones lgicas que representan. Las estructuras de datos lineales incluyen pilas, colas y listas ligadas lineales. Las estructuras de datos no lineales incluyen grafos y rboles.

15

UNIDAD 2 MODELO ENTIDAD RELACIN (E-R) 2.1. EL MODELO ENTIDAD-RELACIN 2.1.1. ENTIDADES Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de entidades, que son objetos que existen y que se distinguen de otros por sus caractersticas, por ejemplo: un alumno se distingue de otro por sus caractersticas particulares como lo es el nombre, o el numero de control asignado al entrar a una institucin educativa, as mismo, un empleado, una materia, etc. Las entidades pueden ser de dos tipos: Tangibles : Son todos aquellos objetos fsicos que podemos ver, tocar o sentir. Intangibles: Todos aquellos eventos u objetos conceptuales que no podemos ver, aun sabiendo que existen, por ejemplo: la entidad materia, sabemos que existe, sin embargo, no la podemos visualizar o tocar. Las caractersticas de las entidades en base de datos se llaman atributos, por ejemplo el nombre, direccin telfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, nmero de seguro social, departamento, etc., son atributos de la entidad empleado. 2.1.2 RELACIONES Una entidad se puede asociar o relacionar con ms entidades a travs de relaciones, Una relacin es la asociacin que existe entre dos a ms entidades. 2.1.3 ATRIBUTOS De cada entidad se almacenan una serie de datos que se denominan atributos de la entidad. Pueden ser atributos de una entidad cualquier caracterstica o propiedad de sta. Son atributos de la entidad libros: Autor, Ttulo, rea de Edicin, ISBN. Pero para entender mejor esto, veamos un ejemplo: Consideremos una empresa que requiere controlar a los vendedores y las ventas que ellos realizan; de este problema determinamos que los objetos o entidades principales a estudiar son el empleado (vendedor) y el artculo (que es el producto en venta), y las caractersticas que los identifican son:

16

Em mpleado: Nom mbre Pue esto Sal lario R.F F.C.

Artculo: : Descripcin Costo Clave

La re elacin ent tre ambas entidades la podemo os establecer como V Venta. Bueno, ah B hora nos falta f desc cribir como o se repr resenta un n modelo E-R grfi icamente, la represe entacin es e muy se encilla, se e emplean smbolos s, los cuales son: mbolo S Rep presenta

As s nuestro ejemplo anterior que edara repr resentado de la siguiente forma a:

2.2 RESTRICC R CIONES DE D ASIGNA ACIN Existen 4 tipos de relac ciones qu ue pueden establece erse entre entidades s, las cuales estable ecen con cuantas c en ntidades de e tipo B se pueden relacionar r una entid dad de tipo o A:

no a uno. Relacin un

17

e presenta a cuando existe e una relacin r co omo su nom mbre lo ind dica uno a uno, Se deno ominado ta ambin relacin de matrimonio. Una en ntidad del tipo A sol lo se pued de relacion nar con una a entidad del d tipo B, y viceversa; Por ejemp P plo: la relacin asig gnacin de d autom vil que c contiene a las entid dades EMPLEADO, AUTO, es una rela acin 1 a 1, ya que asocia a un emp pleado con un nico automvil por lo tanto ningn empleado posee m s de un automvil a a asignado, y ningn ve ehculo se asigna a ms m de un trabajador r. Es representa ado grfica amente de la siguiente manera a:

A: Representa R a a una ent tidad de cualquier tip po diferent te a una entida ad B. R: en el diagra ama repres senta a la relacin r qu ue existe entre e las en ntidades. El ex xtremo de la flecha que q se enc cuentra pun nteada indica el uno de la relac cin, en este e caso, una u entida ad A ligada a una entidad B. Relacin un no a much hos. S Significa que una entidad e de el tipo A puede p rela acionarse con cualquier cant tidad de entidades del d tipo B, , y una en ntidad del tipo B solo puede estar relac cionada co on una enti idad del tip po A. Su representac cin grfic ca es la siguiente:

e caso que el extr remo punt teado de la a flecha de e la relaci n de Ntese en este A y B, B indica una entidad d A conecta ada a muc chas entida ades B.

M Muchos a uno. u Ind dica que una u entidad d del tipo B puede relacionars r se con cua alquier cantidad de entidades e del tipo A, A mientras que cad da entidad d del tipo A solo puede relac cionarse co on solo una entidad del d tipo B. 18

M Muchos a muchos. m Es stablece que q cualqu uier cantid dad de en ntidades del d tipo A pueden estar relac cionados con c cualquier cantida ad de entidades del ti ipo B.

A los tipos s de relac ciones ant tes descritos, tambin se le conoce como c card dinalidad. L cardinal La lidad nos especifica e los tipos de d relacion nes que ex xisten entr re las entid dades en el e modelo E-R y esta ablecer co on esto las s validacion nes necesarias para a conseguir que los datos d de la a instancia a (valor ni ico en un momento dado de una u base de datos) co orresponda an con la realidad. r Algu unos ejemp plos de car rdinalidade es de la vid da comn pueden p se er: Uno o a uno. El noviazgo, el RFC E C de cada a persona a, El CUR RP persona al, El acta a de nacimiento, ya a que solo existe un solo docu umento de este tipo para cada a una as diferente es persona as. de la Uno o a muchos. Cl liente Cuenta en un banco, , Padre-Hi ijos, Camin-Pasajeros, zoologicoanim males, rbo ol hojas. Muc chos a mu uchos. Arquitecto proyectos, fiesta personas, p estudiante e s. materias 2.3 CLAVES C La distincin d d una entidad entre otra se de de ebe a sus atributos, a lo o cual lo hacen nico o. Una llave primar ria es aque el atributo el cual con nsideramo os clave pa ara la 19

d los dem ms atributo os que des scriben a la a entidad. Por ejemp plo, si identificacin de sideramos la entidad d ALUMNO O de la UT TP, podramos tener r los siguie entes cons atrib butos: Nom mbre, Cuatr rimestre, Especialida E ad, Direcci n, Telfono, Nmer ro de regis stro, de tod dos estos atributos a e que podr el remos designar como o llave prim maria es el e nmero de registr ro, ya que e es difere ente para cada c alum mno y este e nos identifica en la a institucin n. Claro que puede C p hab ber ms de d un atrib buto que pueda p iden ntificarse como c llave e primaria en e este ca aso se sele ecciona la que q consid deremos m ms importante, los dems d atrib butos son denominad dos llaves s secundar rias. Una clave o llave primaria es indicada U i grficament te en el m modelo E-R R con una lnea deba ajo del nom mbre del at tributo. Reduccin de e diagrama as E-R a tablas Un diagrama d E E-R, puede ser representado tambin t a travs de e una colec ccin de ta ablas. Para a cada una a de las entidades y relacione es existe u una tabla nica a la que se le e asigna como nom mbre el de el conjunto o de entid dades y de e las relac ciones respectivamente, cada tabla tiene e un nme ero de colu umnas que e son defin nidas por la a cantidad de atributos y las cu uales tienen el nombr re del atrib buto. La transform macin de e un ejemplo de una Venta en e la que intervienen n las dades de Vendedor r con los atributos RFC, nombre, pue esto, salario y entid Artc culo con los atributos s Clave, de escripcin, costo. Cuyo o diagrama a E-R es el e siguiente e:

Entonces s las tablas s resultante es siguiend do la descripcin ant terior son: Tab bla Empleado Nombre e Puesto Tefilo Cesar Tabl la artculo o Clave Descripci D n Costo A100 Abanico A 460 20 Auxiliar ventas Salario RFC TEAT701210XYZ COV7411 120ABC

Vendedo or 2000 1200

C260 Tabla Venta RFC

Colcha 1200 matrimonial

Clave

TEAT701210XYZ C260 COV741120ABC A100 Ntese que en la tabla de relacin - Venta, contiene como atributos a las llaves primarias de las entidades que intervienen en dicha relacin, en caso de que exista un atributo en las relaciones, este atributo es anexado como una fila ms de la tabla; Por ejemplo si anexamos el atributo fecha a la relacin venta, la tabla que se originaria sera la siguiente: RFC Clave Fecha

TEAT701210XYZ C260 10/12/96 COV741120ABC A100 11/12/96

Generalizacin. Es el resultado de la unin de 2 o ms conjuntos de entidades (de bajo nivel) para producir un conjunto de entidades de ms alto nivel. La generalizacin se usa para hacer resaltar los parecidos entre tipos de entidades de nivel ms bajo y ocultar sus diferencias. La generalizacin consiste en identificar todos aquellos atributos iguales de un conjunto de entidades para formar una entidad(es) global(es) con dichos atributos semejantes, dicha entidad(es) global(es) quedara a un nivel ms alto al de las entidades origen. Ejemplo: Tomando el ejemplo del libro de fundamentos de base de datos de Henry F. Korth. Donde: Se tiene las entidades Cta_Ahorro y Cta_Cheques, ambas tienen los atributos semejantes de No_Cta y Saldo, aunque adems de estos dos atributos, Cta_Ahorro tiene el atributo Tasa_Interes y Cta_Cheques el atributo Saldo_Deudor. De todos estos atributos podemos juntar (generalizar) No_Cta y Saldo que son iguales en ambas entidades. Entonces tenemos: 21

P Podemos l leer esta grfica co omo: La entidad e Ct ta_Ahorro hereda de d la entid dad CUEN NTA los atributos a No_Cta y saldo, adems a del atributo o de Tasa aInteres, de d forma semejante s Cta_cheq que tiene los l atributo os de No_ _Cta, Sald do y SaldoD Deudor. Como pode C emos obse ervar la Ge eneralizacin trata de e eliminar la redunda ancia (repe eticin) de e atributos, al engloba ar los atributos seme ejantes. La entidad(es) de bajo nivel cuen ntan (hered dan) todos s los atribut tos corresp pondientes s. Esp pecializaci n E el resu Es ultado de tomar t un subconjunt s to de entid dades de alto nivel para form mar un conjunto de en ntidades de e ms bajo o nivel. * En la ge eneralizaci n cada entidad e de e alto nivel debe se er tambin una entid dad de bajo o nivel. La especializ zacin no tiene t este limitante. l * Se represe enta por medio m de un n tringulo o denomina ado con la etiqueta "ISA", se distingue d d la generalizacin por el gro de osor de las s lneas qu ue conecta an al trin ngulo con la as entidades. * La especia alizacin denota d la diferencia d entre e los co onjuntos de entidade es de alto y bajo nive el. 2.4 MODELO M E ENTIDAD - RELACI IN EXTE ENDIDO En el e modelo de datos Entidad-Relacin Ex xtendido se e incluyen los conce eptos lacin y se del modelo Entidad-Re E s incorpo oran los conceptos c de Subc clase, Supe erclase con los conc ceptos asoc ciados de Especializacin y Ge eneralizacin.

22

2.4.1. SUBCLASE Y SUPERCLASE En el modelo ERE, 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 propsitos de la Base de Datos y, por tanto, deberan representarse de forma explcita. Por ejemplo, la entidad EMPLEADO puede a su vez subdividirse en SECRETARIA, INGENIERO, JEFE, TCNICO, 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 tambin 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 relacin existente entre las Superclases y las Subclases como relacin Clase/Subclase. En el ejemplo anterior, EMPLEADO/SECRETARIA y EMPLEADO/TCNICO 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 "Lety Lpez" ser tambin la EMPLEADO "Lety Lpez". Por tanto, la ocurrencia de Subclase es la misma que en la Superclase pero con un rol especfico. 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. Modelo De Datos Orientadas A Objetos. Las aplicaciones de las bases de datos en reas como el diseo asistido por computadora, la ingeniera de software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones. El modelo de bases de datos orientado a objetos es una adaptacin a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y cdigo que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensin del concepto ISA del modelo Entidad Relacin. Puesto que el valor de un dato en un objeto tambin es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.

23

El propsito de los sistemas de bases de datos es la gestin de grandes cantidades de informacin. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestin de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerrquicas y, ms tarde, en bases de datos relacionales. Estructura de objetos. El modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. Un objeto tiene asociado:

un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto. Un conjunto de mensajes a los que el objeto responde. Un mtodo, que es un trozo de cdigo para implementar cada mensaje. Un mtodo devuelve un valor como respuesta al mensaje. El trmino mensaje en un contexto orientado a objetos, no implica el uso de un mensaje fsico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles especficos de implementacin. La capacidad de modificar la definicin de un objeto sin afectar al resto del sistema est considerada como una de las mayores ventajas del modelo de programacin orientado a objetos. Las clases en un sistema orientado a objetos se representan en forma jerrquica, as que las propiedades o caractersticas del elemento persona las contendrn (heredaran) los elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar al utilizado en la de especializacin (la relacin ISA) del modelo E-R. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo as que una jerarqua (en forma grfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan. 2.4.2 HERENCIA Herencia De Atributos En La Relacin Clase/Subclase. Debido a que una subclase es a su vez parte se una superclase, la subclase tendr sus atributos especficos 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. 24

2.4.3 ESPECIALIZACIN El proceso por el que se definen las diferentes subclases de una superclase se conoce como especializacin. El conjunto de subclases se define basndonos en caractersticas diferenciadoras de las ocurrencias de entidad de la superclase. Por ejemplo, el conjunto se subclases {SECRETARIA, INGENIERO, TECNICO} es una especializacin de la superclase EMPLEADO mediante la distincin del tipo de trabajo en cada ocurrencia de entidad. Podemos tener varias especializaciones de una misma entidad basndonos en distintos criterios. Por ejemplo, otra especializacin de EMPLEADO podra dar lugar a las subclases ASALARIADO y SUBCONTRATADO, dependiendo del tipo de contrato.

Diagramas ERE. La figura 1 muestra como se representa la especializacin en un diagrama ERE. Las subclases definidas por una especializacin estn unidas mediante lneas a un circulo, que conecta con la superclase. El smbolo de pertenencia en las lneas entre las subclases y el circulo representan la direccin de la relacin clase/subclase. Los atributos aplicables solamente a cada una de las subclases se unen a estas mediante arcos (por ejemplo, velocidad en la subclase SECRETARIA). Estos atributos se denominan atributos especficos de la subclase. Las subclases tambin pueden tener relaciones especificas con otras entidades (por ejemplo, la relacin PERTENECE entre SUBCONTRATADO y EMPRESA).

25

Figura 1

Utilizacin de subclases en los modelos de datos. Hay dos razones principales para el uso de la relacin clase/subclase en los modelos de datos. La primera es que ciertos atributos no pueden ser aplicados a todas las ocurrencias de entidad correspondiente a la superclase. Una subclase se define para agrupar aquellas ocurrencias de entidad donde el atributo es aplicable. Suele ocurrir que las subclases comparten la mayora de los atributos correspondientes a la superclase. Por ejemplo, SECRETARIA tiene el atributo de velocidad mientras que INGENIERO tiene tipo, sin embargo ambos comparten los mismos atributos de EMPLEADO. La segunda razn para la utilizacin de subclases es que algunas relaciones pueden tener sentido solo para algunas ocurrencias de entidad de la superclase. Por ejemplo, si solo los empleados subcontratados pueden pertenecer a otras empresas, podremos representar este hecho mediante la creacin de la subclase SUBCONTRATADO y relacionarla con la entidad EMPRESA mediante la relacin PERTENECE, como se puede ver en la figura 1.

2.4.4 GENERALIZACIN El proceso de especializacin expuesto en el punto anterior nos permite lo siguiente: Definir un conjunto se subclases a partir de una entidad. 26

 Asociar atributos especficos a cada subclase. Establecer relaciones especficas entre cada subclase con otras entidades o subclases. Podemos pensar en un proceso inverso de abstraccin en el cual suprimimos las diferencias entre las distintas entidades, identificando sus caractersticas comunes, y generalizando dichas entidades en una sola superclase de la cual las entidades iniciales seran subclases especiales. Por ejemplo, supongamos las entidades COCHE y CAMION de la figura 2(a); podremos generalizarlas en la entidad VEHICULO, como se muestra en la figura 2(b). Tanto COCHE como CAMION sern ahora subclases de la superclase generalizada VEHICULO. Usamos el trmino generalizacin para referirnos al proceso de definicin de una entidad generalizada a partir de unas entidades dadas.

Hay que tener en cuenta que el proceso de generalizacin puede ser visto funcionalmente como el proceso inverso de especializacin. Por tanto, en la figura 2 podemos ver {COCHE, CAMION} como una especializacin de VEHICULO, as como VEHICULO puede verse como la generalizacin de COCHE y CAMION. De la misma forma podemos ver en la figura 1 a EMPLEADO como la generalizacin de SECRETARIA, TCNICO e INGENIERO. En algunas ocasiones se utilizan flechas para representar en los diagramas ERE cual a sido la tcnica de identificacin de superclases/clases. Consultas orientadas a objetos: Los lenguajes de programacin orientados a objetos requieren que toda la interaccin con objetos se realiza mediante el envo de mensajes. 27

Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la materia de Base de Datos I, para realizar esta consulta se tendra que enviar un mensaje a cada instancia alumno As un lenguaje de consultas para un sistema de bases de datos orientado a objetos debe incluir tanto el modelo de pasar el mensaje de objeto a objeto como el modelo de pasar el mensaje de conjunto en conjunto. Complejidad de Modificacin. En base de datos orientados a objetos pueden existir los siguientes cambios:

Adicin de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la jerarqua de clase o subclase cuidando las variables o mtodos de herencia correspondientes. Eliminacin de una clase: Se requiere la realizacin de varias operaciones, se debe de cuidar los elementos que se han heredado de esa clase a otras y reestructurar la jerarqua. En s la estructuracin de modelos orientados a objetos simplifica una estructura evitando elementos o variables repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando en modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar una reestructuracin que involucra una serie de pasos complejos.

2.5 EJERCICIOS 1. Disear un modelo E-R para la relacin Registro de Automvil que consiste en obtener la tarjeta de circulacin de un automvil con los siguientes datos: Automvil: modelo, placas y color. Tarjeta de Circulacin: propietario, nmero de serie y tipo. 2. Disear el modelo E-R para el registro de los pases, indicando su nmero de habitantes y dimensin, as como el nombre, direccin y partido del presidente actual. 3. Disear un modelo E-R que indique que un cliente puede abrir muchas cuentas, para que una cuenta solo pertenezca a un cliente. DATA CLIENTE: Nom, CURP, Dir. DATA CTA : Tipo CTA, Num CTA, Saldo APERTURA: Fecha.

28

4. Disear un modelo E-R que indique los estudiantes que un maestro puede tener o los maestros que un estudiante puede tener en el cuatrimestre donde cada alumno lleva 6 materias diferentes. 5. Disear un modelo E-R que registre la venta de artculos, conociendo las caractersticas del empleado que realizo la venta, al realizar la venta se agrego la fecha y el nombre del cliente. 6. Disear un modelo E-R bajo las siguientes condiciones: Existen varios empleados trabajando en diferentes proyectos, pero dependiendo del trabajo que realiza puede llegar a utilizar un equipo o maquinaria, Entidades: empleado, proyecto y maquinaria. La entidad (relacin) trabajo debe relacionarse con la entidad maquinaria. 7. Elaborar diagrama E-R para una oficina de registro de una universidad mantiene datos acerca de todo curso: profesor, matricula, hora y lugar. Para cada est-curso se almacena una calificacin. Documenta las ligaduras hechas. 8. Elaborar diagrama E-R para una compaa de seguros de coches , que tiene un conjunto de clientes, quienes pueden tener 1 o varios coches, cada coche tiene asociado el nmero de accidentes, si sucede. 9. Elaborar diagrama E-R para un hospital con un conjunto de pacientes y un conjunto de mdicos, asociar cada paciente con un registro de los diferentes exmenes realizados. 10. Elaborar diagrama E-R para un negocio de equipo electrnico, tenemos una entidad con las descripciones del equipo existente (la principal) lo que se encuentra en nico almacn, debemos conocer los pedidos, las ventas y los clientes, cada entidad con un mnimo de 3 atributos. Debe haber 3 relaciones que nos muestran la existencia, la elaboracin de solicitudes y de facturas, con 2 relaciones de grado 2 y una de grado 3. 11. Disear un diagrama E-R para una escuela, con departamento escolar, biblioteca y departamento deportivo. Existe una entidad principal con los datos de todos los alumnos, el departamento escolar se encarga de asignar grupo a cada alumno y con una entidad de materias se asignan 5 materias a cada grupo. En la biblioteca existe una entidad de libros para poder registrar los pedidos y el departamento deportivo tiene que registrar a todos los alumnos a un deporte especfico que no depende del grupo en que se encuentre.

29

UNIDAD 3 MODELO RELACIONAL. 3.1 Conceptos del modelo Relacional. Modelo de datos: es una coleccin de herramientas conceptuales para la descripcin de de datos, relaciones entre datos, semntica de los datos y restricciones de consistencia. Relacin: es el elemento bsico del modelo relacional y se puede representar como una tabla. Modelo relacional: El modelo relacional ofrece una manera nica de representar los datos: como una tabla bidimensional denominada relacin, dicha relacin contiene atributos. Nombre Esteban Bentez Prez Luis Flores Aguilar Virginia Prez Ruiz 3.1.1 Atributos. Un atributo es una caracterstica o cualidad de una entidad o relacin, que cae dentro del alcance del sistema, acerca del cual el sistema debe mantener, correlacionar y desplegar la informacin. Los atributos sirven de nombre a las columnas de la relacin; es decir, generalmente describen el significado de las entradas de las columnas situada debajo de ellos. Nombre Telefono CP Telefono 2654554 2547823 2356897 CP 72600 Relacin 72450 Cliente 78458

Existen diferentes tipos de atributos como son: Atributos simples y compuestos. Los atributos simples no estn divididos en subpartes; es decir, en otros atributos. Los atributos compuestos, en cambio, se pueden dividir en subpartes, por ejemplo: Nombre podra estar estructurado como un atributo compuesto que consiste en nombre, apellido-paterno, apellido-materno. Atributos univalorados y multivalorados. Los atributos univalorados tienen un solo valor para una entidad concreta, por ejemplo el atributo CP para una entidad cliente especfico, referencia un nico cdigo postal. Se considera un atributo multivalorado porque en ocasiones un atributo tiene un conjunto de valores para una entidad especfica, en el caso de un conjunto de entidades empleado con el atributo nombresubordinado, cualquier empleado particular puede tener, uno o ms subordinados; por lo tanto, diferentes entidades empleado dentro del conjunto de entidades tendrn diferentes nmeros de valores para el atributo nombre-subordinado.

30

Atributos nulos. Se usa cuando una entidad no tiene un valor para un atributo. Por ejemplo, si un empleado en particular no tiene subordinados, el valor nombre-subordinado para este empleado ser nulo. Atributo derivado. El valor para este tipo de atributo se puede derivar de los valores de otros atributos o entidades. Por ejemplo: considrese que el conjunto de entidades empleado tiene como atributos fechacomienzo y antigedad, que representan el primer da en que el empleado comenz a trabajar para el banco y el tiempo total en que el empleado lleva trabajando para el banco, respectivamente, el valor de antigedad se puede derivar del valor de fecha-comienzo y de la fecha actual. En este caso, fecha comienzo se puede referenciar como un atributo base o atributo almacenado.

3.1.2 Dominios. Un dominio D es un conjunto finito de valores homogneos y atmicos V1, V2, , Vn, caracterizado por un nombre, decimos valores homogneos porque son todos del mismo tipo y atmicos porque son indivisibles en lo que al modelo se refiere; es decir, si se descompusiesen, perderan la semntica a ellos asociada.2 Por ejemplo podemos definir el dominio materias, cuyo conjunto de valores podra ser: Bases de Datos, Sistemas Operativos, Lenguajes de programacin, matemticas, etc. Si A es un atributo y D es su dominio, entonces esto se puede denotar de la siguiente manera: D=Dom (A) El modelo relacional exige que los componentes de una tupla sean atmicos; es decir, que pertenezcan a algn tipo elemental como enteros o cadenas de caracteres. No se permite que un valor sea una estructura de registro, un conjunto, una lista, un arreglo o cualquier otro tipo que pueda tener sus valores divididos en componentes ms pequeos. 3.1.3 Tuplas. A los renglones de una relacin, si no son el rengln del encabezado que contiene los atributos, se les da el nombre de tuplas. Una tupla tiene un componente para cada uno de los atributos de la relacin. Cuando queramos escribir una tupla aislada, no como parte de una relacin, normalmente separaremos con comas los componentes y pondremos parntesis alrededor de la tupla, por ejemplo: (Esteban Bentez Prez, 2654554, 72600) Las tuplas representan los objetos y la relacin a la que pertenecen representa su clase, en el ejemplo anterior cada tupla representa un objeto cliente.

31

3.1.4 Relaciones El elemento central del modelo relacional es la relacin. Una relacin tiene un nombre, un conjunto de atributos que representan sus propiedades y un conjunto de tuplas que incluyen los valores que cada uno de los atributos toma para cada elemento de la relacin. No se deben confundir los conceptos de tabla y de relacin, ya que una tabla es solo una forma de representar a una relacin. Y adems: No puede haber dos tuplas iguales. El orden de las tuplas no es significativo. El orden de los atributos no es significativo. Cada atributo solo puede tomar un nico valor de su dominio correspondiente. 3.2 Esquema de una relacin. Se pueden distinguir dos conceptos ligados a la notacin de la relacin: Intencin de una relacin: Parte definitoria y esttica de la relacin, es a lo que se le llama esquema de relacin. Es invariable en el tiempo. Cliente (nombre: int; telfono: varchar(60), CP:varchar(10)) Extensin: Conjunto de tuplas que en un instante determinado, satisfacen el esquema de la relacin y se encuentran almacenadas en la base de datos. Normalmente se le llama simplemente relacin. Cambia en el transcurso del tiempo. Nombre Esteban Bentez Prez Luis Flores Aguilar Virginia Prez Ruiz Telfono 2654554 2547823 2356897 CP 72600 72450 78458

Tanto el esquema como las tuplas de una relacin son conjuntos, no listas; y de ah que no importe el orden en que sean presentadas. Se pueden enumerar las tuplas en cualquiera de sus rdenes posibles y la relacin sigue siendo la misma. Esteban Bentez Prez 2654554 2654554 2654554 72600 72600

Esteban Bentez Prez 72600

Esteban Bentez Prez

A la cantidad de tuplas que existen dentro de la relacin se le conoce como cardinalidad; es decir, es el nmero total de renglones de la relacin. La clasificacin de las relaciones se da en dos grupos: Relaciones nominadas y relaciones sin nombre. 32

3.2.1 Relaciones nominadas. Las relaciones nominadas o con nombre, adems se dividen en otros dos grupos por su duracin: Persistentes: son aquellas relaciones cuya definicin (esquema de relacin) permanece en la base de datos, borrndose solamente mediante una accin explcita del usuario. o Base: existen por s mismas, no en funcin de otras relaciones y se crean especificando explcitamente su esquema de relacin (nombre y conjunto de pares: atributo/dominio). Sus extensiones (ocurrencias de la relacin), al igual que su definicin, tambin se encuentran almacenadas. o Vistas: Son relaciones derivadas que se definen dando un nombre a una expresin de consulta. Se pueden tomar como relaciones virtuales, en el sentido de que no tienen datos almacenados, sino que lo nico que se almacena es su definicin en trminos de otras relaciones con nombre, las cuales pueden ser relaciones base, vistas o instantneas. o Instantneas: son relaciones derivadas al igual que las vistas; es decir, se definen en trminos de otras relaciones nominadas, pero tienen datos propios almacenados, los cuales son el resultado de ejecutar la consulta especificada o de guardar una relacin base. Temporales: una relacin temporal desaparece de la base de datos en un cierto momento sin necesidad de una accin de borrado especfica por el usuario. o Autnomas: este tipo de relacin no se deriva de otra, al igual que las relaciones base. o Vistas temporales; similar a una vista pero de forma temporal. o Instantneas temporales: similar a una instantnea pero de forma temporal.

3.2.2 Relaciones sin nombre Son los resultados de las consultas que no se materializan sino que se entregan al usuario que ha realizado la consulta Resultado final de una consulta Resultados intermedios de una consulta

3.2.3 Concepto de clave. Una clave candidata de una relacin es un conjunto de atributos que identifican unvoca y mnimamente cada tupla de la relacin. Por la propia definicin de relacin siempre hay, al menos una clave candidata, ya que una relacin es un conjunto de tuplas, entonces no existen dos tuplas iguales y, por tanto, el conjunto de todos los atributos siempre tiene que identificar unvocamente a cada tupla. 33

3.2.3.1 Clave primaria y alternativa Una relacin puede tener ms de una clave candidata, entre las cuales se debe distinguir las claves: 1. Clave primaria: es aquella candidata que el usuario escoger, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relacin. Cuando slo existe una clave candidata, sta ser la clave primaria. 2. Claves alternativas: son aquellas claves candidatas que no han sido escogidas como clave primaria. 3.2.3.2 Clave Fornea Se denomina clave fornea o ajena de una relacin (R1) a un conjunto no vaco de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relacin(R2), R1 y R2 no son necesariamente distintas. La clave ajena y la correspondiente clave primaria deben estar definidas sobre el mismo dominio. 3.3 Transformacin del modelo E-R al modelo Relacional. La traduccin de un diagrama entidad/relacin a un esquema de base de datos se parece a la traduccin de un diseo de lenguaje de definicin de objetos en un esquema de base de datos. Pero en cierto modo, el modelo de E/R representa una forma intermedia entre un diseo orientado a objetos y un diseo relacional. As, al comenzar con un diagrama E/R, ya est hecho en gran parte el trabajo que debemos realizar. Hay tres diferencias importantes: En el modelo E/R, las relaciones se extraen como un concepto aparte y no como si estuvieran incrustadas como propiedades de clases. Esa diferencia nos sirve para evitar el tipo de redundancia que hemos encontrado en la seccin cuando optamos por insertar una relacin multivaluada como tuplas que representan objetos. En el lenguaje de definicin de objetos, los atributos pueden tener cualquier tipo de coleccin como <Set>. El modelo E/R, aunque es un poco vago respecto a las clases de tipos que se permiten, suele considerarse que admite valores estructurados, pero no conjuntos ni otros constructores de tipos de coleccin. En el modelo de E/R, se permite que las relaciones posean atributos. En el lenguaje de definicin de objetos no existe un concepto correspondiente.

34

3.3.1 De los conjuntos Entidad a las Relaciones. Primero consideraremos los conjuntos entidad que no son dbiles. En cada conjunto entidad no dbil crearemos una relacin del mismo nombre y con el mismo conjunto de atributos. Esta relacin no contendr indicacin alguna de la relacin en que participa el conjunto entidad; manejaremos relaciones con relaciones individuales. 3.3.2 De las relaciones E-R a las Relaciones. Las relaciones del modelo de E/R tambin se representan por medio de relaciones. La relacin de una relacin R determinada posee los siguientes atributos: Para cada conjunto entidad que participa en la relacin R, tomamos su atributo o atributos llave como parte del esquema de la relacin de R. Si la relacin posee atributos, stos sern tambin atributos de la relacin R.

Si un conjunto entidad interviene varias veces en una relacin ser necesario cambiar el nombre a los atributos para evitar la duplicacin de nombres. De manera parecida, habr que hacer lo mismo para evitar la duplicacin, en caso de que el mismo nombre de un atributo aparezca dos o ms veces entre los atributos de R y los conjuntos entidad que intervienen en la relacin R. Las relaciones a menudo estn "normalizadas", lo cual significa que evitan parte de la redundancia que se da en disear directamente de la descripcin del lenguaje de definicin de objetos. Las relaciones bidireccionales del lenguaje de definicin de objetos se reemplazan con una sola relacin que representa la relacin que existe en ambas direcciones. 3.3.3 Traduccin del lenguaje de definicin de objetos a relaciones. Como hemos visto, el resultado de traducir relaciones las asociaciones que se dan en el modelo E/R nos da un mejor esquema relacional de base de datos. Pero podemos emplear libremente la tcnica de E/R para separar como relacin individual una de tipo muchos a uno o muchos a muchos. Con ello evitamos la redundancia y excesiva proliferacin de tuplas que a veces ocurre cuando intentamos implementar una relacin multivaluada en el lenguaje de definicin de objetos con la clase para la cual se define. 3.3.4 Manejo de los conjuntos entidad dbiles. Cuando un conjunto entidad dbil aparece en un diagrama E/R, hay que hacer tres cosas en forma diferente: La relacin del conjunto entidad dbil W tambin habr de incluir no slo los atributos de W, sino tambin los atributos llave de los restantes conjuntos entidad que contribuyan a formar la llave de W. Es fcil

35

reconocer estos conjuntos entidad porque desde W se accede a ellos a travs de una relacin de muchos a uno y de un diamante doble. Las relaciones en que aparezca el conjunto entidad dbil W habrn de utilizar como llave de Mtodos sus atributos llave, entre ellos los de otros conjuntos entidad que contribuyan a la llave de W. No es necesario que las relaciones de diamante doble, del conjunto entidad dbil W que sirven a otros para obtener la llave de W, sean convertidas en una relacin. La justificacin de ello es que los atributos de esa relacin siempre sern un subconjunto de los atributos del conjunto entidad dbil W; por tanto, estas relaciones no aportan otra informacin que no sea el hecho de que ayudan a W a encontrar su llave.

Desde luego, cuando se introducen estos atributos adicionales para construir la llave de un conjunto entidad dbil, se tendr mucho cuidado para no utilizar dos veces un mismo nombre. Si es necesario, se cambiar el nombre de algunos atributos o de todos. 3.3.5 Transformacin de los conceptos de E-R extendido en Relaciones. El modelo E-R permite la representacin de cualquier tipo de relacin existente entre los objetos del mundo real que forman parte del dominio del problema en estudio. Las ltimas actualizaciones del modelo E-R, que han dado lugar a lo que se denomina Modelo Entidad-Interrelacin Extendido (EE-R), permiten la representacin de cualquier tipo de relaciones existentes entre clases de objetos que considera los principios de abstraccin. 3.3.5.1 Interrelaciones Reflexivas. Son relaciones unarias y consideran que en el tipo de interrelacin se ve involucrado un nico tipo de entidad. Por ejemplo, el tipo de entidad que muestra la siguiente figura, describe la relacin existente entre el tipo de entidad Trabajador con ella misma, y que representa que un trabajador es jefe de 0 o varios trabajadores, mientras que un trabajador slo es dirigido por 0 (el jefe de todos) o 1 trabajador.

Se trata de un tipo de interrelacin reflexiva en la que interviene un nico tipo de entidad que desempea dos papeles diferentes en el mismo tipo de interrelacin. No todos los modelos de datos permiten representar este tipo de interrelaciones, tal y como se presenta en el mundo real. El modelo EE-R permite este tipo de interrelaciones, aunque hay que tener en cuenta que no 36

ser siempre fcil la traslacin de esta representacin conceptual a una representacin lgica. 3.3.5.2 Interrelaciones Exclusivas. En un problema del mundo real, un tipo de entidad puede mantener relaciones con un conjunto de otros tipos de entidad, pero no siempre estas relaciones son independientes. Por ejemplo, en la figura siguiente, se presentan tres tipos de entidad Articulo, Proveedor y Fabricante, y el problema en el que los artculos son suministrados por los proveedores o por los fabricantes, pero un artculo nunca puede ser suministrado por un proveedor que no fabrica el artculo, de forma que si el fabricante puede suministrarlo, en ningn momento ser solicitado ese artculo a ningn proveedor.

Para indicar la exclusividad entre dos tipos de interrelacin que mantiene un mismo tipo de entidad se procede a representar un segmento que corta a los dos arcos que representan la relacin del tipo entidad con los tipos de interrelacin exclusiva. 3.3.5.3 Generalizacin y herencia en el modelo E-R. El modelo EE-R permite representar las relaciones jerrquicas existentes entre los tipos de entidad de los problemas del mundo real. La generalizacin es una abstraccin que identifica una relacin jerrquica que representa un tipo de entidad ES_UN subtipo de otro tipo de entidad representada a un nivel de abstraccin mayor. Este tipo de relaciones entre tipos de entidad implica la consideracin de tipos de entidad (o supertipos) y de subtipos de entidad (clases, superclases y subclases de objetos). Un subtipo de entidad es un tipo de entidad que mantiene un tipo de interrelacin jerrquica con otro tipo de entidad y que: Representa a un conjunto de entidades cuyas propiedades y comportamiento general es considerado por el tipo de entidad con la que mantiene el tipo de interrelacin. La relacin jerrquica puede ser n-aria entre un tipo de entidad y un conjunto de subtipos de ese tipo de entidad. Las propiedades y el comportamiento de los subtipos son heredados del tipo de entidad con el cual mantienen un tipo de interrelacin jerrquica. 37

La herencia es una abstraccin incorporada al modelo E-R recientemente e implica la consideracin de que con una nica definicin de las propiedades y comportamiento de un conjunto de entidades, esta definicin es automticamente considerada para todos aquellos conjuntos con los que exista una relacin jerrquica (una especializacin). Las propiedades y/o el comportamiento de un subtipo pueden y deben cambiar con respecto a otros subtipos que intervengan en la misma relacin jerrquica n-aria entre todos estos subtipos y un mismo tipo de entidad. Puesto que los subtipos son tipos de entidad a un nivel de abstraccin menor, stos deben poder distinguirse sin ambigedad del resto de los tipos de entidad existentes en la representacin del problema y, por tanto, deben tener un conjunto de propiedades que permita esta discriminacin. Para cada subtipo de entidad pueden ser definidas tanto las propiedades como el comportamiento del tipo de entidad con la que mantienen un tipo de interrelacin jerrquica. Esta caracterstica permite la existencia de mecanismos para diferenciar a los diferentes subtipos de una misma clase y, adems, permite la cancelacin condicionada de la herencia producida por la interrelacin jerrquica. Un tipo de entidad puede ser un subtipo para ms de un tipo de entidad con las que puede mantener diferentes relaciones jerrquicas. Esta caracterstica, denominada herencia mltiple, permite que un tipo de entidad herede propiedades y comportamiento de ms de otro tipo de entidad. La herencia mltiple puede dar lugar, en ocasiones, a inconsistencias en las propiedades y/o comportamiento que se hereda, lo que se debe solucionar mediante la redefinicin de las herencias.

Un tipo de interrelacin jerrquica representa una especializacin de un tipo de entidad en otros tipos de entidad. Esta especializacin puede ser debida a: Una diferencia en cuanto al nmero de propiedades que definen los subtipos de entidad. De esta forma, diferentes subtipos que mantienen un mismo tipo de interrelacin jerrquica son definidos sobre la base de la agregacin de un conjunto diferente de propiedades, si bien entre el conjunto de subtipos puede existir un subconjunto de propiedades comunes. diferentes valores que pueden ser medidos para una propiedad que existe en el conjunto de subtipos que mantienen un mismo tipo de interrelacin jerrquica. Que se cumplan ambas condiciones.

La especializacin de un tipo de entidad en un conjunto de subtipos, puede ser exclusiva o inclusiva: Especializacin exclusiva (especializacin sin solapamiento): representa el hecho de que una instancia del tipo de entidad ms general slo puede pertenecer o estar asociada a una y slo una instancia de los subtipos de entidad especializados.

38

Especializacin inclusiva (especializacin con solapamiento): representa el hecho de que una instancia del tipo de entidad ms general puede tener asociadas instancias de cualquiera de los subtipos.

La especializacin de un tipo de entidad en un conjunto de subtipos puede ser total o parcial Especializacin total. Representa el hecho de que las entidades que son reconocidas en el problema que se est representando son de alguno de los subtipos especializados, no existiendo entidades que no pertenezcan a alguno, varios o todos estos subtipos de entidad. Especializacin parcial: representa el hecho de que pueden existir entidades que pertenezcan al tipo de entidad y no a ninguno de los subtipos en los cuales este tipo de entidad est especializado. Es decir, describe un refinamiento incompleto del problema que se representa, debido a un conocimiento incompleto del mismo y/o una simplificacin de la representacin del mismo. Por lo tanto se pueden representar cuatro tipos de interrelaciones jerrquicas que se representaran mediante el modelo EE-R: Total sin solapamiento: La siguiente figura muestra el tipo de entidad Persona el cual puede ser especializada en dos subtipos de entidad Hombre y Mujer de forma tal y sin solapamiento. Una entidad persona podr pertenecer al subtipo Hombre o al subtipo Mujer necesariamente; es decir, no existir una Persona que no sea de alguno de estos dos subtipos y adems de forma exclusiva, por lo que una entidad pertenecer a uno y slo uno de estos subtipos. Adems, cada entidad de alguno de estos subtipos vendr caracterizada por algn atributo o conjunto de atributos definidos para estos subtipos o heredados del tipo de entidad Persona, ms el atributo sexo, el cual tiene la funcin de clasificador de las entidades Persona en alguno de estos subtipos.

Parcial sin solapamiento: La siguiente figura muestra un ejemplo de especializacin parcial exclusiva. En este caso se ha considerado un tipo de entidad Enfermedad que puede ser especializada en dos subtipos Vrica y Bacteriana. Este diagrama representa el hecho de que en el problema se consideran un conjunto de entidades Enfermedad las cuales pertenecern bien a alguno de los subtipos considerados Vrica o Bacteriana, pero que adems existirn entidades Enfermedad las cuales 39

no puedes ser clasificadas en ninguno de estos subtipos debido, posiblemente, al desconocimiento del valor del atributo Tipo utilizado como discriminador.

Total con solapamiento: La siguiente figura representa un refinamiento total con solapamiento en el que un tipo de entidad Empresa se ha redefinido en dos subtipos Pblica y Privada. Se est representando el hecho de que podrn existir en el dominio del problema entidades que puedan ser consideradas tanto del tipo Pblica como Privada, o bien de ambos tipos al mismo tiempo y, adems el hecho de que no podrn existir entidades que no puedan ser especializadas en alguno de estos dos subtipos.

Parcial con solapamiento: en la siguiente figura se representa a un tipo de entidad Persona que puede ser refinado en dos subtipos Trabajador y Estudiante de forma parcial con solapamiento. Este ejemplo representa que una entidad Persona puede ser del tipo Trabajador y/o del tipo Estudiante y que adems pueden existir entidades Persona que no puedan clasificarse en ninguno de estos dos subtipos.

40

En los dos ltimos ejemplos, los subtipos de entidad incorporan nuevos atributos mediante los cuales pueden diferenciarse entidades pertenecientes a los distintos subtipos (o del tipo de entidad general en el caso en que la especializacin no sea total). Igualmente podran existir atributos pertenecientes al tipo de interrelacin jerrquica cuya funcin fuera de esta diferenciacin de las entidades pertenecientes a los subtipos. 3.3.5.4 Las cardinalidad en la jerarqua. Dependiendo del tipo de interrelacin jerrquica que se represente, y por tanto exista en el dominio del problema, los tipos de entidad que intervienen en el mismo participan o pueden participar con un nmero determinado de ocurrencias. As, se tienen que tener en cuenta las siguientes consideraciones en la representacin de este tipo de interrelaciones: El tipo de entidad ms general o el supertipo de entidad que es especializado participa siempre con la cardinalidad mnima 1 y con la cardinalidad mxima 1, puesto que se esta representando como una entidad de este tipo puede especializarse en otros subtipos. Para cualquier clase de este tipo de interrelaciones jerrquicas. La cardinalidad mxima con la que participan los subtipos de entidad en el tipo de interrelacin es 1, puesto que se est representando para cada entidad del supertipo una especializacin o refinamiento de la misma. Si el tipo de interrelacin es total o parcial sin solapamiento, los subtipos participan siempre con cardinalidad mnima 0, puesto que una entidad del tipo no puede pertenecer al mismo tiempo a ms de un subtipo (ver figuras de total y parcial sin solapamiento). Si el tipo de interrelacin es total o parcial con solapamiento, los subtipos pueden participar con la cardinalidad mnima 0 1, puesto que una entidad del supertipo puede a su vez ser especializada en cualquiera de los subtipos simultneamente (ver figura de total y parcial con solapamiento).

41

3.3.6 Representacin de las restricciones en el Modelo EE-R. El modelo EE-R cuenta con algunos mecanismos para la representacin de las restricciones que estn presentes en los problemas del mundo real. Si consideramos que una restriccin es una condicin que est presente para un conjunto o subconjunto de objetos que estn presentes en el dominio del problema, las restricciones pueden aparecer: En los valores que pueden ser medidos para un atributo. Si bien el atributo est definido en un determinado dominio, en el dominio del problema puede ser necesario considerar restricciones en cuanto a este dominio. Por ejemplo, un atributo edad definido en el dominio de los nmeros enteros de dos dgitos y para el cual slo se deben considerar que tome los valores comprendidos en el intervalo [18, 65]. En los valores de las correspondencias entre conjuntos de objetos del sistema que representan los tipos de interrelacin entre los tipos de entidad; es decir, el valor de las cardinalidades mximas y mnimas. En la existencia de entidades pertenecientes a un determinado tipo de entidad, siempre y cuando no existan otras entidades pertenecientes a otro(s) tipo(s) de entidad (las entidades dbiles o las que participan en un tipo de interrelaciones jerrquicas).

La representacin de las restricciones existentes en un problema del mundo real est directamente ligada a la semntica del problema. La representacin de la semntica es extremadamente compleja si no se utiliza un lenguaje natural, puesto que la semntica es dependiente del contexto en el que se encuentran los tems de informacin acerca del problema. Pocos modelos de datos son capaces de representar de forma efectiva la semntica de un problema del mundo real, y menos an mediante una representacin grfica. En el modelo EE-R es posible representar grficamente parte de las restricciones antes sealadas, aunque no as todas ellas, como el lmite o intervalo de valores que puede tomar un atributo, necesitndose para ello una representacin textual del problema del mundo real. 3.3.6.1 Sintaxis Del Modelo EE-R. La representacin textual de un problema del mundo real mediante el modelo EE-R, requiere la representacin mediante una gramtica preestablecida del conocimiento e informacin acerca de las caractersticas del problema; es decir, de cada uno de los tipos de entidad e interrelaciones reconocidos y de la estructura de cada uno de estos tipos. Mediante una descripcin simple se deben describir todos los elementos del problema y todas aquellas caractersticas de estos que permiten su identificacin en el mundo real, as como dentro del conjunto de los objetos representados. Como muestra la siguiente tabla se describirn cada uno de los tipos de entidad, sus atributos, dominios y restricciones, as como los conjuntos de atributos que pueden ser considerados como identificadores de las entidades 42

de este tipo. Y, adems, se describir la lista de tipos de interrelacin existentes entre los tipos de entidad. Definicin del Problema: Nombre del problema Descripcin de los tipos de entidad Se relacionan cada uno de los tipos de entidad con indicacin de la siguiente informacin. Tipo de entidad Nombre Hereda de Para cada uno de los atributos que caracterizan el tipo de entidad se indica. Atributo Nombre Si el atributo es compuesto, se declaran los atributos componentes. Lista de atributos Lista de nombres componentes Para cada atributo simple se especifica la siguiente informacin. Dominio Nombre del dominio Cardinalidad Multiplicidad Restricciones Se declara el rango de valores permitidos. [Valor mnimo, valor mximo] Intervalo de valores (coleccin de valores permitidos) Lista de valores Identificador principal Lista de atributos Se declara la lista de los identificadores alternativos para el tipo de entidad. Identificador alternativo Lista de atributos Descripcin de los tipos de interrelacin. Se relacionan cada uno de los tipos de interrelacin con indicacin de:. Tipo de interrelacin Nombre Se especifican cada uno de los tipos de entidad que participan en el tipo de interrelacin. Tipo de entidad Nombre Se especifica la cardinalidad con la que participa el tipo de entidad. Cardinalidad mnima Cardinalidad mnima Cardinalidad mxima Cardinalidad mxima /* Se especifican cada uno de los atributos que caracterizan el tipo de interrelacin de la misma forma que se ha realizado para los tipos de entidad */ La sintaxis representada en la tabla, no pretende ser una descripcin formal del modelo EE-R, sino una gua a seguir que permita especificar la representacin de un problema, adems de grficamente, sintcticamente favoreciendo la calidad y legibilidad de la documentacin que se genere del proceso de anlisis del problema en estudio.

3.4 LGEBRA RELACIONAL El algebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relacin. 43

Las ocho operaciones se agrupan en dos como sigue

Operadores tradicionales: o Unin o Interseccin o Diferencia o Producto Cartesiano. Operadores Especiales: o Restriccin o seleccin o Proyeccin o Reunin o Divisin

3.4.1 OPERACIONES DEL LGEBRA RELACIONAL Las operaciones seleccin, proyeccin y renombramiento se denominan operaciones unarias porque trabajan sobre una sola relacin. Las otras operaciones operan sobre pares de relaciones y se denominan por lo tanto binarias. 3.4.1.1 Operacin de Seleccin o Restriccin: La operacin de restriccin selecciona tuplas que satisfacen un predicado dado. Se utiliza la letra griega sigma ( ) para denotar la seleccin. El predicado aparece como subndice. La relacin del argumento se da entre parntesis. Por tanto, para seleccionar las tuplas de la relacin prstamo en que la sucursal es <<Plaza Dorada>> hay que escribir
nombre_sucursal=<<Plaza

Dorada>> (prstamo)

Si la relacin prstamo es como se muestra a continuacin Numero_prestamo P-11 P-14 P-15 P-16 P-17 P-18 Nombre_sucursal PLAZA DEL SOL CENTRO PLADA DORADA PLAZA DORADA CENTRO PLAZA LORETO Importe 900 1500 1500 1300 1000 2000

La relacin que resultar de la consulta anterior es: Numero_prestamo P-15 P-16 Nombre_sucursal PLADA DORADA PLAZA DORADA Importe 1500 1300

44

En general, g se e permiten las compa araciones que utiliza an , =, <, <=, >, >= en el pred dicado de la l selecci n. Adems, se pued den combinar varios predicado os en uno mayor utili izando las conectivas y (^) y o (v). = nom mbre_sucursal=<<Plaza ^importe >12 D Dorada>> 200 (prsta amo)

.1.2 Opera acin de Proyeccin P n: 3.4. Sup ngase qu ue se dese ea hacer un na lista de e todos los nmeros del prstamo y del importe de d los mis smos, per ro sin que e aparezcan los no ombres de e las sucu ursales. La L operacin proye eccin per rmite prod ducir esta a relacin. La oper racin es unaria qu ue devuelv ve su rela acin de argumento a os, excluyendo algunos argum mentos. Da ado que las s relacione es son conjuntos, se eliminan todas t las filas f duplica adas. Las proyeccion nes se den notan con la letra ma ayscula pi ( ). Se crea c una lis sta de los atributos que q se desea que aparezcan en el resultado como subndic ce. La rela acin de argumento a os se escribe a cont tinuacin entre e par ntesis. Po or tanto la consulta para crear r la lista de d todos lo os nmero os de prs stamo y del importe de d los mism mos puede e escribirse e como:
numero_pres stamo, importe

(prstamo o)

Y la relacin que resulta es: Num mero_prest tamo P-11 1 P-14 4 P-15 5 P-16 6 P-17 7 P-18 8 Importe e 900 1500 1500 1300 1000 2000

3.4.2 2 Compo osicin de operacion nes relacionales Es importante el hecho de que el e resultado o de una operacin relacional l sea tamb bin una relacin. Considrese e la consu ulta ms compleja c < <<Encontra ar los clien ntes que viven en el centro>> c h que escribir: hay
nombre_clie ente ,( colonia_cliente

=<< <Centro>>(Cliente))

Tng gase en cu uenta, en vez v de dar r en el arg gumento la a operacin n proyeccin el nom mbre de una a relacin se s da una expresin que se ev vala como o una relac cin. En general g dado que el resultado de la oper racin del algebra re elacional es del mism mo tipo (re elacin) qu ue los dat tos de ent trada, las operaciones del alg gebra relac cional pue eden com mponerse para form mar una expresin n del alg gebra relac cional.

45

La composicin de operaciones del algebra relacional para formar expresiones es igual a la de las operaciones aritmticas 3.4.2.1 Operacin Unin Considrese una consulta para averiguar el nombre de todos los clientes del banco que tienen una cuenta o un prstamo o ambas cosas. Obsrvese que la relacin cliente no contiene esa informacin, dado que los clientes no necesitan tener ni cuenta ni prstamo en el banco. Para contestar a esta consulta hace falta la informacin de las relaciones impositoras y prestatarias que a continuacin se dan: Nom_cliente Oscar Ral Joaqun Martn Abril Num_cuenta C-102 C-103 C-104 C-105 C-106 Nom_cliente Ramiro Ral Joaqun Sandra Guillermo Num_prestamo P-16 P-17 P-18 P-19 P-20

Se conoce la manera de averiguar los nombres de todos los clientes con prstamo en el banco
nom_cliente

(prestatario)

Tambin se conoce la manera de averiguar el nombre de todos los clientes en el banco:

nom_cliente

(impositor)

Para contestar a la consulta hace falta la unin de estos dos conjuntos; es decir, hacen falta todos los nombres de clientes que aparecen en alguna de las dos relaciones o en ambas. Estos datos se pueden averiguar mediante la operacin binaria unin, denotada, como en la teora de conjuntos, por U. por tanto la expresin buscada es:
nom_cliente

(prestatario)

nom_cliente

(impositor)

La relacin resultante de esta consulta aparece en la siguiente tabla:

46

Nom_cliente Abril Guillermo Joaqun Martn Oscar Ramiro Ral Sandra Tngase en cuenta que en el resultado hay ocho tuplas, aunque hay cinco prestatarios y cinco impositores distintos. Esta discrepancia aparente se debe a que Joaqun y Ral son ala vez prestatarios e impositores. Dado que las relaciones son conjuntos, se eliminan los valores duplicados. Obsrvese que en este ejemplo se toma la unin de dos conjuntos, ambos consistentes en valores nom_cliente. En general, se debe asegurar que las uniones se realicen entre relaciones compatibles. Por lo tanto para que una operacin unin relacin1 U relacin2 sea vlida hay que exigir que se cumplan dos condiciones:

Las relaciones 1 y 2 deben ser de la misma aridad. Es decir, deben tener el mismo nmero de atributos. Los dominios de los atributos i-simos de relacin1 y de relacin2 deben ser iguales para todo i

3.4.2.2 Operacin diferencia de conjuntos Las operaciones diferencias de conjuntos, denotada por ( - ) signo menos , permite buscar las tuplas que estn en una relacin perno no en la otra. La expresin relacin1 relacin2 da como resultado una relacin que contiene las tuplas que estn en relacin1 pero no en la relacin2. Se puede buscar todos los clientes del banco que tienen abierta una cuenta pero no tienen concedido ningn prstamo escribiendo.
nom_cliente

(impositor)

nom_cliente

(prestatario)

La relacin resultante de esta consulta es: Nom_cliente Abril Martn Oscar

47

Como en el caso de la operacin de unin, hay que asegurarse de que las diferencias de conjuntos se realicen en relaciones compatibles. Por lo tanto para que la operacin diferencia de conjuntos sea vlida hay que exigir que las relaciones sean de la misma aridad y que los dominios de los atributos i-simos de las relaciones sean iguales. 3.4.3 Operacin Producto Cartesiano: La operacin denotada por un aspa (x) permite combinar la informacin de cualquiera de dos relaciones. El producto cartesiano de las relaciones r1 y r2 como r1 x r2. Recurdese que las relaciones se definen como subconjuntos del producto cartesiano de un conjunto de dominios. A partir de esta definicin ya se debe tener una intuicin sobre la definicin del producto cartesiano. Sin embargo, dado que el mismo nombre de atributo puede aparecer tanto en r1 como en r2, hay que crear un esquema de denominacin para distinguir entre ambos atributos. En este caso se logra adjuntando al atributo el nombre de la relacin de la que proviene originalmente. Por ejemplo. El esquema de relacin de r=prestatario x prstamo es: (prestatario.nom_cliente, prestatario.Num_prestamo, prstamo.nombre_sucursal, prestamo.num_prestamo, prestamo.importe) Con este esquema se puede distinguir entre prestatario.num_prestamo y prestamo.num_prestamo. Para los atributos que solo aparecen en uno de los dos esquemas se suele omitir el prefijo con el nombre de la relacin. Esta simplificacin no genera ambigedad alguna. Por tanto, se puede escribir el esquema de la relacin como de r como: (nom_cliente, prestatario.Num_prestamo, nombre_sucursal, prestamo.num_prestamo, importe) El acuerdo de denominaciones precedente exige que las relaciones que sean argumentos de la operacin de producto cartesiano tengan nombres diferentes. Esta exigencia causa problemas en algunos casos, como cuando se desea calcular el producto cartesiano de una relacin consigo misma. Se producen un problema similar si se utiliza el resultado de una expresin del algebra relacional en un producto cartesiano, dado que har falta un nombre para la relacin para poder hacer referencia a sus atributos. Supngase que desea averiguar los nombres de todos los clientes que tienen concedido un prstamo en la sucursal de Plaza Dorada. Se necesita para ello informacin de las relaciones prstamo y prestatario

48

Prstamo Numero_presta mo P-11 P-14 P-15 P-16 P-17 P-18 Nombre_sucur sal PLAZA DEL SOL CENTRO PLADA DORADA PLAZA DORADA CENTRO PLAZA LORETO Import e 900 1500 1500 1300 1000 2000

Prestatario Nom_clien te Ramiro Ral Joaqun Sandra Guillermo Numero_presta mo P-16 P-17 P-15 P-19 P-20

Si se escribe:
nombre_sucursal=<<Plaza

Dorada>> (prestatario x prstamo)

Teniendo una relacin que solo atae a la sucursal de Plaza dorada. Sin embargo la columna nom_cliente puede contener clientes que no tengan concedido ningn prstamo en la sucursal mencionada (Si no se ve el motivo por el cual esto es cierto, recurdese que el producto cartesiano toma todos los emparejamientos posibles de una tupla de prestatario con una tupla de prstamo). Dado que la operacin de producto cartesiano asocia todas las tuplas de prstamo con todas las tuplas de prestatario, se sabe que , si un cliente tiene concedido un prstamo en la sucursal de Plaza Dorada, hay alguna tupla prestatario X prstamo que contiene el nombre y que prestatario.numero_prestamo = prestamo.numero_prestamo. Por tanto si escribimos:
prestatario.numero_prestamo=prestamo.numero_prestamo(

(prestatario x prstamo))

nombre_sucursal=<<Plaza

Dorada>>

Slo se obtienen las tuplas de prestatario X prstamo que corresponden a los clientes que tienen concedido un prstamo en la sucursal de Plaza Dorada. Finalmente, dado que slo se desea obtener nom_cliente, se realiza una proyeccin:
nom_cliente( prestatario.numero_prestamo=prestamo.numero_prestamo(

Dorada>> (prestatario x prstamo)))

nombre_sucursal=<<Plaza

49

UNIDAD 4 Diseo de BD Relacionales. 4.1 Restricciones de Integridad. Las restricciones de integridad garantizan que el contenido de la base de datos es conforme con las reglas establecidas para presentar el Universo del Discurso. La integridad de una base de datos significa la existencia de dos componentes importantes que son la exactitud y la completitud. Es decir, que la integridad de base de datos garantiza que todos los datos son correctos (validos) y relevantes. 4.1.1 Clasificacin de restricciones Dependiendo del autor que se consulte es la clasificacin que se hacen sobre este tema, aunque en muchos casos hay muchos trminos repetitivos en muchas de ellas: 4.1.1.1 Restricciones Inherentes. Las restricciones que impone el mismo modelo, el cual no permite ciertas estructuras, son las restricciones inherentes, que no son definidas por los usuarios sino obligadas por el propio modelo, lo que quita la flexibilidad a la hora de representar el mundo real. Existen una serie de caractersticas de una relacin que han de cumplirse obligatoriamente, por lo que se trata de restricciones inherentes, y estas son las siguientes: 1. No hay dos tuplas iguales (de donde se deduce la obligatoriedad de la clave primaria). 2. El orden de las tuplas no es significativo. 3. El orden de los atributos no es significativo. 4. Cada atributo slo puede tomar un nico valor del dominio sobre el que est definido, no admitiendo por tanto los grupos repetitivos. Se dice que una tabla que cumple esta condicin est normalizada, primera forma norma (este tema se tratara mas adelante). Toda relacin ha de estar normalizada, en caso contrario no es realmente una relacin. Si en la siguiente tabla queremos agregar un atributo Idiomas para especificar que idiomas habla nuestro cliente, la tabla resultante sera: Nombre Esteban Bentez Prez Luis Flores Aguilar Virginia Prez Ruiz Telefono 2654554 2547823 2356897 CP 72600 72450 78458 Idiomas Ingls, Espaol Ingls Francs

50

La tabla anterior no consiste estrictamente en una relacin al no estar normalizada (el atributo idiomas toma ms de un valor del correspondiente dominio); para normalizarla habra que repetir los valores de Nombre, Telefono y CP para cada uno de los idiomas que habla el cliente, tal como aparece en la siguiente tabla: Nombre Esteban Bentez Prez Esteban Bentez Prez Luis Flores Aguilar Virginia Prez Ruiz Telefono 2654554 2654554 2547823 2356897 CP 72600 72600 72450 78458 Idiomas Ingls Espaol Ingls Francs

Adems de las restricciones inherentes derivadas de la misma definicin de relacin, existe otra restriccin inherente que es la regla de integridad de entidad, la cual impone que: Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor nulo. 4.1.1.2 Restricciones Semnticas. Las restricciones semnticas son facilidades que el modelo ofrece a los usuarios a fin de que stos puedan reflejar en el esquema, lo ms fielmente posible, la semntica del mundo real. Sin embargo, estas restricciones semnticas, no son muchas veces suficientes para captar toda la semntica del universo del discurso que se est tratando de modelar. Las principales restricciones semnticas del modelo relacional son las siguientes: 1. Clave primaria: permite declarar un atributo o un conjunto de atributos como clave primaria de una relacin, por lo que sus valores no se podrn repetir ni se admitirn los nulos. La obligatoriedad de la clave primaria es una restriccin inherente del modelo relacional; sin embargo, la declaracin de un atributo como clave primaria de una relacin es una restriccin semntica que responde a la necesidad del usuario de imponer que los valores del conjunto de atributos que constituyen la llave primaria no se repitan en la relacin ni tampoco tomen valores nulos. 2. Unicidad (UNIQUE): mediante la cual se indica que los valores de un conjunto de atributos no pueden repetirse en una relacin. Esta restriccin permite la definicin de claves alternativas. 3. Obligatoriedad (NOT NULL): se indica que el conjunto de atributos no admite valores nulos. 4. Integridad referencial (FOREIGN KEY): si una relacin R2 (relacin que referencia) tiene un descriptor que es una clave candidata de la relacin R1 (relacin referenciada), todo el valor de dicho descriptor debe concordar con un valor de la clave candidata referenciada de R1 o bien ser nulo.

51

La integridad referencial es una importante restriccin semntica que viene impuesta por el mundo real, siendo el usuario quien la define al describir el esquema relacional, y el modelo la reconoce sin necesidad de que se programa ni de que se tenga que escribir ningn procedimiento para obligar a su cumplimiento. Adems de definir las claves ajenas, hay que determinar las consecuencias que pueden tener ciertas operaciones (borrar y modificar) realizadas sobre las tuplas de la relacin referenciada; pudiendo distinguir las siguientes opciones: 1. Operacin restringida: el borrado de las tuplas de la relacin que contiene la clave referenciada slo se permite si no existen tuplas con ese valor en la relacin que contiene la clave ajena. 2. Operacin con transmisin en cascada (CASCADE): el borrado de tuplas de la relacin que contiene la clave candidata referenciada, lleva consigo el borrar en cascada las tuplas de la relacin que contiene la clave ajena. 3. Operacin con puesta a nulos (SET NULL): el borrado de tuplas de la relacin que contiene la clave candidata referenciada lleva consigo poner a nulos los valores de las claves ajenas de la relacin que referencia. Esta opcin slo es posible cuando el atributo que es clave ajena admite valores nulos. 4. Operacin con puesta a valor por defecto (SET DEFAULT): el borrar tuplas de la relacin que contiene la clave candidata referenciada lleva consigo poner el valor por defecto a la clave ajena de la relacin que referencia, valor por defecto que habra sido definido al crear la tabla correspondiente. Existen otras restricciones llamadas de rechazo, en las que el usuario formula una condicin mediante un predicado definido sobre un conjunto de atributos de tuplas o de dominios, el cual debe ser verificado por los correspondientes objetos en toda operacin de actualizacin para que el nuevo estado constituya una ocurrencia vlida del esquema; en caso de que la operacin intente violar la condicin se impide que la operacin se lleve a cabo (es decir, se produce un rechazo de la operacin). Se pueden distinguir dos restricciones de rechazo, segn la condicin afecte a un nico elemento de la base de datos o a ms de uno. 1. Verificacin (CHECK): comprueba, en toda operacin de actualizacin, si el predicado es cierto o falso y en el segundo caso, rechaza la operacin. Estas restricciones se definen sobre un nico elemento y puede o no tener nombre. 2. Asercin (ASSERTION): acta de forma idntica a la anterior, pero a diferencia de ella se puede afectar a varios elementos y su definicin por tanto, no va unida a la de un determinado elemento, por lo que siempre ha de tener un nombre, ya que la asercin es un elemento ms del esquema que tiene vida por s mismo. As pues, las restricciones de llaves y las restricciones en general forman parte del esquema de la base de datos. Las declara el diseador junto con el diseo estructural. Una vez declarada una restriccin, quedan prohibidas las 52

inserciones o modificaciones de la base de datos que la violen. Por lo tanto, aunque una instancia particular de la base de datos puede cumplir con ciertas restricciones, las nicas restricciones verdaderas son las que identifique el diseador como aplicables a todas las instancias de la base de datos que ofrezca un modelo correcto del mundo real.1 4.1.2. Integridad de Entidades y Referencial, claves externas. Conceptualmente las entidades y las relaciones individuales son distintas; desde una perspectiva de bases de datos, sin embargo la diferencia entre ellas se debe expresar en trminos de sus atributos. Por tanto, los valores de los atributos de una entidad deben ser tales que permitan identificar unvocamente (de forma nica) a la entidad. En Otras palabras, no se permite que ningn par de entidades tengan exactamente los mismos valores de sus atributos. 4.1.2.1 Restricciones de clave. Especifican las claves candidatas de cada esquema de relacin, los valores de las claves deben ser nicos para cada tupla en cualquier caso de ese esquema de relacin. Una clave o llave permite identificar un conjunto de atributos suficientes para distinguir las entidades entre s. Las claves tambin ayudan a identificar unvocamente a las relaciones y as a distinguir las relaciones entre s. Una superllave es un conjunto de uno o ms atributos que, tomados colectivamente, permiten identificar de forma nica una entidad en el conjunto de entidades. Por ejemplo el atributo id_cliente del conjunto de entidades clientes es suficiente para identificar una entidad cliente entre otras. As id_cliente es una superllave. Pero en el caso de nombre_cliente no puede ser una sper clave porque varias personas podran tener el mismo nombre. Cuando las superllaves forman subconjuntos combinados para identificar a una entidad se les conoce como claves candidatas Es posible que conjuntos distintos de atributos pudieran servir como claves candidatas. Supngase que una combinacin de nombre_cliente y calle_cliente es suficiente para distinguir entre los miembros del conjunto de entidades cliente. Entonces los conjuntos {id_cliente} y {nombre_cliente, calle_cliente} son claves candidatas. Los valores clave identifican tuplas y mantienen relaciones, ambas funciones ocasionan dos restricciones adicionales. Una llave externa no es necesariamente un solo atributo; al igual que una llave o una superllave, puede ser un subconjunto de atributos, siempre que sirva para identificar una tupla nica de la tabla correspondiente. De manera formal, una llave externa de una relacin R es un subconjunto de los atributos de R, cuyos valores concuerdan con una superllave en alguna otra relacin y por tanto, establecen una relacin entre las dos tablas. Es frecuente que una llave externa tenga el mismo nombre que la superllave de la tabla a la cual se refiere, pero esta conveniencia no siempre es posible, particularmente en relaciones recursivas. 53

El Modelo relacional incluye dos reglas generales de integridad, las cuales se refieren respectivamente a las llaves primarias y a las llaves externas. Una llave primaria de una relacin es slo un identificador nico para esa relacin. Una llave externa representa una referencia a la tupla donde se encuentra el valor correspondiente de la llave primaria. Reglas: 1. Ningn componente de la llave primaria de una relacin base puede aceptar valores nulos: en una base de datos relacional nunca registraremos informacin acerca de algo que no podamos identificar. 2. La base de datos no debe contener valores de llave externa sin concordancia: con el trmino valores de llave ajena sin concordancia quiere decir que un valor no nulo de la llave externa para el cual no existe un valor concordante de la llave primaria en la relacin objetivo pertinente. Si B hace referencia a A, entonces A debe existir. Si el esquema de una base de datos relacional se basa en las tablas derivadas de un esquema Entidad relacin es posible determinar la clave primaria del esquema de una relacin a partir de las claves primarias de los conjuntos de entidades o de relaciones de los que se deriva el esquema: 1. Conjunto de entidades fuertes. La clave primaria del conjunto de entidades se convierte en clave primaria de la relacin. 2. Conjunto de entidades dbiles. La tabla y por lo tanto, la relacin correspondientes a un conjunto de entidades dbiles incluyen: Los atributos del conjunto de entidades dbiles. La clave primaria del conjunto de entidades fuertes del que depende el conjunto de entidades dbiles. La clave primaria de la relacin consiste en la unin de la clave primaria del conjunto de entidades fuertes y el discriminante del conjunto de entidades dbiles. Una primera clasificacin considera tres tipos de restricciones, como parte del modelo relacional: 4.1.2.2 Integridad De Entidad. Establecen que ningn valor de clave primaria puede ser nulo, esto es porque el valor de la clave primaria se usa para identificar las tuplas Debido a que un valor clave es sustituto fundamental para una tupla, es razonable insistir en que los valores clave nunca sean nulos. Esta restriccin se denomina integridad de entidad. La integridad de entidad requiere que una tupla nunca deba contener valores nulos en sus atributos de llave. Es comn en bases de datos grandes que falten ciertos datos; los atributos sin llave pueden ser nulos sin demasiada conveniencia; pero no se desea especificar el valor como nulo porque nunca se podra encontrar la tupla otra vez.

54

4.1.2.3 Integridad Referencial. Establece que una tupla de relacin que haga referencia a otra relacin debe referirse a una tupla existente en esa relacin. En otras palabras: La integridad referencial requiere que una llave externa contenga ya sea un valor nulo o la llave de una tupla dominante existente de la entidad a la que hace referencia. La integridad referencial es una restriccin que exige que un valor clave deber nulo o contener un valor que exista realmente en la tabla a que se hace referencia. La integridad referencial es importante porque las llaves externas son el nico mecanismo para mantener relaciones. Por consiguiente la integridad referencial protege contra errores que puedan alterar relaciones legtimas o crear agrupaciones no validas.

4.2 Normalizacin de Base de Datos Normalizacin es un proceso que clasifica relaciones, objetos y formas de relacin, en base a las caractersticas que cada uno posee. Si se identifican ciertas reglas se aplica una categora; si no cumplen las reglas, se descomponen repartiendo sus atributos entre esquemas de relacin ms pequeos que cumplen las condiciones establecidas. Objetivos de un diseo normalizado: Eliminar anomalas de actualizacin Conservar la informacin (descomposicin sin prdida de informacin). Conservar las dependencias funcionales (descomposicin sin prdida de DF). No crear dependencias nuevas o interrelaciones inexistentes. Facilidad de uso. Eficiencia. Ventajas de la normalizacin: La cantidad de espacio requerido para almacenar los datos es la menor posible; Evita anomalas en inserciones, modificaciones y borrados. Mejora la independencia de datos. Mayor rapidez en la ordenacin y en la creacin de ndices. Menos ndices por tabla. Evita restricciones artificiales en la estructura de los datos.

Por ejemplo: Formalizacin CERO (No aplicada ninguna regla de normalizacin) 55

usuarios nombre Joe Jill empresa ABC XYZ direccion_empresa 1 Work Lane 1 Job Street url1 abc.com abc.com url2 xyz.com xyz.com

Observe los campos url1 y url2 Qu haremos cuando en nuestra aplicacin necesitemos una tercera url? Quieres tener que aadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos? Obviamente no, se debe crear sistema funcional que pueda crecer y adaptarse fcilmente a los nuevos requisitos. 4.2.1 Primer nivel de Formalizacin/Normalizacin. (F/N) Los datos tienen que ser atmicos. Eliminar los grupos repetitivos de las tablas individuales. Crear una tabla separada por cada grupo de datos relacionados. Identificar cada grupo de datos relacionados con una clave primaria.

Sin embargo se est rompiendo un punto de la 1FN cuando repetimos los campos url1 y url2, tambin se repite la clave primaria. La regla tres bsicamente significa que tenemos que poner un campo tipo contador autoincrementable para cada registro. De otra forma, si tuviramos dos usuarios llamados de la misma forma como los diferenciaramos. Una vez que se aplica el primer nivel de F/N tenemos la siguiente tabla: Usuarios user_id nombre empresa direccin_empresa url 1 1 2 2 Joe Joe Jill Jill ABC ABC XYZ XYZ 1 work lane 1 work lane 1 job street 1 job street abc.com Xyz.com abc.com Xyz.com

56

4.2.2 Segundo nivel de Normalizacin Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros. Relacionar estas tablas mediante una clave externa.

Hemos separado el campo url en otra tabla, de forma que podemos aadir ms en el futuro si tener que duplicar los dems datos. Tambin vamos a usar nuestra clave primaria para relacionar estos campos: usuarios user_i d 1 2 nombr e Jos Mara empres a ABC XYZ direccion_empres a 1 work lane 1 job street urls url_id 1 2 3 4 relUserId url 1 1 2 2 abc.com xyz.com abc.com xyz.com

Ahora se tienen tablas separadas y la clave primaria en la tabla usuarios, user_id, est relacionada ahora con la clave externa en la tabla urls, relUserId. Pero si quiere aadir otro empleado a la empresa ABC, se duplicaran el nombre de la empresa y su direccin, entonces se aplica la 3FN. 4.2.3 Tercer nivel de F/N. Eliminar aquellos campos que no dependan de la clave. empresa emprId empresa direccion_empresa 1 2 usuarios user_id nombre relEmpresaId 1 2 Joe Jill 1 2 ABC XYZ 1 work lane 1 job street

57

Urls url_id 1 2 3 4 RelUserId url 1 1 2 2 abc.com xyz.com abc.com xyz.com

Ahora las tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicacin ni corrupcin de datos. La mayora de los desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede manejar fcilmente los datos obtenidos de una cualquier empresa en su totalidad, y en la mayora de los casos esto ser cierto. Sin embargo en nuestra tabla urls, el campo url tiene valores duplicados. Esto es perfectamente aceptable si la entrada de datos de este campo es solicitada al usuario en nuestra aplicacin para que teclee libremente su url, y por lo tanto es slo una coincidencia que Joe y Jill teclearon la misma url. Pero qu pasa si en lugar de entrada libre de texto usramos un men desplegable con 20 o incluso ms urls predefinidas? Entonces tendramos que llevar nuestro diseo de BD al siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende mucho de un tipo muy especfico de relacin, la relacin 'varios-con-varios', la cual an no hemos encontrado en nuestra aplicacin. 4.2.3.1 Relaciones entre los Datos Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varios-con-varios. Observa las tablas de la 1FN. Suponemos que ponemos el campo url en una tabla separada, y cada vez que introducimos un registro en la tabla usuarios tambin introducimos una sola fila en la tabla urls. Entonces tendramos una relacin uno-a-uno: cada fila en la tabla usuarios tendra exactamente una fila correspondiente en la tabla urls. Para los propsitos de nuestra aplicacin no sera til la normalizacin. En la 2FN. Nuestras tablas permiten a un slo usuario tener asociadas varias urls. Esta es una relacin uno-con-varios, el tipo de relacin ms comn, y hasta que se nos present el dilema del Tercer Nivel de F/N. la nica clase de relacin que necesitamos. La relacin varios-con-varios, sin embargo, es ligeramente ms compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado con varias urls. Como dijimos, vamos a cambiar la estructura para permitir que varios usuarios estn relacionados con varias urls y as tendremos una relacin varios-con-varios. Veamos como quedaran nuestras tablas antes de seguir con este planteamiento:

58

usuarios user_id nombre relEmpresaId 1 2 Joe Jill 1 2

empresa emprId empresa direccion_empresa 1 2 ABC XYZ 1 work lane 1 job street

Urls urlId 1 2 url abc.com xyz.com

url_relations relationId relatedUrlId relatedUsedId 1 2 3 4 1 1 2 2 1 2 1 2

Para disminuir la duplicacin de los datos (este proceso nos llevar al Cuarto Nivel de F/N), hemos creado una tabla que slo tiene claves externas y primarias url_relations. Hemos sido capaces de remover las entradas duplicadas en la tabla urls creando la tabla url_relations. Ahora podemos expresar fielmente la relacin que ambos Joe and Jill tienen entre cada uno de ellos, y entre ambos, las urls. As que veamos exctamente que es lo que el Cuarto Nivel de F/N. supone: 4.2.4 Cuarto Nivel de F/N. En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla. Ya que slo se aplica a las relaciones varios-con-varios, la mayora de los desarrolladores pueden ignorar esta regla de forma correcta. Pero es muy til en ciertas situaciones, tal como esta. Hemos optimizado nuestra tabla urls eliminado duplicados y hemos puesto las relaciones en su propia tabla. Ahora podemos seleccionar todas las urls de Joe realizando la siguiente instruccin SQL: SELECT nombre, url FROM usuarios, urls, url_relations WHERE url_relations.relatedUserId = 1 AND usuarios.userId = 1 AND urls.urlId = url_relations.relatedUrlId Y si queremos recorrer todas las urls de cada uno de los usuarios: SELECT nombre, url FROM usuarios, urls, url_relations WHERE usuarios.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId

59

4.2.5 Quinto Nivel de F/N. Existe otro nivel de normalizacin que se aplica a veces, pero es de hecho algo complicado y en la mayora de los casos no es necesario para obtener la mejor funcionalidad de nuestra estructura de datos o aplicacin. Su principio sugiere: La tabla original debe ser reconstruida desde las tablas resultantes en las cuales ha sido troceada. Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna extraa en tus tablas y que la estructura de las tablas que has creado sea del tamao justo que tiene que ser. Es una buena prctica aplicar esta regla, pero a no ser que se trate con una extensa estructura de datos probablemente no la

60

UNIDAD VII Lenguaje de Manipulacin de Datos (SQL-DML) OBJETIVO UNIDAD VII: El alumno realizar scripts utilizando el Lenguaje de Manipulacin de Datos (DML) para la actualizacin y consulta de informacin 7.1 Consultas y vistas. Objetivo particular: Identificar las clausulas y sintaxis del DML para la generacin de consultas, manejo de vistas y operaciones con los datos (select, view y funciones de agregado). Actividades: Realizar consultas y vistas de una base de datos con SQL. 7.1.1 Definicin de Consulta SQL En bases de datos, una consulta es el mtodo para acceder a los datos en las bases de datos. Con las consultas se puede modificar, borrar, mostrar y agregar datos en una base de datos. Para esto se utiliza un lenguaje de consultas. El lenguaje de consultas a base de datos ms utilizado es el SQL. Tcnicamente hablando, las consultas a la base de datos se realizan a travs de un lenguaje de manipulacin de datos (DML Data Manipulation Language). SQL es un lenguaje DML, pero adems posee otras caractersticas de otros lenguajes. Por ejemplo, permite tambin crear bases de datos. La consulta bsica en SQL es llamada select from - where. Una consulta SQL bsica puede constar con un mximo de seis clusulas, de las cuales slo dos son obligatorias (SELECT y FROM). Las clusulas se especifican en el siguiente orden: SELECT < lista de atributos > FROM < lista de tablas > WHERE < condicin > GROUP BY < atributo(s) de agrupacin > HAVING < condicin de agrupacin > ORDER BY < lista de atributos > Donde: SELECT: indica qu atributos o funciones se van a recuperar. FROM: especifica todas las relaciones (tablas) que se necesitan en la consulta. WHERE: especifica las condiciones, si es que hacen falta, para 61

seleccionar tuplas de esas relaciones, incluyendo las condiciones de reunin. GROUP BY: especifica atributos de agrupacin. HAVING: especifica una condicin que deben cumplir los grupos seleccionados, no las tuplas individuales. Las funciones agregadas integradas COUNT, SUM, MIN, MAX y AVG se usan junto con la agrupacin. ORDER BY: especifica un orden para presentar el resultado de una consulta. La Estructura tpica para las consultas SQL a bases de datos. El bloque de consulta tiene la siguiente forma: SELECT < lista de atributos > FROM < lista de tablas> WHERE < condicion > La lista de atributos, es la lista de nombres de atributos cuyos valores sern recuperados en la consulta. La lista de tablas, es la lista de nombres de las tablas o relaciones necesarias para procesar la consulta. La condicin, es la expresin condicional (booleana) que identifica las tuplas que sern recuperadas por la consulta. Por ejemplo, la siguiente consulta a una base de datos, da como resultado la lista de alumnos (nombre y apellido) que se encuentran registrados en la tabla ALUMNO donde el curso al que asisten es llamado "informatica": SELECT nombre, apellido FROM alumno WHERE alumno.curso = "informatica"; La clusula WHERE puede ser omitida, lo cual devolvera todos los alumnos. Esta instruccin lo que hace es elegir un campo de la base de datos en concreto o seleccionar todos los campos, ejemplo: Una base de amigos en la que guardamos, Nombre, Apellidos, Telefono. Los campos son Nombre, Apellidos y Telefono. El Select sera: Select nombre : con esto seleccionamos el campo Nombre al cual despues le aplicamos una determinada instruccion, como buscar a los Jose, Pedro, etc... , al igual en vez de poner nombre podemos elegir cualquiera de los otros campos de que se compone la base de datos. 62

Select *: Con esto seleccionamos todos los campos, indistintamente de cuantos campos tengamos, ya sean tres como antes o ms, da igual el nmero de campos, con esto los seleccionamos todos. Estas son las dos opciones que nos da la instruccin Select. A la hora de usar la instruccin Select, debemos tener en cuenta que: * sta instruccin no modifica la base de datos ni su contenido. * Todos los sistemas que usan Sql , tieneTn esta instruccin disponible. * La sintaxis mnima de Select es Select * from Tabla, from se utiliza para especificar cual de las tablas es la que vamos a usar. Otro uso de Select es : Select Campo as variable from table Con sta orden hacemos lo siguiente, supongamos que tenemos un campo muy largo, como Fechaaltaafiliacion, como este campo tiene un nombre muy largo, podemos asignarle una variable que sea mas pequea, osea que sera: Select Fechaaltaafiliacion as fealta from tabla, con esto conseguimos que la variable fealta que es ms fcil de conocer, contenga los datos de Fechaaltaafiliacion. 7.1.1.1 La orden From From significa desde, con esta orden hacemos referencia a la tabla que vamos a usar, el formato seria as: Select * from tabla Con esto especificamos que seleccionamos (select) todos (*) desde la tabla , la tabla ser sustituida por el nombre de nuestra tabla o base de datos, supongamos que tenemos una tabla llamada Clientes y que dentro tenemos los datos de todos nuestros clientes, para poder hacer uso de ellas, haramos esto: Select * From clientes Lo que hemos hecho es seleccionar con el Select todos los registros (clientes) que tiene la base de datos, pues le hemos puesto el asterisco (*) que significa que lo extraiga todo, o sea que extraiga todos los clientes que tuviramos en ese momento dentro de la base de clientes, pues con el from le decimos que de donde tiene que extraerlo todo es desde la base clientes. 7.1.1.2. La orden Where 63

Where significa donde y la usaremos para hacer referencia a algo en concreto dentro de un campo de la base de datos (tabla). Supongamos que tenemos la base de datos de clientes y la hemos seleccionado: Select * from clientes Esto como ya sabemos nos extrae a todos los clientes que en ese momento haya dentro de la base de datos Clientes, pero y si nosotros quisieramos solo los que se llamasen por ejemplo JUAN, tendriamos que extraerlos todos y tener que comprobarlos uno a uno y ver como se llaman, pero con la clausula Where no es necesario, pues lo hace por nosotros. Where solo necesita dos parametros, el nombre del campo donde tiene que buscar y lo que tiene que buscar, lo demas lo hace sola. Entonces, en nuestra base de datos Clientes, tendriamos un campo que se llama Nombre y dentro de el, estan los nombre de cada uno de los clientes en sus respectivas fichas. Para sacar a aquellos que se llamasen JUAN, solo tendriamo que hacer esto: Select * from clientes where nombre='JUAN' Puede ser que en vez de estas comillas ', sean comillas dobles ", o tambien que no use comillas, osea que ira el nombre directamente, esto depende del programa que estemos usando, pero no habra mas problemas al respecto. Esta orden, lo que hace es extraer uno a uno todos los clientes e ir comprobando que en el campo Nombre, se encuentre o no JUAN, si se encuentra , entonces lo seleccionara para mostrarlo despues, si no estuviera dicho nombre entonces lo ignoraria, como es obvio el ahorro de tiempo es muy grande. Pero ademas, la clausula Where tiene unos parametros para hacer mas completo su uso: SELECT * FROM clientes WHERE edad>=28 AND edad<=36 Esto selecciona todos los clientes con edades comprendidas entre los 28 y los 36 aos. SELECT * FROM clientes WHERE provincia='MADRID' provincia='VALENCIA OR provincia= 'BARCELONA' OR

64

Esto selecciona todos los campos de la tabla 'clientes', pero los registros de todos los clientes de las provincias de 'MADRID', 'VALENCIA' o 'BARCELONA'. SELECT nombre, apellidos FROM clientes WHERE edad>=18 Esto selecciona los campos 'nombre' y 'apellidos' de la tabla clientes, escogiendo a aquellos clientes que sean mayor de edad (masr o igual que 18 aos). SELECT * FROM clientes WHERE edad BETWEEN 18 AND 45 Esto selecciona todos los clientes con edades comprendidas entre los 18 y los 45 aos. SELECT * FROM cuentas WHERE fecha=#7/1/97# Esto selecciona los apuntes de 'cuentas' realizados el 1 de Julio de 1.997 (la fecha ha de indicarse en ingls (mes/da/ao)). SELECT * FROM cuentas WHERE fecha BETWEEN #7/1/97# AND #7/31/97# Selecciona los apuntes de 'diario' realizados en Julio de 1.997. SELECT * FROM clientes WHERE nombre LIKE 'JU*' Esto selecciona los clientes cuyo nombre comience con los caracteres 'JU'. SELECT * FROM clientes WHERE apellidos LIKE '*AM' Esto selecciona los clientes cuyos apellidos terminen con los caracteres 'AM'. SELECT * FROM clientes WHERE apellidos LIKE '*GARCI*' Esto selecciona los clientes cuyos apellidos contengan, en cualquier posicin, los caracteres 'GARCI'. 7.1.1.3 Funciones de Agregado de Sql Las funciones de agregado realizan un clculo sobre un conjunto de valores y devuelven un solo valor. Si exceptuamos la funcin COUNT, todas las funciones de agregado ignoran los valores NULL. Las funciones de agregado se suelen utilizar con la clusula GROUP BY de la instruccin SELECT. Todas las funciones de agregado son deterministas. Esto significa que las funciones de agregado devuelven el mismo valor cada vez que se las llama con un conjunto especfico de valores de entrada. Con las funciones de agregado de SQL, se pueden determinar varias estadsticas relacionadas con conjuntos de valores. Estas funciones se pueden 65