sql - ルックアップ列の数が多いテーブルのベストプラクティス

Question

さて、少し背景があります...プログラマーとして最初にDB設計の経験が限られていたので、いくつかの新しい間違いを犯しました。つまり、統合されたコードルックアップテーブルと別のテーブルでのEAV実装です。私は現在、それらを従来のRDBMSに作り直そうとしていますが、今回はそれが正しく行われていることを絶対に確認したいと思います。

私の大きな問題のテーブルは、州に報告しなければならないクライアントデータを含む150列程度の大きなテーブルです。このデータのほとんどは状態固有のルックアップ値を使用しているため、現在の設計計画では、さまざまなルックアップテーブルに対して75〜100FKになることになります。

次に、このデータのレポートを作成する必要があるため、各属性のコード値と説明の両方を簡単に参照できるようにする必要があります。私が考えることができる唯一のオプションは、データをフラット化する2つの個別のビュー（またはおそらく1つの大規模なビュー）を作成することです。特に収集されたデータが変更される可能性があることを考えると、作成および保守するのはかなり退屈なプロセスのようです。これが標準的な方法であれば、私はレッグワークを行っても大丈夫ですが、私が知らないより良い方法があるかどうか興味があります。

USE [TestCompany]
GO

/****** Object:  Table [CLI].[AttributesTable]    Script Date: 02/07/2013 15:01:34 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [CLI].[AttributesTable](
    [AttributesTableID] [int] NOT NULL,
    [ChartID] [int] NOT NULL,
    [AdmitCounty] [int] NULL,
    [AdmissionReason] [int] NULL,
    [Gender] [int] NULL,
    [Race] [int] NULL,
    [Occupation] [int] NULL,
    [MaritalStatus] [int] NULL,
    [Education] [int] NULL,
    [SpecialEducation] [int] NULL,
    [Impairment] [int] NULL,
    [Hispanic] [int] NULL,
    [HearingStatus] [int] NULL,
    [ExpectedPaysource] [int] NULL,
    [PublicAssistance] [int] NULL,
    [Dietary] [int] NULL,
    [EmploymentStatus] [int] NULL,
    [LivingArrangements] [int] NULL,
    [IncomeSource] [int] NULL,
    [LegalStatus] [int] NULL,
    [CommitType] [int] NULL,
    [EnrolledInSchool] [nchar](10) NULL,
    [GradePointAverage] [int] NULL,
    [EducationProgram] [int] NULL,
    [HIV] [int] NULL,
    [SelfHelpPrograms] [int] NULL,
    [MediationPrescribed] [int] NULL,
    [DischargeReason] [int] NULL,
    [DischargeReferral] [int] NULL,

 CONSTRAINT [PK_AttributesTable] PRIMARY KEY CLUSTERED 
(
    [AttributesTableID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AdmissionReason_Code] FOREIGN KEY([AdmissionReason])
REFERENCES [LKP].[AdmissionReasonCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AdmissionReason_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_CommitType_Code] FOREIGN KEY([CommitType])
REFERENCES [LKP].[CommitTypeCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_CommitType_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_Dietary_Code] FOREIGN KEY([Dietary])
REFERENCES [LKP].[DietaryCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_Dietary_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_DischargeReason_Code] FOREIGN KEY([DischargeReason])
REFERENCES [LKP].[DischargeReasonCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_DischargeReason_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_DischargeReferral_Code] FOREIGN KEY([DischargeReferral])
REFERENCES [LKP].[DischargeReferralCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_DischargeReferral_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_Chart] FOREIGN KEY([ChartID])
REFERENCES [CLI].[Chart] ([ChartID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_Chart]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_CommitTypeCode] FOREIGN KEY([CommitType])
REFERENCES [LKP].[CommitTypeCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_CommitTypeCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EducationCode] FOREIGN KEY([Education])
REFERENCES [LKP].[EducationCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EducationCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EducationProgramIndicatorCode] FOREIGN KEY([EducationProgram])
REFERENCES [LKP].[EducationProgramIndicatorCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EducationProgramIndicatorCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EmploymentStatusCode] FOREIGN KEY([EmploymentStatus])
REFERENCES [LKP].[EmploymentStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EmploymentStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_GenderCode] FOREIGN KEY([Gender])
REFERENCES [LKP].[GenderCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_GenderCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_GPACode] FOREIGN KEY([GradePointAverage])
REFERENCES [LKP].[GPACode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_GPACode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HearingStatusCode] FOREIGN KEY([HearingStatus])
REFERENCES [LKP].[HearingStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HearingStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HispanicCode] FOREIGN KEY([Hispanic])
REFERENCES [LKP].[HispanicCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HispanicCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HIVTestCode] FOREIGN KEY([HIV])
REFERENCES [LKP].[HIVTestCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HIVTestCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_ImpairmentCode] FOREIGN KEY([Impairment])
REFERENCES [LKP].[ImpairmentCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_ImpairmentCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_IncomeSourceCode] FOREIGN KEY([IncomeSource])
REFERENCES [LKP].[IncomeSourceCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_IncomeSourceCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_LegalStatusCode] FOREIGN KEY([LegalStatus])
REFERENCES [LKP].[LegalStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_LegalStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_LivingArrangementCode] FOREIGN KEY([LivingArrangements])
REFERENCES [LKP].[LivingArrangementCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_LivingArrangementCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_MaritalStatusCode] FOREIGN KEY([MaritalStatus])
REFERENCES [LKP].[MaritalStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_MaritalStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_MedicationPrescribedCode] FOREIGN KEY([MediationPrescribed])
REFERENCES [LKP].[MedicationPrescribedCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_MedicationPrescribedCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_PaySourceCode] FOREIGN KEY([ExpectedPaysource])
REFERENCES [LKP].[PaySourceCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_PaySourceCode]
GO

score 1 · Accepted Answer

レポートが主な関心事である場合は、「レポート」または「分析」データベースを構築することをお勧めします (通常、ETL またはExtact/Transform/Loadツールを使用して実行されます)。これらのデータベースは、多くの場合、選択的に非正規化されています。たとえば、「性別」コードテーブルへの fk 参照の代わりに'Male'、レポートテーブルにあるはずです。実際の程度は必要に応じて変化し、特定のパフォーマンスレベルの問題が発生するまでは、おそらくビューを通じて表示する必要があります。

ただし、「ライブ」データがどのように見えるかなどの日常業務では、正規化されたアプローチが必要になります。テーブルには、などがある
と想定しています。(ほぼ)常に収集され、「静的」である重要なものはすべて、このテーブルに入れる必要があります。たとえば、人種は訪問の過程で変わる可能性は低いです (そしておそらく、静的な患者記録の一部であるべきです)。多少「まばら」であるが、頻繁に収集されるものはすべて、おそらく「関連」テーブルに入れる必要があります。何かのようなもの：ChartvisitedOncollectingCaregiverId

Education_Status
=================
chart_id  -- fk reference to chart.id
school  -- fk reference to attribute-specific code table
program  -- see above
grade_point_average  -- DECIMAL(3, 2)

... 等々。
完全にオプションであり、めったに収集されないものは、EAV になる可能性があります。「領域」に基づいて、これらのセットアップが複数存在する場合があることに注意してください。また、これらも可能な限り「コード化」する必要があります。

Unusual_Symptom_Type
======================
id  -- autogen
name  -- varchar(20) (eg - 'Turning Blue', 'Allergic to Oxygen', etc)

Unusual_Symptom
====================
chart_id  -- fk reference to chart.id
unusual_symptom_type_id  -- fk reference to unusual_symptom_type.id
note -- varchar(20) (eg - 'Afternoon Sky', 'Combusts', etc)

もちろん、レポートのためにこれを再構築する必要があります。これは「トランザクション」データベース固有の「弱点」です。データの品質は通常まともで、更新も簡単ですが、すべてを「読み取り可能な」形式にまとめるのは困難な場合があります。可能な場合はビューを作成して、関連する領域を結び付けます。

score 0 · Accepted Answer

ビュー、場合によってはより小さなビューが、あなたができる最善のことだと思います。幾つか？あなたの状況と要件に応じて。レポートごと、またはレポートのグループごとにビューを作成できます。それはすべて依存します... これは私が考え、行うことです。参考までに - 私は DBA ではなく、開発者です。

sql - ルックアップ列の数が多いテーブルのベストプラクティス

2 に答える 2

Related

Reference