이벤트 관리에 적용된 소셜 그래프
이벤트 관리의 세계에서는 참가자 간의 관계를 아는 것이 중요하지 않습니다. 액세서리 디테일: 기억에 남는 경험을 정리하는 열쇠입니다. 그는 누구입니까? 누구의 친구? 테이블에서 어떤 전 파트너 쌍을 분리해야 합니까? 어느 동료 같이 앉고 싶어할까요?
In 이벤트를 플레이하세요,
이러한 질문에 대한 답변은 다음과 같습니다. 완전한 소셜 그래프 그 너머의 모양
52가지 관계 유형 10개의 카테고리로 그룹화되어 있으며 각 카테고리에는 숫자 가중치가 있습니다.
그것은에서 간다 -1.0 (적) 아 1.0 (더 강한 가족 유대).
이 그래프는 지능형 좌석, 감지 등의 고급 기능을 지원합니다.
충돌 및 초대 제안.
이 기사에서 찾을 수 있는 내용
- 10가지 가중치 카테고리로 구성된 52가지 관계 유형
- 9단계의 관계 강화 시스템(RelationshipStrength)
- 자동 양방향성 및 역 유형 계산
- 상태 워크플로우: PENDING, ACCEPTED, REJECTED
- 지능형 그룹화를 위한 커뮤니티 감지
- 테이블 충돌을 방지하기 위한 충돌 감지
- 소셜 그래프 기반 지능형 좌석 배치
- 자동 초대 제안
- D3.js를 사용한 대화형 시각화
10개 카테고리의 52개 관계 유형
시스템의 핵심은 열거형(enum)이다 TipoRelazione, 정의하는 값 객체
두 사용자 사이에 가능한 모든 링크. 각 유형에는 무게 (무게) 어때요?
중요성과 표시 이름 사용자 인터페이스용.
범주는 핵가족부터 조직 관계, 관계까지 다양합니다.
부정적인.
TIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
GENITORE 1.00 Genitore
FIGLIO 1.00 Figlio/a
CONIUGE 1.00 Coniuge
PARTNER 0.95 Partner
GEMELLO 0.95 Gemello/a
FRATELLO 0.90 Fratello
SORELLA 0.90 SorellaTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
NONNO 0.85 Nonno
NONNA 0.85 Nonna
NIPOTE_DI_NONNI 0.85 Nipote (di nonni)
ZIO 0.70 Zio
ZIA 0.70 Zia
NIPOTE_DI_ZII 0.70 Nipote (di zii)
CUGINO_PRIMO 0.60 Cugino/a di Primo Grado
CUGINO_SECONDO 0.40 Cugino/a di Secondo Grado
CUGINO_TERZO 0.30 Cugino/a di Terzo GradoTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
SUOCERO 0.70 Suocero
SUOCERA 0.70 Suocera
GENERO 0.75 Genero
NUORA 0.75 Nuora
COGNATO 0.60 Cognato
COGNATA 0.60 CognataTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
PADRINO 0.65 Padrino
MADRINA 0.65 Madrina
FIGLIOCCIO 0.65 Figlioccio/a
PATRIGNO 0.60 Patrigno
MATRIGNA 0.60 Matrigna
FIGLIASTRO 0.55 Figliastro
FIGLIASTRA 0.55 Figliastra
FRATELLASTRO 0.55 Fratellastro
SORELLASTRA 0.55 SorellastraTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
GENITORE_ADOTTIVO 0.95 Genitore Adottivo
FIGLIO_ADOTTIVO 0.95 Figlio/a Adottivo/a
FRATELLO_ADOTTIVO 0.80 Fratello/Sorella Adottivo/a
FRATELLO_CONSANGUINEO 0.70 Fratello Consanguineo
SORELLA_CONSANGUINEA 0.70 Sorella Consanguinea
BISNONNO 0.65 Bisnonno/a
PRONIPOTE 0.65 Pronipote
PROZIO 0.50 Prozio/aTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
MIGLIORE_AMICO 0.85 Migliore Amico/a
AMICO_STRETTO 0.80 Amico/a Stretto/a
AMICO 0.50 Amico/a
COMPAGNO_CLASSE 0.40 Compagno/a di Classe
CONOSCENTE 0.30 Conoscente
COLLEGA 0.30 Collega
VICINO 0.25 Vicino/aTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
DIRIGENTE 0.60 Dirigente
RESPONSABILE 0.50 Responsabile
DIPENDENTE 0.40 Dipendente
COLLABORATORE 0.35 Collaboratore
CONSULENTE 0.35 Consulente
STAGISTA 0.30 StagistaTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
PRESIDENTE 0.70 Presidente
VICEPRESIDENTE 0.65 Vicepresidente
SEGRETARIO 0.60 Segretario
TESORIERE 0.60 Tesoriere
MEMBRO_DIRETTIVO 0.55 Membro del Direttivo
CONSIGLIERE 0.50 Consigliere
ASSOCIATO 0.40 Associato/Socio
VOLONTARIO 0.35 VolontarioTIPO PESO NOME VISUALIZZAZIONE
----------------------------------------------------
NEMICO -1.00 Nemico/a
RIVALE -0.50 Rivale
EX_CONIUGE -0.30 Ex Coniuge
EX_PARTNER -0.20 Ex Partner
SCONOSCIUTO 0.00 Sconosciuto/a
이러한 세분성을 통해 시스템은 채권 유형뿐만 아니라
또한 그 강도. 에이 MIGLIORE_AMICO (0.85) 무게는 거의 a와 비슷합니다.
FRATELLO (0.90), 반면 CONOSCENTE (0.30) 영향이 크다
알고리즘 결정이 열등합니다.
관계의 무게와 힘
각 관계에는 다음과 같은 수치적 가중치가 있습니다. -1.0 e 1.0.
시스템은 이 연속 값을 이산 규모로 변환합니다. 9개 레벨
힘 열거형을 통해 RelationshipStrength, 인터페이스에서 사용됨
사용자는 그래프에서 모서리의 색상 및 두께 표시기를 표시합니다.
LIVELLO RANGE PESO DESCRIZIONE
-----------------------------------------------------
VERY_STRONG >= 0.80 Molto Forte
STRONG >= 0.60 Forte
MODERATE >= 0.40 Moderata
WEAK >= 0.20 Debole
VERY_WEAK > 0.00 Molto Debole
NEUTRAL == 0.00 Neutrale
SLIGHTLY_NEGATIVE >= -0.30 Leggermente Negativa
NEGATIVE >= -0.60 Negativa
VERY_NEGATIVE < -0.60 Molto Negativa
방법 getStrength() 열거형의 TipoRelazione 변환을 수행합니다
자동. 예를 들어, CONIUGE (가중치 1.0) 반환 VERY_STRONG,
하는 동안 NEMICO (가중치 -1.0) 반환 VERY_NEGATIVE. 이 매핑
시각화의 기본: 아치 VERY_STRONG 나는
굵은 선과 따뜻한 색상으로 표현되었으며, 호는 NEGATIVE 나는
빨간색으로 점선으로 표시되었습니다.
무게는 다음 방법을 통해 사용자가 수동으로 조정할 수도 있습니다.
regolaPeso(double nuovoPeso). 예를 들어 주최자는 더 낮은 수준을 원할 수 있습니다.
두 친척이 사이가 좋지 않은 경우 가족 관계의 부담, 또는
특히 가까운 동료의 부담을 높인다.
UserRelationship 엔터티
집계 루트 RelazioneUtente 그래프에서 단일 관계를 나타냅니다.
사회적. 각 인스턴스는 두 명의 사용자를 유형, 체중 및 상태와 연결합니다. 테이블
relazioni_utenti 사용자 ID, 유형 및
성능 쿼리를 보장하기 위해 무게를 측정합니다.
RelazioneUtente (Aggregate Root)
├── id Long (auto-generated)
├── utenteId1 Long (FK → users)
├── utenteId2 Long (FK → users)
├── tipoRelazione TipoRelazione (enum)
├── peso Double (-1.0 a 1.0)
├── bidirezionale Boolean (auto-calcolato)
├── tipoRelazioneInversa TipoRelazione (auto-calcolato)
├── stato StatoRelazione (PENDING/ACCEPTED/REJECTED)
├── richiestaInviataDaUtenteId Long (chi ha inviato la richiesta)
├── richiestaInviataIl Instant (timestamp invio)
├── rispostaDataIl Instant (timestamp risposta)
├── note String (max 500 caratteri)
├── creatoIl Instant (audit)
├── aggiornatoIl Instant (audit)
└── versione Long (optimistic locking)
VINCOLI:
├── UniqueConstraint(utenteId1, utenteId2) → no duplicati
├── utenteId1 ≠ utenteId2 → no self-relation
└── peso ∈ [-1.0, 1.0] → range validato
팩토리 메소드를 통해 생성이 발생합니다. RelazioneUtente.crea(), 얼마나 유효한지
데이터는 관계 유형에서 자동으로 가중치를 계산하고 양방향성을 결정합니다.
초기 상태를 다음으로 설정합니다. PENDING.
자동 양방향성
모든 관계가 대칭적인 것은 아닙니다. 시스템은 관계 여부를 자동으로 결정합니다.
양방향인지, 그렇지 않은 경우 역방향 유형이 무엇인지. 이런 계산이 나오네요
생성자에서 RelazioneUtente 두 가지 개인 방법을 통해.
대칭 관계
일부 관계는 양방향으로 동일하게 유지됩니다. Alice가 친구 Bob의 경우 Bob은 자동으로 동일한 이름으로 Alice와 친구가 됩니다. 종류와 무게.
SIMMETRICHE (bidirezionale = true, tipo inverso = stesso tipo):
Familiari: CONIUGE, PARTNER, GEMELLO, FRATELLO, SORELLA,
FRATELLASTRO, SORELLASTRA, FRATELLO_CONSANGUINEO,
SORELLA_CONSANGUINEA, FRATELLO_ADOTTIVO,
CUGINO_PRIMO, CUGINO_SECONDO, CUGINO_TERZO,
COGNATO, COGNATA
Sociali: AMICO, AMICO_STRETTO, MIGLIORE_AMICO,
CONOSCENTE, COLLEGA, VICINO, COMPAGNO_CLASSE
Negativi: RIVALE, NEMICO, SCONOSCIUTO역 유형과의 방향 관계
다른 관계에는 본질적인 방향이 있습니다. 조상 의 밥, 그럼 밥이에요 아들 앨리스에 의해. 시스템이 자동으로 계산합니다. 그래프를 양방향으로 탐색하려면 역방향 유형을 사용하세요.
TIPO DIRETTO → TIPO INVERSO
--------------------------------------------
GENITORE → FIGLIO
FIGLIO → GENITORE
NONNO / NONNA → NIPOTE_DI_NONNI
ZIO / ZIA → NIPOTE_DI_ZII
SUOCERO / SUOCERA → GENERO (o NUORA)
PADRINO / MADRINA → FIGLIOCCIO
PATRIGNO → FIGLIASTRO
MATRIGNA → FIGLIASTRA
GENITORE_ADOTTIVO → FIGLIO_ADOTTIVO
FIGLIO_ADOTTIVO → GENITORE_ADOTTIVO
BISNONNO → PRONIPOTE
PRONIPOTE → BISNONNO
이 메커니즘은 그래프 탐색에 매우 중요합니다.
사용자의 모든 자녀를 찾으려면 관계만 찾을 필요가 없습니다.
tipoRelazione = GENITORE 그리고 사용자는 utenteId1, 그러나 또한
관계 tipoRelazione = FIGLIO 그리고 사용자는 utenteId2.
관계 상태: 양자 간 작업 흐름
각 관계는 요청과 유사한 양방향 확인 워크플로를 거칩니다. 소셜 네트워크에서의 우정. 이를 통해 양 당사자가 다음 사항에 동의함을 보장합니다. 그래프에서 관계가 활성화되기 전에 링크를 연결합니다.
┌─────────────────────────────────┐
│ │
▼ │
[CREAZIONE] → PENDING ──── accetta() ──→ ACCEPTED │
│ │
└──── rifiuta() ──→ REJECTED ─────┘
│
└── resetRichiesta()
(reinvia come PENDING)
REGOLE:
├── Solo il DESTINATARIO può accettare o rifiutare
├── Solo le richieste PENDING possono cambiare stato
├── Le richieste REJECTED possono essere reinviate
└── Le relazioni ACCEPTED sono visibili nel grafo- 보류 중 (확인 대기 중): 각 새 관계의 초기 상태입니다. 요청자가 요청을 보냈지만 수신자는 아직 응답하지 않았습니다. 관계는 아직 그래프에 표시되지 않으며 알고리즘에 영향을 주지 않습니다.
- 수락됨 (수락됨): 관계가 활성화되어 두 사용자 모두에게 표시됩니다. 그래프 시각화, 초대 제안, 충돌 감지 및 커뮤니티 감지에 사용됩니다.
- 거부됨 (거부됨): 수신자가 요청을 거부했습니다. 관계는 추적을 위해 데이터베이스에 남아 있지만 활성화되지는 않습니다. 신청자는 향후 다음을 통해 새로운 요청을 제출할 수 있습니다.
resetRichiesta().
신청자/수혜자 구분
분야 richiestaInviataDaUtenteId 요청을 보낸 사람을 추적합니다.
수신자는 자동으로 쌍의 다른 사용자가 됩니다. 받는 사람만
요청을 수락하거나 거부할 수 있습니다. 이 제약 조건은 다음에서 검증됩니다.
방법 validaDestinatario() 잘못된 사용자가 시도하면 예외가 발생합니다.
대답하다.
도메인 서비스: GestoreConlegamentiDomainService
여러 엔터티와 관련된 비즈니스 논리는 도메인에 의해 조정됩니다.
서비스 GestoreCollegamentiDomainService. 이 서비스는 생성을 처리합니다.
중복 유효성 검사 및 상태별 링크 필터링이 포함된 요청 수입니다.
creaRichiestaCollegamento(richiedenteId, destinatarioId, tipo):
1. VALIDAZIONE: richiedenteId ≠ destinatarioId
→ "Non puoi creare collegamento con te stesso"
2. RICERCA DUPLICATI: cerca relazione esistente (in entrambe le direzioni)
3. SE ESISTE:
├── PENDING → ERRORE "Richiesta già inviata e in attesa"
├── ACCEPTED → ERRORE "Collegamento già esistente"
└── REJECTED → RESET: reinvia come nuova PENDING
(aggiorna tipo, richiedente, timestamp)
4. SE NON ESISTE:
└── CREA: nuova RelazioneUtente con stato PENDING
이 서비스는 링크를 필터링하는 방법도 제공합니다. getCollegamentiAccettati()
관계만 반환 ACCEPTED, 하는 동안 getRichiesteRicevutePending()
e getRichiesteInviatePending() 들어오는 요청과 나가는 요청을 구별합니다.
계산 contaRichiesteRicevutePending() 파워 알림 배지
사용자 인터페이스에서.
커뮤니티 감지
소셜 그래프의 가장 강력한 기능 중 하나는 식별입니다. 자동 지역 사회 — 조밀하게 연결된 사람들의 그룹 그들 사이. ~ 안에 이벤트를 플레이하세요, 이는 가족, 친구 그룹 및 그룹을 자동으로 식별하는 것으로 해석됩니다. 직장 동료.
GRAFO DEGLI INVITATI (60 persone)
│
├── CLUSTER 1: Famiglia Sposo (12 persone)
│ ├── Genitori (peso 1.0)
│ ├── Fratelli e cognati (peso 0.6-0.9)
│ ├── Nonni (peso 0.85)
│ └── Zii e cugini (peso 0.3-0.7)
│
├── CLUSTER 2: Famiglia Sposa (14 persone)
│ ├── Genitori (peso 1.0)
│ ├── Sorelle e cognati (peso 0.6-0.9)
│ └── Parenti estesi (peso 0.3-0.7)
│
├── CLUSTER 3: Amici Università (8 persone)
│ ├── Amici stretti (peso 0.8)
│ ├── Compagni di classe (peso 0.4)
│ └── Collegamento inter-cluster: 2 persone
│ collegano Cluster 3 ↔ Cluster 4
│
├── CLUSTER 4: Colleghi Lavoro Sposo (10 persone)
│ ├── Dirigente (peso 0.6)
│ ├── Responsabile (peso 0.5)
│ └── Colleghi (peso 0.3)
│
├── CLUSTER 5: Amiche Sposa (8 persone)
│ └── Migliori amiche (peso 0.85)
│
└── CLUSTER 6: Vicini e Conoscenti (8 persone)
└── Vicini (peso 0.25) + Conoscenti (peso 0.3)
알고리즘은 연결 밀도와 에지 가중치를 분석하여 결정합니다.
그룹 간의 자연스러운 경계. 열거형의 도우미 메서드 TipoRelazione 그들은 촉진한다
분류: isFamilyRelation(), isSocialRelation(),
isOrganizationalRelation() e isCoreFamily() 확인할 수 있도록 해주세요
각 채권의 성격을 빠르게 파악하세요.
참조 테이블 TipoRelazioneDB 유형을 8가지 범주로 구성
형식적인: FAMIGLIA_STRETTA, FAMIGLIA_ALLARGATA, ACQUISITI,
SPIRITUALI, SOCIALI, PROFESSIONALI,
ORGANIZZATIVI e NEGATIVI. 각 유형에는 다국어 번역이 있습니다
(이탈리아어 및 영어) 및 인터페이스 드롭다운 표시 순서.
충돌 감지
충돌 감지는 계획 수립에 있어 중요한 기능입니다. 이벤트. 주최자가 여러 사람을 초대하면 시스템이 자동으로 분석합니다. 부정적인 관계에 있는 커플을 식별하기 위해 그들 사이의 관계.
ENDPOINT: GET /api/v1/relationships/conflicts?userIds=1,2,3,4,5
INPUT: Lista di ID utenti (partecipanti all'evento)
OUTPUT: Lista di ConflictAlert con severità
ALGORITMO:
1. Recupera tutte le relazioni dell'organizzatore
2. Filtra: solo relazioni tra utenti nella lista
3. Filtra: solo relazioni con peso < 0 (negative)
4. Per ogni conflitto, calcola la SEVERITA':
SEVERITA' RANGE PESO ESEMPIO
──────────────────────────────────────────
HIGH peso <= -0.70 NEMICO (-1.0)
MEDIUM peso <= -0.30 RIVALE (-0.5)
LOW peso < 0.00 EX_PARTNER (-0.2)
RESPONSE:
ConflictAlert {
userId1, userId2,
user1Name, user2Name,
relationshipType,
weight,
severity (HIGH | MEDIUM | LOW)
}
주최자는 상황에 따라 다른 색상으로 표시되는 알림 목록을 받습니다.
심각도: 빨간색 HIGH (ENEMY와 같은 심각한 충돌), 주황색
MEDIUM (RIVAL 또는 EX_SPOUSE와 같은 중간 정도의 충돌), 노란색은 LOW
(EX_PARTNER와 같은 가벼운 충돌) 이를 통해 귀하는 다음에 대해 정보를 바탕으로 결정을 내릴 수 있습니다.
좌석 배치.
사용 사례: 지능형 좌석
소셜 그래프의 가장 구체적인 사용 사례는 레이아웃 최적화입니다. 결혼식, 기업 만찬 및 지정된 좌석이 있는 기타 행사 중 테이블에서. 시스템은 커뮤니티 감지와 갈등 감지를 결합하여 성향을 제안합니다. 최적.
OBIETTIVI DELL'ALGORITMO:
├── MASSIMIZZARE: relazioni positive allo stesso tavolo
├── MINIMIZZARE: conflitti allo stesso tavolo
├── RISPETTARE: capacità massima per tavolo (8-10 persone)
└── PRESERVARE: nuclei familiari e gruppi di amici
ESEMPIO OUTPUT (8 tavoli da 8 persone):
TAVOLO 1 - "Famiglia Sposo (genitori)"
├── Sposo, Genitori Sposo, Fratello + Cognata
├── Nonni paterni
└── Score medio relazioni: 0.87 (VERY_STRONG)
TAVOLO 2 - "Famiglia Sposa (genitori)"
├── Sposa, Genitori Sposa, Sorella + Cognato
├── Nonni materni
└── Score medio relazioni: 0.85 (VERY_STRONG)
TAVOLO 5 - "Amici Università"
├── 8 amici con peso medio 0.65
└── Score medio relazioni: 0.65 (STRONG)
⚠ CONFLITTO EVITATO:
Marco (EX_CONIUGE, peso -0.3) e Laura
→ Assegnati a tavoli diversi (Tavolo 4 vs Tavolo 6)
→ Distanza fisica: 3 tavoli di separazione알고리즘은 단계적으로 진행됩니다. 먼저 커뮤니티 감지로 식별된 클러스터를 할당합니다. 기본 단위로 개인을 이동시켜 분포를 세분화하여 전체 점수를 확인하고 마지막으로 감지된 충돌이 동일하게 유지되는지 확인합니다. 지역. 주최자는 언제든지 제안을 무시할 수 있으며 시스템은 다시 계산합니다. 실시간 점수.
초대 제안
소셜 그래프를 사용하면 i와의 관계를 기반으로 새로운 손님을 제안할 수도 있습니다.
이미 참가자가 확정되었습니다. 엔드포인트 GET /api/v1/relationships/suggestions
소셜 네트워크를 분석하고 기존 그룹과 가장 잘 연결된 사람들을 식별합니다.
ENDPOINT: GET /api/v1/relationships/suggestions
?participantIds=1,2,3,4&minConnections=2&limit=10
ALGORITMO:
1. Per ogni partecipante confermato:
└── Recupera tutti i collegamenti ACCEPTED
2. Costruisci mappa candidati:
└── candidatoId → [lista connessioni con partecipanti]
└── ESCLUDI: già partecipanti
└── ESCLUDI: relazioni negative (peso < 0)
3. Per ogni candidato, calcola SCORE:
├── commonConnections = numero connessioni con partecipanti
├── avgWeight = peso medio delle connessioni
└── score = (commonConnections/5 * 0.40) + (avgWeight * 0.60)
^^^^^^^^^^^^^^^^^^^^
normalizzato a [0,1]
4. FILTRA: commonConnections >= minConnections
5. ORDINA: per score decrescente
6. LIMITA: a N risultati
ESEMPIO SUGGERIMENTO:
"Invita anche Marco Rossi"
├── Conosce 3 partecipanti (peso medio: 0.72)
├── Score: (0.6 * 0.40) + (0.72 * 0.60) = 0.672
└── Motivo: "Conosce 3 partecipanti (peso medio: 0.72)"채점 공식은 두 가지 요소의 균형을 맞춥니다. 40% 점수는 공통 연결 수(최대 5개로 정규화됨)를 기준으로 하며, 60% 그것은 관계의 평균 강도에 의해 결정됩니다. 이는 다음을 의미합니다. 친한 친구가 2명(가중치 0.80)인 사람이 더 높은 점수를 받는 것으로 나타났다. 단순한 지인이 3명인 1명(가중치 0.30).
D3.js를 사용한 시각화
관계 그래프는 인터페이스에서 시각적으로 렌더링됩니다.
이벤트를 플레이하세요
시각화를 통해 강제로 지시되는 D3.js 기반. 엔드포인트
GET /api/v1/relationships/graph 노드 + 가장자리 형식으로 데이터를 반환합니다.
도서관에서 예상됩니다.
GraphDataResponse {
"nodes": [
{
"id": "1",
"name": "Federico Calò (Tu)",
"degree": 12, // numero di connessioni
"cluster": null // community (futuro)
},
{
"id": "2",
"name": "Marco Rossi",
"degree": 5,
"cluster": null
}
],
"links": [
{
"source": "1",
"target": "2",
"weight": 0.80, // forza del legame
"type": "AMICO_STRETTO"
},
{
"source": "1",
"target": "3",
"weight": -0.50,
"type": "RIVALE"
}
]
}
Il GetRelationshipGraphQueryHandler 연결에서 시작하여 그래프를 작성합니다.
현재 사용자가 수락합니다. 각 노드에 대해 다음을 계산합니다. grado (정도),
즉, 시각화의 노드 크기를 결정하는 연결 수입니다.
현재 사용자는 표시 이름에 접미사 "(You)"로 강조 표시됩니다.
D3.js 시각화에서 그래프 속성은 시각적 개체에 매핑됩니다.
- 노드 크기: 정도에 비례 - 사용자의 연결이 많을수록 노드가 더 크게 나타납니다.
- 매듭 색상: 속한 클러스터 기준 — 동일한 커뮤니티에 대해 동일한 색상
- 아치의 두께: 무게에 비례 - 강한 관계에는 두꺼운 호가 있고, 약한 관계에는 얇은 호가 있습니다.
- 활 색상: 긍정적인 관계는 녹색, 부정적인 관계는 빨간색 점선으로 표시
- 노드 간 거리: 무게에 반비례 - 유대감이 강한 사람은 가까이 다가옵니다.
- 대화형 도구 설명: 호 위에 마우스를 올리면 관계 유형과 가중치가 표시됩니다.
국제화
관계 시스템은 완전한 현지화를 지원합니다. 테이블
stati_relazione 상태에 대한 설명을 제공합니다. 7개 언어
(IT, EN, FR, ES, DE, SV, PT), 표는 tipi_relazione 제안 이름
이탈리아어와 영어로 번역되었습니다. 방법 getDescrizioneLocalizzata(lingua)
사용자의 언어에 따라 올바른 문자열을 반환합니다.
STATO IT EN FR
─────────────────────────────────────────────────────────
PENDING In attesa di Waiting for En attente de
conferma confirmation confirmation
ACCEPTED Accettata Accepted Acceptée
REJECTED Rifiutata Rejected Refusée외부 손님 디렉토리
등록된 사용자 간의 그래프 외에도 이벤트를 플레이하세요
또한 간의 관계를 관리합니다. 외부 손님 — 가지고 있지 않은 사람들
플랫폼에 있지만 주최자가 초대하고 싶어하는 계정. 엔터티
RelazioneInvitatiEsterni 단순화된 세트로 이러한 연결을 모델링합니다.
10가지 유형의 관계.
TipoRelazioneTraInvitati:
├── CONIUGE (famiglia)
├── PARTNER (famiglia)
├── GENITORE (famiglia)
├── FIGLIO (famiglia)
├── FRATELLO (famiglia)
├── PARENTE (famiglia)
├── AMICO (sociale)
├── COLLEGA (sociale)
├── CONOSCENTE (sociale)
└── ALTRO
Helper methods:
├── isFamiglia() → true per CONIUGE/PARTNER/GENITORE/FIGLIO/FRATELLO/PARENTE
└── isVicino() → true per tutti i familiari + AMICO
기업은 다음을 보장합니다. 정식 순서 두 손님 사이에
(invitato_id_1 < invitato_id_2) 다른 방향으로 중복되는 것을 방지합니다.
두 손님 모두 동일한 사용자의 주소록에 속해야 하며 검증되어야 합니다.
팩토리 메소드에서 crea().
CQRS 아키텍처 및 REST API
전체 관계 시스템은 CQRS(Command Query Responsibility Segregation) 패턴을 따릅니다. 명령은 상태(요청 생성, 수락, 거부)를 수정하는 반면 쿼리는 부작용(그래프, 충돌, 제안) 없이 데이터를 읽습니다.
RelationshipGraphController
│
├── GET /api/v1/relationships/graph
│ └── Restituisce il grafo completo dell'utente
│ Response: GraphDataResponse { nodes[], links[] }
│
├── GET /api/v1/relationships/conflicts?userIds=1,2,3
│ └── Rileva conflitti tra gli utenti specificati
│ Response: ConflictAlertResponse[] {
│ userId1, userId2, user1Name, user2Name,
│ relationshipType, weight, severity
│ }
│
└── GET /api/v1/relationships/suggestions
?participantIds=1,2,3&minConnections=2&limit=10
└── Suggerisce invitati basandosi sulle connessioni
Response: InvitationSuggestionResponse[] {
userId, userName, profileImageUrl,
commonConnections, averageConnectionWeight,
score, reason
}
모든 쿼리는 성능을 최적화하기 위해 읽기 전용 트랜잭션에서 실행됩니다.
인증은 JWT를 통해 처리되며 각 엔드포인트는 ID를 확인합니다.
현재 사용자의 SecurityUtils.getCurrentUserIdOrThrow().
이벤트용 소셜 그래프가 필요한 이유는 무엇입니까?
잘 조직된 행사와 기억에 남는 행사의 차이는 세부적인 관계에 있습니다. 소셜 그래프 이벤트를 플레이하세요 관계형 데이터를 구체적인 결정으로 변환합니다: 어디에 앉을 것인지, 누구를 초대할 것인지, 방지하기 위해 충돌합니다. 52가지 관계 유형, 9가지 강도 수준 및 알고리즘 포함 커뮤니티 감지를 통해 시스템은 주최자에게 네트워크에 대한 전체 보기를 제공합니다. 손님과의 친목 - 모두 대화형 인터페이스 기반을 통해 이루어집니다. D3.js에서는 간단한 드래그 앤 드롭으로 그래프를 탐색할 수 있습니다.
다음 기사에서는 문서 및 첨부 파일 관리 시스템을 살펴보고 분석합니다. Play The Event가 이벤트와 관련된 계약서, 허가증, 송장 및 기타 파일을 구성하는 방법 버전 관리 및 세분화된 공유가 가능합니다.