This is a cache of http://dbflute.seasar.org/ja/data/doc/harbor/schema-maihamadb.html. It is a snapshot of the page at 2024-11-01T00:42:06.132+0000.
maihamadb schema

Schema for maihamadb (h2)

generated from MAIHAMADB.PUBLIC

Table List

*Push 'tab' (primary tab order)
No. Alias Name Type ForeignTable ReferrerTable TableComment EntityName
1 会員 MEMBER TABLE MEMBER_STATUS, MEMBER_ADDRESS(AsValid), MEMBER_LOGIN(AsLatest) MEMBER_ADDRESS, MEMBER_FOLLOWING, MEMBER_FOLLOWING, MEMBER_LOGIN, MEMBER_SECURITY, MEMBER_SERVICE, MEMBER_WITHDRAWAL, PURCHASE
会員のプロフィールやアカウントなどの基本情報を保持する。
基本的に物理削除はなく、退会したらステータスが退会会員になる。
ライフサイクルやカテゴリの違う会員情報は、one-to-oneなどの関連テーブルにて。
Member
2 会員住所情報 MEMBER_ADDRESS TABLE MEMBER, REGION  
会員の住所に関する情報で、同時に有効期間ごとに履歴管理されている。
会員を基点に考えた場合、構造的には one-to-many だが、業務的な定型条件で one-to-one になる。このような構造を「業務的one-to-one」と呼ぶ!
有効期間は隙間なく埋められるが、ここでは住所情報のない会員も存在し、厳密には(業務的な) "1 : 0..1" である。
MemberAddress
3 会員フォローイング MEMBER_FOLLOWING TABLE MEMBER, MEMBER  
とある会員が他の会員をフォローできる。すると、フォローした会員の購入履歴が閲覧できる。
MemberFollowing
4 会員ログイン MEMBER_LOGIN TABLE MEMBER, MEMBER_STATUS   MemberLogin
5 会員セキュリティ情報 MEMBER_SECURITY TABLE MEMBER  
会員とは one-to-one で、会員一人につき必ず一つのセキュリティ情報がある
MemberSecurity
6 会員サービス MEMBER_SERVICE TABLE MEMBER, SERVICE_RANK  
会員のサービス情報(ポイントサービスなど)。
テストケースのために、あえて統一性を崩してユニーク制約経由の one-to-one を表現している。
MemberService
7 会員ステータス MEMBER_STATUS TABLE   MEMBER, MEMBER_LOGIN
会員のステータスを示す固定的なマスタテーブル。いわゆるテーブル区分値!
業務運用上で増えることはなく、増減するときはプログラム修正ともなうレベルの業務変更と考えられる。

こういった固定的なマスタテーブルには、更新日時などの共通カラムは定義していないが、業務上そういった情報を管理する必要性が低いという理由に加え、ExampleDBとして共通カラムでER図が埋め尽くされてしまい見づらくなるというところで割り切っている。実業務では統一的に定義することもある。
MemberStatus
8 会員退会情報 MEMBER_WITHDRAWAL TABLE MEMBER, WITHDRAWAL_REASON  
退会会員の退会に関する詳細な情報。
退会会員のみデータが存在し、"1 : 0..1" のパターンの one-to-one である。
共通カラムがあってバージョンNOがないパターン。
基本的に更新は入らないが、重要なデータなので万が一のために更新系の共通カラムも。
MemberWithdrawal
9 商品 PRODUCT TABLE PRODUCT_CATEGORY, PRODUCT_STATUS PURCHASE
 
Product
10 商品カテゴリ PRODUCT_CATEGORY TABLE PRODUCT_CATEGORY PRODUCT, PRODUCT_CATEGORY
商品のカテゴリを表現するマスタ。自己参照FKの階層になっている。
ProductCategory
11 商品ステータス PRODUCT_STATUS TABLE   PRODUCT
商品のステータスを表現する固定的なマスタ。
ProductStatus
12 購入 PURCHASE TABLE MEMBER, PRODUCT PURCHASE_PAYMENT
一つの商品に対する購入を表現する(購入履歴とも言える)。
実業務であれば購入詳細というテーブルを作り、「購入という行為」と「その中身(詳細)」を違う粒度のデータとしてそれぞれ管理するのが一般的と言えるでしょう。というか、注文とか請求とかそういうことを考え始めたらもっと複雑になるはずですが、ExampleDBということで割り切っています。
Purchase
13 購入支払 PURCHASE_PAYMENT TABLE PURCHASE  
購入に対する支払。
分割払いもできるのでmanyとなり、会員からの孫テーブルのテストができてうれしい。
PurchasePayment
14 地域 REGION TABLE   MEMBER_ADDRESS
主に会員の住所に対応する漠然とした地域。
かなりざっくりした感じではある。唯一の業務的one-to-oneの親テーブルのケース。
Region
15 サービスランク SERVICE_RANK TABLE   MEMBER_SERVICE
会員のサービスレベルを表現するランク。(ゴールドとかプラチナとか)
ServiceRank
16 退会理由 WITHDRAWAL_REASON TABLE   MEMBER_WITHDRAWAL
会員に選ばせる定型的な退会理由のマスタ。そういえば、これ表示順カラムがないですねぇ...
WithdrawalReason

(会員)MEMBER  (arrangeQuery=2)

会員のプロフィールやアカウントなどの基本情報を保持する。
基本的に物理削除はなく、退会したらステータスが退会会員になる。
ライフサイクルやカテゴリの違う会員情報は、one-to-oneなどの関連テーブルにて。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 会員ID MEMBER_ID INTEGER 10 MEMBER_ADDRESS(AsValid),
MEMBER_LOGIN(AsLatest) 
MEMBER_ADDRESS,
MEMBER_FOLLOWING,
MEMBER_FOLLOWING,
MEMBER_LOGIN,
MEMBER_SECURITY,
MEMBER_SERVICE,
MEMBER_WITHDRAWAL,
PURCHASE 
 
連番として自動採番される。会員IDだけに限らず採番方法はDBMS次第。
memberId Integer
2       o * 会員名称 MEMBER_NAME VARCHAR 100       
会員のフルネームの名称。
苗字と名前を分けて管理することが多いが、ここでは単純にひとまとめ。
memberName String
3     o   * 会員アカウント MEMBER_ACCOUNT VARCHAR 50       
ログインIDとして利用する。
昨今メールアドレスをログインIDとすることが多いので、あまり見かけないかも!?
memberAccount String
4       o * 会員ステータスコード MEMBER_STATUS_CODE CHAR 3 MEMBER_STATUS    MemberStatus
会員ステータスを参照するコード。
ステータスが変わるたびに、このカラムが更新される。
memberStatusCode String
5       o   正式会員日時 FORMALIZED_DATETIME TIMESTAMP 26, 6       
会員が正式に確定した(正式会員になった)日時。
一度確定したらもう二度と更新されないはずだ!
formalizedDatetime LocalDateTime
6           生年月日 BIRTHDATE DATE 10       
必須項目ではないので、このデータがない会員もいる。
birthdate LocalDate
7         * 登録日時 REGISTER_DATETIME TIMESTAMP 26, 6       
レコードが登録された日時。
会員が登録された日時とほぼ等しいが、そういった業務的な役割を兼務させるのはあまり推奨されない。といいつつ、このテーブルには会員登録日時がない...
仕様はどのテーブルでも同じなので、共通カラムの説明はこのテーブルでしか書かない。
registerDatetime LocalDateTime
8         * 登録ユーザ REGISTER_USER VARCHAR 200       
レコードを登録したユーザ。
会員テーブルであれば当然、会員自身であるはずだが、他のテーブルの場合では管理画面から運用者による登録など考えられるので、しっかり保持しておく。
registerUser String
9         * 更新日時 UPDATE_DATETIME TIMESTAMP 26, 6       
レコードが(最後に)更新された日時。
業務的な利用はあまり推奨されないと別項目で説明したが、このカラムはソートの要素としてよく利用される。
updateDatetime LocalDateTime
10         * 更新ユーザ UPDATE_USER VARCHAR 200       
レコードを更新したユーザ。
システムは誰が何をしたのかちゃんと覚えているのさ。
updateUser String
11         * バージョンNO VERSION_NO BIGINT 19       
データのバージョンを示すナンバー。
更新回数と等しく、主に排他制御のために利用される。
versionNo Long

(会員住所情報)MEMBER_ADDRESS

会員の住所に関する情報で、同時に有効期間ごとに履歴管理されている。
会員を基点に考えた場合、構造的には one-to-many だが、業務的な定型条件で one-to-one になる。このような構造を「業務的one-to-one」と呼ぶ!
有効期間は隙間なく埋められるが、ここでは住所情報のない会員も存在し、厳密には(業務的な) "1 : 0..1" である。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 会員住所ID MEMBER_ADDRESS_ID INTEGER 10       
会員住所を識別するID。
期間ごとに同じ会員のデータを保持することがあるため、これは単なるPKであってFKではない。
memberAddressId Integer
2     o+ o * 会員ID MEMBER_ID INTEGER 10 MEMBER     
会員を参照するID。
期間ごとのデータがあるので、これだけではユニークにはならない。有効開始日と合わせて複合ユニーク制約となるが、厳密には完全な制約にはなっていない。有効期間の概念はRDBでは表現しきれないのである。
memberId Integer
3     +o   * 有効開始日 VALID_BEGIN_DATE DATE 10       
一つの有効期間の開始を示す日付。
前の有効終了日の次の日の値が格納される。
validBeginDate LocalDate
4         * 有効終了日 VALID_END_DATE DATE 10       
有効期間の終了日。
期間の最後の日が格納される。基本的に、次の有効開始日の一日前の値となるが、次の有効期間がない場合は 9999/12/31 となる。
validEndDate LocalDate
5         * 住所 ADDRESS VARCHAR 200       
まるごと住所
address String
6       o * 地域ID REGION_ID INTEGER 10 REGION    Region
地域を参照するID。かなり漠然とした地域。
regionId Integer
7         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
8         * REGISTER_USER VARCHAR 200       
 
registerUser String
9         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
10         * UPDATE_USER VARCHAR 200       
 
updateUser String
11         * VERSION_NO BIGINT 19       
 
versionNo Long

(会員フォローイング)MEMBER_FOLLOWING

とある会員が他の会員をフォローできる。すると、フォローした会員の購入履歴が閲覧できる。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 会員フォローイングID MEMBER_FOLLOWING_ID BIGINT 19       
連番
memberFollowingId Long
2     o+ o+ * わたし MY_MEMBER_ID INTEGER 10 MEMBER     
気になった人がいて...勇気を振り絞った会員のID。
myMemberId Integer
3     +o o+ * あなた YOUR_MEMBER_ID INTEGER 10 MEMBER     
いきなりのアクションに...ちょっと心揺らいだ会員のID。
yourMemberId Integer
4       o * その瞬間 FOLLOW_DATETIME TIMESTAMP 26, 6       
ふりかえるとちょっと恥ずかしい気持ちになる日時
followDatetime LocalDateTime

(会員ログイン)MEMBER_LOGIN

ログインするたびに登録されるログイン履歴。
登録されたら更新されるも削除されることもない。さらには、登録する人もプログラムもはっきりしているので、(紙面の都合上もあって)ここでは共通カラムは省略している。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 会員ログインID MEMBER_LOGIN_ID BIGINT 19       
 
memberLoginId Long
2     o+ o * 会員ID MEMBER_ID INTEGER 10 MEMBER     
 
memberId Integer
3     +o o * ログイン日時 LOGIN_DATETIME TIMESTAMP 26, 6       
ログインした瞬間の日時。
同じ会員が同じ日時にログインはできない。(ユニーク制約で重複ログインできないようにしてある)
loginDatetime LocalDateTime
4         * モバイルログインフラグ MOBILE_LOGIN_FLG INTEGER 10      Flg
モバイル機器からのログインか否か。
mobileLoginFlg Integer
5       o * ログイン時会員ステータスコード LOGIN_MEMBER_STATUS_CODE CHAR 3 MEMBER_STATUS    MemberStatus
ログイン時の会員ステータス
loginMemberStatusCode String

(会員セキュリティ情報)MEMBER_SECURITY

会員とは one-to-one で、会員一人につき必ず一つのセキュリティ情報がある
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 会員ID MEMBER_ID INTEGER 10 MEMBER     
そのまま one-to-one を構成するためのFKとなる。
memberId Integer
2         * ログインパスワード LOGIN_PASSWORD VARCHAR 100       
ログイン時に利用するパスワード。
本当は良くないが、Exampleなのでひとまず暗号化していない。
loginPassword String
3         * リマインダ質問 REMINDER_QUESTION VARCHAR 50       
パスワードを忘れた際のリマインダ機能における質問の内容。
reminderQuestion String
4         * リマインダ回答 REMINDER_ANSWER VARCHAR 50       
パスワードを忘れた際のリマインダ機能における質問の答え。
reminderAnswer String
5         * リマインダ利用回数 REMINDER_USE_COUNT INTEGER 10       
リマインダを利用した回数。
これが多いと忘れっぽい会員と言えるが、そんなことを知ってもしょうがない。
reminderUseCount Integer
6         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
7         * REGISTER_USER VARCHAR 200       
 
registerUser String
8         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
9         * UPDATE_USER VARCHAR 200       
 
updateUser String
10         * VERSION_NO BIGINT 19       
 
versionNo Long

(会員サービス)MEMBER_SERVICE

会員のサービス情報(ポイントサービスなど)。
テストケースのために、あえて統一性を崩してユニーク制約経由の one-to-one を表現している。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 会員サービスID MEMBER_SERVICE_ID INTEGER 10       
独立した主キーとなるが、実質的に会員IDとは one-to-one である。
memberServiceId Integer
2     o o * 会員ID MEMBER_ID INTEGER 10 MEMBER     
会員を参照するID。ユニークなので、会員とは one-to-one の関係に。
memberId Integer
3       o * サービスポイント数 SERVICE_POINT_COUNT INTEGER 10       
購入したら増えて使ったら減る。
servicePointCount Integer
4       o * サービスランクコード SERVICE_RANK_CODE CHAR 3 SERVICE_RANK    ServiceRank
どんなランクがあるのかドキドキですね。
serviceRankCode String
5         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
6         * REGISTER_USER VARCHAR 200       
 
registerUser String
7         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
8         * UPDATE_USER VARCHAR 200       
 
updateUser String
9         * VERSION_NO BIGINT 19       
 
versionNo Long

(会員ステータス)MEMBER_STATUS

会員のステータスを示す固定的なマスタテーブル。いわゆるテーブル区分値!
業務運用上で増えることはなく、増減するときはプログラム修正ともなうレベルの業務変更と考えられる。

こういった固定的なマスタテーブルには、更新日時などの共通カラムは定義していないが、業務上そういった情報を管理する必要性が低いという理由に加え、ExampleDBとして共通カラムでER図が埋め尽くされてしまい見づらくなるというところで割り切っている。実業務では統一的に定義することもある。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 会員ステータスコード MEMBER_STATUS_CODE CHAR 3    MEMBER,
MEMBER_LOGIN 
MemberStatus
会員ステータスを識別するコード。
固定的なデータなので連番とか番号にはせず、データを直接見たときも人が直感的にわかるように、例えば "FML" とかの3桁のコード形式にしている。(3って何会員だっけ?とかの問答をやりたくないので)
memberStatusCode String
2         * 会員ステータス名称 MEMBER_STATUS_NAME VARCHAR 50       
表示用の名称。
国際化対応するときはもっと色々考える必要があるかと...ということで英語名カラムがないので、そのまま区分値メソッド名の一部としても利用される。
memberStatusName String
3         * 説明 DESCRIPTION VARCHAR 200       
会員ステータスそれぞれの説明。
区分値の一つ一つの要素に気の利いた説明があるとディベロッパーがとても助かるので絶対に欲しい。
description String
4     o   * 表示順 DISPLAY_ORDER INTEGER 10       
UI上のステータスの表示順を示すNO。
並べるときは、このカラムに対して昇順のソート条件にする。
displayOrder Integer

(会員退会情報)MEMBER_WITHDRAWAL

退会会員の退会に関する詳細な情報。
退会会員のみデータが存在し、"1 : 0..1" のパターンの one-to-one である。
共通カラムがあってバージョンNOがないパターン。
基本的に更新は入らないが、重要なデータなので万が一のために更新系の共通カラムも。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * MEMBER_ID INTEGER 10 MEMBER     
 
memberId Integer
2       o   退会理由コード WITHDRAWAL_REASON_CODE CHAR 3 WITHDRAWAL_REASON    WithdrawalReason
定型的な退会した理由を参照するコード。
何も言わずに退会する会員もいるので必須項目ではない。
withdrawalReasonCode String
3           退会理由入力テキスト WITHDRAWAL_REASON_INPUT_TEXT CLOB 2147483647       
会員がフリーテキストで入力できる退会理由。
もう言いたいこと言ってもらう感じ。サイト運営側としてはこういうのは真摯に受け止めて改善していきたいところ。
withdrawalReasonInputText String
4         * 退会日時 WITHDRAWAL_DATETIME TIMESTAMP 26, 6       
退会した瞬間の日時。
正式会員日時と違い、こっちは one-to-one の別テーブルで管理されている。
withdrawalDatetime LocalDateTime
5         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
6         * REGISTER_USER VARCHAR 200       
 
registerUser String
7         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
8         * UPDATE_USER VARCHAR 200       
 
updateUser String

(商品)PRODUCT

No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * PRODUCT_ID INTEGER 10    PURCHASE   
 
productId Integer
2       o * 商品名称 PRODUCT_NAME VARCHAR 50       
ExampleDBとして、コメントの少ないケースを表現するため、あえてコメントを控えている。
実業務ではしっかりとコメントを入れることが強く強く推奨される。「よりによってこのテーブルでやらないでよ!」あわわ、何も聞こえません〜
productName String
3     o   * 商品ハンドルコード PRODUCT_HANDLE_CODE VARCHAR 100       
これだけは書いておこう、商品を識別する業務上のコード。よく品番とか言うかもしれませんねぇ...
productHandleCode String
4       o * PRODUCT_CATEGORY_CODE CHAR 3 PRODUCT_CATEGORY     
 
productCategoryCode String
5       o * PRODUCT_STATUS_CODE CHAR 3 PRODUCT_STATUS    ProductStatus
 
productStatusCode String
6         * 定価 REGULAR_PRICE INTEGER 10       
 
regularPrice Integer
7         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
8         * REGISTER_USER VARCHAR 200       
 
registerUser String
9         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
10         * UPDATE_USER VARCHAR 200       
 
updateUser String
11         * VERSION_NO BIGINT 19       
 
versionNo Long

(商品カテゴリ)PRODUCT_CATEGORY

商品のカテゴリを表現するマスタ。自己参照FKの階層になっている。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 商品カテゴリコード PRODUCT_CATEGORY_CODE CHAR 3    PRODUCT,
PRODUCT_CATEGORY 
 
自分のテーブルの別のレコードからも参照される。
productCategoryCode String
2         * 商品カテゴリ名称 PRODUCT_CATEGORY_NAME VARCHAR 50       
 
productCategoryName String
3       o   親カテゴリコード PARENT_CATEGORY_CODE CHAR 3 PRODUCT_CATEGORY     
最上位の場合はデータなし。まさひく自己参照FKカラム!
parentCategoryCode String

(商品ステータス)PRODUCT_STATUS

商品のステータスを表現する固定的なマスタ。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 商品ステータスコード PRODUCT_STATUS_CODE CHAR 3    PRODUCT  ProductStatus
商品ステータスを識別するコード。
productStatusCode String
2         * 商品ステータス名称 PRODUCT_STATUS_NAME VARCHAR 50       
表示用の名称、英語名カラムがないのでそのままメソッド名の一部としても利用される。
productStatusName String
3     o   * 表示順 DISPLAY_ORDER INTEGER 10       
もう、ご想像の通りです。
displayOrder Integer

(購入)PURCHASE

一つの商品に対する購入を表現する(購入履歴とも言える)。
実業務であれば購入詳細というテーブルを作り、「購入という行為」と「その中身(詳細)」を違う粒度のデータとしてそれぞれ管理するのが一般的と言えるでしょう。というか、注文とか請求とかそういうことを考え始めたらもっと複雑になるはずですが、ExampleDBということで割り切っています。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * PURCHASE_ID BIGINT 19    PURCHASE_PAYMENT   
 
purchaseId Long
2     o+ o+ * 会員ID MEMBER_ID INTEGER 10 MEMBER     
会員を参照するID。
購入を識別する自然キー(複合ユニーク制約)の筆頭要素。
memberId Integer
3     +o o+ * 商品ID PRODUCT_ID INTEGER 10 PRODUCT     
あなたは何を買ったのか?
productId Integer
4     +o o+ * 購入日時 PURCHASE_DATETIME TIMESTAMP 26, 6       
購入した瞬間の日時。
purchaseDatetime LocalDateTime
5         * 購入数量 PURCHASE_COUNT INTEGER 10       
購入した商品の一回の購入における数量。
purchaseCount Integer
6       o * 購入価格 PURCHASE_PRICE INTEGER 10       
購入によって実際に会員が支払った(支払う予定の)価格。
基本は商品の定価に購入数量を掛けたものになるが、ポイント利用や割引があったりと必ずしもそうはならない。
purchasePrice Integer
7         * 支払完了フラグ PAYMENT_COMPLETE_FLG INTEGER 10      Flg
この購入に関しての支払いが完了しているか否か。
paymentCompleteFlg Integer
8         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
9         * REGISTER_USER VARCHAR 200       
 
registerUser String
10         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
11         * UPDATE_USER VARCHAR 200       
 
updateUser String
12         * VERSION_NO BIGINT 19       
 
versionNo Long

(購入支払)PURCHASE_PAYMENT

購入に対する支払。
分割払いもできるのでmanyとなり、会員からの孫テーブルのテストができてうれしい。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o o     * 購入支払ID PURCHASE_PAYMENT_ID BIGINT 19       
連番
purchasePaymentId Long
2       o * 購入ID PURCHASE_ID BIGINT 19 PURCHASE     
支払い対象の購入へのID
purchaseId Long
3       +o * 支払金額 PAYMENT_AMOUNT DECIMAL 10, 2       
支払った金額。さて、小数点なのはなぜでしょう?
paymentAmount BigDecimal
4       o+ * 支払日時 PAYMENT_DATETIME TIMESTAMP 26, 6       
支払ったときの日時
paymentDatetime LocalDateTime
5         * 支払方法コード PAYMENT_METHOD_CODE CHAR 3      PaymentMethod
手渡しや銀行振込など
paymentMethodCode String
6         * REGISTER_DATETIME TIMESTAMP 26, 6       
 
registerDatetime LocalDateTime
7         * REGISTER_USER VARCHAR 200       
 
registerUser String
8         * UPDATE_DATETIME TIMESTAMP 26, 6       
 
updateDatetime LocalDateTime
9         * UPDATE_USER VARCHAR 200       
 
updateUser String

(地域)REGION

主に会員の住所に対応する漠然とした地域。
かなりざっくりした感じではある。唯一の業務的one-to-oneの親テーブルのケース。
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 地域ID REGION_ID INTEGER 10    MEMBER_ADDRESS  Region
地域をしっかりと識別するID。
珍しく(固定的な)マスタテーブルとしては数値だが、Exampleなのでやはり色々なパターンがないとね、ってところで。
regionId Integer
2         * 地域名称 REGION_NAME VARCHAR 50       
地域を漠然と表す名称。
regionName String

(サービスランク)SERVICE_RANK

会員のサービスレベルを表現するランク。(ゴールドとかプラチナとか)
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * サービスランクコード SERVICE_RANK_CODE CHAR 3    MEMBER_SERVICE  ServiceRank
サービスランクを識別するコード。
serviceRankCode String
2         * サービスランク名称 SERVICE_RANK_NAME VARCHAR 50       
サービスランクの名称。
ゴールドとかプラチナとか基本的には威厳のある名前
serviceRankName String
3         * サービスポイント発生率 SERVICE_POINT_INCIDENCE DECIMAL 5, 3       
購入ごとのサービスポイントの発生率。
購入価格にこの値をかけた数が発生ポイント。ExampleDBとして数少ない貴重な小数点ありのカラム。
servicePointIncidence BigDecimal
4         * 新規受け入れ可能フラグ NEW_ACCEPTABLE_FLG INTEGER 10      Flg
このランクへの新規受け入れができるかどうか。
newAcceptableFlg Integer
5         * 説明 DESCRIPTION VARCHAR 200       
ランクに関する業務的な説明。
description String
6     o   * 表示順 DISPLAY_ORDER INTEGER 10       
UI上の表示順を表現する番号。
displayOrder Integer

(退会理由)WITHDRAWAL_REASON

会員に選ばせる定型的な退会理由のマスタ。そういえば、これ表示順カラムがないですねぇ...
No. PK ID UQ IX Not
Null
Alias Name Type Size ForeignTable ReferrerTable Classification ColumnComment PropertyName JavaType
1 o       * 退会理由コード WITHDRAWAL_REASON_CODE CHAR 3    MEMBER_WITHDRAWAL  WithdrawalReason
 
withdrawalReasonCode String
2         * 退会理由テキスト WITHDRAWAL_REASON_TEXT CLOB 2147483647       
退会理由の内容。
テキスト形式なので目いっぱい書けるが、そうするとUI側できれいに見せるのが大変でしょうね。
withdrawalReasonText String
3     o   * DISPLAY_ORDER INTEGER 10       
 
displayOrder Integer

Classification Definition

Classification Type Top Comment Definition
Flg implicit general boolean classification for every flg-column
Code Name Alias Comment Sisters
1 True Checked means yes true
0 False Unchecked means no false
MemberStatus table status of member from entry to withdrawal
Code Name Comment serviceAvailable shortOfFormalized
FML Formalized as formal member, allowed to use all service o  
WDL Withdrawal withdrawal is fixed, not allowed to use service    
PRV Provisional first status after entry, allowed to use only part of service o o
ServiceRank table rank of service member gets
Code Name Comment
PLT Platinum platinum rank
GLD Gold gold rank
SIL Silver silver rank
BRZ Bronze bronze rank
PLS Plastic plastic rank
Region table mainly region of member address
Code Name Comment
1 America  
2 Canada  
3 China  
4 Chiba  
WithdrawalReason table reason for member withdrawal
Code Name Comment
SIT Sit site is not kindness
PRD Prd no attractive product
FRT Frt because of furiten
OTH Oth other reasons
ProductCategory table category of product. self reference
Code Name Comment
MSC Music  
FOD Food  
HEB Herb of Food
MCD MusicCD of Music
INS Instruments of Music
ProductStatus table status for product
Code Name Comment
ONS OnSaleProduction  
PST ProductionStop  
SST SaleStop  
PaymentMethod implicit method of payment for purchase
Code Name Alias Comment recommended
HAN ByHand by hand payment by hand, face-to-face o
BAK BankTransfer bank transfer bank transfer payment  
CRC CreditCard credit card credit card payment  

ArrangeQuery List

MEMBER

MemberCQ

arrangeLogin() // Arrange member login query.
 
arrangeLoginByIdentity() // Arrange member login query by identity.
 

Procedure

Schema Diagram

maihamadb_erd

ER Diagram

Thanks

Created by dbflute(AutoGenerator)

x

Input the new column comment of

*required (saved in cookie)