數(shù)據(jù)庫設計規(guī)范與命名規(guī)則模板_第1頁
數(shù)據(jù)庫設計規(guī)范與命名規(guī)則模板_第2頁
數(shù)據(jù)庫設計規(guī)范與命名規(guī)則模板_第3頁
數(shù)據(jù)庫設計規(guī)范與命名規(guī)則模板_第4頁
數(shù)據(jù)庫設計規(guī)范與命名規(guī)則模板_第5頁
已閱讀5頁,還剩19頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

數(shù)據(jù)庫設計規(guī)范、技巧與命名規(guī)范一、數(shù)據(jù)庫設計過程數(shù)據(jù)庫技術是信息資源管理最有效的手段。數(shù)據(jù)庫設計是指:對于一種給定的應用環(huán)境,構造最優(yōu)的數(shù)據(jù)庫模式,建立數(shù)據(jù)庫及其應用系統(tǒng),有效存儲數(shù)據(jù),滿足顧客信息規(guī)定和解決規(guī)定。數(shù)據(jù)庫設計的各階段:A、需求分析階段:綜合各個顧客的應用需求(現(xiàn)實世界的需求)。B、在概念設計階段:形成獨立于機器和各DBMS產品的概念模式(信息世界模型),用E-R圖來描述。C、在邏輯設計階段:將E-R圖轉換成具體的數(shù)據(jù)庫產品支持的數(shù)據(jù)模型,如關系模型,形成數(shù)據(jù)庫邏輯模式。然后根據(jù)顧客解決的規(guī)定,安全性的考慮,在基本表的基礎上再建立必要的視圖(VIEW)形成數(shù)據(jù)的外模式。D、在物理設計階段:根據(jù)DBMS特點和解決的需要,進行物理存儲安排,設計索引,形成數(shù)據(jù)庫內模式。1.需求分析階段需求收集和分析,成果得到數(shù)據(jù)字典描述的數(shù)據(jù)需求(和數(shù)據(jù)流圖描述的解決需求)。需求分析的重點:調查、收集與分析顧客在數(shù)據(jù)管理中的信息規(guī)定、解決規(guī)定、安全性與完整性規(guī)定。需求分析的辦法:調查組織機構狀況、各部門的業(yè)務活動狀況、協(xié)助顧客明確對新系統(tǒng)的多個規(guī)定、擬定新系統(tǒng)的邊界。常見的調查辦法有:跟班作業(yè)、開調查會、請專人介紹、詢問、設計調查表請顧客填寫、查閱統(tǒng)計。分析和表達顧客需求的辦法重要涉及自頂向下和自底向上兩類辦法。自頂向下的構造化分析辦法(StructuredAnalysis,簡稱SA辦法)從最上層的系統(tǒng)組織機構入手,采用逐級分解的方式分析系統(tǒng),并把每一層用數(shù)據(jù)流圖和數(shù)據(jù)字典描述。數(shù)據(jù)流圖表達了數(shù)據(jù)和解決過程的關系。系統(tǒng)中的數(shù)據(jù)則借助數(shù)據(jù)字典(DataDictionary,簡稱DD)來描述。2.概念構造設計階段通過對顧客需求進行綜合、歸納與抽象,形成一種獨立于具體DBMS的概念模型,能夠用E-R圖表達。概念模型用于信息世界的建模。概念模型不依賴于某一種DBMS支持的數(shù)據(jù)模型。概念模型能夠轉換為計算機上某一DBMS支持的特定數(shù)據(jù)模型。概念模型特點:(1)含有較強的語義表達能力,能夠方便、直接地表達應用中的多個語義知識。(2)應當簡樸、清晰、易于顧客理解,是顧客與數(shù)據(jù)庫設計人員之間進行交流的語言。概念模型設計的一種常見辦法為IDEF1X辦法,它就是把實體-聯(lián)系辦法應用到語義數(shù)據(jù)模型中的一種語義模型化技術,用于建立系統(tǒng)信息模型。使用IDEF1X辦法創(chuàng)立E-R模型的環(huán)節(jié)以下所示:2.1初始化工程這個階段的任務是從目的描述和范疇描述開始,擬定建模目的,開發(fā)建模計劃,組織建模隊伍,收集源材料,制訂約束和規(guī)范。收集源材料是這階段的重點。通過調查和觀察成果,業(yè)務流程,原有系統(tǒng)的輸入輸出,多個報表,收集原始數(shù)據(jù),形成了基本數(shù)據(jù)資料表。2.2定義實體實體集組員都有一種共同的特性和屬性集,能夠從收集的源材料——基本數(shù)據(jù)資料表中直接或間接標記出大部分實體。根據(jù)源材料名字表中表達物的術語以及含有”代碼”結尾的術語,如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標記出來,從而初步找出潛在的實體,形成初步實體表。2.3定義聯(lián)系IDEF1X模型中只允許二元聯(lián)系,n元聯(lián)系必須定義為n個二元聯(lián)系。根據(jù)實際的業(yè)務需求和規(guī)則,使用實體聯(lián)系矩陣來標記實體間的二元關系,然后根據(jù)實際狀況擬定出連接關系的勢、關系名和闡明,擬定關系類型,是標記關系、非標記關系(強制的或可選的)還是非擬定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標記,則為標記關系,否則為非標記關系。非標記關系中,如果每個子實體的實例都與并且只與一種父實體關聯(lián),則為強制的,否則為非強制的。如果父實體與子實體代表的是同一現(xiàn)實對象,那么它們?yōu)榉诸愱P系。2.4定義碼通過引入交叉實體除去上一階段產生的非擬定關系,然后從非交叉實體和獨立實體開始標記侯選碼屬性,方便唯一識別每個實體的實例,再從侯選碼中擬定主碼。為了擬定主碼和關系的有效性,通過非空規(guī)則和非多值規(guī)則來確保,即一種實體實例的一種屬性不能是空值,也不能在同一種時刻有一種以上的值。找出誤認的擬定關系,將實體進一步分解,最后構造出IDEF1X模型的鍵基視圖(KB圖)。2.5定義屬性從源數(shù)據(jù)表中抽取闡明性的名詞開發(fā)出屬性表,擬定屬性的全部者。定義非主碼屬性,檢查屬性的非空及非多值規(guī)則。另外,還要檢查完全依賴函數(shù)規(guī)則和非傳遞依賴規(guī)則,確保一種非主碼屬性必須依賴于主碼、整個主碼、僅僅是主碼。以此得到了最少符合關系理論第三范式的改善的IDEF1X模型的全屬性視圖。2.6定義其它對象和規(guī)則定義屬性的數(shù)據(jù)類型、長度、精度、非空、缺省值、約束規(guī)則等。定義觸發(fā)器、存儲過程、視圖、角色、同義詞、序列等對象信息。3.邏輯構造設計階段將概念構造轉換為某個DBMS所支持的數(shù)據(jù)模型(例如關系模型),并對其進行優(yōu)化。設計邏輯構造應當選擇最適于描述與表達對應概念構造的數(shù)據(jù)模型,然后選擇最適宜的DBMS。將E-R圖轉換為關系模型事實上就是要將實體、實體的屬性和實體之間的聯(lián)系轉化為關系模式,這種轉換普通遵照以下原則:一種實體型轉換為一種關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。數(shù)據(jù)模型的優(yōu)化,擬定數(shù)據(jù)依賴,消除冗余的聯(lián)系,擬定各關系模式分別屬于第幾范式。擬定與否要對它們進行合并或分解。普通來說將關系分解為3NF的原則,即:表內的每一種值都只能被表達一次。表內的每一行都應當被唯一的標記(有唯一鍵)。表內不應當存儲依賴于其它鍵的非鍵信息。4.數(shù)據(jù)庫物理設計階段為邏輯數(shù)據(jù)模型選用一種最適合應用環(huán)境的物理構造(涉及存儲構造和存取辦法)。根據(jù)DBMS特點和解決的需要,進行物理存儲安排,設計索引,形成數(shù)據(jù)庫內模式。5.數(shù)據(jù)庫實施階段運用DBMS提供的數(shù)據(jù)語言(例如SQL)及其宿主語言(例如C),根據(jù)邏輯設計和物理設計的成果建立數(shù)據(jù)庫,編制與調試應用程序,組織數(shù)據(jù)入庫,并進行試運行。數(shù)據(jù)庫實施重要涉及下列工作:用DDL定義數(shù)據(jù)庫構造、組織數(shù)據(jù)入庫、編制與調試應用程序、數(shù)據(jù)庫試運行,(DataDefinitionLanguage(DDL數(shù)據(jù)定義語言)用作開新數(shù)據(jù)表、設定字段、刪除數(shù)據(jù)表、刪除字段,管理全部有關數(shù)據(jù)庫構造的東西)●Create(新增有關數(shù)據(jù)庫構造的東西,屬DDL)●Drop(刪除有關數(shù)據(jù)庫構造的東西,屬DDL)●Alter(更改構造,屬DDL)6.數(shù)據(jù)庫運行和維護階段在數(shù)據(jù)庫系統(tǒng)運行過程中必須不停地對其進行評價、調節(jié)與修改。內容涉及:數(shù)據(jù)庫的轉儲和恢復、數(shù)據(jù)庫的安全性、完整性控制、數(shù)據(jù)庫性能的監(jiān)督、分析和改善、數(shù)據(jù)庫的重組織和重構造。7.建模工具的使用為加緊數(shù)據(jù)庫設計速度,現(xiàn)在有諸多數(shù)據(jù)庫輔助工具(CASE工具),如Rational公司的RationalRose,CA公司的Erwin和Bpwin,Sybase公司的PowerDesigner以及Oracle公司的oracleDesigner等。ERwin重要用來建立數(shù)據(jù)庫的概念模型和物理模型。它能用圖形化的方式,描述出實體、聯(lián)系及實體的屬性。ERwin支持IDEF1X辦法。通過使用ERwin建模工具自動生成、更改和分析IDEF1X模型,不僅能得到優(yōu)秀的業(yè)務功效和數(shù)據(jù)需求模型,并且能夠實現(xiàn)從IDEF1X模型到數(shù)據(jù)庫物理設計的轉變。ERwin工具繪制的模型對應于邏輯模型和物理模型兩種。在邏輯模型中,IDEF1X工具箱能夠方便地用圖形化的方式構建和繪制實體聯(lián)系及實體的屬性。在物理模型中,ERwin能夠定義對應的表、列,并可針對多個數(shù)據(jù)庫管理系統(tǒng)自動轉換為適宜的類型。設計人員可根據(jù)需要選用對應的數(shù)據(jù)庫設計建模工具。例如需求分析完畢之后,設計人員能夠使用Erwin畫ER圖,將ER圖轉換為關系數(shù)據(jù)模型,生成數(shù)據(jù)庫構造;畫數(shù)據(jù)流圖,生成應用程序。二、數(shù)據(jù)庫設計技巧1.設計數(shù)據(jù)庫之前(需求分析階段)1.1客戶需求,涉及顧客將來需求變化。1.2理解公司業(yè)務類型,能夠在開發(fā)階段節(jié)省大量的時間。1.3重視輸入(要統(tǒng)計的數(shù)據(jù))、輸出(報表、查詢、視圖)。1.4創(chuàng)立數(shù)據(jù)字典和ER圖表數(shù)據(jù)字典(DataDictionary,簡稱DD)是各類數(shù)據(jù)描述的集合,是有關數(shù)據(jù)庫中數(shù)據(jù)的描述,即元數(shù)據(jù),不是數(shù)據(jù)本身。(最少應當包含每個字段的數(shù)據(jù)類型和在每個表內的主外鍵)。數(shù)據(jù)項描述:數(shù)據(jù)項名,數(shù)據(jù)項含義闡明,別名,數(shù)據(jù)類型,長度,取值范疇,取值含義,與其它數(shù)據(jù)項的邏輯關系數(shù)據(jù)構造描述:數(shù)據(jù)構造名,含義闡明,構成:[數(shù)據(jù)項或數(shù)據(jù)構造]數(shù)據(jù)流描述:數(shù)據(jù)流名,闡明,數(shù)據(jù)流來源,數(shù)據(jù)流去向,構成:[數(shù)據(jù)構造],平均流量,高峰期流量數(shù)據(jù)存儲描述:數(shù)據(jù)存儲名,闡明,編號,流入的數(shù)據(jù)流,流出的數(shù)據(jù)流,構成:[數(shù)據(jù)構造],數(shù)據(jù)量,存取方式解決過程描述:解決過程名,闡明,輸入:[數(shù)據(jù)流],輸出:[數(shù)據(jù)流],解決:[簡要闡明]ER圖表和數(shù)據(jù)字典能夠讓任何理解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。ER圖對表明表之間關系很有用,而數(shù)據(jù)字典則闡明了每個字段的用途以及任何可能存在的別名。對SQL表達式的文檔化來說這是完全必要的。1.5定義原則的對象命名規(guī)范數(shù)據(jù)庫多個對象的命名必須規(guī)范。2.表和字段的設計(數(shù)據(jù)庫邏輯設計)表設計原則1準化和規(guī)范化數(shù)據(jù)的原則化有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。原則化有好幾個形式,但ThirdNormalForm(3NF)普通被認為在性能、擴展性和數(shù)據(jù)完整性方面達成了最佳平衡。簡樸來說,恪守3NF原則的數(shù)據(jù)庫的表設計原則是:”O(jiān)neFactinOnePlace”即某個表只涉及其本身基本的屬性,當不是它們本身所含有的屬性時需進行分解。表之間的關系通過外鍵相連接。它含有下列特點:有一組表專門寄存通過鍵連接起來的關聯(lián)數(shù)據(jù)。2數(shù)據(jù)驅動采用數(shù)據(jù)驅動而非硬編碼的方式,許多方略變更和維護都會方便得多,大大增強系統(tǒng)的靈活性和擴展性。舉例,如果顧客界面要訪問外部數(shù)據(jù)源(文獻、XML文檔、其它數(shù)據(jù)庫等),不妨把對應的連接和途徑信息存儲在顧客界面支持的表里。如果顧客界面執(zhí)行工作流之類的任務(發(fā)送郵件、打印信箋、修改統(tǒng)計狀態(tài)等),那么產生工作流的數(shù)據(jù)也能夠寄存在數(shù)據(jù)庫里。角色權限管理也能夠通過數(shù)據(jù)驅動來完畢。事實上,如果過程是數(shù)據(jù)驅動的,你就能夠把相稱大的責任推給顧客,由顧客來維護自己的工作流過程。3考慮多個變化在設計數(shù)據(jù)庫的時候考慮到哪些數(shù)據(jù)字段將來可能會發(fā)生變更。4表名、報表名和查詢名的命名規(guī)范(采用前綴命名)檢查表名、報表名和查詢名之間的命名規(guī)范。你可能會很快就被這些不同的數(shù)據(jù)庫要素的名稱搞糊涂了。你能夠統(tǒng)一地命名這些數(shù)據(jù)庫的不同構成部分,最少你應當在這些對象名字的開頭用Table、Query或者Report等前綴加以區(qū)別。如果采用了MicrosoftAccess,你能夠用qry、rpt、tbl和mod等符號來標記對象(例如tbl_Employees)。用sp_company標記存儲過程,用udf_(或者類似的標記)標記自定義編寫的函數(shù)。字段設計原則:1每個表中都應當添加的3個有用的字段。dRecordCreationDate,在SQLServer下默認為GETDATE()sRecordCreator,在SQLServer下默認為NOTNULLDEFAULTUSERnRecordVersion,統(tǒng)計的版本標記;有助于精確闡明統(tǒng)計中出現(xiàn)null數(shù)據(jù)或者丟失數(shù)據(jù)的因素時效性數(shù)據(jù)應涉及”近來更新日期/時間”字段。時間標記對查找數(shù)據(jù)問題的因素、按日期重新解決/重載數(shù)據(jù)和去除舊數(shù)據(jù)特別有用。2對地址和電話采用多個字段描述街道地址就短短一行統(tǒng)計是不夠的。Address_Line1、Address_Line2和Address_Line3能夠提供更大的靈活性。尚有,電話號碼和郵件地址最佳擁有自己的數(shù)據(jù)表,其間含有本身的類型和標記類別。3表內的列[字段]的命名規(guī)則(采用前綴/后綴命名)、采用故意義的字段名對列[字段]名應當采用原則的前綴和后綴。如鍵是數(shù)字類型:用_N后綴;字符類型:_C后綴;日期類型:_D后綴。再如,如果你的表里有好多”money”字段,你不妨給每個列[字段]增加一種_M后綴。假設有兩個表:Customer和Order。Customer表的前綴是cu_,因此該表內的子段名以下:cu_name_id、cu_surname、cu_initials和cu_address等。Order表的前綴是or_,因此子段名是:or_order_id、or_cust_name_id、or_quantity和or_description等。這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的SQL語句能夠寫成以下所示:Select*FromCustomer,OrderWherecu_surname="MYNAME";andcu_name_id=or_cust_name_idandor_quantity=1在沒有這些前綴的狀況下則寫成這個樣子(用別名來分辨):Select*FromCustomer,OrderWhereCustomer.surname="MYNAME";andC_id=Order.cust_name_idandOrder.quantity=1第1個SQL語句沒少鍵入多少字符。但如果查詢涉及到5個表乃至更多的列[字段]你就懂得這個技巧多有用了。5選擇數(shù)字類型和文本類型的長度應盡量充足假設客戶ID為10位數(shù)長。那你應當把數(shù)據(jù)庫表字段的長度設為12或者13個字符長。但這額外占據(jù)的空間卻無需將來重構整個數(shù)據(jù)庫就能夠實現(xiàn)數(shù)據(jù)庫規(guī)模的增加了。6增加刪除標記字段在表中包含一種”刪除標記”字段,這樣就能夠把行標記為刪除。在關系數(shù)據(jù)庫里不要單獨刪除某一行;最佳采用去除數(shù)據(jù)程序并且要認真維護索引整體性。7提防大小寫混用的對象名和特殊字符采用全部大寫并且包含下劃符的名字含有更加好的可讀性(CUSTOMER_DATA),絕對不要在對象名的字符之間留空格。8小心保存詞要確保你的字段名沒有和保存詞、數(shù)據(jù)庫系統(tǒng)或者常見訪問辦法沖突,例如,用DESC作為闡明字段名。后果可想而知!DESC是DESCENDING縮寫后的保存詞。表里的一種SELECT*語句倒是能用,但得到的卻是一大堆毫無用處的信息。9保持字段名和類型的一致性在命名字段并為其指定數(shù)據(jù)類型的時候一定要確保一致性。如果字段在表1中叫做”agreement_number”,就別在表2里把名字改成”ref1”。如果數(shù)據(jù)類型在表1里是整數(shù),那在表2里可就別變成字符型了。固然在表1(ABC)有處鍵ID,則為了可讀性,在表2做關聯(lián)時能夠命名為ABC_ID。10避免使用觸發(fā)器觸發(fā)器的功效普通能夠用其它方式實現(xiàn)。在調試程序時觸發(fā)器可能成為干擾。如果你確實需要采用觸發(fā)器,你最佳集中對它文檔化。3.選擇鍵和索引(數(shù)據(jù)庫邏輯設計)參考:《SQL優(yōu)化-索引》一文4.數(shù)據(jù)完整性設計(數(shù)據(jù)庫邏輯設計)1完整性實現(xiàn)機制:實體完整性:主鍵參考完整性:父表中刪除數(shù)據(jù):級聯(lián)刪除;受限刪除;置空值父表中插入數(shù)據(jù):受限插入;遞歸插入父表中更新數(shù)據(jù):級聯(lián)更新;受限更新;置空值DBMS對參考完整性能夠有兩種辦法實現(xiàn):外鍵實現(xiàn)機制(約束規(guī)則)和觸發(fā)器實現(xiàn)機制顧客定義完整性:NOTNULL;CHECK;觸發(fā)器2用約束而非商務規(guī)則強制數(shù)據(jù)完整性采用數(shù)據(jù)庫系統(tǒng)實現(xiàn)數(shù)據(jù)的完整性。這不僅涉及通過原則化實現(xiàn)的完整性并且還涉及數(shù)據(jù)的功效性。不要依賴于商務層確保數(shù)據(jù)完整性;它不能確保表之間(外鍵)的完整性因此不能強加于其它完整性規(guī)則之上。如果你在數(shù)據(jù)層確實采用了約束,你要確保有方法把更新不能通過約束檢查的因素采用顧客理解的語言告知顧客界面。3強制批示完整性在有害數(shù)據(jù)進入數(shù)據(jù)庫之前將其剔除。激活數(shù)據(jù)庫系統(tǒng)的批示完整性特性。這樣能夠保持數(shù)據(jù)的清潔而能迫使開發(fā)人員投入更多的時間解決錯誤條件。4使用查找控制數(shù)據(jù)完整性控制數(shù)據(jù)完整性的最佳方式就是限制顧客的選擇。只要有可能都應當提供應顧客一種清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數(shù)據(jù)的一致性。某些公共數(shù)據(jù)特別適合查找:國家代碼、狀態(tài)代碼等。5采用視圖為了在數(shù)據(jù)庫和應用程序代碼之間提供另一層抽象,能夠為應用程序建立專門的視圖而不必非要應用程序直接訪問數(shù)據(jù)表。這樣做還等于在解決數(shù)據(jù)庫變更時給你提供了更多的自由。6分布式數(shù)據(jù)系統(tǒng)對分布式系統(tǒng)而言,在你決定與否在各個站點復制全部數(shù)據(jù)還是把數(shù)據(jù)保存在一種地方之前應當預計一下將來5年或者10年的數(shù)據(jù)量。當你把數(shù)據(jù)傳送到其它站點的時候,最佳在數(shù)據(jù)庫字段中設立某些標記,在目的站點收到你的數(shù)據(jù)之后更新你的標記。為了進行這種數(shù)據(jù)傳輸,請寫下你自己的批解決或者調度程序以特定時間間隔運行而不要讓顧客在每天的工作后傳輸數(shù)據(jù)。本地拷貝你的維護數(shù)據(jù),例如計算常數(shù)和利息率等,設立版本號確保數(shù)據(jù)在每個站點都完全一致。7關系如果兩個實體之間存在多對一關系,并且尚有可能轉化為多對多關系,那么你最佳一開始就設立成多對多關系。從現(xiàn)有的多對一關系轉變?yōu)槎鄬Χ嚓P系比一開始就是多對多關系要難得多。8給數(shù)據(jù)保有和恢復制訂計劃考慮數(shù)據(jù)保存方略并包含在設計過程中,預先設計你的數(shù)據(jù)恢復過程。采用能夠公布給顧客/開發(fā)人員的數(shù)據(jù)字典實現(xiàn)方便的數(shù)據(jù)識別同時確保對數(shù)據(jù)源文檔化。編寫在線更新來”更新查詢”供后來萬一數(shù)據(jù)丟失能夠重新解決更新。9用存儲過程讓系統(tǒng)做重活提供一整套常規(guī)的存儲過程來訪問各組方便加緊速度和簡化客戶程序代碼的開發(fā)。數(shù)據(jù)庫不只是一種寄存數(shù)據(jù)的地方,它也是簡化編碼之地。5.其它設計技巧1避免使用觸發(fā)器觸發(fā)器的功效普通能夠用其它方式實現(xiàn)。在調試程序時觸發(fā)器可能成為干擾。如果你確實需要采用觸發(fā)器,你最佳集中對它文檔化。2使用常見英語(或者其它任何語言)而不要使用編碼在創(chuàng)立下拉菜單、列表、報表時最佳按照英語名排序。如果需要編碼,能夠在編碼旁附上顧客懂得的英語。3保存常見信息讓一種表專門寄存普通數(shù)據(jù)庫信息非常有用。在這個表里寄存數(shù)據(jù)庫現(xiàn)在版本、近來檢查/修復(對Access)、關聯(lián)設計文檔的名稱、客戶等信息。這樣能夠實現(xiàn)一種簡樸機制跟蹤數(shù)據(jù)庫,當客戶埋怨她們的數(shù)據(jù)庫沒有達成但愿的規(guī)定而與你聯(lián)系時,這樣做對非客戶機/服務器環(huán)境特別有用。4包含版本機制在數(shù)據(jù)庫中引入版本控制機制來擬定使用中的數(shù)據(jù)庫的版本。時間一長,顧客的需求總是會變化的。最后可能會規(guī)定修改數(shù)據(jù)庫構造。把版本信息直接寄存到數(shù)據(jù)庫中更為方便。5編制文檔對全部的快捷方式、命名規(guī)范、限制和函數(shù)都要編制文檔。采用給表、列、觸發(fā)器等加注釋的數(shù)據(jù)庫工具。對開發(fā)、支持和跟蹤修改非常有用。對數(shù)據(jù)庫文檔化,或者在數(shù)據(jù)庫本身的內部或者單獨建立文檔。這樣,當過了一年多時間后再回過頭來做第2個版本,出錯的機會將大大減少。6測試、測試、重復測試建立或者修訂數(shù)據(jù)庫之后,必須用顧客新輸入的數(shù)據(jù)測試數(shù)據(jù)字段。最重要的是,讓顧客進行測試并且同顧客一道確保選擇的數(shù)據(jù)類型滿足商業(yè)規(guī)定。測試需要在把新數(shù)據(jù)庫投入實際服務之前完畢。7檢查設計在開發(fā)期間檢查數(shù)據(jù)庫設計的常見技術是通過其所支持的應用程序原型檢查數(shù)據(jù)庫。換句話說,針對每一種最后表達數(shù)據(jù)的原型應用,確保你檢查了數(shù)據(jù)模型并且查看如何取出數(shù)據(jù)。三、數(shù)據(jù)庫命名規(guī)范1.實體(表)的命名1.1基本原則命名以表述實體的真實含義、方便識別為目的,盡量不采用縮寫,盡量使用大寫或大寫首字母英文單詞,不使用復數(shù)。同一字段名在數(shù)據(jù)庫中應保持含義相似。不同含義的實體應當采用不同的字符表達,單詞間使用”-”分隔。嚴禁使用中文或拼音縮寫進行命名,表名、字段名、視圖名長度控制在5個單詞之內,總長度不大于30個字符1.2如遇單詞太長,可采用縮寫,選擇次序以下首選在命名規(guī)范”常見縮寫”中列示的縮寫。行業(yè)商定被廣泛接受的縮寫。元音字母剔除法生成的縮寫,縮寫后長度應控制在5個字符以內,大寫表達,但需在項目詞匯表列示。1.3對表的命名1)表以名詞或名詞短語命名,擬定表名是采用復數(shù)還是單數(shù)形式,另外給表的別名定義簡樸規(guī)則(比方說,如果表名是一種單詞,別名就取單詞的前4個字母;如果表名是兩個單詞,就各取兩個單詞的前兩個字母構成4個字母長的別名;如果表的名字由3個單詞構成,從頭兩個單詞中各取一種然后從最后一種單詞中再取出兩個字母,成果還是構成4字母長的別名,其它依次類推)對工作用表來說,表名能夠加上前綴WORK_背面附上采用該表的應用程序的名字。在命名過程當中,根據(jù)語義拼湊縮寫即可。注意:將字段名稱會統(tǒng)一成大寫或者小寫中的一種,故中間加上下劃線。舉例:基本辦法:業(yè)務分類+表實體+可選的后綴Train_Exam_Result培訓考試分值表Train_Exam_Student培訓考試學生信息表Train表達培訓業(yè)務的分類,Exam表達考試實體,Result表達考試計劃實體計劃的后綴2)如果表或者是字段的名稱僅有一種單詞,那么建議不使用縮寫,而是用完整的單詞。舉例:定義的縮寫MaterialMa物品;物品表名為:Material,而不是Ma.可是字段物品編碼則是:Ma_ID;而不是Material_ID3)全部的存儲值列表的表前面加上前綴Z目的是將這些值列表類排序在數(shù)據(jù)庫最后。4)全部的冗余類的命名(重要是累計表)前面加上前綴X冗余類是為了提高數(shù)據(jù)庫效率,非規(guī)范化數(shù)據(jù)庫的時候加入的字段或者表5)關聯(lián)類通過用下劃線連接兩個基本類之后,再加前綴R的方式命名,背面按照字母次序羅列兩個表名或者表名的縮寫。關聯(lián)表用于保存多對多關系。如果被關聯(lián)的表名不不大于10個字母,必須將原來的表名的進行縮寫。如果沒有其它因素,建議都使用縮寫。舉例:表Object與本身存在多對多的關系,則保存多對多關系的表命名為:R_Object;表Depart和Employee;存在多對多的關系;則關聯(lián)表命名為R_Dept_Emp2.屬性(列)的命名1)采用故意義的列名列名以精確表述實體屬性為目的。由于在表的命名上加入了對實體業(yè)務的分類,在不發(fā)生歧義的狀況下,在列名命名上能夠不再添加分類前綴。表內的列要針對鍵采用一整套設計規(guī)則。每一種表都將有一種自動ID作為主健,邏輯上的主健作為第一組候選主健來定義;A、如果是數(shù)據(jù)庫自動生成的編碼,統(tǒng)一命名為:PK_IDB、如果是自定義的邏輯上的編碼則用縮寫加”ID”的辦法命名,即”XXXX_PK_IDC、如果鍵是數(shù)字類型,你能夠用_NO作為后綴;D、如果是字符類型則能夠采用_CODE后綴E、對列名應當采用原則的前綴和后綴。舉例:銷售訂單的編號字段命名:Sal_Ord_ID如果還存在一種數(shù)據(jù)庫生成的自動編號,則命名為:PK_ID注意:在數(shù)據(jù)庫設計時需要注意數(shù)據(jù)類型的選擇,應遵照”數(shù)字優(yōu)先、定長優(yōu)先”原則2)全部的屬性加上有關類型的后綴注意,如果還需要其它的后綴,都放在類型后綴之前。注:數(shù)據(jù)類型是文本的字段,類型后綴TX能夠不寫。有些類型比較明顯的字段,能夠不寫類型后綴。3)采用前綴命名給每個表的列名都采用統(tǒng)一的前綴,那么在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點,例如破壞了自動表連接工具的作用,后者把公共列名同某些數(shù)據(jù)庫聯(lián)系起來。3.視圖的命名1)視圖以V作為前綴+有含義的命名(基本表)命名規(guī)則和表的命名類似;例Vi_Cus

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論