❶ oracle 會話連接數什麼意思
連接資料庫採用會話的模式。會話連接數是說的是最多可以支持同時多少個連接連到資料庫。因為資料庫系統也會管理進程的。
❷ 什麼是資料庫連接連接和會話之間有什麼關系
原理上和網站的一個session差不多，只是session是把key放在cookie裡面，資料庫連接是把key放在客戶端的library的內存里（比如.Net Sql Client)。對MS SQL來說，這個連接的協議叫TDS，底下可以走多種傳輸層協議，比如tcpip，也可以named pipe。而MySQL就又有自己的協議。當然在拿到key之前，先要走個authentication過程，比如Windows Authentication或者Sql authentication，過了authentication才會產生一個session key。如果是啟用SSL的話那麼整個連接上的數據流還會被加密，防止信息泄露或者中間人攻擊。
❸ windows自帶性能監控器問題
你要滴在任務管理器里全部都有 ALT +DEL+ CTRL
Windows 性能監視器工具
如果需要在一台計算機上監視多個 Report Server 實例，可以同時或單獨監視這些實例。選擇要包括的實例是計數器添加過程的一部分。有關使用 Windows 附帶的性能工具的更多信息，請參見微軟 Windows 產品文檔。
若要訪問性能工具
• 從「開始」菜單上選擇「運行」。
• 在「打開」文本框中輸入「perfmon」，然後單擊「確定」。
• 在性能監視器工具中，在左側窗格里選擇 System Monitor 對象，然後右擊「性能」圖表。
• 選擇「添加計數器」。
現在，可以開始選擇這些對象和要監視的計數器了。
ASP.NET 應用程序性能計數器
有關 ASP.NET 應用程序性能計數器的大部分信息最近已被合並到一個題為「改善 .NET 應用程序的性能和伸縮性」的綜合文檔中。下表描述了一些可用於監視和優化 ASP.NET 應用程序（包括 Reporting Services）性能的重要計數器。
性能對象 計數器 實例 描述
Processor（處理器）
% Processor Time（處理器時間百分比）
__Total
「% Processor Time」監視運行 Web 伺服器的計算機的 CPU 利用率。低 CPU 利用率或者無法最大化 CPU 利用率（無論客戶端負載為多少）都表明 Web 應用程序中存在對資源的爭用或鎖定。
Process（進程）
% Processor Time（處理器時間百分比）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
由 ASP.NET 工作進程所使用的處理器時間所佔的百分比。在將標准負載情況下的性能與先前捕獲的基準進行對比時，如果此計數器的值出現下降，則說明降低了對處理器的需求，因此也提高了伸縮性。
Process（進程）
Working Set（工作集）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
由 ASP.NET 主動使用的內存數量。雖然應用程序開發人員對應用程序使用的內存數量擁有最大的控制權，但系統管理員也可通過調整會話的超時期限來顯著影響這一點。
Process（進程）
Private Bytes（專有位元組）
aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）
Private Bytes 是當前分配給該進程且不能由其他進程共享的內存數量（以位元組計）。不時出現的尖峰表明某些地方存在瓶頸，會導致工作進程繼續持有不再需要的內存。如果此計數器突然下降為接近 0 的值，則可能表示 ASP.NET 應用程序由於無法預料的問題進行了重啟。為了驗證這一點，請監視「ASP.NET Application Restarts」計數器。
ASP.NET Applications（ASP.NET 應用程序）
Requests/ Sec（每秒的請求數）
__Total
允許您檢驗請求的處理速度是否於發送速度相適應。如果每秒請求數的數值低於每秒產生的請求數，則會出現排隊現象。這通常意味著已經超過了最大請求速度。
ASP.NET Applications（ASP.NET 應用程序）
Errors Total（總錯誤數）
__Total
在執行 HTTP 請求期間發生的錯誤總數。包括任何分析器、編譯或運行時錯誤。此計數器是「Errors During Compilation」（編譯錯誤數）、「Errors During Preprocessing」（預處理錯誤數）和「Errors During Execution」（執行錯誤數）計數器的總和。運轉正常的 Web 伺服器不應產生任何錯誤。如果錯誤發生在 ASP.NET Web 應用程序中，它們的存在可能會讓實際的吞吐量結果產生偏差。
ASP.NET
Request Execution Time（請求執行時間）
顯示了呈現所請求頁面並將其傳送給用戶所需的時間（以毫秒計）。跟蹤此計數器通常要比跟蹤頁面呈現時間效果更好。此計數器可以更全面地衡量從開始到結束的整個請求時間。在與基準進行對比時，如果此計數器的平均值較低，則說明應用程序的伸縮性和性能均得到了改善。
ASP.NET
Application Restarts（應用程序重新啟動）
應用程序在 Web 伺服器生存期間發生重新啟動的次數。每次發生 Application_OnEnd 事件時，應用程序的重新啟動次數都會增加。應用程序進行重新啟動的原因可能是：更改了 Web.config 文件、更改了存儲在應用程序的 \bin 目錄下的程序集、或者 Web Forms 頁面中發生了太多的更改。如果此計數器的值出現意料之外的增加，說明某些不可預知的問題導致 Web 應用程序被關閉。在這種情況下，應該認真調查問題原因。
ASP.NET
Requests Queued（排隊的請求數）
在隊列中等待服務的請求數。如果此數字隨著客戶端負載的增加而呈現線性的增長，則說明 Web 伺服器計算機已經達到了它能夠處理的並發請求極限。此計數器的默認最大值為 5,000。您可以在計算機的 Machine.config 文件中更改此設置。
ASP.NET
Worker Process Restarts（工作進程重新啟動）
工作進程在伺服器計算機上重新啟動的次數。如果出現意料之外的故障或者被有意回收，則工作進程會重新啟動。如果此計數器的值出現意料之外的增加，應認真調查問題原因。
除了上表中介紹的這些核心監視要素之外，在您試圖診斷 ASP.NET 應用程序具有的特定性能問題時，下表中的性能計數器也可對您有所幫助。
性能對象 計數器 實例 描述
ASP.NET Applications（ASP.NET 應用程序）
Pipeline Instance Count（管線實例計數）
__Total
指定 ASP.NET 應用程序的活動請求管線實例的數量。由於只有一個執行線程可以在管線實例內運行，所以此數值反映了為特定應用程序處理的並發請求的最大數量。大多數情況下，在存在負載的情況下此數值較低為佳，這表明處理器得到了很好的利用。
.NET CLR Exceptions（.NET CLR 異常）
# of Exceps Thrown（引發的異常數）
顯示應用程序中引發的異常數。如果此數值出現意料之外的增加，說明可能存在性能問題。如果僅僅存在異常，則並不需要擔心，因為異常對於某些代碼路徑來說是正常工作的一部分。例如，HttpResponse.Redirect 方法通過引發一個不可捕獲的異常 ThreadAbortException 來完成工作。同樣，對 ASP.NET 應用程序跟蹤此計數器也更加有用。使用「Errors Total」計數器確定該異常是否將導致應用程序出現意料之外的錯誤。
System（系統）
Context Switches/ sec（每秒的上下文切換次數）
測量 Web 伺服器計算機上所有處理器切換線程上下文的速度。如果此計數器的值很高，可能表示對鎖的爭用頻繁發生，或者在線程的用戶模式和內核模式之間切換頻繁。使用采樣優化程序和其他工具執行進一步調查可證實上述猜測。
Reporting Services 性能計數器
Reporting Services 包括一組它自己的性能計數器，用於收集有關報告處理和資源消耗方面的信息。可通過 Windows 性能監視器工具中出現的兩個對象來監視實例和組件的狀態和活動：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 對象。
MSRS 2005 Web Service 性能對象包括一組用來跟蹤 Report Server 處理過程的計數器，這些處理過程通常通過在線互動式報告瀏覽操作而引發。這些計數器在 ASP.NET 停止該 Web 服務後被重設。下表列出了可用於監視 Report Server 性能的計數器，並描述了它們的目的。
性能對象：RS Web Service
計數器 描述
Active Sessions（活動會話數）
活動會話的數量。此計數器反映了尚未過期的所有瀏覽器會話總數。這並不是同時處理的請求數，而是存儲在 ReportServerTempDB 資料庫中的會話數量。
Cache Hits/Sec（每秒緩存命中次數）
每秒從目錄中取得的報告請求的數量。如果此值增加，而「Memory Cache Hits」的值不增加，則說明報告數據沒有被重新處理，但是頁面被重新呈現。將此計數器與 Memory Cache Hits/Sec 計數器一同使用，可以確定用於緩存、磁碟或內存的資源是否充足。
Cache Misses/Sec（每秒緩存未命中數）
每秒未能從目錄中（與內存中相對）返回報告的請求數量。將此計數器與 Memory Cache Misses/Sec 計數器一同使用，可以確定用於緩存、磁碟或內存的資源是否充足。
First Session Requests/Sec（每秒的首次會話請求數）
每秒中從 Report Server 緩存中啟動的新的用戶會話數量。
Memory Cache Hits/Sec（每秒內存緩存命中數）
每秒中從內存中的緩存里取得報告的次數。內存中緩存是 Reporting Services 緩存的一部分，用於在內存或臨時文件中保存已呈現過的報告。這樣可以為請求提供最佳的性能，因為無需執行任何處理工作。如果使用內存中緩存，報告伺服器將不會通過查詢 SQL Server 來獲得緩存的內容。
Memory Cache Misses/Sec（每秒內存緩存未命中數）
每秒中未能從內存中的緩存里取得報告的次數。
Next Session Requests/Sec（每秒的下一次會話請求）
每秒在現有會話中請求打開報告的次數。
Report Requests（報告請求）
當前處於活動狀態並且將由 Report Server 進行處理的報告數量。
Reports Executed/Sec（每秒執行的報告數）
每秒成功執行的報告的數量。此計數器提供了有關報告處理量的統計信息。綜合使用此計數器和 Request/Sec，比較可從緩存中返回的報告請求的執行情況。
Requests/Sec（每秒的請求數）
每秒向 Report Server 發出的請求數。此計數器跟蹤由 Report Server 處理的所有類型的請求。
Total Cache Hits（緩存命中總數）
自服務啟動以來，從緩存中獲得報告的請求總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。
Total Cache Misses（總的緩存未命中數）
自服務啟動以來，不能從緩存中獲得報告的總次數。此計數器在 ASP.NET 停止該 Web 服務後被重設。可使用此計數器確定磁碟空間和內存是否充足。
Total Memory Cache Hits（總的內存緩存命中數）
自服務啟動以來，從內存中緩存里返回的已緩存報告的總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。內存中緩存是在 CPU 內存中存儲報告的那部分緩存。如果使用內存中緩存，報告伺服器將不會通過查詢 SQL Server 來獲得緩存的內容。
Total Memory Cache Misses（總的緩存未命中數）
自服務啟動以來，針對內存中緩存的緩存未命中總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。
Total Processing Failures（處理故障總數）
自服務啟動以來，發生的所有報告處理故障的總數。此計數器在 ASP.NET 停止該 Web 服務後被重設。處理故障可能來自報告處理器，也可能來自任何擴展。
Total Reports Executed（執行的報告總數）
自服務啟動以來得到成功執行的報告的總數。
Total Requests（總請求數）
自服務啟動以來，向 Report Server 發送的所有請求的總數。
RS Windows Service 性能對象包括一組用於跟蹤報告處理過程的計數器，這些處理過程是通過預定操作而引發的。預定操作可能包括訂閱和交付、報告執行快照以及報告歷史。微軟的工作負載中並不包含任何預定操作或交付操作，此處列出這些性能計數器僅是便於您進行參考。
可使用此性能對象監視 Report Server Windows 服務。如果您准備在一個橫向伸縮配置中運行 Report Server，那麼這些計數器應用於所選的伺服器，而不是應用於橫向伸縮配置整體。這些計數器在應用程序域回收之時將被重設。下表列出了可用於監視預定和交付操作的計數器，並描述了它們的目的。
性能對象：RS Windows Service
計數器 描述
Cache Flushes/Sec(每秒緩存刷新次數)
每秒刷新緩存的次數。
Cache Hits/Sec（每秒緩存命中數）
每秒獲取到緩存報告的請求數量。
Cache Misses/Sec（每秒緩存未命中數）
每秒未能從緩存中獲得報告的請求的數量。
Delivers/Sec（每秒交付數）
每秒從各種交付擴展交付的報告的數量。
Events/Sec（每秒事件數）
每秒處理的事件數量。被監視的事件，包括 SnapshotUpdated 和 TimedSubscription。
Memory Cache Hits/Sec（每秒內存緩存命中數）
每秒中從內存中的緩存里取得報告的次數。
Memory Cache Misses/Sec（每秒內存緩存未命中數）
每秒中未能從內存中的緩存里取得報告的次數。
Report Requests（報告請求數）
當前處於活動狀態並且將由 Report Server 進行處理的報告數量。可使用此計數器評估緩存策略。向特定呈現擴展提交的請求數。請求的數量可能比執行的報告數量多許多。
Reports Executed/Sec（每秒執行的報告數）
每秒成功執行的報告的數量。
Snapshot Updates/Sec（每秒快照更新數）
每秒報告執行快照的預定更新數量。
Total App Domain Recycles（應用程序域回收總數）
自服務啟動以來回收的應用程序域總數。
Total Cache Flushes（緩存刷新總數）
自服務啟動以來，Report Server 的緩存更新總數。
Total Cache Hits（緩存命中總數）
自服務啟動以來，從緩存中獲得報告的請求總數。
Total Cache Misses（總的緩存未命中數）
自服務啟動以來，不能從緩存中獲得報告的總次數。
可使用此計數器確定是否需要更多磁碟空間或內存。
Total Deliveries（總交付數）
由 Scheling and Delivery Processor 交付的報告總數（對於所有交付擴展）。
Total Events（總事件數）
自服務啟動以來發生的事件的總數。
Total Memory Cache Hits（總的內存緩存命中數）
自服務啟動以來，從內存中緩存里返回的已緩存報告的總數。
Total Memory Cache Misses（總的緩存未命中數）
自服務啟動以來，針對內存中緩存的緩存未命中總數。
Total Processing Failures（處理故障總數）
自服務啟動以來，發生的所有報告處理故障的總數。處理故障可能來自報告處理器，也可能來自任何擴展。
Total Rejected Threads（被拒絕的線程總數）
拒絕執行非同步處理後在同一線程中作為同步過程在以後進行處理的數據處理線程總數。
Total Report Executions（報告執行總數）
已執行報告的總數。
Total Requests（請求總數）
自服務啟動以來得到成功執行的報告的總數。
Total Snapshot Updates（快照更新總數）
自服務啟動以來，報告執行快照進行更新的總數。
如果您打算排除 Reporting Services 存在的性能問題，記錄以下性能計數器通常很有幫助：ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。
可選的 Reporting Services 性能計數器
以下列出了一些適用於 RS Web Service 但在默認情況下並未安裝的性能計數器。但是，在執行性能優化工作時，可以通過這些計數器來改善您洞察性能的能力。為實現這個目的，請在命令提示符中執行以下語句：
installutil.exe /u ReportingServicesLibrary.dll
然後再執行：
installutil.exe ReportingServicesLibrary.dll
為了成功執行該語句，您可能首先需要修改您的路徑，在路徑中包含 Microsoft .NET Framework 的安裝目錄。在路徑修改完畢後，請從包含 ReportingServicesLibrary.dll 文件的目錄下執行先前語句。默認情況下，該文件安裝在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目錄下。這些計數器沒有進行徹底的本地化。
Active Database Connections（活動資料庫連接）
某個時間處於活動狀態的資料庫連接的數量。只統計指向 Report Server 目錄的連接。
Active Datasource Connections（活動數據源連接）
某個時間處於活動狀態的資料庫連接的數量。只統計由當前運行的報告打開的數據源連接。
Active Threads（活動線程）
當前處於活動狀態的線程數量。在 Web 服務中，它包含一些為請求提供服務的線程。在交付服務中，它包含工作線程以及維護和輪詢線程。
Byte count（位元組計數）
對於上一次請求，在呈現當前報告時向客戶端返回的位元組數量。這與對應的執行日誌條目相類似。
Row Count（行計數）
對於上一次請求，由當前報告返回的行的數量。這與對應的執行日誌條目相類似。
Time in Compression（壓縮時間）
對於上一次請求，在快照和 PDF 報告壓縮上花費的時間（以毫秒計）。
Time in data source access（數據源訪問時間）
對於上一次請求，在獲取報告的數據源信息上花費的時間（以毫秒計）。其中包括執行查詢和取回結果所需的時間。這與對應的執行日誌條目相類似。
Time in database（資料庫時間）
對於上一次請求，在獲取 Report Server 目錄信息上花費的時間（以毫秒計）。
Time in processing（處理時間）
對於上一次請求，在報告處理上花費的時間（以毫秒計）。這與對應的執行日誌條目相類似。
Time in rendering（呈現時間）
對於上一次請求，在呈現報告上花費的時間（以毫秒計）。這與對應的執行日誌條目相類似。
❹ 資料庫的基本功能是什麼
網路不僅僅為我們提供了一個相互通信的途徑，而且還是一個有史以來人類最豐富的信息資源庫，還是一龐大的，可供人們相互交流思想的自由論壇，還是一場當代高技術與商貿相結合的電子商務革命。
Internr主要可以幫助網上用戶實現以下基本功能：
（1）收發電子郵件
收發電子郵件是Internet最基本且使用很廣泛的服務之一，人們使用Internr電子郵件系統可方便、快捷、經濟地與世界各地聯網的用戶收發郵件。普通國際郵件一般要一周左右才能送達，而電子郵件則在轉瞬間完成郵件發送，價格約為普通郵件的1/10～1/5，由於多用途的郵件協議（MIME），使用電子郵件系統可以發送多媒體信息（包括圖像、文本文件、聲音等）。電子郵件提高了人們對信息的利用速度和利用水平，從而使電子郵件成為最受人歡迎的通信方式，它正在逐漸取代傳統的郵政系統，在Internr用戶較多的國家，傳統的郵政系統已經受到嚴重的沖擊。
（2）網路文件傳輸服務
在Internr發展早期，網路中許多文件信息特別是電腦共享自由軟體，是以匿名網路文件傳輸（Aobryroods，FTP），在網路中進行傳遞的，它對Internr的發展起了很重要的作用，就是現在，網路文件傳輸服務在Internr信息傳輸中仍是不可缺少的。
人們使用網路文件傳輸服務可以下載各種實用軟體、數據、文件等，對信息共享、傳送、交流具有十分重要的意義。
（3）網路信息資源檢索
Internr作為一個有史以來人類最大最豐富的信息知識空間，目前它的信息量近乎是無限的。它的信息資源主要存放在世界各地的網路伺服器中，它的信息內容極其廣泛，包括藝術、建築、文學、商業投資、國際貿易、經濟、教育、聯機圖書館資料庫、娛樂、電影、音樂、時實新聞、雜志、報紙、體育、游戲、政治、軍事、法律、科學、技術、環境、宗教等，五花八門，應有盡有。
目前，Internr的資源以WWW超文本信息內容最為豐富，WWW檢索工具的訪問使用率最高。主要的WWW檢索引擎有：Yahoo、AltaVista、BigBook公司、EXeife、Infoseek、Lyeos公司、WebnCrawler，上述檢索引擎一般向用戶提供兩種檢索方式，即目錄檢索和關鍵詞檢索。
總之，只要你需要信息，就可以直接進行網路檢索，獲取信息，為我所用。
（4）Internr網路新聞
在Internr中，還有一個世界范圍的自由論壇，即網路新聞。它利用Internr網路通信系統進行網路新聞傳輸。網路新聞是免費的，它包括8000多個專題，涉及的內容極其豐富，任何一個人都可以從中找到自己感興趣的題目，並與世界各地互不相識的人們進行問題討論和思想交流。
通過網路新聞，你可以向世界各地素不相識的人們提問，並陳述自己的觀點和意見。如果你經常閱讀網路新聞，你將從中獲取許多有益的幫助，它將成為你的良師益友。
除了網路新聞USENET外，讀者還可以通過www網址：http://www.cnn.com瀏覽Internr多媒體新聞，它是由美國有線新聞網路CNN在Internr上建立的WWW新聞站點，CNN是世界上最大的從事電視新聞的公司。讀者通過該站點不僅可以瀏覽CNN發布的世界各地新聞內容，還可以獲取有關天氣、運動、科技、保健、娛樂等信息內容，包括北京地區四天內的天氣預報。
❺ SQL 請問SQL高手，系統中的這幾個資料庫都是做什麼用的
數據：計算機中用來描述事物的記錄
數據模型：是一種對客觀事物抽象化的表現形式。數據模型應該真實、易於理解、便於實現
建模：對客觀事物加以抽象，提取主要特徵，歸納成一個簡單清晰的輪廓，使復雜問題變得易於處理
數據模型三要素：數據結構、數據操作、完整性約束
數據結構描述靜態特徵，按數據結構可以把數據模型分為層次模型、網狀模型、關系模型
數據操作描述動態特徵，數據操作主要分為更新（插入、刪除、修改）、檢索兩大類，統稱增、刪、改、查
完整性約束確保數據的正確性、有效性、相容性
資料庫：簡稱DB(database)，是由資料庫管理系統管理的數據的聚集
資料庫管理系統:簡稱DBMS(DataBase Management System)是專門用於建立和管理資料庫的一套軟體，介於應用程序和操作系統之間。屬於系統軟體
資料庫系統：簡稱DBS（DataBase System)。資料庫、DBMS、應用程序和軟體系統統稱資料庫系統
關系：關系就是一張二維表
關系模型：數據以關系的形式表示，就是以二維表的形式表示數據模型
屬性：關系的標題欄中各列的名字
模式：關系的名稱和關系的屬性集
元組：二維表的所有行統稱為元組，元組的各個分量對應於關系的各個屬性。一個元組表示一個對象
域：關系的每個屬性的取值范圍
關系的實例：給定關系中元組的集合稱為該關系的「實例」。一個給定的關系模式，可以有許多關系實例。
關系型資料庫管理系統：簡稱RDBMS(Relationg DataBase Management System)，採用關系數據模型的資料庫管理系統。
資料庫系統的體系結構的三層結構和兩層映象：從資料庫管理的角度出發，資料庫系統的體系可分三層，外模式、模式、內模式。兩層映象是，外模式/模式映象、模式/內模式映象
外模式：又稱用戶模式，相當於SQL中的視圖（VIEW)模式，是資料庫用戶可以看見和使用的局部數據的邏輯結構和特徵描述，是與某應用有關的數據的邏輯表示
模式：分為概念模式、邏輯模式，是所有資料庫用戶的公共數據視圖，是資料庫中全部數據的邏輯結構和特徵的描述，一個資料庫只有一個模式
外模式/模式映象：把局部邏輯結構描述與全局邏輯結構描述聯系起來。一個模式可以與多個外模式對應聯系。例如，SQL SERVER中一個關系模式上可以建立多個滿足不同用戶要求的視圖VIEW。這種映象可以保證數據與應用程序之間的邏輯獨立性，即改變模式，不影響外模式，則與外模式相關的應用程序無序修改
內模式：由稱為存儲模式，是資料庫物理結構和存儲方式的描述，是數據在資料庫內部的表示方式。一個資料庫只有一個內模式。內模式描述記錄的存儲方式、索引的組織方式、數據是否壓縮、是否加密等，不涉及硬體設備。
模式/內模式映象：把全局邏輯結構描述與物理結構描述聯系起來。一個模式只有一個內模式。這種映象保證了數據與程序之間的物理獨立性，當內模式修改時，由於模式未變，所以無需修改程序。
DBMS的體系結構（組成）：查詢處理程序、存儲管理程序、事務管理程序、客戶/伺服器程序體系結構
查詢處理程序：負責查詢處理，它的一個重要任務是「優化」查詢。
事務管理程序：保證多個事務並發執行
存儲管理程序：既管理磁碟上的數據文件又管理存放數據文件部分內容的內存數據緩沖區
客戶/伺服器程序體系結構：大多數DBMS程序採用這種程序體系結構，把整個DBMS程序系統劃分為兩部分，DBMS核心部分屬於伺服器程序，客戶程序主要用於與用戶相互配合並將查詢或其他命令傳送給伺服器程序的查詢介面。
資料庫設計
資料庫設計的步驟：需求分析、概念設計、邏輯設計、物理設計
需求分析和概念設計階段的工作與具體資料庫管理系統無關，這一階段的工作獨立於資料庫管理系統
邏輯設計和物理設計階段的共組與具體採用何種資料庫管理系統相關。
需求分析階段：應用領域的調查、定義信息與應用、定義操作任務、定義數據項、預測未來改變，結果產生相關文檔
概念設計階段：也稱為建模
任務：資料庫概念模式（模式）設計、事務設計
概念模式設計的工具：E/R圖。對於面向對象的資料庫則可採用面向對象定義語言ODL
E/R圖：稱為實體-聯系模型
E/R圖的組成：實體集（矩形）、屬性（橢圓）、聯系（菱形）
聯系的類型：一對一、一對多、多對多。用線條和箭頭表示不同的聯系。箭頭指向的一方代表「一」
鍵碼屬性的表示：下劃線
聯系中的角色：即一個實體集內部實體之間的聯系
多向聯系：多個實體集之間發生的一個聯系
多向聯系轉化為雙向聯系的方法：將多向聯系轉換成實體集，然後在原來與之聯系的實體集和新的實體集之間建立新的雙向聯系
E/R圖中的子類的表示方法和繼承：如果實體集B是實體集A的子類，則它們之間用一個標有isa的三角形和兩根線條建立特殊的聯系。三角形的尖端指向超類（父類），子類實體集上只需標出子類特有的屬性，繼承父類的所有屬性。
ODL對象定義語言：是用面向對象的術語來說明資料庫結構的一種推薦的標准語言，主要用途是書寫面向對象資料庫的設計
對象：是某種可研究，可觀察的實體，例如：一個人、一門課程、一本書等等
類：具有相似特性的對象可以歸為一類
ODL描述的三種特性：屬性（Attribute)、聯系（Relationship)、方法(Method)
ODL書寫規則：
interface 類名1{
attribute 數據類型1 屬性名1；
attribute 數據類型2 屬性名2；
.
.
.
relationship [Set]<類名2> 聯系名1
inverse 類名2::聯系名2；
.
.
}
說明：
關鍵字interface、attribute、relationship、<set>、inverse
常用數據類型有string（字元串）、integer（整型）、float（浮點型）、enum（枚舉型）
[]中的set為任選項，當類1與類2的聯系是一對一時，不需要使用set，當類1與類2的聯系是一對多時必須使用set
inverse表示在類2中聯系名2所表示的聯系與類1中聯系名1所表示的聯系是多對一的對應聯系
ODL例一：用ODL描述製片公司與電影，假如製片公司部名稱不重復。因為，一個製片公司可以製作多部影片，而一部影片只能由一個公司製作發行，所以製片公司與影片的關系是一對多的關系。
interface studio{
attribute string studioname;
attribute string address;
attribute string phone;
relationship set<movie> make
inverse movie::madeby;
}
interface movie{
attribute string movietitle;
attribute integer length;
attribute enum incolor ;
attribute integer year;
relationship set studio madeby
inverse studio::make;
}
ODL例二：用ODL描述學生與課程，一名學生可以選擇多門課程來學習，一門課程可以被多名學生選修。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
relationship set<course> choice
inverse course::choisedby;
}
interface course{
attribute string ctitle;
attribute integer credit;
relationship set<student> choisedby
inverse student::choice;
}
ODL例三：用ODL描述校長與學校的關系，一名校長只能管理一所學校，一所學校只能設一名校長。
interface chairman{
attribute string chname;
attribute enum gender ;
attribute integer age;
attribute string phone;
relationship set university manage
inverse university::leadby;
}
interface university{
attribute string unnmae;
attribute string addr;
relationship set chairman leadby
inverse chairman::manage;
}
ODL子類描述方法：自類繼承父類的所有屬性和聯系。子類可以有自己的特殊屬性和聯系。子類中屬性和聯系的描述方法與上述例子相同。
interface 子類名:基類名
ODL子類描述例：碩士研究生類是學生的一個子類。每名碩士研究生有若干名導師，一名導師可以帶多名碩士研究生。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
}
interface master:student{
attribute string special;
relationship set<advisor> direct
inverse advisor::directedby;
}
interface advisor{
attribute string name;
attribute string address;
}
邏輯設計階段：把概念設計階段產生的資料庫概念模式變換為資料庫邏輯模式。資料庫邏輯模式依賴於邏輯數據模型和資料庫管理系統。目前做流行的資料庫管理系統都是關系型邏輯數據模型。所以，本教程知討論如何把概念模式轉變為關系模型
邏輯設計階段的步驟：
1.概念模式轉變為關系模型
2.對關系模型進行規范化和優化
3.適應DBMS限制條件的修改
4.對性能、存儲空間等的優化
1.概念模式轉變為關系模型
E/R圖轉變為關系模型的方法：
1.一個實體集轉變為一個關系模式，這個關系模式包含實體集所有的簡單屬性和復合屬性的簡單子屬性。實體集的名稱可以用作為關系模式的名稱，用下劃線來表示關系的鍵碼
2.一個聯系轉變為一個關系模式，一般情況下用聯系名作為關系名，用聯系的實體集的鍵碼和聯系本身的屬性作為此關系模式的屬性集。
E/R圖轉變為關系模型實例：
實例一：一個班級只能有一個班長，而且必須有一個班長，E/R圖如下：
學生與班級的聯系是一對一的聯系(1:1)。學生實體集的鍵碼是學號。班級實體集的鍵碼是班號。這個E/R圖可以轉變為如下的關系模型
學生（學號，姓名，性別，出生日期）
班級（班號，名稱，地點）
班長（學號，班號，注冊）
聯系反映的是具有某學號的學生擔任具有某班號班級的班長。這種轉變方法是常用的方法。
如果想減少查詢時使用連接操作的次數，提高查詢效率，以上E/R圖也可以轉變為如下關系模型
學生（學號，姓名，性別，出生日期，班號）
班級（班號，名稱，地點）
學生關系模式中的「班號」是外鍵碼。這種關系模式中，由於學生關系中記錄了所有學生的學號，但不是每個學生都擔任班長（按教科書上的術語叫做不是全參與），因此不是每個元組的班號屬性都有數據，即應該允許班號為空。否則，學生實體集必須是全參與，即每個學生都是班長。
實例二：一個影片公司可以製作多部影片，但是一部影片只能歸一個製片公司所有。假如公司不重名，影片也不重名，則公司名稱是製片公司實體集的鍵碼，影片名是影片實體集的鍵碼。
影片公司與影片的聯系是1對多的聯系（1：N)。這個E/R圖可以轉變為以下關系模型
影片公司（公司名稱，地點）
影片（影片名，片長）
製作（公司名稱，影片名）
同樣，假如影片公司是全參與，即每個影片公司至少製作了一部電影，則可以轉變為以下關系模型
影片公司（公司名稱，地點，影片名）
影片（影片名，片長）
其中，影片公司關系中的影片名是外鍵碼
實例三：學生與課程之間的聯系是「選修」。一個學生可以選多門課程，一門課程可以被多名學生選修，所以它們之間的「選修」聯系是多對多(N:M)
上述E/R圖可以轉變為以下關系模型
學生（學號，姓名）
課程（課程號，課程名）
選修（學號，課程號，成績）
選修關系中的學號和課程號是外鍵碼
2.對關系模型進行規范化和優化
為什麽要把關系模型規范化：為了有效地消除關系中存在的數據冗餘和更新異常等現象
基本概念
函數依賴：如果關系R的兩個元組在屬性A1，A2，...An上一致，則它們的另一個屬性B上也一致，那末，我們就說在關系R中屬性B函數地依賴於屬性A1，A2，...An或者說屬性A1，A2，...An函數決定屬性B。
關系的鍵碼：
如果一個或多個屬性的集合滿足如下條件，則稱該集合為關系R的鍵碼（key):
1.這些屬性函數決定該關系的所有其它屬性。
2.的任何真子集都不能函數決定R的所有其它屬性。
關系的超鍵碼：包含鍵碼的屬性集稱為超鍵碼，是「鍵碼的超集」的簡稱
函數依賴規則：分解/合並規則、傳遞規則、平凡依賴規則
平凡依賴：對於函數依賴A1，A2，...An->B，如果B是A中的某一個，我們稱這種依賴是平凡依賴
非平凡依賴：對於函數依賴A1，A2，...An->B，如後B中至少有一個不在A中，我們稱這種依賴是非平凡依賴
完全非平凡依賴：對於函數依賴A1，A2，...An->B，B中沒有一個在A中，我們稱這種依賴是完全非平凡依賴
主屬性：鍵碼所在的屬性
非主屬性：鍵碼以外的屬性
封閉集（閉包）對於給定的函數依賴集S，屬性集A函數決定的屬性集合就是屬性集A在依賴集S下的封閉集
範式就是符合某一種級別的關系模式的集合。
規范化通過分解把屬於低級範式的關系模式轉換為幾個屬於高級範式的關系模式的集合，這一過程稱為規范化
1範式（1NF)，如果一個關系模式R的所有屬性都是不可分割的基本數據項，則這個關系屬於1NF
2範式(2NF),若關系模式R屬於1NF，且每個非主屬性都完全依賴於鍵碼，則R屬於2NF
3範式（3NF),若關系模式R屬於1NF，且每個非主屬性都不傳遞依賴於鍵碼，則R屬於3NF
BC範式（BCNF),若關系模式屬於1NF，且R的每個非平凡依賴的決定因素都包含鍵碼，則R屬於BCNF
規范化分解原則：無損連接、保持依賴
無損連接：當對關系模式R進行分解時，R的元組將分別在相應屬性集進行投影而產生新的關系，如果對新的關系進行自然連接得到的元組的集合與原關系完全一致，則稱為無損連接
保持依賴：如果分解後的總的函數依賴集與原函數依賴集保持一致，則稱為保持依賴。
模式分解的兩個規則：公共屬性共享、相關屬性合一
公共屬性共享：保留公共屬性，進行自然連接是分解後的模式實現無損連接的必要條件
相關屬性合一：把以函數依賴的形式聯系在一起的相關屬性放在一個模式中，從而使原有的函數依賴得以保持，這是分解後的模式實現保持依賴的充分條件
模式分解的三種方法
一、部分依賴歸子集；完全依賴隨鍵碼——用於建立2NF
例：關系R(A,B,C,D,E,F,G)上存在函數依賴,A->BCD,E->F,AE->G,AE->BCD,AE->F
分析以上依賴可以看出，AE是鍵碼（AE->BCD)。因為AE是鍵碼，A是主屬性，A->BCD，所以BCD是部分依賴於AE
根據部分依賴歸子集的方法，因為A是AE的真子集，所以A與BCD歸在一起構成一個關系模式。R1(A,B,C,D)
同理對於AE->F，有E->F所以AE->F是部分依賴，非主屬性F所依賴的真子集是E，所以E和F可以歸在一個關系模式中R2(E,F)
AE->G是完全函數依賴，完全依賴隨鍵碼，所以AEG歸在一個關系模式中R3(A,E,G)
因此R(A,B,C,D,E,F,G)可以分解為符合2NF的關系模式如下:
R1(A,B,C,D)
R2(E,F)
R3(A,E,G)
二、基本依賴為基礎，中間屬性做橋梁——用於建立3NF
例：關系R(A,B,C,D,E)上存在函數依賴,AB->C,C->D,D->E
顯然中間橋梁是C->D，他構成了傳遞依賴鏈，因此，R可以分解為R1(A,B,C),R2(C,D)。分解後在R1，R2中都不存在傳遞依賴。
三、找違例自成一體，舍其右全集歸一；若發現仍有違例，再回首如法炮製——用於建立BCNF
BCNF違例：違背BC範式的函數依賴稱為BC範式違例
例：關系R(A,B,C,D,E)的鍵碼是AB,有函數依賴AB->CDE,ABC->E,C->D
分析上述三個函數依賴可以看出，C->D是BCNF違例。因為它的決定因素不包含鍵碼。我們作如下分解
違例自成一體，即CD構成一個關系模式R1(C,D)
舍其右全集歸一，即從R的屬性中取掉C->D的右邊的屬性D，其左邊的屬性C與其他所有屬性構成一個新的關系R2(A,B,C,E)
新的關系模式如下：
R1(C,D)
R2(A,B,C,E)
注意：以BCNF違例為基礎進行模式分解，最終得到的屬於BCNF的關系模式都能實現無損連接，但未必能保持函數依賴
邏輯設計例一：假如有關系模式R(A,B,C,D)和函數依賴集S=。
（1）找出所有BCNF違例。
（2）如果該關系模式不是BCNF，則將它分解為BCNF
（3）找出所有的違背3NF的依賴
（4）如果該關系不是3NF，則將它分解為3NF
步驟一：找出R在S上的所有非平凡依賴，首先計算封閉集
單屬性封閉集：A+=A,B+=BCD,C+=C,D+=D
雙屬性封閉集：AB+=ABCD,AC+=AC,AD+=AD,BC+=BCD,BD+=BCD,CD+=CD
三屬性封閉集：ABC+=ABCD,ABD+=ABCD,BCD+=BCD,ACD+=ACD
四屬性封閉集：ABCD+=ABCD
步驟二：根據計算所得的封閉集，找出鍵碼和超鍵碼
鍵碼：AB
超鍵碼：ABC,ABD,ABCD
步驟三：找出所有的非平凡函數依賴
B->C,B->D,AB->C,AB->D,BC->D,BD->C,ABC->D,ABD->C
其中，AB->C,AB->D,ABC->D,ABD->C不是BCNF違例，因為前兩個依賴的決定因素本身就是鍵碼，而後兩個依賴的決定因素包含鍵碼。所以，B->C,B->D,BC->D,BD->C是BCNF違例，因為它們的決定因素都不包含鍵碼。實際上可以看出R不是2NF，因為存在部分函數依賴：ABC->D,ABD->C,AB->C,AB->D,B->C,B->D
步驟四：進行BCNF規范。BCNF違例自成一體。從以上BCNF違例中選擇B->C自成一體
R1(B,C)
舍其右全集歸一，即捨去B->C的右邊屬性C，所以得到
R2(A,B,D)
但是在R2中還存在BCNF違例B->D，因此B->D自成一體，得到R21(B,D),舍其右全集歸一得到R22(A,B)
最後得到的關系模式是：R1(B,C),R21(B,D),R22(A,B)
通過關系模式分解，把一個非2NF的關系模式歸范成一個BCNF。代價是，在實際操作中增加了連接操作。
（3）B->C,B->D，B不是鍵碼也不是超鍵碼，而C,D都是鍵碼以外的屬性，即是非主屬性。所以R不是3NF。
邏輯設計例二：有關系R(A,B,C,D)和函數依賴集S=
（1）找出所有BCNF違例。
（2）如果該關系模式不是BCNF，則將它分解為BCNF
（3）找出所有的違背3NF的依賴
（4）如果該關系不是3NF，則將它分解為3NF
步驟一：找出R在S上的所有非平凡依賴，首先計算封閉集
單屬性封閉集：A+=ABCD,B+=ABCD,C+=ABCD,D+=ABCD
雙屬性封閉集：AB+=ABCD,AC+=ABCD,AD+=ABCD,BC+=ABCD,BD+=ABCD,CD+=ABCD
三屬性封閉集：ABC+=ABCD,ABD+=ABCD,BCD+=ABCD,ACD+=ABCD
四屬性封閉集：ABCD+=ABCD
步驟二：找出所有非平凡函數依賴
A->B,A->C,A->D,B->A,B->C,B->D,C->A,C->B,C->D,D->A,D->B,D->C
AB->C,AB->D,AC->B,AC->D,AD->B,AD->C,BC->A,BC->D,BD->A,BD->C,CD->A,CD->B
ABC->D,ABD->C,BCD->A,ACD->B
步驟三：找出鍵碼和超鍵碼
鍵碼：A,B,C,D
超鍵碼：AB,AC,AD,BC,BD,CD,ABC,ABD,BCD,ACD,ABCD
根據以上結果分析，R是3NF也是BCNF
3NF要求不存在每個非主屬性對於鍵碼的部分依賴或傳遞依賴
練習：對於
1.R(A,B,C,D)和函數依賴集S=
2.R(A,B,C,D,E)和函數依賴集S=
3.R(A,B,C,D,E)和函數依賴集S=
（1）找出所有BCNF違例。
（2）如果該關系模式不是BCNF，則將它分解為BCNF
物理設計階段：任務是在資料庫邏輯設計的基礎上，為每個關系模式選擇合適的存儲結構和存取路徑
物理設計階段步驟：
（1）分析影響資料庫物理設計的因素；
（2）為關系模?
請參考
❻ 什麼是SQL會話
會話（SESSION）：當你連接到資料庫用戶時就建立了會話。相當於處理SQL語句的一個平台。
連接到資料庫用戶開始到退出資料庫結束會話就是會話的一個生命周期。