Está en la página 1de 38
Disefio de vistas El objetivo principal del diseto de vistas es crear un esquema conceptual par tiendo de una descripcién informal de los requerimientos del usuario. Se utiliza el termino vista para referirse a la percepcidn de una base de datos o de los re~ querimientos de datos de una aplicacién, tal como lo ve un usuario 0 un grupo de usuarios, El disefto de vistas abarca, tipicamente, dos actividades distintas: 1) el analisis de los requerimientos, para captar el significado de los objetos de in- terés en la aplicacién, su agrupacién en clases, sus propiedades etc.; 2) la repre- sentacidn de estos abjetos, clases y propiedades, usando los conceptos del mo- delo ER. La primera actividad esta especialmente influida por la naturaleza de los re- querimientos; éstos pueden incluir descripciones en lenguaje natural, formula- rios, formatos de registros y esquemas de datos, que claramente representan una realidad dada de diferentes maneras, Con los requerimientos expresados en len- guaje natural, la estructura de la informacién puede estar oculta en descripcio- ‘nes ambiguas, incompletas o contradictorias, Con representaciones més estrue- turadas, a veces es mas facil deducir la estructura subyacente de la informacion y expresarla en términos de los componentes de un esquema ER; sin embargo, es posible que se omita informacion importante en estas representaciones. En este capitulo, se describe el disetio de vistas para tres tipos distintos de requeri- mientos: lenguaje natural, formularios y declaraciones de registros. Las descripciones en lenguaje natural se hacen normalmente por escrito; asi, se deduce informacién sobre la estructura de la base de datos a partir de un and- lisis textual de los requerimientos, En el apartado 4.1, se presentan sugerencias practicas para analizar y eliminar las ambiguedades de las descripciones textua- Ie, Un formulario es cualquier médulo de papel usado para recolectar datos; en €l caso de sistemas de informacion que ya emplean computadoras, se puede usar también descripciones impresas de pantallas con formato, es decir, pantallas que se presentan en una terminal para introducir datos en un programa o base de datos ya cxistente. En el apartado 4.2 se clasifica la informacion presente en los formularios y luego se ofrece una metodologia para crear un esquema mediante la extraccién progresiva de informacion de los formularios. Las declaraciones de registros 0 formatos de registros pertenecen a aplica- 100 DISERNO CONCEPTUAL DE BASES DE DATOS 1. Andios de tos requerimientos 1.1. Anataar les requoriniontos y ftrar es ambiguadaoo 1'2. Dia los erunsiados on cornice homogeneoe 2. Dsseho inci 21. Congr un esquema amazén global 3. Disefo de esquemas: para cada concepto del esquema armazén,aplica 31 Printvas cessandentos 32 Pematvas asoondertas 33. Prmtvas oxtugas hasta ue toc os requermlentos estén expresaces en & esquema Figura 4.1. Disefio de vistas a parti de requerimientos en lenguaje natural. ciones ya existentes, escritas en lenguajes de programacién convencionales, Es importante tener en cuenta este tipo de datos de entrada, porque en muchos casos el sistema de bases de datos incorpora una organizacién de archivos cons- truida con un lenguaje de programacion convencional. En el apartado 4.3, se centra la atencién en Cobol, el lenguaje de programacién mas usado para apli- caciones convencionales de procesamiento de datos. El analisis de los requerimientos est fuertemente influido por la naturaleza de los requerimientos. Los pasos subsecuentes utilizan las primitivas y estrate- Bias de discfto gencrales, descritas en los apartados 3.1 y 3.2. 4.1. Disefio de vistas a partir de requerimientos expresados en lenguaje natural Una metodologta para el diseio de vistas a partir del lenguaje natural incluye el anélisis de requerimientos, el disefio inicial y el disefio de esquemas, como muestra la figura 4.1, Durante el andlisis de los requerimientos, el texto que des- cribe los requerimientos se analiza cuidadosamente para descubrir ambigieda- des y para entender en detalle el significado de los terminos, Luego se dividen os enunciados en conjuntos homogeneos, de modo que cada conjunto corres- ponda a un concepto especifico. Durante el disefto inicial, estos grupos de enun- ciados son la base para construir el esquema armaz6n, que expresa los concep- tos e interrelaciones mas importantes. Luego, el esquema se refina por medio de primitivas descendentes y ascendentes, hasta que todos los requerimientos estén representados en términos de conceptos de ER. 4.1.1. Andlisis de los requerimientos Sabemos, por experiencia, que el Lenguaje natural es ambiguo y que los malen- tendidos son muy comunes. En el caso de requerimientos escritos en lenguaje DISERO DE VISTAS 101 En una base de detos de una uriversidad, se representan datos sobre estudiantes y protesores, Para ls estuciantes, se representa ol apelico, edad, sexo, ciudad y provincia de ‘acimiento, ciudad y provincia de residencia de sus familas, bgeres y provincias donde vivieron antes (con el lapso que vveron en cada unc), cursos que han ‘aprobado, con nomore, cddgo, protesor, nota y focha. Asimismo, eo roprosontan ios cursos 2 os que asisten en la actualdad y, pare cada uno, dia, sitios 10 horas ce imparticion de las clases (cada curso 111. ¢ imparte lo sumo una vez en un dia) Para estuctantos graduados, 12 © representa ol nombre do! consajero 19. el numero total de créditos en el ultimo af. 14 Para estudiantes de doctorado, se representa el tiuo y area 15 ce investigaoién da su tesis. Para los maestros, 2 16 representa o apelido, edad, lugar y provincia de nacimianto, 17 _romere del dopartamento ai que pertenecen, nimero de taléfono, 18. titio, stuaciin y temas de investgacién. Figura 4.2. Requerimiontos para la base de datos de una universidad. natural, es conveniente realizar un anélisis profundo del texto, Este anilisis es atin mds necesario cuando los requerimientos se transmiten oralmente, me- diante entrevistas 0 conversaciones informales. Sdlo cuando los requerimientos han sido establecidos firmemente, se puede continuar con seguridad. Los ejem- los de este apartado se basan en los requerimientos escritos presentados en la figura 4.2. Si analizamos en detalle los enunciados de la figura 4.2, encontraremos va- rias inexactitudes y ambigiedades. ,Cémo se puede proceder a descubrirlas y filtrarlas? Las siete reglas empiricas que siguen son de utilidad. 1. Elegir el nivel apropiado de abstraccién para los términos. Los térmi- nos abstractos se usan con frecuencia en enunciados de la vida real, en casos en que los términos especificos serian mas apropiados para clarificar la situacién. Las categorias generales son comunes en el lenguaje natural porque produce una comunieacién répida y eficaz en la que, comiinmente, la ambigiedad se resuelve por el contexto, Sin embargo, en el disefio conceptual se debe utilizar ‘términos en un nivel correcto de abstraceion, especialmente si el disenador no ‘es un experto en el dominio de la aplicacion. En nuestro ejemplo, aparecen los siguientes terminos abstractos: lugares, lapso y situacion; los términos apropia- dos correspondientes son: ciudades, nimero de aftos, estado civil. 2. Evitar el uso de casos en lugar de conceptos generales, Esta regla evita Ja fuente opuesta de ambighedades; los usuarios de los sistemas de informacion adoptan, a veces, términos mas especificos que lo necesario. Por ejemplo, en una empresa de electronica, un encargado puede decir: anecesito conocer, a diario, la cantidad en existencia de chips». El término chips no describe un con- $02 DISERIO CONCEPTUAL DE BASES DE DATOS cepto, sino mas bien un caso del concepto correcto, esto ¢s, componentes. Por tanto, el término preferido tendria que ser componentes. Evitar las expresiones vagas o indirectas. En el lenguaje natural se usan. con frecuencia la repeticién deliberada y las expresiones indirectas. Se puede decir: «mica la persona sentada en la taquilla», en vez de: «mira el taquillero». La segunda oraci6n indica una clase especifica de entidades (taquillero), mien- tras que la primera se refiere a la misma clase indicando una interrelacién con otra clase de entidades (persona). Asi pues, la segunda oracién permite una cla- sificacién mas clara de los conceptos. Al usar rodeos se incurre en ¢l riesgo de expresar el significado de los conceptos en términos de referencias implicitas a otros conceptos, en lugar de referencias explicitas 2 los conceptos mismos. 4. Elegir un estilo estandarizado de enuneiado. En la libre conversacion se usan muchos estilos sintécticos para lograr una comunicacién mas eficaz. Esta variedad de estilos debe evitarse en los textos que definen los requerimientos; el uso de categorias sintacticas simples permite un modelado directo (y tinico) de los requerimientos, Idealmente, se deberian producir enunciados que res- pondan a algtin estilo esténdar; por ejemplo, las descripciones de los datos de- berian ser de la forma . Los enuncia- dos que describen operaciones deberian utilizar, tanto como sea posible, estructuras sintécticeas no ambiguas, similares a las de los lenguajes de progra- macion, como 0 . La aplicacion com- pleta de esta regla no es siempre posible o conveniente; el disenador debe seleccionar un estilo apropiado como un término medio entre la estandariza- cin y la expresividad, 5. Verificar los sinénimes y homénimos. Los requerimientos suelen resul- tar de las contribuciones de varios usuarios. Distintas personas pueden dar el mismo significado a diferentes palabras (sindnimes) o diferente significado a las mismas palabras (homénimos). En general, el riesgo de los homénimos es ma- yor cuando el vocabulario de términos es pequento, mientras que el riesgo de los, sinénimos es mayor cuando el vocabulario de términos es rico. Mas ain, si dos usuarios distintos adoptan vocabularios en diferentes niveles de abstraccisn, in- curren en el riesgo de los sinénimos. En el ejemplo, los tres términos diferentes: ‘maestro, profesor y consejero se refieren al mismo concepto (son sinénimos).. Lugares se usa dos veces, con diferentes significados (homénimo). 6. Hacer explicitas las referencias entre términos. Algunas ambiguedades surgen al no especificar las referencias entre los términos. En el ejemplo, no esta claro si el ntimero de teléfono es una propiedad de los profesores 0 de los depar- tamentos. Notese que los conceptos referidos pueden estar explicitamente men- cionados en los requerimientos (profesores y departamentos) u omitidos por completo (esto es cierto para dia que se puede interpretar como dia de la se- DISERO DE VISTAS 103 nea Tomine ‘Nuevo tring 5 Logares ‘Cudados 8 Lapse ‘Num go afos 8 ‘Actuaed ‘Ato actual 9 Da Dia doa somana 8 Stios ‘Alas 10 Clases Cursos 6 Masso Profesor 6 Logar Chdad v Telstons Toston 18 department 8 ‘stuacon Estado evi ‘Stusctnes ambigo 18 Tema ‘Area ce rvestigaion Shona oo tea de ivestgaccn ona Kea Figura 4.3. Términos ambiguos en los requerimientos con posibles correcciones. ‘mana o dia del mes; los términos semana y mes no aparecen en los requeri= mienios) 7. Utilizar un glosario. La creacion de un glosario de términos es una buena forma (aunque demanda bastante tiempo) de entender el significado de los tér- ‘minos y eliminar las ambigaedades de los requerimientos. Después de crear un glosario completo, solo se deberian utilizar los términos del glosario en las des- cripciones de los requerimientos. Fl glosario debe incluir, para cada término: 1) su nombre; 2) una definicién corta (5 a 20 palabras) que sea aceptable para to- dos los usuarios del término; 3) posibles sinénimos, es decir, términos que ten- gan igual significado para los usuarios (los sindnimos expresan cl area de equi- valencia del término); y 4) posibles palabras clave, es decir, palabras légicamente cercanas al término (ias palabras clave expresan el drea de influencia del tér- mino). La aplicacién de estas reglas usualmente produce requerimientos més es- tructurados que al inicio de la actividad de disetio. La figura 4.3 muestra todas las fuentes de ambigiedad y sus correcciones. La figura 4.4 muestra los reque- rimientos eseritos de nuevo. Llegados a este punto, s¢ analiza el texto y se descompone en conjuntos de ‘enunciados, tales que cada conjunto de enunciados se refiera al mismo con- cepto; este proceso se muestra en la figura 4.5. Esta actividad produce modifi- caciones locales del texto 0 el desplazamiento de fragmentos del mismo, y ayuda a estructurar los requerimientos. Si los enunciados relativos al mismo concepto estan agrupados, es mas facil tener en cuenta todos los detalles acerca de ese concepto durante el diseto. 104 DISERO CONCEPTUAL DE BASES DE DATOS En una base de datos de una uriversidad se representen datos sobre estudiantes y profesores. Para los estuclanies $9 representa el apeligo, edad, sexo, Cudad y provincia de nacmiento, ‘Cudad y provincia de residencia de sus familias, cudades y provincas donde hen vivido antos (con el numero de aos que vivieron en cada une), cursos que hen aprobado, con nombre, ‘éeigo, profesor, nota y fecha. Asimismo, se representan los cursos a los que asisten en el afi actual , para caca uno, ola de la Semana, aulas y horas de mparticion de los cursos (cada Curso ‘0 imparto a fo sumo una vez on un dia). Para estudiantes greduados se representa o! nombre del Cconsejere doctorado, se representa el tuo y éree de investigacién de sus tesis. Para profesores se representa el epelido, edad, ciudad y provincia de nacimiento, nombre del depertamento al que Pertenecen, nimero de teléfono del Gepertamento, tuo, estado oily area de Investigacion. Figura 4.4. Los requerimientos, después de fitrar las ambigiledades, 4.1.2. isefio inicial El objetivo del disco inicial es la creacién de un esquema armaz6n. Los con- eptos que aparecen en el esquema armazén son los conceptos mas evidentes mencionados en los requerimientos, Primero se considera el agrupamiento de los enunciados determinados durante el analisis de requerimientos: los concep- tos mencionados en cada grupo serdn buenos candidatos para transformarse en En ura base de datos do un universidad ve representa datos sobre estuaries y rotesores, Enunciados generales Para os estudartes, se rpresertao polio, edad, 70, cudad y provha de nacmiento, Guded y rovncla de residencia de 5s fais, cludadesy provincia Gord han vio anes (con & nero de aos que vero (2 cada ual cursos que har aprobado, con nombre, cbdigo, profesor, nota y fecha Enunciados sobre estuclantes, [Asmisro se represent los curs aos que asisten on elo actualy para cada uno, ia dela serena. aes horas de imparbcion de los cursos (cada curso se impare aio sumo une vez en Wd. Para estuaries craduacos se representa ol nombre del corsejero er el timo ato. Para estudiantes de docio- a Se representa ol uo y ea de vesigacon de su tess Enunciados sobre pos espections de estudiantes Para profesores se represenia el epelio, edad, Cuded y provincia de nacrnonte, nombre del depertamento al ‘quo pertenacon, nimare de telllone del deparamento, tile estado chilyérea de investiga, Enunciados sobre profesores Figura 4.5. Particién de enunciados en grupos homogéneos. DISENO DE VISTAS 105 esToOANTE Gia cso (8) Primer esquema armazon Guo PERSONA (©) Esquema armazén refinado Figura 4.6. Desarrollo del esquema armaron, entidades del esquema armazon. En el ejemplo, son: ESTUDIANTE, PROFESOR y curso. Se aflade CIUDAD, una entidad facilmente reconocible. Una vez que se elige un grupo inicial de entidades, se le puede superponer una red inicial de interrelaciones, correspondientes a entaces ldgicos entre gru- pos de enunciados. Asi, la interrelacion LUGAR_DE_NACIMIENTO_DE conecta CIUDAD Con ESTUDIANTE y PROFESOR, IMPARTE une PROFESOR y CURSO, RE- LACIONADO_CON une CURSO y ESTUDIANTE, y OTRA une CIUDAD y ESTU- DIANTE. Las dos ultimas interrelaciones son, intencionalmente, imprecisas y se refinardn mas adelante. El esquema correspondiente se muestra en la figura 4.6a, Ya se tiene un primer esquema armaz6n; antes de continuar con el disefo, es conveniente revisar el esquema armazon y posiblemente realizar alguna rees- ‘tructuracin. Si se observa las interrelaciones LUGAR_DE_NACIMIENTO_DE entre 406 OISER CONCEPTUAL DE BASES DE DATOS los pares de entidades (ESTUDIANTE, CIUDAD) y (PROFESOR, CIUDAD), se descu- bre una semejanza entre PROFESOR y ESTUDIANTE; esta semejanza se confirma si se observa el resto de los requerimientos. Por tanto, modificamos el esquema introduciendo la nueva entidad PERSONA y fusionando las dos interrelaciones LUGAR_DE_NACIMIENTO en una interrelacién nueva entre CIUDAD y PERSONA. La introduccién de la nueva entidad PERSONA simplifica las posteriores activi- dades de diseo, puesto que las propiedades comunes a ESTUDIANTE y PROFE- SOR ahora se relacionardin con PERSONA. 4.1.3. Diseito de esquemas Ahora se procede a tefinar y extender el esquema a fin de representar todas las caracteristicas expresadas en los requerimientos. El anatisis se concentra en cada concepto de! esquema armazén, verificando si se puede refinar con el uso de las, reglas de refinamiento analizadas en el capitulo 3, En el ejemplo, se usa lo si- guiente: 1, Refinamientos descendentes. a) La entidad eSTUDIANTE se puede refinar en términos de dos subconjun- tos: ESTUDIANTE_GRADUADO y ESTUDIANTE_DE_ESTUDIANTE_DE_DOC- ‘TORADO. b) La interrelacion OTRA, entre las entidades CIUDAD y ESTUDIANTE, se puede refinar en términos de dos interrelaciones: RESIDENCIA y RESIDENCIA- -FAMILIAR. 2. Refinamientos ascendentes. Una vez insertada la emtidad ESTUDIANTE_GRA. DUADO en el esquema, se observan los requerimientos y se nota que existe una relacion entre estudiantes graduados y sus profesores asesores, Esta in- terrelacidn, llamada ASESORADO_POR, se puede insertar ahora en el es- quema. 3, Refinamientos centrifugos. Una de las propiedades de la entidad PROFESOR € DEPARTAMENTO. Puesto que hay varias de las propiedades asociadas con los departamentos (nombre, direccién y numero de telefono), se puede re- presentar DEPARTAMENTO como una entidad, y el enlace ldgico entre PRO- FESOR y DEPARTAMENTO mediante la interrelacion PERTENECE_A. El es- quema que resulta de la aplicaci6n de estas primitivas se muestra en la figura 47. Para praceder a hacer los refinamientos finales, ahora se puede enfocar cada concepto del esquema y verificar su complecién, De ese modo, sc definen atri- ‘butos para cada entidad o interrelacion y se especifican los identificadores y las correspondencias. Puede verse que los requerimientos textuales no se expresan muy bien con la interrelacién RELACIONADO.CON, entre ESTUDIANTE y CURSO. De hecho, Ia interrelacién se debe refinar con la introduccién de estas nuevas interrelaciones: DISERIO DE VISTAS 107 oa raw |

[commen ‘eon CA FAMLIAR Fescen> oe CADE ESTUDIANTE PROFESOR 000, ESTUDANTE ‘SRADUADO eTown. as Figura 4.7. Refinamionto del esquema armazén, 1, La interrelacin APROBO, la cual representa cursos que el estudiante aprobd, con dos atributos: NOTA y FECHA. 2. La interrelacién asisTe, la cual representa cursos a los que el estudiante asiste actualmente. 3. La interrelaci6n Se_IMPARTE_EN, entre CURSO y la nueva entidad DIA_DE- -LA.SEMANA, que representa el horario semanal de clases @ las que asisten los estudiantes durante el aito actual, con dos atributos: AULA y HORA, El esquema se completa ahadiéndole algunos otros atributos, cardinalidades de interrelaciones e identificadores. El esquema final se muestra en la figura 4.8. 4.2. Diseito de vistas a partir de formularios Los formularios son documentos estructurados utilizados para intercambiar i formacion dentro de las organizaciones, y en particular para proporcionar in- formacién de entrada de datos a los sistemas automatizados. Puesto que los for- mularios estén orientados al usuario, deben ser de ficil comprensi6n, Comunmente, se puede distinguir cuatro partes en un formulario: de certi- ficacién, extensiva, intensiva y partes descriptivas. La parte de certificacién con= tiene informacién que certifica la existencia y correccién del formulario, como ‘son los identificadores, fecha de emisién, sellos, marcas y firmas. Por lo regular, 108 DISENO CONCEPTUAL DE BASES DE DATOS ownc sveaiw0 Prov I 7° on on coun ° a eAATAVENTO aa fm u “ | Jase fava etre nenent oe censos on na 0 Cu mo esse cSTaNTE mrareson Fo mus _ oso |” FF iter ce mvesmancon oF a t rr) on eae. oh ‘awcuo | eruowTe, Lormo.ress reo o eaeerouse Fotas an foun coo. «f ome So] ons Le te Ta p MLA <2 > sonas oo CASE —]-# sovere esa Figura 4.8. Esquema final. esta parte no comunica informacién seméntica pertinente y no se hard mds re- ferencia a ella. La parte extensiva es el conjunto de campos que son llenados con valores proporcionados por el usuario cuando se compila el formulario. Esta es la informacion que una persona incorpora en un formulario preimpreso. La arte intensiva es el conjunto de referencias a nombres de campos, explicitas 0 implicitas, del formulario. Esta es la informacion preimpresa en los formularios de papel. La parte descriptiva contiene instrucciones o reglas que deben seguirse para Ilenar los campos de la parte extensiva. La figura 4.9 muestra el Formulario 1040EZ del impuesto sobre la renta para declarantes solteros sin dependientes, emitido por el servicio norteamericano de recaudacion interna (U.S. Internal Revenue Service, IRS): las cuatro partes se indican en la figura. Usualmente las partes extensiva ¢ intensiva del formulario DSENO DE VISTAS 109 Sea ae STR Canarian ‘eruuny Declaracién de impuestos pare 1040EZ declarentes solteros sin dependiontes. 1989 Wombre _ pslnciaea IRS S my tene cima, por fre ade Ter vor core Ine ranee 9876543210 Se namer deep ci KE Ingresos | ivmium¥v-taguew bma WS) 4 gyuecs 2 2 inumoy prt esc 9 oes Ml ie. Sinan? f mmeesacoaes See wna 0 8 mn a tn a 1 dn pun i ple oe en Enclastic cunt maecunsaseuoe 2 ea th ort Calcule su puesto rest mpvaonten mmc cite {itgns tb tbe sel rer eabaente: Cm carm ate re En ing ene : Devolueiin ocantdad QUE 80s cnt Soude ‘taal! 9 Siete Yaar el nnn a Ella declare: serene deni en rey cmp aetna ‘comarceans X Fara ce conten "Einca ae Prada ja Aino de Aca te Recon fe Tao cas conan eles | FornularLo 104082 385) Fare eesti?) Figura 4.9. Formulario 1040EZ de deciaracién de impuastos de Estados Unidos. 110 DISERIO CONCEPTUAL DE BASES DE DATOS 421. 1. Andis do los roquerimentos 14. Diaoga ae partes oxtereiva, intnsiva y deeerptiva cl formulario 112 Seloelone eres y bares 2. Diseho Inti 24. Construya un eequema armazén global 3. Disefo de esquemas: para cada area 3.1. Constuya ol esquaa da area 582. Fusion esque co dra con ol esque smazcn Figura 4.10. Disefo de vistas a partir de formuarios. se intercalan; las partes descriptivas pueden estar interealadas 0 separadas (por ejemplo, las notas al pie). A veces se omite la parte descriptiva, porque las re- glas para Ilenar el formulario son muy evidentes (por ejemplo, el campo APELLIDO_DE_SOLTERA debe ser llenado s6lo por mujeres). ‘Una metodologia para el disefto de vistas a partir de formutarios se muestra en la figura 4,10. Dentro del andlisis de los formularios, se identifican las partes extensiva, intensiva y descriptiva. El formulario se descompone en areas, es de- cir, porciones del formulario que son homogéneas en su contenido y describen los mismos conceptos. Lucgo se desarrolla cl esquema armazén scleccionando ‘unos cuantos conceptos para cada drea, y cl disefio de vistas subsecuente se rea liza mediante un andlisis érea por area. Anlisis de formularios El primer objetivo del anélisis de formularios es entender la estructura y signi- ficado del formulario; para este fin, es util distinguir sus partes extensiva, inten- siva y descriptiva. Se obtiene informacién adicional sobre la estructura de los formularios subdividiendolos en areas, Puesto que los formularios se usan para facilitar el intercambio de informacidn, la posicién de los campos en los for- mularios estd, por lo regular, muy estudiada, y la informacin homogénea es contigua. Un drea es, simplemente, una porcién del formulario que trata con elementos de datos estrechamente relacionados entre si. Considérese una parte del formulario 1040A para la declaracién de impucs- tos individuales en los Estados Unidos de 1989, mostrado en la figura 4.11. Se istinguen tres areas: el drea | se refiere a los datos personales, el area 2 a las exenciones y el drea 3 a la evaluacion de ingresos. Las areas pueden dividirse posteriormente en subéreas, En el drea 2 se detecta una subarea sobre los de- pendientes del declarante, y en el area 3 se detecta una subarea sobre la proce- dencia de las rentas. Como regla general, los disetadores prefieren usar descom- posiciones en areas que dividan cada formulario en fragmentos de complejidad similar; lo mismo se aplica a la descomposicién de areas en subéreas. Ast, las reas y subéreas de los formularios resultan buenas candidatas para descompo- DISERNO DE VISTAS mt ner la actividad de disefto. En la figura 4.1 se asocia un marco con cada area 0 subérea; el arbol de la figura 4.12 también representa la descomposicion del for- mulario en areas. 4.2.2, Disefio inicial En el disefto de un esquema armaz6n es importante la eleccion de un grupo de conceptos que estén en un nivel de abstraccién apropiado: ni muy general, ni muy detallado. Si los conceptos son demasiado generales, se requiere un gran numero de refinamientos para completar el disefo; si los conceptos son dema- siado detallados, el esquema armaz6n no offece una visidn global de la aplica- cin, Un buen punto de partida pars elegir los conceptos del esquema armazon ces organizar las éreas de forma jerarquica, en una estructura de arbol que indi que fragmentos de informacién homogéneos de alto nivel La figura 4.13 muestra el esquema armazén e indica, para cada entidad, el rea de la que proviene. El esquema armazén incluye las entidades DATOS_PER- SONALES, DATOS_DE_EXENCIONES, DATOS_DE_INGRESOS y DETALLE.DE_DA- ‘TOS_DE_INGRESOS, y las interrelaciones entre ellas. 4.2.3. Disefio de esquemas Durante el diseto de esquemas, el esquema armazén se transforma y enriquece: progresivamente. Tanto la parte intensiva del formulario como la extensiva, proporcionan sugerencias uitiles sobre cémo proceder en el disefio. En este sub- apartado se analizan algunas estructuras que se presentan comunmente en los, formularios y se muestra la traduccion de estas estructuras a conceptos de ER. ‘Texto paramétrico. El texto paramétrico es un texto en lenguaje natural con alunos campos vacios que tienen que llenarse con valores provenientes de do- minios adecuados. El texto se completa con indicaciones adicionales sobre los valores a introducir en los campos; tanto el texto como las indicaciones adicio- nales constituyen la parte intensiva. Cuando los campos se llenan, el texto se vuelve completo y coherente. Un ejemplo de texto paramétrico es el siguiente: Se certifica que________, nacidoen one) oem) art el_/ 1 19_, sirvio en el ejército desde ol _/ _/ 19 hasta el_) _/ 19__ como. Diese Adviértanse los distintos tipos de subtitulos usados en el texto paramétrico para expresar las propiedades de los datos. En la primera linea del texto, Norn- 112 1989 omar cnr en mare DISERKO CONCEPTUAL DE BASES DE DATOS Régimen 1 (Form arto 1040A) Panet (coninuscise Nore 9 Femina teva por Sada de dor Soenenes tie 2 ego ree a tas Tike Tea ie 103 pms WR De a Ba gia i Iho ya lbare 8a sm te bie ee su pening wry 88 IRCLUVA la cannes rman oper ctl 10 em 14 Les ume eo clad rear Gree 909 pu chad ue pe ue aifque Vspepee ar rare im 16 bebe ivy sings ties En pn 4c aS scones A TO 17 seme ema 4 19, eek tec ws eros eon po nae io sonar spect, ates i ea {Ser iota ecane jens we dati apne » 20 eee pain Rene a ore 9 ew naz cl edn (ceo 9 ner todas Ov nsuna erase een omen N08 Ens ean de anus ince Next ce ane nan Parte ‘untomaone eee an formate 189 Orb deuna ‘moras de ambre de ia Smee pe onl eee ‘re apancr Pie rman. Parte i Sesmulona ooo ita eres se ‘proc t ‘mide area ‘ede teat gue Bomalen Tagresoe por interones (ea p26 de av nscNS alee par) ut ime mar IDE eb me emt a Tina aeneeie pana aa 2 sone canna ens tnd al eu eel ma 1404, eB 2 ‘gresoe por dvidendos (sean. 24d as instances) React pre ona din | Fr 1404» ci a de en ident ‘ee Figura 4.11. Formulario 1040A para la declaracién individual del impuesto sobre la renta en Estados Unidos, DISENO DE VISTAS 13. Toaoa —_Declaracion individual dei to sobre la renta de EEUU. 1989 Pee) (a Nee Exiqueta, 1 ™ eer oro nde para campaha presidencial a Drea dont 8. fo Cs ON ampten eaten SSalenen coun gnc msnbc Gacictnns | Lg Enea Pao? 1 seo, peeve rte 62 Merge, | 2 Qeratocerdcontecicandcwusio nti Bete | 9 Gcunonenwnna uma oda ans ug ee oon ana oe Soe 4 catenin praca We pg 1 ST now ae soe we Se ran stone sntorce au catenin or ar ie cw 1h ep Paot =" | cee rea canateneeeeT mith Tac Bh ae RON RA SORT SAREE previo 1985. manger age bo Steet pues ee a | ‘Caleule sus, - j— {0 Fen won rine nab 3, Rama OH na nT tomer sone Keomest] Betsey mes hee = sointeaaa ieee: % | 9 iden nr mare i com ef ‘ 40 Compensaciia por devemsiro tsepuro) et formelacio 1089.6. 0 i 11 seein? 4.9) nt en bu Fae sn Apa on tee a Eee enone eres i” | catia D exiccn tas nu a ree Catered ease ee > Seren nua Ea i 19 oes nowt me eta tet ope ty alsa relent tyrone eos pe Rm | Figura 4.11.Bis (Cont) 114 DISERO CONCEPTUAL DE BASES DE DATOS Formuéatio de deciaracién del impuesto sobre la renta foIN wi ears | Dependientes Procedencia de los ingresos Figura 4.12. Arbol de éreas y subéreas del formulario mostrado en la figura 4.11 bre y Apellido son nombres tinicos de conceptos de! formulario. En esa misma linea, Ciudad y Pueblo son los dos nombres posibles del concepto correspon- diente. Para terminar, en la ultima linea, Oficial y Soldado indican los posibles valores para el concepto en cuestiGn. El esquema ER correspondiente debe con- tener cuatro atributos: APELLIDO, NOMBRE, CIUDAD_DE_NACIMIENTO Y RAN- GO_MILITAR. El texto estructurado, como desde _/ _/ 19_ hasta __/ _/ 19_.. indica explicitamente la existencia de dos atributos, COMIENZO.DEL_SFRVICIO_MILITAR y FINAL DEL_SERVICIO_MILITAR y ademés proporciona informacién sobre la c3- tructura de los datos (por ejemplo, necesidad de 6 bytes), que sera util en las, siguientes fases del diseno. ‘oa DATOS PERSONALES INGRESOS DATOS_DE_ EXENCIONES, Brea? Figura 4.13. Esquema armazén de la base de datos para el formulario del impuesto sobre la renta. DISENO DE VISTAS 115 Paso? argue au estado 1 1 Soltero, (Yea puede usar fmuaro 104062) ‘lel Geclorade 2 ( Casado con cedaracén corjunta pian) ‘5 C Gasado con celaraocn separada. irodurca arb ol nimare de seguro social dl conyuge y ol nombre completo aqui 40 Cite de eb (on pron cfd (oa apg 16) apron calf Sain 6 0 Veta candy con, Figura 4.14. Ejemplo de una lista. Listas. En una lista se presentan exhaustivamente todos los posibles valo- res de un concepto: se selecciona algunos de ellos (por ejemplo, poniendo una marea) cuando se completa el formulario. La figura 4.14 muestra una lista del formulario de declaracién del impuesto sobre la renta 1040A. Cuando se traduce una lista a conceptos ER, es importante entender si las alternativas presentadas al usuario son excluyentes; en este caso, se puede uti zar un solo atributo con un valor sencillo para representar Ia lista de alternati- vas. Si, por cl contrario, son posibles las elecciories multiples, sera necesario in- troducir un atributo sencillo con miiltiples valores o bien un atributo para cada ‘opcién (de tipo booleano). En el ejemplo de la figura 4.14, las opciones son ex- cluyentes; por esta razon, se introduce el atributo sencillo ESTADO_DE_DECLA- RACION. Tablas. Las tablas se modelan convenientemente introduciendo entidades especificas que tienen dos conjuntos de atributos: los idenuificadores y los valo- ves. Los identificadores seleccionan de manera inequivoca cada posicién de la tabla, mientras que los valores corresponden al contenido de la tabla. En el formulario de declaracién del impuesto sobre la renta 1040A, la segunda y ter cera partes presentan una tabla cada una, las tablas de ingresos por intereses € ingresos por dividendos. En este caso, se refina la entidad DETALLE_DE_DA- ‘TOS_DE_INGRESOS, presente en el esquema armaz6n, para dar dos entidades individuales: DETALLE_DATOS_INTERESES ¥ DETALLEDATPS_DIVIDENDOS, correspondientes cada una a una de las tablas; el identificador para cada fila de Ja tabla lo da la combinacion del numero de seguro social del declarante y el numero de la fila. Los atributos de valor son NOMBRE_DEL_PAGADOR e IM- PORTE. Las tablas pueden ser mas complejas (arrays multidimensionales); por ejemplo, la figura 4.15 muestra un ejemplo de array tridimensional que repre- senta los gastos de una compafia durante un periodo de tres aios. Cada gasto se reficre a un aito, un mes del aio y un periodo del mes, En el caso de los arrays multidimensionales, el niimero de atributos necesarios para la identi cacion es mayor. En este ejemplo, los atributos de identificacion son: IDENTI- FICADOR_DE_LA.COMPASIA, ANO, MES y PERIODO; el atributo de valor &s GASTO. artes opeionales del formulario. Un campo del formulario es opcional cuando se puede llenar o dejar vacio, dependiendo de reglas que usualmente 116 DISERIO CONCEPTUAL DE BASES DE DATOS Gastos durante los tres uitimos aos 1966 | ene Feb Mar Abr May Jun 24 Age Sep Oct Nov Oe 1909 | Ene Feb Mar Abr May Jun Jd g9 Sop Oct Nov De 1990 | Ere Feb Mar Abr May Jun Ju Ago Sep Oct No Die Figura 4.15. Ejemplo de tabla multidimensional aparecen en forma explicita, pero que también pueden ser implicitas. Por ejem- plo, considérese el enunciado en la zona superior de la tercera parte del formu- lario del impuesto sobre la renta (Fig. 4.11): Llene esta parte y acompatte el ré- ‘gimen 1 al formulario 10404 si recibié mds de 4008 en dividendos. Esta oracion indica que la tabla INGRESOS_POR_DIVIDENDOS entera puede dejarse vacia, Esta opcionalidad se traduce al modelo ER asignando cero como cardinalidad mt- nima de la entidad DATOS_DEINGRESOS en la interrelacion DETALLE_DE_DIVI- DENDOS. La mayorfa de las opcionalidades se refieren a los atributos. Considérese de nuevo la parte del formulario de la figura 4.14 y obsérvese que las opciones 3 y 4 precisan Ienar un espacio vacio. Esto corresponde a introducir algunos atributos adicionales: NUM_SEG_SOC_DEL_CONYUGE, NOMBRE_DEI_HUO_PARA_CABE- ZA.DEFAMILIA, y ¢l atributo compuesto NOMBRE_COMPLETO_DEL_CONYUGE. Sin embargo, puesto que el rellenado de espacios se requiere sélo en el caso de elecciones especificas, estos atributos son, ciertamente, opcionales (por ejemplo, con cardinalidad minima de 0). Datos derivados. Un campo contiene datos derivados cuando su valor se puede calcular a partir de otros datos del formulario. El formulario del im- puesto sobre Ia renta contiene muchos ejemplos de datos derivados; por ejem- plo, el ntimero de casillas marcadas en el area de exenciones puede derivarse de las casillas individuales. Asimismo, los campos 11, 12c y 13 del area de ingresos DISERO DE VISTAS 17 corresponden a datos calculados. Por ultimo, los totales de las cantidades en las tablas para ingresos por intereses y por dividendos pueden derivarse sumando entradas individuales. Es importante sefalar que los datos derivados no se almacenan necesaria- mente en la base de datos, porque pueden ser calculados por un programa. Sin embargo, volver a calcularlos puede ser costoso; asi, en algunas aplicaciones, los datos derivados se almacenan realmente dentro de registros de base de datos. Quiza 1o més razonable en el nivel conceptual sea incluir los datos derivados € indicar con claridad cémo se pueden calcular. La figura 4.16a muestra ef esquema conceptual final. Todos los detalles del esquema se deben considerar con cuidado, especialmente los valores de cardi- nalidad de los atributos y los atributos compuestos. Notese que los dependientes se modelan como una entidad en las subdreas de exenciones, puesto que se puede asociar algunas propiedades (atributos, interrelaciones, subentidades) con los dependientes. La figura 4.16b indica las reglas que se usan para calcular los da- tos derivados. 4.3. Disefio de vistas a partir de formatos de registros Las aplicaciones comerciales implantadas en computadores usan invariable- mente archivos, es decir, conjuntos de registros almacenados en la memoria se~ cundaria. Cada registro consiste en un grupo de campos, los cuales pueden, a su vez, componerse de subcampos. En consecuencia, los registros suelen tener una estructura jerérquica y cada campo se sitiia cn un determinado nivel dentro de la jerarquia. Los lenguajes mas comunmente usados para escribir aplicaciones son Cobol, PL/1, Fortran y C. La estructura de los archivos se declara en los programas que los utilizan; por ejemplo, los archivos de Cobol se declaran en una determinada parte de los programas en Cobol, llamada division de datos (DATA Division). La figura 4.17 muestra la declaracion en Cobol de un archivo PEDiDo. Cada registro corres- ponde a un pedido; algunos campos (por ejemplo, CODIGO-DE-PIEZA, UNIDAD- DE-PIEZA, CANTIDAD) cortesponden a unidades atémicas de informacién (cam pos clementales); otros campos (por ejemplo, VALOR, FECHA-DE-ENVIO) estén a su vez estructurados en subcampos (campos compucstos). En Cobol, como en otros lenguajes que utilizan archivos, varias cldusulas de la definicion de archivos especifican e! papel de los campos, su asignacion de almacenamiento, los tipos de acceso disponibles para el archivo y otras carac- teristicas. Esta informacion es muy importante para determinar los significados de los campos, sus relaciones l6gicas internas y las abstracciones definidas entre ellos, para asf poder representar el archivo en términos de un esquema eR. Los programas de aplicacién que no utilizan un Dems (sistema de gestién de bases de datos) repiten, por lo regular, la definicién de archivos en sus partes iniciales. En el disciio de esquemas ER a partir de formatos de registros, se empicza 118 DSENO CONCEPTUAL DE BASES DE DATOS [0 ESTHDO.DE DECLARAOON DATOS an po no SE0.900 TT ee Fo PRES.CANPATGN 7 a Toman 07 AT manee ota An J» nausensoe I> covresicioncesewrteD Seleeeria [—O IMPORTE.GRAVABLE NTERESES FO DEDUCCION.IRA Lo senccoum.cowiee Lu [Fo Ton oenoaesos mee Lo ronLanst00 ms To ness a0 xusta00 on Lo tora oeoroaces Fo roratenrereses CETL [Fo vows pcs008 es. on sor. s62.0 even COMP ETO SONU ‘owen ne | Bay Dabs Tcaeeneres aL Se 8 ewer oepenoenre HS non. i DOSLAROS. [-® WNLSEA.s0C ‘OLMAS 9) Esquema conceptual fel Figura 4.18, Esquema del formulario de la declaracién de la renta. ATRIBUTO DISENO DE VISTAS. 119 DERIVAGION TOTAL DE INGRESOS TOTAL AJUSTADO INGRESO BRUTO AIUSTADO TOTAL DE INTERESES TOTAL DE DIVIDENDOS TOTAL CASILLAS. TOTAL DEPENDIENTES ‘TOTAL EXENCIONES (b) Esquema conceptual final ‘SALARIO TOTAL + INGRESOS POR INTERESES + NGRESOS POR- DIVIDENDOS + COMPENSACION DESEMPLEO DEDUCCION IRA + DEDUCCION IRA CONYUGE TOTAL DE INGRESOS ~ TOTAL AJUSTADO. ‘uma de IMPORTE en DETALLE DATOS INTERESES conectados por la nterelacén DETALLE DE INTERESES suma de IMPORTE en DETALLE DATOS DIVIDENDOS conectades por lainterretacon OETALLE DE DIVIDENDOS 1 + cardhaldad de NUM DE SEG SOC DEL CONYUGE ‘ardinalided de OEPENDIENTE TOTAL CASILLAS + TOTAL OEPENOIENTES Figura 4.16.Bis Esquema de! formulario del impuesto sobre la renta (continuacién). introduciendo una entidad sencilla para representar el archivo y se le da el mismo nombre que al archivo. Esta eleccidn es bastante natural, ya que un archivo es un conjunto de datos con la misma estructura. Luego, se consideran las partes 01 PEDIDO. 02 NUMERO-DE-PEDIDO. PIC x(10), 02 FECHA.DE-EMISION. 03 ANO-DE-ENISION ic 2) 03 MES-DE-ENISION Pic 92), 03. DIA-DE-EMISION PIC 92). 02 FECHA.DE-ENTREGA. 3 ANO-DEENTREGA Pic 92, 03. MES-DE-ENTREGA PIC 93, 03 DIAOE-ENTREGA PIC 9a, 02 VALOR. 03 PRECIO Pic aeqve9, 03 CODIGO-MONETARIO PIC X@} 03 TASA-DE-CAMBIO PIC 96)v99. (02 LINEA-DE-PEDIOO OCCURS 10 TIMES, 03 CODIGO-FIEZA Pic 96) 03. CLAVE-DE-LINEA co 03. UNIDAD-DE-MEDIDA PIC X02) 93. CANTIDAD PIC 9(6) COMPUTATIONAL. 02 CODIGO-DE-ALMACEN, Pic x9) 02 CODIGO-DE-PROVEEDOR PIC x(4). 02 CLIENTE PIC X(15), 02 FABRICA PIC x@). igura 4.17. Descripcién en Cobol de un archivo Pepioo. 120 DISERO CONCEPTUAL DE BASES DE DATOS (cléusulas) de la definicion del archivo para deducir propiedades estructurales adicionales del archivo. Asi, la representacién simple inicial del archivo se en- riquece progresivamente con la introduccién de nuevas entidades, interrelacio- nes, generalizaciones, atributos, etcétera. En este apartado se examinan algunas de las clausulas que pueden aparecer en una definicién de archivo y se ofrecen directrices generales para su transformacién en elementos del modelo ER. Para concretar las ideas, se usar la terminologia del lenguaje Cobol. 4.3.1. Campos simples ‘Un campo es simple cuando tiene una sola ocurrencia en cada caso de registro y ¢s subindicado (o repetitivo) en caso contrario, Los campos simples pueden ser elementales 0 compuestos. Los campos elementales simples se traducen en atributos simples del modelo ER; los campos compuestos se traducen en atri- butos compuestos. Considérese el formato de registro de Ja figura 4.17. Las si- guientes lineas se traducen en atributos simples de la entidad PEDIDO. 02 CLIENTE x(15). 02 FABRICA PIC X(2) Las siguientes lineas se traducen en un atributo compuesto de la entidad PE- DIDO. 02 FECHA-DE-EMISION. 03 ANO-DE-EMISION PIC 9(2). 03 MES-DE-EMISION PIC 9(2), 03. DIA-DE-EMISION Pic (2), 4.3.2. Campos subindicados (repetitivos) Los campos subindicados de Cobo! tienen multiples ocurrencias, y cada ocu- rrencia se identifica por un mimero progresivo. En Cobol, los campos subindi- cados estan definidos en una cldusula OCCURS, la cual especifica el ntimero de ocurrencias del campo en cada caso del registro. En la figura 4.17, LINEA-DE-PE- DIDO €s repetitivo y ocurre 10 veces en un registro de PEDIDO. Los campos sub- indicados con una cléusula OCCURS sencilla se traducen en atributos sencillos, y sus cardinalidades minima y maxima corresponden al valor de la cléusula ‘occurs. Una estructura de datos usada con frecuencia en Cobol es la tabla, o array DISERO DE VISTAS 121 CANTIDAD EN EXISTENCIA DE UN PRODUCTO a eee % a a Fo 23 be ra 3 Mor 98 rs Pa wwe 2 2 a My 54 6 8 we 8 38 % a ul cr 2% 2 e do 5a & 9 se 98 & Ps ote Fs 2 a Nov 8 5 & a De 8 6 a 01 PRODUCTO 2 NOMBRE PIC x20) (© CODGO PIC x8) 2 PRECIO PCa 02 TABLADE-CANTIDAD-ENEXIST. 03 CANTIDADENEXIST-PoR-ANO OCCURS 4 TIVES. (64 CANTIOADEN-EXIST-POP-MES FC 99 OCCURS 12 TIMES. ) }=-# co0i80. prooucto [9 noweRe Fo precio (co0160_0€ PROD es © CANTIDAD © Figura 4.18. Tabla que muestra la cantidad en existencia de un producto, el formato de registro correspondiente y el esquema eR, n-dimensional, Los arrays con n dimensiones se expresan en Cobol con el uso de n clausulas OccuRs subordinadas. Los registros con mds de una clausula Oc ‘cons subordinada se representan mejor introduciendo una nueva entidad. 122 DISERIO CONCEPTUAL DE BASES DE DATOS Considérese Ia tabla de la figura 4.182, que muestra la cantidad en existencia de un producto, clasificada por mes y afto, Esta tabla se describe en Cobol como un campo subindicado, definido por el uso de dos casos de la cldusula OCCURS, como muestra la figura 4.18b. Como ya se expuso en el apartado anterior, una tabla se representa en el modelo ER introduciendo una entidad nueva; en este caso, se aftade CANTIDAD_ENLEXIST que tiene como atributos de identificacion CODIGO_DE_PROD, ANO y MES, con el atributo de valor CANTIDAD. La entidad CANTIDAD_EN_EXIST est conectada a la entidad PRODUCTO por la interrelacién pispontBiLipaD (Fig. 4.18c). 4.3.3. Redefinicion de campos La redefinicion de campos permite a los programadores definir la misma parte de un registro usando diferentes cldusulas de definicion de campos. Puede uti- lizarse con dos propésitos diferentes: 1) visuatizar los mismos datos segiin dife- rentes puntos de vista, y 2) optimizar el espacio de almacenamiento fisico. La primera aplicacién de la cldusula REDEFINES se muestra en la figura 4.19: cl mismo conjunto de campos se agrega en dos grupos diferentes, de acuerdo con su uso en los procedimientos. El disefiador debe elegir la mejor represen- tacion conceptual, que puede ser cualquiera de las dos o una combinacion de elias. En este ejemplo, los subcampos BUSQUEDA se usan en un procedimiento de actualizacion que no distingue el nombre y el apellido, y que no requiere el dia y el mes de nacimiento. En el esquema conceptual es preferible mencionar explicitamente todos los atributos, por lo cual se selecciona la primera alterna- tiva La segunda aplicacién de la cléusula REDEFINES usualmente indica la pre- sencia de una jerarquia de generalizacién entre los conceptos descritos en el archivo. En la figura 4.20, el campo DATOS_DEL_TRABAJADOR se redefine dos veces en 10s campos DATOS_DE_SECRETARIA y DATOS_DE_DIRECTOR. Se puede traducir el archivo a un esquema con la entidad EMPLEADO y una jerarquia de generalizacion con las subentidades TRABAJADOR, SECRETARIA Y DIRECTOR. 4.3.4. Punteros simbélicos Un puntero simbélico es un campo de un registro que denota el identificador de otto registro, Los punteros simb6licos suelen usarse en Cobol para expresar interrelaciones logicas entre archivos. Por ejemplo, en la figura 4.21 se definen tres formatos de registro, referentes a empleados, departamentos y proyectos. Las relaciones entre empleados, departamentos y proyectos en los que traba- jan se expresan por medio de tres campos diferentes, que se usan como pun- teros: 1) CODIGO-DEPARTAMENTO liga los empleados con sus departamentos, 2) CODIGO-DEPARTAMENTO proyecto vincula los empleados con los proyectos cn los que trabajan, y 3) CODIGO-DEPARTAMENTO liga los proyectos con los de- partamentos que los controlan, DISENO DE VSTAS 123 (01 PERSONA (2 DATOS-PERSONALES 03 NoMaRE 4 APELUDO. Pie x20) 04 NOMBRE-DE-PLA Pic x20) 03 FECHADE.NACINENTO 4 ARO Pc oo Ot MES Pico ok Om Pic 99 (2 DATOSPERSONALES IS. REDEFINES OATOS-PERSONALES or ovees (a) Came ees owas vensou > al L__}-Cesicresvcnr Ye ©) Figura 4.19. Primer ejemplo de uso de Ia cldusula ReDeriNEs, Los punteros se traducen a interrelaciones en el modelo ER. Estas interrela- ciones conectan la entidad que tiene el campo puntero y la entidad correspon- diente al archivo al que «apunta». Las cardinalidades minima y maxima de las interrelaciones dependen del significado especifico de los campos. La figura 4.21 muestra la traduccion de tos punteros recién mencionados a interrelaciones de las entidades EMPLEADO, DEPARTAMENTO y PROYECTO, Como caso particular, puede suceder que un puntero se refiera al campo identificador del registro en el que esta definido; este caso se ejemplifica en la figura 4.22, que describe la estructura jerdrquica de los proyectos y subproyectos desarrollados en una com- pafiia, Estos punteros corresponden a las autointerrelaciones, o interrelaciones en /azo (es decir, las interrelaciones binarias de una entidad con la misma enti- dad), 43.5. Banderas El término bandera hace referencia a campos o grupos de campos que suelen utilizar los programadores en Cobol para indicar si cl campo o campos subsc~ DISENO CONCEPTUAL DE BASES DE DATOS (1 EMPLEADO. 2 coniso Pic x, @_TIPO.DE-TRABAJO PIC x (02 DATOS.DEL-TRABAJADOR, 03) HORAS-SEMANALES Pic 99 03 EN-TURNO. Pic x 83, AFLIACION-SINDICATO PIC x6), (2 DATOS.DE SECRETARIA REDEFINES DATOS DEL-TRABAJADOR. 08 NIVEL PICD. 04" TELEFONO FIC 9. (2 DATOS-DE-OIRECTOR REDEFINES DATOS-DE-SECAETARIA 08 PRESUPLESTO ACB), « = evpteado [5 4 TRABAJADOR SECRETARA DIRECTOR BBL TURNO TELEFONO S presuruesto HOMS.seMALes 6 HIE GarAcON SNOCATO ©) Figura 4.20. Segundo ejemplo de uso de la cléusula ReDerwnes. cuentes en un caso de registro toman un valor o se dejan vacios. Las banderas pueden indicar la presencia de un subconjunto entre dos (o mas) conceptos dis- ‘tintos expresados en el archivo. Como ejemplo, considérese en la figura 4,23 el archivo de pélizas de seguro de una compaiifa, Algunos campos son validos para cualquier tipo de péliza (NUMERO, FECHA-DE-TERMINO, etc.); solo algunas polizas incluyen el riesgo de robo. Esta propiedad estd puntualizada por el campo BANDERA_DE_ROBO: el va- lor es 0 para polizas que cubren robo, | para las que no. Si el valor de BANDE- RA_DE_ROBO €s 0, los campos CANTIDAD_ASEGURADA y COBERTURA deben es- pecificarse. Notese que ésta es una convencién adoptada por el programador; sin embargo, en Cobol no se dispone de un control durante la ejecucién para ascgurar su cumplimiento. Se puede traducir la declaracién de archivo de dos formas diferentes: 1) con una entidad inica, en cuyo caso los campos a los que se refiere la bandera se traducen en términos de atributos con cardinalidad mi- DISENO DE VISTAS 125 02 EVPLEADO, 03, cooigo Pic x10), 03 CODIGO-DEPARTAMENTO PK a(S). 33, COOIGO-PROYECTO PIC 47} OCCURS 10 THES. 02 DEPARTAMENTO 03, Congo" Px), @ Proyecto, 93, COED Bem), 03 COD.DEPT FIC a5, 03 DESCRIPCON PIC x(30, « 20100 ef Stea50 proveoro [8 $2200 Reuiaoo> DEPARTAMENTO Conrnowd T Como © Figura 4.21. Primer ejemplo de traduccién de punteros. nima opcional de cero, y 2) con dos entidades relacionadas por un subconjunto, ‘como muestra la figura 4.23. 4.3.6. Reglas para valores de campos En muchos programas en Cobol, Ios usos especificos de los campos se expresan, en términos de reglas basadas en los valores. Estas reglas son muy generales y tipicamente incluyen intrincados trucos de programacién, dificiles de entender. Dado que su semantica no se expresa mediante las propiedades estructurales de los datos, las reglas casi siempre se entienden con solo estudiar los programas. Como ejemplo, se muestra un archivo que trata de la contabilidad de una compania. Se definen tres niveles de contabilidad: ta division, el centro de cos- tos y la cuenta especifica, Las cuentas se agrupan por centro de costos, y éstos se agrupan por divisiones. Asi, el campo CENTRO-DE-CosTOS (que indica el c6~ digo de un centro de costos) s6lo es significativo en registros de cuentas, y el ‘campo DIVISION (que indica el cédigo de una divisién) s6lo cs significative en registros de centros de costos. El formato de registros del archivo se muestra en 126 DISERIO CONCEPTUAL DE BASES DE DATOS 01 PROYECTO. 02 co0IGo. PIC x(5) 2 DESCRIPCION. FIG (80) 02 CODIGO-SUPERPROYECTO PIC xis) 02 PRESUPLESTO PIC 9) ® sus 1# conico PROYECTO [-0 DESCRIPCION (On) PRESUPUESTO ‘SUPER < > wy Figura 4.22. Segundo ejemplo de traduccion de punteros. ©) la figura 4.24a. Los valores especificos de los cédigos establecen si un caso de registro pertenece a uno de los tres niveles. Las reglas para los valores de los c6- digos se muestran en la figura 4.24b. Se puede concluir que: 1) el archivo es el resultado de la fusion de tres tipos logicamente diferentes de registros, relacio- nados jerarquicamente, y 2) los campos CENTRO_DE_COSTOS Y DIVISION se pue- den considerar como punteros a otros registros del mismo archivo. Partiendo de este analisis, en la figura 4.24c se muestra un posible esquema ER para la definicion del archivo, La entidad INFORME_DE_CONTABILIDAD re- presenta la raiz de una generalizacién cuyas subentidades son CUENTA, CEN- ‘TRO_DE_COSTOS y DIVISION. Las dos interrelaciones de uno a muchos entre las subentidades expresan la estructura jerarquica definida entre los conceptos. Este apartado se completa mostrando en la figura 4.25 el esquema ER que representa el archivo PEDIDO presentado en la figura 4,17. El archivo se traduce introduciendo dos entidades, PEDIDO y LINEA_DE_PEDIDO, Notese que los dos atributos CODIGO_DE_ALMACEN y CODIGO_DE_PROVEEDOR son en realidad punteros, y pueden representarse de manera conveniente a través de interrela- ciones con las entidades ALMACEN y PROVEEDOR. 4.4. Resumen Este capitulo ha examinado tres enfoques diferentes para el diseiio de esquemas conceptuales de bases de datos, con base en los distintos tipos de requerimientos de entrada. Se ha mostrado, casi siempre mediante reglas y ejemplos simples, como aprovechar la estructura de los requerimientos. Las sugerencias se uti Ejercicios DISERNIO DE VISTAS 127 01 POLIZA-DE-SEGURO. 02 NUMERO PIC x(10), (02 FECHA-DE-TERMINO. 03 AND PIC 92, 03 MES PICA. 03 DA PIG 92, (02 BANDERA.DE-ROBO PICS. 8@ NO-ROBO VALUED. 88 S-ROBO VALUE 02 CANTIDAD-ASEGURADA PIC (10), 02 COBERTURA PIC 9{10} (a) TP _NUMERO nag an POLIZA. DE_SEGURO TeRMINO Yo MES Dia { BANDERA DE_ROBO Pouza. _ | 0 CANTIDAD_ASEGURADA CON_SEGURO_ DE.ROBO |—O COBERTURA ) Figura 4.23. Ejemplo de traduccién de una bandera. zan sobre todo durante la primera etapa del disefio, donde los requerimientos tienen que entenderse y corresponderse con los esquemas armaz6n conceptua- Jes; después, el diseflador debe ser capaz de profundizar el andlisis desarrollando: los pasos de refinamiento de acuerdo con la metodologfa general expuesta en el capitulo 3. 4.1. Construya un esquema conceptual para la siguiente descripcién en len- guaje natural. Disene un sistema de bases de datos para una Facultad de Farmacia, Di- vision de Farmacocinética Clinica, La division tiene proyectos de investi- gacion en varias etapas de desarrollo: en curso, pendientes y completos. Cada proyecto obtiene fondos de una subvencidn Unica. Por lo general, la 128 DISENO CONCEPTUAL DE BASES DE DATOS (1 INFORME-DE-CUENTA, @ 2 @ @ cs @e copI60 Pos, ESCRIPCION Pic x90, CENTRO-DE-CosToS © PICS). vision Pic se), ESPONSABLE PIC X80. archivo de contablidac de una comparia. ‘TEL CODIGO ESTA ENTRE TEL REGISTRO SE REFIERE A 1000 y 9980 ‘na cuenta 100 980 tn can de costos *y9e tna (@) Regias detinidas para el archivo ce contablidas 12 cooico INFORME_DE Gontaationd [© Bescarcon Fo ResPoNsaBLe cuenta | | o=naRORe | vsiow ‘cOsTOS on (ta (ut) oa eS (6) Esquema conceptual ra 4.24, Ejemplo de traduccién de archivos con regias dependientes de los va- lores. ‘mayor parte de esta subvencion se usa para pagar a los sujetos de estudio; os diversos farmacos y equipos usados en los experimentos suelen ser pro- porcionados por una o més compaifas farmacéuticas. Un proyecto estudia los efectos del férmaco en varios sujetos, algunos de los cuales ticnen regi- menes terapéuticos desiguales. Varios empleados de la Facultad de Far- macia trabajan en cada proyecto, dirigido por un investigador principal; cada investigador principal puede controlar varios proyectos. Cuando se completa un estudio, se hace un informe de la investigacion, donde se des- criben los resultados del estudio. DISERIO DE VISTAS 129 PeDID0 tay —o cente n> Lo Franca i) NUDE PEDIOO unenoe. Hho Cave DeLNEA Peo [0 uNCAD.ce MeDOK CANTON Figura 4.25. Representaciin en del archivo PeD00. 42. 43. Construya un esquema conceptual para la siguiente descripcion en ten- guaje natural Disefie un sistema de bases de datos para controlar la informacion sobre rutas de una compaiiia de autobuses. Cada ruta cubierta por la compaia tiene un lugar de inicio y uno de término, pero puede pasar por varias pa- radas intermedias. La compaiia esta distribuida en varias sucursales. No todas las ciudades donde paran los autobuses tienen una sucursal; sin em- bargo, toda sucursal debe estar cn una ciudad situada en las rutas de au- tobuses. Pueden existir miltiples sucursales en una misma ciudad y tam- bien multiples paradas en la misma ciudad. La compafia asigna un autobuis a cada ruta; algunas rutas pueden tener varios autobuses. Cada au- tobus tiene un conductor y un asistente, asignados al autobus por el dia. Construya un esquema conceptual para la siguiente descripcién en Ien- guaje natural. Diseiic la base de datos para la oficina de administracion y reservas de una compafiia de autobuses. Cada pasajero puede reservar un asiento para un tramo determinado de las rutas que cubre el autobiis. Las rutas tienen un lugar de inicio, uno de término y varios lugares intermedios. Los pasajeros pueden especificar si prefieren la seccién de fumadores o de no fumadores. Algunos pasajeros pueden abordar un autobus, aun sin reserva, cuando hay asientos vacios. Con cada reserva, se almacenan el apellido, iniciales y nu- mero de teléfono de! pasajero. En ocasiones no se realizan los viajes por malas condiciones atmosféricas, en cuyo caso se notifica a los pasajeros que tienen reservas. Al final del viaje, el asistente del conductor informa a la compaiia la cantidad total de billetes comprados por los pasajeros en el DISENO CONCEPTUAL DE BASES DE DATOS MENTO DE SALUD Y SERVICIOS DE REHEABILITACION lore spe bre ean Se ee Ee nla ee se feleate pre eperso pa fo secdete bor! ue eee res Toe [shewwarbimnnie [anna ag ce ea ‘Feast cme a [eet [AT ee haere cnt [Teer 7 Caan (ake acne (ta rawaonne re ae Co apt 1. Oierte e Toe eenaeae cadena 2 Arnel Cn ee (ES tne en ti it cp [Neem csnesocnin car ce cman mare) Figura 4.28. Formulario para un informe de accidente, DISERO DE VSTAS 131 er DE RC ACONTS Ppa Be M ” he tote on einai eo cnt recone pe stim yr pd pe eet pe ote rm ESE LA erQuTTA De MPRESON ABAD 'SERYICIOS TECNICOS DE. COMUNICACION SERYICIOS TECNICOS DE COMUNICACION Figura 4.27. Formulario para solicitar reimpresiones de articulos del IEEE. 192 on on o or DISERO CONCEPTUAL DE BASES DE DATOS DATOS DE EMPLEADOS. (2 NUMERODENTIFICACION 02 NOMBRE 2 EMPLEADO-SUPERVCOR [2 CONTROLADO POR WANDOS DEL SISTEMA (2 CONTROLADO.POR.ALARMAS-DEL SISTEMA MANDOS-DEL-SISTEMA, G2 TPO. 02 FECHA G2 HORA, 03, HORAS 03 MMNUTOS 03, SeaUNDOS (02. UBICACION 93) NOMBRE 93 LUGAR 3 TRO ‘ALARMAS-DEL SISTEMA, TPO. 2 FECHA VALOR 2 HORA 02 HORAS. 03 MMNUTOS: 03, SeGuNDOS (© UBICACION 03 NOMBRE 08 Lugar 03 THO. omunucactones, TTECNOLOGIA Vvaocos PK 90. (@_DISPOSITIVO-REMOTO OCCURS 10 TIMES. Pca, PIC m0), FIC 20), FIC m5) OCCURS 10 TIMES, Pic »(6) OCCURS 10 TIMES. 3) NOMBRE ‘Pe x10, 93. TPO, PIC xi), 93 LugAR PIC x20), (02 DATOS-DE-CLABLEADO. 03 MODEM. 4 TPO Pe x10), Of VeLOgDADTRANEMEION PED 04 FILER Pic 20), (02. DATOS.DE NICROONDAS REDEFINES DATOS.DE CABLEADO. 03 RADIO. 04 RADO Pe x6) ‘04 MOOO.DE-TRANSMISION Pic <8) 04 FRECUENCIA Pe 10), (04 ANTENA’ PIC 6) Figura 4.28. Definictén de archivo del control distribuido de un proceso de manutac- tura. DISERO DE VISTAS 133, 44. 45. 4.6, 47. autobtis ¢ indica esta cantidad a la oficina administrativa de la sucursal de destino de la ruta. Construya un esquema conceptual para la siguiente descripcién en len- guaje natural. Diserte la base de datos para un entorno de apoyo a la programacion. En este entorno los programadores producen programas, que se escriben en determinados lenguajes de programacion. Cada programa es escrito por un determinado programador, puede llamar a otros programas y puede ser utilizado por determinados usuarios. Los usuarios se reconocen por su nombre de entrada al sistema; los programadores se reconocen por su nombre de entrada al sistema y por su c6digo; los programas poseen nom- bres compuestos que incluyen el nombre del programa, la extension y el c6digo de! programador, Los programas tienen un numero de version, una fecha y una descripcion breve; algunos programas interactian con los DBMS. Cada DsMs mantiene datos almacenados en forma de relaciones, con va- rios atributos y una clave primaria. Cada base de datos la define un admi- nistrador de bases de datos, que es un programador especializado en la ad- ministracion de datos. Construya un esquema conceptual que contenga todos los datos del for- mulario mostrado en la figura 4.26, un informe sobre lesiones del Depar- tamento de Salud y Servicios de Rehabilitacion det Estado de Florida. ‘Construya un esquema conceptual que contenga todos los datos del for- mulario mostrado en la figura 4.27, un formutario de pedidos para solici- tar reimpresiones de articulos del IEEE (Instituto de Ingenieros Eléctricos y Electronics). Traduzca las definiciones de archivos en Cobol de la figura 4.28 a un es- quema ER. Toda la aplicacion trata del control distribuido de un proceso de manufactura. El archivo DATOS-DE-EMPLEADOS indica que cada em- pleado puede controlar mandos y alarmas. El archivo MANDOS.DEL_SIS- TEMA trata de los mandos disponibles para controlar procesos y los lugares. donde cada mando puede accionarse. E] archivo ALARMAS_DEL_SISTEMA trata de los mismos datos en el caso de las alarmas. Por tiltimo, el archivo COMUNICACIONES describe los datos sobre subsistemas de comunicaciones, su tecnologia, los dispositivos conectados, ubicaciones de los dispositi- vos, etc. La transmision de datos puede hacerse mediante microondas o por cable. 194 DISENO CONCEPTUAL DE BASES DE DATOS Bibliografia P. P. Chen, «English Sentence Structure and Entity-Relationships Diagrams», Informa- tion Sciences, 29, 1983, 127-150. Este articulo investiga la estrecha relaci6n existente entre la estructura de la oracién inglesa y los diagramas ER. Por ejemplo, los sustantivos corresponden a entidades y los verbos a interrelaciones. V. de Antoneliis y B. Demo, «Requirements Collection and Analysis». En S. Ceri, ed., Methodology and Toots for Data Base Design, North-Holland, 1983. Se proponen algunas reglas empiricas para restringir la descripcién en lenguaje na- tural de los requerimientos, de acuerdo con convenciones adecuadas (filtros para el len- guaje natural), y para calificar, dentro de las restricciones impuestas a las descripciones, enunciados que se refieren a datos, operaciones, sucesos y restricciones. C. Elek y P. C. Lockemann, «Acquisition of Terminological Knowledge Using Database Design Techniques». En S. Navathe, ed., Proc. ACM-SIGMOD International Confe- rence, Austin, Tex., 1985. Este articulo propone conceptos, métodos y herramientas de apoyo para la construc- cion de una terminologia comuinmente aceptada ¢ integrada para usarse en un esquema conceptual. JF. Sowa, Conceptual Structures: Information Processing in Mind and Machine, Addi- son-Wesley, 1984 Los esquemas ER no tienen e} suficiente detalle para captar todo el significado del texto ‘en inglés u otros lenguajes naturales. En su lugar, el autor propone el uso de grafos con- ceptuales que ofrecen una representacion seméntica intermedia: pueden representar el significado de las oraciones en inglés y, asimismo, pueden facilitar fa traduccién a dia- gramas ER M, Colombetti, G. Guida, y M. Somalvico, «NLDA: A Natural Language Reasoning System for the Analysis of Data Base Requirements», En S. Ceri, ed., Methodology and Tools for Data Base Design, North-Holland, 1983. Este articulo presenta un sistema para el andlisis de requerimientos en lenguaje na- tural que ayuda al diseador a extraer de los requerimientos la descripcién de los datos, transacciones y sucesos. Estos se filtran y clasifican adecuadamente y, en cierta medida, el sistema ayuda al diseador a inferir la estructura del esquema de base de datos a partir de ellos. M. Bouzeghoub y G. Gardarin, «The Desiga of an Expert System for Database Design», Proceedings of the First International Workshop on New Applications of Databases, Cambridge. Mass., 1983. B, Flores, C. Proix y C. Rolland, «An Intelligent Tool for Information Design», Proc. Fourth Scandinavian Research Seminar on Information Modeling and Data Base ‘Management, Ellivuori, Fintandia, 1985. Estos dos articulos describen sistemas expertos para el diseito de bases de datos; entse ‘otras caracteristicas, los sistemas analizan, interpretan y estructuran la informacion pro- porcionada mediante enunciados en lenguaje natural. También interactiian con el usua- rio para eliminar las situaciones ambiguas 0 para pedir la informacién que falta. Final- DISERO DE VISTAS 135 mente, se produce un modelo conceptual de la base de datos; el modelo es en realidad una rica red semintica. El primer enfoque se centra en las propiedades estaticas de los datos y utiliza la normalizaci6n; el segundo se centra en las propiedades dinamicas de los datos (por ejemplo, operaciones y sucesos). C. Batini, B. Demo y A. di Leva, «A Methodology for Conceptual Design of Office Da- tabases, Information Systems, 9, nims. 3, 4, 1984, 251-63. Este articulo ¢s la fuente de la metodologia para derivar esquemas conceptuales que toma formularios como documentos de entrada (Apdo. 4.2). K. H. Davis y K. Arora, «A Methodology for Translating a Conventional File System into an Entity-Relationship Model». En J. Liu, ed., Proc. Fourth International Con Jerence on Entity-Relationship Approach, Chicago. IEEE Computer Society Press, 1985. E.G. Nilsson, «The Translation of Cobol Data Structure to an Entity-Relationship Type Conceptual Scheman, Proc. Fourth Intemational Conference on Entity-Relationship Approach, Chicago, IEEE Computer Society Press, 1985. Estos dos articulos describen metodologfas para traducir un archivo convencional a tun esquema ER. Las metodotogias proceden a traducir primero la declaracion del archivo convencional a un modelo de datos intermedio, eliminando los detalles sobre la implan- tacién fisica del archivo, En seguida, el modelo intermedio se traduce al modelo ER. Hi. Beck y S. B. Navathe, «Integrating Natural Language and Query Processing», Proc: IEEE COMPCON, San Francisco, feb-mar, 1990, Ese articulo expone la correspondencia entre las consuitas en lenguaje natural y una estructura conceptual en el modelo de datos CANDIDE, propuesto por los autores. Se de- sarrolla un léxico especifico para el dominio de aplieacién, y el razonamiento sobre los términos se utiliza usando las jerarquias conceptuales de cliusulasy atributos

También podría gustarte