web-dev-qa-db-ja.com

さまざまな種類のチケットのセットに基づいてチケットシステムをモデリングしますか？

「サポートチケット」の作成を可能にするプロジェクトに取り組んでいます。ただし、これらは修正が必要なものに限定されるものではないため、より正確には「ジョブ」と呼ぶことができます。

プロジェクトのフロントエンドの場合、チケットは事前定義された「テンプレート」から作成されます。以下に3つの例を挙げました。

  1. オンラインストアフロントから廃止された製品を削除する。このテンプレートには、廃止された製品が属するベンダー、廃止された製品、中止の理由に関する情報が必要です。
  2. 製品のアップロードエラーの解決。アップロードのバッチID、修正が必要なエラーの数、エラーの発生元のベンダーに関する情報を提供する必要があります。
  3. ワークステーションの修正。ワークステーション番号、問題の内容、および緊急度に関する情報は、必須のフィールドです。

もちろん、チケットの種類ごとに、チケットの名前（問題/割り当ての短い要約）、発行者のuser_id、期限、解決済みかどうかなどの共通の属性を共有します。

このシステムを関係的にモデル化しようとしていますが、それが適切かどうかはわかりません。私が抱えている最大の苦労は、チケットのさまざまな「種類」をモデル化して関連付ける方法です。これはある種の継承には完璧に思えますが、リレーショナルデータベースに保存する必要がありますか？

ある種の [〜＃〜] eav [〜＃〜] モデルを試すのは自然なことですが、これはペストのように避けるべきだと聞いたことがあります（わからないかどうかはわかりません）。これは正確な評価ではありません）。

これが私の現在の試みの図です：

Current Attempt

残りの関係をコンテキストの画像に含めました。

SQLEditor によって生成される、付随する（汎用）SQLコード：

CREATE TABLE actions
(
  action_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  name VARCHAR NOT NULL,
  PRIMARY KEY (action_id)
);

CREATE TABLE departments
(
  department_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  name VARCHAR NOT NULL UNIQUE,
  PRIMARY KEY (department_id)
);

CREATE TABLE entities
(
  entity_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  entity_name VARCHAR NOT NULL UNIQUE,
  PRIMARY KEY (entity_id)
);

CREATE TABLE activity_types
(
  activity_type_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  entity_id INTEGER NOT NULL,
  name VARCHAR NOT NULL,
  PRIMARY KEY (activity_type_id)
);

CREATE TABLE objectives
(
  objective_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  name VARCHAR NOT NULL,
  PRIMARY KEY (objective_id)
);

CREATE TABLE statuses
(
  status_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  name VARCHAR,
  PRIMARY KEY (status_id)
);

CREATE TABLE notifications
(
  notification_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  target_id INTEGER NOT NULL,
  active INTEGER NOT NULL,
  action_id INTEGER,
  closed INTEGER NOT NULL,
  activity_id INTEGER NOT NULL,
  PRIMARY KEY (notification_id)
);

CREATE TABLE ticket_keys
(
  ticket_key_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  name VARCHAR NOT NULL UNIQUE,
  PRIMARY KEY (ticket_key_id)
);

CREATE TABLE tasks
(
  task_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  ticket_id INTEGER NOT NULL,
  name VARCHAR NOT NULL,
  resolved INTEGER NOT NULL,
  PRIMARY KEY (task_id)
);

CREATE TABLE ticket_vals
(
  task_val_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  ticket_key_id INTEGER NOT NULL UNIQUE,
  ticket_id INTEGER NOT NULL,
  val VARCHAR NOT NULL,
  PRIMARY KEY (task_val_id)
);

CREATE TABLE users
(
  user_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  username VARCHAR NOT NULL UNIQUE,
  department_id INTEGER NOT NULL,
  first_name VARCHAR NOT NULL,
  last_name VARCHAR NOT NULL,
  hash VARCHAR NOT NULL,
  salt VARCHAR NOT NULL UNIQUE,
  PRIMARY KEY (user_id)
);

CREATE TABLE comments
(
  comment_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  ticket_id INTEGER NOT NULL,
  commenter_user_id INTEGER NOT NULL,
  comment VARCHAR NOT NULL,
  PRIMARY KEY (comment_id)
);

CREATE TABLE targets
(
  target_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  ticket_id INTEGER,
  task_id INTEGER,
  objective_id INTEGER,
  user_id INTEGER,
  department_id INTEGER,
  PRIMARY KEY (target_id)
);

CREATE TABLE sessions
(
  session_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  user_id INTEGER NOT NULL,
  time_in VARCHAR NOT NULL UNIQUE,
  time_out VARCHAR UNIQUE,
  duration INTEGER,
  PRIMARY KEY (session_id)
);

CREATE TABLE tickets
(
  ticket_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  date_created DATE NOT NULL,
  name VARCHAR NOT NULL UNIQUE,
  issuer_user_id INTEGER NOT NULL,
  deadline VARCHAR NOT NULL,
  resolved INTEGER NOT NULL,
  recurring INTEGER NOT NULL,
  recur_interval VARCHAR,
  objective_id INTEGER,
  status_id INTEGER NOT NULL,
  PRIMARY KEY (ticket_id)
);

CREATE TABLE activities
(
  activity_id INTEGER NOT NULL AUTO_INCREMENT  UNIQUE,
  user_id INTEGER,
  activity_type_id INTEGER NOT NULL,
  source_id INTEGER,
  PRIMARY KEY (activity_id)
);

ALTER TABLE activity_types ADD FOREIGN KEY (entity_id) REFERENCES entities (entity_id);

ALTER TABLE notifications ADD FOREIGN KEY (target_id) REFERENCES targets (target_id);

ALTER TABLE notifications ADD FOREIGN KEY (action_id) REFERENCES actions (action_id);

ALTER TABLE notifications ADD FOREIGN KEY (activity_id) REFERENCES activities (activity_id);

ALTER TABLE ticket_keys ADD FOREIGN KEY (ticket_key_id) REFERENCES ticket_vals (ticket_key_id);

ALTER TABLE tasks ADD FOREIGN KEY (ticket_id) REFERENCES tickets (ticket_id);

ALTER TABLE ticket_vals ADD FOREIGN KEY (ticket_key_id) REFERENCES ticket_keys (ticket_key_id);

ALTER TABLE ticket_vals ADD FOREIGN KEY (ticket_id) REFERENCES tickets (ticket_id);

ALTER TABLE users ADD FOREIGN KEY (department_id) REFERENCES departments (department_id);

ALTER TABLE comments ADD FOREIGN KEY (ticket_id) REFERENCES tickets (ticket_id);

ALTER TABLE comments ADD FOREIGN KEY (commenter_user_id) REFERENCES users (user_id);

ALTER TABLE targets ADD FOREIGN KEY (ticket_id) REFERENCES tickets (ticket_id);

ALTER TABLE targets ADD FOREIGN KEY (task_id) REFERENCES tasks (task_id);

ALTER TABLE targets ADD FOREIGN KEY (objective_id) REFERENCES objectives (objective_id);

ALTER TABLE targets ADD FOREIGN KEY (user_id) REFERENCES users (user_id);

ALTER TABLE targets ADD FOREIGN KEY (department_id) REFERENCES departments (department_id);

ALTER TABLE sessions ADD FOREIGN KEY (user_id) REFERENCES users (user_id);

ALTER TABLE tickets ADD FOREIGN KEY (issuer_user_id) REFERENCES users (user_id);

ALTER TABLE tickets ADD FOREIGN KEY (objective_id) REFERENCES objectives (objective_id);

ALTER TABLE tickets ADD FOREIGN KEY (status_id) REFERENCES statuses (status_id);

ALTER TABLE activities ADD FOREIGN KEY (user_id) REFERENCES users (user_id);

ALTER TABLE activities ADD FOREIGN KEY (activity_type_id) REFERENCES activity_types (activity_type_id);

したがって、考えられるのは、可能なすべての属性をticket_keysに格納し、ticket_valsを通じて関連する属性をチケットに関連付けることでした。しかし、これは解決策というよりは回避策のようです。このモデルには「テンプレート」という概念はありません。おそらくそれは必要でもありませんか？

テンプレートの概念を含める必要があると私が感じた理由の1つは、特権のためです。特定のユーザーだけが特定のテンプレートを表示できます。たとえば、adminだけがUploading products from a new vendorのチケットを開くことができます。しかし、私の現在のセットアップを考えると、それは苦痛のように感じます。たぶん私はprivilege_requiredをticket_keysに追加することもできますが、それでも正しくないようです。

私の素朴な試み、およびリレーショナルモデルがこのプロジェクトに適しているかどうかについてのアドバイスをいただければ幸いです。文書ストアはより適切ですか？

database-designrelational-theory
4
Qcom

説明で「テンプレート」という用語を言及しましたが、デザインでは使用しません。したがって、最初に、すべての可能なテンプレートタイプをリストするテーブルが必要です-id列とname列を持つtemplate_type。例として、次のデータが含まれている場合があります。

Id    Name
 1    Removing a discontinued product(s) from online storefronts
 2    Resolving product upload error
 3    Fixing a workstation

次に、各テンプレートタイプの構成用のストレージが必要です-template。特定のテンプレートに含まれる各ticket_keyのレコードと、template_typeテーブルのid列への参照が含まれます。これで、特定の各チケットには、そのテンプレートタイプを参照するtemplate_type_id列が必要です。

さらに、特定のticket_key、特にtemplateにアクセス権を設定することで、認証システムを実装できます。

編集：回答に対するコメントに従って修正。

2
Serg