Database File: This is your main file that encompasses the entire database and that is saved to your hard-drive.
Example) StudentDatabase.mdb
Table: A table is a collection of data about a specific topic. There can be multiple tables in a database.
Example #1) Students
Example #2) Teachers
Field: Fields are the different categories within a Table. Tables usually contain multiple fields.
Example #1) Student LastName
Example #2) Student FirstName
Datatypes: Datatypes are the properties of each field. A field only has 1 datatype.
FieldName) Student LastName
Datatype) Text
1
Database Relationship
Formal Definitions
A one-to-one (1:1) relationship is when at most one instance of entity A is associated with one instance of entity B. Because this is similar to one table of records, this type of relationship is hardly used since you can as well simply create one table. For example,
"employees in the company are each assigned their own office. For each employee there exists a unique office and for each office there exists a unique employee.
A one-to-many (1:N) relationship is when for one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A. An example of a 1:N relationship is: a department has many employees and each employee is assigned to one department.
A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. An example is: employees can be assigned to no more than two projects at the same time; projects must have assigned at least three employees
A single employee can be assigned to many projects; conversely, a single project can have assigned to it many employee. Here the cardinality for the relationship between employees and projects is two and the cardinality between project and employee is three.
Many-to-many relationships cannot be directly translated to relational tables but instead must be transformed into two or more one-to-many relationships using associative entities.
2
Informal Definitions
In a one-to-one relationship , each record in one table can have only one matching record in a second table, and each record in the second table can have only one matching record in the first table. This type of relationship is fairly uncommon, because most information related in this way would be in one table.
A one-to-many relationship is the most common type of relationship. In a one-to-many relationship, a record in Table A can have many matching records in Table B, but a record in Table B has only one matching record in Table A. For example, one publisher can publish many journals, but it's highly unlikely that a journal would have more than one publisher. Similarly, one bindery could receive many volumes each year to be bound, but each volume would only go to one bindery.
In a many-to-many relationship , a record in one table (table 1) can have many matching records in a second table (table 2), and a record in table 2 can have many matching records in table 1. This type of relationship is only possible by defining a third table
(called a junction table) whose primary key consists of two fields - the foreign keys from both Tables 1 and 2. A many-to-many relationship is really two one-to-many relationships with a third table.
To implement this type of relationship, you can create what is called a junction table. A junction table is a table whose main purpose is to bring together fields from other tables, creating a type of cross relationship for the necessary fields. A junction table can be very helpful for data analysis and sub-forms/sub-reports:
Many to Many
Table 1 Table 2
One to Many One to Many
Junction
Table
A junction table is usually made of three or four fields (usually not less than three and usually not more than four; a classic junction table has only three fields). The first field, almost less engaged, is used as the primary key, the same type of field almost every table has. The other fields hold data that would emanate from other tables.
3
Relationship in Access
A relationship works by matching data in key fields - usually a field with the same name in both tables. In most cases, these matching fields are the primary key from one table, which provides a unique identifier for each record, and a foreign key in the other table.
For example, teachers can be associated with the students they're responsible for by creating a relationship between the teacher's table and the student's table using the
TeacherID fields.
Having met the criteria above, follow these steps for creating relationships between tables:
1.
In the database window view, at the top, click on Tools ---> Relationships
2.
Select the Tables you want to link together, by clicking on them and selecting the
Add Button
3.
Drag the primary key of the Parent table (Teacher in this case), and drop it into the same field in the Child table (Student in this case.)
4.
Select Enforce Referential Integrity o When the Cascade Update Related Fields check box is set, changing a primary key value in the primary table automatically updates the matching o value in all related records.
When the Cascade Delete Related Records check box is set, deleting a record in the primary table deletes any related records in the related table
5.
Click Create and Save the Relationship
4
Referential Integrity
Referential integrity is a database concept that ensures that relationships between tables remain consistent. When one table has a foreign key to another table, the concept of referential integrity states that you may not add a record to the table that contains the foreign key unless there is a corresponding record in the linked table. It also includes the techniques known as cascading update and cascading delete, which ensure that changes made to the linked table are reflected in the primary table.
Consider the situation where we have two tables: Employees and Managers. The
Employees table has a foreign key attribute entitled ManagedBy which points to the record for that employee’s manager in the Managers table. Referential integrity enforces the following three rules:
1.
We may not add a record to the Employees table unless the ManagedBy attribute points to a valid record in the Managers table.
2.
If the primary key for a record in the Managers table changes, all corresponding records in the Employees table must be modified using a cascading update.
3.
If a record in the Managers table is deleted, all corresponding records in the
Employees table must be deleted using a cascading delete.
Primary Key
The primary key of a relational table uniquely identifies each record in the table. It can either be a normal attribute that is guaranteed to be unique (such as Social Security
Number in a table with no more than one record per person) or it can be generated by the
DBMS. Primary keys may consist of a single attribute or multiple attributes in combination. Imagine we have a student records database that contains three tables. The first table, STUDENTS, contains a record for each student at the university. The second table, CLASSES, contains a record for each class session offered. The third table,
ENROLLMENT, contains student enrollment records (e.g. each record represents a single student enrolling in a single course).
There would be multiple records for each student (representing all the classes that student is enrolled in) and multiple records for each class session (representing all the students enrolled in that class). A student's unique student ID number would be a good choice for a primary key in the STUDENTS table. The student's first and last name would not be a good choice, as there is always the chance that more than one student might have the same name.
5
Foreign Key
A foreign key is a relationship or link between two tables which ensures that the data stored in a database is consistent.
The foreign key link is set up by matching columns in one table (the child ) to the primary key columns in another table (the parent ).
In the example below, there is a link between the Company and Contact tables. The
Company table is the parent table in the link. The Contact table is the child: the
Company_ID field in the Contact table indicates which Company a Contact belongs to.
6