首先通過運行資料庫客戶端管理軟體SQLyogEnt進行查詢，第一步運行SQLyogEnt，在桌面找到SQLyogEnt的軟體圖標，用戶雙擊這個圖標。
Ⅱ ASP查詢資料庫日期中的年份該怎麼查尋
兩種比較簡單的方法可以實現
例如: datestr 是你從資料庫里查出來的日期
第一種方法: response.write(year(datestr)) ,這樣輸出的就是日期中的年份
第二種方法: 換個思路去考慮,有意義的年份都應該是四位數的,所以可以用截取字元串的方式去完成, response.write(left(datestr,4)) ,這樣也成
希望可以幫助到你
Ⅲ SQL數據表只有年齡怎麼查詢出生年份
SQL數據表只有年齡可以使用資料庫里的日期處理函數，倒推出生年份。年齡指的是，從出生年月到現在經過了多少年。也就是說，從現在往前推年齡的年數，就得到了出生年份。比如，你現在20歲，可以用如下SQL得出出生的年月：SELECT DATEADD(year, -20, GETDATE)。
年齡：
年齡，指一個人從出生時起到計算時止生存的時間長度，通常用年歲來表示。年齡是一種具有生物學基礎的自然標志，一個人出生以後，隨著日月流逝，年齡也隨之增長，這是不可抗拒的自然規律。人在進行自身再生產的同時，也進行著年齡的再生產，它總是由不同年代出生的不同年齡的個人所組成。都與每個人的年齡密切相關。所以，正確計算年齡具有十分重要的意義。
Ⅳ 資料庫的發展簡史
使用計算機後，隨著數據處理量的增長，產生了數據管理技術。
數據管理技術的發展與計算機硬體（主要是外部存儲器）系統軟體及計算機應用的范圍有著密切的聯系。
數據管理技術的發展經歷了以下四個階段：人工管理階段、文件系統階段、資料庫階段和高級資料庫技術階段。
數據管理的誕生
資料庫的歷史可以追溯到五十年前，那時的數據管理非常簡單。
通過大量的分類、比較和表格繪制的機器運行數百萬穿孔卡片來進行數據的處理，其運行結果在紙上列印出來或者製成新的穿孔卡片。
而數據管理就是對所有這些穿孔卡片進行物理的儲存和處理。
然而，1950 年雷明頓蘭德公司（Remington Rand Inc）的一種叫做Univac I 的計算機推出了一種一秒鍾可以輸入數百條記錄的磁帶驅動器，從而引發了數據管理的革命。
1956 年IBM生產出第一個磁碟驅動器—— the Model 305 RAMAC。
此驅動器有50 個碟片，每個碟片直徑是2 英尺，可以儲存5MB的數據。
使用磁碟最大的好處是可以隨機存取數據，而穿孔卡片和磁帶只能順序存取數據。
1951： Univac系統使用磁帶和穿孔卡片作為數據存儲。
資料庫系統的萌芽出現於二十世紀60 年代。
當時計算機開始廣泛地應用於數據管理，對數據的共享提出了越來越高的要求。
傳統的文件系統已經不能滿足人們的需要，能夠統一管理和共享數據的資料庫管理系統（DBMS）應運而生。
數據模型是資料庫系統的核心和基礎，各種DBMS軟體都是基於某種數據模型的。
所以通常也按照數據模型的特點將傳統資料庫系統分成網狀資料庫、層次資料庫和關系資料庫三類。
最早出現的網狀DBMS，是美國通用電氣公司Bachman等人在1961年開發的IDS（Integrated Data Store）。
1964年通用電氣公司（General ElectricCo.）的Charles Bachman 成功地開發出世界上第一個網狀DBMS也即第一個資料庫管理系統——集成數據存儲（Integrated Data Store IDS），奠定了網狀資料庫的基礎，並在當時得到了廣泛的發行和應用。
IDS 具有數據模式和日誌的特徵，但它只能在GE主機上運行，並且資料庫只有一個文件，資料庫所有的表必須通過手工編碼生成。
之後，通用電氣公司一個客戶——BF Goodrich Chemical 公司最終不得不重寫了整個系統，並將重寫後的系統命名為集成數據管理系統（IDMS）。
網狀資料庫模型對於層次和非層次結構的事物都能比較自然的模擬，在關系資料庫出現之前網狀DBMS要比層次DBMS用得普遍。
在資料庫發展史上，網狀資料庫佔有重要地位。
層次型DBMS是緊隨網路型資料庫而出現的，最著名最典型的層次資料庫系統是IBM 公司在1968 年開發的IMS（Information Management System），一種適合其主機的層次資料庫。
這是IBM公司研製的最早的大型資料庫系統程序產品。
從60年代末產生起，如今已經發展到IMSV6，提供群集、N路數據共享、消息隊列共享等先進特性的支持。
這個具有30年歷史的資料庫產品在如今的WWW應用連接、商務智能應用中扮演著新的角色。
1973年Cullinane公司（也就是後來的Culli軟體公司），開始出售Goodrich公司的IDMS改進版本，並且逐漸成為當時世界上最大的軟體公司。
網狀資料庫和層次資料庫已經很好地解決了數據的集中和共享問題，但是在數據獨立性和抽象級別上仍有很大欠缺。
用戶在對這兩種資料庫進行存取時，仍然需要明確數據的存儲結構，指出存取路徑。
而後來出現的關系資料庫較好地解決了這些問題。
1970年，IBM的研究員E.F.Codd博士在刊物《munication of the ACM》上發表了一篇名為「A Relational Model of Data for Large Shared Data Banks」的論文，提出了關系模型的概念，奠定了關系模型的理論基礎。
盡管之前在1968年Childs已經提出了面向 *** 的模型，然而這篇論文被普遍認為是資料庫系統歷史上具有劃時代意義的里程碑。
Codd的心願是為資料庫建立一個優美的數據模型。
後來Codd又陸續發表多篇文章，論述了範式理論和衡量關系系統的12條標准，用數學理論奠定了關系資料庫的基礎。
關系模型有嚴格的數學基礎，抽象級別比較高，而且簡單清晰，便於理解和使用。
但是當時也有人認為關系模型是理想化的數據模型，用來實現DBMS是不現實的，尤其擔心關系資料庫的性能難以接受，更有人視其為當時正在進行中的網狀資料庫規范化工作的嚴重威脅。
為了促進對問題的理解，1974年ACM牽頭組織了一次研討會，會上開展了一場分別以Codd和Bachman為首的支持和反對關系資料庫兩派之間的辯論。
這次著名的辯論推動了關系資料庫的發展，使其最終成為現代資料庫產品的主流。
1969年Edgar F.「Ted」 Codd發明了關系資料庫。
1970年關系模型建立之後，IBM公司在San Jose實驗室增加了更多的研究人員研究這個項目，這個項目就是著名的System R。
其目標是論證一個全功能關系DBMS的可行性。
該項目結束於1979年，完成了第一個實現SQL的 DBMS。
然而IBM對IMS的承諾阻止了System R的投產，一直到1980年System R才作為一個產品正式推向市場。
IBM產品化步伐緩慢的三個原因：IBM重視信譽，重視質量，盡量減少故障；IBM是個大公司，官僚體系龐大，IBM內部已經有層次資料庫產品，相關人員不積極，甚至反對。
然而同時，1973年加州大學伯克利分校的Michael Stonebraker和Eugene Wong利用System R已發布的信息開始開發自己的關系資料庫系統Ingres。
他們開發的Ingres項目最後由Oracle公司、Ingres公司以及矽谷的其他廠商所商品化。
後來，System R和Ingres系統雙雙獲得ACM的1988年「軟體系統獎」。
1976年霍尼韋爾公司(Honeywell)開發了第一個商用關系資料庫系統——Multics Relational Data Store。
關系型資料庫系統以關系代數為堅實的理論基礎，經過幾十年的發展和實際應用，技術越來越成熟和完善。
其代表產品有Oracle、IBM公司的 DB2、微軟公司的MS SQL Server以及Informix、ADABAS D等等。
1974年IBM的Ray Boyce和Don Chamberlin將Codd關系資料庫的12條准則的數學定義以簡單的關鍵字語法表現出來，里程碑式地提出了SQL(Structured Query Language)語言。
SQL語言的功能包括查詢、操縱、定義和控制，是一個綜合的、通用的關系資料庫語言，同時又是一種高度非過程化的語言，只要求用戶指出做什麼而不需要指出怎麼做。
SQL集成實現了資料庫生命周期中的全部操作。
SQL提供了與關系資料庫進行交互的方法，它可以與標準的編程語言一起工作。
自產生之日起，SQL語言便成了檢驗關系資料庫的試金石，而SQL語言標準的每一次變更都指導著關系資料庫產品的發展方向。
然而，直到二十世紀七十年代中期，關系理論才通過SQL在商業資料庫Oracle和DB2中使用。
1986年，ANSI把SQL作為關系資料庫語言的美國標准，同年公布了標准SQL文本。
SQL標准有3個版本。
基本SQL定義是ANSⅨ3135-89，「Database Language - SQL with Integrity Enhancement」[ANS89]，一般叫做SQL-89。
SQL-89定義了模式定義、數據操作和事務處理。
SQL- 89和隨後的ANSⅨ3168-1989，「Database Language-Embedded SQL」構成了第一代SQL標准。
ANSⅨ3135-1992[ANS92]描述了一種增強功能的SQL，叫做SQL-92標准。
SQL-92包括模式操作，動態創建和SQL語句動態執行、網路環境支持等增強特性。
在完成SQL-92標准後，ANSI和ISO即開始合作開發SQL3標准。
SQL3的主要特點在於抽象數據類型的支持，為新一代對象關系資料庫提供了標准。
1976年IBM E.F.Codd發表了一篇里程碑的論文「R系統：資料庫關系理論」，介紹了關系資料庫理論和查詢語言SQL。
Oracle的創始人Ellison非常仔細地閱讀了這篇文章，被其內容震驚，這是第一次有人用全面一致的方案管理數據信息。
作者E.F.Codd 1966年就發表了關系資料庫理論，並在IBM研究機構開發原型，這個項目就是R系統，存取數據表的語言就是SQL。
Ellison看完後，敏銳意識到在這個研究基礎上可以開發商用軟體系統。
而當時大多數人認為關系資料庫不會有商業價值。
Ellison認為這是他們的機會：他們決定開發通用商用資料庫系統Oracle，這個名字來源於他們曾給中央情報局做過的項目名。
幾個月後，他們就開發了Oracle 1.0。
但這只不過是個玩具，除了完成簡單關系查詢不能做任何事情，他們花相當長的時間才使Oracle變得可用，維持公司運轉主要靠承接一些資料庫管理項目和做顧問咨詢工作。
而IBM卻沒有計劃開發，為什麼藍色巨人放棄了這個價值上百億的產品，原因有很多：IBM的研究人員大多是學術出身，他們最感興趣的是理論，而非推向市場的產品，從學術上看，研究成果應公開發表論文和演講能使他們成名，為什麼不呢？還有一個很主要的原因就是IBM當時有一個銷售得還不錯的層次資料庫產品IMS。
直到1985年IBM才發布了關系資料庫DB2 ，Ellision那時已經成了千萬富翁。
Ellison曾將IBM 選擇Microsoft 的MS-DOS作為IBM-PC機的操作系統比為：「世界企業經營歷史上最嚴重的錯誤，價值超過了上千億美元。」IBM發表R系統論文，而且沒有很快推出關系資料庫產品的錯誤可能僅僅次之。
Oracle的市值在1996年就達到了280億美元。
隨著信息技術和市場的發展，人們發現關系型資料庫系統雖然技術很成熟，但其局限性也是顯而易見的：它能很好地處理所謂的「表格型數據」，卻對技術界出現的越來越多的復雜類型的數據無能為力。
九十年代以後，技術界一直在研究和尋求新型資料庫系統。
但在什麼是新型資料庫系統的發展方向的問題上，產業界一度是相當困惑的。
受當時技術風潮的影響，在相當一段時間內，人們把大量的精力花在研究「面向對象的資料庫系統(object oriented database)」或簡稱「OO資料庫系統」。
值得一提的是，美國Stonebraker教授提出的面向對象的關系型資料庫理論曾一度受到產業界的青睞。
而Stonebraker本人也在當時被Informix花大價錢聘為技術總負責人。
然而，數年的發展表明，面向對象的關系型資料庫系統產品的市場發展的情況並不理想。
理論上的完美性並沒有帶來市場的熱烈反應。
其不成功的主要原因在於，這種資料庫產品的主要設計思想是企圖用新型資料庫系統來取代現有的資料庫系統。
這對許多已經運用資料庫系統多年並積累了大量工作數據的客戶，尤其是大客戶來說，是無法承受新舊數據間的轉換而帶來的巨大工作量及巨額開支的。
另外，面向對象的關系型資料庫系統使查詢語言變得極其復雜，從而使得無論是資料庫的開發商家還是應用客戶都視其復雜的應用技術為畏途。
二十世紀六十年代後期出現了一種新型資料庫軟體：決策支持系統(DSS)，其目的是讓管理者在決策過程中更有效地利用數據信息。
於是在1970年，第一個聯機分析處理工具——Express誕生了。
其他決策支持系統緊隨其後，許多是由公司的IT部門開發出來的。
1985年，第一個商務智能系統(business intelligence)由Metaphor計算機系統有限公司為Procter & Gamble公司開發出來，主要是用來連接銷售信息和零售的掃描儀數據。
同年， Pilot軟體公司開始出售第一個商用客戶/伺服器執行信息系統——mand Center。
同樣在這年，加州大學伯克利分校Ingres項目演變成Postgres，其目標是開發出一個面向對象的資料庫。
此後一年， Graphael公司開發了第一個商用的對象資料庫系統—Gbase。
1988年，IBM公司的研究者Barry Devlin和Paul Murphy發明了一個新的術語—信息倉庫，之後，IT的廠商開始構建實驗性的數據倉庫。
1991年，W.H. Bill Inmon出版了一本「如何構建數據倉庫」的書，使得數據倉庫真正開始應用。
1991： W.H.「Bill」 Inmon發表了」構建數據倉庫」
二十世紀九十年代，隨著基於PC的客戶/伺服器計算模式和企業軟體包的廣泛採用，數據管理的變革基本完成。
數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。
Inter的異軍突起以及XML語言的出現，給資料庫系統的發展開辟了一片新的天地。
Ⅳ 請問下查60、70年代的中文文獻，用什麼資料庫合適
這種比較老的文獻主要是去圖書館或者博物館查，雖然也可以用資料庫，比如cnki，但只能查到很少的一部分。