« XEADでリバースエンジニアリング | トップページ | 生産管理システムのレファレンスモデル近日公開 »

2007.05.09

インポート機能をさっそくバージョンアップ

 先日公開したXEADを早くもバージョンアップした。「XEADファイルのインポート機能」に含まれていた重大なバグ(テーブル定義の更新処理に関するもの)の修正と、「CREATE TABLE文のインポート機能」の使い勝手の改善である。後者では、(1)特定名のフィールドについてデータモデル上で非表示設定できるようにするとともに、(2)CREATE TABLE文上のデータタイプをXEADのデータタイプの初期値として取り込めるようにした。それぞれについて、もう少し補足しよう。

Image070509

(1)スタンプ属性等をモデル上で非表示とする
 実装されたテーブルには、「レコード更新日時」などのいわゆる「スタンプ属性」が含まれることがある。それらはデータ管理上必要なものではあるが、データモデルとして眺める際にはちょっと目障りだ。

 上手い具合に、スタンプ属性はデータベース全体で同一のフィールド名が与えられていることが多い。そこで、上図のようにフィールド名を指定することで、それらがどのテーブルに含まれていようともフィールド属性の「モデル上で表示」がオフに設定されるようにした。

(2)CREATE TABLE文からデータタイプを取り込む
 CREATE TABLE文上で記述されているデータタイプを、XEADのデータタイプとして取り込めるようにした。フィールドのデータ型や桁数もインポートされるようになったということだ。

 ただし、前回のエントリーで説明したように、これらは本来は異なる概念である点に注意が必要だ。XEADでのデータタイプの典型例を示すと次のようになる。

データタイプ 基本データ型 桁数 SQLのデータタイプ
商品番号   String      6 CHAR(6)
顧客番号   String      6 CHAR(6)
摘要     String     256 VARCHAR(256)
1桁区分   String      1 CHAR(1)
フラグ    Boolean      1 BOOLEAN
数量・金額  Number     11.2 NUMBER(11.2)

 ここからわかるようにXEADのデータタイプは、SQLのデータタイプとは部分的に重複しながらも独立した概念である。SQLのデータタイプとして同一でも、業務上の意味が異なれば、XEAD上ではそれらは異なるデータタイプとして認識される。たとえば、同じ「CHAR(6)」であっても、XEAD上では「商品番号」と「取引先番号」とは異なるデータタイプである。

 この見方がさまざまな局面で利いてくる。まず、テーブル関連を定義する際に、外部キー(FK)とこれに対応する相手テーブルの識別キー(PK,SK)とが、同一のデータタイプのフィールドで構成されていることが要求される。結果的に、縁もゆかりもない項目間でテーブル関連が定義されることを防げる。

 また、データタイプのレベルで桁数を変更することで、それが指定されているすべてのフィールドの桁数を一瞬で変更できるという効果もある。たとえば、商品番号を6桁から8桁に変えたいのであれば、「商品番号」のデータタイプ上で変えるだけでよい。いくつのフィールド定義が関係していようと、それらは桁数については「商品番号」のデータタイプをダイナミックに参照しているためだ。(パネルイメージ上の桁数まで自動的に変わればいいとは思うが、残念ながらそれはできない)

 先週公開したバージョンでは、CREATE TABLE文からデータタイプを取り込むことはしていなかった。ここまで説明したように、両者が似て非なる概念だからだ。

 ところが、300以上のテーブルを含むデータベースのCREATE TABLE文を取り込んでみてわかったのだが、XEAD上でデータタイプをあらためて設定する労力が半端ではない。また、テーブル定義として重要なはずのフィールド桁数が設定されないというのはあまりにも中途半端だ。

 そういうわけで、せいぜい同一のSQLのデータタイプにもとづいてXEADのデータタイプを初期設定できるようにした。本来ならば上記のように設定されるべきデータタイプが、次のように初期設定される。

データタイプ 基本データ型 桁数 SQLのデータタイプ
CHAR(6)    String      6 CHAR(6)
VARCHAR(256) String     256 VARCHAR(256)
CHAR(1)    String      1 CHAR(1)
BOOLEAN    Boolean     1 BOOLEAN
NUMBER(11.2) Number     11.2 NUMBER(11.2)

 データタイプの体系を作り変えて設定し直す必要があるとしても、この状態を起点にしたほうがよほど楽だ。

 じっさいのところ、CREATE TABLE文のインポート機能は使ってみるとじつに面白い。試しに、手近の既存システムのデータベースをデータモデル化してみてほしい。設計者が何を考えていたか(また何を考えていなかったか)がよくわかる。DB設計に興味がある技術者なら夢中になれること請け合いだ。

|

« XEADでリバースエンジニアリング | トップページ | 生産管理システムのレファレンスモデル近日公開 »

コメント

CREATE TABLE文のインポートは、インポート元ファイルの識別子
が「.txt」でなければいけないのですね。
RDBMSの種類によれば、「.sql」というテキスト形式のファイル
へと出力するツールを持っている物もあるので、「.sql」
という識別子も対象にして頂ければと考えています。

また、キー構成のインポートにて「PRIMARY KEY」から始まる
CREATE TABLEの派生文では、キー構成としてインポート出来ない
のですね。。。

触った時に少し感じたことを、書かせて頂きました。

投稿: 上條 靖芳 | 2007.05.10 17:14

上条さま

.sqlのファイル名への対応は次回のバージョンアップ版で反映するつもりです。それまでは処理前に拡張子を.txtに変更する形で対応していただければと思います。

うまくいかない例を示していただけませんか。CREATE TABLEもDBMS毎に微妙に方言があるので、そこらへんの問題かもしれません。

投稿: わたなべ | 2007.05.10 23:18

>うまくいかない例を示していただけませんか。CREATE TABLEも
>DBMS毎に微妙に方言があるので、そこらへんの問題かもし
>れません。

以下に例示いたします。なお、RDBMSはORACLEです。
-----------------------------------------------------------
CREATE TABLE 規模ドライバ評価値
(
規模要因略号 CHAR(4) NOT NULL,
判定基準レベル NUMBER(1,0) NOT NULL,
判定値 NUMBER(3,2),
説明 VARCHAR2(128),
更新日付 DATE,
PRIMARY KEY (規模要因略号, 判定基準レベル) USING INDEX
STORAGE( BUFFER_POOL DEFAULT)
NOLOGGING
)
STORAGE( BUFFER_POOL DEFAULT)
NOCACHE
NOLOGGING
/


CREATE TABLE コストドライバ判定値
(
モデル区分 CHAR(1) NOT NULL,
分類コード CHAR(1) NOT NULL,
コスト要因略号 CHAR(4) NOT NULL,
判定基準レベル NUMBER(1,0) NOT NULL,
判定値 NUMBER(3,2),
説明 VARCHAR2(2048),
更新日付 DATE,
PRIMARY KEY (モデル区分, 分類コード, コスト要因略号, 判定基準レベル) USING INDEX
STORAGE( BUFFER_POOL DEFAULT)
NOLOGGING
)
STORAGE( BUFFER_POOL DEFAULT)
NOCACHE
NOLOGGING
/
--------------------------------------------------------------

投稿: 上條 靖芳 | 2007.05.11 10:17

はうあっ、何の変哲もないステートメントなのに確かにPKが取り込まれませんね。トレースしてみたら、PRIMARY KEY句の後に、FOREIGN KEY句等が続いていないと、PRIMARY KEY句の内容が読み込まれないという変なロジックになってました(T_T) さっそく、sqlの拡張子も考慮した修正版(1.3.2)をアップしました。ご報告、感謝です。

投稿: わたなべ | 2007.05.11 19:39

わたなべさん、早速の対応、有り難うございます。

修正版(1.3.2)をダウンロードして、実験してみました。
拡張子「.sql」の対応および「PRIMARY KEY」の対応が
なされていることを確認いたしました。

これで現状(AS-IS)から理想(TO-BE)への対応を行い、
XEADを使用した客先提案に役立たせていただきます。

投稿: 上條 靖芳 | 2007.05.14 11:13

わたなべさんへ
TABLE名、フィールド名が英名で定義してある場合、CREATE TABLE文のインポートでは、テーブル名、フィールド名にインポートされ使いにくいのですが、こちらを、テーブルのIDおよび、フィールドの別名に入れるオプションを追加していただくことは、可能でしょうか?

投稿: MZ | 2007.05.22 00:46

こんな感じのSQLは取り込めませんか?
-- テーブル・ストアドプロシージャ・ビューの削除
DROP TABLE Company ;
DROP TABLE Shop ;

-- テーブルの作成
CREATE TABLE Company (
CompanyId BIGINT NOT NULL,
CompanyName VARCHAR(50)
) ;

CREATE TABLE Shop (
ShopId BIGINT NOT NULL,
ShopName VARCHAR(50),
CompanyId BIGINT
) ;


-- 主キー制約の作成
ALTER TABLE Company ADD CONSTRAINT PK_Company
PRIMARY KEY (CompanyId) ;


ALTER TABLE Shop ADD CONSTRAINT PK_Shop
PRIMARY KEY (ShopId) ;

-- インデックスの作成
ALTER TABLE Company
ADD CONSTRAINT UQ_Company_CompanyName UNIQUE (CompanyName) ;
ALTER TABLE Shop
ADD CONSTRAINT UQ_Shop_ShopName UNIQUE (ShopName) ;

-- 外部キー制約の作成
ALTER TABLE Shop ADD CONSTRAINT FK_Shop_Company
FOREIGN KEY (CompanyId) REFERENCES Company (CompanyId) ;

投稿: MZ | 2007.05.22 01:23

MZさま

ご提案ありがとうございます。テーブル名とフィールド名の設定オプションは良いアイデアなので、次のバージョン(1.3.3)で対応したいと思います。

DROPやALTER文については難しいところですねぇ。それらをインポートできるようにしたとしても、結局は中途半端なものになってしまいそうです。そのテーブルがすでに何らかの機能定義に入出力テーブルとして関連づけられている場合にはDROPを許可できないし、他のテーブルとの関連定義をともなっている場合にはキー定義のALTERを許可できません。

とりあえず、キー定義句をひととおり組み込んだCREATE文を用意する形で対応していただけますでしょうか。なおインポート処理においては、テーブル定義だけをひととおり作成した後に、最初からキー定義句をパースするというロジックになっているので、CREATE文中のテーブルの並び順を心配する必要はありません。

投稿: わたなべ | 2007.05.22 22:16

いつも勉強させていただいています。モデリングを行う時にコンセプトウェアを大変参考にさせていただいてます。今度、生産管理の仕事に着く事になったため生産管理のコンセプトウェアがアップされる事を心待ちにしています。ご予定の方いつごろになりますでしょうか?楽しみに待っています。

投稿: ひかさ | 2007.05.24 02:11

ひかささま

感想ありがとうございます。「CONCEPTWARE/生産管理」は各方面からせっつかれているのですが、公開予定は9月です。遅れていて申し訳ないのですが、なかなかいい感じになりつつあるので楽しみにしていてください(^^)

投稿: わたなべ | 2007.05.24 18:57

わたなべ様へ

いつも感服して、いろいろと利用させていただいています。
ところで、creat文の取り込みで、以下のように
2項目での親子関係の場合、
親子のリレーションが張られないようですが、
いかがでしょうか。

-------------start------------------------------------
--新規サブシステム - TA
CREATE TABLE TA(
A001 NUMBER(3) NOT NULL,
B001 CHAR(3) NOT NULL,
PRIMARY KEY(A001, B001)
);

--新規サブシステム - TB
CREATE TABLE TB(
L001 CHAR(3) NOT NULL,
M001 NUMBER(3) NOT NULL,
N001 NVARCHAR2(3) NOT NULL,
PRIMARY KEY(L001, M001, N001),
FOREIGN KEY(M001, L001) REFERENCES TA (A001, B001)
);

---------------end---------------------------------

投稿: MSJ | 2007.05.27 13:16

MSJさま

確かにこの例では親子関係が生成されませんね。さっそく次のバージョン(1.3.4)で対応しようと思います。ご報告感謝です。

投稿: わたなべ | 2007.05.28 13:57

わたなべ様へ
PCが壊れて、新しいPCを買ったらOSが、windows vistaでした。
申し訳ないのですがinstallerをvista対応してもらえないでしょうか?

投稿: MZ | 2007.07.13 17:05

MZさま

了解です。調査のうえ、次の版で対応しようと思います。

投稿: わたなべ | 2007.07.17 09:55

渡辺様。
いつも拝見させていただいています。

インポート機能を試しているのですがなかなかうまくいきません。
ツールより生成されるCreate Tableを元にいろいろと手で修正を加えながら試しているのですが一部列のみインポートされる状態です。
ロジックの観点から注意したほうがよい点などアドバイスいただければ幸いです。

使用しているDBはSQL Server2005です。
修正前のデータは下記のようなものです。

USE [aaa]
GO
/****** オブジェクト: Table [dbo].[ASSIGN_PARTSINFO] スクリプト日付: 09/29/2007 18:56:37 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[ASSIGN_PARTSINFO](
[PARTSINFO_ID] [int] IDENTITY(1,1) NOT NULL,
[ATTACHED_TYPE_ID] [int] NOT NULL,
[LIST_ORDER_INDEX_ID] [int] NOT NULL,
[PARENT_BM_PARTSNUMBER_ID] [int] NOT NULL,
[BM_PARTSNUMBER_ID] [int] NOT NULL,
[ITEM_TYPE_CD] [nchar](1) NOT NULL,
[PAGE_ID] [int] NULL,
[CORRECTION_QUANTITY] [int] NULL,
[TYPE_ID] [int] NULL,
[LIST_INDEX] [nchar](3) NULL,
[TARGET_DATE] [datetime] NULL,
[FUI_FLG] [bit] NULL,
CONSTRAINT [PK_ASSIGN_PARTSINFO] PRIMARY KEY CLUSTERED
(
[PARTSINFO_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

投稿: 黒龍 | 2007.09.29 19:32

黒龍さま

 下のようであれば取り込まれます。カギカッコを丸カッコに、データタイプを大文字に、また、一部のデータタイプを変更してあります。

CREATE TABLE ASSIGN_PARTSINFO (
PARTSINFO_ID INTEGER NOT NULL,
ATTACHED_TYPE_ID INTEGER NOT NULL,
LIST_ORDER_INDEX_ID INTEGER NOT NULL,
PARENT_BM_PARTSNUMBER_ID INTEGER NOT NULL,
BM_PARTSNUMBER_ID INTEGER NOT NULL,
ITEM_TYPE_CD CHAR(1) NOT NULL,
PAGE_ID INTEGER NULL,
CORRECTION_QUANTITY INTEGER NULL,
TYPE_ID INTEGER NULL,
LIST_INDEX CHAR(3) NULL,
TARGET_DATE DATE NULL,
FUI_FLG BOOLEAN NULL,
CONSTRAINT PK_ASSIGN_PARTSINFO PRIMARY KEY (PARTSINFO_ID)
);

 インポート処理で認識されるデータタイプを以下に示します。データタイプがまだ足りないし、大文字でなければいけないというのも気の利かない仕様ですね。改善する必要がありそうです。

INTEGER
TINYINT
SMALLINT
MEDIUMINT
BIGINT
REAL
DOUBLE
FLOAT
DECIMAL
NUMERIC
NUMBER
ENUM
CHAR
DATE
TIME
BLOB
TEXT
SET
BOOLEAN

投稿: わたなべ | 2007.10.03 10:10

早速の返信ありがとうございます。
なるほど。そういった仕組みだったんですね。この情報があればそれほど苦労せず取り込めそうです。
ありがとうございました。

よろしくお願いします。

投稿: 黒龍 | 2007.10.03 17:51

いつもお世話になっております。

早速試してみたところほとんどのテーブルは問題なく取り込めましたが一部おかしなデータがありました。
すばらしい機能で感謝感激です。

検証中に変わった現象を見ました。ごくシンプルなテーブルなのですがPRIMARY KEYの判断をミスしてしまうようです。

該当するSQLを添付します。
CREATE TABLE ADDITIONAL_INFO_DEFAULTSET_MT (
TARGET_PARTSNAME_ID INTEGER NOT NULL,
FUI_FLG BOOLEAN NULL,
EXPENDABLE_PARTS_FLG BOOLEAN NULL,
CONSUME_PARTS_FLG BOOLEAN NULL,
REGULAR_REPLACE_PARTS_FLG BOOLEAN NULL,
TARGET_PARTSNAME VARCHAR(4000) NULL,
CONSTRAINT PK_ADDITIONAL_INFO_DEFAULTSET_MT PRIMARY KEY (TARGET_PARTSNAME_ID)
);

関連はCreate文で書かないといけないんですね・・・。感嘆には変換できそうにないので今のところ未検証です^^;

投稿: 黒龍 | 2007.10.03 20:37

黒龍さま

現象を確認しました。修正版を近日公開します。データタイプとしても、INT,NCHAR,BIT等も追加し、データタイプの小文字表記にも対応しました。ご報告、ありがとうございました。

投稿: わたなべ | 2007.10.04 10:47

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: インポート機能をさっそくバージョンアップ:

« XEADでリバースエンジニアリング | トップページ | 生産管理システムのレファレンスモデル近日公開 »