-1

我正在做一個項目,而且我不是數據庫的專家,所以遇到了一些問題。在架構中,我想有幾個小型數據庫(單個工作站)將數據推送到一個大型的集中式數據庫中,這些數據庫將這些數據存儲在表中,並且每次推送數據時只添加記錄。 分析這些數據會有所幫助,但是中央數據庫必須是OLTP(因爲它是醫療記錄並且必須始終處於運行狀態,所以停機時間不可行),因此OLAP可能是另一種情況層分佈在集中式數據庫之上,並且分析時不會干擾這些單個工作站與中央數據庫之間的數據交換?還是中央數據庫需要自己的OLAP體系結構? OLTP數據庫還可以存儲例如病史數據嗎? (我在問,因爲這些數據也可能是歷史數據,以前的疾病等等,所以我不太瞭解它在表格中的樣子)。 這種架構的要求是什麼? (比如,對於整個城市來說,數據主要由txt和鏈接組成)。感謝提前幫助球員,希望我是足夠清楚:)OLAP層集中式OLTP數據庫設計

Ps。順便說一下,這將是存儲患者電子健康記錄的中央數據庫,在患者就診後或新的診斷後,將由數個醫生的診所和診所推送。因此,數據交換將是雙向的,從單個工作站到中央數據庫以及其他方式(如果醫生需要其他醫生的信息)。你知道更好的建築嗎?如果我們想分析這些數據,我認爲這是唯一可行的選擇,但是再次,我不是專家,所以不能說太多,讓我知道你的想法:)

回答

0

您的運營數據庫(OLTP)用於存儲交易信息。這是高度規範化,以防止異常,並加快寫入。像患者訪問信息這樣的東西將存儲在這裏。

您可以使用同一個數據庫來分析信息,但將其放入一個不太標準化的表單可以使這變得更容易,尤其是對於非DBA。這將是您的分析數據庫(數據倉庫),您可以使用它執行OLAP操作。

OLAP是一組操作(如pivot,slice,dice)。數據倉庫是爲便於分析而設計的數據庫。他們是不同的。

我不明白停機時間與OLTP vs OLAP有何關係。

是有可能的是,OLAP是集中式數據庫 上述另一個層和分析時在數據中不會這些奇異工作站和中央數據庫之間 交換干擾?

通常,您會將數據從運營數據庫提取到分析數據庫中。只是做選擇不會干涉它。我會說你的分析數據庫是「旁邊」的操作之一,而不是「上面」。

或者中央數據庫是否需要OLAP架構本身?

如果您正在中央數據庫中進行事務處理,那麼沒有。

也可以OLTP數據庫存儲例如病史數據?

+0

感謝您的快速回復:)我開始閱讀關於數據庫的原因是因爲這個項目,我跑了很多網站,其中OLTP數據庫被描述爲非常穩定和可靠,快速的讀取和沒有停機時間,而OLAP的速度很慢,有些操作可能會讓整個系統暫時停頓一段時間,這對中央數據庫非常穩定並始終保持正常狀態非常重要。 – 2015-02-07 00:19:06

+0

我確實看到停機時間與OLTP vs OLAP有關。 – 2015-02-07 12:11:29

1

正如尼爾已經表示,標準化是在OLTP環境良好設計的關鍵原則(沒有雙關語意)。其他一些設計原則是建立良好數據倉庫或數據集市的關鍵。數據集市可以作爲OLAP操作的基礎。

通常,OLAP不需要當前數據。一旦每天更新通常就足夠了,有時候可能會像每月一次那樣少見。你知道你的要求在你的情況。將數據從操作(OLTP)數據庫複製到分析(OLAP)數據庫的過程稱爲「提取,轉換和加載(ETL)」。 ETL處理可能非常複雜並涉及大量編程,儘管有些工具可以幫助構建ETL過程。除非您已經確定了OLTP和OLAP數據庫的設計,否則您無法真正構建ETL,但可以提前進行規劃並進行設計,以便它們一起工作。

有時,OLAP數據庫根本不在關係(SQL)數據庫中,而是以某種特定形式(通常稱爲「數據多維數據集」)。專門研究所謂「商業智能」的分析師通常使用數據立方體,有時這些格式是專有的並且綁定到該工具。

當OLAP數據庫是關係型數據庫時,經常使用的一種設計是「星型模式」或其一些變體。事實證明,如果數據元素的名稱對相關人員有意義,則對於即取即用或向下鑽取界面來說非常方便。

你有很多學習要做。祝你好運。