資料庫原理教學大綱

1. 資料庫原理

《資料庫原理及應用》教學大綱

課程編號 1620127 總學時 46 理論 32 實驗/上機 14
學分 2.5 開課單位 信息學院 開課系 電子工程系 修訂時間 2006年1月1日

課 程 簡 介
教學內容
《資料庫原理及應用》主要討論資料庫系統的基本概念，基本原理，基本方法以及有關的應用。
主要內容包括：資料庫系統的組成、關系資料庫、資料庫設計以及數據保護等，同時講解一種重要的資料庫系統的應用。要求學生通過本課程的學習了解有關資料庫系統的基本概念，掌握相關的知識，初步掌握資料庫設計方法，並能用資料庫系統建立資料庫及簡單的應用。
修讀專業：本大綱適合本科電子信息工程專業使用
先修課程：《數據結構》
教材：資料庫系統及應用（第二版） 「北京市高等教育精品教材」立項項目。由崔巍編著，高等教育出版社

一、 課程的性質與任務
本課程是電子信息工程專業有關資料庫的一門統設必修課。主要任務是介紹資料庫組織、管理和使用的一般知識，包括數據模型、資料庫結構、資料庫系統、資料庫設計、關系運算、關系規范化、關系查詢（sql語言）等方面的知識；介紹至少一種實際的資料庫管理系統的構成與使用。目的使學生通過該課程的學習，具有進行簡單資料庫應用系統設計與開發的能力。
二、 課程的基本要求
1．熟練掌握（代碼：A）：資料庫中的概念、資料庫設計與編程方法。資料庫的結構與特點，資料庫系統的組成及各部分的功能，熟練使用結構化查詢語言（SQL）。
2．掌握（代碼：B）：關系代數語言的使用；關系演算語言的使用；三級一致性的區別及其與可串列化調度的關系；關系資料庫以及面向對象資料庫的特點與區別；查詢表達式優化的方法。
3．了解（代碼：C）：關系、關系模型、鍵碼、視圖、函數依賴等概念
三、 修讀專業
本大綱適合本科電子信息工程專業使用
四、 本課程與其它課程的聯系
由於資料庫理論及應用是各種計算機技術的綜合應用，為了能夠讓學生很好地理解資料庫技術，要求學生在學習本課程之前最好已經學習過以下課程：《程序設計》、《數據結構》、《操作系統》等課程。當然主要要求學生具有「數據結構」的基本知識，其他課程的知識要求是其次的。
對於現行資料庫的選擇，建議教師最好選擇「Microsoft SQL Server」，其它的資料庫如：Oracle，IBM DB2相對比較難理解和應用，Access又過於簡單。
五、 教學內容安排、要求、學時分配及作業
Chapter 1 緒論（2）
1.1 什麼是資料庫(C)
1.2 資料庫管理系統(C)
1.3 資料庫管理和資料庫管理員(B)
1.4 資料庫系統(B)
1.5 資料庫的過去、現在和未來(C)
作業：第2題
Chapter 2 數據模型和三層模式資料庫（4）
2.1 信息結構與E-R方法(C)
2.2 概念數據模型(B)
2.2.3 連接陷阱(C)
2.3 傳統的三大數據模型(C)��
2.4 數據獨立性與三層結構(B)��
2.5 資料庫管理系統的結構(B)��
Chapter 3 關系資料庫（4）
3.1 關系資料庫系統概述(C)��
3.2 關系數據模型(C)��
3.3 關系模型的完整性約束(B)��
3.4 關系代數(B)��
3.5 關系資料庫系統的三層模式結構(B)��
作業：第8題--1），2）
Chapter 4 Microsoft SQL Server資料庫基礎（1）
4.1 客戶/伺服器體系結構(C)��
4.2 Microsoft SQL Server基礎(C)��
4.3 Transact-SQL簡介(C)��
Chapter 5關系資料庫標准語言——SQL（8）
5.1 SQL語言概述(B)��
5.2 SQL的數據定義功能(B)��
5.3 SQL的數據查詢功能(C)��
5.4 視圖(View) (B)�
5.5 SQL的數據操作功能(A)��
5.6 SQL的數據控制功能(A)��
5.7 SQL的宿主使用(B)��
5.8 動態SQL(B)��
作業：第2題--7），9），11 ）
Chapter 6 存儲過程、觸發器�和數據完整性（4）
6.1 存儲過程(B)��
6.2 觸發器及其用途(B)��
6.3 數據完整性(A)�
作業：第2題--3）�
Chapter 7 安全性（4）
7.1 安全性概述(C)��
7.2 用戶管理和角色管理(A)��
7.3 許可權管理(A)��
7.4 其他安全問題(C)��
Chapter 8 事務管理（2）
8.1 事務(B)��
8.2 並發控制(B)��
8.3 恢復(A)��
作業：第1題，第2題
Chapter 9 關系數據理論（2）
9.1 基本概念(C)��
9.2 函數依賴的公理系統(C)��
9.3 規范化(B)��
9.4 模式分解(B)��
Chapter 10 資料庫設計（1）
10.1 完善E-R模型中的概念(C)��
10.2 資料庫設計的過程(B)�
六、 實驗內容與要求
序號 實驗內容 學時
1 建立資料庫（B）�� 2
2 建立表和數據完整性（A）� 2
3 SQL數據操作（B）�� 2
4 SQL數據查詢（A）�� 2
5 視圖的定義和操作（B）�� 2
6 存儲過程、觸發器（B）�� 2
7 用戶管理和許可權管理（A） 2
七、 教材與參考書
本課程選用教材：崔巍，資料庫系統及應用（第二版），高等教育出版社
本課程推薦參考書：
1）薩師煊、王珊，資料庫系統概論（第一版），北京：高等教育出版社，1983
2）薩師煊、王珊，資料庫系統概論（第二版），北京：高等教育出版社，1991
3）薩師煊、王珊，實用資料庫系統匯編，北京：高等教育出版社，1990
4）王珊、陳紅、文繼榮，資料庫和資料庫管理系統，北京：電子工業出版社，1995
5）馮玉才，資料庫基礎（第二版），武漢：華中理工大學出版社，1993
6）施伯樂、何繼潮、崔靖，關系資料庫的理論及應用，鄭州：河南科技出版社，1990
7)《資料庫系統概論》第三版 普通高等教育「九五」國家教委重點教材，由薩師煊、王珊編著，高等教育出版社

2. 大數據課程基礎內容都應該包含哪些

數學，英語！
基礎階段：Linux、Docker、KVM、MySQL基礎、Oracle基礎、MongoDB、redis。
hadoop maprece hadoop，HDFS工作原理，YARN介紹及組件介紹。
大數據存儲階段：hbase、hive、sqoop。
大數據架構設計階段：Flume分布式、Zookeeper、Kafka。
大數據實時計算階段：Mahout、Spark、storm。
大數據數據採集階段：python、Scala。
數據分析：python，R
大數據商業實戰階段：實操企業大數據處理業務場景，分析需求、解決方案實施，綜合技術實戰應用。

3. 200分2天內求大學本科資料庫課程設計!急!急！

一、課程設計的內容
本課程設計要採用本課程中學習的資料庫設計方法，運用其基本思路與主要圖表工具完成「企業報刊訂閱管理系統」資料庫應用系統。完成信息需求分析與資料庫的概念設計、邏輯設計、物理設計以及處理功能設計，用SQL Sever的資料庫管理系統、JSP開發工具實現該系統，並運行、評價、改進之；在此基礎上嚴格按課程設計教學大綱所附報告提綱撰寫課程設計報告。通過本課程設計進一步弄懂資料庫系統及其相關的基本概念，理解資料庫系統的系統結構、主要特點，掌握資料庫設計的原理、方法及其基本過程，初步具備資料庫應用設計的能力，初步形成運用資料庫應用系統解決管理決策中的實際問題的基本素質。
二、課程設計的要求與數據
要求學生結合所學管理知識，在借鑒課堂教學案例、了解家人或親友所從事的業務及其流程的基礎上，參考有關資料，選擇自己了解的一項業務，運用課堂所學資料庫系統與資料庫設計知識，完成信息需求分析、資料庫概念設計、邏輯設計、物理設計，實現完成該業務的資料庫應用系統，並運行、評價改進之，最後要寫出課程設計報告。
三、課程設計應完成的工作
要求學生按照《資料庫應用課程設計》教學大綱完成一個資料庫應用系統，並撰寫相應的課程設計報告，主要內容包括：
概述：系統的基本任務，主要業務，開發目標
1. 需求分析
2. （資料庫）概念（模型）設計
3. （資料庫）邏輯（模型）設計
4. 資料庫物理設計與資料庫保護設計
5. 處理功能設計
6. 資料庫應用系統的實現
7. 資料庫應用系統運行
四、課程設計進程安排
序號 設計各階段內容 地點 起止日期

五、應收集的資料及主要參考文獻
[1] 王 珊、陳 虹編著，資料庫系統原理教程，清華大學出版社，2003.
[1] 金銀秋主編，資料庫原理與設計，科學出版社，2000.
[2] 李建中 王珊，資料庫系統原理，電子工業出版社，1998.
[3] 李大友，資料庫原理及應用（第二版），清華大學出版社，2000

發出任務書日期： 年 月 日 指導教師簽名：

計劃完成日期： 年 月 日 基層教學單位責任人簽章：

主管院長簽章：
目錄
概述 …………………………………………………………………4
1. 需求分析…………………………………………………………4
1.1用戶需求……………………………………………………………………4
1.2業務流程分析………………………………………………………………4
1.3信息需求分析………………………………………………………………5
1.4功能需求分析………………………………………………………………6
2. （資料庫）概念（模型）設計…………………………………7
3. （資料庫）邏輯（模型）設計…………………………………9
3.1 一般邏輯模型設計…………………………………………………………9
3.2 具體邏輯模型設計…………………………………………………………9
4. 資料庫物理設計與資料庫保護設計…………………………10
4.1設計索引……………………………………………………………………10
4.2 設計表間關系………………………………………………………………10
4.3完整性設計…………………………………………………………………10
5. 處理功能設計…………………………………………………11
6. 資料庫應用系統的實現………………………………………11
7. 資料庫應用系統運行…………………………………………11
7.1 寫出系統操作使用的簡要說明……………………………………………11
7.2 系統實施過程………………………………………………………………11
7.3系統使用結果………………………………………………………………22
7.4系統評價……………………………………………………………………31

企業報刊訂閱管理系統
概述
隨著社會不斷的發展，人們的生活水平越來越高，對知識的和對時事的渴求也越來越高，人們希望能夠方便快捷地訂閱各種報刊雜志。但是各種各樣的報刊名目和詳細信息以及訂閱，為相關企業的管理造成很大的麻煩。因此網上訂閱成為不可或缺的一部分。
本系統就是面向一個企業的報刊訂閱管理系統。此系統是一種比較智能化的管理系統，它面向所有企業部門的職工用戶，但具有比較高的安全性能。它能夠實現報刊訂閱的基本功能，包括新報刊信息的錄入、訂閱、查詢等操作以及後台資料庫的備份和恢復。用戶合法注冊後必須輸入有效密碼才能成功進入此系統，可以進行訂閱報刊，查詢信息，統計信息等操作。對於非法操作，系統有識別和防護措施。

1. 需求分析
1.1 用戶需求：
本系統就是面向一個企業的報刊訂閱管理系統。此系統是一種比較智能化的管理系統，它面向所有企業部門的職工用戶，但具有比較高的安全性能。它能夠實現報刊訂閱的基本功能，包括新報刊信息的錄入、訂閱、查詢等操作以及後台資料庫的備份和恢復。用戶合法注冊後必須輸入有效密碼才能成功進入此系統，可以進行訂閱報刊，查詢信息，統計信息等操作。對於非法操作，系統有識別和防護措施。
訂閱信息處理的特點是訂閱信息處理量比較大,所管理的信息信息種類繁多,而且訂閱單、編輯單的發生量特別大,關聯信息多,查詢和統計的方式各不相同。因此在管理上實現起來有一定因難。
本系統在設計過程中,為了克服這些困難,需要使程序代碼標准化,軟體統一化,確保軟體的可維護性和實用性；刪除不必要的管理冗餘,實現管理規范化、科學化；界面友好、簡單化,做到實用、方便,盡量滿足報刊訂閱中員工的需要。

1.2 業務流程分析：
本系統主要面向的用戶有系統管理員、讀者。下面分角色對該系統的不同操作范圍做說明。
本系統主要有以下功能模塊：
（1）登陸功能：登陸系統為身份驗證登錄。分為管理員登錄和一般用戶登錄。分別通過不同的用戶名和密碼進入報刊訂閱管理界面，新的用戶需要注冊。
（2）錄入新信息功能：對於管理員，包括新用戶信息和新報刊信息的錄入功能，信息一旦提交就存入到後台資料庫中；普通用戶自行注冊進行可以修改個人信息。
（3）訂閱功能：用戶可以訂閱報刊，系統自動計算所需金額，並顯示在界面上；管理員不可訂閱報刊，必須以用戶身份訂閱報刊。
（4）查詢功能：用戶可以查詢並顯示自己所訂閱的信息；管理員可以按人員、報刊、部門分類查詢。查詢出的信息顯示在界面上,並且可以預覽和列印出結果。
（5）統計功能：管理員可以按用戶、部門、報刊統計報刊的銷售情況，並對一些重要的訂閱信息進行統計；普通用戶可以統計出自己的訂閱情況，並且可以預覽和列印出結果。
（6）系統維護功能：數據的安全管理，主要是依靠管理員對資料庫里的信息進行備份和恢復，資料庫備份後，如果出了什麼意外可以恢復資料庫到當時備份的狀態，這提高了系統和數據的安全性，有利於系統的維護。
下圖為該系統的業務流程圖

1.3 信息需求分析
1.3.1 資料收集：業務流程中用到的相關單據主要是報刊信息還有訂單信息
報刊信息表：
報刊代號 46-250 報刊名稱 IT時代周刊
出版報社 科技出版社
出版周期 半月刊
每月定價 10.00 元/月
分類編號 1001
報刊介紹 《IT時代周刊》是一本深刻解讀信息時代商業變革的雜志。除深度報道信息產業的重大新聞外，還報道金融、汽車、股市、零售等傳統行業利用IT提升商業與管理的新聞。《IT時代周刊》以調查見深度；以商業故事見功力。是CEO/CIO/CFO以及政府官員、商業領袖首選刊物。
訂單信息表：
訂單編號 報刊代號 用戶編號 訂閱日期 訂閱月數 份數 操作
3003 46-205 3206 2008-7-1 訂一月 1 取消訂閱
3004 26-306 3108 2008-7-8 訂半年 2 取消訂閱
3005 72-310 3100 2008-7-9 訂一年 1 取消訂閱
3006 45-214 2541 2008-7-10 訂一季 1 取消訂閱

1.3.2 事項分析：根據以上資料中標題、表頭等中各欄目名，可以得出相關事項，作為數據項；分析這些數據項，找出組合項、導出項、非結構化數據項，確定基本項。檢查是否有要補充的基本數據項，是否有要改進的地方，補充改進之，得出所有基本項。
1.4 功能需求分析：
本系統的主要結構功能圖如下：

2. （資料庫）概念（模型）設計
基本項構思ERD的四條基本原則：
①原則1 （確定實體）：能獨立存在的事物，例如人、物、事、地、團體、機構、活動、事項等等，在其有多個由基本項描述的特性需要關注時，就應把它作為實體。
②原則2 （確定聯系）：兩個或多個實體間的關聯與結合，如主管，從屬，組成，佔有，作用，配合，協同等等，當需要予以關注時，應作為聯系。實體間的聯系可分為一對一、一對多、多對多等三類，在確定聯系時還要確定其類型。
③原則3 （確定屬性）：實體的屬性是實體的本質特徵。實體應有標識屬性（能把不同個體區分開來的屬性組），並指定其中一個作為主標識。聯系的屬性是聯系的結果或狀態。
④原則4（一事一地）：信息分析中得到的基本項要在且僅在實體聯系圖中的一個地方作為屬性出現。

經過上述系統功能分析和需求總結，設計如下面所示的數據項和數據結構。
 管理員表（Adminuser）：用於存放管理員的數據記錄，包括數據項：管理員名、密碼。
 部門表（Department）：用來存放部門的相關記錄，包括數據項：部門號，部門名。
 用戶表（Users）：用於存放注冊用戶的記錄，包括數據項：用戶賬號、密碼、真實姓名、身份證號、聯系電話，聯系地址，部門號（和部門表有關）等。
 報刊類別表（NewspaperClass）：用於存放初始的報刊類別記錄，包括數據項：分類編號、分類名稱。
 報刊信息表（Newspaper）：用於存放報刊記錄，包括數據項：報刊代號、報刊名稱、出版報社、出版周期、季度報價、內容介紹、分類編號（和報刊類別表有關）等。
 訂單表（Order）：用於存放用戶下達的訂閱報刊的基本信息，包括數據項：訂單編號、用戶編號（用戶表的主碼）、報刊代號（報刊信息表的主碼）、訂閱份數、訂閱月數等。

根據上面的設計規劃出來的實體有部門實體、管理員實體、用戶實體、報刊類別實體、報刊信息實體和訂單實體。
部門實體的E-R圖如下圖所示： 管理員實體的E-R圖如下圖所示：

用戶實體的E-R圖如下圖所示： 報刊信息實體的E-R圖如下圖所示：

訂單實體的E-R圖如下圖所示： 報刊類別實體的E-R圖如下圖所示：

所有實體之間的的關系E-R圖如下圖所示：

3. （資料庫）邏輯（模型）設計
3.1 一般邏輯模型設計：
關系模型的邏輯結構是一組關系模式的集合。將E-R圖轉換為關系模型就是要將實體型、實體的屬性和實體型之間的聯系轉換為關系模式。
由ERD導出一般關系模型的四條原則；
①一個1：1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。如果軟換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，每個實體的碼均是該關系的候選碼。如果與某一端實體對應的關系模式何明，則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。
②一個1：n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼。
③一個m：n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系碼的一部分。
④3個或3個以上實體間的一個多元聯系可以轉換為一個關系模式。與該多元聯系項鏈呢的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系碼的一部分。

根據以上原則將E-R圖轉換成的關系模式如下：
部門（部門號，部門名稱）
用戶（用戶賬號，密碼，用戶真實姓名，聯系電話，聯系地址，部門號）
管理員（管理員名，密碼）
報刊類別（分類編號，分類名稱）
報刊（報刊代號，報刊名稱，出版報社，出版周期，每月訂價，內容介紹，分類編號）
訂單（用戶編號，報刊代號，訂閱份數，訂閱月數，訂閱總額）

3.2 具體邏輯模型設計：
在SQL Server2000資料庫中，首先創建newspaper資料庫，然後根據資料庫的邏輯結構分析創建表4-1━4-6的6張數據表。在前台訪問資料庫階段設置了用戶和密碼，用戶為sa，密碼為空。
表4-2 department部門表結構
欄位名稱 欄位類型 允許空 說明
depNumber（主碼） Char（10） 否 部門號
depName Char(50) 是 部門名稱
表4-3 users用戶表結構
欄位名稱 欄位類型 允許空 說明
userNo（主碼） Char（10） 否 用戶帳號
userName Char(20) 是 真實姓名
passWord Char(10) 否 用戶密碼
address Char(150) 是 用戶聯系地址
phone Char(20) 是 用戶聯系電話
depNumber Char(10) 否 用戶所屬部門號
表4-3 newspaperClass報刊分類表結構
欄位名稱 欄位類型 允許空 說明
classid（主碼） Int（4） 否 報刊分類編號
className Char(30) 是 報刊分類名稱
表4-4 newspaper報刊表結構
欄位名稱 欄位類型 允許空 說明
newsNo（主碼） Char（10） 否 報刊代號
newsName Char(40) 否 報刊名稱
classid Int（4） 否 報刊分類編號
publish Char(150) 是 出版報社
pubPeriod Char(30) 是 出版周期
content Char(4000) 是 內容介紹
price Float(8) 否 每月報價
表-6 book訂單表結構
欄位名稱 欄位類型 允許空 說明
userNo（主碼） Char（10） 否 用戶帳號
newsNo（主碼） Char（10） 否 報刊代號
orderAmount Int（4） 否 訂閱份數
orderMonth Int（4） 否 訂閱月數
totalPrice Float(8) 是 訂閱總額
表4-1 adminuser管理員表結構
欄位名稱 欄位類型 允許空 說明
adminUser（主碼） Char(20) 否 管理員用戶名
adminPass Char(10) 否 管理員密碼
4. 資料庫物理設計與資料庫保護設計
4.1設計索引：我們可以在最經常查詢的列上建立索引以提高查詢效率。
而在這個系統中，我們經常要按用戶賬號，按報刊代號，按部門查詢，所以，我們可以為這三個表建立索引，建立所以的SQL語句如下，這幾個都是字元型
Create unique index userNum on users(userNo)
Create unique index departNum on department(depNumber)
Create unique index newsNum on newspaper(newsNO)

4.2 設計表間關系：

4.3完整性設計列出主要欄位完整性的欄位名、完整性約束條件；列出記錄完整性約束及其約束條件；列出參照完整性表。
主要欄位的完整性欄位名和參照完整性表可以參照上圖各個表之間的關系來看。
比如建立報刊表newspaper時，要求報刊代號在100~99999之間，報刊名稱和每月定價不能取空值，報刊類別是報刊類別表的主鍵，則
Create table user
(userNo char(10) constraint C1 check(newsNo between 100 and 99999),
newsName char(40) constraint C2 not null,
classid int(4) constraint C3 not null,
publish char(150)，pubPeriod char(30),content char(4000),
price float(8) not null,
constraint C4 foreign key(classid) references newspaperclass(classid) )
4.4在有多個用戶操作時，考慮用戶授權與安全性控制。
因為這個報刊訂閱系統由多個用戶使用，分為管理員和用戶，他們擁有不同的許可權和安全性控制。所以在許可權設置方面，採用管理員和用戶分別使用用戶名和密碼進入他們能使用許可權范圍里的界面。管理員登陸系統後，可以添加、修改用戶和報刊的信息，可以對訂單進行查詢和統計，並且可以把查詢統計的結果進行預覽和列印出來，還要對資料庫系統進行維護，適時備份資料庫，一旦資料庫遇到問題，可以恢復到最近備份的狀態，減少不必要的損失。
用戶登錄，用戶使用該系統前需要進行注冊，他應該是該企業某個部門下面的員工，所以他需要輸入他的部門號等信息，注冊成功後，登錄到系統，可以修改自己的信息還有訂閱報刊，但由於許可權的限制，他只能查看和統計自己的訂單信息。
5. 處理功能設計
5.1 主控模塊設計：
使用本系統，首先它會自動彈出「歡迎使用本系統」的歡迎界面，然後跳轉到用戶身份驗證界面，選擇管理員的身份進入，有錄入（錄入報刊信息、錄入用戶信息），查詢，統計(統計用戶、統計、報刊訂單)，系統維護（備份資料庫、恢復資料庫），注銷，退出等菜單可使用，沒注冊的用戶可進入注冊界面進行注冊，然後返回登錄界面登錄，進入後有歡迎界面，有訂閱、查詢、統計、修改、注銷、退出等菜單可使用。
6. 資料庫應用系統的實現
6.1 資料庫及其表結構的建立：按照上面的邏輯分析見表
6.2數據輸入：在建好的各個表中輸入數據，要符合數據的約束條件
7. 資料庫應用系統運行
7.1 寫出系統操作使用的簡要說明
本系統的運行需要安裝PowerBuilder9.0和SQL Server2000軟體。操作該系統，首先把備份的資料庫還原出來，導入SQL Server中，然後打開該系統，連接上還原出來的資料庫，再運行，就可以了。
7.2 系統實施過程
（1）打開PowerBuilder，新建一個工作區，命名為newspaper
（2）新建一個Application，取名newspaper，然後點擊工具欄上的DB Profile，新建一個MSS Microsoft SQL Server，填入Profile Name，伺服器名，用戶名，密碼，資料庫，如下圖，然後輸入連接資料庫的主要代碼：
open(w_welcome)
// Profile newspaper
SQLCA.DBMS = "MSS Microsoft SQL Server"
SQLCA.Database = "newspaper"
SQLCA.ServerName = "CHINA-41CD782EF"
SQLCA.LogId = "sa"
SQLCA.LogPass=""
SQLCA.AutoCommit = False
SQLCA.DBParm = ""
connect;
if sqlca.sqlcode<>0 then
messagebox("錯誤","資料庫連接錯誤，程序將關閉！",stopsign!)
return
end if
close(w_welcome)
open(w_login)

（3）製作登錄頁面w_login，在「確定」按鈕輸入如下：

「注冊」按鈕代碼：open(w_register) //打開用戶注冊頁面
「退出」按鈕代碼：close（w_login） //退出本系統
(4)製作注冊窗口w_register，在「注冊」按鈕的代碼如下：

「取消」按鈕代碼：close(w_register)
open(w_login)
（5）製作管理員主菜單w_adminview，建管理員主界面w_adminview，將該菜單放到窗口中
（6）製作用戶主菜單w_userview，建用戶主界面w_userview，將菜單放到窗口中
（7）製作管理員主菜單里的錄入報刊信息窗口w_inmagazine，錄入用戶信息窗口w_inuser，
製作數據窗口dw_magagrid，dw_magafree，dw_userfree，dw_usergrid，在數據窗口調整好外觀，添加控制項，並設定相應的動作，分別放到這兩個窗口中
這兩個窗口功能相識，在窗口中輸入：
dw_1.settransobject(sqlca)
dw_1.retrieve()
dw_2.settransobject(sqlca)
dw_2.retrieve()

（8）製作管理員主菜單中的查詢訂閱信息窗口w_searchorder，製作數據窗口dw_booksearch，將其放入窗體中，在窗口中輸入代碼：
dw_1.settransobject(sqlca)
dw_1.retrieve()
sle_1.setfocus()
在「查詢」按鈕中輸入代碼：

「預覽」按鈕的代碼：

「關閉」按鈕代碼：close（w_searchorder）
數據窗口欄位如下：

（9）製作管理員主菜單中的統計用戶訂單窗口w_statuser，統計部門訂單窗口w_statdept，統計報刊訂單窗口w_statnews：製作統計數據窗口dw_statnews，dw_statuser，dw_statdept將dw_statnews，dw_statuser，dw_statdept分別放入w_statnews， w_statuser，w_statdept中；以下僅列出按出按部門統計的代碼和界面 (按用戶、報刊統計類似，略)；
按部門統計代碼：
窗口代碼：
按部門統計數據窗口：
dw_1.settransobject(sqlca)
dw_1.retrieve()
預覽鍵代碼：（與上頁預覽代碼相同）
退出：close(parent)

（10）管理員主菜單中的更改登錄在w_adminview中的代碼

（11）管理員主菜單中的退出系統在w_adminview中的代碼

（12）管理員主菜單中的資料庫備份窗口w_backup，「開始備份」按鈕的代碼如下

在「>>」按鈕帶輸入代碼：

（13）管理員主菜單中的資料庫恢復窗口w_restore，「開始恢復」按鈕的代碼如下
在「>>」按鈕帶輸入代碼：

在「開始恢復」按鈕輸入代碼：

（14）用戶主菜單的訂閱報刊窗口w_userorder
該系統中定義了一個全局變數gs_userid，其它窗口界面都可以使用該變數，並顯示用戶名，用戶登錄後，它會顯示「~~~~，歡迎使用本系統！」的歡迎界面。
窗口代碼：
dw_1.settransobject(sqlca)
dw_1.retrieve()
sle_1.setfocus()
sle_2.text=gs_userid
「清空」按鈕代碼：
sle_1.text=""
sle_3.text=""
sle_5.text=""
「退出」按鈕代碼：
close(w_userorder)
「訂閱」按鈕代碼：

（14）用戶主菜單的查詢訂單窗口w_usersearch，將訂單查找dw_booksearch放到窗口裡，在窗口中過過濾器篩選中用戶自己的訂單信息，一打開就可以看到自己的訂單信息，可列印和預覽結果

窗口代碼：

「預覽」和「退出」按鈕同上
（15）用戶主菜單的查詢訂單窗口w_userstatis，將用戶統計dw_statuser放到窗口裡，在窗口中過過濾器篩選中用戶自己的訂單信息，一打開就可以看到自己的訂單信息，可列印和預覽結果，窗口代碼如下：

用戶統計dw_statuser數據窗口如下：

「預覽」「退出」按鈕略
（16）用戶主菜單中的修改用戶信息窗口w_usermodify，打開會先顯示出你的信息，而用戶名這一欄是輸入不了的，也就是不能修改用戶名，窗口代碼如下：

「保存」按鈕代碼如下：

（17）用戶主菜單中的更改登錄和退出系統的代碼和管理員的一樣，這里就省略了。
7.3系統使用結果

打開本系統，首先彈出歡迎界面，通常一閃而過，然後到了登錄界面，點擊「注冊」

按確定後，彈出「恭喜，您已注冊成功！」的對話框。如果這時刷新服務管理器，打開SQL Server企業管理器，打開該資料庫的用戶表，就可看到剛才注冊的用戶已經在表中了

然後返回到登陸頁面，輸入剛才注冊到的用戶名和密碼maishning，123456

登錄後，彈出一個窗口，有供用戶使用的菜單，界面顯示「~~~~，歡迎使用本系統」

選擇「訂閱」菜單，在這個訂閱界面，用戶可以瀏覽到所有的報刊信息，要訂閱報刊時，用戶不需輸入用戶名與密碼，只需輸入您要訂閱的報刊代號（該報刊代號必須是報刊表中存在的），訂閱份數（必須是小於8的整數才有效），然後選擇需要訂閱的月數（一月、一季、半年或一年）然後點擊「訂閱」按鈕

訂閱成功後，系統彈出「恭喜！你已成功訂閱該報刊，總金額是~~~~」確定後會顯示出您所訂閱的總額是多少元，按「清空」按鈕後可以訂閱其它報刊（同樣的報刊不可重復訂閱）

再訂閱其它報刊，然後按「退出」按鈕，來到用戶主菜單然後選擇「查詢」菜單，這個數據窗口經過過濾，一打開就直接顯示該用戶過訂閱的訂單，可以進行預覽和列印。

由於許可權的限制，「統計」菜單中的也是只能統計自己訂單信息的數據

在「退訂」報刊菜單中，可以查看自己的訂單，單擊「退訂」然後「保存」即可完成退訂
在「修改」信息菜單中，用戶名也是不可輸入的文本框，即不可修改用戶名，其它信息可以修改，保存後它會自動添加到資料庫中

選擇菜單上的「注銷」，可以用不同的身份進入系統，確定後回到登錄界面

以管理員的身份登錄，用戶名111，密碼111，按登錄按鍵，可看到管理員菜單

選擇菜單欄中的錄入->錄入報刊信息，管理員可以大致瀏覽所有報刊信息，在上面的數據窗口可以查看上一頁和下一頁的具體內容，並且可以對其進行添加，刪除、修改、保存等操作。

錄入用戶信息頁面，基本相似

選擇菜單欄中的「查詢」->「訂單信息」,管理員擁有的許可權可以看到所有的訂單信息

管理員也可以根據需要分別按部門、按用戶、按報刊查詢，比如，要查詢msishning用戶，在文本框中輸入關鍵字，選擇單選按鈕中的「按部門號」，點擊「查詢」，結果如下
可對全部訂單或查詢出來的訂單進行預覽和列印，方便使用

菜單欄中的「統計」菜單有三個子菜單，管理員可以分別統計用戶訂單信息、部門訂單信息和報刊訂單信息， 直接選擇就可看到統計結果，比如選擇「統計用戶訂單信息」

可將統計出來的結果進行預覽和列印，方便使用，其它兩個統計功能相似，略

主菜單中的系統維護->資料庫備份，選擇備份的位置，然後「開始備份」

主菜單中的系統維護->資料庫恢復，選擇之前備份的文件，輸入路徑和資料庫名，然後「開始恢復」

7.4系統評價：

4. 大數據培訓課程大綱去哪裡學

一、基礎部分：java語言 和 LINUX系統

二、數據開發:

1、數據分析與挖掘

一般工作包括數據清洗，執行分析和數據可視化。學習Python、資料庫、網路爬蟲、數據分析與處理等。

大數據培訓一般是指大數據開發培訓。

大數據技術龐大復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。

2、大數據開發

數據工程師建設和優化系統。學習hadoop、spark、storm、超大集群調優、機器學習、Docker容器引擎、ElasticSearch、並發編程等；

課程學習一共分為六個階段：

5. 關系資料庫規范化理論的基礎和內容

一個關系資料庫模式由一組關系模式組成，一個關系模式由一組屬性名組成。關系資料庫設計，就是如何把已給定的相互關聯的一組屬性名分組，並把每一組屬性名組成關系的問題。然而，屬性的分組不是唯一的，不同的分組對應著不同的資料庫應用系統，它們的效率往往相差很遠。
為了使資料庫設計合理可靠，簡單實用，長期以來，形成了關系資料庫設計的理論——規范化理論。
6.1 關系規范化的作用
規范化，就是用形式更為簡潔，結構更加規范的關系模式取代原有關系模式的過程。
如果將兩個或兩個以上實體的數據存放在一個表裡，就會出現下列三個問題：
Ø 數據冗餘度大
Ø 插入異常
Ø 刪除異常
所謂數據冗餘，就是相同數據在資料庫中多次重復存放的現象。數據冗餘不僅會浪費存儲空間，而且可能造成數據的不一致性。
插入異常是指，當在不規范的數據表中插入數據時，由於實體完整性約束要求主碼不能為空的限制，而使有用數據無法插入的情況。
刪除異常是指，當不規范的數據表中某條需要刪除的元組中包含有一部分有用數據時，就會出現刪除困難。
（以P98工資表為例）
解決上述三個問題的方法，就是將不規范的關系分解成為多個關系，使得每個關系中只包含一個實體的數據。
（講例子解）
當然，改進後的關系模式也存在另一問題，當查詢職工工資時需要將兩個關系連接後方能查詢，而關系連接的代價也是很大的。
那麼，什麼樣的關系需要分解？分解關系模式的理論依據又是什麼？分解完後能否完全消除上述三個問題？回答這些問題需要理論指導。下面，將加以討論：

6.2 函數依賴

6.2.1屬性間關系

實體間的聯系有兩類：一類是實體與實體之間聯系；另一類是實體內部各屬性間的聯系。資料庫建模一章中討論的是前一類，在這里我們將學習第二類。

和第一類一樣，實體內部各屬性間的聯系也分為1:1、1:n和m:n三類：

例：職工（職工號，姓名，身份證號碼，職稱，部門）

1、 一對一關系（1:1）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中至多有一個值與之對應，反之，對於Y中的任一具體值，X中也至多有一個值與之對應，則稱X、Y兩屬性間是一對一關系。

如本例職工關系中職工號與身份證號碼之間就是一對一關系。

2、一對多關系（1:n）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中可以找到多個值與之對應，而對於Y中的任一具體值，X中至多隻有一個值與之對應，則稱屬性X對Y是一對多關系。

如職工關系中職工號與職稱之間就是一對多的關系。

3、多對多關系（m:n）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中有n個值與之對應，而對於Y中的任一具體值，X中也有m個值與之對應，則稱屬性X對Y是一對多（m:n）關系。

例如，職工關系中，職稱與部門之間就是多對多的關系。

上述屬性間的三種關系，實際上是屬性值之間相互依賴與相互制約的反映，因而稱之為屬性間的數據依賴。

數據依賴共有三種：

Ø 函數依賴（Functional Dependency，FD）

Ø 多值依賴（Multivalued Dependency，MVD）

Ø 連接依賴（Join Dependency，JD）

其中最重要的是函數依賴和多值依賴。

6.2.2 函數依賴

函數依賴，是屬性之間的一種聯系。在關系R中，X、Y為R的兩個屬性或屬性組，如果對於R的所有關系r 都存在：對於X的每一個具體值，Y都只有一個具體值與之對應，則稱屬性Y函數依賴於屬性X。或者說，屬性X函數決定屬性Y，記作X→Y。其中X叫作決定因素，Y叫作被決定因素。

上述定義，可簡言之：如果屬性X的值決定屬性Y的值，那麼屬性Y函數依賴於屬性X。換一種說法：如果知道X的值，就可以獲得Y的值，則可以說X決定Y。

若Y函數不依賴於X，記作：X→Y。

X Y

若X→Y，Y→X，記作：

前面學習的屬性間的三種關系，並不是每種關系中都存在著函數依賴。

u 如果X、Y間是1:1關系，則存在函數依賴 X←→Y

u 如果X、Y間是1:n關系，則存在函數依賴： X→Y或Y→X（多方為決定因素）

u 如果X、Y間是m:n關系，則不存在函數依賴。

注意，屬性間的函數依賴不是指R的某個或某些關系子集滿足上述限定條件，而是指R的一切關系子集都要滿足定義中的限定。只要有一個具體的關系r（R的一個關系子集）不滿足定義中的條件，就破壞了函數依賴，使函數依賴不成立。

這里的關系子集，指的是R的某一部分元組的集合，例如：地測學院的學生關系中只包含了地測學院學生的數據，所以它是長安大學學生關系的一個子集。

6.2.3 碼的定義

前面，我們對碼進行了直觀化的定義，下面用函數依賴的概念對碼作出較為精確的形式化的定義：

設K是關系模式R（U，F）中的屬性或屬性組，K』是K的任一子集。若K→U，而不存在K』→U，則K為R的候選碼（Candidate Key）

Ø 若候選碼多於一個，則選其中的一個為主碼（Primary Key）；

Ø 包含在任一候選碼中的屬性，叫做主屬性（Primary Attribute）；

Ø 不包含在任何碼中的屬性稱為非主屬性（Nonprime Attribute）或非碼屬性（Nonkey Attribute）

Ø 關系模式中，最簡單的情況是單個屬性是碼，稱為單碼（Single Key）；最極端的情況是整個屬性組是碼，稱為全碼（All－Key）。

前面已多次遇到單碼的情況，下面是一個全碼的例子：

簽約（演員名，製片公司，電影名）

外碼：設有兩個關系R和S，X是R的屬性或屬性組，並且X不是R的碼，但X是S的碼（或與S的碼意義相同），則稱X是R的外部碼（Foreign Key），簡稱外碼或外鍵。

如：職工（職工號，姓名，性別，職稱，部門號）

部門（部門號，部門名，電話，負責人）

其中職工關系中的「部門號」就是職工關系的一個外碼。

在此需要注意，在定義中說X不是R的碼，並不是說X不是R的主屬性，X不是碼，但可以是碼的組成屬性，或者是任一候選碼中的一個主屬性。

如：學生（學生號，姓名，性別，年齡…）

課程（課程號，課程名，任課老師…）

選課（學生號，課程號，成績）

在選課關系中，（學生號，課程號）是該關系的碼，學生號、課程號又分別是組成主碼的屬性（但單獨不是碼），它們分別是學生關系和課程關系的主碼，所以是選課關系的兩個外碼。

關系間的聯系，可以通過同時存在於兩個或多個關系中的主碼和外碼的取值來建立。如要查詢某個職工所在部門的情況，只需查詢部門表中的部門號與該職工部門號相同的記錄即可。所以，主碼和外碼提供了一個表示關系間聯系的途徑。

6.2.4 函數依賴和碼的唯一性

由上述碼的形式化定義，我們可以說：碼是由一個或多個屬性組成的，可唯一標識元組的最小屬性組。

碼在關系中總是唯一的，即一個碼函數唯一地決定一行。如果碼的值重復，則整個元組都會重復。否則，違反了實體完整性規則。而元組的重復則表示存在兩個完全相同的實體，這顯然是不可能的，所以碼是不允許重復取值的。

所以，只有當某個屬性或屬性組能夠函數決定關系中的每一個其它的屬性，且該屬性組的任何一個真子集都做不到這一點時，該屬性或屬性組才是該關系的碼。

函數依賴是一個與數據有關的事物規則的概念。如果屬性B函數依賴於屬性A，那麼若知道了A的值，則完全可以找到B的值。這並非是可以由A的值計算出B的值，而是邏輯上只能存在一個B的值。

6.3 關系模式的規范化

一、非規范化的關系

當一個表中存在還可以再分的數據項時，這個表就是非規范化的表。非規范化表存在兩種情況：

Ø 表中具有組合數據項（P102表6-4）

Ø 表中具有多值數據項（P103表6-5）

例：

職工號
姓名
工資

基本工資
職務工資
工齡工資

1002
張三
1000
800
200

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

001
張三
教授
計算機
1305
大學

研究生
1963

1982

那麼什麼是規范化關系呢？

當一個關系中的所有分量都是不可再分的數據項時，該關系是規范化的。即當表中不存在組合數據項和多值數據項，只存在不可分的數據項時，這個表是規范化的。

二維表按其規范化程度從低到高可分為5級範式（Normal Form），分別稱為1NF、2NF、3NF（BCNF）、4NF、5NF。規范化程度較高者必是較低者的子集，即：

1NF 2NF 3NF BCNF 4NF 5NF

二、第一範式（1NF）

定義1：如果關系模式R中不包含多值屬性，則R滿足第一範式（First Normal Form），記作：

R∈1NF

1NF是對關系的最低要求，不滿足1NF的關系是非規范化的關系。

非規范化關系轉化為規范化關系1NF方法很簡單，只要上表分別從橫向、縱向展開即可。如下表：

職工號
姓名
基本工資
職務工資
工齡工資

1002
張三
1000
800
200

1005
李四
1200
900
150

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

1002
張三
教授
計算機
1305
大學
1963

1002
張三
教授
計算機
1305
研究生
1982

1005
李四
講師
信電
2206
大學
1989

上表雖然符合1NF，但仍是有問題的關系，表中存在大量的數據冗餘和潛在的數據更新異常。原因是（職工號，學歷）是右表的碼，但姓名、職稱、系名、系辦地址卻與學歷無關，只與碼的一部分有關。所以上表還需進一步地規范化。

三、第二範式（2NF）

定義1：設X、Y是關系R的兩個不同的屬性或屬性組，且X → Y。如果存在X的某一個真子集X』，使X』 → Y成立，則稱Y部分函數依賴於X，記作：X P→ Y（Partial）。反之，則稱Y完全函數依賴於X，記作：X F→ Y （Full）

定義2：如果一個關系 R∈1NF，且它的所有非主屬性都完全函數依賴於R的任一候選碼，則R屬於第二範式，記作：R∈2NF。

說明：上述定義中所謂的候選碼也包括主碼，因為碼首先應是候選碼，才可以被指定為碼。

例如關系模式：

職工（職工號，姓名，職稱，項目號，項目名稱，項目角色）中

（職工號，項目號）是該關系的碼，而職工號→姓名、職工號→職稱、項目號→項目名稱…

所以（職工號，項目號）P→ 職稱、（職工號，項目號）P→ 項目名稱

故上述職工關系不符合第二範式要求。它存在三個問題：插入異常、刪除異常和修改異常。

其中修改異常是這樣的，當職工關系中項目名稱發生變化時，由於參與該項目的人員很多，每人一條記錄，要修改項目信息，就得對每一個參加該項目的人員信息進行修改，加大了工作量，還有可能發生遺漏，存在著數據一致性被破壞的可能。

可把上述職工關系分解成如下三個關系：

職工（職工號，姓名，職稱）

參與項目（職工號，項目號，項目角色）

項目（項目號，項目名稱）

上述三個關系都符合定義2的要求，所以都符合2NF

推論：如果關系模式R∈1NF，且它的每一個候選碼都是單碼，則R∈2NF

符合第二範式的關系模式仍可能存在數據冗餘、更新異常等問題。如關系

職工信息（職工號，姓名，職稱，系名，系辦地址）

雖然也符合2NF，但當某個系中有100名職工時，元組中的系辦地址就要重復100次，存在著較高的數據冗餘。原因是關系中，系辦地址不是直接函數依賴於職工號，而是因為職工號函數決定系名，而系名函數決定系辦地址，才使得系辦地址函數依賴於職工號，這種依賴是一個傳遞依賴的過程。

所以，上述職工信息的關系模式還需要進一步的規范化。

四、第三範式（3NF）

定義1：在關系R中，X、Y、Z是R的三個不同的屬性或屬性組，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，則稱Z傳遞函數依賴於X。

定義2：如果關系模式R∈2NF，且它的每一個非主屬性都不傳遞依賴於任何候選碼，則稱R是第三範式，記作：R∈3NF

推論1：如果關系模式R∈1NF，且它的每一個非主屬性既不部分依賴、也不傳遞依賴於任何候選碼，則R∈3NF

推論2：不存非主屬性的關系模式一定為3NF

五、改進的3NF——BCNF（Boyee－Codd Normal Form）

定義：設關系模式R（U，F）∈1NF，若F的任一函數依賴X→Y（Y X）中X都包含了R的一個碼，則稱R∈BCNF。

換言之，在關系模式R中，如果每一個函數依賴的決定因素都包含碼，則R∈BCNF

推論：如果R∈BCNF，則：

Ø R中所有非主屬性對每一個碼都是完全函數依賴；

Ø R中所有主屬性對每一個不包含它的碼，都是完全函數依賴；

Ø R中沒有任何屬性完全函數依賴於非碼的任何一組屬性。

定理：如果R∈BCNF，則R∈3NF一定成立。

證明：（結合傳遞依賴的定義，用反證法）

注意：當R∈3NF時，R未必屬於BCNF。因為3NF比BCNF放寬了一個限制，它允許決定因素不包含碼。例如：

通訊（城市名，街道名，郵政編碼）中：

F＝｛（城市名，街道名）→郵政編碼，郵政編碼→城市名｝

非主屬性郵政編碼完全函數依賴於碼，且無傳遞依賴，故屬於3NF，但郵政編碼也是一個決定因素，而且它沒有包含碼，所以該關系不屬於BCNF。

又如：

Teaching（Student，Teacher，Course） 簡記為Teaching（S，T，C）

規定：一個教師只能教一門課，每門課程可由多個教師講授；學生一旦選定某門課程，教師就相應地固定。

F＝｛T→C，（S，C）→T,(S，T) →C｝

該關系的候選碼是（S，C）和（S，T），因此，三個屬性都是主屬性，由於不存在非主屬性，該關系一定是3NF。但由於決定因素T沒包含碼，故它不是BCNF。

關系模式Teaching仍然存在著數據冗餘問題，因為存在著主屬性對碼的部分函數依賴問題。

確切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝

所以Teaching關系可以分解為以下兩個BCNF關系模式：

Teacher（Teacher，Course） Student（Student，Teacher）

3NF的「不徹底」性，表現在可能存在主屬性對碼的部分依賴和傳遞依賴。

一個關系模式如果達到了BCNF，那麼，在函數依賴范圍內，它就已經實現了徹底的分離，消除了數據冗餘、插入和刪除異常。
6.4 多值依賴和第四範式

一、多值依賴（Multivalued Dependency）

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

課程C
教員T
參考書B

物理
李勇

王軍
普通物理學

光學原理

物理習題集

數學
李勇

張平
數學分析

微分方程

高等代數

計算數學
張平

周峰
數學分析

計算數學

例：學校中某一門課程由多個教員講授，他們使用相同的一套參考書，每個教員可以講授多門課程，每種參考書可以供多門課程使用。下列是用一個非規范化的表來表示教員T，課程C和參考書B之間的關系。

把上表變換成一張規范化的二維表Teaching，如右表

關系模式Teaching（C，T，B）的碼是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述語義規定，當某門課程增加一名講課教員時，就要向Teaching表中增加與相應參考書等數目的元組。同樣，某門課程要去掉一本參考書時，則必須刪除相應數目的元組。

對數據的增、刪、改很不方便，數據的冗餘也十分明顯。如果仔細考察這類關系模式，會發現它具有一種稱之為多值依賴的數據依賴關系。

定義：設R（U）是屬性集U上的一個關系模式，X，Y，Z是U的子集，且Z＝U-X-Y。如果對R（U）的任一關系r，給定一對（x，z）值，都有一組y值與之對應，這組y值僅僅決定於x值而與z值無關。則稱Y多值依賴於X，或X多值決定Y，記作：X→→Y。――

例如，在關系模式Teaching中，對於一個（C，B）值（物理，普通物理學），有一組T值｛李勇，王軍｝，而這組值僅僅決定於課程C上的值（物理）。即對於另一個（物理，光學原理），它對應的T值仍然是｛李勇，王軍｝，所以T的值與B的值無關，僅決定於C的值，即C→→T 。

多值依賴的另一個等價的形式化定義為：

設關系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一個關系，t1、t2是r的任意兩個元組。如果t1[X]=t2[X]，並在r中存在兩個元組t3、t4，使得：

t3[X]=t4[X]=t1[X]

t3[Y]=t1[Y]，t3[Z]=t2[Z]，

t4[Y]=t2[Y]，t4[Z]=t1[Z]

成立，則X→→Y。

換句話說：如果X→→Y在R（U）中成立，則只要在R的任一關系r中存在兩個元組t1、t2在X屬性上的值相等，則交換這兩個元組在Y（或Z）上的值後得到的兩個新元組t3、t4也必是關系r中的元組。

定義中如果Z＝Ф（空集），則稱X→→Y為平凡的多值依賴，否則為非平凡的多值依賴。

多值依賴具有如下性質：

1. 對稱性：若X→→Y，則X→→Z，其中Z＝U-X-Y

2. 傳遞性：若X→→Y，Y→→Z，則X→→Z-Y

3. 若X→→Y，X→→Z，則X→→YZ

4. 若X→→Y，X→→Z，則X→→Y∩Z

5. 若X→→Y，X→→Z，則X→→Y-Z，X→→Z-Y

多值依賴與函數依賴相比，具有下面兩個基本區別：

（1）多值依賴的有效性與屬性集的范圍有關

若X→→Y在U上成立，則在V（XY V U）上一定成立；反之則不然，即X→→Y在V(V U)上成立，在U上並不一定成立。這是因為多值依賴的定義中不僅涉及屬性組X、Y，而且涉及U中的其餘屬性Z（Z＝U-X-Y）。

一般地說，在R（U）上若有X→→Y在V（V U）上成立，則稱X→→Y為R（U）的嵌入型多值依賴。

而在關系模式R（U）中函數依賴X→Y的有效性，僅決定於X和Y這兩個屬性集的值。只要在R（U）的任何一個關系r中，元組在X和Y上的值使得X→Y成立，則X→Y在任何屬性集V（XY V U）上也成立。

（2）若函數依賴X→Y在R（U）上成立，則對於任何Y』 Y 均有X→Y』 成立。而多值依賴X→→Y若在R（U）上成立，卻不能斷言對於任何Y』 Y有X→→Y』 成立。

多值依賴的約束規則：在具有多值依賴的關系中，如果隨便刪去一個元組，就會破壞其對稱性，那麼，為了保持多值依賴關系中的「多值依賴」性，就必須刪去另外的相關元組以維持其對稱性。這就是多值依賴的約束規則。目前的RDBMS尚不具有維護這種約束的能力，需要程序員在編程中實現。

函數依賴可看成是多值依賴的特例，即函數依賴一定是多值依賴。而多值依賴則不一定就有函數依賴。

二、第四範式（4NF）

定義：如果關系模式R∈1NF，對於R的每個非平凡的多值依賴X→→Y（Y X），X含有碼，則稱R是第四範式，即R∈4NF

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

Teaching關系

關系模式R∈4NF時，R中所有的非平凡多值依賴實際上就是函數依賴。因為每一個決定因素中都含有碼，所以R一定屬於BCNF。

4NF實際上就是限制關系模式的屬性間不允許有非平凡，而且非函數依賴的多值依賴存在。反過來說，4NF所允許的非平凡多值依賴實際上是函數依賴。

例題中的Teaching關系屬於BCNF，但它不屬於4NF。因為它的碼是（C，T，B），關系中存在非平凡多值依賴C→→T ，C→→B，但C不包含碼，而只是碼的一部分。

課程C
參考書B

物理
普通物理學

物理
光學原理

物理
物理習題集

數學
數學分析

數學
微分方程

數學
高等代數

計算數學
數學分析

計算數學
計算數學

CB關系

課程C
教員T

物理
李勇

物理
王軍

數學
李勇

數學
張平

計算數學
張平

計算數學
周峰

CT關系

要使Teaching關系符合4NF，必須將其分解為CT（C，T）和CB（C，B）兩個關系模式。如右表：

從表中顯而易見，符合BCNF的關系Teaching仍然存在著數據冗餘，而分解後的關系CT和CB中只有平凡多值依賴，所以符合4NF，它們已經消除了數據冗餘。可以說：BCNF是在只有函數依賴的關系模式中，規范化程度最高的範式，而4NF是在有多值依賴的關系模式中，規范化程度最高的範式。

如果關系模式中存在連接依賴，即便它符合4NF，仍有可能遇到數據冗餘及更新異常等問題。所以對於達到4NF的關系模式，還需要消除其中可能存在的連接依賴，才可以進一步達到5NF的關系模式。

關於連接依賴和5NF的內容，已超出了本課程教學大綱的要求，在此不再介紹。

6. 請問《資料庫原理及其應用教程》這門課對計算機專業考研重要嗎

主要看考什麼專業的研究生，如果是計算機方面，肯定會涉及到資料庫原理及其應用方面的知識的。
資料庫原理及其應用：以關系資料庫系統為核心，系統全面地闡述了資料庫系統的基本概念、基本原理和應用技術，主要內容包括資料庫技術概述、關系資料庫、關系資料庫的標准語言SQL、關系資料庫設計、資料庫保護、網路資料庫、網路資料庫管理系統SQL Server 2000、分布式資料庫系統、XML資料庫等
考研，即參加碩士研究生入學考試。其英文表述是「Take part in the entrance exams for postgraate schools」。考研首先要符合國家標准，其次按照程序：與學校聯系、先期准備、報名、初試、調劑、復試、復試調劑、錄取等方面依次進行。

7. 大數據培訓課程大綱要學什麼課程

首先我們要了解Java語言和Linux操作系統，這兩個是學習大數據的基礎，學習的順序不分前後。

Java ：只要了解一些基礎即可，做大數據不需要很深的Java 技術，學java SE 就相當於有學習大數據基礎。

Linux：因為大數據相關軟體都是在Linux上運行的，所以Linux要學習的扎實一些，學好Linux對你快速掌握大數據相關技術會有很大的幫助，能讓你更好的理解hadoop、hive、hbase、spark等大數據軟體的運行環境和網路環境配置，能少踩很多坑，學會shell就能看懂腳本這樣能更容易理解和配置大數據集群。還能讓你對以後新出的大數據技術學習起來更快。

Hadoop：這是現在流行的大數據處理平台幾乎已經成為大數據的代名詞，所以這個是必學的。Hadoop裡麵包括幾個組件HDFS、MapRece和YARN，HDFS是存儲數據的地方就像我們電腦的硬碟一樣文件都存儲在這個上面，MapRece是對數據進行處理計算的，它有個特點就是不管多大的數據只要給它時間它就能把數據跑完，但是時間可能不是很快所以它叫數據的批處理。

Zookeeper：這是個萬金油，安裝Hadoop的HA的時候就會用到它，以後的Hbase也會用到它。它一般用來存放一些相互協作的信息，這些信息比較小一般不會超過1M，都是使用它的軟體對它有依賴，對於我們個人來講只需要把它安裝正確，讓它正常的run起來就可以了。

Mysql：我們學習完大數據的處理了，接下來學習學習小數據的處理工具mysql資料庫，因為一會裝hive的時候要用到，mysql需要掌握到什麼層度那?你能在Linux上把它安裝好，運行起來，會配置簡單的許可權，修改root的密碼，創建資料庫。這里主要的是學習SQL的語法，因為hive的語法和這個非常相似。

Sqoop：這個是用於把Mysql里的數據導入到Hadoop里的。當然你也可以不用這個，直接把Mysql數據表導出成文件再放到HDFS上也是一樣的，當然生產環境中使用要注意Mysql的壓力。

Hive：這個東西對於會SQL語法的來說就是神器，它能讓你處理大數據變的很簡單，不會再費勁的編寫MapRece程序。有的人說Pig那?它和Pig差不多掌握一個就可以了。

Oozie：既然學會Hive了，我相信你一定需要這個東西，它可以幫你管理你的Hive或者MapRece、Spark腳本，還能檢查你的程序是否執行正確，出錯了給你發報警並能幫你重試程序，最重要的是還能幫你配置任務的依賴關系。我相信你一定會喜歡上它的，不然你看著那一大堆腳本，和密密麻麻的crond是不是有種想屎的感覺。

Hbase：這是Hadoop生態體系中的NOSQL資料庫，他的數據是按照key和value的形式存儲的並且key是唯一的，所以它能用來做數據的排重，它與MYSQL相比能存儲的數據量大很多。所以他常被用於大數據處理完成之後的存儲目的地。

Kafka：這是個比較好用的隊列工具，隊列是干嗎的?排隊買票你知道不?數據多了同樣也需要排隊處理，這樣與你協作的其它同學不會叫起來，你干嗎給我這么多的數據(比如好幾百G的文件)我怎麼處理得過來，你別怪他因為他不是搞大數據的，你可以跟他講我把數據放在隊列里你使用的時候一個個拿，這樣他就不在抱怨了馬上灰流流的去優化他的程序去了，因為處理不過來就是他的事情。而不是你給的問題。當然我們也可以利用這個工具來做線上實時數據的入庫或入HDFS，這時你可以與一個叫Flume的工具配合使用，它是專門用來提供對數據進行簡單處理，並寫到各種數據接受方(比如Kafka)的。

Spark：它是用來彌補基於MapRece處理數據速度上的缺點，它的特點是把數據裝載到內存中計算而不是去讀慢的要死進化還特別慢的硬碟。特別適合做迭代運算，所以演算法流們特別稀飯它。它是用scala編寫的。Java語言或者Scala都可以操作它，因為它們都是用JVM的。

8. 大數據培訓課程都包含哪些內容

大數據培訓課程內容一般都是從基礎知識講起，並且課程內容與企業實際需求相匹配、理論與實戰相結合這樣學員在培訓機構學完後找工作才比較容易，一般主要學習Java語言基礎、HTML、CSS、Java、JavaWeb和資料庫、Lnux基礎、Hadoop：生態體系、Spark：生態體系等課程內容。如需大數據培訓推薦選擇【達內教育】。

大數據技術龐大復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、資料庫、數據倉庫、機器學習、並行計算、可視化等名種技術范疇和不同的技術層面。一般工作包括數據清洗，執行分析和數據可視化。學習Python、資料庫、網路爬蟲、數據分析與處理等。感興趣的話點擊此處，免費學習一下

想了解更多有關大數據的相關信息，推薦咨詢【達內教育】。達內與阿里、Adobe、紅帽、ORACLE、微軟、美國計算機行業協會（CompTIA）、網路等國際知名廠商建立了項目合作關系。共同制定行業培訓標准，為達內學員提供高端技術、所學課程受國際廠商認可，讓達內學員更具國際化就業競爭力。達內IT培訓機構,試聽名額限時搶購。

9. 資料庫包括那些課程

資料庫課程設計是在學生系統的學習了資料庫原理課程後，按照關系型資料庫的基本原理，綜合運用所學的知識，以小組為單位，設計開發一個小型的資料庫管理系統。通過對一個實際問題的分析、設計與實現，將原理與應用相結合，使學生學會如何把書本上學到的知識用於解決實際問題，培養學生的動手能力；另一方面，使學生能深入理解和靈活掌握教學內容。

總體設計要求：
四到五人為一個小組，小組成員既要有相互合作的精神，又要分工明確。每個學生都必須充分了解整個設計的全過程。
從開始的系統需求分析到最後的軟體測試，都要有詳細的計劃，設計文檔應按照軟體工程的要求書寫。
系統中的數據表設計應合理、高效，盡量減少數據冗餘。
軟體界面要友好、安全性高。
軟體要易於維護、方便升級。
編程語言可由小組根據自己的情況選擇，但一般情況下應該是小組的每個成員都對該語言較熟悉。避免把學習語言的時間放在設計期間。
參考使用的語言有：VF、VB、Delphi 、PB、VC、SQL_Server等。

學生學籍管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要的數據表
學生基本情況數據表，學生成績數據表，課程表，代碼表等。
2．主要功能模塊
1）實現學生基本情況的錄入、修改、刪除等基本操作。
2）對學生基本信息提供靈活的查詢方式。
3）完成一個班級的學期選課功能。
4）實現學生成績的錄入、修改、刪除等基本操作。
5）能方便的對學生的個學期成績進行查詢。
6）具有成績統計、排名等功能。
7）具有留級、休學等特殊情況的處理功能。
8）能輸出常用的各種報表。
9）具有數據備份和數據恢復功能。

三、設計要求
學生成績表的設計，要考慮到不同年級的教學計劃的變化情況。
對於新生班級，應該首先進行基本情況錄入、選課、然後才能進行成績錄入。

圖書管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．要的數據表
圖書基本信息表，借書卡信息表，借閱信息表，圖書分類信息表，代碼表等。
2．功能模塊
1）圖書基本情況的錄入、修改、刪除等基本操作。
2）辦理借書卡模塊。
3）實現借書功能。
4）實現還書功能。
5）能方便的對圖書進行查詢。
6）對超期的情況能自動給出提示信息。
7）具有數據備份和數據恢復功能。

三、設計要求
圖書編號可參考國家統一的圖書編碼方法，再完成基本功能模塊的情況下，盡量使系統能具有通用性。

銀行儲蓄系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要的數據表
定期存款單，活期存款帳，存款類別代碼表等。
2．功能模塊
1）實現儲戶開戶登記。
2）辦理定期存款帳。
3）辦理定期取款手續。
4）辦理活期存款帳
5）辦理活期取款手續。
6）實現利息計算。
7）輸出明細表。
8）具有數據備份和數據恢復功能。

三、設計要求
要進行實際調研，系統功能在實現時參照實際的儲蓄系統的功能。同時要考慮銀行系統數據的安全與保密工作。數據要有加密功能。

設備管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要數據表
設備明細帳表，設備使用單位代碼表，國家標准設備分類表等。
2．功能模塊
1）實現設備的錄入、刪除、修改等基本操作。
2）實現國家標准設備代碼的維護。
3）能夠對設備進行方便的檢索。
4）實現設備折舊計算。
5）能夠輸出設備分類明細表。
6）具有數據備份和數據恢復功能。

三、設計要求
具體設備編碼參考國家統一編碼方法，功能實現也要考慮通用性。

醫院葯品進銷存系統