㈠ 資料庫中的「關系」是什麼意思怎麼理解
樓上的沒錯,不過這樣說你有點抽象.
你看下什麼叫關系資料庫就知道"關系"是什麼了
=================================================
在關系模型中，實體以及實體間的聯系都是用關系表示的。例如，系實體，學生實體，系與學生之間的一對多的聯系都可以分別用一個關系來表示。在一個給定的應用領域中，所有實體和實體之間聯系的關系模式集合構成一個關系資料庫的描述，稱作關系資料庫的內涵。
關系資料庫也有型和值之分，關系資料庫的型也稱為關系資料庫模式，是對關系資料庫的描述，包括若干域的定義以及在這些域上定義的若干關系模式。關系資料庫的值是這些關系模式在某一時刻對應的關系的集合，通常稱為關系資料庫稱關系資料庫的外涵。
㈡ 資料庫中「關系模式」的定義是什麼
關系的描述稱為關系模式（Relation
Schema）。一個關系模式應當是一個五元組。它可以形式化地表示為：R(U,
D,
DOM,
F)。其中R為關系名，U為組成該關系的屬性名集合，D為屬性組U中屬性所來自的域，DOM為屬性向域的映象集合，F為屬性間數據的依賴關系集合。
關系模式通常可以簡記為:R(A1,
A2,
…,
An)。其中R為關系名，A1,
A2,
…,
An為屬性名。而域名及屬性向域的映象常常直接說明為屬性的類型、長度。
關系實際上就是關系模式在某一時刻的狀態或內容。也就是說，關系模式是型，關系是它的值。關系模式是靜態的、穩定的，而關系是動態的、隨時間不斷變化的，因為關系操作在不斷地更新著資料庫中的數據。但在實際當中，常常把關系模式和關系統稱為關系，讀者可以從上下文中加以區別。
㈢ 資料庫中關系模式如何定義
資料庫中關系模型的一般定義可以理解：用二維表來描述現實世界中的事物以及事物之間聯系的數據模型。從數學角度，又可以簡單定義為R(U,F),其中R表示關系模型名，U表示該關系中的屬性，F表示屬性之間的依賴關系。
㈣ 如何定義資料庫表之間的關系
唯一需要注意的是，外鍵欄位的數據類型必須和主鍵的數據類型相同。但是有些系統可以允許這條規則有一個例外，它允許在數字和自動編號（autonumbering）欄位（例如在SQL伺服器系統中訪問Identity和AutoNumber）之間建立關系。此外，外鍵的值可以是空（Null），盡管強烈建議在沒有特別原因的情況下，不要讓外鍵為空。你有可能永遠都不會有機會來使用需要這項功能的資料庫。 現在回到我們的示例關系表，並開始輸入合適的外鍵。（請繼續在紙上打草稿——在你的資料庫系統中創建真正的數據表還為時過早。要知道在紙上糾正錯誤要容易得多。）要記住，你正在把主鍵的值添加到關系表裡。只要調用實體之間的關系就行了，而其他的就簡單了： 書籍和分類是有關系的。 書籍和出版社是有關系的。 書籍和作者是有關系的。 作者和郵政編碼（ZIP）是有關系的。 郵政編碼和城市是有關系的。 城市和州是有關系的。 這一步並不是一成不變的，你可能會發現在規范化的過程中加入外鍵會更容易一些。在把欄位移動到一個新的數據表時，你可能要把這個新數據表的主鍵添加到原來的數據表裡，將其作為外鍵。但是，在你繼續規范化剩餘數據的時候，外鍵常常會發生改變。你會發現在所有這些數據表被全部規范化之後，一次添加所有的外鍵，這樣效率會更高。 操作數據表 現在讓我們一次操作一個數據表，就從Books數據表開始，它在這個時候只有三個欄位。很明顯，Authors、Categories和Publishers數據表的主鍵會被添加到Books里。當你完成的時候，Books數據表就有了七個欄位： Books Title (PK) ISBN (PK) Price FirstNameFK (FK) Authors.FirstName many-to-many LastNameFK (FK) Authors.LastName many-to-many CategoryFK (FK) Categories.Category many-to-many PublisherFK (FK) Publishers.Publisher one-to-many 要記住，Authors數據表裡的主鍵是一個基於姓和名兩個欄位的復合關鍵字。所以你必須要把這個兩個欄位都添加到Books數據表裡。要注意，外鍵欄位名的結尾包含有FK這個後綴。加入這個後綴有助於提高可讀性和自我歸檔。通過名稱這種方式來區別外鍵會使得追蹤它們更簡單。如果主鍵和外鍵的名稱不同，這沒有關系。 這里出現了三種關系：Books和Authors、Books和Categories，以及Books和Publishers。這三種關系中所存在的兩種問題可能沒有那麼明顯： Books和Authors之間的關系：一本書可以有多個作者。 Books和Categories之間的關系：一本書可以被歸入多個類。 這兩者的關系是多對多的關系。先前我告訴過你，數據表不能直接實現這樣的關系，而需要第三個聯系表來實現。（Books和Publishers的關系是一對多的關系，就像現在所說的，這樣是沒有問題的。） 這兩個新發現的多對多關系將需要一個聯系表來包含來自每個數據表的主鍵，並將其作為外鍵。新的聯系表是：BooksAuthorsmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many FirstNameFK (FK) Authors.FirstName one-to-many LastNameFK (FK) Authors.LastName one-to-many BooksCategoriesmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many CategoryFK (FK) Categories.Category one-to-many 沒有必要更改Categories、Authors或者Publishers數據表。但是，你必須把FirstNameFK、LastNameFK和CategoryFK這三個外鍵從Books里移走： Books Title (PK) ISBN (PK) Price PublisherFK (FK) Publishers.Publisher one-to-many 現在，讓我們轉到Authors數據表上來，它現在有兩個欄位。每個作者都和ZIPCodes數據表中的郵政編碼的值相關。但是，每個郵政編碼會和多個作者相關。要實現這種一對多的關系，就要把ZIPCodes數據表中的主鍵添加進Authors數據表作為外鍵： Authors FirstName (PK) LastName (PK) ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many 至此，你已經准備好了處理剩下的地址部分了。看到它們被分在不同的數據表裡是很讓人奇怪的，但是這是遵照BCNF正確規范化數據的結果。每個郵政編碼的值只會有一個對應的城市值和州值。每個城市和州的值只會被輸入進其對應的數據表裡一次。ZIPCodes和Cities數據表需要外鍵欄位來實現這些關系： ZIPCodes ZIPCode (PK) CityFK (FK) Cities.City one-to-many Cities City (PK) StateFK (FK) States.State one-to-many States State (PK) 從一個到九個 最後，你有了九個數據表：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。圖A是這個示例數據表的資料庫最終的圖形形式。很難想像一個簡單的數據表會被分成九個數據表。 圖A 最初的一個數據表現在需要九個數據表了 由於這個示例資料庫很簡單，你可能會問這些關系有什麼作用。看起來仍在保存冗餘的數據，只不過形式不同罷了——通過外鍵來實現。這是因為我們的數據表現在只有很少幾個欄位。試想一下有十幾個欄位的數據表，會是什麼樣的一個情形。需要承認的是，你仍然需要把數據表的主鍵作為外鍵保存進關系表裡，但是至多可能最多增加一到兩個欄位。比較一下為這個數據表裡的每一條記錄都添加十幾個條目的情形吧。
㈤ 如何定義資料庫表之間的關系
唯一需要注意的是，外鍵欄位的數據類型必須和主鍵的數據類型相同。但是有些系統可以允許這條規則有一個例外，它允許在數字和自動編號（autonumbering）欄位（例如在SQL伺服器系統中訪問Identity和AutoNumber）之間建立關系。此外，外鍵的值可以是空（Null），盡管強烈建議在沒有特別原因的情況下，不要讓外鍵為空。你有可能永遠都不會有機會來使用需要這項功能的資料庫。 現在回到我們的示例關系表，並開始輸入合適的外鍵。（請繼續在紙上打草稿——在你的資料庫系統中創建真正的數據表還為時過早。要知道在紙上糾正錯誤要容易得多。）要記住，你正在把主鍵的值添加到關系表裡。只要調用實體之間的關系就行了，而其他的就簡單了： 書籍和分類是有關系的。 書籍和出版社是有關系的。 書籍和作者是有關系的。 作者和郵政編碼（ZIP）是有關系的。 郵政編碼和城市是有關系的。 城市和州是有關系的。 這一步並不是一成不變的，你可能會發現在規范化的過程中加入外鍵會更容易一些。在把欄位移動到一個新的數據表時，你可能要把這個新數據表的主鍵添加到原來的數據表裡，將其作為外鍵。但是，在你繼續規范化剩餘數據的時候，外鍵常常會發生改變。你會發現在所有這些數據表被全部規范化之後，一次添加所有的外鍵，這樣效率會更高。 操作數據表 現在讓我們一次操作一個數據表，就從Books數據表開始，它在這個時候只有三個欄位。很明顯，Authors、Categories和Publishers數據表的主鍵會被添加到Books里。當你完成的時候，Books數據表就有了七個欄位： Books Title (PK) ISBN (PK) Price FirstNameFK (FK) Authors.FirstName many-to-many LastNameFK (FK) Authors.LastName many-to-many CategoryFK (FK) Categories.Category many-to-many PublisherFK (FK) Publishers.Publisher one-to-many 要記住，Authors數據表裡的主鍵是一個基於姓和名兩個欄位的復合關鍵字。所以你必須要把這個兩個欄位都添加到Books數據表裡。要注意，外鍵欄位名的結尾包含有FK這個後綴。加入這個後綴有助於提高可讀性和自我歸檔。通過名稱這種方式來區別外鍵會使得追蹤它們更簡單。如果主鍵和外鍵的名稱不同，這沒有關系。 這里出現了三種關系：Books和Authors、Books和Categories，以及Books和Publishers。這三種關系中所存在的兩種問題可能沒有那麼明顯： Books和Authors之間的關系：一本書可以有多個作者。 Books和Categories之間的關系：一本書可以被歸入多個類。 這兩者的關系是多對多的關系。先前我告訴過你，數據表不能直接實現這樣的關系，而需要第三個聯系表來實現。（Books和Publishers的關系是一對多的關系，就像現在所說的，這樣是沒有問題的。） 這兩個新發現的多對多關系將需要一個聯系表來包含來自每個數據表的主鍵，並將其作為外鍵。新的聯系表是：BooksAuthorsmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many FirstNameFK (FK) Authors.FirstName one-to-many LastNameFK (FK) Authors.LastName one-to-many BooksCategoriesmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many CategoryFK (FK) Categories.Category one-to-many 沒有必要更改Categories、Authors或者Publishers數據表。但是，你必須把FirstNameFK、LastNameFK和CategoryFK這三個外鍵從Books里移走： Books Title (PK) ISBN (PK) Price PublisherFK (FK) Publishers.Publisher one-to-many 現在，讓我們轉到Authors數據表上來，它現在有兩個欄位。每個作者都和ZIPCodes數據表中的郵政編碼的值相關。但是，每個郵政編碼會和多個作者相關。要實現這種一對多的關系，就要把ZIPCodes數據表中的主鍵添加進Authors數據表作為外鍵： Authors FirstName (PK) LastName (PK) ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many 至此，你已經准備好了處理剩下的地址部分了。看到它們被分在不同的數據表裡是很讓人奇怪的，但是這是遵照BCNF正確規范化數據的結果。每個郵政編碼的值只會有一個對應的城市值和州值。每個城市和州的值只會被輸入進其對應的數據表裡一次。ZIPCodes和Cities數據表需要外鍵欄位來實現這些關系： ZIPCodes ZIPCode (PK) CityFK (FK) Cities.City one-to-many Cities City (PK) StateFK (FK) States.State one-to-many States State (PK) 從一個到九個 最後，你有了九個數據表：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。圖A是這個示例數據表的資料庫最終的圖形形式。很難想像一個簡單的數據表會被分成九個數據表。 圖A 最初的一個數據表現在需要九個數據表了 由於這個示例資料庫很簡單，你可能會問這些關系有什麼作用。看起來仍在保存冗餘的數據，只不過形式不同罷了——通過外鍵來實現。這是因為我們的數據表現在只有很少幾個欄位。試想一下有十幾個欄位的數據表，會是什麼樣的一個情形。需要承認的是，你仍然需要把數據表的主鍵作為外鍵保存進關系表裡，但是至多可能最多增加一到兩個欄位。比較一下為這個數據表裡的每一條記錄都添加十幾個條目的情形吧。
㈥ 關系資料庫中的關系是什麼意思
關系型資料庫實際上是基於關系模型的資料庫,也就是你所問到的關系是什麼意思.
因為關系實際上是一張二維表,表的每一行是一個元素,每一列是一項屬性,而一個元組就是該關系所涉及的屬性集的笛卡爾積的一個元素.
一個關系模式應當是一個5元組.定義關系的描述稱為關系模式）.它可以形式化地表示為：R（U,D,dom,F） 其中R為關系名,U為組成該關系的屬性名集合,D為屬性組U中屬性所來自的域,dom為屬性向域的映象集合,F為屬性間數據的依賴關系集合.
㈦ 資料庫中「關系模式」的定義是什麼
關系模式是指關系的描述
關系模式僅涉及關系名、各屬性名、域名、屬性向域的映象四部分。
它可以形式化地表示為：R、U、D、DOM、 F。其中R為關系名，U為組成該關系的屬性名集合，D為屬性組U中屬性所來自的域，DOM為屬性向域的映象集合，F為屬性間數據的依賴關系集合。
現實世界隨著時間在不斷地變化，因而在不同的時刻，關系模式的關系也會有所變化。但是，現實世界的許多己有事實限定了關系模式所有可能的關系必須滿足一定的完整性約束條件。這些約束或者通過對屬性取值范圍的限定。
(7)資料庫關系的數字定義擴展閱讀：
資料庫中，關系模式是型，關系是值，關系模式是對關系的描述。
1、關系實質上是一張二維表，表的每一行為一個元組，每一列為一個屬性。一個元組就是該關系所涉及的屬性集的笛卡爾積的一個元素。關系是元組的集合，
因此關系模式必須指出這個元組集合的結構，即它由哪些屬性構成，這些屬性來自哪些域，以及屬性與域之間的映象關系。
2、一個關系通常是由賦予它的元組語義來確定的。
元組語義實質上是一個n目謂詞（n是屬性集中屬性的個數，凡使該n目謂詞為真的笛卡爾積中的元素（或者說凡符合元組語義的那部分元素）的全體就構成了該關系模式的關系。
㈧ 關系資料庫中資料庫,表,欄位及元組的概念及相互之間的關系
一、概念
（1）關系資料庫的表採用二維表格來存儲數據，是一種按行與列排列的具有相關信息的邏輯組，它類似於Excle工作表。一個資料庫可以包含任意多個數據表。
（2）關系資料庫：在一個給定的應用領域中，所有實體及實體之間聯系的集合構成一個關系資料庫。它是一種以關系模式為基礎存儲數據以及用數字方法處理資料庫組織的方法，是目前最為流行的一種數據組織形式。
（3）元組（記錄）。表中的一行即為一個元組，或稱為一條記錄。
（4）欄位，數據表中的每一列稱為一個欄位，表是由其包含的各種欄位定義的，每個欄位描述了它所含有的數據的意義，數據表的設計實際上就是對欄位的設計。創建數據表時，為每個欄位分配一個數據類型，定義它們的數據長度和其他屬性。欄位可以包含各種字元、數字、甚至圖形。
二、關系
一個資料庫可以包含若干張表；一張表有若干個欄位；每張表又有若干條記錄（元組），每條記錄（元組）對應每個欄位都有一個值。
(8)資料庫關系的數字定義擴展閱讀
關系資料庫，是建立在關系資料庫模型基礎上的資料庫，藉助於集合代數等概念和方法來處理資料庫中的數據。
同時也是一個被組織成一組擁有正式描述性的表格，該形式的表格作用的實質是裝載著數據項的特殊收集體，這些表格中的數據能以許多不同的方式被存取或重新召集而不需要重新組織資料庫表格。
關系資料庫的定義造成元數據的一張表格或造成表格、列、范圍和約束的正式描述。每個表格（有時被稱為一個關系）包含用列表示的一個或更多的數據種類。 每行包含一個唯一的數據實體，這些數據是被列定義的種類。
㈨ 關系資料庫中的關系是什麼意思
關系資料庫種的關系主要是指創建在關系模型基礎上的資料庫，藉助於集合代數等數學概念和方法來處理資料庫中的數據。
關系模型由關系數據結構、關系操作集合、關系完整性約束三部分組成。現實世界中的各種實體以及實體之間的各種聯系均用關系模型來表示。
關系模型是由埃德加·科德於1970年首先提出的，並配合「科德十二定律」。現如今雖然對此模型有一些批評意見，但它還是數據存儲的傳統標准。
標准數據查詢語言SQL就是一種基於關系資料庫的語言，這種語言執行對關系資料庫中數據的檢索和操作。
(9)資料庫關系的數字定義擴展閱讀：
1．資料庫
關系資料庫可按其數據存儲方式以及用戶訪問的方式而分為本地資料庫和遠程資料庫兩種類型。
(1)本地資料庫：本地資料庫駐留在本機驅動器或區域網中，如果多個用戶並發訪問資料庫，則採取基於文件的鎖定(防止沖突)策略，因此，本地資料庫又稱為基於文件的資料庫。
典型的本地資料庫有Paradox、dBASE、FoxPro以及Access等。基於本地資料庫的應用程序稱為單層應用程序，因為資料庫和應用程序同處於一個文件系統中。
(2)遠程資料庫：遠程資料庫通常駐留於其他機器中，用戶通過結構化查詢語言SQL來訪問遠程資料庫中的數據，因此，遠程資料庫又稱為SQL伺服器。
有時，來自於遠程資料庫的數據並不駐留於一個機器而是分布在不同的伺服器上。典型的SQL伺服器有InterBase、Oracle、Sybase、Informix、MicrosoftSQLServer，以及IBMDB2等。
基於SQL伺服器的應用程序稱為兩層或多層應用程序，因為資料庫和應用程序駐留在彼此不依賴的系統(層)中。
本地資料庫與SQL伺服器相比較，前者訪問速度快，但後者的數據存儲容量要大得多，且適合多個用戶並發訪問。
究竟使用本地資料庫還是SQL伺服器，取決於多方面因素，如要存儲和處理的數據多少，並發訪問資料庫的用戶個數，對資料庫的性能要求等。
2．表
關系資料庫的基本成分是一些存放數據的表(關系理論中稱為「關系」)。資料庫中的表從邏輯結構上看相當簡單，它是由若干行和列簡單交叉形成的，不能表中套表。
它要求表中每個單元都只包含一個數據，可以是字元串、數字、貨幣值、邏輯值、時問等較為簡單的數據。一般資料庫中無法存儲c++語言中的結構類型、類對象。圖像的存儲也比較煩瑣，很多資料庫無法實現圖像存儲。
3．視圖
為了方便地使用資料庫，很多DBMS都提供對於視圖(Access中稱為查詢)結構的支持。視圖是根據某種條件從一個或多個基表(實際存放數據的表)或其他視圖中導出的表，資料庫中只存放其定義，而數據仍存放在作為數據源的基表中。故當基表中數據有所變化時，視圖中看到的數據也隨之變化。