This document discusses the relational data model and relational algebra. It defines key concepts of the relational model such as relations, tuples, domains, attributes, and constraints. It also covers relational algebra operations like SELECT, PROJECT, JOIN, and set operations. Relational algebra provides a foundation for implementing queries in relational database management systems.
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...Raj vardhan
The Relational Data Model and Relational Database Constraints
Ch5 (Navathe 4th edition)/ Ch7 (Navathe 3rd edition)
Example of STUDENT Relation(figure 5.1)
Introduction To Database Management Systemcpjcollege
Database Management System (DMBS)
• Collection of interrelated data • Set of programs to access the data • DMBS contains information about a particular enterprise • DBMS provides an environment that it both convenient and efficient to use
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...Raj vardhan
The Relational Data Model and Relational Database Constraints
Ch5 (Navathe 4th edition)/ Ch7 (Navathe 3rd edition)
Example of STUDENT Relation(figure 5.1)
Introduction To Database Management Systemcpjcollege
Database Management System (DMBS)
• Collection of interrelated data • Set of programs to access the data • DMBS contains information about a particular enterprise • DBMS provides an environment that it both convenient and efficient to use
Comparison of Relational Database and Object Oriented DatabaseEditor IJMTER
The object-oriented database (OODB) is the combination of object-oriented
programming language (OOPL) systems and persistent systems. Object DBMSs add database
functionality to object programming languages. They bring much more than persistent
storage of programming language objects. A major benefit of this approach is the unification
of the application and database development into a seamless data model and language
environment. This report presents the comparison between object oriented database and
relational database. It gives advantages of OODBMS over RDBMS. It gives applications of
OODBMS.
Data modeling is a process used to define and analyze data requirements needed to support the business processes within the scope of corresponding information systems in organizations.
This Presentation would make you understand the Fundamentals of Database Design, Data Models (Conceptual, Logical & Physical), ERD, ERM. Also, have real-life examples and case study to understand better.
● Data Modeling and Data Models.
● Business Rules (Translating Business Rules into Data Model Components).
● Emerging Data Models: Big Data and NoSQL.
● Degrees of Data Abstraction (External, Conceptual, Internal and Physical model).
Comparison of Relational Database and Object Oriented DatabaseEditor IJMTER
The object-oriented database (OODB) is the combination of object-oriented
programming language (OOPL) systems and persistent systems. Object DBMSs add database
functionality to object programming languages. They bring much more than persistent
storage of programming language objects. A major benefit of this approach is the unification
of the application and database development into a seamless data model and language
environment. This report presents the comparison between object oriented database and
relational database. It gives advantages of OODBMS over RDBMS. It gives applications of
OODBMS.
Data modeling is a process used to define and analyze data requirements needed to support the business processes within the scope of corresponding information systems in organizations.
This Presentation would make you understand the Fundamentals of Database Design, Data Models (Conceptual, Logical & Physical), ERD, ERM. Also, have real-life examples and case study to understand better.
● Data Modeling and Data Models.
● Business Rules (Translating Business Rules into Data Model Components).
● Emerging Data Models: Big Data and NoSQL.
● Degrees of Data Abstraction (External, Conceptual, Internal and Physical model).
Database Normalization
The term Normalization is a process by which we can efficiently organize the data in a database. It associates relationship between individual tables according to policy designed both to care for the data and to create the database more flexible by eliminating redundancy and inconsistent dependency.
In other words, Database normalization is a process by which a presented database is tailored to bring its component tables into compliance with a sequence of progressive standard forms. It is an organized way of ensuring that a database construction is appropriate for general purpose querying and also includes the functions of insertion, deletion and updating.
Edgar Frank Codd was the person who introduced the process of database normalization firstly in his paper called A Relational Model of Data for Large Shared Data Banks. The two main objective of database normalization is eliminating redundant data and ensuring data dependencies make sense and make sure that every non-key column in every table is directly reliant on the key and the whole key.
Redundant data or unnecessary data will take more and more space in the database and later, creates the maintenance problem in the database. If data that exists in more than one place must be changed because it wastes disk space and the data must be changed in exactly the same way in all locations of the table.
Upload a presentation to download APPLICATIChapter-02 -sualihmehammednur
IT Course Upload a presentation to download
APPLICATION OF INTEGRATION
Upload a presentation to download
APPLICATION OF INTEGRATION
Upload a presentation to download
APPLICATION OF INTEGRATION
Upload a presentation to download
APPLICATION OF INTEGRATION
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
Chapter 6 relational data model and relational
1. C H A P T E R 6 , 7
RELATIONAL DATA MODEL
AND RELATIONAL ALGEBRA
Relational Data Model and Relational Algebra
1
Sahaj Computer Solutions
2. RELATIONAL MODEL CONCEPTS
The relational model represents the database as a
collection of relations.
In the formal relational model terminology, a row is
called a tuple, a column header is called an
attribute, and the table is called a relation.
The data type describing the types of values that can
appear in each column is represented by a domain of
possible values.
Relational Data Model and Relational Algebra
2
Sahaj Computer Solutions
3. Domains, Attributes, Tuples, and Relations
A domain D is a set of atomic values.
By atomic we mean that each value in the domain is
indivisible.
A relation schema R, denoted by R(A1, A2, ...
, An),is made up of a relation name R and a list of
attributes A1,A2, ..., An.
Each attribute Ai is the name of a role played by
some domain D in the relation schema R.
D is called the domain of Ai and is denoted by
dom(A).
Relational Data Model and Relational Algebra
3
Sahaj Computer Solutions
4. Characteristics of Relations
Ordering of Tuples in a Relation:
A relation is defined as a set of tuples.
Mathematically, elements of a set have no order among them;
hence, tuples in a relation do not have any particular order.
Tuple ordering is not part of a relation definition, because a
relation attempts to represent facts at a logical or abstract
level.
Ordering of Values within a Tuple, and an
Alternative Definition of a Relation
According to the preceding definition of a relation, an n-tuple is an
ordered list of n values, so the ordering of values in a tuple-and
hence of attributes in a relation schema-is important.
Relational Data Model and Relational Algebra
4
Sahaj Computer Solutions
5. Characteristics of Relations
However, at a logical level, the order of attributes and their
values is not that important as long as the correspondence
between attributes and values is maintained.
An alternative definition of a relation can be given as relation
schema R = {A1, A2, ••• , An} is a set of attributes, and a
relation state r(R) is a finite set of mappings r = {t1,t2,…,tm},
where each tuple t1 is a mapping from R to D, and D is the
union of the attribute domains; that is, D = dom(Al )U
dom(A2) U ... U dom(An).
Relational Data Model and Relational Algebra
5
Sahaj Computer Solutions
6. Characteristics of Relations
Values and Nulls in the Tuples
Each value in a tuple is an atomic value; that is, it is not
divisible into components within the framework of the basic
relational model.
Hence, composite and multivalued attributes are not allowed.
An important concept is that of nulls, which are used to
represent the values of attributes that may be unknown or may
not apply to a tuple.
A special value, called null, is used for these cases.
Relational Data Model and Relational Algebra
6
Sahaj Computer Solutions
7. Characteristics of Relations
Interpretation (Meaning) of a Relation
The relation schema can be interpreted as a declaration or a
type of assertion.
For example, the schema of the STUDENT relation asserts
that, in general, a student entity has a Name, SSN,
HomePhone, Address, OfficePhone, Age, and Performance.
Notice that some relations may represent facts about entities,
whereas other relations may represent facts about
relationships.
Relational Data Model and Relational Algebra
7
Sahaj Computer Solutions
8. Relational Model Notation
A relation schema R of degree n is denoted by
R(A1, A 2, ... ,An).
An n-tuple t in a relation r(R) is denoted by t =
<V1, V2, ••• ,vn>, where Vi is the value
corresponding to attribute Ai.
The letters Q, R, S denote relation names.
The letters q, r, s denote relation states.
The letters t, u, V denote tuples.
Relational Data Model and Relational Algebra
8
Sahaj Computer Solutions
9. Relational Model Notation
In general, the name of a relation schema such as
STUDENT also indicates the current set of tuples in
that relation-the current relation state-whereas
STUDENT(Name, SSN, ...) refers only to the relation
schema.
An attribute A can be qualified with the relation
name R to which it belongs by using the dot notation
R.A-for example, STUDENT.Name or
STUDENT.Age.
Relational Data Model and Relational Algebra
9
Sahaj Computer Solutions
10. RELATIONAL MODEL CONSTRAINTS AND
RELATIONAL DATABASE SCHEMAS
Relational Data Model and Relational AlgebraSahaj Computer Solutions
10
Constraints on databases can generally be divided
into three main categories:
Constraints that are inherent in the data model. We call these
inherent model based constraints.
Constraints that can be directly expressed in the schemas of
the data model, typically by specifying them in the DDL. We
call these schema-based constraints.
Constraints that cannot be directly expressed in the schemas
of the data model, and hence must be expressed and enforced
by the application programs. We call these application-based
constraints.
11. Domain Constraints
Relational Data Model and Relational AlgebraSahaj Computer Solutions
11
Domain constraints specify that within each
tuple, the value of each attribute A must be an
atomic value from the domain dom(A).
The data types associated with domains typically
include standard numeric data types for integers
(such as short integer, integer, and long integer) and
real numbers (float and double-precision float).
Characters, booleans, fixed-length strings, and
variable-length strings are also available, as are
date, time, timestamp, and, in some cases, money
data types.
12. Key Constraints and Constraints on Null Values
Relational Data Model and Relational AlgebraSahaj Computer Solutions
12
A superkey SK specifies a uniqueness constraint
that no two distinct tuples in any state r of R can
have the same value for SK.
Suppose that we denote one such subset of attributes
by SK, then for any two distinct tuples t1 and t2 in a
relation state r of R, we have the constraint that
t1[SK] ≠t2[SK]
Any such set of attributes SK is called a superkey of
the relation schema R.
13. Relational Data Model and Relational AlgebraSahaj Computer Solutions
13
A key satisfies two constraints:
Two distinct tuples in any state of the relation cannot have
identical values for (all) the attributes in the key.
It is a minimal superkey-that is, a superkey from which we
cannot remove any attributes and still have the uniqueness
constraint in condition 1 hold.
A relation schema may have more than one key.
In this case, each of the keys is called a candidate
key. For example, the CAR relation has two
candidate keys: LicenseNumber and
EngineSerialNumber.
14. Entity Integrity, Referential Integrity, and Foreign
Keys
Relational Data Model and Relational AlgebraSahaj Computer Solutions
14
The entity integrity constraint states that no primary
key value can be null.
This is because the primary key value is used to
identify individual tuples in a relation.
Having null values for the primary key implies that
we cannot identify some tuples.
15. Entity Integrity, Referential Integrity, and Foreign
Keys
Relational Data Model and Relational AlgebraSahaj Computer Solutions
15
The referential integrity constraint is specified
between two relations and is used to maintain the
consistency among tuples in the two relations.
Informally, the referential integrity constraint states
that a tuple in one relation that refers to another
relation must refer to an existing tuple in that
relation.
To define referential integrity more formally, we first
define the concept of a foreign key.
16. Entity Integrity, Referential Integrity, and Foreign
Keys
Relational Data Model and Relational AlgebraSahaj Computer Solutions
16
A set of attributes FK in relation schema R1 is a
foreign key of R2 that references relation R2 if it
satisfies the following two rules:
The attributes in FK have the same domain(s) as the primary
key attributes PK of R2; the attributes FK are said to reference
or refer to the relation R2.
A value of FK in a tuple t1 of the current state r1 (R1) either
occurs as a value of PK for some tuple t2 in the current state
r2(Rz) or is null.
17. Other Types of Constraints
Relational Data Model and Relational AlgebraSahaj Computer Solutions
17
Other Types of Constraints
The preceding integrity constraints do not include a large
class of general constraints, sometimes called semantic
integrity constraints, which may have to be specified
and enforced on a relational database.
Examples of such constraints are "the salary of an
employee should not exceed the salary of the employee's
supervisor" and "the maximum number of hours an
employee can work on all projects per week is 56“.
Mechanisms called triggers and assertions can be
used.
18. Other Types of Constraints
Relational Data Model and Relational AlgebraSahaj Computer Solutions
18
The types of constraints we discussed so far may be
called state constraints, because they define the
constraints that a valid state of the database must
satisfy.
Another type of constraint, called transition
constraints, can be defined to deal with state
changes in the database.
An example of a transition constraint is: "the salary
of an employee can only increase."
19. UPDATE OPERATIONS AND DEALING WITH
CONSTRAINT VIOLATIONS
Relational Data Model and Relational AlgebraSahaj Computer Solutions
19
There are three basic update operations on relations:
insert, delete, and modify.
Insert is used to insert a new tuple or tuples in a
relation, Delete is used to delete tuples, and Update
(or Modify) is used to change the values of some
attributes in existing tuples.
20. The Insert Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
20
The Insert operation provides a list of attribute values for a new tuple t
that is to be inserted into a relation R.
Insert can violate any of the four types of constraints
Insert <'Cecilia', 'F', 'Kolonsky', null, '1960-04-05', '6357 Windy
Lane, Katy, TX', F, 28000, null, 4> into EMPLOYEE.
This insertion violates the entity integrity constraint (null for the
primary key SSN), so it is rejected.
Insert <'Alicia', 'I'. 'Zelaya', '999887777', '1960-04-05', '6357 Windy
Lane, Katy, TX', F, 28000, '987654321', 4> into EMPLOYEE.
This insertion violates the key constraint because another tuple with
the same SSN value already exists in the EMPLOYEE relation, and so
it is rejected.
21. The Insert Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
21
Insert <Cecilia', 'F', 'Kolonskv', '677678989', '1960-04-05', '6357
Windswept, Katy, TX', F, 28000, '987654321', 7> into EMPLOYEE.
This insertion violates the referential integrity constraint specified on
DNO because no DEPARTMENT tuple exists with DNUMBER = 7.
Insert <Cecilia', 'F', 'Kolonsky', '677678989', '1960-04-05', '6357 Windy
Lane, Katv, TX', F, 28000, null, 4> into EMPLOYEE.
This insertion satisfies all constraints, so it is acceptable.
If an insertion violates one or more constraints, the default
option is to reject the insertion.
22. The Delete Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
22
The Delete operation can violate only referential
integrity, if the tuple being deleted is referenced by the
foreign keys from other tuples in the database.
To specify deletion, a condition on the attributes of the
relation selects the tuple (or tuples) to be deleted. Here
are some examples.
Delete the WORKS_ON tuple with ESSN = '999887777' and PNO =
10.
This deletion is acceptable.
Delete the EMPLOYEE tuple with SSN = '999887777'.
This deletion is not acceptable, because tuples in WORKS_ON refer to this
tuple. Hence, if the tuple is deleted, referential integrity violations
will result.
23. The Delete Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
23
Several options are available if a deletion operation
causes a violation.
The first option is to reject the deletion.
The second option is to attempt to cascade (or propgate) the
deletion by deleting tuples that reference the tuple that is being
deleted
A third option is to modify the referencing attribute values
that cause the violation; each such value is either set to null or
changed to reference another valid tuple.
Combinations of these three options are also
possible.
24. The Update Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
24
The Update (or Modify) operation is used to change the
values of one or more attributes in a tuple (or tuples) of
some relation R.
For Example:
Update the SALARY of the EMPLOYEE tuple with SSN =
'999887777' to 28000.
Update the DNO of the EMPLOYEE tuple with SSN =
'999887777' to 1.
Updating an attribute that is neither a primary key nor a
foreign key usually causes no problems; the DBMS need
only check to confirm that the new value is of the correct
data type and domain.
25. The Update Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
25
Modifying a primary key value is similar to deleting one
tuple and inserting another in its place, because we use
the primary key to identify tuples.
If a foreign key attribute is modified, the DBMS must
make sure that the new value refers to an existing tuple
in the referenced relation (or is null).
Update the DNO of the EMPLOYEE tuple with SSN =
'999887777' to 7.
Unacceptable, because it violates referential integrity.
Update the SSN of the EMPLOYEE tuple with SSN =
'999887777' to '987654321'.
Unacceptable, because it violates primary key and referential
integrity constraints.
26. Review of Previous Class
Relational Data Model and Relational AlgebraSahaj Computer Solutions
26
RELATIONAL MODEL CONSTRAINTS
Entity Integrity, Referential Integrity, and
Foreign Keys
UPDATE OPERATIONS AND DEALING
WITH CONSTRAINT VIOLATIONS
Insert Operation
Delete Operation
Update Operation
27. The Relational Algebra
Relational Data Model and Relational AlgebraSahaj Computer Solutions
27
The basic set of operations for the relational model is
the relational algebra.
These operations enable a user to specify basic
retrieval requests.
A sequence of relational algebra operations forms a
relational algebra expression, whose result will also
be a relation that represents the result of a database
query (or retrieval request).
28. The Relational Algebra
Relational Data Model and Relational AlgebraSahaj Computer Solutions
28
The relational algebra is very important for several
reasons.
First, it provides a formal foundation for relational
model operations.
Second, and perhaps more important, it is used as a
basis for implementing and optimizing queries in
relational database management systems (RDBMSs.
Third, some of its concepts are incorporated into the
SQL standard query language for RDBMSs.
29. The SELECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
29
The SELECT operation is used to select a subset of
the tuples from a relation that satisfy a selection
condition.
One can consider the SELECT operation to be a filter
that keeps only those tuples that satisfy a qualifying
condition.
The SELECT operation can also be visualized as a
horizontal partition.
30. The SELECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
30
For example, to select the EMPLOYEE tuples whose
department is 4, or those whose salary is greater
than $30,000, we can individually specify each of
these two conditions with a SELECT operation as
follows:
DNO=4 (EMPLOYEE)
sALARY>30000(EMPLOYEE)
31. The SELECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
31
In general, the SELECT operation is denoted by
<selection condition>(R)
where the symbol (sigma) is used to denote the SELECT
operator, and the selection condition is a Boolean expression
specified on the attributes of relation R.
For example, to select the tuples for all employees
who either work in department 4 and make over
$25,000 per year, or work in department 5 and make
over $30,000, we can specify the following SELECT
operation:
(DNO=4 AND SALARY>25000) OR (DNO=5 AND SALARY > 30000)
(EMPLOYEE)
32. The SELECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
32
The <selection condition> is applied independently
to each tuple t in R.
This is done by substituting each occurrence of an
attribute Ai in the selection condition with its value
in the tuple t[Ai].
If the condition evaluates to TRUE, then tuple t is
selected. All the selected tuples appear in the result
of the SELECT operation.
33. The SELECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
33
The Boolean conditions AND, OR, and NOT have
their normal interpretation, as follows:
(cond1 AND cond2) is TRUE if both (cond 1 ) and (cond2) are
TRUE; otherwise, it is FALSE.
(cond1 OR cond2) is TRUE if either (cond 1) or (cond2) or both
are TRUE; otherwise, it is FALSE.
(NOT cond) is TRUE if cond is FALSE; otherwise, it is FALSE.
The SELECT operator is unary; that is, it is applied to a single
relation.
34. The PROJECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
34
The PROJECT operation, on the other hand, selects
certain columns from the table and discards the
other columns.
If we are interested in only certain attributes of a
relation, we use the PROJECT operation to project
the relation over these attributes only.
The result of the PROJECT operation can hence be
visualized as a vertical partition.
35. The PROJECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
35
The general form of the PROJECT operation is :
π <attribute list> (R)
where π (pi) is the symbol used to represent the PROJECT
operation, and <attribute list> is the desired list of attributes
from the attributes of relation R.
The result of the PROJECT operation has only the attributes
specified in <attribute list> in the same order as they appear
in the list.
For example, to list each employee's first and last
name and salary, we can use the PROJECT operation
as follows:
π LNAME, FNAME, SALARY( EMPLOYEE)
36. The PROJECT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
36
If the attribute list includes only non key attributes
of R, duplicate tuples are likely to occur.
The PROJECT operation removes any duplicate
tuples, so the result of the PROJECT operation is a
set of tuples, and hence a valid relation.
This is known as duplicate elimination. For
example, consider the following PROJECT
operation:
π SEX, SALARY( EMPLOYEE)
37. Sequences of Operations and RENAME Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
37
Sometimes , we may want to apply several relational
algebra operations one after the other.
Either write the operations as a single relational
algebra expression by nesting the operations,
Or we can apply one operation at a time and create
intermediate result relations.
In the latter case, we must give names to the
relations that hold the intermediate results.
38. Sequences of Operations and RENAME
Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
38
For example, to retrieve the first name, last name, and
salary of all employees who work in department number
5, we must apply a SELECT and a PROJECT operation.
We can write a single relational algebra expression as
follows:
π FNAME, LNAME, SALARY(DNO=5 (EMPLOYEE))
Alternatively, we can explicitly show the sequence of
operations, giving a name to each intermediate relation:
DEP5_EMPSDNO=5 (EMPLOYEE)
RESULT π FNAME, LNAME, SALARY (DEP5_EMPS)
39. Sequences of Operations and RENAME
Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
39
It is often simpler to break down a complex sequence of
operations by specifying intermediate result relations
than to write a single relational algebra expression.
We can also use this technique to rename the attributes
in the intermediate and result relations.
To rename the attributes in a relation, we simply list the
new attribute names in parentheses, as in the following
example:
TEMP DNO=5 (EMPLOYEE)
R (FIRSTNAME, LASTNAME, SALARY) π FNAME, LNAME, SALARY
(TEMP)
40. Sequences of Operations and RENAME
Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
40
The general RENAME operation when applied to a
relation R of degree n is denoted by any of the
following three forms:
S(B1, B2. .... B)R) or S (R) or (B1,B2,...,Bn)(R)
where the symbol (rho) is used to denote the
RENAME operator, S is the new relation name, and
B1 , B2, •• ., Bn are the new attribute names. The first
expression renames both the relation and its
attributes, the second renames the relation only, and
the third renames the attributes only.
41. RELATIONAL ALGEBRA OPERATIONS
FROM SET THEORY
Relational Data Model and Relational AlgebraSahaj Computer Solutions
41
Several set theoretic operations are used to merge
the elements of two sets in various ways, including
UNION, INTERSECTION, and SET
DIFFERENCE (also called MINUS).
These are binary operations; that is, each is applied
to two sets (of tuples).
When these operations are adapted to relational
databases, the two relations on which any of these
three operations are applied must have the same
type of tuples; this condition has been called union
compatibility.
42. UNION, INTERSECTION &MINUS
Relational Data Model and Relational AlgebraSahaj Computer Solutions
42
Two relations R(A1, A2, ... , An) and S(B1 , B2, ... , Bn)
are said to be union compatible if they have the same
degree n and if dom(A) = dom(B) for 1≤ i ≤ n.
This means that the two relations have the same
number of attributes, and each corresponding pair of
attributes has the same domain.
43. UNION, INTERSECTION &MINUS
Relational Data Model and Relational AlgebraSahaj Computer Solutions
43
We can define the three operations
UNION, INTERSECTION, and SET DIFFERENCE
on two union-compatible relations Rand S as
follows:
UNION: The result of this operation, denoted by R U S, is a
relation that includes all tuples that are either in R or in S or in
both Rand 5. Duplicate tuples are eliminated.
INTERSECTION: The result of this operation, denoted by R
∩ S, is a relation that includes all tuples that are in both Rand
S.
SET DIFFERENCE (OR MINUS): The result of this
operation, denoted by R - S, is a relation that includes all
tuples that are in R but not in S.
44. CARTESIAN PRODUCT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
44
The CARTESIAN PRODUCT operation-also known
as CROSS PRODUCT or CROSS JOIN-which is
denoted by ×.
This is also a binary set operation, but the relations
on which it is applied do not have to be union
compatible.
This operation is used to combine tuples from two
relations in a combinatorial fashion.
In general, the result of R(A1,, A2, ... , An ) X
S(B1,B2, ... , Bm) is a relation Q with degree n + m
attributes Q(A1,A2 ... , An, B1, B2, ... , Bm), in that
order.
45. CARTESIAN PRODUCT Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
45
For example, suppose that we want to retrieve a list of
names of each female employee's dependents. We can do
this as follows:
FEMALE_EMPS SEX=' F' (EMPLOYEE)
EMPNAMESπ FNAME, LNAME, SSN (FEMALE_EMPS)
EMP_DEPENDENTSEMPNAMES X DEPENDENT
ACTUAL_DEPENDENTSSSN=ESSN
(EMP_DEPENDENTS)
RESULTπ FNAME. LNAME, DEPENDENT_LNAME
(ACTUAL_DEPENDENTS)
46. BINARY RELATIONAL OPERATIONS
Relational Data Model and Relational AlgebraSahaj Computer Solutions
46
The JOIN Operation
The JOIN operation, is used to combine related
tuples from two relations into single tuples. This
operation is very important for any relational
database with more than a single relation, because it
allows us to process relationships among relations.
47. The JOIN Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
47
To illustrate JOIN, suppose that we want to retrieve
the name of the manager of each department. To get
the manager's name, we need to combine each
department tuple with the employee tuple whose
SSN value matches the MGRSSN value in the
department tuple. We do this by using the JOIN
operation, and then projecting the result over the
necessary attributes, as follows:
48. The EQUI JOIN and NATURAL JOIN
Variations of JOIN
Relational Data Model and Relational AlgebraSahaj Computer Solutions
48
The most common use of JOIN involves join
conditions with equality comparisons only.
Such a JOIN, where the only comparison operator
used is =, is called an EQUIJOIN.
Notice that in the result of an EQUIJOIN we always
have one or more pairs of attributes that have
identical values in every tuple.
49. The EQUI JOIN and NATURAL JOIN
Variations of JOIN
Relational Data Model and Relational AlgebraSahaj Computer Solutions
49
For example the values of the attributes MGRSSN
and SSN are identical in every tuple of DEPT_MGR
query because of the equality join condition specified
on these two attributes.
Because one of each pair of attributes with identical
values is superfluous, a new operation called
NATURAL JOIN-denoted by * was created to get
rid of the second (superfluous) attribute in an
EQUIJOIN condition
50. The EQUI JOIN and NATURAL JOIN
Variations of JOIN
Relational Data Model and Relational AlgebraSahaj Computer Solutions
50
The standard definition of NATURAL JOIN requires
that the two join attributes (or each pair of join
attributes) have the same name in both relations. If
this is not the case, a renaming operation is applied
first.
In the following example, we first rename the
DNUMBER attribute of DEPARTMENT to DNUM-
so that it has the same name as the DNUM attribute
in PROJECT-and then apply NATURAL JOIN:
51. The EQUI JOIN and NATURAL JOIN
Variations of JOIN
Relational Data Model and Relational AlgebraSahaj Computer Solutions
51
The attribute DNUM is called the join attribute.
If the attributes on which the natural join is specified
already have the same names in both
relations, renaming is unnecessary.
As we can see, the JOIN operation is used to
combine data from multiple relations so that related
information can be presented in a single table.
Note that sometimes a join may be specified between
a relation and itself such operations are also known
as inner joins.
52. The Division Operator
Relational Data Model and Relational AlgebraSahaj Computer Solutions
52
The DIVISION operation, denoted by , is useful for
a special kind of query that sometimes occurs in
database applications.
An example is "Retrieve the names of employees who
work on all the projects that 'John Smith' works on."
To express this query using the DIVISION operation,
proceed as follows.
First, retrieve the list of project numbers that
'JohnSmith' works on in the intermediate relation
SMITH_PNOS:
53. The Division Operator
Relational Data Model and Relational AlgebraSahaj Computer Solutions
53
Next, create a relation that includes a tuple
<PNO, ESSN> whenever the employee whose social
security number is ESSN works on the project whose
number is PNO in the intermediate relation
SSN_PNOS:
54. The Division Operator
Relational Data Model and Relational AlgebraSahaj Computer Solutions
54
Finally, apply the DIVISION operation to the two
relations, which gives the desired employees' social
security numbers:
55. Aggregate Functions and Grouping
Relational Data Model and Relational AlgebraSahaj Computer Solutions
55
The request that cannot be expressed in the basic relational
algebra can be expressed in mathematical aggregate functions
on collections of values from the database.
Examples of such functions include retrieving the average or
total salary of all employees or the total number of employee
tuples.
These functions are used in simple statistical queries that
summarize information from the database tuples.
Common functions applied to collections of numeric values
include SUM, AVERAGE, MAXIMUM, and MINIMUM.
The COUNT function is used for counting tuples or values.
56. Aggregate Functions and Grouping
Relational Data Model and Relational AlgebraSahaj Computer Solutions
56
We can define an AGGREGATE FUNCTION
operation, using the symbol (pronounced “script
F"), to specify these types of requests as follows:
<grouping attributes> <function list> (R)
where <grouping attributes> is a list of attributes of the relation
specified in R, and <function list> is one of the allowed functions-
such as SUM, AVERAGE, MAXIMUM, MINIMUM, COUNT.
For Example: The queryget the DNO, Count of
Employees and Average salary of the employees.
57. Outer Join Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
57
The JOIN operations described earlier match tuples
that satisfy the join condition.
For example, for a NATURAL JOIN operation R *
S, only tuples from R that have matching tuples in S-
and vice versa-appear in the result.
Hence, tuples without a matching (or related) tuple
are eliminated from the JOIN result.
Tuples with null values in the join attributes are also
eliminated. This amounts to loss of information
58. Outer Join Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
58
A set of operations, called outer joins, can be used
when we want to keep all the tuples in R, or all those
in S, or all those in both relations in the result of the
JOIN, regardless of whether or not they have
matching tuples in the other relation.
This satisfies the need of queries in which tuples
from two tables are to be combined by matching
corresponding rows, but without losing any tuples
for lack of matching values.
59. Outer Join Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
59
For example, suppose that we want a list of all
employee names and also the name of the
departments they manage if they happen to manage
a department; if they do not manage any, we can so
indicate with a null value.
We can apply an operation LEFT OUTER JOIN,
denoted by, to retrieve the result as follows:
60. Outer Join Operation
Relational Data Model and Relational AlgebraSahaj Computer Solutions
60
The LEFT OUTER JOIN operation keeps every tuple in
the first, or left, relation R in R ,.S; if no matching tuple
is found in S, then the attributes of S in the join result are
filled or "padded" with null values.
A similar operation, RIGHT OUTER JOIN, denoted
by, keeps every tuple in the second, or right, relation S in
the result of R ) S.
A third operation, FULL OUTER JOIN, denoted by
keeps all tuples in both the left and the right relations
when no matching tuples are found, padding them with
null values as needed.
61. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
61
Step 1: Mapping of Regular Entity Types.
For each regular (strong) entity type E in the ER schema,
create a relation R that includes all the simple attributes of E.
Include only the simple component attributes of a composite
attribute.
Choose one of the key attributes of E as primary key for R. If
the chosen key of E is composite, the set of simple attributes
that form it will together form the primary key of R.
In our example, we create the relations EMPLOYEE,
DEPARTMENT, and PROJECT in Figure to correspond to the
regular entity types EMPLOYEE, DEPARTMENT, and
PROJECT
62. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
62
63. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
63
The foreign key and relationship attributes, if any, are
not included yet; they will be added during subsequent
steps.
These include the attributes SUPERSSN and DNO of
EMPLOYEE, MGRSSN and MGRSTARTDATE of
DEPARTMENT, and DNUM of PROJECT.
In our example, we choose SSN, DNUMBER, and
PNUMBER as primary keys for the relations
EMPLOYEE, DEPARTMENT, and PROJECT.
The relations that are created from the mapping of entity
types are sometimes called entity relations because each
tuple (row) represents an entity instance.
64. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
64
Step 2: Mapping of Weak Entity Types:
For each weak entity type W in the ER schema with
owner entity type E, create a relation R and include
all simple attributes of W, as attributes of R.
In addition, include the primary key attribute that
correspond to the owner entity type(s) as foreign key
attributes of R; this takes care of the identifying
relationship type of W .
The primary key of R is the combination of the
primary key(s) of the owner(s) and the partial key of
the weak entity type W, if any.
65. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
65
In our example, we create the relation DEPENDENT
in this step to correspond to the weak entity type
DEPENDENT.
We include the primary key SSN of the EMPLOYEE
relation-which corresponds to the owner entity type-
as a foreign key attribute of DEPENDENT; we
renamed it ESSN, although this is not necessary.
The primary key of the DEPENDENT relation is the
combination {ESSN, DEPENDENT_NAME} because
DEPENDENT_NAME is the partial key of
DEPENDENT.
66. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
66
Step 3: Mapping of Binary 1:1 Relationship
Types.
For each binary 1:1 relationship type R in the ER
schema, identify the relations S and T that
correspond to the entity types participating in R.
There are three possible approaches:
(1) the foreign key approach,
(2) the merged relationship approach, and
(3) the cross-reference or relationship relation approach.
67. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
67
Foreign key approach:
Choose one of the relations-S, and include as a foreign key in S
the primary key of T.
It is better to choose an entity type with total participation in
R in the role of S.
Include all the simple attributes (or simple components of
composite attributes) of the 1:1 relationship type R as
attributes of S.
68. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
68
Merged relation option:
An alternative mapping of a 1:1 relationship type is possible by
merging the two entity types and the relationship into a single
relation.
This may be appropriate when both participations are total.
69. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
69
Cross-reference or relationship relation
option:
The third alternative is to set up a third relation R for the
purpose of cross-referencing the primary keys of the two
relations Sand T representing the entity types.
This approach is required for binary M:N relationships.
The relation R is called a relationship relation, (or sometimes a
lookup table), because each tuple in R represents a
relationship instance that relates one tuple from S with one
tuple of T.
70. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
70
Step 4: Mapping of Binary 1: N Relationship
Types:
For each reguar binary 1:N relationship type R, identify the
relation S that represents the participating entity type at the N-
side of the relationship type.
Include as foreign key in S the primary key of the relation T
that represents the other entity type participating in R.
This is done because each entity instance on the N-side is
related to at most one entity instance on the 1-side of the
relationship type.
Include any simple attributes of the 1:N relationship type as
attributes of S.
71. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
71
In our example, we now map the 1:N relationship types
WORKS_FOR, CONTROLS, and SUPERVISION from
Figure A.
For WORKS_FOR we include the primary key
DNUMBER of the DEPARTMENT relation as foreign key
in the EMPLOYEE relation and call it DNO.
For SUPERVISION we include the primary key of the
EMPLOYEE relation as foreign key in the EMPLOYEE
relation itself because the relationship is recursive-and
call it SUPERSSN.
The CONTROLS relationship is mapped to the foreign
key attribute DNUM of PROJECT, which references the
primary key DNUMBER of the DEPARTMENT relation.
72. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
72
Step 5: Mapping of Binary M:N Relationship Types:
For each binary M:N relationship type R, create a new relation
S to represent R.
Include as foreign key attributes in S the primary keys of the
relations that represent the participating entity types; their
combination will form the primary key of S.
Also include any simple attributes of the M:N relationship
type (or simple components of composite attributes) as
attributes of S.
Notice that we cannot represent an M:N relationship type by a
single foreign key attribute in one of the participating
relations (as we did for 1:1 or I:N relationship types) because
of the M:N cardinality ratio; we must create a separate
relationship relation S.
73. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
73
In our example, we map the M:N relationship type
WORKS_ON from Figure A by creating the relation
WORKS_ON in Figure B.
We include the primary keys of the PROJECT and
EMPLOYEE relations as foreign keys in WORKS_ON
and rename them PNO and ESSN, respectively.
We also include an attribute HOURS in WORKS_ON to
represent the HOURS attribute of the relationship type.
The primary key of the WORKS_ON relation is the
combination of the foreign key attributes {ESSN, PNO}.
74. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
74
Step 6: Mapping of Multivalued Attributes:
For each multivalued attribute A, create a new
relation R.
This relation R will include an attribute
corresponding to A, plus the primary key attribute K-
as a foreign key in R-of the relation that represents
the entity type or relationship type that has A as an
attribute.
The primary key of R is the combination of A and K.
If the multivalued attribute is composite, we include
its simple components.
75. RELATIONAL DATABASE DESIGN USING
ER-TO-RELATIONAL MAPPING
Relational Data Model and Relational AlgebraSahaj Computer Solutions
75
In our example, we create a relation
DEPT_LOCATIONS.
The attribute DLOCATION represents the
multivalued attribute LOCATIONS of
DEPARTMENT, while DNUMBER-as foreign
keyrepresents the primary key of the
DEPARTMENT relation.
The primary key of DEPT_LOCATIONS is the
combination of {DNUMBER, DLOCATION}.
A separate tuple will exist in DEPT_LOCATIONS for
each location that a department has.