0% found this document useful (0 votes)
2 views34 pages

First Lecture in Query

The document provides a comprehensive overview of the Database Life Cycle, detailing phases from analysis to user interaction, and highlights the evolution from file-based systems to structured database systems. It emphasizes the importance of relationships, attributes, and roles within database management, as well as the transition from traditional data storage methods to modern database systems that ensure data integrity and security. Key concepts such as entity relationships, cardinality, and the roles of various stakeholders in database development are also discussed.

Uploaded by

Awad alshair
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views34 pages

First Lecture in Query

The document provides a comprehensive overview of the Database Life Cycle, detailing phases from analysis to user interaction, and highlights the evolution from file-based systems to structured database systems. It emphasizes the importance of relationships, attributes, and roles within database management, as well as the transition from traditional data storage methods to modern database systems that ensure data integrity and security. Key concepts such as entity relationships, cardinality, and the roles of various stakeholders in database development are also discussed.

Uploaded by

Awad alshair
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Database Life Cycle: A Simplified Overview

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.

ITI SQL Workshop Notes - By Adham Khaled


7. Lack of Standards
o Each system followed its own conventions, leading to inconsistency.
o Interoperability was a challenge.
8. Integration Issues
o Integrating data from different sources was complex.
o Violations of data consistency and integrity were common.
The Birth of Database Systems
• To address these issues, Database Systems emerged.
• They transitioned from a collection of files to a structured set of tables with
relationships.
• Key features included data integrity, security, standardized rules, and efficient
query capabilities.

ITI SQL Workshop Notes - By Adham Khaled


Key Aspects of Database Systems
1. One Standard
o Database systems adhere to a common standard.
o This consistency ensures compatibility and facilitates communication.
2. Metadata + Data
o Metadata describes the data.
o It includes:
▪ Column names
▪ Table names
▪ Relationships
▪ Primary keys
o Without metadata, accessing data becomes impossible.
3. Column Data Types
o Each column should have a specific data type (e.g., integer, float, string).
o Defining data types ensures accurate storage and efficient querying.
4. Primary Keys
o Every table should have a primary key.
o The primary key uniquely identifies each record.
o It ensures data integrity and efficient retrieval.
5. Foreign Keys
o To link tables, we use foreign keys.
o While not explicitly in the ER diagram, foreign keys emerge during the
mapping phase. They establish relationships between tables.
6. Centralized Database Server
o All tables reside on a centralized database server.
o This centralization streamlines management, security, and maintenance.
ITI SQL Workshop Notes - By Adham Khaled
ITI SQL Workshop Notes - By Adham Khaled
- User Demand for Simplicity
• Users wanted applications to handle databases.
• Interacting directly with MDF and IDF files was cumbersome.
• IBM played a significant role in early database adoption.
- Database Engines Convergence
• Around 2012, the gap between database engines narrowed.
• Leading players like Oracle, MySQL, and Microsoft improved usability.
• Common features emerged, making database systems more accessible.

________________________________________________________________________
If we wanted to describe Database System as a Diagram, we’ll notice that the end user
isn’t on the diagram ...

ITI SQL Workshop Notes - By Adham Khaled


ITI SQL Workshop Notes - By Adham Khaled
ITI SQL Workshop Notes - By Adham Khaled
• XML; In the early days of software development, integrating databases from different
vendors was challenging due to compatibility issues. Each database system had its own
protocols and data structures. However, XML (Extensible Markup Language) changed the
game. It provided a standardized, platform-independent format for representing
structured data. Developers could create custom schemas, bridging the gap between
applications and databases. XML facilitated seamless data exchange and mapping to
relational databases, making it a crucial tool for simplifying database interoperability

ITI SQL Workshop Notes - By Adham Khaled


1. Database Administrator (DBA):
o Responsible for managing and maintaining the database system.
o Handles tasks like backups, security, performance tuning, and user access control.
2. System Analysts:
o Analyze business requirements and translate them into technical specifications.
o Collaborate with developers and stakeholders to design effective database
solutions.
3. Database Designer:
o Designs the database schema, tables, and relationships.
o Ensures data integrity and efficient data storage.
4. Database Developer:
o Writes SQL queries, stored procedures, and triggers.
o Implements business logic within the database.
5. Application Programmers:
o Develop applications that interact with the database.
o Use APIs and libraries to connect to the database.
6. BI & Big Data Specialists (Data Scientists):
o Work with large datasets for business intelligence and analytics.
o Extract insights from data using tools like SQL, Python, or R.
7. End Users:
o Regular users who interact with the database through applications.
o Perform tasks like data entry, reporting, and querying.

ITI SQL Workshop Notes - By Adham Khaled


ITI SQL Workshop Notes - By Adham Khaled
1. Attributes for Relationships:
o In a database, relationships between entities are often represented by
attributes. These attributes describe the connection between two entities.
For example, consider the relationship between a student and a database
class. The attribute could be the student’s grade in that class.
o When designing a database schema, it’s essential to identify these attributes
and define them clearly. Naming conventions for relationship attributes can
help maintain consistency and readability.
2. Pay Attention to Nouns and Verbs:
o When reading requirements documents or analyzing a problem, focus on the
nouns and verbs. These often correspond to entities and relationships.
o Nouns typically represent entities (e.g., “student,” “class,” “course,” etc.).
These are the building blocks of your database schema.

ITI SQL Workshop Notes - By Adham Khaled


o Verbs often describe relationships (e.g., “enrolls in,” “attends,” “teaches,”
etc.). These verbs indicate how entities are related to each other.
3. Multi-Relationships:
o Yes, it’s possible to have multiple relationships between two entities. Let’s
explore this further:
▪ Consider a scenario where a student can be both a “member” and a
“leader” of a student organization. Here, the same student entity has
two distinct relationships with the organization: one as a regular
member and another as a leader.
▪ Similarly, an employee might have different relationships with a
project, such as being a “developer,” a “tester,” and a “project
manager.”
▪ These multi-relationships enrich the semantics of the model, allowing
for more nuanced representations.

ITI SQL Workshop Notes - By Adham Khaled


- Entity Transition to Tables: All entities in our system will be transitioned into tables
within the database structure.

- Strong Entities: A "strong" entity is characterized by its independence; it remains


unaffected by the deletion of another entity. For example, if an employee leaves a
department, the existence and structure of the department itself remain unchanged.

- 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.

- Weak Entities: A "weak" entity is dependent on a "strong" parent entity. It cannot


exist without the strong entity it is associated with.

ITI SQL Workshop Notes - By Adham Khaled


- Key Definitions:

• The unique identifier for a strong entity is termed a "primary key".


• A weak entity has a "partial key", which is used in conjunction with the primary
key of the strong entity it depends on. These relationships and keys will become
clearer during the database mapping phase.

ITI SQL Workshop Notes - By Adham Khaled


ITI SQL Workshop Notes - By Adham Khaled
Attributes of an Entity
Attributes are the characteristics or properties that define an entity.
Necessity: Every entity must have attributes. An entity without attributes is not
considered a complete entity.
Simple Attributes: A simple attribute is one that:
• Cannot be divided into smaller parts.
• Is not calculated or derived at runtime.
• Is unique and cannot be repeated for the same entity.
Examples:
City: A customer living in one city, such as NYC, has a simple attribute of "City". This
attribute is straightforward and not divisible.
Name: A customer’s name is also a simple attribute. It is not calculated and remains
constant at runtime. Each customer has one unique name, making it a simple attribute.

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.

ITI SQL Workshop Notes - By Adham Khaled


When discussing attributes, it's important to understand the concept of composite
attributes. For example, if we have attributes like First Name, Last Name, and Date
of Birth (which consists of Month, Day, and Year), we are dealing with composite
attributes.

A key point to remember is that a composite attribute is essentially a single


attribute that is divided into multiple components. If you combine these
components, they should form one complete entity. This is why it's termed as
"composite" – it represents one attribute that has been split into parts.

ITI SQL Workshop Notes - By Adham Khaled


When a value can be computed during runtime based on other available data, it is
considered a derived value.

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.

ITI SQL Workshop Notes - By Adham Khaled


If there is something related to the same person but it doubled or tripled such as
customer who have two phone numbers and three addresses in different cities.

ITI SQL Workshop Notes - By Adham Khaled


Complex Attribute is about mixing multi-valued with Composite.

ITI SQL Workshop Notes - By Adham Khaled


Recap:

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).

ITI SQL Workshop Notes - By Adham Khaled


Relationship is the diamond that connect between two entities, the verb that describes
the relation between two entities.
It is possible to be more than relationship between two entities if they are giving
different meanings …

ITI SQL Workshop Notes - By Adham Khaled


Degree of Relationships (Types of Relationships)

ITI SQL Workshop Notes - By Adham Khaled


Unary Relationship; It’s about a relation between Entity and the entity itself

ITI SQL Workshop Notes - By Adham Khaled


Relationships in ER Diagrams:

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.

Example: Customer (entity) purchases (relationship) Product (entity). The diamond


could be labeled "purchases."

• Ternary Relationship: A less common type, involving three different entities.


Imagine a diamond shape connecting all three entities. It represents a more
complex interaction where all three entities are involved.

ITI SQL Workshop Notes - By Adham Khaled


Example: Supplier (entity) supplies (relationship) Product (entity) to Project (entity).
The diamond here represents the "supplies" relationship between suppliers, products,
and projects.

ITI SQL Workshop Notes - By Adham Khaled


Cardinality

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;

Consider the relationship between an instructor and a course:

Instructor ≤◊ Teach ◊≥ Course

Here, the relationship is defined by the verb "teach."

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:

- One instructor teaches many courses.

- One course is taught by many instructors.

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.

ITI SQL Workshop Notes - By Adham Khaled


Observer here, he used one sentence at describing the department. And two at
employee.
Ask yourself first, does all employees should work in a department. Observer here he
written must every employee to have a department. So, all employees are involved in
the relationship so this is a total participation and we’ll represent it by two lines that
linked to the diamond.
Let’s analyze when he talked about the department, He use word May which means
that isn’t mandatory to all departments to have employees. So, we’ll represent it by one
line that linked to the diamond. So, this is a partial participation.

ITI SQL Workshop Notes - By Adham Khaled


Candidate key is the pre-phase of choosing the primary key. Imagine the is a customer
and we have a lot of data about him, so we will put some possible keys to be the
primary key, but we didn’t decide yet, so this called a candidate key.
Remember if there is nothing that can be a primary key. So it is time to composite some
items together to be a unique key

ITI SQL Workshop Notes - By Adham Khaled


ITI SQL Workshop Notes - By Adham Khaled

You might also like