Scribd Logo
Upload

Welcome to Scribd!

  • Date - Fundamentos SBD - Cap 2

    Uploaded by

    Edisson Melo
    19 views22 pages

    Original Title

    Date.Fundamentos SBD.Cap 2

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    19 views22 pages

    Date - Fundamentos SBD - Cap 2

    Uploaded by

    Edisson Melo

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 22
    CAPITULO Arquitectura de los sistemas de bases de datos 21 INTRODUCCION Ahora estamos en condiciones de presenta la arquitectura para un ssema de base de dato. Nues- ‘20 objetivo al presentar esta arquitectura es ofecer una infaesructura en la que puedanbasarse Jos captulos siguientes. Dicha inraestrutura resulta itil para deseibir los conceptos geneales elas bases de datos par explicar la estructura de sistemas de bases de datos expen: pero no afrmarns que tod sistema pueda coined enleramente con esa iffaesrucura en particu- lar, i queemos sugere que eta aruitectura represent le nica infraesiuctura posible. En par ticular, es probabie que ls sistemas "pequetos" (veal capitulo |) no mangjen todos los aspectos e la argaltectura. Sin embargo, la arquiteerura parece ajustarse bastante bien a la masoria de Jos sistemas; es mis, es pricticamente idéntica ala arquiteturapropuesta por el Grupo de Es- tudo en Sistemas de Administracion de Bases de Datos de ANSUSPARC (la tan mencionada arguitectara ANSL'SPARC. Vea las referencias (2.12.2). Sin embargo, nosotros deciimos no ‘Sequir a terminologia ANSUSPARC en todos ss deals, Nota: Este capitulo se asemeja al capitulo | en el sentido de que también es en cierto modo _baracto yard, aunque es fundamental entender el material que conine para una apreciacn ‘completa de la estructura y posibildades de un sistema de base de dalos modem, Por lo tanto, al igual que en el capitulo 1 tl vez prefiera por ahora silo dare wna lida “ger” y egresar ‘lis ade, cuando sea directamente relevante para los temas que estéabordando. 22 LOS TRES NIVELES DE LA ARQUITECTURA [La arquitectura ANSISPARC se divide en tes niveles, eonncdes com intemo, concep y ‘extemo, repectivamente(vea i figura 2.1). Hablando en trminos generates: ‘= El nivel interno (también conocido coma el nivel ic) es el que est ms cerca de a ‘macenamiento fisio: es deci, ese que tiene que ver con la fora en que ls datos estin almacenados fsieamente 1 El nivel externo (también conocido como el nivel ligico de usuario) es el mis promo a los usuarios: es deci, el que tiene que ver con la forma en que los usuarios Individuals ven ls datos, ‘= EL nivel conceptual (tambidn conocido como el nivel ligico de la comunidad. o€n ova ines s6lo como el nivel gio sin calfear) es un nivel de indrecidn entre los ors dos, ‘Observe que el nvel extemo tiene que ver con las pereepsiones de usuarios individuals, rmicrras que el nivel conceptud iene que er con la percepcion de una comunidad de uses, s ” Parte | Preliminares ‘Nivel extemo I (sta do usuario ‘naiules) ‘Nive concoptal {Gia do ia comunidas ‘de usuerce) Nivel intarno (vata do ‘amacenamionts) |__| Figura 21. Los tres niveles dela arquitectura. En otras palabras, habré muchas “vistas externas” dstnts, cada una consistente en una repre- seataci6n ms 0 menos abstracta de alguna parte de a base de datos total, y habréprecsamente tuna “vista conceptual” que del mismo modo consste en una representacign abstracta de Ia base de datos en su totalidad.* (Recuerde que la mayorta de los usuarios nose interesarin a toda la ‘base de datos, sno so en una pat limita dela misma). En forma similar, habréprecisarnente ‘una “vista interna’ que represen a a base de datos tal como estéalmacenada fisicamemt Un ejemplo haré més claras estas ideas. La figura 2.2 muestra la vista conceptual, la vista imema correspondiente y dos de las vistas externas (una para un usuario de PLM y otra para un ‘usuario de COBOL), todas ellas para una base de datos de personal sencilla, Por supuesto, el ‘ejemplo es completamente hipottico —no pretend reflejar ningin sistema real— y hemos omi- tido deliberedamente muchos detalles irelevanes, Explicacin: 1 Enel nivel conceptual, a base de dato contene informacion concerniente aun tipo de ent- dad denominads EMPLEADO. Cada empleado individual tiene un NUMERO_EMPLEADO (de seis caracteres), un NUMERO_DEPARTAMENTO (de cuatro ceractees)y un SALA RIO (de cinco digitos decimales). 1 En l nivel interno, los empleados esti representads por un tipo de registro denominado [EMP_ALMACENADO, de veinte bytes de longitud, EMP_ALMACENADO contiene cu- ‘wo campos almacenados: un prefijo de ses bytes (que presumiblerentccontieneinformacién ‘decontrol como los indicadores ols apuntadores)y ies campos de datos correspondientes alas tres propiedades de los empleados. Adem, os repistrs de EMP_ALMACENADO ‘sn indexados sobre el campo EMP# por medio de un indice de nombre EMPX,cuya defi icin no se muestra. ‘© El usuario de PL tiene una vista extera de la base de datos en la que cada empleado ests ‘epreseniado por un registro PL/I que contiene dos campos (los nimeros de departamento “gut por abwraco simplemente queremos devs que la representacéa en cuestiéncomprende consrac clones come los estos y campos qu stn mds onentadas alos usuarios, a diferencia das oosrcciow ‘ek como ls bts los bytes que esin mals oientadas al miguina. Capitulo 2 1 Arqitectura de os sistemas de bases de datos 88 Figura 22. Un ejemplo de ls tres nivel. ‘no Son de inter para este usuario por lo tanto fueron omitdos). El tipo del registro ests {sarees ‘Scimsoos concep! tne a = Yemiomacon oxtncn cesta ‘ca + esrectea 4 foam [ Sen [RRO PSF ae uu _| Figura 2.3. Arquitecturadetllada del sistema, Capitulo 2 Arquitectura de los sistemas de bases de datos 37 2.3 /EL NIVEL EXTERNO Elnivelextemo esl nivel del usuario individual, Como expliqn en el cptlo 1, un usuario dado ede ser un propramar de aplicacions o bien un usuario final oon susie rad de sofia ‘on, (El DBA es un importante cas especial: peo adiferncia de ors wsros el DBA tambien necesita imeresarse en los niveles conceptual intemo. Vea ls dos secione siguientes) Cada ‘usuario tiene as disposicin un lenguaje: 1 Para el programador de aplicaciones, ésteseréya sea un lenguaie de programacié com vencional (por ejemplo, PL, C=, Java o bien un lengua de tipo propetrio que sa es pecitico al sistema en cuestibn, A menudo, a estos lenguajes de tipo propietaro se les

    You might also like