Il Matrimonio Gay : Dal punto di vista della costruzione del database

NOTA IMPORTANTISSIMIA: Questo documento non e' farina del mio sacco, l'originale e' di Sam Hughes, trovate l'originale su http://qntm.org/, tradotto e ri-pubblicato con autorizzazione dell'autore.

Ci sono varie obiezioni contro l'espansione del matrimonio "convenzionale", "come-Dio-intende" - "un Uomo, una Donna" ma, per quello che mi riguarda, i piu' pragmatici sono gli amministratori che tali matrimoni dovrebbero gestirli dal punto di vista burocratico.

Per esser franchi, il sistema non e' costruito per gestirli. Tutti i moduli e la documentazione disponibile hanno spazi assegnati per il nome del marito e della moglie. Gli sposi devono accuratamente compilare tali moduli in stampatello negli appositi spazi e poi passare i documenti cosi' compilati ad impiegati depressi che procedono poi a re-inserire tali informazioni in computers usando appositi software di front-end che sono costruiti esattamente nello stesso modo. E quando premono il tasto "invio" le informazioni vengono inserite in un qualche database che semplicemente implode o vomita un qualche tipo di errore se si prova a fargli digerire qualche cosa di cosi' anomalo come due uomini che si amano abbastanza dal voler inviare una dichiarazione delle tasse unificata.

Parlando come una persona abituata ad aver a che fare con i computer, modificare i documenti cartacei non e' il mio lavoro. E' probabilmente molto costoso e vi sono probabilmente milioni di documenti gia' pronti che dovrebbero essere riciclati o bruciati invece di essere usati. O forse e' semplice. Non lo so. La vera domanda dal mio punto di vista e' come memorizzare tali informazioni in un computer.

Alterare la struttura di un database per consentire una cosa come il matrimonio gay puo' essere facile o difficile a seconda di come il sistema e' stato progettato all'inizio. Vediamo un po'.

Nota: A grande richiesta popolare il problema e' adesso noto come 'Y2Gay'.

Nota: questo documento si riferisce esclusivamente alle unioni civili riconosciute dallo stato. Organizzazioni religiose, chiese et similia possono ovviamente riconoscere, creare ed annullare ogni sorta di unione a cui possano pensare. Anche le chiese usano i database.

Uno

Cominciamo con un sistema veramente idiota, che sicuramente nessuno con un singolo neurone funzionante vorrebbe mai usare. Una roba tipo questa:


"maschi"
	id
	nome
	cognome
	data_di_nascita
	id_moglie (fk riferita a femmine.id - null se single)

"femmine"
	id
	nome
	cognome
	data_di_nascita
	id_marito (fk riferita a maschi.id - null se single)

Fantastico! Tutti sono sposati o meno ed e' semplicissimo sapere chi e' sposato con una semplice query. Una semplice join fornira' chi e' sposato con chi.

Problemi? E' una miniera d'oro per quanto riguarda le contraddizioni, informazioni duplicate e cosi' via. Se "Maschio" 45 (Giorgio) ha 'id_moglie' 699, allora "Femmina" 699 (Elisabetta) deve anche lei avere id_marito uguale a 45. Che succede se e' Null o, ancora meglio, che succede se id_marito e' 1078 (il fratello di Giorgio)? Possiamo immaginarci le risate. O forse no.

Due

Difficile da crederci, ma questa struttura e' un pochino meno idiota di quella precedente.


"Maschi"
	id
	nome
	cognome
	data_di_nascita
	id_moglie (fk riferita a femmine.id, null se single)

"Femmine"
	id
	nome
	cognome
	data_di_nascita

Questo elimina il problema di contraddizioni ed ambiguita', ma e' un perfetto bersaglio per qualunque commento di tipo sessista/sciovinista. Ed inoltre, che succede se decidiamo di memorizzare altre informazioni relative al matrimonio in se stesso? Tipo, quando e' iniziato?

Tre


"Maschi"
	id
	nome
	cognome
	data_di_nascita
	id_moglie (fk riferita a femmine.id, null se single)
	data_matrimonio	(null se single)

"Femmine"
	-come Due-

Ok, e che succede se divorziano?

Quattro


"Maschi"
	id
	nome
	cognome
	data_di_nascita
	id_moglie (fk riferita a femmine.id, null se single)
	data_matrimonio	(null se single)
	data_divorzio (null se single o non divorziato)

"Femmine"
	-come Due-

Ooookey, ma che succede se volessimo memorizzare *tante* informazioni relative al matrimonio? Tipo, dove e' stato tenuto, i nomi dei testimoni, dettagli della licenza e cosi' via? Io non mi sono mai sposato, ma sono piu' che sicuro che i dettagli amministrativi sono parecchi. Se tutte queste informazioni sono attaccate alla tabella "Maschi" diventa un po' problematico. Meglio memorizzare il tutto in una apposita tabella.

E chi divorzia potrebbe sposarsi di nuovo! Ma sono sicuro che i vari burocrati vorrebbero sempre i dati del matrimonio precedente insieme a quelli del nuovo matrimonio! Cancellare completamente le informazioni precedenti non e' una grande idea.

Cinque


"Maschi"
	id
	nome
	cognome
	data_di_nascita
	id_matrimonio (fk riferita a 'matrimoni.id' null se single)

"Femmine"
	id
	nome
	cognome
	data_di_nascita
	id_matrimonio (fk riferita a 'matrimoni.id' null se single)

"Matrimoni"
	id
	id_marito (fk riferita a maschi.id)
	id_moglie (fk riferita a femmine.id)
	data_matrimonio
	data_divorzio (null se mai divorziati)

Questa ha gia' piu' senso. La tabella "Matrimoni" puo' avere anche piu' informazioni mentre le informazioni relative a "Maschi" e "Femmine" sono dove gli compete.

Ovviamente tutto il sistema e' incredibilmente stupido e sciovinista. Uomini e Donne sono uguali, giusto? Quindi ogni cambiamento strutturale alla tabella Uomini dovrebbe essere riportata nella tabella "Donne". Dal punto di vista pratico significa anche che ogni cambiamento alla logica dell'applicazione che usa questa struttura deve essere applicata due volte, o come minimo ci deve essere un mastodontico switch per consentire al software di usare la tabella giusta. Ed ogni altra tabella in questo ipotetico database deve essere in grado di riferirsi alla tabella "maschi" o "femmine" a seconda del sesso della persona riferita.

E' completamente stupido farlo in questo modo. Tuttavia, c'e' un buon motivo per cui non ho semplicemente ignorato i passaggi da 1 a 6. Ed e' che c'e' un sacco di gente nel mondo che pensa in questo modo. Questo e' il loro modo reale di pensare al concetto di "matrimonio". Questa gente non e' in grado di capire che uomini e donne sono uguali, il risultato e' che una cosa come il matrimonio gay provoca seri problemi di integrita' referenziale nella loro testa. "Ma se sono tutti e due maschi, chi e' la moglie?". Patetico.

Sette


"Umani"
	id
	nome
	cognome
	data_di_nascita
	sesso (m o f)

"Matrimoni"
	id
	id_marito (fk riferita ad un maschio nella tabella umani)
	id_moglie (fk riferita ad una femmina nella tabella umani)
	data_matrimonio
	data_divorzio (null se mai divorziati)

Ecco che stiamo raggiungendo qualche cosa che non e' sciovinista ed e' sufficientemente intelligente che potrebbe anche esistere da qualche parte. Questo schema e' abbastanza logico, se assumiamo che voi viviate in un qualche paese cristiano. Ovviamente, se si vuole forzare una relazione un-uomo-una-donna con questo schema e' necessario aggiungere una qualche logica applicativa per fare in modo che id_marito punti effettivamente ad un "umano" di sesso maschile ed id_moglie ad uno di sesso femminile. E, suppongo, bisognerebbe anche fare delle verifiche che nessun maschio o femmina sposato/a improvvisamente cambi sesso. O, molto piu' prosaicamente, che nessuno cambi sesso e basta.

Fino a questo punto, implementare una cosa come il matrimonio gay in questo schema -trasformare il database in un gaybase- e' stato relativamente complicato. Ma adesso abbiamo qualche cosa di diverso. Per consentire as un uomo di sposare un altro uomo o una donna un'altra donna, quello che dobbiamo fare e' rimuovere queste funzioni di controllo logico. Per coerenza si potrebbe anche rinominare la struttura.

Otto


"Umani"
	-come sette-

"Matrimoni"
	id
	partner-1 (fk riferita ad umani.id)
	partner-2 (fk riferita ad umani.id)
	data_matrimonio
	data_divorzio

Con l'avvento del matrimonio gay tuttavia, abbiamo aggiunto un problema. La struttura precedente consente ad ogni umano di sposare un umano. Notare l'assenza dell'avverbio "differente" nella frase precedente. Il matrimonio e' una relazione binaria, una persona non puo' sposare se' stessa.

E perche' no?

Ottima domanda. La maggioranza della gente risponderebbe che "e' idiota". Il che significa che una risposta logica dovrebbe balzare subito alla mente. Ed ecco la mia.

Per rispondere a questa domanda e' necessario lasciare il campo dei database e guardare a quali privilegi e doveri lo stato di "matrimonio" conferisce ai suoi membri. Ci sono benefici legali, tipo l'essere autorizzati a visitare una persona in ospedale o avere potere decisionale nel caso il partner sia incapacitato. Questi sarebbero ovviamente inutili se siete il marito/moglie di voi stessi. Ma ci sono anche benefici fiscali, che sono ovviamente pensati per una coppia, i cui membri sono ovviamente interessati entrambi a livello legale/abitativo/riproduttivo. Se una persona sposa se stessa ovviamente non c'e' nessun interesse di questo tipo ed e' semplicemente un vantaggio fiscale. Percui, si', il matrimonio e' di tipo binario (o almeno, non unario. Matematicamente non-riflessivo).

Quindi, rimuovendo la limitazione maschio/femmina, bisognerebbe come minimo aggiungere una verifica a qualche livello logico per assicurare che i due id_partner siano, in effetti, diversi e che la gente non possa sposare se' stessa. Sono quasi sicuro che tale controllo non entrerebbe mai in funzione, ma deve essere li' da qualche parte. Questo piccolo problema logico e' in effetti il piu' grosso ostacolo.

Nove

Ovviamente, viviamo nel 21o secolo, e, come dirrebbe Eddie Izzard, "ci saranno parecchi ragazzi che useranno make-up in questo millennio". Sostanzialmente sto' parlando di voialtri "non-convenzionali", voialtri non-maschi-e-non-femmine. Il semplice fatto di avere 'sesso' che puo' assumere solo i valori canonici di 'maschio' o 'femmina' e' tanto miope quanto il pensare al matrimonio come maschio/femmina. Quindi...


umani
	id
	nome
	cognome
	data_di_nascita
	id.sesso (fk riferita a sessi.id)


sessi
	id
	descrizione

Dove "sessi" conterra' i vari valori tipo "maschio", "femmina", "asessuato", "ermafrodita", "ignoto" e tutto lo spazio disponibile per ulteriori alterazioni, dato che, sicuramente, il concetto di 'sesso' diventera' sempre piu' complicato via via che il tempo passa.

In effetti, l'intero concetto di genere/sesso e' molto piu' complesso di cosi'. Come sappiamo infatti, il concetto di "sesso" e' strettamente biologico e si riferisce per lo piu' al tipo di organi che si trovano tra le gambe, mentre il concetto di 'genere' e' piu'... mentale che altro. Quindi...

Dieci


"Umani"
	id
	nome
	cognome
	id_sesso (fk riferita a sessi.id)
	id_genere (fk riferita a generi.id)

(non riporto la tabella matrimoni per semplicita')

"Sessi"
	id
	descrizione

"Generi"
	id
	descrizione

Dove "generi" potrebbe includere 'maschio', 'femmina', 'ignoto', 'indeciso' e cosi' via. Ripensandoci, tutta questa discussione tra generi e sessi e' stupida. Perche' non aggiungiamo un altro campo per identificare se qualcuno e' un travestito oppure no...

Hey! Ferma tutto! Il punto cruciale di questa discussione non e' il dimostrare che la vostra forma fisica non indica chi potete o non potete sposare? Lasciamo perdere quindi del tutto il discorso 'sesso'.

Undici


Umani
	id
	nome
	cognome
	data_di_nascita

Matrimoni
	-come otto-

Meglio. Ora, aprendo una parentesi, si potrebbe discutere sul fatto che le leggi contro il matrimonio gay siano semplicemente scioviniste. Per esempio, supponiamo che io viva in un paese dove il matrimonio gay sia proibito, ora, ogni donna di tale paese ha il diritto di sposarmi. Ma ogni uomo non ha tale diritto, anzi, e' espressamente negato. Quindi in questo caso le donne hanno dei diritti che gli uomini non hanno. Stesso discorso ma al contrario per le donne ovviamente.

Le leggi contro il matrimonio gay introducono una linea di demarcazione molto ben definita tra due gruppi di persone nel mondo e dicono chiaramente che "ogni matrimonio deve attraversare questa linea". Ma ogni legge che discrimina tra uomini e donne e' chiaramente discriminatoria.

Parlando come un database designer, quei due campi 'partner1' e 'partner2' non mi piacciono molto. Ho lavorato in parecchi database con 'qualchecossa1' e 'qualchecosa2' ed ogni volta mi sono ritrovato a doverne aggiungere un '3' e poi un '4' e cosi' via. Ed ogni volta la logica di gestione deve essere alterata e la complessita' aumenta ("stai cercando di forzare l'unicita' degli indirizzi di posta? be spero che tu ti sia ricordato di confrontare 'email_1' con 'email_2' ed 'email_3' e...").

Questo e' un controllo che non e' stato manco considerato per il momento. Bisogna assicurarsi che ogni individuo sia coinvolto in un solo matrimonio alla volta. Non si puo' avere A sposato con B ed allo stesso tempo B sposato con C. E bisogna anche essere cauti. Bisogna assicurarsi che A sia partner_1 o partner_2 in al piu' un matrimonio. Non si puo' che A sia sposato con B ed allo stesso tempo B sia sposato con A. Questo creerebbe due separati matrimoni! E questo non si puo'!

E perche' no?

Bella domanda. Cominciamo ad analizzarla con calma.

Poligamia.

Dire che un matrimonio puo' coinvolgere esattamente due persone e' limitato come dire che un matrimonio deve essere solo tra uomini e donne. Perche' un matrimonio non potrebbe coinvolgere piu' di 2 persone? E' altamente non-convenzionale, e la parte psicologica di un matrimonio poligamico e' complessa di suo. Dovete essere gente speciale per far funzionare un matrimonio a tre. Ma gente non-convenzionale e 'speciale' e' sempre esistita nel mondo reale, quindi perche' non fare in modo che possa funzionare sia dal punto di vista elettronico e legale?

Qui' secondo me "legale" e' il vero blocco. Penso di essere nel giusto quando dico che molto del "legalesauro" globale e' appositamente pensato per matrimoni di tipo binario piu' che per matrimoni eterosessuali. Questo non e' semplice come cambiare un paio di parole in una legge esistente, qui si tratta di cambiare profondamente tutta o una vasta parte della legislazione esistente. Le possibilita' di "buchi" legislativi e' enorme. E tutto questo dovrebbe essere fatto per consentire ad una piccola minoranza di gente di fare come vogliono. Io penso che si dovrebbe fare (dove non e' gia' stato fatto) e gli argomenti contro non sono meglio degli argomenti contro il matrimonio gay, ma gli ostacoli sono piu' grossi.

In ogni caso, IANAL, IAADBE.

Dodici


"Umani"
	-come undici-

"Matrimoni"
	id
	data_matrimonio
	data_divorzio

"Partners"
	id
	id_umano (fk riferita ad umani.id)
	id_matrimonio (fk riferita a matrimoni.id)

Sulla carta, questa struttura dovrebbe essere relativamente semplice da creare e gestire. In pratica? Ah Ah Ah Ah!!! Questo schema in effetti crea 'blob' (no, non Binary Large Objects) di gente tutti collettivamente sposati tra di loro. Ogni umano e' membro al massimo di un matrimonio. Questo e' facile da forzare facendo in modo che partners.id_umano sia una chiave unica. Un matromonio puo' avere ogni numero di membri. Nessun tipo di codifica speciale per quello.

Per evitare i problemi di "matrimoni unari" e prevenire la gente di sposare se stessa, o, in questo schema, di creare un singolo-uomo blob, bisogna assicurarsi che ogni 'matrimonio' abbia come minimo due elementi, e questa e' l'unico problema di logica applicativa che questo schema introduce.

Fantastico.

Assumendo che i matrimoni siano statici.

Ecco che incontriamo il tipico problema introdotto quando si cerca di adattare '2-cose' in 'n-cose'. Fino ad ora, A e B erano sposati o no. Se il matrimonio tra i due veniva annullato si passava da 'sposati' a 'non sposati'. Ma qui siamo in una situazione dove un 'blob' si puo' creare tra A e B. Che succede se C si unisce al blob in una data seguente? Che data di matrimonio si mette in quel caso? E che succede se C decide di andarsene ma A e B restano?

Questo potrebbe essere semplice da risolvere in pratica. Basta annullare l'intero matrimonio e crearne uno nuovo con la nuova data. Ma sembra un accrocchio e suona complesso dal punto di vista legale. Alla fine, sembra che A e B abbiano avuto 3 matrimoni mentre in realta' ne hanno avuto solo uno.

Possiamo aggiustarlo?

Tredici


"Umani"
	-come undici-

"Matrimoni"
	id

"Partners"
	id
	id_umano (fk riferita ad umani.id)
	id_matrimonio (fk riferita a matrimoni.id)
	data_inizio
	data_fine (null se mai annullato)

Questo schema e' molto piu' sofisticato. Un blob si forma quando almeno due persone si uniscono come 'partners', se una terza persona si unisce, si crea un'altra linea nella tabella 'partners' senza alterare niente altro. Se qualcuno decide di andarsene, solo uno dei partners avra' un matrimonio annullato, senza alterare nessuno degli altri. Potrebbe anche decidere di tornare indietro, in quel caso sarebbe una nuova linea completamente. Tuttavia, questo significa che quella persona avrebbe due matrimoni discontinui anche se coinvolgono le stesse persone. E gli altri due avrebbero solo una linea di 'partners' quindi, tecnicamente, un solo matrimonio anche se in effetti sarebbero due. Nel caso di un matrimonio a due che cessasse di esistere, entrambi i partner dovrebbero andarsene allo stesso tempo, altrimenti rimarrebbe un matrimonio con un elemento "attivo". Tutto questo dovrebbe essere forzato nella logica applicativa.

Ed ovviamente, bisognerebbe anche assicurarsi che ad ogni momento una persona possa essere membro di un solo matrimonio alla volta.

Piuttosto complicato.

E mi posso immaginare anche altre complicazioni, tipo, che succede se A e B sono sposati tra di loro e C e D sono sposati tra di loro ed ad un certo punto A decide di sposare C? Bisognerebbe inventarsi un qualche sistema per cui B viene trascinato nel matrimonio tra A-C e D o viceversa. Oppure, per consistenza, che i due 'blob' diventino un unico blob a quattro.

Certo, si puo' architettare. Ma non senza introdurre annullamenti arbitrari nel sistema e pertanto discontinuita' tra i vari 'matrimoni'. Perche' in questo caso il concetto di matrimonio non e' solo una relazione binaria irriflessiva, e' una relazione transitiva, irreflessiva binaria. Se A e' sposato con B e B e' sposato con C, allora A e' sposato con C.

Giusto?

Quattordici (Orcaboia! Sta ancora andando avanti!)

Le ramificazioni legali di quello che sto per descrivere sono praticamente impossibili da concepire, almeno, io non ho idea di quali diritti e doveri una unione come questa potrebbe avere, ne' tantomeno ho idea di quale sorta di "universo trans-umano" potrebbe accomodarla. Questo e' lo schema di un ipotetico database di matrimoni per voialtri uomini del 31simo secolo.


"Umani"
	id
	nome
	cognome
	data_di_nascita

"Matrimoni"
	id
	id_partner_1 (fk riferita a umani.id)
	id_partner_2 (fk riferita a umani.id)
	data_inizio
	data_fine

In un matrimonio transitivo, chiunque e' sposato con chiunque altro. Un matrimonio transitivo inizia creando una relazione binaria A-B, A sposa B. C puo' unirsi a questo schema semplicemente sposando entrambi, quindi C sposa A e B aggiungendo due linee in 'matrimoni'. C potrebbe quindi divorziare da entrambi e quindi ri-sposarli entrambi.

Se C e D (sposati tra di loro) decidono di unirsi alla prima coppia, ognuno dei due dovrebbe sposare gli altri due. Quindi C dovrebbe sposare sia A che B e la stessa cosa vale per D. Il che potrebbe essere problematico, ma matrimoni di questa 'stazza' non credo siano molto comuni in ogni caso.

Ma questo non e' necessario. C potrebbe anche decidere di sposare solo B.

Quello che abbiamo creato e' una cosa chiamata un Grafo. Un grafo e' una struttura matematica formata da punti (umani) ed una serie di linee (matrimoni) che unisconoi punti in modo binario (una linea/matrimonio - due punti/umani). Fino ad ora abbiamo assunto che tutti i punti sono rossi (maschi) o blu (femmine) e che tutte le linee (matrimoni) devono necessariamente unire un punto rosso con un punto blu.

Da quel punto abbiamo anche concesso l'esistenza di punti di colore diverso, e concesso che il colore dei punti e' irrilevante e che le linee possono anche unire due punti indipendentemente dal colore.

Poi abbiamo raggiunto il punto in cui consentire un punto (persona) a connettersi con al piu un altro punto e' limitante ed abbiamo deciso di consentire ogni possibile combinazione di linee in ogni possibile configurazione. Il matrimonio tradizionale "binario" e' ancora il piu' comune. Un trangolo (tre persone ciascuna sposata con l'altra) puo' occasionalmente apparire. Ma, in teoria, ogni possibile figura o forma puo' connettersi con ogni altra forma possibile. E le linee possono apparire o sparire ad ogni momento.

Il fatto che esistano ancora id_partner_1 e id_partner_2 e' discutibile, ma la ragione della loro esistenza non esiste piu'. Non siamo piu' limitati a matrimoni binari. Chiaramente, ogni possibile combinazione puo' essere costruita usando una combinazione di matrimoni binari.

Giusto?

Senza perdere generalita', si potrebbe fare in modo che id_partner_1 e' sempre un numero inferiore a id_partner_2, questo renderebbe le ricerche assai piu' semplici perche' l'ordine non ha piu' importanza. Il matrimonio puo' essere molte cose, ma di certo e' commutativo. Se A e' sposato con B, allora B e' sposato con A.

Giusto?

Epilogo

Bene, e' cominciato con una idea riguardo eguaglianza dei diritti di matrimonio e SQL ed e' finito con teoria dei grafi, qualche cosa che, almeno io, non mi aspettavo. Matrimoni non-commutativi - o, penso, non-uguali - in cui uno dei partner e' considerato, legalmente, inferiore all'altro (per esempio nel caso in cui uno dei partner riceva le proprieta' dell'altro se questo dovesse morire ma non viceversa) suona come una progressione logica del tema adesso ed una ricetta per una nuova schiera di leggi repressive e discriminatorie un momento dopo. In effetti, pensandoci sopra, credo che anche matrimoni intransitivi potrebbero essere visti in questo modo.

Forse il sistema piu' semplice sarebbe proibire i matrimoni del tutto. Oppure, ancora meglio, dichiarare semplicemente tutti come sposati con tutti gli altri. Ma in questo caso, che cosa farebbero i database designer per tutto il giorno?

Davide Bianchi
03/12/2008 00:00

Commenti & Opinioni

Il Matrimonio Gay : Dal punto di vista della costruzione del database

Nessun messaggio this document does not accept new posts