1.本技術涉及數據治理技術領域，具體而言涉及一種高校數據資源目錄整合系統及方法。

背景技術：

2.數據資源目錄的建設是構建高校數據中心工作中至關重要的一環，在梳理數據資產和構建數據中臺化治理過程中起到承上啟下的作用。但是，目前數據資源整體建設層面還存在以下問題：1、缺乏統一的數據視圖。數據的管理人員和使用人員無法準確快速地找到自己需要的數據。數據的管理人員也無法從宏觀層面掌握自己擁有哪些數據資產，擁有多少數據資產。這些數據資產分布在哪里，以及變化情況怎樣等。

3.2、數據價值難估。難以對數據對業務和應用的貢獻進行評估，從而難以像運營有形資產一樣運營數據。產生這個問題的原因有兩個，意思沒有建立起合理的數據價值評估模型，二是缺乏對不同應用場景下數據資產使用情況的統計。

4.3、缺乏安全的數據環境。目前學校大部分的數據開放是通過點對點式申請、授權使用，當數據大范圍開放時還需要對整體數據的管理、確權、認領等機制進行統一的管理，提升數據環境的安全系數，保障個人和學校數據隱私。

5.4、數據質量不透明。目前業務部門在使用數據時無法做的責權明確，導致在數據使用上存在冗余，數據泄密等情況。而統一數據多個來源既帶來數據重復又無法明確數據的權威性，導致數據糾錯補錄實施起來極為困難。以上現狀導致數據質量：不一致、不準確、不及時、不唯一、不完整、空數據等情況，但是由于數據隱藏在業務系統背后，導致質量問題不便跟蹤和追溯，從而導致數據質量問題處理過程不透明，無法閉環。

6.這些問題已經影響到數據價值的發揮，導致數據越積越多而整體管理、使用及安全問題變得很難控制，逐漸成為數據管理負擔。。

技術實現要素：

7.本技術針對現有技術的不足，提供一種高校數據資源目錄整合系統及方法，本技術在數據治理的過程中通過業務端、數據端和信息中心之間的協同實現數據確權認領，通過數據字典表的檢查維護實現新業務數據從數據接入到資源目錄的自動維護更新，面向決策層，形成統一的、邏輯上的、全局的學校數據視圖，基于數據治理建設成果構建高校數據資源目錄，按照校級統一的標準規范實現對數據資源的梳理、元數據采集、描述、編目、分類目錄管理和可視化數據的展現，進而將各類數據資源按照校級資源目錄進行呈現。本技術具體采用如下技術方案。

8.首先，為實現上述目的，提出一種高校數據資源目錄整合系統，其包括：業務端，用于供業務廠商設置業務系統全量數據字典表，通過數據字典表對系統中數據表、數據字段的含義進行標準化定義，以作為數據廠商提供業務數據、對數據進行答疑確認調研工作的

標準依據；數據端，用于供數據廠商接入業務數據，通過對業務數據的檢查核對，根據數據字典表建立數據資源模型，通過數據治理、數據資源統一整合實現數據集成；信息中心，用于對數據字典表中更新內容進行審核，協助數據廠商進行數據確認，將確認后數據通過治理平臺對接相應的權責部門，根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，并根據更新內容協調業務廠商更新標準化定義。

9.可選的，如上任一所述的高校數據資源目錄整合系統，其中，所述業務端包括：數據字典表生成單元，用于為數據廠商提供業務系統全量數據字典表，接收信息中心根據新增業務內容擴展出的新需求而對標準化定義進行的更新；數據確權反饋單元，用于通過數據認領、數據仲裁方式調整由信息中心更新后數據字典表中各數據表、數據字段所對應的權責部門；其中，所述數據字典表包含對數據表、數據字段對應含義的具體說明和定義。

10.可選的，如上任一所述的高校數據資源目錄整合系統，其中，所述數據端包括：檢查核對單元，用于根據業務端所提供的數據字典表對業務數據數據表、數據字段進行分類整合，整合后根據各字段所對應業務廠商及部門確認的在線調研結果對數據字典中標準化定義進行檢查；數據資源建模單元，用于根據國際標準模型采用標準模型規范建立數據資源模型，并對國際標準模型外的數據表及數據字段按照數據字典中標準化定義新建模型并向信息中心反饋；數據集成單元，用于在接收到信息中心對新建模型規范性的確認后進行數據集成，同步數據；質檢對標單元，用于對數據集成后是否符合數據字典中標準化定義進行檢測。

11.可選的，如上任一所述的高校數據資源目錄整合系統，其中，所述信息中心設置有：審核單元，用于對國際標準模型外數據表及數據字段所建立的新建模型進行審核，確認數據集分類規范，數據命名規范，保障資源目錄規范性擴展；確認同步單元，用于協助數據廠商進行數據確認，將確認后數據通過治理平臺對接相應的權責部門；新需求擴展單元，用于根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，業務廠商在收到新增業務相關內容后并根據更新內容協調業務廠商更新標準化定義。

12.可選的，如上任一所述的高校數據資源目錄整合系統，其中，所述治理平臺用于對接相應的權責部門，在對相應數據表、數據字段進行數據集成的同時，根據業務廠商調研反饋的結果，在治理平臺所對應的數據模型上預置對應權責部門。

13.可選的，如上任一所述的高校數據資源目錄整合系統，其中，所述資源目錄用于根據權責部門對數據的維護，按照治理平臺的數據模型自動更新資源目錄。

14.同時，為實現上述目的，本技術還提供一種高校數據資源目錄整合方法，其步驟包括：第一步，由業務廠商設置業務系統全量數據字典表，通過數據字典表對系統中數據表、數據字段的含義進行標準化定義，以作為數據廠商提供業務數據、對數據進行答疑確認調研工作的標準依據；第二步，由數據廠商接入業務數據，通過對業務數據的檢查核對，根據數據字典表建立數據資源模型，通過數據治理、數據資源統一整合實現數據集成；第三步，在信息中心對數據字典表中更新內容進行審核，協助數據廠商進行數據確認，將確認后數據通過治理平臺對接相應的權責部門，并根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，根據更新內容協調業務廠商更新標準化定義。

15.可選的，如上任一所述的高校數據資源目錄整合方法，其中，所述數據字典表包含對數據表、數據字段對應含義的具體說明和定義；所述第一步具體包括：步驟101，為數據廠

商提供業務系統全量數據字典表，接收信息中心根據新增業務內容擴展出的新需求而對標準化定義進行更新；步驟102，通過數據認領、數據仲裁方式調整由信息中心更新后數據字典表中各數據表、數據字段所對應的權責部門。

16.可選的，如上任一所述的高校數據資源目錄整合方法，其中，第二步具體包括：步驟201，根據業務端所提供的數據字典表對業務數據數據表、數據字段進行分類整合，整合后根據各字段所對應業務廠商及部門確認的在線調研結果對數據字典中標準化定義進行檢查；步驟202，根據國際標準模型采用標準模型規范建立數據資源模型，并對國際標準模型外的數據表及數據字段按照數據字典中標準化定義新建模型并向信息中心反饋；步驟203，在接收到信息中心對新建模型規范性的確認后進行數據集成，同步數據；步驟204，在數據集成后對其是否符合數據字典中標準化定義進行檢測。

17.可選的，如上任一所述的高校數據資源目錄整合方法，其中，所述第三步具體包括：步驟301，對國際標準模型外數據表及數據字段所建立的新建模型進行審核，確認數據集分類規范，數據命名規范，保障資源目錄規范性擴展；步驟302，協助數據廠商進行數據確認，將確認后數據通過治理平臺對接相應的權責部門；步驟303，根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，業務廠商在收到新增業務相關內容后并根據更新內容協調業務廠商更新標準化定義。

18.有益效果本技術通過供業務商設置業務系統全量數據字典表的業務端，供數據廠商接入業務數據進行檢查核對建立數據資源模型實現數據集成的數據端，以及連接治理平臺協調數據廠商更新標準化定義的信息中心，通過數據資源目錄實現各類數據資源的統一整合，構建數據分析應用，優化數據擁有單位的經營管理，優化數據庫架構并通過權責部門的設置實現如下建設效益：從業務運用角度，業務發展加快了數據膨脹的速度，也帶來數據不統一的問題，業務部門頻繁增加和剝離同樣對數據管理提出挑戰。而數據資產目錄的目的就是把數據定義清楚，提升數據質量，然后進一步做整合、構建數據分析應用，優化數據擁有單位的經營管理，創造業務價值；從數據質量提升角度，有了數據資源目錄，方便我們去做數據分類分級方面的工作，規定不同的安全等級，確保數據安全可控。一數一源不僅可以優化數據庫架構提高效率，同時明確數據來源可以及時進行數據糾錯補錄，持續提升數據質量；從建設效果展示上來說，數據資源目錄可以驗證數據中心工作進度，可視化的數據資源目錄可以直觀得展示工作量，例如：數據源集成數量，可供調取的api開發數量等；在數據建設方面通過數據認領的方式，明確數據來源責任到人，基于誰提交誰治理的理念，嚴格保障“一數一源”，構建數據oa協同化治理平臺，用任務下派消息提醒的方式，保證數據治理的及時性，明確性，便捷性。

19.本技術的其它特征和優點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本技術而了解。

附圖說明

20.附圖用來提供對本技術的進一步理解，并且構成說明書的一部分，并與本技術的

實施例一起，用于解釋本技術，并不構成對本技術的限制。在附圖中：圖1是本技術的高校數據資源目錄整合系統的工作流程示意圖。

具體實施方式

21.為使本技術實施例的目的和技術方案更加清楚，下面將結合本技術實施例的附圖，對本技術實施例的技術方案進行清楚、完整地描述。顯然，所描述的實施例是本技術的一部分實施例，而不是全部的實施例。基于所描述的本技術的實施例，本領域普通技術人員在無需創造性勞動的前提下所獲得的所有其他實施例，都屬于本技術保護的范圍。

22.本技術領域技術人員可以理解，除非另外定義，這里使用的所有術語（包括技術術語和科學術語）具有與本技術所屬領域中的普通技術人員的一般理解相同的意義。還應該理解的是，諸如通用字典中定義的那些術語應該被理解為具有與現有技術的上下文中的意義一致的意義，并且除非像這里一樣定義，不會用理想化或過于正式的含義來解釋。

23.數據資源目錄的建設是構建高校數據中心工作中至關重要的一環，在梳理數據資產和構建數據中臺化治理過程中起到承上啟下的作用。面向國家教育發展戰略中對信息化、智能化校園的要求，構建數據資源目錄能夠幫助高校完整梳理數據來源，完善數據治理流程，持續提升數據質量，從而能夠宏觀得構建高校數字化整體架構，為高校數據中心建設統一范式，為人才畫像數據提供全類型標簽，為數據共享提供高效便捷的檢索條件，為數據安全提供監控渠道，為數據質量提升提供數據血緣追溯渠道，為精準化管理和數字化決策提供元數據的支撐。

24.圖1為根據本技術的一種高校數據資源目錄整合系統，其包括：業務端，用于供業務廠商設置業務系統全量數據字典表，通過數據字典表對系統中數據表、數據字段的含義進行標準化定義，以作為數據廠商提供業務數據、對數據進行答疑確認調研工作的標準依據；數據端，用于供數據廠商接入業務數據，通過對業務數據的檢查核對，根據數據字典表建立數據資源模型，通過數據治理、數據資源統一整合實現數據集成；信息中心，用于對數據字典表中更新內容進行審核，協助數據廠商進行數據確認，將確認后數據通過治理平臺對接相應的權責部門，根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，并根據更新內容協調業務廠商更新標準化定義。

25.該系統工作過程如下：01.由業務端的數據字典表生成單元提供數據字典：業務廠商為數據廠商首先提供業務系統全量數據字典表，通過數據字典表對系統中數據表、數據字段的含義進行標準化定義和說明，以作為數據廠商提供業務數據、對數據進行答疑確認調研工作的標準依據。

26.02.由數據端的檢查核對單元進行檢查核對：數據廠商對提供的數據字典表對表、字段進行分類整合；整合后接入業務數據，進行在線調研。調研結果可分別發送至各數據所屬部門字段，交由業務廠商及部門確認。調研結束后根據權責部門對數據的維護更新按照數據資源模型自動更新資源目錄，根據更新內容協調業務廠商更新標準化定義。權責部門對數據進行維護更新時，還相應更新對數據目錄下個數據資源項的數據管理人、數據錄入方式的標記，以明確數據管理方式，并通過維護過程中形成的維護日志記錄數據維護周期、維護方式：

03.由數據端的數據資源建模單元在數據治理平臺上進行數據資源建模：建立模型的標準主要分為如下兩個方面，其中，對于已具備國際標準的數據資源，需按照標準規范建立模型：根據標準要求，分別將表及字段含義調整至符合內置國標標準模型要求，采用標準模型規范命名表及字段，以確保數據安全。標準模型中，數據需依法合規進行規范化管理，并按照學校頒布的數據資產管理辦法對數據的調取、應用、數據接口、數據驗證要求、數據存儲方式進行規范化設置，以依據統一的制度保障數據開放使用的安全性；對于新建的數據資源，例如，業務新增表及字段：需對現有標準模型外的相關表及字段，按照標準規范新建模型，并向信息中心進行反饋。

27.04.由信息中心的審核單元：對新建表或字段進行審核，確認數據集分類規范，數據命名規范，保障資源目錄規范性擴展。

28.05.由數據廠商的數據集成單元在信息中心確認數據模型規范性后，進行數據集成，同步數據。數據集成過程中，按照標準規范要求設置數據申請、審核機制，并通過api接口實時調取處理終端對數據資源的使用狀況，在監測到終端對數據的調取和使用超出預先設定的權限范圍后觸發接口撤回已調取數據以確保數據專事專用、最小夠用、未經許可不得留存，杜絕數據被誤用、濫用。在滿足各方合理需求前提下，最大限度保障數據所有方權益，確保數據使用合規、范圍可控。

29.06.觸發治理平臺在數據集成的同時，根據和業務廠商調研反饋的結果，在治理平臺上數據模型上預置好對應權責部門，確保“一數一源”。

30.07.通過治理平臺的數據模型及權責部門自動更新資源目錄，通過對學校數據資產進行全面的梳理，形成數據資產目錄并按目錄區分各自責任，明確一數一源。

31.08.在信息中心收到業務廠商相關新需求，例如：新增業務時，還觸發系統返回01步提供相應字典表由數據廠商核對檢查，并針對該新需求重新執行02至07步，實現對新需求以及相應數據資源的梳理。

32.上述步驟中，02.檢查核對（數據調研反饋）、04.審核（信息中心）都可通過如下的技術手段在平臺上在線完成。

33.步驟02中，由數據廠商接入業務數據，通過數據端的檢查核對單元對業務數據進行檢查核對分類整合的具體步驟中：由數據廠商對提供的數據字典表對表、字段進行分類整合。整合過程中，首先根據數據字典表中對系統數據表、數據字段的標準化定義進行特征提取，比如，按照標準化的數據特征對數據進行深度可分離的逐通道卷積，提取出分別對應于數據物理量、統計來源、權責部門、數據類型、數值范圍、運算規則等參數，獲得標準化的數據結構特征，然后根據標準化的數據結構特征調取與之對應的整合模塊，通過整合模塊中預先設定的數據整合規則，將業務數據中各項內容按照數據整合規則所確定的整合順序、統計運算規則、權責部門標記規則進行整合。其中，各整合模塊預先由系統根據數據整合要求以及數據本身的結構特征、內容特征由數據廠商預先進行設定，以滿足信息中心的數據需求。

34.步驟02中，整合后接入業務數據，進行在線調研的過程中：調研結果可分別發送至各數據所屬部門字段，交由業務廠商及部門確認。調研結束后根據權責部門對數據進行維護更新，按照實際使用需求相應向數據廠商反饋對整合模塊的改進需求，由數據廠商根據

需求相應調整整合模塊所設定的數據整合規則，相應調整針對特定數據結構特征的整合模塊的整合順序、統計運算規則、權責部門標記規則等。將調整后的數據整合規則更新進入數據資源模型，以自動更新資源目錄。

35.當系統中產生新的未曾定義的內容數據時，觸發系統執行08步驟：由信息中心根據新增業務內容擴展出的新需求而對標準化定義進行的更新，對業務廠商提供更新的標準化定義要求，由此，業務廠商能夠根據更新內容協調更新標準化定義。

36.本技術中以平臺化、系統化的方式對高效數據資源進行統一管理。數據存儲的物理介質并不需要集中設置。本系統定義由標準化數據接口實現數據資源的接入和調取，但不提供數據的對外留存接口，因此，各個分散的物理存儲介質上均可按照本系統的標準模型存儲數據。本技術通過對各類型數據資源發布規范標準并相應建立模型，實現對資源管理邏輯的集中。能夠在不影響業務數據資源日常管理的前提下，通過信息中心發布數據管理需求，由數據廠商和業務廠商相互協調實現對數據資源管理邏輯上的更新。由此，本技術能夠根據信息中心的數據處理需求而靈活梳理各類數據資源，構建適應于信息中心具體業務需求和管理標準的數據資源目錄，保障各業務單元穩定運行，邏輯上集中管理數據資產。

37.由此，本技術通過業務端、數據端以及信息中心之間的協同，在調研的任務的同時對數據進行確權的工作，可方便新業務數據的數據接入，保證數據的完整性并保證數據的業務含義確保數據資源規范化分類，實現如下功能：1、統一的元數據管理，包括資源注冊、資源掛接、資源管理、資源同步、數據維護。本技術通過數據字典表、符合標準模型規范的數據資源模型等手段配合于高校自身的信息化管理辦法、數據資源管理辦法等，制定硬性的數據管理標準，保障數據資源目錄建設持久有序發展。

38.2、明確的數據資源分類，包括資源目錄分類、自定義多級子分類、分類啟動/停用、權限下發。

39.3、靈活的資源編目，包括歸類管理、目錄發布、編目管理、二級授權。

40.4、用于動態運行的數據資源掛載，包括資源掛載、目錄維護、二級授權、資源審核。

41.5、本技術中通過資源分配、任務發布、數據認領、數據審批等過程實現對數據資源的認領和權責管理，實現一數一源。通過數據認領、在線數據確權、數據仲裁，并通過權責部門標記實現數據質量問題可追溯，做到誰產生、誰維護。由此，本技術的系統具有較高的在線數據資源管理能力，能夠直接通過權責部門標記明確源數據管理的唯一主體。僅具備權責部門標記的部門才可對實體存儲介質中存儲的數據資源進行校驗、更新等維護工作，由此可保障本系統內數據資源的完整性、準確性和一致性，減少重復收集造成的資源浪費和數據冗余。同時，本技術還通過數據字典表生成單元、檢查核對單元、數據資源建模單元、數據集成單元、資源目錄幾個模塊共同建立了數據規范標準，實現統一規范下的數據共享機制，通過對數據進行統一化、標準化的管理，能夠有效提升數據利用效率和應用水平，實現數據多向賦能。

42.6、通過規范的資源發布管理，包括提交目錄、編目調整、發布審核、批量審核等手段，梳理數據關系，統一數據視圖，定位數據問題，逐步實現學校數據的準確性、一致性和規范性。

43.7、實現面向數據相關人員的三清單一目錄體系，構建統一的資源目錄基礎上，形

成各數據相關部門或人員的責任清單（管理的數據）、權利清單（使用的數據）和問題清單（質量問題處理）。

44.綜上，本技術能夠形成一套高校數據資產的清單目錄，面向校內數據分析師、信息中心數據管理專員和其他部門的數據用戶提供校園基礎數據和指標數據資產。本技術可根據業務價值目標更好地查找、理解和使用相關的數據資產，通過如下方式實現釋放數據價值、促進數據安全共享、提升學校治理能力三個目的：通過不斷匯聚、整合分散在各個業務系統、各個線上線下流程以及各個“機器”中的數據，統一編目、統一鑒權、統一開放，建設形成數據資源清單，基于時間、數據來源、數據類型、數據應用場景等維度輸出數據資產，便于數據使用者在線查找、使用數據資源；將數據資產以公開、透明、安全的方式編目呈現，各數據使用單位和個人能夠在線申請、發布數據資產信息，形成開放的數據共享、互惠互利的數據資源平臺，促進各類數據的流動和共享，進一步提升數據資產的價值；通過在線（pc或移動端）的認領、仲裁、編目、發布等一系列自動化辦公手段，統一管理數據資產，使得數據管理者（信息化部門、數據資源管理部門）全局掌控數據資產的產生、流動、共享、質量反饋和使用情況；讓數據提供者（各業務部門、數據生產源頭）了解數據供給、質量反饋和共享使用情況，可在線管理數據編目，在線監控其管控范圍內的數據資源實時狀態；通過便捷的辦公手段，共同促進數據資產生態的建設，變相提升學校數據、業務的治理能力。

45.以上僅為本技術的實施方式，其描述較為具體和詳細，但并不能因此而理解為對本技術專利范圍的限制。應當指出的是，對于本領域的普通技術人員來說，在不脫離本技術構思的前提下，還可以做出若干變形和改進，這些均屬于本技術的保護范圍。

實用數據庫開發實踐MySQL——數據模型

目錄

第1關 關系模型

數據庫數據模型通常可分為三種：關系模型、層次模型和網狀模型。

關系型數據模型

用二維表表示實體類型及實體間聯系的數據模型稱之為關系數據模型。

關系型數據模型對應的數據庫自然就是關系型數據庫了，這是目前應用最多的數據庫。

關系模型基本術語

在關系模型種有以下術語：

注意：關系必須是規范化的，滿足一定的規范條件。最基本的規范條件：關系的每一個分量必須是一個不可分的數據項，不允許表中還有表。

關系模型的數據操縱與完整性約束

關系模型的數據操縱主要包括查詢、插入、刪除和更新數據，它的數據操縱是集合操作，操作對象和操作結果都是關系，如關系代數。

數據及其聯系所具有的制約和依賴規則，保證數據的正確性、有效性和相容性

關系必須滿足實體完整性、參照完整性和用戶定義完整性約束

關系模型優缺點

結構簡單，都是一些表格的框架，實體的屬性是表格中列的條目，實體之間的關系也是通過表格的公共屬性表示，結構簡單明了。

存取路徑對用戶而言是完全隱蔽的，使程序和數據具有高度的獨立性，其數據語言的非過程化程度較高。

操作方便，操作的基本對象是集合而不是某一個元祖。

有堅實的數學理論做基礎，包括邏輯計算、數學計算等。

查詢效率低，關系數據模型提供了較高的數據獨立性和非過程化的查詢功能（查詢的時候只需指明數據存在的表和需要的數據所在的列，不用指明具體的查找路徑），因此加大了系統的負擔。

由于查詢效率較低，因此需要數據庫管理系統對查詢進行優化，加大了 DBMS 的負擔。

use mydb;

實驗

例如以學生選課系統為例進行說明：

學生選課系統的實體包括：學生、教師、課程；其聯系一般為學生與課程之間是一種多對多的關系，教師與課程之間是多對多的關系。學生可以同時選擇多門課程，一門課程也可以同時被多個學生同時選擇；一位教師可以教授多門課程，一門可能可以由多個教師教授。因此他們之間的聯系如下：

將該 E-R 圖映射為關系數據模型中的表格如下：

從中我們可以觀察到學生與課程之間的聯系以及教師和課程之間的多對多聯系都被映射成了表格。其中選課表中的 stu_id 和 分別是引用學生表和課程表的 的外鍵，教課表也是如此。

編程要求

編寫 SQL 語句，將 E-R 圖 轉換成二維表，創建這些轉換的表。 E-R 圖如下：

說明：一共涉及五張表，將表明分別確定為（參賽選手表）、（參賽學校表）、（參賽作品表）、（參賽選手與作品聯系表）和(參賽選手與學校聯系表)，創表時除兩張關聯表外，各字段順序按照圖中標簽順序擬定，字段類型除編號、學號、得分、電話、大小為int(11)，其他字段皆為varchar(32)。

兩張關聯表字段順序如下：

字段說明

p_id

選手編號

pr_id

作品編號

作品成績

獲獎等級

字段說明

s_name

學校名稱

p_id

選手編號

頭歌實驗代碼

#請在此添加實現代碼
########## Begin ##########
#在mydb庫中創建表
create table t_player(
    p_id int(11) NOT NULL,
    p_name varchar(32) NOT NULL,
    p_sex varchar(32) NOT NULL,
   p_num int(11) NOT NULL,
   p_email varchar(32) NOT NULL,
   PRIMARY KEY (p_id) 
);
create table t_school(
    s_name varchar (32) NOT NULL,
    s_address varchar(32) NOT NULL,
    s_telephone int(11) NOT NULL,
    s_email varchar (32) NOT NULL,
    PRIMARY KEY (s_name)
);
create table t_product(
    pr_id int(11) NOT NULL,
    pr_name varchar(32) NOT NULL,
    pr_kind varchar(32) NOT NULL,
    pr_link varchar(32) NOT NULL,
    pr_size int(11) NOT NULL,
    PRIMARY KEY (pr_id)
);
create table t_player_product(
    p_id int(11) NOT NULL,
    pr_id int(11) NOT NULL,
    pr_grade int(11) NOT NULL,
    grade_rates varchar(11) NOT NULL,
    CONSTRAINT fk_player_product1 FOREIGN KEY t_player_product(p_id) REFERENCES t_player(p_id),
    CONSTRAINT fk_player_product2 FOREIGN KEY t_player_product(pr_id) REFERENCES t_product(pr_id)
);
create table t_school_player(
    s_name varchar(32) NOT NULL,
    p_id int(11) NOT NULL,
   CONSTRAINT fk_school_stu1 FOREIGN KEY t_school_player(s_name) REFERENCES t_school(s_name),
    CONSTRAINT fk_school_stu2 FOREIGN KEY t_school_player(p_id) REFERENCES t_player(p_id)
);
########## End ##########

第2關 層次模型 層次型數據模型

層次模型是數據庫系統中最早出現的數據模型，層次數據庫系統采用層次模型作為數據的組織方式。它采用樹形結構來表示各類實體以及實體間的聯系。

其實層次數據模型就是的圖形表示就是一個倒立生長的樹，由基本數據結構中的樹（或者二叉樹）的定義可知，每棵樹都有且僅有一個根節點，其余的節點都是非根節點。每個節點表示一個記錄類型對應與實體的概念，記錄類型的各個字段對應實體的各個屬性。各個記錄類型及其字段都必須記錄。

上圖中，R1、R2 等表示實體類型，也叫做結點，每個實體類型可包含若干個屬性，也叫做字段。R1 結點和 R2 結點之間的關系叫做實體間聯系。R1 結點叫做根結點，R2 結點和 R3 結點叫做 R1 結點的子節點。R1 結點叫做 R2 結點的雙親結點。沒有子結點的結點也叫做葉結點，如 R3 、R4和 R5。

以學校某個系的組織結構為例：

層次模型的數據操縱與完整性約束

層次模型的數據操縱主要有查詢、插入、刪除和更新，進行插入、刪除、更新操作時要滿足其完整性約束條件。

無相應的雙親結點值就不能插入子女結點值

如果刪除雙親結點值，則相應的子女結點值也被同時刪除

更新操作時，應更新所有相應記錄，以保證數據的一致性

數據及其聯系所具有的制約和依賴規則

保證數據庫中數據的正確性、有效性和相容性

通過指針維護父子關系

層次模型優缺點

層次模型的數據結構比較簡單清晰

查詢效率高，性能優于關系模型，不低于網狀模型

層次數據模型提供了良好的完整性支持

結點之間的多對多聯系表示不自然

對插入和刪除操作的限制多，應用程序的編寫比較復雜

查詢子女結點必須通過雙親結點

層次命令趨于程序化???

層次模型轉化為關系模型

關系模型是現在數據庫的主流模型，要想把層次模型轉化為關系模型，只需把層次模型中的各個實體通過外鍵關聯即可。

現有一個層次模型如下：

該層次模型有三個實體，分別是系、教研室和學生。我們可以把它轉化為如下圖的關系模型：

可以看出轉化為關系模型后，依舊有3個實體，各實體之間通過系編號這一屬性形成關聯，這一屬性體現在建表語句中就是添加外鍵。

編程要求

編寫 SQL 語句，將指定的層次模型轉換為相應的關系模型后創建表并插入數據。具體要求如下：

將學生表命名為 student，教研室表命名為 edu，院系表命名為 dept，職工表命名為 emp。其中表中字段解釋如下：

字段名建表用字段名

系號

dept_id

系名

地址

addr

教研室號

edu_id

教研室名

學號

姓名

年級

職工號

emp_id

姓名

職稱

title

注意：創表時外鍵字段名和主鍵字段名一致

插入數據如下圖：

頭歌實驗代碼

#請在此添加實現代碼
########## Begin ##########
#在mydb庫中創建表并插入數據
CREATE TABLE dept (
    dept_id CHAR (3) PRIMARY KEY,
    dept_name VARCHAR (20) NOT NULL,
    addr VARCHAR (100)
);
CREATE TABLE edu (
    edu_id CHAR (3) PRIMARY KEY,
    edu_name VARCHAR (20),
    dept_id CHAR (3),
    FOREIGN KEY (dept_id) REFERENCES dept (dept_id)
);
CREATE TABLE student (
    student_id CHAR (10) PRIMARY KEY,
    student_name VARCHAR (10),
    level_class CHAR (3),
    dept_id CHAR (3),
    FOREIGN KEY (dept_id) REFERENCES dept (dept_id)
);
CREATE TABLE emp (
    emp_id CHAR (10) PRIMARY KEY,
    emp_name VARCHAR (10),
    title VARCHAR (10),
    edu_id CHAR (3),
    dept_id CHAR (3),
    FOREIGN KEY (edu_id) REFERENCES edu (edu_id),
    FOREIGN KEY (dept_id) REFERENCES dept (dept_id)
);
INSERT INTO dept VALUES ('D02', '計算機', 'R1101');
INSERT INTO edu VALUES ('R01', '數據庫', 'D02'),
                ('R02', '網絡', 'D02'),
                ('R03', '人工智能', 'D02');
INSERT INTO student VALUES ('S0012', '王明','G1','D02'),
                            ('S0020', '鄭直','G2', 'D02'),
                   ('S0199', '周密','G3', 'D02');
INSERT INTO emp VALUES ('E1101', '何璧','教授','R01', 'D02'),
                ('E3721', '劉新','講師','R01', 'D02'),
                ('E1234', '王思','教授','R03', 'D02'),
                ('E3722', '付弈','助教','R03', 'D02');
########## End ##########

第3關 網狀模型 網狀數據庫模型

對于層次和非層次結構的事物都能比較自然的模擬，在關系數據庫出現之前網狀 DBMS (數據庫任務組)要比層次 DBMS 用得普遍。

網狀型數據模型

用有向圖表示實體和實體間聯系的數據結構模型稱為網狀數據模型。

網狀模型是一種比層次模型更具普遍性的結構。滿足下面兩個條件的基本層次聯系的集合稱為網狀數據模型：①允許一個以上的結點無雙親；②一個結點可以有多于一個的雙親。

下圖即是一個簡單的網狀模型例子：

層次模型中子女結點與雙親結點的聯系是唯一的，而在網狀模型中，這種關系可以不唯一。因此節點之間的對應也就是 m:n 的關系，從而克服了層次狀數據模型的缺點。

下面以學生和課程之間的關系為例：

以課程和學生之間的關系來說，他們是一種 m:n 的關系，也就是說一個學生能夠選修多門課程，一門課程也可以被多個學生同時選修。

網狀模型的數據操縱與完整性約束

主要包括查詢、插入、刪除和更新。具體如下：

進行插入操作時，允許插入尚未確定雙親結點值的子結點值。如可增加一名尚未分配到某個教研室的新老師，也可增加一些剛來報到還未分配宿舍的學生。

進行刪除操作時，允許只刪除雙親結點值。如可刪除一個教研室，而該科研室所有教師的信息仍保留在數據庫中。

修改數據時，可直接表示非樹狀結構，而無須像層次模型那樣增加冗余結點，因此修改操作時只需要指定更新記錄即可。

進行更新操作時只需更新指定記錄即可。

一般來說，網狀模型沒有層次模型那樣嚴格的完整性約束條件，但具體的網狀數據庫系統（如 DBTG）對數據操作都加了一些限制，提供了一定的完整性約束。DBTG 在模式 DDL 中提供了定義 DBTG 數據庫完整性的若干概念和語句，主要有：

支持記錄碼的概念，碼是唯一標識記錄的數據項的集合。

保證一個聯系中雙親記錄和子記錄之間是一對多的聯系。

可以支持雙親記錄和子記錄之間某些約束條件。如有些子記錄要求雙親記錄存在才能插入，雙親記錄刪除時也連同刪除。

網狀模型優缺點

網狀數據模型可以很方便的表示現實世界中的很多復雜的關系。

修改網狀數據模型時，沒有層次狀數據模型的那么多的嚴格限制，可以刪除一個節點的父節點而依舊保留該節點；也允許插入一個沒有任何父節點的節點，這樣的插入在層次狀數據模型中是不被允許的，除非是首先插入的是根節點。

實體之間的關系在底層中可以借由指針指針實現，因此在這種數據庫中的執行操作的效率較高。

網狀數據模型的結構復雜，使用不易，隨著應用環境的擴大，數據結構越來越復雜，數據的插入、刪除牽動的相關數據太多，不利于數據庫的維護和重建。

網狀數據模型數據之間的彼此關聯比較大，該模型其實一種導航式的數據模型結構，不僅要說明要對數據做些什么，還說明操作的記錄的路徑。

DDL、DML語言復雜，用戶不容易使用。

記錄之間聯系是通過存取路徑實現的，用戶必須了解系統結構的細節。

網狀模型與層次模型

網狀模型與層次模型之間的區別：

網狀模型允許多個結點沒有雙親結點

網狀模型允許結點有多個雙親結點

網狀模型允許兩個結點之間有多種聯系（復合聯系）

網狀模型可以更直接地描述現實世界

層次模型實際上是網狀模型的一個特例

網狀模型轉化為關系模型

網狀模型轉化成關系模型只需將其網狀模型節點之間指針描述的聯系在關系模型中使用外鍵描述即可。

仍使用上面示例中學生和課程間聯系的網狀模型，我們將它轉化為關系模型后如下圖：

編程要求

編寫 SQL 語句，將指定的網狀模型轉換為相應的關系模型后創建表，并向表中插入數據。具體要求如下：

將學生表命名為 ，課程表命名為 ，關系表命名為 ，表種各字段如下：

字段名稱備注類型

s_id

學號

varchar(32)

s_name

學生姓名

varchar(32)

s_class

年級

varchar(32)

c_id

課程號

varchar(32)

c_name

課程名

varchar(32)

學分

int(3)

grade

成績

varchar(32)

學生信息和課程信息如下：

S1

張樂

大一

S2

王沖

大二

S3

翠花

大一

C1

數據庫

45

C2

python

30

表的插入數據如下圖：

頭歌實驗代碼

#請在此添加實現代碼
########## Begin ##########
CREATE TABLE t_student (
    s_id VARCHAR(32) NOT NULL,
    s_name VARCHAR(32) NOT NULL,
    s_class VARCHAR(32),
    PRIMARY KEY (s_id)
);
CREATE TABLE t_course (
    c_id VARCHAR(32) NOT NULL,
    c_name VARCHAR(32) NOT NULL,
    c_creadit INT(3),
    PRIMARY KEY (c_id)
);
CREATE TABLE t_relation (
    s_id VARCHAR(32) NOT NULL,
    c_id VARCHAR(32) NOT NULL,
    grade VARCHAR(32) NOT NULL,
    CONSTRAINT fk_1 FOREIGN KEY t_relation(s_id) REFERENCES t_student(s_id),
    CONSTRAINT fk_2 FOREIGN KEY t_relation(c_id) REFERENCES t_course(c_id)
);
INSERT INTO t_student VALUES("S1","張樂","大一"),("S2","王沖","大二"),("S3","翠花","大一");
INSERT INTO t_course VALUES("C1","數據庫",45),("C2","python",30);
INSERT INTO t_relation VALUES("S1","C1","A"),
                             ("S1","C2","A"),
                             ("S2","C1","B"),
                             ("S2","C2","A-"),
                             ("S3","C1","C");
########## End ##########