It would be interesting to see this done.
I have a very quick look at OrientDB.
Personally, I'd step back from asking how to map SDB or anything else to OreintDb but to first think about how the unique features of OrientDB can be best used to store RDF. With an general sense of what the design is, looking at what existing bits and pieces provides is easier.
Specifically to the SDB point:
SDB translates parts of SPARQL queries to SQL. The SQL uses joins (for basic graph patterns) and leftjoin (or optional). So in lookign at OrientDB Iooked for joins given it calls itself a NoSQL database. The document suggests it's support for SQL is really that here is an SQL-like language for access to one table at a time.
The syntax is:
SELECT [<Projections>] FROM <Target> [WHERE <Condition>*] [ORDER BY <Fields>* [ASC|DESC]*] [LIMIT <MaxRecords>]
FROM <target> means no joins. In (full) SQL, that would be a list of tables.
That's not to say that OrientDB is unsuitable - just that expecting it to act as a specific engine for SQL may not be quite so straight forward.
Maybe TDB is a better starting point using OrientDB embedded. OreintDB may be an excellent indexing engine for either RDF stored verbosely (i.e. a layout of string, string, string for SPO even though it repeats strings) or RDF mapped to nodeid and a node table (normalized) , which is what TDB does.