lección 5 de bases de datos

Módulo 5: Base de Datos Espaciales

© J.Strobl, M. Compte, R. Resl | 1994‐2014 1 de 54

Lección5DiseñodeBasesdeDatosLaFigura5.1muestraunmodelosimplificadodelasecuenciahabitualdeunproyectodecreacióndeunabasededatos,desdeelanálisisprevio,pasandoportodaslasfases,hasta su finalización. De esa forma, comenzamos a desglosar los componentesdiscutidos.

5.1AnálisisprevioEs imposible ser dogmático sobre el punto de inicio del ciclo de diseño de bases dedatos.Encualquierejerciciodebasededatoshabráunprocesodeinvestigación(previoatomarladecisión)quedecidirásuconstrucción.Elgradodeformalidadconquesellevaráestainvestigaciónvariaráconsiderablementede un proyecto a otro. Para grandes proyectos de base de datos, probablemente sedediquen recursos considerables a la producción de justificaciones de los costes ybeneficios, estudios de viabilidad, análisis de los sistemas, informes sobre lasnecesidadesdelosusuarios,etc.Aveces,seutilizanlosestudiospilotoylosprototiposparaayudaralosdirectivosatomardecisionesdeunaformamásescalonada. Ennuestrapropiaáreadeinterés,porejemplo,hahabidonumerososejerciciosdurantelos últimos años para examinar el proceso de implantación de bases de datos SIG enadministracionesmunicipalesyotrasorganizaciones. Esimportantetenerencuentalaimportanciadeunbuenanálisis,yaquedeestodependedecómoseestructurenlospasosparalacreacióndelproyectodebasededatos,elentenderlasraícesdelproblemarealycomoesteserállevadoaunmodelocomputacional,noescatimarreparoseneltiempodeanálisis,seguroesconveniente



detenerseenelanálisishastalograrunaplenacomprensióndelproblema,quetenerquerealizarmuhcoscambiosenlosdiseñosposterirores.

Fig.5.1:Secuenciadediseñodeunabasededatos

MANTENIMIENTO

IMPLEMENTACIÓN

COMPROBACIÓN

DISEÑO FÍSICO

DISEÑO LÓGICO

Análisis Previo (sistemas disponibles, necesidades

de los usuarios)



5.2Diseñológico

Losdirectivosquetomaránladecisiónvanaexigirqueeldiseñadordelabasededatosproduzca un diseño lógico. Ésto significa que el diseñador tiene que comprenderminuciosamente laestructurade losdatos implicadosyproducirunmodelodedatosconceptualquesirvadefundamentoparalabasededatos.Un modelo de datos conceptual se centra en identificar las entidades, las relacionesentre éstas y los atributos de las entidades que la base de datos debe almacenar. Unobjetivo particular del diseño lógico consiste en identificar el ‘formato natural’ oinherentedelosdatos,demaneraquelesimpongalasmínimasrestriccionesposibles.En labúsquedadel formatonatural, elmétododebasededatosesperahacerque losdatosde laorganizaciónestén igualmentedisponiblespara todas lasaplicacionesquepuedannecesitarteneraccesoadichosdatos.Mientrasqueenelmétodoorientadoalaaplicación los formatos de los archivos de datos tienen que estar dispuestos paraoptimizar la ejecución de actividades específicas, en el método BD los datos sealmacenan en una estructura natural (o neutral) que es igualmente apropiada paratodaslasaplicaciones.Elobjetivofinaleslaobtencióndeunmodelodedatosconceptual,queconsisteenunadeclaraciónlógicadelasentidades,atributosyrelacionesentreentidadesquelabasededatos debe contener.Normalmente, elmodelo de datos conceptual consiste en notas,tablasydiagramasestructurados.Estafasedediseñológicoeselcorazóndelmétododebasededatos,yeltiempoinvertidoenellaayudaráaevitarfuturosproblemas.Un punto a resaltar es que el modelo de datos conceptual debería ser creadoindependientemente de cualquier paquete de software específico. El propósito delmodeloconceptualesofrecerunadeclaración‘pura’delaestructuradelabasededatos.Enteoría,elmodeloconceptualdeberíaserimplementableutilizandocualquierpaquetedeSGBDapropiado.Para ayudar a los analistas a estructurar sus ideas, se han desarrollado una serie detécnicasdemodelamiento.Enlaslecciones6y7vamosaexaminardosdeellas:

ModeladoEntidad‐Atributo‐Relación(EAR) Normalización

El modelado Entidad‐Atributo‐Relación y la Normalización pueden usarse de formaindependiente o bien complementando una con la otra. Amenudo, EAR se usa comotécnica preliminar y un poco ‘vasta’ para desarrollar el modelo inicial de datos. Lanormalizaciónpuedeusarsedespuésparaajustarelmodelopreliminaraunmodelodedatos conceptual que consista enuna seriededefinicionesde tablas apropiadasparausarconunabasededatosrelacional.Existen en la actualidad muchas herramientas automatizadas (CASE), que puedenayudarnosaconstruireldiseñológicoeinclusolossiguientespasosdeldiseñomismo



de la base de datos, sin embargo esto demanda de un conocimiento de dichaherramientaysobretodocomoeslógicodelentendimientodelprocesomismo.

5.3DiseñofísicoUnavezcompletadoeldiseño lógicosatisfactoriamente, lapróximafaseenelprocesogeneralconsisteentraducireldiseñoaunsoftwareSGBD(porejemplo,PostgreSQL,MSAccess, Oracle,MySQL o cualquier otro producto disponible). La fase de diseño físicoimplica establecer la estructura de datos (por ejemplo, estructuras de registros,archivos y nombres de archivos, índices y algoritmos) que traducirá el diseñoconceptualenunarealidadfísicadentrodelsoftwareSGBD.Esenestafasedediseñofísicocuandonuestrodiseñoteóricochocaconlarealidad.Losdiseñosdedatos conceptuales deberían estar basados en una serie de característicasteóricamentedeseables(enlaactualidad,amenudoencajanconlasdelModelodeDatosRelacional). Pero existen pocos paquetes SGBD, si existe alguno, que encajen con elmodeloteórico.Cadasoftwaretienesuspropias limitaciones, idiosincrasiasy,aveces,auténticas‘estupideces’.Normalmente,habiendoproducidoyaunadeclaraciónelegantede la estructura de datos, el diseñador tiene que ser transigente con el diseño lógicoparapoderadaptarloalaslimitacionesdelsoftwareSGBDelegido.Además de la adaptación forzada por las limitaciones del software escogido, eldiseñadorpuede alejarse de la conceptualización teóricamentepurapor razonesmáspragmáticas. A veces, por ejemplo, la estructura teórica más elegante no obtienetiemposderespuestaóptimos.Eldiseño lógicoproduceunadeclaración(óptimaparaelusuario)de laestructuradedatos pragmática informáticamente. El diseño físico, por su parte, produce unadeclaracióndelaestructuradedatos.Lascuestionesrelativasaldiseñofísicosediscutenposteriormenteenlalección8.

5.4ComprobaciónUna vez establecido el diseño de la base de datos, la siguiente fase consiste enasegurarnosquedichodiseñofuncionayquepuedegenerarlosresultadosrequeridosporlosusuarios.Eldiseñosatisfactoriodemétodosdecomprobaciónesunatareadifícil.Elgrannúmerodepeticionesquepuedengenerarse,inclusoconunnúmerorelativamentepequeñodeopciones,significaqueescasiimposiblecomprobarexhaustivamenteunpequeñotrozode código. La literatura sobre ingeniería de software dedica gran atención a latrascendencia de los controles de calidad de los software. Definitivamente, no essuficientecomprobarque ‘funciona’.Tenemosqueprobarque ‘SIEMPREfunciona’(enlamedidaquenosseaposible).



5.5Implementación

Lasiguiente faseconsisteenentrar todos losdatosrealesdentrode labasededatos.Crearunmanualdeuso(ayudas)yquizásunmanualdeejercicios.

5.6MantenimientoLasorganizacionesevolucionancontinuamenteytambiénlaspeticionesasusbasesdedatos. Consecuentemente, una gran parte del tiempo, los profesionales de bases dedatos estarán más ocupados en la actualización y la ampliación de nuevas bases dedatosqueensudiseño.Unodelospuntosfuertesdelmétododebasededatosesqueelmantenimientopuedealcanzarsemáseficientementequeconelanteriormétodoorientadoalaaplicación.Lascuestionescomoelformatonaturaldelosdatosyladisponibilidaddeindependenciadelos datos (que se explica más adelante) hacen el mantenimiento de los SGBD mássencillo.La Figura 5.1muestra diferentes ciclos de feedback en la secuencia de diseñodeunabase de datos. Debemos admitir que esta secuencia es más bien un intento deracionalizacióndeunproceso,amenudodesordenado.Normalmente, losdiseñadoresde bases de datos conocen desde el principio el software SGBD que utilizarán y éstoqueda reflejado en elmodelo de datos conceptual que producen en la fase de diseñológico.Además,losusuariossuelendescubrirloquerealmentequierensólocuandovenel sistema de trabajo, por lo que a menudo hay que rediseñar la base de datosinmediatamentedespuésdela‘Versión1.0’.OtropuntoatenerencuentasobrelaFigura5.1esque,aunqueaquísepresentaenelcontexto de diseño de bases de datos, de hecho es una versión simplificada de unmodelogeneraldeingenieríadelsoftwarequepuedeseraplicadoacualquierproyectodedesarrollodesoftware.

5.7AutomatizacióndelCiclodelSoftwareEneldesarrollodeunsistemadesoftwareesnecesariotomarencuentalasetapasdelciclodevidadelsoftware,yaqueestasnospermitenasegurarqueelsoftwarecumplirácon su objetivo de unamanera estructurada y fiable, en la actualidad se han creadoalgunos métodos para definir el ciclo de vida del software, sin embargo para elconocimiento general presentamos ciertas directrices que se enmarcan en dichosmétodos,estosdebenestablecerunestudiodelossiguientesaspectos:

1. Análisis:Construyeunmodelodelosrequisitos2. Diseño:Apartirdelmodelodeanálisissededucenlasestructurasdedatos,la

estructuraenlaquedescomponeelsistemaylainterfazdeusuario.3. Codificación:Construyeelsistema.Lasalidadeestafaseescódigoejecutable.4. Pruebas:Secompruebaquesecumplencriteriosdecorrecciónycalidad.



5. Mantenimiento:Enestafase,quetienelugardespuésdelaentregaseaseguraqueelsistemasigafuncionandoyadaptándoseanuevosrequisitos.

Lasetapasconstandetareas.Ladocumentaciónesunatareaimportantequeserealizaen todas las etapas ya que nos permitirá registrar adecuadamente los procesos ypermitiráfacilitarlafasedemantenimientoycorreccióndeldiseñoycodificación.Elprocesodediseñoesunapartedelciclodevidadelsoftwarequehasidoaltamentetratadoporempresasdedicadasaestaslabores,tantoeldiseñológicocómoelfísicosonactividadesquepuedenserautomatizadasconuntipodeherramientasconocidascomoCASE (Computer‐Aided Software Engineering ó Ingeniería de Software Asistida porComputadora).El solo estudio de este tipo de herramientas llevaría consigo una buena cantidad detiempo, por lo que dentro de estemódulo indicaremos que son herramientas que sededicanalaautomatizacióndelciclodevidadelsoftwareEn nuestro caso, en la parte de diseño, las herramientas CASE más comúnmenteutilizadas son: ERwin, EasyCASE Oracle Designer, SystemArchitect, entre otras,comprenden el diseño lógico a través de una interfas gráficamás comprensible y sutransformación directa (automática) al diseño físico o viceversa, dando incluso laposibilidaddeutilizarencualquiermomentoelLenguajedeDefinicióndeDatos,paramanipular la estructuramisma de la Base de Datos, esto permite al analista realizarprototipos de froma rápida y concentra sus atención en otras actividades tanto dediseñocomodeimplementación.Si queremos profundizar el tema en la parte de diseño a través de ete tipo deherramientastenemosmuchabibliografíaexistenteatravésdeInternet,eldominiodeestasherramientasconseguridadpermitiránahorrartiempoysimplificarelprocesodediseño e incluso de la codificación de su Base de Datos, siempre y cuando podamostenerunconocimientopreviodelaparteconceptualdeldiseñoeimplementacióndelasBasedeDatos,comotratamosdeexplicareneltranscursodelpresentemódulo.

¿Quéhasaprendidoenestalección?

Elprocesodediseñodeunabasededatosconsisteen lasfasesdeAnálisisPrevio,DiseñoLógico,DiseñoFísico,Comprobación,ImplementaciónyMantenimiento.

PreviaalaimplementaciónfísicadeunaBDtenemosquehacerunplanteamientológicodeésta.

La implementación física,debidoa lanaturalezade laaplicaciónodel software

usado,puedevariarenciertamedidaconrespectoaldiseñológicoinicial. Unabasededatosesunelementoqueevolucionaamedidaquelaorganizaciónlo

hace, requiriéndoseno solomantenimiento regular, sino tambiénampliaciones yreplanteamientos.

Laexistenciadeherramientasdeautomatizacióndelciclodevidadelsoftware,conénfasiseneldiseño,locualpermiteacelerarlacreacióndelaBasedeDatos.



Lección6Diseñológico,ModeloE‐A‐REnestasecciónveremoselmétodoEARparalaelaboracióndeundiseñológicodeunabase de datos. Dicho modelo lo introdujo, en 1976, Peter Chen del Instituto deTecnologíadeMassachusetts,yseusadeformageneralizadacomomediodemodeladodedatos.Susatractivosincluyen:Métododearriba‐abajo:latécnicafuncionadelogeneralhastaeldetalle,yéstaesunaformasencilladeprocedercuandounoounaseplanteacómotratarunproblema.Visual: El modelado EAR consiste esencialmente en una serie de diagramas querepresentanlaestructuradeunconjuntodedatos.Simplicidad: Aunque un análisis completo EAR puede resultar bastante exigente, elsignificadodelosdiagramasEARsimplessepuedeexplicardeformafácilapersonassinformacióntécnica.Aveces, losdiseñadoresutilizan losdiagramasEARendiscusionespreliminaresconusuarioscomounmedioparacomunicarideas.Podemos secuenciar el método E-A-R en tres (posiblemente cuatro) fases: 1. Identificación de entidades 2. Identificación de relaciones entre entidades 3. Identificación de atributos de las entidades (4.Derivación de tablas) Elmétodo EARno produce de forma automática unmodelo de datos conceptual quepueda trasladarse directamente a una base de datos relacional. Como aquí nos



preocupansobre todo lasbasesdedatos relacionales,hemos incluidounacuarta faseentreparéntesisparaindicarqueelmétodoEARpuedeusarseparaproducirunaseriedetablasqueseacerquenmásalastablasrelacionales.

6.1IdentificarentidadesHemosdefinidoanteriormentelasentidadescomo‘objetos’o‘cosas’,esdecir,cualquiercosaidentificableconexistenciaindependienteysobrelacuallaorganizaciónnecesitarecogerinformación.LaprimeraacciónenelmodeladoEARconsisteenexaminarlainformaciónrecogidaenlas investigaciones preliminares y elaborar una lista de todas las ‘entidades’importantes.Enunadescripciónescrita,lossustantivosqueaparecenennuestralistasonamenudocandidatosaserentidades.EnlosdiagramasEARlasentidadessedibujannormalmentecomocajasquecontienenel nombre de la entidad. Así, si estuviéramos modelando una base de datos sobrefamilias,podríamostener:

ESPOSO

6.2IdentificarrelacionesUna relación es una asociación del mundo real entre dos objetos. Por ejemplo, unmaridoyunamujerestán‘casados’,unacompañía‘emplea’aunempleado,ounCenso‘contiene’ Distritos. En descripciones escritas, a menudo son los verbos los que danalgunapistasobrelasrelaciones.En losdiagramasEAR, las relacionesserepresentanconuna líneaentre lascajasqueindicaeltipoderelación.Porejemplo: casados Pude ayudar a comprender si establecemos una buena relación entre las entidades,haciendounalecturalógicadederechaaizquierdayviceversa:ESPOSA casada con ESPOSO LamujerestácasadaconsumaridoESPOSO casado con ESPOSA Elseñorestácasadoconsumujer Puedenexistirmuchasvariantesenlas lecturas,sinembargocomopodemosverdebeexistir una relación lógica entre las entidades a través de su relación, esto ayudará aevitarcomplicacionesenladecisióndeestablecerlasrelacionesentrelasentidades.Un aspecto importante del modelado EAR es determinar el grado de relación. Aquí,grado se refiere al número de instancias (registros) que pueden participar en la

ESPOSA ESPOSO



relación.Lasrelacionespuedenserbienuno‐a‐uno(1:1),uno‐a‐muchos(1:M)omuchos‐a‐muchos(M:N).

Uno‐a‐uno(1:1):Existeunarelacióndeuno‐a‐unocuandounainstanciadeunaentidadpuedetenerunarelaciónconuna(ysólouna)instanciadeotra;osea,larelaciónesentreparesdeentidades.Larelaciónentremaridoymujerpareceunbuenejemplo,unmaridosólopuedetenerunamujer,yviceversa.

El papel de las asunciones En el último párrafo hemos hecho una asunción no explicitada: suponemos que tratamos con una sociedad monógama. Obviamente, ésto sólo será cierto en algunas culturas. Una de las áreas que un diseñador de base de datos debe intentar comprender durante las investigaciones preliminares son las Reglas de la Organización, que determinan cómo trabaja ésta y cómo pueden ser interpretados y usados sus datos. A menudo, igual que hemos asumido (¡casi sin darnos cuenta!) que una mujer sólo puede tener un marido, las reglas de una organización pueden estar tan profundamente asentadas que no resultan aparentes. Maughan-Saunders (1992) se refiere a ‘reglas empresariales’, y apunta que dichas reglas son en verdad un aspecto de la integridad de los datos. Es decir, los datos sólo son válidos (tienen integridad) si la interpretación que hacemos de ellos en la base de datos coincide con la interpretación que les da la organización.

Uno‐a‐muchos: Las relaciones uno‐a‐muchos (1:M) existen cuando una

instancia en un lado de la relación puede asociarse conmuchas instancias delotrolado(peronoviceversa).Porejemplo,unamadrepuedetenervarioshijos,perounniñosólopuedetenerunamadre.

Enundiagrama, lasrelacionesuno‐a‐muchosserepresentancomountenedorconlaspuntashaciaelladodel‘muchos’delarelación: Progenitor de La decisión de utilizar los verbos en la relación es importante, pero esto depende demuchosfactorescómolenguaje,costumbres,ubicación,uotros.Enelpresenteejemploalguiénpodríarelacionarloconelverbo“tener”,asínuestrarelaciónpodríaleersedelasiguienteforma:

UnaMadre“tiene”hijos(plural)

MADRE HIJO



Muchos‐a‐muchos: Las relaciones muchos‐a‐muchos (M:N) existen cuandopueden haber varios participantes en ambos lados del enlace. Piensa, porejemplo,enlarelaciónentrelosestudiantesyloscursos.

Cualquierestudiantepodráparticiparenmásdeuncurso,yloscursosestánpensadospara tener más de un estudiante. En un diagrama, las relaciones muchos‐a‐muchostienentenedoresenambosladosdelalínea: Participan De igual forma el establecer el verbo correcto en la relación dependerá de nuestropunto de vista, es coveniente recordar la relación lógica en la lectura de derecha aizquierdayviceversa,yaqueenalgunoscasospuedeserqueelverbonoencajeenlasdos vías. Sin embargo basta con que el diseñadordel modelo, enmarque suentendimientodelarelación.

6.3IdentificarlosatributosdelasentidadesHabiendoestablecidoentidadesyrelaciones,nosquedalatareadeasignaratributosalas entidades. En las descripciones escritas, los atributos aparecerán amenudo comoadjetivos de los sustantivos. Por su parte, elmodelado EAR sigue la regla de sentidocomúnquedicequelosatributosdeberíanasignarsealasentidades(sustantivos)alasquedescriben.En un diagrama, los atributos pueden mostrarse como elementos que salen de lasentidadesalascualespertenecen(verFigura6.1.a).Sinembargo,losdiagramasEARdegrandes dimensiones pueden saturarse fácilmente si queremos mostrar todos losatributos; por ello, a menudo los diagramas EAR se dibujan mostrando sólo lasentidadesylasrelacionesyluegoseproducensub‐diagramasquemuestransólopartesdeldiagramaprincipalconlosatributosadjuntos.

6.4DerivacióndetablasLas listasdeatributosasociadosconentidadesquesemuestranen laFigura6.1asonunareminiscenciadeladefinicióndecabeceradelModeloRelacionalquepresentamosanteriormente. Así que es tentador asumir que, de la Figura 6.1a, podrían derivarsedirectamentedostablasparadibujareldiseñodeformarelacional:ESTUDIANTE (IdEstudiante,Nombre,Edad,...) CURSO (IdCurso,Nombre,Departamento,...) EstaasunciónNOescorrecta.

ESTUDIANTE CURSO



Fig.6.1:DiagramaEntidad‐Atributo‐RelaciónAunque a la larga queremos derivar definiciones tabulares de los diagramas EAR, enestepuntonopodemosasumirqueexistaunarelacióndirectaentreentidadesEARytablas en el Modelo Relacional, dado que existen todavía algunos problemas quedeberíamosresolverantes.AquívamosahacerreferenciaatresextensionesdelmodelobásicoEAR:

a) Clavesprimariasoprincipalesb) Relacionesentreentidadesc) Gruposrepetidos

a) ClavesprimariasoprincipalesElModeloRelacionalinsisteenquecadafiladeunatabladebeseridentificadadeformaúnicamedianteunaclaveprimaria.ÉstonoformaparteexplícitamentedelprocesoEAR,asíqueesnecesarioasegurarsedequedentrodelosatributosasignadosacadaentidadexistaunaclaveprimariaadecuada.En loscasosenquenoexistatalclave,elanalistadebecrearunaclave‘artificial’enlalistadeatributos.Amenudo,estasclavesimpuestasseránsimplementeunasecuenciaúnicadenumeración.



b) RelacionesentreentidadesComovimosenlalección4,elModeloRelacionalutilizaatributoscompartidos(clavesexternas) para relacionar una tabla con otra tabla. De nuevo, ésto no forma parteexplícitamentedelmodeloEARbásicoyporellodebemosasegurarnosque las clavesadecuadas estén en su sitio dentro del modelo conceptual para que este modelo seajustealosprincipiosrelacionales.Afortunadamente, lasreglasparatransformarrelacionesEARaformatorelacionalsonbastantedirectas:

RelacionesUno‐a‐uno:Cuandoexisteunarelaciónuno‐a‐uno,esposiblereunirlas dos entidades involucradas en una sola tabla relacional. Supongamos, porejemplo, una empresa en la que cadadepartamentopuede tener undirector ycadadirectorpuededirigirsóloundepartamento,osea:

Dirigido por En un Modelo Relacional sería posible reducir esta relación en una tabla única,considerandoaldirectorcomounatributodeldepartamento,deestaforma:DEPARTAMENTO (IdDepto, Nombre_Depto, Localizacion,IdDirector, Nombre_Director) Unaalternativa,más convenientepor razones conceptualesodeprocesamiento, seríamantenerlasdosentidadesseparadasyendostablas,usandounaclaveexternaparalareferenciacruzadaentreellas.Lasoluciónseríaésta:DEPARTAMENTO (IdDepto, Nombre_Depto,Localizacion,Depto.) DIRECTOR_DEPTO (IdDirector, Nombre_Director, IdDepto) obienésta:DIRECTOR_DEPTO (IdDirector, Nombre Director) DEPARTAMENTO (IdDepto, Nombre_Depto,LocalizacionDepto, IdDirector) Ladecisióndemanteneronodostablasdependerádelascircunstanciasdecadacaso.Incluirambasentidadesenunatablasiemprefunciona,perohaycircunstanciasenlas

DEPARTAMENTO DIRECTOR



queusardostablaspuederesultarmáseficaz(verelpárrafode ‘Separacióndetablas’enlalección9).

Relaciones Uno‐a‐Muchos: Supongamos que en una universidad cadaestudiante tiene un (único) tutor personal, pero que los profesores puedenactuar como tutorespersonalesdemásdeunalumno,de formaque tengamosunarelaciónuno‐a‐muchos:

instruye Aquí,losatributosdelosprofesorespuedenalmacenarseenunatabladePROFESOR:PROFESOR (IdProfesor, Asignatura, Salario, etc.) Éstonospermitealmacenardetallessobre losprofesoresaúncuandoéstosnoactúencomotutorespersonales.Losatributosdelosestudiantespuedenalmacenarseen:ESTUDIANTE (IdEstudiante, Curso, IdProfesor) Date cuenta que el Número de Identificación del PROFESOR se ha incluido enESTUDIANTE como clave externa. Ésto significa que es posible identificar para cadaestudiantequéprofesoressututorpersonal.En términos generales, cualquier relación 1:M puede dibujarse en forma tabularañadiendo la claveprincipal deluno en la tabla delmuchos, o sea, creandouna claveexterna.Estasoluciónnospermitemantenerentradasconvalor‘nulo’(null)enlaclaveexterna.Supón,porejemplo,quenuestrauniversidaddecidequedejarádecidiralosestudiantessiquierenuntutorpersonalyquesólotresestudiantesdemildecidenaceptarlaoferta.Significaríaquehabría997valoresnullenlacolumnaIdProfesor.Obviamente,consumeun espacio considerable. Algunos autores ven esta práctica de permitir la entrada devaloresnullenclavesexternascomounproblema.Howe(1985),sugierequesedeberíamantenerelobjetivodeasignaratributosallídondegenerenmenosentradasdevalornull.UnasoluciónalternativaseríaintroducirunatablaintermediaentreESTUDIANTEyPROFESOR:ESTUDIANTE (IdEstudiante, Nombre,...) TUTOR (IdEstudiante, IdProfesor) PROFESOR (IdProfesor, Nombre,...).

PROFESOR ESTUDIANTE



Asíevitamoselproblemadelosvaloresnull,peroacambiocreamosunatablaextraquepodríareducirlavelocidaddeprocesamiento(verlección9).

Relaciones Muchos‐a‐Muchos: El Modelo Relacional no puede acomodardirectamente relacionesmuchos‐a‐muchos tal y como aparecen en la Fig. 6.1a.Sin embargo, las relaciones M:N SIEMPRE pueden ser descompuestas en dosrelaciones1:M,usandolaclaveprimariadecadatablaoriginalcomoatributosdelatablaintermedia.

Así, sivolvemosa larelaciónEstudiante‐Curso(losestudiantestomanvarioscursosylos cursos tienen varios estudiantes). Las cabeceras de las tablas necesarias paraimplementarlarelacióndeformarelacionalson:ESTUDIANTE (IdEstudiante, Nombre,...) CURSO (IdCurso, Titulo,...) MATRICULADO (IdEstudiante, IdCurso) LaFigura6.1bilustratantoelcambioeneldiagramaEAR,queresultadeinsertarunatabla intermedia, como la estructura de la tabla. La tabla intermedia MATRICULADOactúacomoreferenciacruzadaentre lasdostablasoriginales.Talycomose indicaenlas entradas de la tabla Matriculado en la Figura 6.1b, las tablas que usamos paraimplementar una relación M:N siempre tendrán una clave primaria que es unacombinacióndelasclavesprimariasdelasdostablasqueenlazamos.PuntualicemosdosaspectosdeladescomposiciónderelacionesM:N.Primero,respectoal Modelo Relacional, vemos ahora que las tablas pueden usarse para representarRELACIONES así como entidades, nuestra tabla deMATRICULADO representa aquí larelación ‘estudianteestámatriculadoacurso’.Segundo, latablaMATRICULADOpuedeextenderse para albergar atributos sobre el estado de la relación entre estudiantes ycursos. Supongamos, por ejemplo, que necesitamos guardar registro de si losestudianteshanpagadolamatrículadecadacursoalqueasisten.EllugarmásadecuadoparaguardaresteatributoseríalatablaMATRICULADO:MATRICULADO(IdEstudiante,IdCurso,Matricula_Pagada) c)GruposRepetidosUna tercera extensión almétodo EAR necesaria para acercar los diagramas EAR a laformarelacionaleseltratamientodelosgruposrepetidos.

Nota:Enestemóduloaceptaremos laposibilidadde tenervaloresnull enunaclaveexterna.Seguiremoslareglasimpledequelasrelaciones1:Msiempresepueden implementar colocando la clave principal del uno en la tabla delmuchos.



Recuerda de la lección 4 (apartado 4.2.1) que una de las restricciones en el ModeloRelacional es que las entradas de las tablas relacionales deben ser atómicas, es decircadaceldapuedealbergarsolounúnicovalor.Sinembargo,amenudopermitimosenlastablasdepapellaentradadevariosvaloresdelmismotipoenunasolaceldadelatabla.EnlajergadelModeloRelacionalesungruporepetido,yesnecesarioeliminarlosdelosmodelosconceptualesquedebenpresentarsedeformarelacional.Pongamosunejemploparaclarificarlascosas.Imaginaqueestamoscreandounabasededatosdefamiliasapartirdeunatablaconlasiguientecabecera:FAMILIA (Apellido, Direccion ,(Coche)) dondelosparéntesisenCocheindicanlaposibilidaddequeunafamiliatengamásdeuncoche,demodoqueCocherepresentaungruporepetidodentrodelatabla.Algunosmodelosdebasededatospuedenmanejarestetipodeestructurasindificultad,perolainsistenciadelModeloRelacionalenlasestructurastabularessimplessignificaquedebemostomarmedidasparaeliminarlosgruposrepetidos.LaFigura6.2ilustraelproblemaylasoluciónmásadecuada.Comoacabamosdedecir,encajarmásdeunaentradaenunasolaceldaenunatablarelacionalestáprohibido(verFigura 6.2). Pero ¿quizá podamos simplemente añadir una columna extra llamada‘segundocoche’?Éstotampocoesunabuenaidea.Silamayoríadelasfamiliasresultantenersólouncoche,habrámuchoespaciomalgastadoyaúnpeor,¿quéocurrirácuandolosRibascomprenuntercercoche?(Figura6.2b).Quizápodamosañadirfilasextraalatabla,peroquerríadecirduplicarelnombrey ladireccióndelasfamiliastantasvecescomocochesposean(Figura6.2c)yduplicardatosenunabasededatos(sinunabuenarazón)activalaseñaldealarma.Laúnicasoluciónsatisfactoriaescrearunanuevatablaespecíficamenteparaalbergarlosgruposrepetidos,deestaforma:FAMILIA (Apellido, Direccion) COCHES PROPIEDAD (Apellido, Coche) Ésto resuelve el problema sin crear campos null(ver Figura 6.2d). Así pues, la reglageneral es que la repetición de campos se resuelve estableciendo una tabla separadaparaloscamposrepetidos.Éstosetraduceenunaentidadadicionalyunarelación1:MenlosdiagramasEAR.



Fig.6.2:LosproblemasdelosgruposrepetidosHastaaquíesdondenecesitamosllegarconelmodeloEAR.Lospasosquehemoshechohasta ahora no garantizan que las tablas producidas se ajusten completamente a lasexpectativas del Modelo Relacional. Sin embargo, hemos mostrado lo suficiente delmétodo como para ilustrar de qué forma el modelado EAR puede ser muy útil paraayudaralosdiseñadoresdedatosa‘pensarcómotratarunproblema’.Para conocermás en detalle el comportamiento de las tablas, tomaremos la segundatécnicadediseño,laNormalización,queexplicamosenlasiguientelección.



6.5¿Quéhasaprendidoenestalección?

El modelado EAR (entidad‐atributo‐relación) proporciona un medio gráfico eintuitivoparaexplorarlaestructuradeunconjuntodedatos.

Las entidades acostumbran a ser las cosas o sustantivos y los atributosacostumbran a ser los adjetivos de esos sustantivos o elementos que definen adichasentidades.

Haytrestiposderelacionesentreentidades:Uno‐a‐uno(1:1),Uno‐a‐muchos(1:M)yMuchos‐a‐muchos(M:N).

Enlasrelaciones1:1ambastablaspuedencombinarseenunasolaoañadirunadelasclavesprimariascomoclavesecundariadelaotra.

En las relaciones1:M incluiremos la claveprimariade la tabla ‘Uno’ como claveexternaenlatabla‘Muchos’.

EnlasrelacionesM:Ntendremosquegenerarunaterceratablaparaalmacenarlarelación.Dicha tabla deberá tener como claves externas las claves primarias decadaunadelastablasMyN.



Lección7‐Diseñológico,NormalizaciónLanormalizaciónesotratécnicademodeladodedatosparaeldesarrollodeundiseñológico que, a diferencia del modelado EAR, evolucionó directamente del ModeloRelacional, por lo que un conjunto de tablas que hayan sido ‘normalizadas’ con éxitotienenlagarantíadecumplirconlasexpectativasdelModeloRelacional.LascaracterísticasdelaNormalizaciónson:

Métododeabajohaciaarriba:SiEAResunmétododearribahaciaabajo(delomásgeneralalomásdetallado), laNormalizaciónempiezaconeldetalledelosatributos y aplica una serie de transformaciones para crear una estructurageneralpartiendodeldetalle.

Formal:SiEAResunmétodovisualconelcualunopuede‘garabatear’elcamino

hacia una solución, la Normalización es un método que sigue un conjunto dereglas que deben ser aplicadas en una secuencia particular de forma que seasegurelacreacióndelastablasapropiadas.

El proceso de Normalización puede entenderse como una sucesión de fases:

1. Reunir una lista con todos los atributos 2. Establecer algunas tablas iniciales



3. Aplicar la Primera Normalización 4. Aplicar la Segunda Normalización 5. Aplicar la Tercera Normalización (6. Aplicar las Normalizaciones Cuarta y Quinta si es necesario). (7. Comprobar las relaciones)

Date(1995)señalaquelaNormalizaciónesbásicamenteunaformalizacióndealgunasideasmuy simples y de sentido común sobre las características que las tablas debenmanejar bien en una base de datos relacional. Algunos textos parecen olvidar estasimplicidadypresentanexposicionesdeltemamuyrigurosas.Intentaremosencontrarelpuntomedio.

7.1ReunirunalistacontodoslosatributosSi la técnica de Normalización se usa independientemente de cualquier otra técnica,entonceselpuntodepartidaseríaestablecerunalistadetodoslosatributosasociadosconunsistema.Teóricamente,éstopuedeentendersecomoelpasodereunirunaúnicatablaprototipoqueincluyatodoslosatributos.Alolargodeestalecciónusaremosuncaso de estudio sobre comercios relacionados con la venta de muebles para darejemplosdelprocesodeNormalización:Comercio(cadaunode los atributosde laBDComercio)

7.2IdentificarlastablasinicialesElpasosiguientealatablaprototipo(laprimeratablacontodoslosatributos),consisteen reunir una serie de tablas provisionales cada una de las cuales parece agruparatributosquepertenecenalamismaentidad.Sireconocemosqueenunabasededatosrealpuedenhabervarioscientosdeatributos,entoncessabremosquelatareainicialdeldiseñadorparaidentificarentidadesyasignaratributos a las entidades puede ser muy dura. Por esta razón, muchos diseñadoresusaríanunaversióninformaldelmodeladoEARquelesayudaríaaproducirunconjuntode tablas provisionales sobre las cuales podrían aplicar después las técnicas denormalización.Paranuestraexploraciónde laNormalización,asumiremosqueundiseñadordedatosha producidoun conjunto inicial de tablas para la base de datosde laUDE (ver casopráctico),unadelascualeses:

FABRICA (FabricaId, Nombre, Direccion, (CodigoProducto, DescripcionProducto, Marca), FechaApertura, Area, ResponsableArea)

yutilizaremostécnicasdeNormalizaciónparamejorarlaestructuradeestastablas.



PorloquehemosvistodelmodeladoEAR,sabemosqueintentarimplementarestatablaen una base de datos relacional causaría serios problemas. Puedes pensar que losproblemasconFABRICAsontanobviosquenadieempezaríajamásporsemejantetabla.Perorecuerdaqueenunejercicioreallasrelacionesentreatributosyentidadespuedensermuycomplejas,ylastablasinicialespuedenmuybiensermerasaproximacionesaloquerealmenteresultará(Encualquiercaso,yparaserhonestos,sinoempezáramosporuna tabla problemática, no podríamos enseñarte de qué manera la Normalizaciónmejoralascosas,¿verdad?).DibujarunatablaconlaestructuradeFabrica(Figura7.1)deberíamostrarclaramentelosproblemasconlatabla:‐lasfilasenlatablatienennúmerosvariablesdeelementos.Lasfilas1y3tienennueveelementoscadaunamientrasquelafila2,acausadelosgruposrepetidosdeproductos,tieneveintisieteelementos.ÉstocontradiceclaramenteelModeloRelacionalyconsumeespacio.‐ sólo losproductosqueactualmentesemanufacturanen,almenos,una fábricade laciudadpuedenregistrarseen la tabla.Si la fabrica5cesasuproducción,porejemplo,perdemosdetallesdelcódigoyladescripcióndeCerradurayTornillos.

JERGA En la jerga de las bases de datos relacionales, ésto se conoce formalmente como una anomalía de suprimir. Como la tabla no está formada correctamente, si suprimimos un elemento estaríamos forzados a suprimir otro elemento que quizá queramos conservar.

‐ennuestradescripcióndelsistemadelaUDEdijimosquelaUnidadnecesitaconocertodosloscódigosydescripcionesdeproductos,segúnlaclasificacióndelgobierno,ynosóloloscódigosparalosproductosqueactualmenteproducenlasfábricasdelaciudad.Perosivamosausar la tabladeFabricaparaalbergar la informaciónsobrecódigosydescripciones de Productos, tenemos un problema.No podemos insertar informaciónsobreunproductohastaqueunafábricaenlaciudadempieceaproducirlo.

JERGA ¡Sorpresa! Ésto se conoce formalmente como la anomalía de insertar, y es el reverso de la anomalía de suprimir. Aquí el problema viene causado por la inclusión, en una misma tabla, de dos entidades lógicamente separadas, en este caso producto y fabricante, de forma que no podemos insertar datos sobre una instancia de una de ellas hasta que no tengamos una instancia apropiada de la



otra. Ambas anomalías, Suprimir e Insertar, son resultado de tener en una tabla atributos que pertenecen a dos entidades lógicamente separadas.

FABRICAFabricaId

Nombre Direccion Fecha Apertura

NumeroArea

ResponsableArea

CodigoProducto

Descripcion Producto

Marca

1

ACE Ltd

‐‐‐‐‐‐

90 1 Smith 101 Nuts

SupaNuts

5

IMPS Co

‐‐‐‐‐‐

84 2 Jones 102

101 103

Bolts Nuts Screws

BestBolts BestNuts BestScrews

3

JACKS Ltd

‐‐‐‐‐‐

70 1 Smith 101 Nuts

JacksNuts

Fig.7.1:Tablanonormalizada‐ se da una innecesaria duplicación de datos. Si la descripción de Tuercas cambia aTuercas Cuadradas, serían necesarias actualizaciones para cada fábrica que producetuercas.

JERGA Ésta es la anomalía de Actualizar. Cuando los datos están duplicados, siempre existe el peligro de que la integridad de la base de datos se degrade porque sólo se ha conseguido una actualización parcial, dejando algunos registros sin modificar.

‐DatecuentaqueNumeroAreayResponsableAreasiemprevanemparejadas.CuandoelNumeroAreaes1,elresponsabledebeserSmith,cuandoes2,debeserJones.Estáclaroque aquí hay algo que no funciona, ya que los nombres de los responsables estaránrepetidosinnecesariamente.Las tablas, como la de Fabrica, que muestran características no satisfactorias, seconocen como no normalizadas. Las técnicas de normalización pueden aplicarse deforma secuencial a estas tablas para producir tablas normalizadas, o sea,relacionalmente ‘correctas’ (Figura 7.2). El resultado de cualquier proceso denormalizaciónesproducir,apartirdeunatabla,dosomástablasquetendránmejorescaracterísticas.Asípues,laNormalizaciónesconsisteenseparar,repetidamente,tablasentablasmáspequeñasydemejorrendimiento.



Retirada de grupos repetidos Eliminar la dependencia parcial Eliminar la dependencia transitiva

Fig.7.2:SecuenciadeNormalización

7.3PrimeraFormaNormal(1FN)

LaPrimeraFormaNormal implicasimplemente laretiradade losgruposrepetidosdeuna tabla. Como ya hemos encontrado el problema de los grupos repetidos en elmodeladoEAR,podemostrataréstodeformarápida.TodoloquenecesitamoshaceresdividirFabrica endos tablas, Fabrica2yHechoPor, éstaúltima conteniendo losdatosrepetidos:

Fabrica2 (FabricaId, Nombre, Direccion, FechaApertura, NumeroÁrea, ResponsableArea) HechoPor (FabricaId, CodigoProducto, DescripcionProducto, Marca)

Las tablas de la Figura 7.3 ilustran el resultado de la tabla. Date cuenta que la claveprimaria de la tabla madre (FabricaId) se ha introducido en ambas tablas ‘hijas’(FABRICA2yHECHOPOR).

RELACIONES NO NORMALIZADAS

PRIMERA FORMA NORMAL (1FN)

SEGUNDA FORMA NORMAL (2FN)

TERCERA FORMA NORMAL (3FN)



FABRICA 2 HECHOPOR FabricaId CódigoProducto DescripcionProducto Marca 1 101 Nuts SupaNuts

5 102 Botls BestBolts 5 101 Nuts BestNuts 5 103 Screws BestScrews

3 101 Nuts JacksNuts

Fig.7.3:PrimeraformaNormalAl fnalizar la Primera Forma Normal el diseño aún no está terminado, pero en estemomentonodeberíamostenerningúngruporepetido.

7.4SegundaFormaNormal(2FN)LaSegundaFormaNormalseusaparaeliminarunproblemaquesólopuedeaparecerentablasenlasquelaclaveprimariaesunacombinacióndeatributos.ComoFabrica2tiene una clave primaria basada en un único atributo, no sufre este problema y porahorapodemosolvidarnosdeella.Fabricayaestáen2FN.

Examinemosahora latablaHechoPor.Laduplicidadde informaciónen latablaquesemuestra en la Figura 7.3 debería alertarte del hecho que todavía existen problemas.Para identificar un nombre de marca necesitamos saber tanto el valor de FabricaIdcomo el de CodigoProducto, es decir, ‘SuperTuercas’ sólo puede ocurrir cuandoFabricaIdes5yCodigoProductoes101.ÉstosignificaquelaclaveprimariaparalatabladebeserFabricaId+CodigoProducto.EnlajergadelaNormalización,sediríaqueMarcaesfuncionalmentedependientedeFabricaId+CodigoProducto. La DescripcionProducto, sin embargo, es funcionalmentedependiente sólo de CodigoProducto, es decir que si CodigoProducto es 102,DescripcionProducto siempre debe ser ‘Cerradura’. Así, con la tabla en su formatoactual,siuncentenardefábricashacentornillosladescripcióndelproducto‘tornillos’estaráduplicadacienveces.

JERGA Formalmente, el atributo Y es funcionalmente dependiente de la clave X si, y sólo si, cada valor de X en una tabla está asociado exclusivamente con un valor Y.

FabricaId Nombre Dirección FechaApertura

NumeroArea

ResponsableArea

1 ACE Ltd ------ 90 1 Smith 5 IMPS Co ------ 84 2 Jones 3 JACKS Ltd ------ 70 1 Smith



La Dependencia funcional total ocurre cuando la clave X es una clave compuesta y son necesarios los valores de todos los elementos de la clave para determinar el valor de Y. La Dependencia funcional parcial ocurre cuando la clave X es una clave compuesta y el valor de Y está determinado por sólo una parte de los componentes de la clave.

Para evitar duplicación innecesaria, HechoPor puede dividirse en dos tablas máspequeñas:

HECHOPOR2 (FabricaId,CodigoProducto, Marca) PRODUCTO (CodigoProducto, DescripcionProducto)

Dividir HechoPor en dos tablas no sólo elimina la duplicación innecesaria deDescripcionProducto en nuestromodelo, sino que además significa que, dado que latabladeProductosnocontieneningunareferenciaafabricas,podemosusarlatabladeProductosparaalmacenarlaclasificaciónenteradeProductos,sinimportarsialgunadelasfábricasenlaciudadmanufacturaproductosespecíficos(verFigura7.4).Fig.7.4:SegundaFormaNormalFABRICA 2

HECHOPOR 2 FabricaId Código

ProductoMarca

1 101 SupaNuts 5 102 BestBolts 5 101 BestNuts 5 103 BestScrews3 101 JacksNuts

PRODUCTO Codigo Producto

Descripción

101 Nuts 102 Bolts 103 Screws



JERGAEn términos formales del modelado relacional, 2FN trata con los problemascausados por dependencias parciales, sabiendo que una dependencia parcialocurrecuandoelvalordeunatributoquenoactúadeclaveesdeterminadoporunaparte,ynoporlatotalidad,deunaclaveprimaria.Una tabla está en segunda formanormal si está en primera forma normal ytodossusatributosquenosonclavessondependientesdeunaclaveCOMPLETA.

7.5TerceraFormaNormal(3FN)

Ahora ya hemos creado tres tablas más pequeñas a partir de nuestra tabla inicialFABRICA,perositefijasenlatablaFabrica2enlaFigura7.3verásquetodavíatenemosunproblema.Denuevo,laduplicidaddedatoseselsignodealarma.LosnombresdelosResponsablesArea se repiten cada vez que su NumeroArea es listado. Ésto ocurreporque el valor de ResponsableArea es funcionalmente dependiente no sólo deFabricaId sino también del valor de NumeroArea: si sabes el NumeroArea, puedespredecir el ResponsableArea. La solución es, de nuevo, dividir las tablas (ver Figura7.5):

Fabrica3 (FabricaId, Nombre, Direccion, FechaApertura, NumeroArea) Area(NumeroArea, ResponsableArea)

JERGAAquí el problema es la dependencia transitiva. Una dependencia transitivaocurrecuandoelvalordeunatributoquenoesclaveesdependientedelvalordeotroatributoquetampocoesclave.Unatablaestáenterceraformanormalsiestáensegundaformanormalycadaatributonoclaveesindependientedecualquierotroatributoquenoesclave.

En elmomento en que las tablas han sido transformadas a 3FN, funcionaránadecuadamente en un SGBDR (RDBMS). Las tablas en 3FN habrán eliminadoduplicacióninnecesariaytendránunaestructurainternasimple.



Fig.7.5:TerceraFormaNormalTABLAS: PRODUCTO (CodigoProducto,DescripcioProducto)

FABRICA3 (FabricaId,Nombre,Direccion,FechaApertura,CompañiaId, NumeroArea) AREA (NumeroArea,ResponsableArea) HECHOPOR (FabricaId ,CodigoProducto,Marca)

ExistendosfrasesqueayudanamemorizaryresumirlosobjetivosalosquedeberíanaspirarlosmodelosdedatosconceptualesbasadosenelModeloRelacional,frasesquela3FNproporcionayquevalelapenaescribirenmayúsculasynegrita:‘UNHECHOENUNLUGAR’(osea,evitarlasduplicacionesinnecesarias)‘CADAATRIBUTOQUENO ESCLAVEDEBERÍA SERDEPENDIENTEDE LA CLAVE(1FN),DETODALACLAVE(2FN)YDENADAMÁSQUELACLAVE(3FN)’



SirepasaslastablasquemuestralaFigura7.5verásqueéstassonlascaracterísticasdelascuatrotablasquecreamosapartirdelatablainicialFabrica.Conlaexcepcióndeladuplicación necesaria para establecer claves externas, todos los hechos sonalmacenadossólounavezenlastablas,yporellolaposibilidaddeencontraranomalíasdeactualizaciónquedadescartada.Dadoqueeliminamoslasduplicaciones,eltamañototaldelabasededatosseguramentese reducirá.Ennuestro ejemplo, el ahorrodeespacio aniveldenúmerode celdas esmodesto,habiendo45celdasenlatablainicialFabricay40enlascuatrotablasfinales;allídondeseaprobableencontrarmuchoscamposrepetidos,elahorrodeespacioserámayor. Date cuenta, además, que el hecho de que los campos clave sean los únicosatributosquepuedenduplicarselegítimamenteenundiseño3FNseaconsejaelusodecamposclavecortos,paraminimizarlademandadeespacio.

7.6CuartayQuintaFormasNormales

Las formas normales Cuarta y Quinta tratan casos especiales que parecen existirbásicamenteenlossueñosdelosInformáticos.TambiénexisteunmétodoalternativoalanormalizaciónllamadoNormalizacióndeBoyce‐Codd.Como nuestro propósito es simplemente saber que las tablas que diseñamosfuncionarán adecuadamente podemos ignorar tranquilamente estas otras formas denormalización,bastándonossaberdesuexistencia.

7.7ComprobarlasrelacionesComo has visto, 1FN, 2FN y 3FN se concentran en refinar una tabla concreta en unaseriedetablasmáspequeñasyeficaces.EmpezamosnuestrocasoconunatablallamadaFabrica y terminamos con cuatro tablas (Fabrica3,Area, Producto yHechoPor).Dadoqueestascuatrotablassehancreadocomopartedeun‘árbol’denormalizaciónúnico,podemos esperar que esta familia de tablas poseerá las relaciones de clave externanecesariasparaenlazarlascorrectamente.Seguramente el diseñador de datos habrá desarrollado secuencias de normalizaciónsimilares sobreotras tablasprovisionales creadasdesde la listade losatributosde laUDE (quizás ‘Compañia’, y ‘Empleo’); ahora estará revisando una serie de familias detablasmáspequeñas,ynecesitaráasegurarsedequelastablasderivadasdediferentesmadrestienenlassuficientesclavesexternasparapoderlasrelacionarentreellas(AquíestaríajustificadoelusoparaleloopreviodelastécnicasEAR,yaqueEARdibujaunasrelaciones entre tablas muy claras). En nuestro caso de estudio, veremos que notenemoselenlacenecesarioentreFabricayCompañia,asíquetendremosqueinsertarCompañiaIdenFabrica3.Lacantidaddeenlacesysunaturalezadependerá,obviamente,delacalidaddenuestrospuntos de partida, o sea de las tablas provisionales, que usemos. Por ejemplo, si



hubiéramos empezado con una tabla provisional llamada Compañia, que incluyeraFabricacomogruporepetido,esdecir:

Compañia(CompañiaId,..,..,(FabricaId,NombreFabrica,etc),..)

elenlaceentrelastablasfinalesCompañiayFabricahubierasurgidodeformanaturaldelanormalizacióndeCompañia.Perounonosiemprepuedeestarsegurodeempezarporelpuntoideal,asíqueesaconsejableunacomprobaciónpragmáticaparaasegurarquetodaslasclavesnecesariasestánensusitio.Al finaldelprocesodenormalización, las tablas intermediassondescartadas,dejandounmodelodedatosformadosóloportablasqueestánenTerceraFormaNormal.EnelcasodelaUDE,elprocesodenormalizacióndeberíaproducirelmismoconjuntodetablasquefueproducidodesdeelanálisisEAR,esdecir:

FABRICA(FabricaId,Nombre,Direccion,FechaApertura, CompañiaId,NumeroArea) COMPAÑIA(CompañiaId,Nombre,DireccionSede) PRODUCTO(CodigoProducto,DescripcionProducto) EMPLEO(FabricaId,FechaEncuesta,NumeroEmpleados) HECHOPOR(FabricaId,CodigoProducto,Marca) AREA(NumeroArea,ResponsableArea)

En la siguiente lección mostraremos cómo pueden implementarse en PostgreSQL unconjuntosimplificadodeestastablas.

7.5DocumentarelmodeloconceptualEstafasenoesexclusivadelprocesodeNormalizaciónydeberíarealizarsetambiénconelmodeladoEARoencualquierotroprocesodediseñoquerealicemos.Si eres como la mayoría de la gente, has estado trabajando en tu mesa intentandoproducir un modelo de datos conceptual para el problema de la UDE. Seguramenteahoraestarásrepasandounmontóndepapelesquesignificanalgoparati,peroquenosignificarían demasiado para nadie más. Peor aún, si tienes que volver a tus notasdentrodeunmes, tampoco significaránmuchopara ti.Asíqueahoraesmomentodeintentardocumentartumodeloconceptual.Está claro, como con todos los informes, que la forma de un documento del modeloconceptualcambiaráencadacasoparticular.Peropodemosponernosdeacuerdoenunconjuntodeelementosquenormalmentedeberíanestarincluidos:1) ReglasdelaOrganizaciónCualquier modelo conceptual reflejará la forma en que el diseñador ha entendido elfuncionamiento de la organización o el sistema. Es imposible construir un modeloconceptualsinhaceralgunasasuncionessobrelosusoseinterpretacionesdelosdatospermitidos.Laformamásdirectadehacerexplícitaslasasuncionesquehasutilizadoes



escribirlas en una lista de ‘normas de la organización’. Para ser prudente, tambiénpodríashacerquetucliente/aojefe/acomprobaraquetulistacoincideconlasuya.2)UndiagramaEntidad‐RelaciónIndependientementedesiutilizas formalmenteelmétodoEARono,undiagramaquemuestre cómo las entidades se relacionanunas conotras esunmedioexcelenteparacomunicarlaestructuradetumodeloatimismoyaotros.2) UnconjuntodedefinicionesdetablasSi el modelo conceptual está basado en el Modelo Relacional, entonces un elementoesencialdeladocumentaciónseráunconjuntodecabecerasdetablasen,almenos,3FN.Duranteelprocesodecreacióndeunmodeloconceptual,eldiseñadorpuedeusartodotipodenombrescrípticosparatablasyatributos,peroladocumentaciónfinaldebesercomprensibleparaotragente,demodoquedebemantenerseunapolíticaconsistenteala hora de poner los nombres. Maughan‐Saunders (1992) sugiere algunasconvencionespara losnombres en las tablas.En suopinión, elnombredeuna tabladeberíaser:

Único: o sea, cada tabla en una base de datos debe ser identificada por unnombreúnico.

Descriptivo:elnombredelatabladeberíareflejarlomásclaramenteposiblelaentidadcontenidaenlatabla.

Singular:elnombredelatabladeberíadescribircadaunadelasfilas,yporello

deberíaestarsiempreensingular.PorejemploComercio,enlugardeComercios.

Legal: (Nota) Aquí rompemos nuestra regla de que el modelo de datosconceptual debería ser generado independientemente de cualquier SGBDRespecífico.(Perocomoenelmomentodeestarconsiderandolasconvencionesdelos nombres estamos tan cerca de implementar nuestro diseño, ésta es unatransgresión permitida). Todos los paquetes de softwaretienen sus propiasrestriccionesenlaformadelosnombresqueaceptan.MuchosSGBDRutilizanlosnombresdadosa las tablascomonombresdelarchivo,asíque losnombresdeéstasdebensernombresdearchivoaceptadosporelsistemaoperativo.

4)UnalistadedefinicionesdeatributosCadacabeceradetabla incluyeuna listade losatributosqueestáncontenidosenella,pero también es necesario dar más detalles de cada atributo por separado. Aquí denuevodifuminaremosunpocoladistinciónentrelostemasrelacionadosconelmodeloconceptual y los que anticipan la implementación. Cuando definimos atributos, esnecesarioconsiderarlossiguientestemas:



Nombres: Todos los temas de preocupación referentes a los nombres de lastablastambiénafectanalosnombresdelosatributos.Denuevo,siunnombredeatributoeslegal,ono,dependerádelpaqueteinformáticoutilizado.

Otraconsideraciónreferentealtemadelosnombresdelosatributosessipodemos,odebemos, usar elmismonombre en tablasdiferentes.Ennuestrabasededatosde laUDE,porejemplo,tenemospotencialmentedosatributosalosquenosgustaríallamar‘Nombre’:losnombresdelasfábricasylosnombresdelascompañías.SQLpermiteusarlos nombres de las tablas como calificativos que especifican a qué atributo nosreferimos cuando nos encontramos con atributos de tablas diferentes, pero con elmismo nombre. Así, ‘Compañia.Nombre’ significaría el atributo Nombre en la tablaCompañia, y ‘Fabrica.Nombre’ sería el atributo Nombre en la tabla de Fabrica. En lapráctica,sinembargo,elusodenombresdetablascomocalificativosparalosatributosimplica texto innecesario, así que seguramente preferiríamos usar nombres para losatributos que sean únicos A TRAVÉS de las tablas, en este caso: NombreFabrica yNombreCompañia.Existe una excepción para usar nombres únicos cuando tratamos con atributos quefuncionancomoclavesexternas.Enestoscasosesconvenienteutilizardeliberadamenteelmismonombreparaunatributoqueesclaveexternayclaveprimariaenotratabla.Estoayudaalosusuariosydiseñadoresarecordarqueelatributofuncionacomoenlaceentredostablas.

TiposdeDatos:Un tipodedatos describe la naturaleza de los datos queunacolumna de atributos puede aceptar. De nuevo, ésto es específico para cadapaquete de software. En dBASEIV, por ejemplo, los atributos pueden definirsecomounodelosochotipossiguientes:SmallInt,Integer,Decimal,Numeric,Float,Char,DateyLogical.Access SQL soportaonce tipos (Binary,Byte,Bit, counter,currency, datetime, single, double, short, long, longtext). Para algunos tipos dedatos, tales comoChar yTexto, también esnecesario especificar el númerodecaracteresrequeridosporlacolumna.

Dominio:Eldominiodeunatributoeselconjuntodetodoslosvaloresposibles

que puede tener el atributo. Supongamos, por ejemplo, que la clasificación deProductosdelgobiernopresentacódigosdel1al5000.EldominiodelatributoCodigoProductoseríantodoslosenterosde1a5000,excluyendodeestaformacualquierentradanegativaosuperiora5000.De formasimilar, sinecesitamosCodigosPostales en nuestra base de datos de los comercios, deberíamosespecificarundominiopara loscódigospostalesque incluyerasólo loscódigosexistentesdentrodelaciudadyregistradosenunformatoespecífico.

En la práctica, con los paquetes SGBDR ésto no siempre es posible puesto que, comoacabamos de ver, la mayoría de dichos paquetes sólo pueden soportar un númerolimitadodetiposdedatos.Lomejorquepodemoshaceres incluirennuestromodeloconceptualnotassobre lasrestriccionesquenosgustaría imponera losvaloresde losatributos.Mástardequizálasimpondremosatravésdelacodificacióndeaplicaciones.



La Figura 7.7 proporciona una de las posibles presentaciones de las notas sobreatributos para la tabla FABRICA en la base de datos de la UDE asumiendo lasrestricciones de dBASE IV SQL (Fíjate que si antes hemos citado Dirección como unatributoúnico,aquílohemosdescompuestoenunaseriemásrealistadeatributos).FABRICA‐Fig.7.7:NotasdelosatributosenlatablaNombredBase

Nombrecompleto

Tipodedatos

ValoresNulos

Único Dominio,restricciones,notas

FabId Identificadordefábrica

SmallInt NoNulo Único Claveprimariadefábrica.NoaparecenlosFabIddelasfábricasquehandejadodecomerciar.

Extension NomFab Nombre de la

fábricaChar(30) NoNulo Aceptamayúsculasy

minúsculas.Calle Char(30) Localidad Char(30) Hayquedefinirun

listadodelocalidadesvalidas.

Pueblo Char(12) Mayúsculas.Eldominioes‘HUDDERSFIELD,DEWBURY,BATELY,HECKMONDWIDEyCLECKHEATON.

CP Códigopostal Char(8) Formatoestándar.Comprobarsemanalmentelavalidezdelosdatos.

FechaAper Fecha deApertura

SmallInt Fechaenquelafábricaempezólaactividad.

CompId IdentificadordeCompañia

SmallInt Claveexterna.VertablaCompañia.




LaNormalizaciónproporcionaunmedio formal(opuestoalmodeladoEAR)paraanalizarlascaracterísticasdelastablas.

Elprocesoempiezaporgenerarunaúnicatablacontodalainformaciónnecesariaparaelsistema(tablaprototipo).

Latablaprototipoirásufriendomodificaciones(mejoras)alolargodelasdistintasFormasNormales.

LastablasenTerceraFormaNormalfuncionancorrectamenteenunSGBDR.

Cadaatributo(decadatabla)quenoesclavedeberíaserdependientedelaclave(1FN),detodalaclave(2FN)ydenadamásquedelaclave(3FN).

Ladocumentaciónesesencial.



Lección8‐DiseñofísicoHabiendoproducidounmodelo conceptual de unabasededatos, el próximopaso esconsiderar cómo funcionará ésta en la práctica. Hay una serie de cuestiones que esnecesario considerar. Por ejemplo: ¿El tiempo de respuesta de la BD será aceptable?¿QuétamañotendrálaBD?y¿Tenemossuficientecapacidaddememoriaenelsistemaparasoportarla?Si laBDdebefuncionarenred,deberemosconsiderarlostiemposdetransmisión y seguramente la asignación físicade laBDen variosprocesadoresde lared. Si procede, ¿es necesario comprar equipo nuevo y decidir qué especificacionestendrálanuevainstalación?El proceso de reconciliar un modelo de datos conceptual con una configuraciónespecíficade softwareyhardware es la fase físicadel procesodediseñodebasesdedatos.NormalmentelaestructurafinaldelaBDseráuncompromisoentreloideal,talycomo está representado en el modelo conceptual, y lo posible, tal y como vieneimpuestoporlaslimitacionesdeinstrumentosyaplicacionesespecíficas.Unadiscusióncompletadelostemasdeldiseñofísiconoeselobjetivodeestalección,peropodemosilustrarlanaturalezadedichostemasrepasandobrevementedosdelasmayorespreocupacionesdentrodeldiseñofísico:velocidadderespuestaytamaño.

8.1VelocidadderespuestaUnacríticade lasbasesdedatosrelacionalesesqueson lentascomparadasconotrosmétodosylaculparecaesobreelhechodehabersacrificadolafuncionalidadacambiodelageneralizaciónyfacilidaddeusodelosSGBDR.Éstopuedeserciertoono,perosíestáclaroqueparalosdiseñadoresdegrandesbasesdedatos(yalgunasbasesdedatosSIG songrandes) esunagranpreocupacióndurante elprocesodeldiseñoasegurarse



quelosSGBDRfuncionanconlamayorrapidezposible,porloquesehandesarrolladounaseriedetécnicasdemejoradelavelocidad:

a) Índicesb) Seleccióndeclavesc) Divisióndetablasd) Agrupacióndetablas(Desnormalización)e) OptimizaciónSQL

a)ÍndicesLosíndicessonelmétodoporexcelenciaqueutilizanlosdiseñadoresquetrabajanconSGBDR para obtener tiempos de respuesta adecuados. En realidad, sin los Índices elMétodoRelacionalnoseríaoperativo.Los índices son tan importantesenSGBDRquemerecenquelesdediquemosnuestraatención.El concepto de un índice nos resultamuy familiar: usamos índices en los libros paraencontrarlaspáginasquecontienenlainformaciónquequeremos,yusamoslosíndicesdelasbibliotecasparalocalizarloslibrosquequeremos.Piensaenlolentoqueseríaelproceso de encontrar un libro en una biblioteca si no pudieras usar el sistema deíndices.Tendríasquerecorrersecuencialmentetodoslosestantesdelabibliotecahastadarconellibroquequerías.Podemosintuirquelosíndicesenlossistemasinformáticosde bases de datos sirven para elmismo propósito que los índices en los libros o lasbibliotecas.Existenparaahorrartiempo.En lamayoríadeSGBDRse implementafísicamenteunatabla“base”comounarchivoadicional.Estatabla“base”seactualizaconcadaactualizacióndelabasededatos.SinohubieraíndicesyunusuariopidieraalSGBDquerecuperaraunafiladedatos,elsistemadebería leersecuencialmenteelarchivohasta llegara la localizaciónfísicadelregistroqueguardalafiladedatos.Sielarchivodeesteejemplotuvieravariosmilesderegistrosyelregistroobjetode labúsquedaestuvierahaciael final,habríaunretrasoconsiderableenlarespuesta.Si,encambio,hacemoslaconsultasobreunatributoparael cual se ha creado un índice, el SGBDR podrá ‘buscar’ la localización del registropedidoenelíndiceydirigirsedirectamentealpuntodelarchivodondeseencuentra.Los índices son valiosos para mejorar los tiempos de respuesta cuando los usuariosquierenextraerinformacióndeunaúnicatabla,perosonesencialesparaoperacionesquerequierenextraerinformacióndedosomástablas.Talcomovimosenlatécnicadenormalización,esprobablequeunmodelodedatoscorrectamentediseñadoparaunaBD relacional esté formado por muchas tablas, y en consecuencia muchas de lasconsultas que se le pueden hacer requerirán que las tablas estén enlazadastemporalmente.Desarrollarestasoperacionesdeuniónsiníndicesseríaterriblementelento.



Imagina,porejemplo,queennuestrabasededatosde laUDEquisiéramossaberquéfábricashacen‘tornillos’.Paraconseguirésto,siníndices,elSGBDRdebería:a) buscar secuencialmente en la tabla de Productos hasta que encuentre el producto‘tornillos’ en la columna DescripcionProducto y reconozca el número deCodigoProductoparatornillos.

b)buscarsecuencialmenteenlatablaHechoPor,identificandoelFabricaIddecualquierfilaquecontengaelvalordeCodigoProductodelostornillos.

c)buscarsecuencialmentelatabladeFabricaparaescogerlosnombresdecadafábricaconunodelosFabricaIdidentificados.

Inclusoconunabasededatospequeña,estaseríauna tareaextremadamente tediosa.Tansoloconíndicesdeclaradosenlacolumnadelosatributosclavesepuedenllevaracaboconéxitopreguntasdeestetipo.Los paquetes SGBDR implementan índices de formas diferentes, pero en términosgeneralesuníndiceconsistefísicamenteenunarchivocondoscolumnas.Unacolumnacontiene los valores del atributo usado para construir el índice. La segunda columnacontiene los números de registro que señalan la posición física de los registros en elarchivodelatabla.Deestaforma,paraextraerunafiladeinformacióndeunatablautilizandounatributoindexado,unSGBDRseguiríalossiguientespasos:

1.buscaríaenelarchivodeíndiceelvalordeatributoespecificado2.leeríaelvalordelnúmeroderegistrodelregistrodeseado3.accederíadirectamentealregistrodeseadodesdeelarchivodetabla.

LaFigura8.1ilustraesteprocesoutilizandolaestructuradelabasededatosdelaUDE.Sehacreadouníndice, llamadoNumFabrDx,enelatributoNombreFabricadelatablaFabrica.LosregistrosenlatablaFabricaestánenelordenenqueseentraron,deformaque‘Buts’fueelprimerregistrocreadoy‘Zees’elúltimo.ObtenerdetallesdelafábricaACECO sin un índice requeriría leer 20001 registros antes de encontrar el registroadecuado. Sin embargo, utilizando el índice el SGBDR puede escanear el archivo deíndice,detectarqueACECOeselregistro20002eirdirectamenteallí.



NumFabrDxClaveÍndice

Registro#

ACECOBEANSLtdBUTTSVANESWATESZEES

200024122000020003

Registro#123420000200012000220003

FabricaFabricaId Nombre

FabricaEtc.

BUITSVANESCAROL.LtdWATESJYMMYSACECOZEES

Fig.8.1:IndicedeNombreFabricaenFABRICA.Fuente:StamperyPrice(1990)Los índicespuedensercreadosenordenascendenteodescendentede laclave índice,siendoNumFabrDxenordenalfabéticoascendente.Tambiénpuedendeclararsecomoúnicosonoúnicos, siendoelprimeroelquenoaceptaentradasdoblesenelatributosobreelcualsehacreadoelíndice.Si los índicessontanvaliosospara incrementar lavelocidaddeconsulta,¿porqué losdiseñadoresnoconstruyeníndicesparatodoslosatributos?Haydosrespuestasaésto.Primero, los archivos de índices, aunque pequeños comparados con los archivos detablas convencionales, consumen espacio. Segundo, aunque los índices aceleransignificativamente las operaciones de consulta, frenan las operaciones de inserción yborrado.Cadavezqueseinsertaosesuprimeunregistrodeunatabla,cualquieríndicerelacionado conelladebe ser actualizado. Lasoperacionesde inserciónen tablasquetieneníndicesúnicospuedenserespecialmentelentas,yaqueparacadanuevoregistroel SGBDR debe comprobar, antes de poder aceptar el registro, que la condición deexclusividadnohasidovioladaparaelatributo.Por lotanto, ladecisióndedóndecolocar índicesrequiereunequilibrio,porpartedeldiseñador, entre las demandas en conflicto. Afortunadamente, existen algunas reglasbastanteclarasquepuedenusarsecomoguía:

- laclaveprimariadecualquiertablasiempredeberíaestarindexadadeformaúnica

- todaslasclavesexternasdeberíanserindexadas,yaquesonlosatributosque

seusanparaunirtablas

- unatributoqueseusefrecuentementeparaaccederaunatabladeberíaserindexado,aunquepuedequenoseauncampoclave.Porejemplo,enelcasodelaUDE,elnombredelafábricanoesuncampoclaveenlatabladeFabrica,pero es probable que muchas consultas estén basadas en el nombre de lafábrica, como por ejemplo: ¿‘Qué produce la fábrica X’?, o ¿Quién es elpropietario de la fábrica X?. Un índice sobre un atributo que no sea clave



primarianiexterna,yqueseausadoparaaccederdirectamentealatabla,esconocidocomoíndicesecundario.

Comoyaapuntábamosanteriormente,unabasededatosgeográficapuedellegaratenerun tamaño muy grande y realizar según qué operaciones geométricas sin un índicecreadosobrelageometríapuederesultarextremadamentelento.Además,lasoperacionessobrecamposalfanuméricosacostumbranaserrelativamentesimples:compararelvalordeunaceldaconunvalordado,leerelvalor,...Determinarsiun valor es mayor que 1000, para poner un ejemplo, es bastante simple. Por elcontrario,lasoperacionessobrecamposgeométricospuedensermuchomáscomplejas(determinarsiunpuntocaedentrodeunpolígono,cálculodedistancias,...).Repetir una operación de comparación sobre un campo alfanumérico 10millones devecesrequieretiempo,perohacerlomismosobreuncampogeométricorequeriráaúnmuchomás.Porejemplo,recientementerecibimosunacapacartográficaqueconsistíaenunamalladepuntosespaciadoscada30metrosparatodaCataluña.Dichospuntostansólotenían3campos:Identificador,GeometríayAltitud.Altenerunpuntocada30metros,latablaconteníaalrededordeunos38millonesderegistros.Dadounpuntoaleatorioenelterrenoejecutamosunaconsultacontralabasededatosparaobtener los4puntosde lamallamáscercanosanuestropunto.Sinelusodeuníndiceimplicaría:

1. Calcularladistanciaentreelpuntodadoycadaunodelos38millonesdepuntos.2. Ordenarascendentementelatabladeacuerdoconladistanciacalculada.3. Mostrarlos4primerosregistros.

EsteprocesoenPostGIStardóalrededordeunos2minutos(113,891milisegundos).Si,porelcontrario,creamosun índicesobreelcampogeometría,elprocesoquedebeseguirelsistemaes:

1. Buscarenlatablaíndicecuálessonlasposiciones(enlatablaquealbergalos38millonesdepuntos)de los registros (puntos)queestángeográficamente cercadenuestropunto.

2. Calcular ladistanciaentre lospuntosencontradosa travésdel índiceynuestropunto.

3. Ordenarascendentementelosresultadossegúnladistancia.4. Mostrarlos4primerosregistros.

Observaqueelpaso1 limita(y lohaceenormemente)elnúmerodepuntossobre loscuales vamos a tener que calcular las distancias. Este proceso en PostGIS tardóexactamente31milisegundos.Enestecaso, lamismaconsultaconíndiceesalrededorde3600vecesmásrápidaquelamismaconsultasiníndice.



Unúltimopuntosobrelosíndices.AunqueeldiseñadordeBDpuedeespecificardóndesecrearánlosíndices,elsoftwaredeterminaráporsímismocuándousarlos.TodoslospaquetesSGBDRtienenrutinasdeoptimizacióndelasconsultasquedeterminancómoejecutarmejoruncomando.Enlíneaconelprincipiodelaindependenciadelosdatos,losusuariosnonecesitanconocerlaexistenciadelosíndices.b)SeleccióndeclavesEn lecciones anteriores mencionamos que cualquier tabla puede tener varias clavescandidatasde las cualesdebemos seleccionaruna claveprimaria.La seleccióndeunaclave primaria debería basarse en consideraciones de eficiencia. Generalmente, lascaracterísticasqueharándeunatributounaclaveeficienteson:

‐unaclavecortaesmásatractivaqueunalarga(osea,1mejorque10000000),yaquereduciráel tamañodelarchivo índiceyademás facilitaráelaccesodelSGBDR.

‐ las clavesnuméricas sonpreferibles a las alfanuméricas, porque losnúmerosocupanmenosespacioqueloscaracteresalfanuméricos.

‐ Es recomendable que el atributo claveno sea volátil; cada vez queuna claveprimariasecambia,significaqueelSGBDRtendráquecambiarnosólounvaloren una tabla, sino en todas las otras tablas que usan la clave primaria comoclaveexterna.Éstoesunejemplodel‘efectocascada’.

Podemos argumentarque elmejor camino esutilizar clavesprimariasqueno tengansignificado (normalmente una secuencia única denúmeros), ya quede esta formanohabrá incentivos para actualizarlas. En realidad, muchos SGBDR proporcionanherramientas de autonumeración para generar claves primarias ideales. En resumen,cortas,numéricas,sinsignificadoyporellopermanentes. Vale la pena repetirloen letra grande y negrita: ‘Las claves primarias deberían ser CORTAS, NUMÉRICAS, SIN SIGNIFICADO Y PERMANENTES’

c)DivisióndetablasLosSGBDRprocesanmejorlastablaspequeñasquelasgrandes.Siobservasquedentrodeunamismatablatususuarios/asutilizanunconjuntodeatributosmásamenudoqueel resto, podrías considerar dividir esta tabla en dos. Hay que separar los atributosconsultadosasiduamentedelosqueraravezseutilizanyestablecerunarelaciónuno‐a‐unoentrelasdostablas.Sifueranecesario,podríarecuperarselainformacióncompleta



de la tabla inicial con una operación de unión.De esta forma, las consultas sobre losatributosusadosfrecuentementeiríanmásrápidoenestanuevatablamás‘pequeña’yde‘usofrecuente’.d)Agrupacióndetablas(Desnormalización)Paradójicamente,enalgunascircunstancias,enlugardedividirlastablasparaobtenerrapidez, podemos agruparlas para ganarla. Si encuentras que los usuarios/as hacenconsultasfrecuentesquecombinanatributosconcretosdetablasseparadas,puedeserventajoso combinar tablas para evitar tener que hacer operaciones de uniónrepetidamente. Por ejemplo, si en la base de datos de la UDE encontramos que elnombredelresponsabledeáreaseusacasisiempreasociadoconlosdetallessobrelasfábricas,podríaseraconsejablerecombinarAREAconFABRICAparaevitaroperacionesinnecesariasdeunión.Debe quedar claro que si recombinas tablas, que por otro lado las técnicas denormalizaciónindicanquedebenestarseparadas,estarásDesnormalizandotubasededatos.Ypuedesempezaraexperimentarlasanomalíasdeactualizar,insertarysuprimircomentadasen laterceraformanormal.Tambiénaumentarásel tamañode labasededatosalpermitir laduplicacióndedatos.DesnormalizarunaBDesunpasoquedebetomarse sólo después de haberlo considerado con calma (y probablemente haberlopensadodosoinclusomásveces).e)OptimizacióndesentenciasSQLComosehaexplicado,parausarSOLelusuariosólodebecrearunasentencia/expresiónlógicayelsoftwaredebasededatosgeneralarespuesta.Sinembargo,losexpertosenSQL (particularmente en el uso de SQL con software específicos) creen que puedenmejorarelrendimientoespecificandosentenciasSQLdeuna formadeterminada.Parahacerésto,esnecesariounconocimientodetalladodelosprocesosinternosdelSGBDR,conocimientoque lamayoríade losusuariosnoposee.Paraoperaciones importantes,losprofesionalesdelasbasesdedatosanalizaránquéformadesentenciaSQLalcanzaráuntiempoderespuestaóptimo.

8.2DefinireltamañodeunabasededatosEstáclaroqueunadelasmayorespreocupacionesdeldiseñofísicoesdeterminarquétamaño final puede alcanzar la base de datos y así saber qué capacidad dealmacenamientoserequerirá.Afortunadamente,eltamañodeunaBDpuedeestimarsedeformaaproximadaconunprocedimientosencillo:

- Calcular el tamaño de cada tabla: La longitud de cada fila de datos puededeterminarsefácilmenteagregandoelnúmerodebytes(caracteres)quesehanpermitidoparacadaatributoydespuésmultiplicandodichacifraporelnúmeroderegistrosenlatabla.



- Calcular archivos índice: El tamaño real de cada archivo de índice variará

dependiendodelmétododeindexaciónusadoydelalongituddelatributoclave.Comoreglageneral, sinembargo,puedescalcularquecada índiceenuna tablaseráun20%delatabla.

- Sumadetablasmásprevisióndecrecimiento:EltamañototaldelaBDserá

la suma de todas las tablas y los archivos de índice. Después, es prudentepermitiralmenosotro20%paraexpansionesfuturas.


Eldiseñofísicoseocupadeestablecerunabasededatosbajounasconsideraciones

desoftwareyhardwareespecíficas.Eldiseñofísicopuederequerirelcompromisodelosmodelosconceptuales

LosíndicessonesencialesparaelcorrectofuncionamientodelSGBDR,perohayque

sercautoconsudefinición

Otros métodos para mejorar la velocidad de respuesta incluyen la correctaseleccióndeclaves,ladivisióndetablasyladesnormalización

Las mejores claves primarias acostumbran a ser CORTAS, NUMÉRICAS, SIN

SIGNIFICADOYPERMANENTES



Lección9–LenguajedeConsultaEstructurado(SQL)El álgebra y el cálculo relacional son parte del Modelo Relacional y los teóricos losutilizan para determinar qué es posible hacer dentro del modelo. Sin embargo, losusuariosnotienenporquésabermanipularelálgebrarelacionaldirectamenteyaquetodos los SGBDR deberían contener uno o dos lenguajes prácticos que, aunque sederivandelálgebraoelcálculo,sepresentanalusuariodeunmodoconvenienteparagestionarsubasededatos.ElStructuredQueryLanguage(SQL)oLenguajedeConsultaEstructuradoeselmáspopularyelquevamosautilizaren losejerciciosprácticosdeestemódulo.Estrictamente, SQL no forma parte del modelo relacional teórico, que consistesimplemente en los elementos Estructurales, de Manipulación e Integridad descritosanteriormente. Sin embargo, SQL ha devenido tan ampliamente implementado en losSGBDRquecreemosapropiadoyconvenientetratarloaquí.Comolenguajedebasesdedatos,SQLtieneundeterminadonúmerodeventajasquelehallevadoasuactualpopularidad:

Completo: El SQL contiene instrucciones que implementan la mayoría de losrequerimientosdeintegridad,manipulaciónyestructuradelModeloRelacional.Así, ofrece un lenguaje de base de datos completo que permite crear, usar yborrar bases de datos. Mientras que con otros sistemas podría ser necesario



aprenderdiferentesconjuntosdecomandosparaestablecerunabasededatosydespuésusarla,conelSQLtenemosunaseriecompletadeherramientasdebasededatosenunformatoconsistente.EnlajergadelmodelosedicequeelSQLesunlenguaje‘relacionalmentecompleto’.

Simplicidad:Apesardesunaturalezacompleta,haymenosdetreintacomandos

SQL, lo que hace que aprender este lenguaje no sea una tarea tan ardua. Losnuevos usuarios pueden adquirir rápidamente los conocimientos suficientespara ser capaces de llevar a cabo la mayoría de las operaciones. Al mismotiempo, la flexibilidad del SQL permite a los usuarios experimentados realizaroperacionescomplejas.

Declarativo:El SQL es unlenguajedeclarativo en el sentido que las sentencias

SQL dicen al ordenador lo que se le pide, pero le dan completa libertad paradeterminarlamaneradeconseguirelresultado.Éstocontrastaconlosmétodosdebajoniveldeloslenguajesdetercerageneración,comoelCOBOL,queprecisanqueelusuario sea capazdeescribirunprogramaparaexplicarlealordenadorqué debe hacer (¡y cómo!) para extraer la información. Mientras que loslenguajes de tercera generación tienden a operar registro a registro, lassentencias SQL, como el álgebra relacional, operan sobre un conjunto deregistros. Los inputs de las sentencias SQL son conjuntos de registros (ycondiciones lógicas que debe cumplir cada fila) y los outputs son nuevosconjuntosderegistros.Laventajadeestemétodoesqueelusuariononecesitaserprogramador.ParautilizarelSQL,losusuariosnecesitanconocerlamaneradeformularlapregunta:elsoftwaredeterminaelmecanismomedianteelqueencontrarálarespuesta.Codd contempla ésto como uno de los beneficios principales del métodorelacional. En los años setenta, la necesidad de emplear programasespecializados para operar sobre bases de datos existentes estaba causandoseriasdificultades.CoddinterpretólafacilidaddeusodelSQLyotroslenguajesrelacionalescomounaumentode laproductividadde losprofesionalesycomounaayudaparalosusuarios.

EstructuradeComandos‘PseudoInglesa’:UnprimerprototipodelSQLfueel

‘StructuredEnglishQueryLanguage’(SEQUEL)queintrodujoIBMen1974,porloque el SQL aún conserva una sintaxis similar al idioma inglés. Todas lassentencias SQL pueden verse como frases en inglés muy restringidas yestructuradas.LoscomandosSQLsiempreempiezanconunverboqueespecificala acción que debe realizar el software (Create,Select,Grant,Drop, Insert, ...) ysiemprehayunobjetoqueeselsujetodelaacción(normalmenteunatabla).

Ampliamente utilizado: El SQL se ha convertido en un lenguaje de base de

datos ampliamente utilizado. Los SGBDR de los grandes ordenadores(mainframe)hanutilizadoelSQLdurantemuchosañosy,cadavezmás,seestáincorporandoenpaquetesSGBDparamicroordenadores.InclusolosSGBDRparaMS Windows, como MS Access, que presentan una interfaz gráfica bastante



agradable para el usuario, utilizan normalmente el SQL. La mayoría de lospaquetesSIG, incluso losdestinadosausuariosnoespecialistasasumenquesetieneciertafamiliaridadconelSQL.ElconocimientosobreSQLes,simplemente,esencialparacualquieraquedeseeutilizarlossistemasdeinformaciónmásalládelnivelbásico.

Además de lo ya señalado, hoy en día existen varios intentos para producir un SQLgeográfico, mediante el cual el usuario podría llegar a realizar cualquiera de lasconsultasgeográficastípicascontansoloescribiruna‘pequeña’fraseenpseudo‐inglés.ProductostalescomoelArcSDEdeESRI,OracleSpatialoPostGISofreceneste tipodelenguaje.AdemásdeutilizarseenpaquetesSGBDRindividuales,elSQLtambiénseutilizabacomomecanismopara transferir la informacióndeunabasededatosaotraensistemasenred.Supónquehaydiferentesusuariosquequierenaccederaunaseriededatoscomún,pero que cada uno de ellos quiere utilizar en su PC su paquete de base de datospreferido.Unasoluciónaesteproblemaconsisteenalmacenarlosdatosenunservidorde red utilizando un gestor de bases de datos que se base totalmente en SQL. Elsoftwaredebasededatosdelusuario,noimportacuál,puedeentoncesutilizarSQLparaextraer los datos del servidor ymodificarlos para convertirlos a un formato familiarpara el usuario. Los usuarios no necesitan ser conscientes que ambos paquetes hanutilizadoSQLparatransferirlosdatosrequeridos.ElestándarODBC(OpenDatabaseConnectivity)deMicrosoftesunejemploconocidodeestemétodo. Los SGBDRpara los que están disponibles losdriversdel ODBC puedenintercambiardatosenbaseasentenciasSQL.Deformasimilar, IBMofreceunservicioSQLcomoparteintegrantedesusistemaoperativoOS2.Aunque se supone que el SQL es un lenguaje estándar, su implementación difiereligeramente de software a software. Como con otros lenguajes, los vendedores desoftwarenohansidocapacesderesistirsealatentacióndeañadirsuspropioscódigosyavecesomitencódigosSQLestándar,yaexistentes.Estasdiferenciasacostumbranasermínimas, por lo que los conocimientos sobre SQL adquiridos con un sistemadeterminado sonválidospara cualquier otro sistema. ¡Nohayque empezardenuevocuandocambiamosdeunsistemaaotro!En las prácticas de este módulo nos centraremos en la implementación del SQL enPostgreSQLy tendremos laoportunidaddedesarrollarnuestrahabilidadparautilizarSQLatravésdeunaseriedeejerciciosprácticos.TambiéntendremoslaoportunidaddepracticarconlasconsultasgeográficasmedianteSQL.Loquesigueahora,sinembargo,esunadescripcióndelassentenciasSQL,independientesdecualquierimplementaciónparticular, para ofrecerte una pequeña muestra de la apariencia y método defuncionamientodelSQL.



9.1ComandosSQLdedefinicióndebasesdedatosComoseexplicóenleccionesanteriores,cualquiersoftwareSGBDnecesitaunLenguajedeDefinicióndeDatos(DataDefinitionLanguage)quepermitaalusuarioproyectarunmodelodebasededatosconceptualentérminoscomprensiblesparaelSGBD.El SQL ofrece cinco comandos que permiten al usuario emprender las tareas dedefinicióndelabasededatos:

CREATE TABLE ALTER TABLE CREATE VIEW CREATE INDEX DROP TABLE/VIEW/INDEX

CREATETABLEEl comando createtablepermite crear unanueva tabla y especificar los tipos de datosquecontendrácadacolumna.Lasintaxisdelcomandoes:

CREATE TABLE <nombre_tabla> ( <nombre_columna><tipo_de_dato> [NOT NULL] [, <nombre_columna><tipo_de_dato> [NOT NULL]...]);

Para describir la sintaxis de los comandos SQL hemos optado por las siguientesconvenciones:

Los comandos y palabras clave se muestran en MAYÚSCULAS. Los comandos,además,aparecenennegrita.

<>(menorqueymayorque)significaquedebemosincluirelelementoqueestá

dentro de estos dos símbolos. Así, en el ejemplo anterior debe haber,obligatoriamente, un nombre de tabla directamente después del comando y,además,tambiéndebehaberalmenosunacolumnadefinidaenlatabla.

[ ] (Corchetes) indican que puede (o no) haber información dentro de los

corchetes,esdecir,loscorchetesencierranpartesopcionalesdelcomando.Enelejemplo anterior, vemos que la palabra clave NOT NULL es opcional y que ladescripcióndelasegundacolumna(peronolaprimera)esopcional.

... (puntossuspensivos) indicanqueestapartedelcomandopuedeserrepetida

tantas veces como sea necesario. En el ejemplo anterior vemos que ladescripcióndecolumnapuedeserrepetidatantasvecescomoqueramos.



Fíjate que las expresiones SQL pueden escribirse en diferentes líneas ya que sólo elpunto y coma final (;) determina el final de la expresión. Los/lasusuarios/aspuedenaprovecharse de ésto para facilitar la lectura del comando en expresiones SQLcomplejas.ElsiguienteejemploilustrarálautilizacióndelcomandoCreateTable.ParacrearlatablaPROPIEDAD,utilizaríamoselsiguientecomando:

CREATE TABLE Propiedad (NumId integer NOT NULL, Ocupante char(20), Direccion char(30), Valor decimal(10.2));

FíjatequehemosutilizadolapalabraclaveNOTNULLparainsistirenquecadaregistroentradoenlatabladebetener,obligatoriamente,unvalorNúmId,locualescovenienteenlasclavesprimariasCREATETABLEcrea lacabecerade la tabla,esdecir,unatablavacíaen laquesehandefinidoloscamposyenlaqueluegopodremosimportarlosdatos.

ALTERTABLEAmenudoocurrequelaestructuradeunabasededatostienequeserrevisadadespuésdeutilizarseduranteuntiempo,seaparaarreglarundeteriorodeldiseñoactualoparaadaptarlabasededatosalasnuevasnecesidades.Fíjate,porejemplo,queenelejemploanteriorhemosolvidadoincluirelcampoNumArea.ALTERTABLEpermitealosdiseñadoresañadircolumnasextraaunatablay/oborraruna/syaexistente/s.LasintaxisdeALTERTABLEes:

ALTER TABLE <nombre_tabla> ADD ( <nombre_columna><tipo_de_dato> [NOT NULL] [, <nombre_columna><tipo_de_dato> [NOT NULL]...] );

ParaañadirNumAreaaPropiedad:

ALTER TABLE Propiedad ADD (NumAreainteger);

ALTER TABLE puede utilizarse sobre tablas que ya tienen datos. El efecto de estecomandoesanálogoatrazarunanuevacolumnaenlastablasenpapel.



ALTERTABLE tambiénpuedeutilizarseparaborrar columnasdeuna tabla, siendo lasintaxisnecesaria:

ALTER TABLE<nombre_tabla> DROP (<nombre_columna>[, <nombre_columna>...]);

CREATEVIEWSupónqueunusuariosiemprequiereverelnombredeláreaenlaqueseencuentralapropiedad,peroquenoestá interesadoen losaspectos financierosde lagestiónde lapropiedad (Evidentemente, los aspectos financieros pueden ser confidenciales y noestar disponibles para este usuario). El comando CREATE VIEW puede ser utilizadoparacrearunatablavistaapropiadaparalasnecesidadesdelusuario.LasintaxisdeCREATEVIEWes:

CREATE VIEW <nombre_vista> [(lista_columnas_vista)] AS <SELECT comando >;

Paracrearelejemplocitado,eldiseñadordeberíaescribirlalíneasiguiente:

CREATE VIEW PropA (Area,CodigoPostal,Ocupante,Direccion)

AS SELECT

Area.Nombre,Area.CodigoPostal,Propiedad.Nombre,Propieda d.Direccion

FROM Propiedad,Area WHERE Propiedad.NumArea = Area.NumArea;

Fíjate que en la tabla Propiedad hay una columna llamada Nombre (nombre delocupante) y que en la tabla Area también hay un campo con ese título (nombre delárea),porloqueincluirambascolumnas,sinalterarlas,causaríaproblemasenlavistadel Usuario A. Con el comando CREATE VIEW podemos utilizar la cláusulalista_columnas_vistaparaindicarlosencabezadosdelascolumnasqueutilizarálavista.La columna nombre, de la tabla Area, se conocerá como Area en la vista PropA y lacolumnanombreenlatablaPropiedadserálacolumnaOcupanteenlavistaPropA.ElfragmentoSELECT...FROM...WHEREdeladeclaraciónCREATEVIEWesuncomandoSQLdemanipulacióndedatos,quecomentaremosmásadelante.Porahoraessuficienterecordar que el efecto de SELECT consiste en poblar la vista con las filas de datosapropiadasextraídasdelastablasbasePropiedadyArea.Las vistas sondinámicas en el sentidoque los cambios realizados en la tablabase sereflejaránenlasvistasqueobtienenlainformacióndeesatabla.Ennuestroejemplo,si



cambiamoselnombredeunocupanteenlacolumnaNombredelatablaPropiedad,elcambioapareceráinmediatamenteenlacolumnaOcupantedelavistaPropA.EnelModeloRelacionalteóricotambiéndeberíanserposibles(exceptoenelcasoquenotengasentidopermitirlo)loscambiosenladirecciónopuesta,esdecirpermitirquelos cambios realizados sobre la vista se actualicen en la tabla base. La posibilidad deactualizarlatablabaseapartirdelavista,sinembargo,cambiaconsiderablementeencadasoftware.AlgunosSGBDRsólopermitenactualizarmediantevistasde‘tablaúnica’,vistas que obtienen la información de una única tabla. Las vistas creadas porcombinacióndedatosprocedentesdemásdeunatablaestándisponiblessólopara laconsultadedatos.ÉstocontradicealmodelodeCodd.

CREATEINDEXComoyadecíamos en lecciones anteriores, un index (índice) es unpequeño archivoque mantiene una relación de la posición de las filas de una tabla y que permite alSGBDRirdirectamentealafilasolicitada,enlugardetenerqueleersecuencialmentelatablahastaencontrarelvalor.Los índicessonparticularmente importantesenunsoftwaredebasededatos,yaquesinelloseltiempoderespuestaseríaintolerablementelargo.Porotrolado,establecerymantener índices hace incrementar el ‘peso’ de la base de datos, por lo que decidircuándodebemosutilizaríndicesesunaparteimportantedelaoptimizacióndelabasededatos.Lasintaxises:

CREATE INDEX [UNIQUE] <nombre_indice> ON <nombre_tabla> (<nombre_columna> [DESC] [,<nombre_columna> [DESC]]...);

Es habitual crear un índice para, almenos, la claveprimaria de cada tabla y para lasclaves externas. En nuestro ejemplo de la tabla Propiedad utilizaríamos la siguienteexpresiónparacrearuníndiceenlacolumnaNumId:

CREATE INDEX UNIQUE IdIndc ON Propiedad (NumId);

Este comando crearáun índice en la columnaNumIdde la tablaPropiedad.Comonohemos incluido lapalabraclaveopcionalDESC,el índiceestaráporordenascendente.Sinembargo,hemosincluidolapalabraclaveUNIQUE,parainsistirquecadavalordelíndiceesúnico,esdecir,nopuedehaberdosfilasconelmismovalorNumId.Al especificar NOT NULL en el comando CREATE TABLE y utilizar UNIQUE en elcomandoCREATEINDEX,hemosimplementado,para la tablaPropiedad, la integridaddeentidadesrequeridoporelModeloRelacionaldeCodd.Ahoranoseríaposiblequeun



usuario entrara un NumId que duplicase un valor previamente introducido ni entrarunanuevafilasinespecificarunvalorparaelatributoNumId.

DROPTABLEHabrámomentosenquenecesitaremosborrarunatabla,vistaoíndicedeunabasededatos.ElcomandoDROPrealizaestatarea,delasiguientemanera:

DROP TABLE <nombre_tabla>; DROP INDEX <nombre_indice>; DROP VIEW <nombre_vista>;

Porejemplo:

DROP TABLE Propiedad;

borraríatodalatablaPropiedaddelabasededatos,y:

DROP INDEX IdIndc;

borraríaelíndiceIdIndcdelabasededatos.DROP VIEW PropA;

borraríalavistaPropA.

9.2ComandosSQLdeManipulacióndeDatosLos comandosdel LenguajedeDefinicióndeDatos (DDL)permiten crearymanteneruna estructura de base de datos. Los datos pueden ser entrados, actualizados,consultadosyborradosmediantelossiguientescuatrocomandosSQL:

INSERT INTO UPDATE DELETE FROM SELECT

INSERTINTOINSERTINTOpermiteañadirdatosaunatablamediantelasintaxis:

INSERT INTO <nombre_tabla> [<lista_columnas>] VALUES (<lista_valores>);



Supongamosquedeseamos insertarunnuevo registro en la tablaPropiedad,perodemomentoaúnnosabemossuvaloroelnombredesuocupante.

INSERT INTO Propiedad (Direccion, NumId)

VALUES (‘Av. Amazonas, 6’);

insertaría el nuevo registro en la tabla. Fíjate que si hubiéramos sabido el valor y elnombre de los/as ocupantes (o sea, que deseáramos introducir una fila completa dedatos)podríamoshaberomitidolacláusulalista_columnasydarlosdatosenelordenespecificadocuandocreamoslatablamedianteCREATETABLE.LautilizacióndeINSERTINTOpuedeserextremadamentetediosacuandotratamosconseriesdedatosmuygrandes,por loque lamayoríade losSGBDR tienenunautilidadquepermite leer los datos de una tabla desde archivos externos. La sintaxis de estoscomandosvariadepaqueteenpaquete.

UPDATEMientrasqueINSERTINTOcreaunanuevafiladedatos,UPDATEtansóloalteralasfilasyaexistentes.Lasintaxises:

UPDATE <nombre_tabla> SET <nombre_columna> = <expresión> [,<nombre_columna> = <expresión>]... [WHERE <condición>];

Así,sisabemoselvalordelapropiedad13yqueJaimeeslapersonaqueviveallí:

UPDATE Propiedad SET Nombre = ‘Jaime’, Valor = 50000 WHERE NúmId = 13;

Actualizarálabasededatosconvenientemente.

DELETEFROMParaborrarunafila(ovarias)deunatablautilizaremoselcomandoDELETEFROM.Lasintaxises:

DELETE FROM <nombre_tabla> [WHERE <condicion>];



Porejemplo,silapropiedad5hasidodestruida:

DELETE FROM Propiedad WHERE NumId = 5;

FíjatequeaunqueesteejemplodeutilizacióndelcomandoDELETEsóloconsideraunafila,estecomandopuedeutilizarseparallevaracabooperacionesmúltiplesdeborrado.Entonces,siqueremosborrartodaslaspropiedadesconunvalormenorde30.000:

DELETE FROM Propiedad WHERE Valor< 30000;

SELECTSELECT es el comandoqueutilizan los usuariosmás frecuentemente, ya quepermiteconsultar la base de datos y esa es la operación realizada con mayor frecuencia encualquierbasededatos.LasconsultasconSELECTpuedensermuycomplejas,puestoquehayungrannúmerodepalabrasclavey funcionesquepuedenutilizarseconestecomando.Aquísóloexaminaremosunospocosparaquetehagasunaideadesuuso.Lasintaxises:

SELECT <lista_columnas> FROM <lista_tablas> [WHERE condiciones_busqueda];

El resultadodeesta sentencia SELECTesunanueva tablaque contiene losdatosquecoincidenconlacondiciónespecificadaenlasentencia.Latablaresultadoestransitoria(sóloexisteenlapantalla)amenosqueseespecifiquelocontrario.LasentenciaSELECTmássimpledetodases:

SELECT * FROM Propiedad; ÉstocreaunalistadetodalatablaPropiedad.EnSQL,elasterisco(*)significa,comoenelDOS(DiskOperatingSystem),‘todos’.

SELECT Nombre, Direccion FROM Propiedad;

crearíaunlistadoconsólolascolumnasNombreyDirecciondelatablaPropiedad.ÉsteeselequivalenteenSQLdeunaoperaciónPROJECTdelálgebrarelacional.

SELECT * FROM Propiedad WHERE Valor> 40000; EstaexpresiónproduciríaunatablaconsóloesasfilascuyoValoresmayorque40.000.ÉsteeselequivalentedeunaoperaciónSELECTdelálgebrarelacional(verFigura9.1a).



ComovimosenelmomentodetratarelcomandoCREATEVIEW,esposibleanidaruncomando SQL dentro de otro. Ésto se hace amenudo con la sentencia SELECT. Parasaber,porejemplo,quiénviveenunacasaquecuestamásqueladeJaime:

SELECT Nombre FROM Propiedad

WHERE Valor > (SELECT Valor FROM Propiedad WHERE Nombre = `Jaime´);

produciríalarespuestaquesemuestraenlaFigura9.1b.BasedeDatos

PROPIEDAD NumId Nombre Direccion Valor NumArea 1 Jorge C/ Chamartín 30000 1 2 Marcos C/ Fuentes 60000 Nulo 3 Irene Parque la Paz 28000 2 4 Javier Av. F. Lorca 55000 1 5 Marta Plaza de Mayo 25000 2 6 Jaime Av. Girona 50000 Nulo 7 Pedro Av. Girona 50000 Nulo

AREA

NúmAreaCod. Postal Nombre 1 17003 Centro Ciudad 2 17007 Barrio San José

Fig.9.1:OperacionesSELECTenSQLa)OperacionesSELECTSELECT * FROM Propiedad WHERE Valor > 40000;

NumId Nombre Direccion Valor NumArea 2 Marcos C/ Fuentes 60000 Nulo 4 Javier Av. F. Lorca 55000 1 6 Jaime Av. Girona 50000 Nulo 7 Pedro Av. Girona 50000 Nulo



b)SELECT Nombre

FROM Propiedad WHERE Valor > (SELECT Valor FROM Propiedad WHERE Nombre = `Jaime´);

Nombre Marcos Javier

c)SELECT NúmId

FROM Propiedad, Area WHERE Area.Nombre = ‘Barrio San José’ AND Area.NumArea = Propiedad.NumArea AND Valor< 30000;

NúmId35

Tambiénesposible crear consultasqueobtienen informacióndemásdeuna tabla (ovista).ParaproducirunatablaqueidentifiquecualquiercasaeneláreaBarrioSanJosécon un valor inferior a 30.000, por ejemplo, es necesario extraer datos de las tablasPropiedadyArea.Lasiguienteexpresión:

SELECT NumId FROM Propiedad, Area WHERE Area.Nombre = ‘Barrio San José’ AND Area.NumArea = Propiedad.NumArea AND Valor< 30000;

ProduciríaunalistadelosNumIddelaspropiedadesquecumplenconnuestrapregunta(verFigura9.1c).Es posible utilizar otras palabras clave como ‘ORDER BY’, ‘DISTINCT’, ’HAVING’ y‘GROUPBY’paracontrolarelformatodelosresultadosdelcomandoSELECT,peroéstassedetallanenelcasoprácticoqueacompañaaestaunidaddidáctica.LaformacomosevayanconstruyendolassentenciasSELECT,dependerádelgradodeconocimientoyexperienciaensuuso,estoindicaquesedeberáejercitarsuutilizacióncon las mayores combinaciones posibles, ya que la solución a las consultas por logeneralnosonunasola,porlotantoesrecomendablelograrunamayordestrezaensuuso.MuchossoftwareSIG,contemplanensuestructuraunaposibilidadderealizarconsultasalabasededatos,enalgunoscasosestasseencuentranyaestructuradasdeunaforma



másnaturalqueel lenguaje SQL, y enalgunos casosde formagráfica, sin ambargoellograr un entendimiento de este lenguaje, permitirá a la hora de realizar consultasestablecer esa secuencia lógica que optimizará los resultados, y el estudiante incluospodrá traducir esta estructura en las sentencias de consultas SQL lo que indicará unbuenmanejodelasbasesdedatos.En la actualidad existe mucha bibliografía relacionada con el lenguaj SQL, inclusoherramientas de consulta inmediata, que dan la posibilidad de ejercitar en línea lasinstrucciones,einclusoverificarloserrorescometidos.

9.3LenguajedeControldeDatosEn sistemas multiusuario, es necesario un mecanismo para controlar el acceso adeterminadaspartesde labasededatos.Comoyahemosvisto, lasVISTASofrecenunmecanismo que personaliza la apariencia de los datos para excluir determinadosatributos(columnas).PeronohayquiénevitequeelUsuarioA(quetienelavistaPropAcreadapara él) consulte la tablaPropiedadademásde la vistaPropA. SQLofrecedoscomandosconlosquemantenerlaseguridaddelosdatos:

- GRANT - REVOKE

GRANTLas bases de datos en las que la seguridad es un elemento importante se crean,normalmente, con una restricción sobre todos los usuarios, excepto para los que eladministradorhadadopermisoexplícitamente,mediantelasentenciaGRANTdelSQL.Lasintaxises:

GRANT <lista_privilegios> On<lista_tablas> To<lista_usuarios>;

Entonces,parapermitirqueelUsuarioAvealavistaPropA:

GRANT select on PropA to UsuA;

Permitiría al Usuario A, que responde al nombre de usuario UsuA, ver y seleccionardatosdelatablavistaPropA.

REVOKEElcomandoREVOKEeliminalosprivilegiosdadospreviamente.



Lasintaxises:

REVOKE <lista_privilegios> On<lista_tablas> From<lista_usuarios>;

¿Quéhasaprendidoenestalección? LenguajedeConsultaEstructurado(SQL):

- lenguajedeBDrelacionalesdominante- declarativo- dealtonivel- completo- fácildeusar

lección 5 de bases de datos

Documents