aboutsummaryrefslogtreecommitdiff
path: root/scripts/graphviz-sql.sh
blob: 3a9bfa0d706df49d95a2acc0577dc60c616e5158 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/bin/sh -
# $Id$
#
# This uses the SQL::Translator package (aka "SQL Fairy") to parse
# a MYSQL schema and diagram the result using GraphViz.
#
# SQL::Translator appears to be pretty good at analyzing SQL, but is
# badly confused about how to format record labels in the "dot"
# language.  I should send the author a patch, but simplest solution
# for now is just to whack sqlt-graph's broken output into shape.
#
# On FreeBSD, SQL Fairy is /usr/ports/databases/p5-SQL-Translator.

for i in "$@"
do
  sqlt-graph --db MySQL --output-type canon --show-datatypes --show-constraints $i |
  perl -0777 -pe '
    s/\\\n//g;
    s/  +/ /g;
    s/\\\|/|/g;
    s/\\{([a-z0-9_]+)\|/${1}|{/gi;
    s/-\\ +//g;
    s/\\ \\l/|/g;
    s/\|\\l \\}/}/g;
    s/\|\\}/}/g;
    s/{\n/{\n\tedge [arrowtail=none, arrowhead=crow];\n/;
  ' |
  dot -Tps2 |
  ps2pdf - ${i%.sql}.pdf
done
size="11,8.5"; splines=true; ratio=fill; node [ shape=record ]; // Objects visible in left-to-right protocol node [ color=blue ]; self [ label="Self|{Preferences}" ]; parent [ label="Parent|{URI|TA|SIA Base}" ]; repo [ label="Repository|{URI|TA}" ]; child [ label="Child|{TA}" ]; biz_sign [ label="Business\nSigning Context|{Keypair|CertChain}" ]; route_origin [ label="Route\nOrigin|{AS Number}" ]; // Objects which left-right protocol sees as part of other // objects but which SQL needs to be separate for // normalization. addr_set [ label="Address\nPrefix", color=purple ]; // Objects created on the fly by the RPKI engine node [ color=green ]; ca [ label="CA|{Last CRL #|Next CRL Date|Last Issued Serial #|Last Manifest #|Next Manifest Date|SIA URI}" ]; ca_detail [ label="CA Detail|{CA Private Key Handle|CA Public Key|Latest CA Certificate|Manifest EE Private Key Handle|Manifest EE Public Key|Latest Manifest EE Certificate|Latest Manifest|Latest CRL}" ]; // Some question whether these objects need to be in database // per se or are just properties hanging on some other object // like ca or ca_detail. For manifests, we need last serial, // same as for CRL. roa [ label="ROA|{EE Certificate|ROA}" ]; // This one is a table of everything we have ever issued to // this child, not to be confused with what's -currently- // issued to this child. Some question whether this hangs off // ca or ca_detail, but we -think- hanging off of ca_detail is // correct because certificates are issued by a particular // keypair. child_cert [ label="Child CA Certificate" ]; // One-many mappings edge [ color=blue, arrowtail=none, arrowhead=crow ]; self -> biz_sign; biz_sign -> child; biz_sign -> parent; biz_sign -> repo; self -> child; self -> parent; repo -> parent; self -> route_origin; route_origin -> addr_set [ color=purple, arrowtail=none, arrowhead=crow ]; // This is many-many because each child is an entity, each CA // can have multiple children, and each child can hold certs // from multiple CAs (thanks, RobL). // ca -> child [ color=green, arrowtail=crow, arrowhead=crow ]; // One-many mappings edge [ color=green, arrowtail=none, arrowhead=crow ]; ca -> ca_detail; child -> child_cert; parent -> ca; ca_detail -> child_cert; ca_detail -> roa; // One-one mapping -- separate object to highlight dynamic nature edge [ color=green, arrowtail=none, arrowhead=none, style=solid ]; route_origin -> roa; } // Local Variables: // compile-command: "dot -Tps2 repository-engine-objects.dot | ps2pdf - repository-engine-objects.pdf" // End: