平面檔案資料庫結構(Flat File database structure)以定界的方式存儲數據,可以將其解釋為單一數據流。平面資料庫在數據之間使用定界符,如逗號等。
由於不同的公司需要存儲不同的數據且具有不同的數據需求,因此每一個平面檔案資料庫系統都是各不相同的。創建一個平面檔案資料庫並存儲數據後,應該設計檢索數據、創建新記錄、更新記錄以及刪除記錄的方法。
基本介紹
- 中文名:平面檔案資料庫結構
- 外文名:Flat File database structure
- 涉及學科:計算機等
- 套用領域:資料庫
- 對立:關係資料庫
- 作用對象:平面檔案
資料庫類型,平面檔案資料庫,關係資料庫,平面檔案資料庫模型,域,缺點,設計平面檔案(Flat File)資料庫,平面檔案資料庫的實現,第一階段: 純文本,2. 第二階段:Excel,3. 第三階段:FileMaker,4. 以往實現,5. 當代實現,
資料庫類型
有很多資料庫設計的格式,但這裡要考慮的兩種最常見的格式是平面檔案和關係資料庫。
平面檔案資料庫
平面檔案資料庫(Flat file database)以定界的方式存儲數據,可以將其解釋為單一數據流。平面資料庫在數據之間使用定界符,如逗號等。平面檔案資料庫在需要時會變的非常大;然而,在試圖添加、刪除或修改其中的任何數據時, 單一數據流會變得效率很低:平dd檔案資料庫一般用作以文本檔案的形式將數據從一處移動到另一處的簡單解決方案。有些公司仍然將平面檔案資料庫用於產品而不是工具,但是這種情況已經不普遍了。平面檔案資料庫的一個嚴重缺點是沒有能力管理請求。例如,平面檔案數據唪在多個命令正好同時提交時必定要失敗。
關係資料庫
關係資料庫(Relationai database)是我們在上面的檔案櫃與資料庫的比較中討論的那種資料庫類型。如果考慮牙醫診所的例子,那么表格就相當於檔案櫃的抽屜,因此,診所中可能有——個稱為“患者”的表格,其中含有數據欄位如患者編號、姓名和保險等。每行當中的數據應該是這樣的:PatientstablePatientID FirstName LastName PhoneRvanJoeO'KeefeSchome555-394-0293 WeCareHMO394-983-0000 Discount Care Providers
關係資料庫的功能可以從其名字中得到暗示:關係。每一行或每個表格都可以與其他表格連結,或是相關,因此消除了重複數據的必要。在上面的例子中,想添加包含主要保險患者時如何做呢?如果大家說“簡甲,只要將他們添加到具有相同保險公司的患者表格中就行了”,這樣就沒有使用關係資料庫的功能。很可能主保險人與其被保險人有關係,如配偶或子女只有共同的電話號碼和地址。為什麼還要重複電話號碼和地址數據昵?如果創建另一個稱為dePatients的表格並且與Patients表格的PatientlD相關,那么就可以將dePatients中的數據與Patients表格中的記錄相關聯。
現在,可以查詢患者(和任伺相關患者),而且能夠得到相同的電話號碼和保險數據,因為這兩個表格是連線起來的。另外,可以在需要時添加或刪除任何相關患者而不會影響主患者的記錄。這種關係的鍵是Patients表格中的數據欄位PatientslD。這個欄位必須是惟一的,否則,關係就沒有作用。這個惟一的值被稱為主鍵(primary key)。可以為一個表格指定一個數據寧段為主鍵,而這個主鍵保證了這些數據欄位中內容不重複。在上面的例子中,Patients表格的PatientslD是主鍵,而每個patientlD唯一標識了Patients表格中的汜錄。如果嘗試插入重複的值到標汜為主鍵的數據卞段中,就會返回錯誤。
上圖中的關係數掘庫中的另外一個鍵是外來鍵(foreignkey),外來鍵值連線到其他表格中的主鍵值。外來鍵中的值與正在連線的主鍵中的值相同。這種關係創建了兩個記錄之間的相關性。如果dePatients中的記錄與Patients表格中的記錄相關(由於外來鍵關係),則在Patients中的記錄不能被刪除。這點很重要,因為如果Patients表格中的記錄被刪除而它與dePatients中的記錄有外來鍵關係,則dePatients中的記錄將成為孤值並與任何內容無關。
平面檔案資料庫模型
在像Oracle和Microsoft這樣的提供商開發出能夠運行在計算機上的資料庫管理系統之前,許多公司都是通過主機上的普通檔案來保存數據的。尤其在大型機時代,使用普通檔案來存儲數據占主導地位。
平面檔案資料庫由一個或多個可讀檔案組成,這些檔案通常按照文本的格式保存。這些檔案中的信息按域來保存,這些域可以有固定長度,也可以是變長的,並且域之間通過一些符號(分界符)來分隔。
域
下面所示的就是一個普通檔案,其中域具有固定寬度:
1234 Ernest Hemingway For Whom the Bell Tolls
5678 Charles Dickens Great Expectations
4321 Ernest Hemingway A Farewell to Arms
8765 Jack London White Fang
4123 fack London Call of the Wild
3456 Mark Twain Adventures of Huckleberry Finn
在這個例子中,很明顯有三個域:標識數、作者名稱以及圖書名稱。每一個域都有固定時長度,如:標識數由4位數組成,它占用4列的長度,而作者名稱最多有20個字母。
下面所示的是由特定的分界符來分隔域長度是變長的普通檔案:
1234:Ernest Hemingway:For Whom the Bell Tolls
5678:Charles Dickens:Great Expectations
4321:Ernest Hemingway:A Farewell to Arms
8765:Jack London:White Fang
4523:Jack London:Call of the Wild
3456: Mairk Twain:Adventures of Huckleberry Finn
在這個例中,三個域之間是通過“:”來分隔的,而且域的寬度是可變的。如果使用分界符來分隔域,就必須保證分界符不會出現在數據中。
注意: 有時候,普通檔案也可以用來在資料庫之間進行數據移植,尤其是在關係資料庫之間。
由於不同的公司需要存儲不同的數據且具有不同的數據需求,因此每一個平面檔案資料庫系統都是各不相同的。創建一個平面檔案資料庫並存儲數據後,應該設計檢索數據、創建新記錄、更新記錄以及刪除記錄的方法。例如,如果要查詢所有作者是Jack London的作品的名稱,就必須以“Jack London”為關鍵字遍歷所有的記錄。此外,還應該過濾數據,也就是只查詢普通檔案中的第3列數據。
缺點
在普通檔案中,訪問數據的問題是必須設計一系列的程式來查詢存儲在普通檔案中的信息。如果沒有這些方法,用戶或客戶就必須自己來查詢這些檔案,這顯然是不能接受的。平面檔案資料庫系統最主要的問題就是:不但要掌握這些普通檔案的結構,還要知道這些數據的物理存儲位置。此外,這種資料庫系統還可能會需要大量的普通檔案,因為相關數據可能會保存在不同的檔案中。在平面檔案資料庫環境中,對數據聯繫的管理是一項非常困難的任務。
如下所列的是平面檔案資料庫系統存在的缺點:
- ·普通檔案無法提供便於數據關聯的結構。
- ·不能有效地管理數據並保證數據的準確性。
- ·通常必須存儲冗餘數據,這導致了準確維護數據的額外工作量。
- ·必須知道檔案中數據域的物理存儲位置。
- ·必須設計管理數據的程式。
設計平面檔案(Flat File)資料庫
設計關係資料庫之前,我們先來了解一下平面檔案資料庫。設計平面檔案資料庫是一個相對簡單的過程。因為真正的平面檔案資料庫不支持檔案之間的信息共享,需要為想在資料庫中追蹤的所有內容定義欄位。
例如,如果要在一個名為“發貨單”的檔案中包含客戶信息,除了已在“發貨單”檔案中定義的欄位之外,還需要定義客戶名稱、地址、城市、州和郵政編碼欄位。如果想在該檔案中包含產品信息,除了已定義的欄位之外,還需要定義產品名稱、顏色、尺寸(或其他屬性)和價格欄位。
平面檔案資料庫可能包含大量欄位,在很多情況下包含大量重複數據,比如:客戶名稱或產品名稱。
設計平面檔案資料庫簡單到只需決定想要追蹤的數據,並為每個數據創建一個欄位即可。圖 1 顯示了為了追蹤向客戶銷售產品的情況而在簡單的平面檔案資料庫中定義的欄位。
接下來,需要考慮如何將信息從一個資料庫傳輸到另一個資料庫。FileMaker Plus 的發布帶來了一項名為“查找”的新功能。強大的“查找”功能可讓您將一個檔案中的數據拷貝貼上到另一個檔案。
在“發貨單”檔案示例中(圖 2),“查找”功能要求您定義“發貨單”檔案中的客戶信息欄位,然後可將客戶信息欄位指定為“查找”欄位。這樣,根據兩個檔案中同時包含的某欄位中的匹配值,您可將“客戶”檔案中的數據拷貝貼上到“發貨單”檔案中。
更改“客戶”檔案中的數據時,“發貨單”檔案中的數據不會自動更改。要更新所做的更改,必須使用“重新查找”命令。因此,如果一個客戶更改了地址,可使用“重新查找”命令來更新該客戶地址的所有匹配項。如果更改了“發貨單”檔案中的客戶數據,也要通過這種並不簡單的方式更新“查找”檔案中的數據。
“查找”使平面檔案資料庫更為實用和強大,讓數據輸入更快速、更準確。藉助該功能,可以將圍繞一個共同主題的數據拆分到不同的檔案中。
平面檔案資料庫的實現
平面檔案資料庫是非常簡單的資料庫模型,利用純文本檔案存儲信息,檔案中的每行代表一條記錄,每條記錄由分割的欄位或固定列組成。與複雜的模型如關係型資料庫比較,平面檔案資料庫好似寫著記錄的一張紙。
讓我們探索下各階段的檔案資料庫。
第一階段: 純文本
下面是以最簡單的文本內聯方式實現,以表格的形式展示數據:
所有的這些實現都是等效的。但是對於這種純文本的方式,僅僅能滿足用戶基本的需求,下面讓我來介紹一款專門為工作而設計的工具。
2. 第二階段:Excel
Microsoft Excel是一個簡單的資料庫工具,數據按照行和列進行組織,首行來表示欄位名稱。
Excel為使用者提供了排序功能,如果按照用戶分組升序排序:
排序後可以發現藍隊在前,紅隊在後。
任意列都可以排序,Excel設計初衷是用來解決複雜數值計算的電子表格工具。 假設用戶表增加了“分數”欄位,如果想對分數欄位計算總和、平均值和標準差,那么Excel是再合適不過了。
3. 第三階段:FileMaker
FileMaker是真正意義上的資料庫管理工具。
數據展示
FileMaker以行列形式展示數據,首行表示欄位名稱,下面是列表的展示方式:
如果資料庫欄位很多,使用表單查看數據詳情可能更方便一些:
數據本身不會改變,改變的只是數據查看的方式,除了默認的展示方式,還可以自定義設計展示。
排序
FileMaker提供了更高級的排序功能,可以對多個欄位正序、倒序或者依據某一給定序列排序。
基於用戶組排序:
與Excel排序後的結果一致。
查找
FileMaker提供了查找功能,可以基於某個欄位進行查找,例如查找名為“Fred”的用戶:
通過查找鎖定了用戶“Fred”:
還可以進行更複雜的操作,例如搜尋Blues用戶組,同時按照用戶名排序。
定義欄位
在現有的資料庫中可以添加額外的欄位,同時設定用數據類型。
除此之外,還可以定義更複雜的操作。
4. 以往實現
計算機的第一個用途就是用作資料庫。
Herman Hollerith認為用一個80位數字和字母混合的字元串,可以存儲美國居民的身份信息,為了使數據排列整齊,使用空格填充。 美國人口普查局至今珍藏著Herman Hollerith打卡機。1890年人口普查記錄是第一個計算機化的資料庫,數以千計裝著打孔卡的盒子做為存儲的介質。
原始計算機主要是政府和公司使用,僅僅做為平面檔案資料庫使用,最典型套用的就是會計領域,如工資單。 但是,很快,平面文本數據已經滿足不了用戶更複雜的需求,促使了關係型資料庫的產生。
20世紀80年代,可配置的平面檔案資料庫廣泛的套用在DOS和MAC作業系統中, 這些資料庫設計的宗旨是易於個人設計和使用資料庫,當時的流行程度不亞於word和excel。
原始計算機主要是政府和公司使用,僅僅做為平面檔案資料庫使用,最典型套用的就是會計領域,如工資單。 但是,很快,平面文本數據已經滿足不了用戶更複雜的需求,促使了關係型資料庫的產生。
20世紀80年代,可配置的平面檔案資料庫廣泛的套用在DOS和MAC作業系統中, 這些資料庫設計的宗旨是易於個人設計和使用資料庫,當時的流行程度不亞於word和excel。
5. 當代實現
今天,幫助新手創建和使用平面文本資料庫的軟體微乎其微,相關功能已經集成於作業系統中。 隨著時間的推移,出現了關係功能的資料庫,例如Borland的Paradox和Microsoft的Access。 許多計算機應用程式一直使用平面檔案資料庫存儲配置數據,有些小程式本質上使用的就是平面檔案。
XML是廣泛使用的檔案格式,支持數據類型的定義、複雜數據結構的定義,以純文本的方式存儲數據。