1. 有沒有用同一個表來介紹sql的三大範式的例子
首先就得知道什麼是sql的三大範式
1.什麼是資料庫三範式？分別是哪三範式？各有什麼優缺點？
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一範式就是無重復的列。說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。例如員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是屬性完全依賴於主鍵。
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
問題分析
因此不滿足第二範式的要求，會產生如下問題
數據冗餘： 同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
更新異常：
1)若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
2)假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。
刪除異常 ： 假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。2.1.2 解決方案
把選課關系表SelectCourse改為如下三個表：學生：Student(學號，姓名, 年齡，性別，系別，系辦地址、系辦電話)；課程：Course(課程名稱, 學分)；選課關系：SelectCourse(學號, 課程名稱, 成績)。2.2 第三範式（3NF）實例分析
接著看上面的學生表Student(學號，姓名, 年齡，性別，系別，系辦地址、系辦電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
（學號）→ (姓名, 年齡，性別，系別，系辦地址、系辦電話)
但是還存在下面的決定關系
(學號) → (所在學院)→(學院地點, 學院電話)
即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況。 (數據的更新，刪除異常這里就不分析了，可以參照2.1.1進行分析)
根據第三範式把學生關系表分為如下兩個表就可以滿足第三範式了：
學生：(學號, 姓名, 年齡, 性別，系別)；
系別：(系別, 系辦地址、系辦電話)。
總結
上面的資料庫表就是符合I,II,III範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
希望對你有幫助哈
2. SQL資料庫查詢去除重復的關鍵字是什麼
distinct 關鍵字可從 select 語句的結果中消除重復的行。如果沒有指定 distinct,將返回所有行,包括重復的行。
資料庫(Database)是按照數據結構來組織、存儲和管理數據的倉庫，它產生於距今六十多年前，隨著信息技術和市場的發展，特別是二十世紀九十年代以後，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。
資料庫有很多種類型，從最簡單的存儲有各種數據的表格到能夠進行海量數據存儲的大型資料庫系統都在各個方面得到了廣泛的應用。
在信息化社會，充分有效地管理和利用各類信息資源，是進行科學研究和決策管理的前提條件。資料庫技術是管理信息系統、辦公自動化系統、決策支持系統等各類信息系統的核心部分，是進行科學研究和決策管理的重要技術手段。
資料庫，簡單來說是本身可視為電子化的文件櫃--存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。
資料庫指的是以一定方式儲存在一起、能為多個用戶共享、具有盡可能小的冗餘度的特點、是與應用程序彼此獨立的數據集合。
在經濟管理的日常工作中，常常需要把某些相關的數據放進這樣的"倉庫"，並根據管理的需要進行相應的處理。
例如，企業或事業單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個資料庫。
有了這個"數據倉庫"我們就可以根據需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內的職工人數等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。
此外，在財務管理、倉庫管理、生產管理中也需要建立眾多的這種"資料庫"，使其可以利用計算機實現財務、倉庫、生產的自動化管理。
3. SQL中的數據冗餘的最佳解決方法是什麼
數據應該盡可能少地冗餘，這意味著重復數據應該減少到最少。比如說，一個部門雇員的電話不應該被存儲在不同的表中， 因為這里的電話號碼是雇員的一個屬性。如果存在過多的冗餘數據，這就意味著要佔用了更多的物理空間，同時也對數據的維護和一致性檢查帶來了問題，當這個員工的電話號碼變化時，冗餘數據會導致對多個表的更新動作，如果有一個表不幸被忽略了，那麼就可能導致數據的不一致性。 從一範式轉化到二範式根據第二範式的定義，轉化為二範式就是消除部分依賴。考察表1-1，我們可以發現，非主屬性<Project Name>部分依賴於主鍵中的<Project Number>; 非主屬性<Employee Name>，<Salary Category>和<Salary package>都部分依賴於主鍵中的<Employee Number>；表1-1的形式，存在著以下潛在問題：1． 數據冗餘：每一個欄位都有值重復；2． 更新異常：比如<Project Name>欄位的值，比如對值"TPMS"了修改，那麼就要一次更新該欄位的多個值；3． 插入異常：如果新建了一個Project，名字為TPT, 但是還沒有Employee加入，那麼<Employee Number>將會空缺，而該欄位是主鍵的一部分，因此將無法插入記錄；Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 'TPT', NULL, NULL, NULL, NULL)
4． 刪除異常：如果一個員工 200003, Kevin 離職了，要將該員工的記錄從表中刪除，而此時相關的Salary信息 C 也將丟失, 因為再沒有別的行紀錄下 Salary C的信息。Delete from sample where EMYNUM = 200003
Select distinct SALCATEGORY, SALPACKAGE from SAMPLE因此，我們需要將存在部分依賴關系的主屬性和非主屬性從滿足第一範式的表中分離出來，形成一張新的表，而新表和舊表之間是一對多的關系。由此，我們得到：
CREATE TABLE "PROJECT" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200)) IN "USERSPACE1";ALTER TABLE "PROJECT" ADD PRIMARY KEY ("PRJNUM");Insert into PROJECT(PRJNUM, PRJNAME) values(100001, 'TPMS'), (100002, 'TCT');
表1-2
表 1-3
CREATE TABLE "EMPLOYEE" ( "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER) IN "USERSPACE1";ALTER TABLE "EMPLOYEE" ADD PRIMARY KEY ("EMYNUM");Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,'Johnson', 'A', 2000), (200002, 'Christine', 'B', 3000), (200003, 'Kevin', 'C',4000), (200004, 'Apple', 'B', 3000);Employee Number Employee Name Salary Category Salary Package200001 Johnson A 2000200002 Christine B 3000200003 Kevin C 4000200004 Apple B 3000
CREATE TABLE "PRJ_EMY" ( "PRJNUM" INTEGER NOT NULL, "EMYNUM" INTEGER NOT NULL) IN "USERSPACE1";ALTER TABLE "PRJ_EMY" ADD PRIMARY KEY ("PRJNUM", "EMYNUM");Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),(100001, 200003), (100002, 200001), (100002, 200004);
同時，我們把表1-1的主鍵，也就是表1-2和表1-3的各自的主鍵提取出來，單獨形成一張表，來表明表1-2和表1-3之間的關聯關系：
表 1-4
這時候我們仔細觀察一下表1-2, 1-3, 1-4, 我們發現插入異常已經不存在了，當我們引入一個新的項目 TPT 的時候，我們只需要向表1-2 中插入一條數據就可以了， 當有新人加入項目 TPT 的時候，我們需要向表1-3, 1-4 中各插入一條數據就可以了。雖然我們解決了一個大問題，但是仔細觀察我們還是發現有問題存在。
回頁首
從二範式轉化到三範式考察表前面生成的三張表，我們發現，表1-3存在傳遞依賴關系，即：關鍵欄位< Employee Number > --> 非關鍵欄位< Salary Category > -->非關鍵欄位< Salary Package >。而這是不滿足三範式的規則的，存在以下的不足：1、 數據冗餘：<Salary Category>和<Salary Package>的值有重復；2、 更新異常：有重復的冗餘信息，修改時需要同時修改多條記錄，否則會出現數據不一致的情況；3、 刪除異常：同樣的，如果員工 200003 Kevin 離開了公司，會直接導致 Salary C 的信息的丟失。Delete from EMPLOYEE where EMYNUM = 200003
Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE因此，我們需要繼續進行規范化的過程，把表1-3拆開，我們得到：
表 1-5
和
表 1-6
這時候如果 200003 Kevin 離開公司，我們只需要從表 1-5 中刪除他就可以了， 存在於表1-6中的Salary C信息並不會丟失。但是我們要注意到除了表 1-5 中存在 Kevin 的信息之外， 表1-4中也存在 Kevin 的信息， 這很容易理解， 因為 Kevin 參與了項目 100001， TPMS， 所以當然也要從中刪除。 至此，我們將表1-1經過規范化步驟，得到四張表，滿足了三範式的約束要求，數據冗餘、更新異常、插入異常和刪除異常。在三範式之上，還存在著更為嚴格約束的BC範式和四範式，但是這兩種形式在商業應用中很少用到，在絕大多數情況下，三範式已經滿足了資料庫表規范化的要求，有效地解決了數據冗餘和維護操作的異常問題。