Study notes  
 
 
A relational database is a type of database that organizes data into tables, which consist of rows and columns.
In a relational database, data is structured in a way that facilitates the establishment of relationships between different pieces of information.

Any real world phenomenon [something] about which we want to record data can be described as an entity.
For each entity, we need to establish what data items or attributes we need to record.

  The domain of an attribute in a database is the set of all possible values that an attribute (or column) can have. It defines the type and range of values allowed for that attribute.
For example:
  For an attribute "Age," the domain might be all integer values from 0 to 120.
  For an attribute "Email," the domain would be all valid email addresses.
  Setting a domain helps maintain data integrity by restricting values to a specific type, range, or format, ensuring that data stored in the database is consistent and meaningful

  The entity integrity rule is a principle in database management that ensures each record in a table is unique and identifiable. It requires that the primary key (the unique identifier for each record) cannot have a null (empty) value. This is because the primary key uniquely distinguishes each record, and if it were empty, it would be impossible to uniquely identify records, leading to inconsistencies in the data.
  In simple terms: every record must have a unique ID that isn't blank.


  In a database, a relationship between two entities (such as tables) exists when there is a link or connection between them. For this relationship to be meaningful, both entities need to have a common attribute — an attribute (or column) that appears in both entities with the same type of information. This common attribute acts as a bridge, allowing the database to connect data across the two tables.
  For example, in a database with a "Students" table and a "Courses" table, both tables might have a "StudentID" attribute. By having "StudentID" in both tables, we can create a relationship, linking each student with the courses they are enrolled in. This common attribute helps ensure that we can reference and organize data across different parts of the database.

Cardinality refers to the relationships between the data in two database tables. Cardinality defines how many instances of one entity are related to instances of another entity.

In other words, cardinality describes a fundamental relationship between two entities or objects. There are three relationship types or cardinalities: one-to-one, one-to-many, and many-to-many. Entity-Relationship (ER) diagrams are used to describe the cardinality in databases.




  Each instance in one entity relates to only one instance in the other, and vice versa.
  Example:
  Entities: Person and Passport
  Relationship: Each person has only one passport, and each passport is assigned to only one person.
  Explanation: In this case, each person in the "Person" table has a unique passport in the
"Passport" table, making it a one-to-one relationship
Explanation: Here, the "Teacher" table has a one-to-many relationship with the "Class" table since one teacher can be responsible for many classes, but each class is managed by only one teacher.


* Many instances in one entity can relate to a single instance in the other entity.
•Example: Entities: Employee and Department
Relationship: Many employees work in one department, but each employee works in only one department.
Explanation: Here, the "Employee" table has a many-to-one relationship with the
"Department" table, as multiple employees can belong to the same department.

  Multiple instances in one entity can relate to multiple instances in the other.
  Example:
  Entities: Student and Course
  Relationship: A student can enroll in multiple courses, and a course can have multiple students.
  Explanation: Here, "Student" and "Course" have a many-to-many relationship. To implement this in a database, we often use a junction table (like Enrollment) that holds records of each unique student-course combination.
  These cardinalities help define the relationships in a da base, structuring how data is linked and retrieved across tables.


Relational Database theory has been developed to help you design the best and most reliable structure for your database.

The process of efficiently organising data in a database is referred to as normalisation - a way to organize data in a database to make it more efficient and reliable.


Reduce Duplication: Normalization helps to avoid storing the same information in multiple places. This saves space and keeps data consistent

Ensure Accuracy: By organizing data properly, normalization helps keep information correct and up-to-date. If something changes, you only have to update it in one place.

Make Searches Faster:A well-organized database can help find and retrieve information more quickly.

Easier to Update: Normalization makes it simpler to add, change, or remove data without causing problems.

Define Connections: It helps establish how different pieces of information relate to each other, making it easier to manage.

Support Growth:As more data is adled, normalised  structure can adapt better: making it easier to expand.



In summary, normalization makes databases work better by keeping data organized and reliable.

The process of creating a sound structure for your data Three stages of normalisation:

  First Normal Form
  Second Normal Form
  Third Normal Form

To achieve First Normal Form we need every component in the database to be atomic.
Every field should store data for one attribute only

First Normal Form also requires that each entity (each row in the table) should be uniquely identified.
The field that uniquely identifies an entity is known as the Primary Key.

You have achieved INF when your rows are uniquely identified, and your columns contain
only one item of a consistent data type.
We aim to achieve a state of where the attributes in non-key columns are dependent on the key

• CustomerID and ProductiD relate to the Order but the Price and Supplier relate only to the Product, so they do not belong in this table.
They should be in a record which is uniquely identified by the ProductiD