DB設計について

あくまで参考までに。色々な情報が追加されるかと思いますので、ここから拡張することをおすすめします。
ホテルの予約サイトのDB設計において、オーナーとユーザーの判断ができるようにするには、テーブルとカラムを以下のように設計することができます。

まず、usersテーブルを作成します。このテーブルには、以下のカラムを持たせます。

• id: ユーザーの一意のID
• email: ユーザーのメールアドレス
• password: ユーザーのパスワード (ハッシュ化されたもの)
• user_type: ユーザーのタイプ (オーナーまたは一般ユーザーを表す。例: 1=オーナー, 2=一般ユーザー)
• name: ユーザーの名前
• gender: 性別 (1=男子、2=女子)

性別のカラムについては、整数で表記することが求められているため、1=男子、2=女子という形で表現できます。これにより、性別を簡潔に表現することができます。

上記のようなテーブル設計を行うことで、ログイン時にuser_typeカラムを利用して、オーナーと一般ユーザーを判断することが可能となります。ログイン認証の処理において、user_typeカラムをチェックし、オーナーである場合は管理者権限を持たせるようにロジックを組むことができます。

データベース設計は多くの要素が関連するため、実際にはより複雑な設計が必要になることがあります。必要に応じて、ホテル情報、部屋情報、予約情報などのテーブルを追加し、リレーションを設定することで、全体の機能を実現できます。

DB設計ではなく、コード設計の範疇になりますが、A00001,B00001 の様にコードに意味を持たせる方法もあります。

今はジェンダー問題になりますが、昔は社員コードの末尾に　３が男性、７が女性のように付番するケースもありました。

尚、末尾をチェックデジットするのもその応用です。バーコードの末尾がチェックデジットです。

業務なのか研修なのかわかりませんが、私が設計する立場なら･･･という前提で回答します。

ログインをする時、オーナーとユーザーの判断ができるようにするためには、

オーナーとユーザーでシステムを分ける(サブシステム化。DBは共有するがプログラムは完全に分ける)ので判断する必要がありません。
オーナー側とユーザー側で要求される機能等が異なるので一つのシステムにする必要はありません。
一つにしてしまうとプログラムが煩雑になり色々と弊害(拡張性・保守性の低下、不具合・セキュリティホールの埋め込みなど)が出やすくなります。

どのようにテーブルとカラムを作ったらいいのでしょうか？

上記の通り、オーナーの属性とユーザーの属性は異なるので別のテーブルで管理します。
例えば、性別の話が出ていますが、ユーザーに性別は必要ですがオーナーの性別は業務上必要ないのではないでしょうか？

DB設計書の書き方の記事が少ない気がするのは気のせいでしょうか

DB設計書の書き方なんて会社はもちろんプロジェクトによって違うので一般的な書き方というものも特にないです。
設計書の書き方よりはデータモデリングなどについての記事の方が参考になるかと思います。