Ci sono varie obiezioni contro l'espansione del matrimonio "convenzionale", "come-Dio-intende" o "un Uomo, una Donna" ma, per quello che mi riguarda, i più pragmatici sono gli amministratori che tali matrimoni dovrebbero gestirli dal punto di vista burocratico.
Per esser sinceri: il sistema non è 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 così 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 così 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 è il mio lavoro. E' probabilmente molto costoso e vi sono probabilmente milioni di documenti già pronti che dovrebbero essere riciclati o bruciati invece di essere usati. O forse è semplice. Non lo so. La vera domanda dal mio punto di vista è come memorizzare tali informazioni in un computer.
Alterare la struttura di un database per consentire una cosa come il matrimonio gay può essere facile o difficile a seconda di come il sistema è stato progettato all'inizio. Vediamo un po'.
Nota: A grande richiesta popolare il problema è adesso noto come 'Y2Gay'.
RiNota: 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, è semplicissimo sapere chi è sposato con una semplice query. Una semplice join fornirà chi è sposato con chi.
Problemi? E' una miniera d'oro per quanto riguarda le contraddizioni, informazioni duplicate e così 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 è Null o, ancora meglio, che succede se id_marito è 1078 (il fratello di Giorgio)? Possiamo immaginarci le risate. O forse no.
Due
Difficile da crederci, ma questa struttura è 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 ambiguità ma è un perfetto bersaglio per qualunque commento di tipo sessista/sciovinista. Inoltre: che succede se decidiamo di memorizzare altre informazioni relative al matrimonio in se stesso? Tipo, quando è 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 (molte, moltissime) informazioni relative al matrimonio? Tipo, dove è stato tenuto, i nomi dei testimoni, dettagli della licenza e così via? Io non mi sono mai sposato ma sono più che sicuro che i dettagli amministrativi sono parecchi. Se tutte queste informazioni sono attaccate alla tabella "Maschi" diventa un pò 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 è 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 già più senso. La tabella "Matrimoni" può avere anche più informazioni mentre le informazioni relative a "Maschi" e "Femmine" sono dove gli compete.
Ovviamente tutto il sistema è incredibilmente stupido e sciovinista. Uomini e Donne sono uguali, giusto? Quindi ogni cambiamento strutturale alla tabella Uomini dovrebbe essere riportata nella tabella Donne. In pratica significa 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. E 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'è un buon motivo per cui non ho semplicemente ignorato i passaggi da 1 a 6. E' che c'è un sacco di gente nel mondo che pensa in questo modo. Questo è il loro modo reale di pensare al concetto di "matrimonio". Questa gente non è in grado di capire che uomini e donne sono uguali, il risultato è che una cosa come il matrimonio gay provoca seri problemi di integrità referenziale nella loro testa. "Ma se sono tutti e due maschi, chi è 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 è sciovinista ma è sufficientemente intelligente e che potrebbe anche esistere da qualche parte. Questo schema è 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 è 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 più 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 - è stato relativamente complicato. Ma adesso abbiamo qualche cosa di diverso. Per consentire a un uomo di sposare un altro uomo o una donna un'altra donna, quello che dobbiamo fare è 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 è una relazione binaria, una persona non può sposare sè stessa.
E perchè no?
Ottima domanda. La maggioranza della gente risponderebbe che "è idiota". Il che significa che una risposta logica dovrebbe balzare subito alla mente. Ed ecco la mia.
Per rispondere è 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'è nessun interesse di questo tipo ed è semplicemente un vantaggio fiscale. Percui, sì, il matrimonio è 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 sè stessa. Sono quasi sicuro che tale controllo non entrerebbe mai in funzione, ma deve essere lì da qualche parte. Questo piccolo problema logico è in effetti il più grosso ostacolo.
Nove
Ovviamente, viviamo nel 21° secolo e come direbbe 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 può assumere solo i valori canonici di maschio o femmina è 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" conterrà i vari valori tipo "maschio", "femmina", "asessuato", "ermafrodita", "ignoto" e tutto lo spazio disponibile per ulteriori alterazioni, dato che, sicuramente, il concetto di sesso diventerà sempre più complicato via via che il tempo passa.
In effetti, l'intero concetto di genere/sesso è molto più complesso di così. Come sappiamo il concetto di "sesso" è strettamente biologico e si riferisce per lo più al tipo di organi che si trovano tra le gambe, mentre il concetto di genere è più mentale che altro. Quindi...
Dieci
"Umani"
id
nome
cognome
id_sesso (fk riferita a sessi.id)
id_genere (fk riferita a generi.id)
"Matrimoni"
id
partner-1 (fk riferita ad umani.id)
partner-2 (fk riferita ad umani.id)
data_matrimonio
data_divorzio
"Sessi"
id
descrizione
"Generi"
id
descrizione
Dove "generi" potrebbe includere maschio / femmina / ignoto / indeciso e così via. Ripensandoci, tutta questa discussione tra generi e sessi è stupida. Perchè non aggiungiamo un altro campo per identificare se qualcuno è un travestito oppure no...
Hey! Ferma tutto! Il punto cruciale di questa discussione non è 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, se supponiamo che viva in un paese dove il matrimonio gay sia proibito, ogni donna di tale paese ha il diritto di sposarmi. Ma ogni uomo non ha tale diritto, anzi, è 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 è 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 così via. Ed ogni volta la logica di gestione deve essere alterata e la complessità aumenta ("stai cercando di forzare l'unicità degli indirizzi di posta? be spero che tu ti sia ricordato di confrontare 'email_1' con 'email_2' ed 'email_3' e...").
Questo è un controllo che non è stato manco considerato per il momento. Bisogna assicurarsi che ogni individuo sia coinvolto in un solo matrimonio alla volta. Non si può 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 più un matrimonio. Non si può che A sia sposato con B ed allo stesso tempo B sia sposato con A. Questo creerebbe due separati matrimoni! E questo non si può!
E perché no?
Bella domanda. Cominciamo ad analizzarla con calma.
Poligamia.
Dire che un matrimonio può coinvolgere esattamente due persone è limitato come dire che un matrimonio deve essere solo tra uomini e donne. Perché un matrimonio non potrebbe coinvolgere più di 2 persone? E' altamente non-convenzionale e la parte psicologica di un matrimonio poligamico è complessa di suo. Dovete essere gente speciale per far funzionare un matrimonio a tre. Ma gente non-convenzionale e speciale è sempre esistita nel mondo reale, quindi perché non fare in modo che possa funzionare sia dal punto di vista elettronico e legale?
Qui secondo me "legale" è il vero blocco. Penso di essere nel giusto quando dico che molto del "legalesauro" globale è appositamente pensato per matrimoni di tipo binario più che per matrimoni eterosessuali. Questo non è 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 possibilità di "buchi" legislativi è 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 è già stato fatto) e gli argomenti contro non sono meglio degli argomenti contro il matrimonio gay ma gli ostacoli sono più grossi.
In ogni caso, IANAL e 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 è membro al massimo di un matrimonio. Questo è facile da forzare facendo in modo che partners.id_umano sia una chiave unica. Un matrimonio può 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 questo è 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 può 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 realtà 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 è molto più sofisticato. Un blob si forma quando almeno due persone si uniscono come "partners" e 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 avrà 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.
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 può architettare. Ma non senza introdurre annullamenti arbitrari nel sistema e pertanto discontinuità tra i vari matrimoni. Perché in questo caso il concetto di matrimonio non è solo una relazione binaria irriflessiva, è una relazione transitiva, irriflessiva binaria. Se A è sposato con B e B è sposato con C, allora A è 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 tanto meno ho idea di quale sorta di "universo trans-umano" potrebbe accomodarla. Questo è 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 è sposato con chiunque altro. Un matrimonio transitivo inizia creando una relazione binaria A-B, A sposa B. C può 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 risposarli 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 è necessario. C potrebbe anche decidere di sposare solo B.
Quello che abbiamo creato è una cosa chiamata un Grafo. Un grafo è una struttura matematica formata da punti (umani) ed una serie di linee (matrimoni) che uniscono i 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 è 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 più un altro punto è limitante ed abbiamo deciso di consentire ogni possibile combinazione di linee in ogni possibile configurazione. Il matrimonio tradizionale "binario" è ancora il più comune. Un triangolo (tre persone ciascuna sposate con gli altri due) può occasionalmente apparire. Ma, in teoria, ogni possibile figura o forma può 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 è discutibile ma la ragione della loro esistenza non esiste più. Non siamo più limitati a matrimoni binari. Chiaramente, ogni possibile combinazione può essere costruita usando una combinazione di matrimoni binari.
Giusto?
Senza perdere generalità, si potrebbe fare in modo che id_partner_1 è sempre un numero inferiore a id_partner_2, questo renderebbe le ricerche assai più semplici perché l'ordine non ha più importanza. Il matrimonio può essere molte cose, ma di certo è commutativo. Se A è sposato con B, allora B è sposato con A.
Giusto?
Epilogo
Bene, è cominciato con una idea riguardo eguaglianza dei diritti di matrimonio e SQL ed è 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 è considerato, legalmente, inferiore all'altro (per esempio nel caso in cui uno dei partner riceva le proprietà 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 più 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?
