Corso di Architetture della Informazione Anno Accademico 2009

Corso di Architetture della Informazione Anno Accademico 2009 -2010 4. 2 Il reverse engineering di schemi C. Batini N. B. Dispensa di approfondimento non in programma 1

1. Introduzione 2

Questo grafico e’ del 1962 Rsappresenta i flussi informativi tra Pubbliche Amministrazioni 3

Fonte Marbach-Rizzi op. cit. da D. Natale, Storia dell'informatica in Italia, Sogei, 2005 4

L’architettura nel 1988 fonte G. Rivieccio, Anagrafe Tributaria, Franco. Angeli, 1995. 5

Struttura tipica di un sistema monolitico di prima generazione Terminale 3270 Mainframe Terminale 3270 File system Base Dati 6

La struttura della informazione e’ rappresentata nel programma • • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMo. 10 COD-UOMO PIC X(5). 10 DESC-UOMO PIC X(80). 05 DONNA REDEFINES UOMO. 10 TIPO-RECORD PIC X. 10 COD-DONNA PIC 9(5). 10 DESC-DONNA PIC X(80). 01 AMMINISTRAZIONE. 05 REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-DUMMY PIC X(6). 10 DES-REGIONE PIC X(80). 05 PROVINCIA REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-DUMMY 2 PIC X(3). 10 DES-PROVINCIA PIC X(80). 05 COMUNE REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-COMUNE PIC X(3). 10 DES-COMUNE PIC X(80). 01 PERSONA-AMMINISTRAZIONE. 05 LEGAME. 10 COD-PERSONA PIC X(5). 10 COD-AMMIN PIC X(3). 7

Organizzazione della programmazione • In realta’ i dati sono locali alle applicazioni … • Ogni programmatore utilizza i tipi di dati che gli servono …. 8

Per cui, funzionalita’ ANAGRAFE • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMo. 10 COD-UOMO 10 DESC-UOMO 05 DONNA REDEFINES 10 TIPO-RECORD 10 COD-DONNA 10 DESC-DONNA PIC X(5). PIC X(80). UOMO. PIC X. PIC 9(5). PIC X(80). 9

Funzionalita’ RESIDENZA • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMo. 10 COD-UOMO 10 DESC-UOMO 05 DONNA REDEFINES 10 TIPO-RECORD 10 COD-DONNA 10 DESC-DONNA 01 PERSONA-AMMINISTRAZIONE. 05 LEGAME. 10 COD-PERSONA 10 COD-AMMIN PIC X(5). PIC X(80). UOMO. PIC X. PIC 9(5). PIC X(80). PIC X(5). PIC X(3). 10

Funzionalita’ AMMINISTRAZIONE • • • • 01 05 10 10 05 10 10 AMMINISTRAZIONE. REGIONE. COD-REGIONE PIC X(3). COD-DUMMY PIC X(6). DES-REGIONE PIC X(80). PROVINCIA REDEFINES REGIONE. COD-REGIONE PIC X(3). COD-PROVINCIA PIC X(3). COD-DUMMY 2 PIC X(3). DES-PROVINCIA PIC X(80). COMUNE REDEFINES REGIONE. COD-REGIONE PIC X(3). COD-PROVINCIA PIC X(3). COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). 11

Le prime metodologie di sviluppo software • 1. Parti dai requisiti utente • 2. Decomponi i requisiti in funzionalita’ omogenee • 3. Per ogni funzionalita’ individua i dati elaborati dalla funzionalita’ • 4. Rappresenta i dati per mezzo di una rappresentazione DBMS (DATA DIVISION COBOL, gerarchica, reticolare, relazionale) 12

Quindi … • Le metodologie sono soprattutto per il disegno delle applicazioni, le applicazioni vengono (talvolta) documentate, i dati si documentano se avanza tempo, cosa che non succede mai. • • • Conseguenza dati locali alle applicazioni, dati documentati dentro le applicazioni, dati con formati e valori eterogenei, dati con semantica invisibile. 13

Il reverse engineering • E’ la attivita’ che permette di rappresentare ogni base di dati (chiamata anche nel seguito legacy data) per mezzo di uno schema descritto nello stesso linguaggio • Come linguaggio comune si utilizza un modello concettuale: – Un modello a oggetti – Il modello Entita’ Relazione – Un modello ontologico • Noi useremo il modello Entita’ Relazione 14

Understanding legacy data • Typical data reverse engineering process: – From implementation structures – To conceptual design • Usually … – Documentation is non-existing or obsolete (not updated) – Designers are gone Knowledge is missing 15

Il reverse engineering • Il reverse engineering è l’attività di traduzione e rappresentazione di uno schema logico di DBMS in un modello concettuale Schema nel modello di input Reverse Engineering Schema in un modello concettuale 16

Il reverse engineering • Intiutitivamente le metodologie per il RE dipendono dal modello schema in input Schema nel modello Di input Modello di rappresentazione Reverse Engineering Schema in un modello concettuale (supponiamo ER con generalizzazioni) 17

Strategie per il RE • Considereremo tre casi relativi al modello di input: – Modello relazionale – Input costituito da moduli o schermate di acquisizione dati. – XML – Linguaggio COBOL negli approfondimenti 18

Una metodologia generale per il reverse engineering • 1. Estrai conoscenza dalla documentazione disponibile • 2. Analizza le astrazioni utilizzate nel modello in input per rappresentare entita’, relazioni, generalizzazioni • 3. Per ogni struttura, trasformala in una corrispondente struttura nel modello ER • 4. Individua e Risolvi eventuali ridondanze di rappresentazione. 19

Astrazioni • Aggregazione (o Part-Of) – l’oggetto astratto ha come parti componenti gli oggetti da astrarre – Es. nel modello Entita’ Relazione la relazione Esame tra le entita’ [Studente, Corso] e’ una astrazione di aggregazione delle due entita’ - Es. nel modello Entita’ Relazione la entita’ - Impiegato (Matricola, Cognome, Eta’) e’ aggregazione dei tre attributi - Es. nel modello relazionale la relazione Impiegato (Matricola, Cognome, Eta’) e’ aggregazione dei tre attributi • Generalizzazione (o Is-A) – l’oggetto astratto corrisponde a un superisieme dell’ oggetto (oggetti) da astrarre. – Es. nel modello Entita’ Relazione l’entita’ Persona e’ generalizzazione delle entita’ Donna e Uomo. 20

2. Reverse engineering dal modello relazionale 21

Relational databases • The existing relational schema is usually not normalized • Information on – – – primary keys, candidate keys, foreign keys, functional dependencies, other constraints, derivation rules, … • may be missing (more often than you beleive). • … and is essential for the reverse engineering process 22

2. 1 Extract knowledge Where to find knowledge 23

Where to find … • Primary keys / Candidate keys – often defined in the schema – check Select Distinct in SQL queries – or mine the DB, that is find correlations among attributes • Foreign keys – check domain compatibility from the schema – check join conditions in SQL queries – check values in the DB • Dependencies (functional, referential integrity) – Mine the DB 24

Example • • • Person ( P#, name, address ) Employee ( E#, position, salary) Firstnames ( P#, firstname ) Emp. Dept ( E#, department ) Department (Name, location, boss, budget ) 25

Foreign keys? Person ( P# , name, address ) Firstnames ( P# , firstname ) Employee ( E# , position, salary ) Emp. Dept ( E# , department ) Department ( name, location, boss, budget ) • Finding foreign keys – Firstnames. P# Person. P# - Person. P# Firstnames. P# – Emp. Dept. E# Employee. E# – Emp. Dept. department Department. name – Department. boss Employee. E# – Employee. E# Person. P# 26

Further Semantic Enrichment • Goals: ensure better understanding of the schemas • Completing existing descriptions with : – meta-data for each representation external keys – thesauri semantic definitions – explicit representation rules Example : if a road crosses a river, a bridge exists – quality indicators 27

Enrichment Examples • Add information on how the schema maps to the real world – add a definition of "Employee" as "those persons who have an employment contract with the enterprise” – add a definition of "salary" in "Employee" as "the gross salary amount, before any deductions" • Add information on the description of the real world – "salary" in "Employee" is expressed in Euros 28

Esempio • Consideriamo inizialmente una relazione in Boyce Codd NF, in cui cioe’ tutte le dipendenze funzionali sono dipendenze di chiave. Lavoratore dipendente Codice Fiscale Data di nascita Citta’ nascita Stipendio CVFFFS 37 07/06/1965 Roma 20. 000 Viene naturale la traduzione Lavoratore dipendente CF Data nascita Citta’ nascita Stipendio 29

In termini di astrazioni Lavoratore dipendente Codice Fiscale Data di nascita Citta’ nascita Stipendio CVFFFS 37 07/06/1965 Roma 20. 000 1 Aggregazione 2. Traduzione della Aggregazione nel Modello ER Lavoratore dipendente CF Data nascita Citta’ nascita Stipendio 3 Entita’ LD su Attributi CF, Data. N, Citta’N, Stipendio 30

Esempio di generalizzazione (omessi gli attributi) • Siano date le relazioni Dipendente Codice Fiscale Data di nascita Citta’ nascita Tipo GNNFRTK 06/11/1963 Milano Dirigente CVFFFS 37 07/06/1965 Roma Impiegato Dipendente Impiegato Codice Fiscale Stipendio Straordinari max CVFFFS 37 30. 000 20 ore Impiegato Dirigente Codice Fiscale Retribuzione annua Premio max. GNNFRTK 200. 000 30. 000 Dirigente 31

Esempio di generalizzazione (omessi gli attributi) Se la generalizzazione e’ completa allora … Dipendente Codice Fiscale Data di nascita Citta’ nascita Tipo GNNFRTK 06/11/1963 Milano Dirigente CVFFFS 37 07/06/1965 Roma Impiegato Dipendente Impiegato Codice Fiscale Stipendio Straordinari max CVFFFS 37 30. 000 20 ore Impiegato Dirigente Codice Fiscale Retribuzione annua Premio max. GNNFRTK 200. 000 30. 000 Dirigente 32

Esempio di generalizzazione (omessi gli attributi) L’indizio che ci ha portato a questa scelta e’ nell’attributo Tipo Dipendente Codice Fiscale Data di nascita Citta’ nascita Tipo GNNFRTK 06/11/1963 Milano Dirigente CVFFFS 37 07/06/1965 Roma Impiegato Dipendente Impiegato Codice Fiscale Stipendio Straordinari max CVFFFS 37 30. 000 20 ore Impiegato Dirigente Codice Fiscale Retribuzione annua Premio max. GNNFRTK 200. 000 30. 000 Dirigente 33

Vediamo ore tre casi particolarmente significativi • Relazione normalizzata Boyce Codd • Relazione non in forma normale di BC • Tre relazioni normalizzate, con identificatori I 1, I 2, I 1 I 2 34

Relazione in forma normale di BC • 1. Relazione normalizzata R(A 1, A 2, …, An) • Traduzione entita’ E(A 1, A 2, …, An) con identificatore A 1 35

Relazione non in forma normale di BC • 1. Relazione R(A 1, A 2, …, An) • Dipende dalla struttura delle dipendenze che fanno perdere la normalizzazione • Caso R(A 1, A 2, …, An) Es. Localizz (Comune, Prov, Regione) • A 1 A 2 e A 2 A 3 A 1 A 2 (1, 1) (1, n) A 2 A 3 36

Tre relazioni normalizzate R 1(A 1, A 2, …, An), R 2(An+1, An+2, …, An+m) R 3(A 1, An+1, …, Ak) Traduzione Due entita’ ER 1(A 1, A 2, …, An), ER 2(An+1, An+2, …, An+m) e una relazione ER 3(A 1, An+1, …, Ak) 37

Tre relazioni con legame di generalizzazione • 2. Tre relazioni normalizzate R 1(A 1, A 2, …, An), R 2(A 1, An+1, …, An+m) R 3(A 1, An+m+1, …, Ak) in cui i valori del dominio di A 2 sono [R 2, R 3] Esempio Persona (…, Sesso, …) Uomo(…) Donna(. . ) Traduzione Tre entita’ su cui e’ definita una relazione di generalizzazione R 1(A 1, A 2, …, An) R 2(A 1, An+1, …, An+m) ISA R 1 R 3(A 1, An+m+1, …, Ak) ISA R 1 38

Esempio di reverse engineering – modello relazionale Relazione Persona (Codice Fiscale, Nome, Cognome, Citta’ di Nascita) Relazione Dipendente (Codice Fiscale, Nome, Cognome, Citta’ di Nascita, Dipartimento, Stipendio) Relazione Citta’ (Citta’, Regione) Persona Città Dipendente 39

7. 1. 2 Reverse engineering da modulistica/Fogli Excel 40

Esempio tabella a due entrate Reddito Mese/ Anno 2002 2003 2004 2005 di Gennaio Febbraio Reddito Mese … … … Anno oppure Anno Mese Valore reddito Reddito 41

Rappresentazioni e corrispondenti trasformazioni • 1. Rappresentazione: Tabella a due entrate, cioe’ con righe e colonne • Tipica trasformazione Relazione binaria, oppure Entita’ 42

Esempio modulistica: l’utente riempia i seguenti campi …. Nome Cognome Codice Fiscale Anno nascita Sesso Persona Riempire solo per nati dopo il 31 dicembre 2000 Nome Padre Nome Madre Luogo Nasc. CAP Regione Giovane 43

Rappresentazioni e corrispondenti trasformazioni • 2. Insieme di campi C 1, C 2, . . , Cn da riempire opzionalmente • Tipica trasformazione Entita’ ISA di altra entita’ definita precedentemente, definita sugli attributi C 1, C 2, . . , Cn 44

Esempio modulistica: l’utente riempia i seguenti campi …. Nome Cognome Codice Fiscale Anno nascita Sesso Via Numero Civico Regione Residenze pregresse Citta’ CAP 45

Esempio modulistica: l’utente riempia i seguenti campi …. Nome Cognome Codice Fiscale Anno nascita Sesso Persona Residenze pregresse Citta’ CAP Ha risieduto Via Numero Civico Regione Residenza 46

Rappresentazioni e corrispondenti trasformazioni • 3. Insieme di campi da riempire piu’ volte • Tipica trasformazione Entita’ in relazione molti a molti con altra entita’ definita precedentemente. 47

Reverse engineering from XML to Entity Relationship 48

XML - Extensible Markup Language • The Extensible Markup Language (XML) is a generalpurpose markup language (http: //www. w 3. org/XML/). • It is classified as an extensible language because it allows its users to define their own tags. • XML (e. Xtensible Markup Language) is one of the premier formats for data representation and interchange. • Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet. 49

XML and ER • XML as a logical database model has some special differences which makes the (standard) ER model unsuitable for the conceptual modeling of XML data [8]. The main differences are: – Hierarchical structure – Irregular structure – Ordering on siblings • These features cannot be properly modeled in the ER model. 50

Traduzione in Entita’ 51

Nel seguito … • XER e’ un linguaggio intermedio tra XML ed ER, in cui si usano strutture Entita’ Relazione in diretta corrispondenza con le strutture XML 52

Traduzione in Entita’ • XER Entity: The XER entity is the basic conceptual object in XER. A XER entity is represented using a rectangle with a title area showing the name of the entity and the body showing the attributes. • XER attributes are properties of entities that are usually atomic, potentially optional or multi-valued. Attributes are shown in the model by placing the names of the attributes in the body of the entity. – Attributes are ordered by default, and the ordering in the diagram is top-to-bottom. Multi-valued attributes are allowed, showing the multiplicity in parentheses. 53

XER Relationships – Example 54

XER Relationships • XER Relationships: Relationships, which denote a connection between two or more entities, are introduced in XER when a complex entity contains a complex element as one of its subelements. – Relationships can be one-to-one, one-to-many or many-to-many. The cardinality of relationships is equivalent to the min. Occurs and max. Occurs tags present in the XML schema. – In a XER diagram, a relationship is shown with a diamond as in the ER model. • Relationships may or may not be named, and labels along the connectors indicate participation constraints for a relationship and the connecting entity. 55

XER Generalizations - Example 56

XER Generalizations • XER Generalizations: The term “generalization” refers to the concept of having an entity that can have different sub-entities (with an IS A relationship). • In XER, a generalization is represented using a covering rectangle containing the specialized XER entities 57

Appendice 1: Esempio di traduzione ER esteso (XER) XML 58

A Complete XER Diagram 59

Conceptual XML • C-XML is a conceptual model consisting of object sets, relationship sets, and constraints over these object and relationship sets • C-XML is “Model-equivalent” with XML Schema: • “Model-equivalent” is a term which describes a system where a high-level model and a low-level execution system have a one-to-one correspondence between features. 60

Description of C-XML • Graphically a C-XML model instance M is an augmented hypergraph whose: – vertices and edges are respectively the object sets and relationship sets of M, and whose augmentations consist of decorations that represent constraints. – boxes represent object sets – dashed if lexical and not dashed if nonlexical because their objects are represented by object identifiers. – With each object set we can associate a data frame (as we call it) to provide a rich description of its value set and other properties. A data frame lets us specify, for example, that Order. Date is of type Date or that Item. Nr values must satisfy the value pattern “[A-Z]{3}-d{7}”. 61

Description of C-XML – Arrowheads on lines specify functional constraints. • In the example (see next slide) an Item has a Price and a Description and is in a one-to-one correspondence with Item. Nr and that an Item in an Order has one Qty and one Sale. Price. – Triangles denote generalization/specialization hierarchies. We can constrain ISA hierarchies by partition (…), union (…), or mutual exclusion (…) among specializations. – Any object-set/relationship-set connection may have a role, but a role is simply a shorthand for an object set that denotes the subset consisting of the objects that actually participate in the connection. 62

C-XML Example Generalization 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: <xs: element name="Customer" abstract="true"/> <xs: element name="Preferred. Customer" substitution. Group="Customer"> <xs: complex. Type> <xs: group ref="Customer. Details"/>. . . </xs: complex. Type> </xs: element> <xs: element name="Regular. Customer" substitution. Group="Customer"> <xs: complex. Type> <xs: group ref="Customer. Details"/> </xs: complex. Type> </xs: element> 63

Attributes C-XML Example 56: <xs: group name="Customer. Details"> 57: <xs: sequence> 58: <xs: element name="Customer. Name" type="xs: string"/> 59: <xs: element name="Customer. Addr" type="xs: string"/> 60: . . . 79: </xs: sequence> 80: </xs: group> 64

C-XML Example 11: <xs: element. . . min. Occurs="0" max. Occurs="5"> Cardinality 65

C-XML Example Primary Key 35: <xs: key name="Order. Key"> 36: <xs: selector xpath=". //Order"/> 37: <xs: field xpath="@Order. ID"/> 38: </xs: key>. . . 60: <xs: element name="Order" min. Occurs="0" max. Occurs="unbounded"> 61: <xs: complex. Type> 62: <xs: sequence>. . . 74: </xs: sequence> 75: <xs: attribute name="Order. ID" type="xs: positive. Integer" use="required"/>. . . 77: </xs: complex. Type> 78: </xs: element> 66

C-XML and XML Schema Artifact of XML nesting n-ary relationship decomposition 67

XQuery and C-XQuery Consider conceptual path “Item//Order. ID” 68

Bibliography 1. 2. 3. 4. 5. 6. 7. 8. A. Badia. Conceptual Modeling for Semistructured Data. In Proceedings of the 3 rd International Conference on Web Information Systems Engineering Workshops (WISE 2002 Workshops), p. 170 -177. Singapore, December 2002. M. Mani. ERe. X: A Conceptual Model for XML. In Proceedings of the Second International XML Database Symposium (XSym 2004), p. 128 -142. Toronto, Canada, August 2004. M. Mani, D. Lee, R. R. Muntz. Semantic Data Modeling Using XML Schemas. In Proceedings of the 20 th International Conference on Conceptual Modeling (ER 2001), p. 149 -163. Yokohama, Japan, November 2001. A. Sengupta, S. Mohan, R. Doshi. XER - Extensible Entity Relationship Modeling. In Proceedings of the XML 2003 Conference, p. 140 -154. Philadelphia, USA, December 2003. G. Psaila. ERX: A Conceptual Model for XML Documents. In Proceedings of the 2000 ACM Symposium on Applied Computing, p. 898 -903. Como, Italy, March 2000. D. W. Embley, S. W. Liddle, R. Al-Kamha. Enterprise Modeling with Conceptual XML. In Proceedings of the 23 rd International Conference on Conceptual Modeling (ER 2004), p. 150165. Shanghai, China, November 2004. G. Dobbie, W. Xiaoying, T. W. Ling, M. L. Lee. ORA-SS: An Object-Relationship-Attribute Model for Semi-Structured Data. Technical Report, Department of Computer Science, National University of Singapore. December 2000 Martin Nečaský, Conceptual Modeling for XML: A Survey, In: Václav Snášel, Karel Richta, Jaroslav Pokorný (Ed. ), Proceedings of the DATESO 2006 Annual International Workshop on Databases, Texts, Specifications, and Objects, Desná — Černá Říčka, Czech Republic, April 2006, ISBN 80 -248 -1025 -5. 69

Appendice 2 Reverse engineering da linguaggio Cobol 70

Esempio di reverse engineering - linguaggio Cobol • • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 COD-UOMO PIC X(5). 10 DESC-UOMO PIC X(80). 05 DONNA REDEFINES UOMO. 10 TIPO-RECORD PIC X. 10 COD-DONNA PIC 9(5). 10 DESC-DONNA PIC X(80). 01 AMMINISTRAZIONE. 05 REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-DUMMY PIC X(6). 10 DES-REGIONE PIC X(80). 05 PROVINCIA REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-DUMMY 2 PIC X(3). 10 DES-PROVINCIA PIC X(80). 05 COMUNE REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-COMUNE PIC X(3). 10 DES-COMUNE PIC X(80). 01 PERSONA-AMMINISTRAZIONE. 05 LEGAME. 10 COD-PERSONA PIC X(5). 10 COD-AMMIN PIC X(3). 71

Es. reverse engineering da linguaggio Cobol • • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 COD-UOMO PIC X(5). 10 DESC-UOMO PIC X(80). 05 DONNA REDEFINES UOMO. 10 TIPO-RECORD PIC X. 10 COD-DONNA PIC 9(5). 10 DESC-DONNA PIC X(80). 01 NASCITA. 05 REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-DUMMY PIC X(6). 10 DES-REGIONE PIC X(80). 05 PROVINCIA REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-DUMMY 2 PIC X(3). 10 DES-PROVINCIA PIC X(80). 05 COMUNE REDEFINES REGIONE. 10 COD-REGIONE PIC X(3). 10 COD-PROVINCIA PIC X(3). 10 COD-COMUNE PIC X(3). 10 DES-COMUNE PIC X(80). 01 PERSONA-NASCITA. 05 LEGAME. 10 COD-PERSONA PIC X(5). 10 COD-AMMIN PIC X(3). 72

• • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 10 05 DONNA 10 10 10 01 NASCITA. 05 REGIONE. 10 10 10 05 PROVINCIA 10 10 05 COMUNE 10 10 01 PERSONA-NASCITA. 05 LEGAME. 10 10 Es. linguaggio Cobol COD-UOMO PIC X(5). DESC-UOMO PIC X(80). REDEFINES UOMO. TIPO-RECORD PIC X. COD-DONNA PIC 9(5). DESC-DONNA PIC X(80). COD-REGIONE COD-DUMMY PIC X(6). DES-REGIONEPIC X(80). REDEFINES REGIONE. COD-REGIONE COD-PROVINCIA COD-DUMMY 2 DES-PROVINCIA REDEFINES COD-REGIONE COD-PROVINCIA COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). PIC X(3). COD-PERSONA COD-NASCITA PIC X(5). PIC X(3). PIC X(80). REGIONE. PIC X(3). Persona Codice Cognome Donna Uomo 73

• • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 10 05 DONNA 10 10 10 01 NASCITA. 05 REGIONE. 10 10 10 05 PROVINCIA 10 10 05 COMUNE 10 10 01 PERSONA-NASCITA. 05 LEGAME. 10 10 COD-UOMO PIC X(5). DESC-UOMO PIC X(80). REDEFINES UOMO. TIPO-RECORD PIC X. COD-DONNA PIC 9(5). DESC-DONNA PIC X(80). COD-REGIONE COD-DUMMY PIC X(6). DES-REGIONEPIC X(80). REDEFINES REGIONE. COD-REGIONE COD-PROVINCIA COD-DUMMY 2 PIC X(3). DES-PROVINCIA REDEFINES COD-REGIONE COD-PROVINCIA COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). PIC X(3). COD-PERSONA COD-NASCITA PIC X(5). PIC X(3). PIC X(80). REGIONE. PIC X(3). Regione Codice Nome Persona Codice Cognome Donna Es. linguaggio Cobol Uomo 74

• • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 10 05 DONNA 10 10 10 01 NASCITA. 05 REGIONE. 10 10 10 05 PROVINCIA 10 10 05 COMUNE 10 10 01 PERSONA-NASCITA. 05 LEGAME. 10 10 COD-UOMO PIC X(5). DESC-UOMO PIC X(80). REDEFINES UOMO. TIPO-RECORD PIC X. COD-DONNA PIC 9(5). DESC-DONNA PIC X(80). COD-REGIONE COD-DUMMY PIC X(6). DES-REGIONEPIC X(80). REDEFINES REGIONE. COD-REGIONE COD-PROVINCIA COD-DUMMY 2 PIC X(3). DES-PROVINCIA REDEFINES COD-REGIONE COD-PROVINCIA COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). PIC X(3). COD-PERSONA COD-NASCITA PIC X(5). PIC X(3). PIC X(80). REGIONE. PIC X(3). Provincia Codice Nome Persona Codice Cognome Donna Es. linguaggio Cobol (anni 50’) Uomo in Regione Codice Nome 75

• • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 10 05 DONNA 10 10 10 01 NASCITA. 05 REGIONE. 10 10 10 05 PROVINCIA 10 10 05 COMUNE 10 10 01 PERSONA-NASCITA. 05 LEGAME. 10 10 Comune Codice Nome Persona Codice Cognome Donna Uomo Es. linguaggio Cobol (anni 50’) COD-UOMO PIC X(5). DESC-UOMO PIC X(80). REDEFINES UOMO. TIPO-RECORD PIC X. COD-DONNA PIC 9(5). DESC-DONNA PIC X(80). COD-REGIONE COD-DUMMY PIC X(6). DES-REGIONEPIC X(80). REDEFINES REGIONE. COD-REGIONE COD-PROVINCIA COD-DUMMY 2 PIC X(3). DES-PROVINCIA REDEFINES COD-REGIONE COD-PROVINCIA COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). PIC X(3). COD-PERSONA COD-NASCITA PIC X(5). PIC X(3). in Provincia Codice Nome PIC X(3). PIC X(80). REGIONE. PIC X(3). in Regione Codice Nome 76

• • • • • • • • DATA DIVISION. WORKING-STORAGE SECTION. 01 PERSONA. 05 UOMO. 10 10 05 DONNA 10 10 10 01 NASCITA. 05 REGIONE. 10 10 10 05 PROVINCIA 10 10 05 COMUNE 10 10 01 PERSONA-NASCITA. 05 LEGAME. 10 10 Persona nato Codice Cognome Donna Uomo Comune Codice Nome Es. linguaggio Cobol COD-UOMO PIC X(5). DESC-UOMO PIC X(80). REDEFINES UOMO. TIPO-RECORD PIC X. COD-DONNA PIC 9(5). DESC-DONNA PIC X(80). COD-REGIONE COD-DUMMY PIC X(6). DES-REGIONEPIC X(80). REDEFINES REGIONE. COD-REGIONE COD-PROVINCIA COD-DUMMY 2 PIC X(3). DES-PROVINCIA REDEFINES COD-REGIONE COD-PROVINCIA COD-COMUNE PIC X(3). DES-COMUNE PIC X(80). PIC X(3). COD-PERSONA COD-NASCITA PIC X(5). PIC X(3). in Provincia Codice Nome PIC X(3). PIC X(80). REGIONE. PIC X(3). in Regione Codice Nome 77

Regola generale • Anche in Cobol occorre trovare traccia nelle strutture linguistiche delle astrazioni presenti. • Vediamo alcuni casi • 1. Campo composto (Esempio di aggregazione) • 02 DATA_DI_EMISSIONE 03 ANNO_DI_EMISSIONE 03 MESE_DI_EMISSIONE 03 GIORNO_DI_EMISSIONE E’ tradotto in un attributo DATA composto di GIORNO, MESE, ANNO. 78

Clausola REDEFINES • Vediamo il caso • 01 EMPLOYEE – 02 CODE PIC X(7) – 02 JOB_TYPE PIC X – 02 DATA-OF-WORKER • 03 WEEK_HOURS – 02 DATA_OF_SECRETARY REDEFINES DATA_OF_WORKER • 03 LEVEL PIC 9 – 04 TELEPHONE PIC 9(7) • Qui la clausola REDEFINES esprime la presenza di una generalizzazione come nell’esempio di alcune trasparenze fa’, in questo caso tra EMPLOYEE e WORKER, SECRETARY. 79

Visti i “trucchi” che permette il Cobol, le possibi rappresentazioni e corrispondenti trasformazioni sono molte…… • 01 REPORT_DI_CAPITOLO – – – 02 CODE 02 DESCRIPTION 02 CENTRO_DI_COSTO 02 DIVISIONE 02 RESPONSIBLE PIC 9(4) PIC X(30) 9(3) 9(2) X(30) Con ulteriore specifica del significato dei campi: Se il codice e’ tra Allora il record si riferisce a 1000 e 9999 100 e 999 Un Capitolo di bilancio Un Centro di costo 1 e 99 Una Divisione 80

Per ulteriori approfondimenti • C. Batini et al. Conceptual Database Design, Benjamin and Cummings, 1992 • In biblioteca 81