In Sybase, users are not the same as schema names, but are a related set. A Sybase instance has many databases: master, model, tempdb, ... including application DBs. One user is each DB's DataBase Owner, dbo. Tables and other ovjects in the table can be owned by dbo or by a granted user. For that user, he sees his own tables if in name conflict with dbo, my_table_name is my_db_name.my_user_id.my_table_name first else my_db_name..my_table_name, but you can look at other users' tables if you use the long form and have permission. A DB has some system tables to store schema information, like syscomments holds the text of all sp among other things.
I use SQuirreL to peruse DB in a vendor-independent way using the always free JDBC jars. Sybase has them as JConnect in various revisions. I have to use old JConnect 2 for my hp roman8 character set. FreeTDS also works for most things, and supports MS SQL Server, too (MS bought it from Sybase and does some neat skins).
Sybase manages things by stored procedures, mostly, so expect to be executing something like sp_adduser. Lots of Sybase Manuals Online. SyBooks Online
Sybase DB seem to like "clustered index" tables, where a clustered index actually holds the table, really more like an indexed sequential file, and other indexes are like side tables with sorted lists of keys and row locations. Clustered index access is much faster, unless you can answer a query with another index and no table access. Space management on old Sybase tables demands a clustered index. Sybase tables work better if you update statistics often enough to keep them relevant, like after a big load. Most prod databases have only dbo tables. Dev and test DB might have user tables, so everyone can diverge their testing and schema. This requires all code to use unqualified table names, which is a problem if using tables in many db.
All users have access to tempdb to create ephemeral (connection life) #name tables (no qualifier needed, names guaranteed unique) or server-run tables with explicit names tempdb..whatever, name conflict quite possible but persistent between sessions, so you can create a table in one isql, run bcp to load it and use another isql to mod the real DB. TempDB has less logging and such, so it is faster. The query planner may generate tables there automatically, like for a union. Master has info on all users and db, model is used to make new DB as a template.
Sybase original tables have page not row locking, but to be competitive in bidding requirements with DB2, Oracle and such they later came up with tables that have row locking, which are surely a different beast.
Sybase has replication, very popular, where the logs are filtered, edited, abstracted and shipped to other DB. Overehead tothe feeding DB is low, just log file i/o, and there may be dedicated 'stable' servers to process the replication, which can go to many servers. The class case was a company with NY, London and Tokyo offices, where each had 2 db replicated around the ring, and changes anywhere go everywhere. Another popular configuration is to have one or more report DB, possibly with different indexes (more, which slows churn), so the reports do not slow the transactions.
Not that I am a certified Sybase DBA or anything.