資料庫問題
㈠ 資料庫常見問題
打開資料庫，根據你提供的sql語句來在資料庫中尋找批配的結果。Rs.RecordCount為匹配的條數。如果條數小於等於零則資料庫中沒有與之相匹配的記錄。就彈出「用戶名和密碼不正確」，否則就是正確了～！
㈡ 關於資料庫的幾個基本問題
其實現在常用的資料庫有好幾種，主要有SQLServer、Oracle、Access、Mysql等。當你選擇用哪種資料庫時關鍵在於你的數據大小、安全性、經濟性等等因素。如果你的數據量比較小，安全性能要求不是很高可以用Access和Mysql資料庫。如果數據量較大，安全性能一般則可以用SQLServer資料庫。如果數據量非常大、安全性能要求也很高就可以用Oracle資料庫，但是Oracle資料庫的價格非常昂貴。自己考慮一下吧
㈢ 關於資料庫的幾個問題
1.C
2.A
3.A
4.錯誤
5.錯誤
6.正確
7.
外模式
-模式，模式-內模式
8.
數據結構化
，（
數據共享
性高、
冗餘度
低、易擴充）
9.
關系模型
，
面向對象模型
12.數據的安全性保護，數據的完整性保護
15.
實體完整性
，
參照完整性
16.外模式，模式
㈣ 資料庫系統要解決什麼問題
資料庫系統解決數據處理的需要而發展起來的一種較為理想的數據處理的核心機構。
資料庫系統對數據的存儲的問題得到了很好的解決。計算機的高速處理能力和大容量存儲器提供了實現數據管理自動化的條件。
資料庫系統是為適應數據處理的需要而發展起來的一種較為理想的數據處理系統，也是一個為實際可運行的存儲、維護和應用系統提供數據的軟體系統，是存儲介質 、處理對象和管理系統的集合體。
(4)資料庫問題擴展閱讀：
資料庫系統的特點：
1、數據的結構化，數據的共享性好，數據的獨立性好，數據存儲粒度小，數據管理系統，為用戶提供了友好的介面。
2、資料庫系統的核心和基礎，是數據模型,現有的資料庫系統均是基於某種數據模型的。
3、資料庫系統的核心是資料庫管理系統。
4、資料庫系統一般由資料庫、資料庫管理系統（DBMS）、應用系統、資料庫管理員和用戶構成。DBMS是資料庫系統的基礎和核心。
資料庫系統的基本要求：
1、能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。
2、冗餘數據少，數據共享程度高。
3、系統的用戶介面簡單，用戶容易掌握，使用方便。
4、能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。
參考資料來源：網路-資料庫系統
㈤ 資料庫問題!
數據管理經歷了人工管理、文件系統、資料庫系統三個階段。
關系數據模型由三部分組成:數據結構,關系操作,關系的完整性。
目前,資料庫領域中最常用的數據模型有:
★ 層次模型 ★ 網狀模型 ★ 關系模型
㈥ 關系資料庫存在哪些問題
1.基本數據類型不能滿足需要
2.數據結構簡單
3.數據和行為分離
4.一致約束不完全，只能預定時機檢查
5.事務短壽，並發控制機制簡單
㈦ 資料庫問題
1.設R(U)是一個屬性集U上的關系模式，X和Y是U的子集。 若對於R(U)的任意一個可能的關系r，r中不可能存在兩個元組在X上的屬性值相等， 而在Y上的屬性值不等， 則稱 「X函數確定Y」 或 「Y函數依賴於X」，記作X→Y。
注意的幾點：
1）. 函數依賴不是指關系模式R的某個或某些關系實例滿足的約束條件，而是指R的所有關系實例均要滿足的約束條件。
2）. 函數依賴是語義范疇的概念。只能根據數據的語義來確定函數依賴。 例如「姓名→年齡」這個函數依賴只有在不允許有同名人的條件下成立 3）. 資料庫設計者可以對現實世界作強制的規定。例如規定不允許同名人出現，函數依賴「姓名→年齡」成立。所插入的元組必須滿足規定的函數依賴，若發現有同名人存在， 則拒絕裝入該元組。
例子：
Student(Sno, Sname, Ssex, Sage, Sdept)
假設不允許重名，則有:
Sno → Ssex， Sno → Sage , Sno → Sdept，
Sno ←→ Sname, Sname → Ssex， Sname → Sage
Sname → Sdept
但Ssex －\→ Sage
若 X → Y，並且 Y → X, 則記為 X ←→ Y。
若 Y 不函數依賴於 X, 則記為 X －\→ Y。
2.最小函數依賴集
定義：如果函數依賴集F滿足下列條件，則稱F為最小函數依賴集或最小覆蓋。 ① F中的任何一個函數依賴的右部僅含有一個屬性；
② F中不存在這樣一個函數依賴X→A，使得F與F-{X→A}等價；
③ F中不存在這樣一個函數依賴X→A，X有真子集Z使得F-{X→A}∪{Z→A}與F等價。
3.範式：
1）.第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。
2 ）.第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是唯一的，因此每個員工可以被唯一區分。這個唯一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
3）. 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
不知道您說的F+和拆分是什麼意思，
我只知道關系模式規范化，關系模式分解。
希望對您有幫助。
㈧ 資料庫系統中的常見故障有哪些
新增archives 時的狀況：
條件和假設：自上次鏡像備份以來已經生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像（冷）拷貝；archive log(s) 可用。
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點： 所有Database Files
所有Control Files（沒有archive(s) 或redo(s) 的情況下，control files 的更新無任何意義）
所有On-Line Redo Logs (Not archives) init.ora file（選項）
3. 啟動資料庫： $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
數據文件, 重作日誌和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的所有所失文件的鏡像（冷）拷貝；archive log(s) 可用
恢復步驟（必須採用不完全恢復的手法）：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點：
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
init.ora file（選項）
3. 啟動資料庫然而並不打開：
svrmgrl>startup mount
4. 做不完全資料庫恢復，應用所有從上次鏡像（冷）備份始積累起來的archives：
svrmgrl> recover database until cancel using backup controlfile;
......
......
cancel
5. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
6. 關閉資料庫並做一次全庫冷備份。
數據文件和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝；archive log(s) 可用
恢復步驟：
1. 將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 選項啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
*** 介質恢復完成
（須在應用完最後一個archive log 後cancel ）
4. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
重作日誌和控制文件同時丟失或損壞時：
條件和假設：Control Files 全部丟失或損壞；Archivelog Mode; 有Control Files 的鏡像（冷）拷貝
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
svrmgrl>exit
2. 以Control File 的鏡像（冷）拷貝覆蓋損壞了的Control File:
$ cp /backup/control1.ctl /disk1/control1.ctl
3. 啟動資料庫然而並不打開：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
4. Drop 壞掉的redo log （排除硬體故障）：
svrmgrl> alter database drop logfile group 2;
5. 重新創建redo log:
svrmgrl> alter database add logfile group 2 '/orig_loc/log2.dbf' size 10M;
6. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
（必須馬上cancel ）
7. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
8. 關閉資料庫並做一次全庫冷備份
只發生歸檔重作日誌丟失或損壞時：
根據不同環境和情況，選擇下述手段之一：
a. 馬上backup 全部datafiles （如果系統採用一般熱備份或RMAN 熱備份）
b. 馬上正常關閉資料庫並進行冷備份（如果系統採用冷備份）
c. 冒險前進！不做備份而讓資料庫接著跑，直等到下一個備份周期再做備份。這是在賭資料庫在下一個備份周期到來之前不會有需要恢復的錯誤發生。
注意:冒險前進的選擇：如果發生錯誤而需要資料庫恢復，則最多隻能恢復到出問題archive log 之前的操作現場。從另一個角度講，archive log(s) 出現問題時，資料庫若不需要恢復則其本身並沒有任何問題。
Oracle邏輯結構故障的處理方法：
邏輯結構的故障一般指由於人為的誤操作而導致重要數據丟失的情況。在這種情況下資料庫物理結構是完整的也是一致的。對於這種情況採取對原來資料庫的全恢復是不合適的，我們一般採用三種方法來恢復用戶數據。
採用exp/imp工具來恢復用戶數據：
如果丟失的數據存在一個以前用exp命令的備份，則可以才用這種方式。
1. 在資料庫內創建一個臨時用戶：
svrmgrl>create user test_user identified by test;
svrmgrl>grant connect，resource to test_user;
2. 從以前exp命令備份的文件中把丟失數據的表按照用戶方式倒入測試用戶：
$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
3. 用相應的DML語句將丟失的數據從測試用戶恢復到原用戶。
4. 將測試用戶刪除：
svrmgrl>drop user test_user cascede;
採用logminer來恢復用戶數據：
Logminer是oracle提供的一個日誌分析工具。它可以根據數據字典對在線聯機日誌、歸檔日誌進行分析，從而可以獲得資料庫的各種DML操作的歷史記錄以及各種DML操作的回退信息。根據這些用戶就可以將由於誤操作而丟失的數據重新加入資料庫內。
1. 確認資料庫的utl_file_dir參數已經設置，如果沒有則需要把這個參數加入oracle的初始化參數文件，然後重新啟動資料庫。下面例子中假設utl_file_dir=』/opt/oracle/db01』；
2. 創建logminer所需要的數據字典信息，假設生成的數據字典文本文件為dict.ora：
svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora'， dictionary_location=>'/opt/oracle/db01』);
3. 確定所需要分析的日誌或者歸檔日誌的范圍。這可以根據用戶誤操作的時間來確定大概的日誌范圍。假設用戶誤操作時可能的日誌文件為/opt/oracle/db02/oradata/ORCL/redo3.log和歸檔日誌』/opt/oracle/arch/orcl/orclarc_1_113.ora』。
4. 創建要分析的日誌文件列表，按日誌文件的先後順序依次加入：
svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>』/opt/oracle/arch/orcl/orclarc_1_113.ora』，options=>dbms_logmnr.NEW);
svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>』 /opt/oracle/db02/oradata/ORCL/redo3.log』，options=>dbms_logmnr.ADDFILE);
5. 開始日誌分析，假設需要分析的時間在』2003-06-28 12:00:00』和』2003-06-28 13:00:00』之間：
svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>』 /opt/oracle/db01/dict.ora』，starttime=>to_date(』 2003-06-28 12:00:00』，』YYYY-MM-DD HH:MI:SS』)，endtime=>to_date(to_date(『2003-06-28 13:00:00』，』YYYY-MM-DD HH:MI:SS』));
6. 獲取分析結果：
svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;
7. 根據分析結果修復數據。
8.結束logmnr:
svrmgrl>dbms_logmnr.end_logmnr;
9. 用適當的方法對原資料庫進行資料庫全備份。
利用備份恢復用戶數據：
採用這種方法時並不是在原資料庫進行恢復，而是利用資料庫備份在新的機器上重新建立一個新的資料庫。通過備份恢復在新機器上將資料庫恢復到用戶誤操作前，這樣就可以獲得丟失的數據將其恢復到原資料庫。
1. 在新的機器上安裝資料庫軟體。
2. 對於採用帶庫備份的現場，需要在新的資料庫伺服器上安裝調試相應的備份管軟體。
3. 根據用戶誤操作的時間點進行基於時間點的資料庫恢復操作。對於沒有採用帶庫備份的現場，可以選取用戶誤操作前最近的備份磁帶進行恢復；對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復。
4.重新打開資料庫：
svrmgrl>alter database open resetlogs;
5. 從新的資料庫中獲取丟失的用戶數據，通過DML操作將其恢復到原資料庫中。
6. 用適當的方法對原資料庫進行資料庫全備份。
㈨ 經典資料庫問題！！！！！
問題1
select idCard,count(*) from carApplyDetail group by idCard having count(*)>1
問題2
對不起，沒想起來怎麼用一條語句更新兩個表，或者用兩條語句，或者在資料庫中寫一個觸發事件。
問題3
select applydate,count(*) as shul from cardapply group by applydate order by shul desc
唉，就這樣吧，第一條記錄就是那個最多的，
雖然記錄多了點
㈩ sql資料庫問題
首先，沒有看到你保存數據的代碼，不知道你保存的時候是否就是你列印的數組。
其次，如果保存的數據就是列印的數據，但是沒有保存上，那麼說明資料庫中的欄位應該是做了限制。
但是目前既沒有看到保存數據的代碼片段，也沒有看到資料庫中欄位的描述，比如什麼類型，長度等信息。
所以，目前只能猜測可能是沒有將數據保存，或者資料庫欄位設置有問題。