講關係數據庫的結構的計算機英語
計算機的英語是牽扯到很多專業的術語，所以學習起來有點困難，小編今天就給大家整理了有關於計算機的英語，有時間可以多多參考一下
Structure of the Relational database
The relational model is the basis for any relational database management system (RDBMS).A relational model has three core components: a collection of objects or relations, operators that act on the objects or relations, and data integrity methods. In other words, it has a place to store the data, a way to create and retrieve the data, and a way to make sure that the data is logically consistent.
A relational database uses relations, or two-dimensional tables, to store the information needed to support a business. Let's go over the basic components of a traditional relational database system and look at how a relational database is designed. Once you have a solid understanding of what rows, columns, tables, and relationships are, you'll be well on your way to leveraging the power of a relational database.
Tables, Row, and Columns
A table in a relational database, alternatively known as a relation, is a two-dimensional structure used to hold related information. A database consists of one or more related tables.
Note: Don't confuse a relation with relationships. A relation is essentially a table, and a relationship is a way to correlate, join, or associate two tables.
A row in a table is a collection or instance of one thing, such as one employee or one line item on an invoice. A column contains all the information of a single type, and the piece of data at the intersection of a row and a column, a field, is the smallest piece of information that can be retrieved with the database's query language. For example, a table with information about employees might have a column called LAST_NAME that contains all of the employees' last names. Data is retrieved from a table by filtering on both the row and the column.
Primary Keys, Datatypes, and Foreign Keys
The examples throughout this article will focus on the hypothetical work of Scott Smith, database developer and entrepreneur. He just started a new widget company and wants to implement a few of the basic business functions using the relational database to manage his Human Resources (HR) department.
Relation: A two-dimensional structure used to hold related information, also known as a table.
Note: Most of Scott's employees were hired away from one of his previous employers, some of whom have over 20 years of experience in the field. As a hiring incentive, Scott has agreed to keep the new employees' original hire date in the new database.
Row:A group of one or more data elements in a database table that describes a person, place, or thing.
Column:The component of a database table that contains all of the data of the same name and type across all rows.
You'll learn about database design in the following sections, but let's assume for the moment that the majority of the database design is completed and some tables need to be implemented. Scott creates the EMP table to hold the basic employee information, and it looks something like this:
Notice that some fields in the Commission (COMM) and Manager (MGR) columns do not contain a value; they are blank. A relational database can enforce the rule that fields in a column may or may not be empty. In this case, it makes sense for an employee who is not in the Sales department to have a blank Commission field. It also makes sense for the president of the company to have a blank Manager field, since that employee doesn't report to anyone.
Field:The smallest piece of information that can be retrieved by the database query language. A field is found at the intersection of a row and a column in a database table.
On the other hand, none of the fields in the Employee Number (EMPNO) column are blank. The company always wants to assign an employee number to an employee, and that number must be different for each employee. One of the features of a relational database is that it can ensure that a value is entered into this column and that it is unique. The EMPNO column, in this case, is the primary key of the table.
Primary Key:A column (or columns) in a table that makes the row in the table distinguishable from every other row in the same table.
Notice the different datatypes that are stored in the EMP table: numeric values, character or alphabetic values, and date values.
As you might suspect, the DEPTNO column contains the department number for the employee. But how do you know what department name is associated with what number? Scott created the DEPT table to hold the descriptions for the department codes in the EMP table.
The DEPTNO column in the EMP table contains the same values as the DEPTNO column in the DEPT table. In this case, the DEPTNO column in the EMP table is considered a foreign key to the same column in the DEPT table.
A foreign key enforces the concept of referential integrity in a relational database. The concept of referential integrity not only prevents an invalid department number from being inserted into the EMP table, but it also prevents a row in the DEPT table from being deleted if there are employees still assigned to that department.
Foreign Key:A column (or columns) in a table that draws its values from a primary or unique key column in another table. A foreign key assists in ensuring the data integrity of a table. Referential IntegrityA method employed by a relational database system that enforces one-to-many relationships between tables.
Data Modeling
Before Scott created the actual tables in the database, he went through a design process known as data modeling. In this process, the developer conceptualizes and documents all the tables for the database. One of the common methods for modeling a database is called ERA, which stands for entities, relationships, and attributes. The database designer uses an application that can maintain entities, their attributes, and their relationships. In general, an entity corresponds to a table in the database, and the attributes of the entity correspond to columns of the table.
Data Modeling:A process of defining the entities, attributes, and relationships between the entities in preparation for creating the physical database.
The data-modeling process involves defining the entities, defining the relationships between those entities, and then defining the attributes for each of the entities. Once a cycle is complete, it is repeated as many times as necessary to ensure that the designer is capturing what is important enough to go into the database. Let's take a closer look at each step in the data-modeling process.
Defining the Entities
First, the designer identifies all of the entities within the scope of the database entities are the persons, places, or things that are important to the organization and need to be tracked in the database. Entities will most likely translate neatly to database tables. For example, for the first version of Scott's widget company database, he identifies four entities: employees, departments, salary grades, and bonuses. These will become the EMP, DEPT, SALGRADE, and BONUS tables.
Defining the Relationships Between Entities
Once the entities are defined, the designer can proceed with defining how each of the entities is related. Often, the designer will pair each entity with every other entity and ask, "Is there a relationship between these two entities?" Some relationships are obvious; some are not.
In the widget company database, there is most likely a relationship between EMP and DEPT, but depending on the business rules, it is unlikely that the DEPT and SALGRADE entities are related. If the business rules were to restrict certain salary grades to certain departments, there would most likely be a new entity that defines the relationship between salary grades and departments. This entity would be known as an associative or intersection table and would contain the valid combinations of salary grades and departments.
Associative Table:A database table that stores the valid combinations of rows from two other tables and usually enforces a business rule. An associative table resolves a many-to-many relationship.
In general, there are three types of relationships in a relational database:
One-to-many The most common type of relationship is one-to-many. This means that for each occurrence in a given entity, the parent entity, there may be one or more occurrences in a second entity, the child entity, to which it is related. For example, in the widget company database, the DEPT entity is a parent entity, and for each department, there could be one or more employees associated with that department. The relationship between DEPT and EMP is one-to-many.
One-to-one In a one-to-one relationship, a row in a table is related to only one or none of the rows in a second table. This relationship type is often used for subtyping. For example, an EMPLOYEE table may hold the information common to all employees, while the FULLTIME, PARTTIME, and CONTRACTOR tables hold information unique to full-time employees, part-time employees, and contractors, respectively. These entities would be considered subtypes of an EMPLOYEE and maintain a one-to-one relationship with the EMPLOYEE table. These relationships are not as common as one-to-many relationships, because if one entity has an occurrence for a corresponding row in another entity, in most cases, the attributes from both entities should be in a single entity.
Many-to-many In a many-to-many relationship, one row of a table may be related to many rows of another table, and vice versa. Usually, when this relationship is implemented in the database, a third entity is defined as an intersection table to contain the associations between the two entities in the relationship. For example, in a database used for school class enrollment, the STUDENT table has a many-to-many relationship with the CLASS table—one student may take one or more classes, and a given class may have one or more students. The intersection table STUDENT_CLASS would contain the combinations of STUDENT and CLASS to track which students are in which classes.
Assigning Attributes to Entities
Once the designer has defined the entity relationships, the next step is to assign the attributes to each entity. This is physically implemented using columns, as shown here for the SALGRADE table as derived from the salary grade entity.
After the entities, relationships, and attributes have been defined, the designer may iterate the data modeling many more times. When reviewing relationships, new entities may be discovered. For example, when discussing the widget inventory table and its relationship to a customer order, the need for a shipping restrictions table may arise.
Once the design process is complete, the physical database tables may be created. Logical database design sessions should not involve physical implementation issues, but once the design has gone through an iteration or two, it's the DBA's job to bring the designers "down to earth." As a result, the design may need to be revisited to balance the ideal database implementation versus the realities of budgets and schedules.
關係數據庫的結構
關係模型是任何關係數據庫管理系統(RDBMS)的基礎。一個關係模型有二個核心組件：對象或關係的集合，作用於對象或關係上的操作，以及數據完整性規則。換句話說，關係數據庫有一個存儲數據的地方，一種創建和檢索數據的方法，以及一種確認數據的邏輯一致性的方法。
一個關係數據庫使用關係或二維表來存儲支持某個事物所需的信息。讓我們瞭解一下一個傳統的關係數據庫系統的基本組件並目學習如何設計一個關係數據庫。一旦你對於行、列、表和關聯是什麼有了深刻理解，你就能夠充分發揮關係數據庫的強大功能。
表，行和列
在關係數據庫中，一個表(或者說一個關係)是一個用於保存相關信息的二維結構。一個數據庫由一個或者多個相關聯的表組成。
注意：不要混淆了關係和關聯。一個關係實際上是一個表，而一個關聯指的是一種連接、結合或聯合兩個表的方式。
表中的一行是一種事物的集合或實例，比如一個員工或發票上的一項。表中的一列包含了一類信息;而且行列交叉點上的數據，字段，即是能夠用數據庫查詢語言檢索到的最小片信息。舉個例子來說，一個員工信息表可能有一個“名字”列，列中就包含所有員工的名字。數據是通過對行、列進行過濾而從表中檢索出來的。
主碼、數據類型和外碼
本篇文章均以假設的斯科特·史密斯的工廠爲例，他是數據庫的建立者和企業的主辦人。他剛開辦了一個飾品公司並目想要使用關係數據庫的幾項基本功能來管理人力資源部門。
關係：用來保存相關信息的一個二維結構(也就是表)。
注意：大多數斯科特的僱員都是僱自過去的從業者，他們中有些人在這個領域己經有20年的經驗了。出於僱用的目的，斯科特同意在新數據庫中維持新進員工最初的僱傭日期。
行：在一個數據庫表中的一組單數據或多數據元素，用於描述一個人、地方或事物。
列：列是數據庫表的組件，它包含所有行中同名和同類型的所有數據。
你會在下面章節學到如何設計數據庫，現在讓我們假設數據庫大部分己經設計完成並且有一些表需要被執行。斯科特創建了EMP表來保存基本的員工信息，就像這樣：
你可能注意到佣金列和管理人列中有一些單元格中沒有值;它們是空值。一個關係數據庫能夠規定列中的一個單元格是否爲空。如此，可以明確那些非銷售部的員工佣金單元爲空。同樣也明確了公司董事長的管理人單元爲空，因爲這個員工不需要向任何人彙報工作。
單元格：是數據庫查詢語言所能夠檢索到的最小片信息。一個單元格就是一個數據庫表的行和列交叉形成的。
另一方面，沒有哪個員工的員工編號單元爲空。公司總是希望爲每個員工分配一個員工號，並目這個號碼必須是每個員工都不同的。關係數據庫的一個特性能夠確定某列的鍵入值必須爲單值。如此，員工編號列便是這個表的主碼。
主碼：主碼即是表中的一列(或多列)，使每一行能夠區別於同表中的其他行。
留意一下EMP表中存儲的不同數據類型：數值型，字符型或字母型，以及日期型。
如你所想，部門成員列保存的是員工所在部門的編號。但是你如何知道哪個部門名稱對應哪個部門編號呢?斯科特建立了DEPT表來具體描述EMP表中提到的部門編號的情況。
EMP表中的部門編號列同DEPT表中的部門編號列有着相同的值。既然如此，EMP表中的部門編號列便被看作是與DEPT表中相同列對應的外碼。
外碼加強了關係數據庫中參考完整性的概念。參考完整性的概念不只可以阻止無效的部門編號被插入EMP表中，而且在某部門仍有員工的情況下，可以防止DEPT表中該部門的信息被刪除。
外碼：表中的一列(或多列)，它的值來自於其他表的主碼列或單值列。一個外碼有助於確定表中數據的完整性。
參考完整性：是關係數據庫用來加強表間一對多關聯的一種方式。
數據建模
在斯科特於數據庫中創建真實表之前，他要經過一個稱作數據建模的過程。在這個過程中，數據庫創建者定義和填寫數據庫中所有表。有一種爲數據庫建模的方式叫作ERA,它可以表示出實體、實體間的關聯和實體的屬性。數據庫設計者使用一個能夠支持實體、實體屬性和實體間關聯的應用程序。通常，一個實體對應數據庫中的一個表，而實體的屬性對應於表中的列。
數據建模：一個定義實體、實體屬性和實體間關聯的過程，從而爲建立物理數據庫做準備。
數據建模過程包括定義實體、定義實體間關聯以及定義每個實體的屬性的過程。一旦一個週期完成，就需要不斷重複直到設計者抓住了重點，足以開始建立數據庫。讓我們進一步瞭解爲數據庫建模過程的步驟。
定義實體
首先，設計者確定數據庫應用程序範圍內的所有實體。實體是人、地方或事物，它們對於整個團體是重要的且需要被記錄在數據庫中。實體將被巧妙的轉化爲數據表。比如，在第一版斯科特飾品公司數據庫中，他定義了四個實體：員工、部門、工資水平和獎金。它們將稱爲EMP(員工)表，DEPT(部門)表，SALGRADE(工資水平)表和BONUS(獎金)表。
定義實體間的關聯
一旦定義了實體，設計者就能夠繼續定義每個實體間是如何關聯的。通常，設計者通常將每個實體同其他實體配對，並目考慮：“兩者之間是否存在關聯呢?”實體間的某些關聯是明顯的，某些不是。
在飾品公司數據庫中，員工實體和部門實體間極可能存在關聯，而依據事物間的關係原則，部門實體跟工資水平實體間似乎就沒有關聯了。如果事物間的關係原則是用來約束某個部門的工資水平的，就可能需要一個新的實體來說明工資水平和部門之間的關聯。這個實體被稱作關係表或交表，其中包含工資水平和部門之間的有效聯合。
關係表：是一個數據庫表，其中保存着另外兩個表的行(記錄)間的有效結合，並且通常強調了事物間的關係原則。關聯表處理的是一個多對多關聯。
通常，關係數據庫間有二種關聯方式：
·一對多關聯：最常見的關聯是一對多關聯。意思是對於每個給出的現有實體(即父實體)都有一個或多個現有的另一個實體(即子實體)與之相關聯。舉個例子來說，在飾品公司數據庫中，部門實體是一個父實體，而每個部門中，都有一個或多個員工屬於該部門。這樣，部門實體和員工實體間的關聯就是一對多關聯。
·一對一關聯：在一個一對一關聯中，表中的一行只關聯另一個表中的一行甚至0行。這種關聯類型通常用於子類型數據中。例如，一個員工表可能保存了所有員工的信息，而全職表、兼職表和承包人表則分別保存全職員工、兼職員工和承包人的信息。這些實體被認爲是員工表的子表，並目同員工表維持一對一關聯。這種關係不像一對多關聯那麼常見，因爲如果一個實體與另一個實體總有對應行，在大多數情況下，兩個實體中的屬性只在一個實體內出現就可以了。
·多對多關聯：在多對多關聯中，表的一行可能對應另一個表的許多行，反之亦然。通常，當這些關聯在數據庫中被執行時，往往再定義第三個實體用來保存前兩個實體間的所有關聯。例如，在一個學籍註冊數據庫中，學生表與班級表之間有一個多對多關聯——一個學生可能聽一門或多門課程，並目一個班級也可能有一個或多個學生。而學生_班級關係表中就包含了學生和班級之間的關係，以表明哪個學生在哪個班。
指定實體屬性
一旦設計者定義了實體間關聯，下一步就是去指定每個實體的屬性。這是實現列的使用，如右圖所示由工資水平實體所建立的工資水平表。
重複步驟：我們仍然在原地
在定義了實體、關聯以及屬性之後，設計者往往要多重複幾次數據建模過程。當我們在回顧關聯時，就會發現需要建立新的實體。比如，當討論飾品庫存表和與它相關的客戶訂單時，就會發現需要制定一個送貨約束表。
一旦設計過程完成，下面將要建立實際的數據庫表。邏輯數據庫的設計過程不會牽涉實際執行中的問題。然而，一旦設計進入到實際的運作，數據庫管理員就會很快讓設計者從理想回到現實中來。結果，設計就可能需要再次構想以求得理想的數據庫存運行與預算和進度之間的平衡。
