++ E-R (entity-relationship) diagrams. I find it easier to look at boxses for each table follow the lines signifying relationships to other boxes. The "crows feet" can signify 1-to-many. The diagram is easier than reading a sequential list of SQL CREATE TABLE statements and making a mental note of "FOREIGN KEY" strings and mentally backtracking to the parent table.
++ swim lanes to show how the "state" of a system is supposed to change with "time". This can succinctly show how data "flows" without having to actually run a program and watch variables in a debugger to manually recreate the "swim lane" in your head.
++ truth tables to summarize combinations of valid/invalid business rules and associated side effects. A grid is easier than parsing a long (and often nested) list of if/then/else/switch statements.
As for UML, the notation never seems to be that succinct or helpful to me. On the surface level, it seems that UML (for code) should have the same return-on-investment as E-R (for db tables) but it doesn't in my experience.
I also wonder if there is a cultural component to UML usage. It doesn't seem like tech companies (such as Microsoft/Google/Amazon/Ubisoft/etc) internally use UML as a prerequisite step for building systems. On the other hand, I could see more UML usage at non-tech companies (such as banks/manufacturing/government) building line-of-business CRUD apps. Grady Booch (Booch & UML notation) did consulting about software methodology at non-tech companies so that may have been a factor.