First Lecture in Query
First Lecture in Query
1. Analysis
o Conducted by a System Analyst who writes the requirements document.
o The goal is to define the scope of the project.
o System analysts bridge the gap between clients and developers.
o They ensure clear communication and understanding of project needs.
2. Database Design
o Performed by the Database Designer.
o Involves creating an Entity Relationship Diagram (ERD).
o Entities represent objects (e.g., hospitals, patients, doctors).
o The ERD visually depicts how these entities relate to each other.
3. Database Mapping
o After drawing the ERD, the focus shifts to database mapping.
o Rules are established, and the actual schema is defined.
o Tables are created based on the ERD.
o This step helps prevent errors and ensures a logical structure.
4. Database Implementation
o Database Developers take charge during this phase.
o They translate the planning (from analysis and design) into reality.
o Relational Database Management Systems (RDBMS) like SQL Server, Oracle,
or MySQL are used.
o Installation of the chosen RDBMS turns the machine into a database server.
o Centralized and shared databases are common (avoiding inconsistent
copies).
5. Application Development
o Programmers build the application and its graphical user interface (GUI).
o The developer becomes a database user, interacting with the engine they’ve
built.
o This step brings the system to life, integrating the database with the
application.
6. User Interaction
o The flow from client to end-user:
▪ Client (requests or interacts with the application)
▪ End-User (uses the application)
▪ Browser (accesses the application via a URL)
ITI SQL Workshop Notes - By Adham Khaled
Evolution from File-Based Systems to Database Systems
In the past, data storage relied on text files, known as File-Based Systems. These systems
had two primary formats: Delimited Files and Fixed Width Files. However, they posed
several challenges:
1. Difficulty in Data Retrieval
o Searching for data was cumbersome due to the lack of efficient search
mechanisms.
o Inconsistencies arose because data was scattered across various files.
2. Lack of Relationships
o File-Based Systems didn’t establish relationships between different data files.
o This absence of connections hindered data integrity and made complex
queries challenging.
3. Database Redundancy
o Data duplication occurred, leading to inefficiencies and wasted storage
space.
o Maintaining consistency across copies was difficult.
4. Security Concerns
o Plain text files lacked security features.
o Permissions and access control were absent.
5. Missing Constraints and Rules
o Without enforced constraints, data quality suffered.
o Business rules and integrity checks were not part of the system.
6. Manual Backup and Restore
o Backing up and restoring data required manual effort.
o No automated processes were in place.
________________________________________________________________________
If we wanted to describe Database System as a Diagram, we’ll notice that the end user
isn’t on the diagram ...
- Example of Strong Entities: In the context of banking, banks are required to maintain
records of all money transfers. Therefore, if a client terminates their contract and
switches to another bank, the original bank continues to keep the transaction data. This
demonstrates the robustness of the entity as it remains stable despite changes in
related entities.
But if he said that there is a First Name and Last Name, or the Data of Birth is about
Month, Day, and Year, Now we talk about the composite Attribute.
Examples:
1. Age Calculation: Given a person's birthdate, you can compute their age.
2. Net Salary Calculation: If you know the gross salary and deductions, you can
determine the net salary.
1. Simple Attribute:
o Definition: An attribute that cannot be divided into smaller parts, is not
calculated at runtime, and is unique to each entity.
o Example: A person's first name or social security number.
2. Composite Attribute:
o Definition: An attribute that can be divided into smaller, meaningful
sub-parts.
o Example: An address can be broken down into street, city, state, and
zip code.
3. Derived Attribute:
o Definition: An attribute whose value is calculated at runtime using a
formula or algorithm.
o Example: Age, which can be derived from a person's date of birth.
4. Multi-valued Attribute:
o Definition: An attribute that can have multiple values for a single
entity.
o Example: A person’s phone numbers, where an individual can have a
home, work, and mobile number.
5. Complex Attribute:
o Definition: An attribute that combines multi-valued and composite
attributes.
o Example: A person’s educational qualifications, where each
qualification (multi-valued) includes details such as institution name,
degree, and year of graduation (composite).
Relationships connect entities in a database schema, showing how they interact with
each other.
• Binary Relationship: The most common type. It involves two different entities.
Imagine a line connecting them, with a diamond in the middle. The diamond
represents the relationship itself, often labeled with a verb describing the
connection.
When dealing with two entities, we must be very careful when choosing the verb,
as it will affect the cardinality and the relationship between the entities.
Definition of Cardinality
Cardinality shows the extent of the relationship between two entities. For
example, there may be only one department and one employee in a certain context.
Example;
Establishing Cardinality;
To establish cardinality, we first identify the verb that describes the relationship (in this
case, "teach").
Types of Relationships
1. One to Many:
After analyzing the "ones" and "many," we determine that the relationship is many to
many. This demonstrates the importance of choosing the correct verb, as it significantly
influences the entire cardinality.
ITI SQL Workshop Notes - By Adham Khaled
ITI SQL Workshop Notes - By Adham Khaled
ITI SQL Workshop Notes - By Adham Khaled
When discussing cardinality, we focused on analyzing one row from the first entity
and observing its relationship or bond with another entity.
In the context of participation:
• Total Participation occurs when all rows of an entity are involved in the
relationship.
• Partial Participation occurs when only some rows of an entity are involved in the
relationship.
Regarding weak entities, note that a weak entity is depicted with two lines, indicating
that every weak entity requires total participation in the relationship. For example,
consider a transaction in a bank: a transaction cannot exist without being associated
with an account in that bank. This demonstrates the principle of a strong entity and
total participation.
Key points to remember:
• When assessing cardinality, we compare one entity’s bond to another entity.
• When assessing participation, we determine if all rows are involved (total
participation) or if only some rows are involved (partial participation).
Pay attention to terminology that indicates the status of participation:
• Partial Participation: Zero or More, May, Optional
• Total Participation: Must, One or More, Mandatory, Obligatory
Lastly:
• The clarity of the case is crucial. Ensure you fully understand the requirements.
• If any requirements are unclear, do not rely on assumptions. Seek additional
details from the system analyst or relevant sources.