BUAN6320 - Chapter - 1-4 & 9
BUAN6320 - Chapter - 1-4 & 9
5
Learning Objectives
• After completing this chapter, you will be able to:
• Describe the main extended entity relationship (EER) model constructs and
how they are represented in ERDs and EERDs
• Use entity clusters to represent multiple entities and relationships in an entity
relationship diagram (ERD)
• Describe the characteristics of good primary keys and how to select them
• Apply flexible solutions for special data-modeling cases
6
The Extended Entity Relationship Model
(EERM)
• Enhanced entity relationship model
• Result of adding more semantic constructs to the original entity
relationship (ER) model like Inheritance, clustering, supertype -subtype
• EER diagrams (EERDs) use the EER model
7
Entity Supertypes and Subtypes
• Entity supertype (-employee) Parent
• Generic entity type related to one or more entity subtypes
• Contains common characteristics
Child
• Entity subtype (-pilot)
• Contains unique characteristics of each entity subtype
• Criteria to determine usage (must meet with both criteria)
• There must be different, identifiable kinds of the entity in the user’s
environment
• The different kinds of instances should each have one or more attributes that
are unique to that kind of instance
8
Inheritance
Enables an entity subtype to inherit attributes and relationships of the
supertype
9
Specialization Hierarchy (1 of 2)
• Entity supertypes and subtypes are organized in a specialization hierarchy
• Depicts arrangement of higher-level entity supertypes and lower-level entity
subtypes
• Relationships are described in terms of “is-a” relationships (1:1)
• Subtype exists within the context of a supertype
• Every subtype has one supertype to which it is directly related
• Supertype can have many subtypes
10
Specialization Hierarchy (2 of 2)
11
Subtype Discriminator / Completeness Constraint
• Nothing but it is another attribute for supertype entities.
• Default comparison condition is the equality comparison
• In some situations the subtype discriminator is not necessarily
based on an equality comparison
Partial >can be null / Complete > no null
Disjoint> must have unique / Overlapping > not unique
d o d o
13
Example;
Person Person
d o
14
Specialization and Generalization
• Specialization
• Top-down process
• Identifies lower-level, more specific entity
subtypes from a higher-level entity supertype
• Based on grouping unique characteristics and
relationships of the subtypes
• Generalization
• Bottom-up process
• Identifies a higher-level, more generic entity
supertype from lower-level entity subtypes
• Based on grouping common characteristics and
relationships of the subtypes
15
Entity Clustering
• “Virtual” entity type used to represent multiple entities and relationships
in ERD
• Formed by combining multiple interrelated entities into a single, abstract entity
object
• More conceptual.. ( Simplifying).. No Attributes, no relationship, PK,FK.
16
Entity Integrity: Selecting Primary Keys
• Primary keys: single attribute or a combination of attributes
• Uniquely identifies each entity instance
• Guarantees entity integrity
• Works with foreign keys to implement relationships
Natural Keys and Primary
Keys
• Natural key or natural identifier:
• Something unique have/has.
• Perfect candidate for primary key selection/modelling.
17
Primary Key Guidelines
• Unique and can’t be null
• No change over time : must be static (not like LastName only)
• Preferably single-attribute : desired but not required
• Preferably numeric : Sorting /incrementing is more easy
• Security-compliant : not composed with security risked attribute( SSN)
• Non intelligent :Should not be another meaning ,must be descriptive and
uniquely identify each entity instance.
18
When to Use Composite Primary Keys (CPK)
They are typically seen in associative entity tables or weak entity tables
20
Design Case 1:Implementing 1:1 Relationships
• Foreign keys work with primary keys to properly implement relationships
in relational model
• Place primary key of the parent entity on the dependent entity as foreign key
One side is mandatory and the Place the PK of the entity on the mandatory
other side side in the entity on the optional side as a FK,
and make the FK mandatory
Both sides are Select the FK that causes the fewest nulls, or
optional or mandatory more simple ( fallow the primary key guide as
much as you can)
21
Design Case 2: Maintaining History of Time-Variant Data
• Time-variant data: data whose values
change over time and for which a
history of the data changes must be
retained
• Requires creating a new entity in a 1:M
relationship with the original entity
• New entity contains the new value, date of
the change, and any other pertinent
attribute
22
Design Case 3: Fan Traps
• Design traps: occurs when a relationship is improperly or incompletely
identified
• Fan trap
• Loopbacks
• Chasm trap
• Fan trap: occurs when one entity is in two 1:M relationships to other entities
fan trap solution
23
Design Case 3: Fan Traps (example from book)
24
Design Case 4: Redundant Relationships
• Occur when there are multiple relationship paths between related entities
• Must remain consistent across the model
• Help simplify the design
25
Questions ?
26
SQL Databases
• Business intelligence:
• Captures and processes business data to generate information that support
decision making
Types of Databases (2 of 5)
• Classification by user ;
• Single-user database: supports one user at a time
• Desktop database: single-user database on a personal computer
• Multiuser database: supports multiple users at the same time
• Workgroup databases: supports a small number of users or a specific department
• Enterprise database: supports many users across many departments
• Classification by location
• Centralized database: data located at a single site
• Distributed database: data distributed across different sites
• Cloud database: created and maintained using cloud data services that
provide defined performance measures for the database
Types of Databases (3 of 5)
• Hierarchical databases.
• Network databases.
• Relational databases.
• Object-oriented databases
Types of Databases (5 of 5)
Practical significance of data dependence is the difference between logical and physical phase.
Data Redundancy
• Unnecessarily storing the same data at different places
• Islands of information (i.e., scattered data locations)
• Increases the probability of having different versions of the same data
• Hardware
• Software
• People
• Procedures
• Data
DBMS Functions (1 of 2)
• Data dictionary management
• Data dictionary: stores definitions of data elements and their relationships
• Data storage management
• Performance tuning ensures efficient performance
• Data transformation and presentation
• Data is formatted to conform to logical expectations
• Security management
• Enforces user security and data privacy
• Multiuser access control
• Sophisticated algorithms ensure that multiple users can access the
database concurrently without compromising its integrity
DBMS Functions (2 of 2)
• Backup and recovery management
• Enables recovery of the database after a failure
• Data integrity management
• Minimizes redundancy and maximizes consistency
• Database access languages and application programming interfaces
• Query language: lets the user specify what must be done without having to
specify how
• Structured Query Language (SQL): de facto query language and data access
standard supported by the majority of DBMS vendors
• Database communication interfaces
• Accept end-user requests via multiple, different network environments
Disadvantages of database systems
• Increased costs
• Management complexity
• Maintaining currency
• Vendor dependence
• Frequent upgrade/replacement cycles
Why Database Design Is Important
• Focuses on design of database structure that will be used to store and
manage end-user data
• Well-designed database: facilitates data management and generates accurate
and valuable information
• Poorly designed database: causes difficult-to-trace errors that may lead to
poor decision making
Data Anomalies (1 of 3)
• Anomalies can occur in poorly planned or un-normalized databases
Can this information about the new course be entered (inserted) into the table COURSE in its
present form?
COURSE# SECTION# C_NAME
ITSS564 072 Database Design
ITSS564 073 Database Design
MIS570 072 Oracle Forms
ITSS564 074 Database Design
Data Anomalies (2 of 3)
Deletion anomalies (certain attributes are lost because of the deletion of other attributes)
• Example : Suppose not enough students enrolled for the course MIS570 which had only one
section 072. So, the school decided to drop this section and delete the section# 072 for
MIS570 from the table COURSE. But then, what other relevant info also got deleted in the
process?
Database Manage and maintain DBMS and Database fundamentals, SQL, vendor courses
Administrator databases
Database Analyst Develop databases for decision support QL, query optimization, data warehouses
reporting
Database Architect Design and implementation of database DBMS fundamentals, data modeling, SQL,
environments (conceptual, logical, and hardware knowledge, etc.
physical)
Database Consultant Help companies leverage database Database fundamentals, data modeling,
technologies to improve business database design, SQL, DBMS, hardware,
processes and achieve specific goals vendor-specific technologies, etc.
Database Security Implement security policies for data DBMS fundamentals, database administration,
Officer administration SQL, data security technologies, etc.
Cloud Computing Design and implement the infrastructure Internet technologies, cloud storage
Data Architect for next-generation cloud database technologies, data security, performance
systems tuning, large databases, etc.
Data Scientist Analyze large amounts of varied data to Data analysis, statistics, advanced
generate insights, relationships, and mathematics, SQL, programming, data mining,
predictable behaviors machine learning, data visualization
Questions ?
Learning Objectives
• After completing this chapter, you will be able to:
• Discuss data modeling and why data models are important
• Describe the basic data-modeling building blocks
• Define what business rules are and how they influence database design
• Understand how the major data models evolved
• List emerging alternative data models and the needs they fulfill
• Explain how data models can be classified by their level of abstraction
Chapter 2 – Data Models
Chapter 9 -Database Design
Data Modeling and Data Models
• Facilitates communication
• Gives various views of the database
• Organizes data for various users
• Provides an abstraction for the creation of good a database
Business Rules
• Brief, precise, and unambiguous description of a policy, procedure, or
principle
• Create and enforce actions within that organization’s environment
• Proper identification of, Relationships, Attributes ,Constraints and Entities
Discovering Business Rules (1 of 2)
• Sources of business rules
• Company managers
• Policy makers
• Department managers
• Written documentation
• Direct interviews with end users & costumers
• Each applicant can submit one or more applications (one application per year for multiple
years).
• Each application is submitted by only one applicant.
Hierarchical and Network Models
• Hierarchical models: developed to manage large amounts of data for
complex manufacturing projects
• Represented by an upside-down tree which contains segments
• Segments are the equivalent of a file system’s record type
• Depicts a set of one-to-many (1:M) relationships
• The network model allows more than one parent and support (M:M) relationship
Schema
Hierarchical Model
• Advantages
• Promotes data sharing
• Parent/child relationship promotes conceptual simplicity and data integrity
• Database security is provided and enforced by DBMS
• Efficient with 1:M relationships
• Disadvantages
• Requires knowledge of physical data storage characteristics
• Navigational system requires knowledge of hierarchical path
• Changes in structure require changes in all application programs
• Implementation limitations
• No data definition
• Lack of standards
Network Model
• Advantages
• Conceptual simplicity
• Handles more relationship types
• Data access is flexible
• Data owner/member relationship promotes data integrity
• Conformance to standards
• Includes data definition language (DDL) and data manipulation language (DML)
• Disadvantages
• System complexity limits efficiency
• Navigational system yields complex implementation, application development, and
management
• Structural changes require changes in all application programs
The Relational Model
• Relational database management system (RDBMS)
• Performs basic functions provided by the hierarchical and network DBMS
systems
• Makes the relational data model easier to understand and implement
• Hides the complexities of the relational model from the user
• Relation Types; One to one (1:1) , One to many (1:M) many to many (M:N)
Data Model Basic Building Blocks
• Entity: person, place, thing, or event about which data will be collected and stored
• Attribute: characteristic of an entity
• Relationship: association among entities
• One-to-many (1:M OR 1..*)
• Many-to-many (M:N or *..*)
• One-to-one (1:1 OR 1..1)
• Constraint: restriction placed on data
• Ensures data integrity
Naming Conventions
• Entity name requirements
• Be descriptive of the objects in the business environment
• Use terminology that is familiar to the users
• Attribute name
• Required to be descriptive of the data represented by the attribute
• Proper naming
• Facilitates communication between parties
• Promotes self-documentation
• NoSQL databases
• Not based on the relational model
• Support distributed database architectures
• Provide high scalability, high availability, and fault tolerance
• Support large amounts of sparse data
• Geared toward performance rather than transaction consistency
• Provides a broad umbrella for data storage and manipulation
NoSQL
• Advantages
• High scalability, availability, and fault tolerance are provided
• Uses low-cost commodity hardware
• Supports Big Data
• Key-value model improves storage efficiency
• Disadvantages
• Complex programming is required
• There is no relationship support
• There is no transaction integrity support
• In terms of data consistency, it provides an eventually consistent model
Data Modeling & Database Modeling
• Data modeling ( a process )
• Conceptual
• Logical
• Physical
Conceptual Design
Logical Design
Physical Design
(1 of 6)
Conceptual Design
• Easy to understand
• Simple boxes ,lines and text
• Easy to enhanced
• Highly abstract –no details
• Describes main data entities, attributes,
relationships, and constrains
• Translation from business requirements
• Most likely you will have multiple version.
(3 of 6)
Conceptual Design
• Goal: Collect all data and requirements from different sources and
make sure all business process and their needs understood correctly
• Goal: finalize all tests, compare with proposed system &needs and confirm with all stakeholders
most of the time this is last step for Conceptual design stage
• Goal: this not required but performance standing point you may need to do if your DB requires very
fast response specially geographically dispersed demands
Some question before to decide any distributed DB:
teaches teaches
(4 of 9)
logical Design
Map the conceptual model to logical model
Step1 components
teaches teaches
(6 of 9)
logical Design
Map the conceptual model to logical model
Step1 components
• Our example doesn’t have any super type or sub type
therefore we skipped that step we also mapped
Ste Activity almost all entitles but “Course “ which it has binary
p Relationship
1 Map strong entities
2 Map supertype/subtype relationships
3 Map weak entities
fills
4 Map binary relationships
5 Map higher-degree relationships
has
has
teaches teaches
(7 of 9)
logical Design
• Goal: Final data control step make sure all data redundant and normalized
during to mapping you may add/remove some of the attributes.
• Goal: Make sure all defined constrains are in place and they are
working correctly
This is last step for logical design and we still are independent from Hardware.
Physical Design
• Volume of data to be used and data usage pattern are very important
Centralized vs distributed on
• Define data storage organization promises vs cloud ,indexes and
Step1 Views
Users , groups , security settings
• Define integrity and security measures
Step2 and assignments
Performance metrics ,read ,
• Determine performance measures write speed ,caching
Step3 Fine-tuning
Database Design Strategies
• Top-down design starts by identifying the data sets and then defines the data elements
for each of those sets
• Involves the identification of different entity types and the definition of each
entity’s attributes
• Bottom-up design first identifies the data elements (items) and then groups them
together in data sets
• First defines attributes, and then groups them to form entities
Centralized versus Decentralized Design
• Centralized design: process by which all
database design decisions are carried out
centrally by a small group of people
• Suitable in a top-down design approach
when the problem domain is relatively small,
as in a single unit or department in an
organization
Questions ?
Chapter 4 – Entity Relationship (ER)
Modeling
115
Learning Objectives
• After completing this chapter, you will be able to:
• Identify the main characteristics of entity relationship components
• Describe how relationships between entities are defined, refined, and
incorporated into the database design process
• See how ERD components affect database design and implementation
• Understand that real-world database design often requires the reconciliation
of conflicting goals
116
The Entity Relationship Model (ERM)
• Forms the basis of an entity relationship diagram (ERD)
• Conceptual database as viewed by end user
117
Database Components
• Database’s main components
1. Entities
2. Relationships
3. Attributes
4. Keys (PK,FK , etc..)
5. Cardinality
6. Existence Dependence
7. Relationship Strength
8. Relationship Participation
9. Relationship Degree
10.Associative (Composite) Entities
118
1.Entities (1 of 2)
Entity :“things” is any object , place , person, product etc. that you want to track
/store in database. ( think like it is container or template)
• Refers to the entity set and not to a single entity occurrence
• ERM corresponds to a table—not to a row—in the relational environment
• ERM refers to a table row as an entity instance or entity occurrence
• In Chen, Crow’s Foot, and UML notations, an entity is represented by a
rectangle that contains the entity’s name
• The entity name, a noun, is usually written in all capital letters
Entity Name
Entity Attributes
119
1.Entities (2 of 2)
Entity : “things” or any object , place , person, product etc. (representation of class )
Entity Instance : singe occurrence of an entity
•Most variations SQL are not case sensitive however name convention should be consistent
Entity
Instances
120
2.Relationships
• Relationship illustrate the association between two entities and the entities
that participle in a relationship are called “participants”.
• They are presented as straight line and operates both direction.
• Usually relationship has a name expressed as a verb and written on the
relationship line
Works
fills
Teaches
121
3.Attributes (1 of 3)
• Characteristics of attributes
122
3.Attributes (2 of 3)
• Characteristics of attributes
• Identifier(Primary Keys): one or more attributes that uniquely identify each entity
instance
• SSN , LastName + EmailAddress , LastName + BirthDate , can be atomic or composite
• Key attributes are underlined in the table structure.
• StudentTable(Lastname , FistName, SSN, PhoneNumber , etc…)
• Composite identifier: primary key composed of more than one attribute that can be
subdivided to yield additional attributes
• Simple attribute: (Atomic) attribute that cannot be subdivided
123
3.Attributes (3 of 3)
• Single vs Multivalued attributes
• Single-valued attribute:attribute that has only a single value
• RoomNumber , CostumerId etc. Keep in mind that a single-valued attribute is not
necessarily a simple attribute.
• Multivalued attributes: attributes that have many values
• Hobbies ,PhoneNumbers etc..
• Derived vs Stored Attributes
• Derived Attribute : Attributes derived (computed) from other stored
attribute. For example age from Date of Birth and Today’s date.
• Stored Attribute : An attribute, which cannot be derived from other attribute,
is known as stored attribute. For example, BirthDate of employee
• Complex Attributes : composite + multivalued attributes = complex attributes. ( multiple address ,
multiple phone number with area codes etc..)
124
4.Keys
• Keys are very important part of Relational database model. They are
used to establish and identify relationships between tables and also
to uniquely identify any record or row of data inside a table.
• Primary Key (PK)
• Foreign Key (FK)
125
5.Connectivity and Cardinality
• Connectivity: noting but relationship classification
• Include 1:1, 1:M, and M:N
• Cardinality: expresses the minimum and maximum number of entity
occurrences associated (or linked ) to the number of occurrence in other entity
• In the ERD, cardinality is indicated by placing the appropriate numbers beside the
entities, using the format (x, y)
• In general ; As cardinality is the maximum number of connections between table rows
(either one or many), modality is the least number of row connections! Modality also
only has two options, 0 being the least or 1 being the least.
126
5.Connectivity and Cardinality
Example Max 1 Max M
Connectivity : either 1:1 or 1:M depends constrains Min 1 Min 1
127
6.Existence Dependence (1 of 2)
• Existence dependence
• Entity exists in the database only when it is associated with another related
entity occurrence
• Referred to as a weak entity
• Has a primary key that is partially or totally derived from parent entity in
the relationship
weak
128
6.Existence Dependence (2 of 2)
• Existence independence
• Entity exists apart from all of its related entities
• Referred to as a strong entity or regular entity
129
7.Relationship Strength
• Weak (non-identifying) relationship
• It cannot exist without the entity which it has a relationship
• Primary key of the related entity does not contain a primary key component of the
parent entity
• Strong (identifying) relationships
• Primary key of the related entity contains a primary key component of the parent
entity
130
8.Relationship Participation
• Optional participation (min. cardinality is 0)
• Any instance of one entity might participate in a relationship with another entity, but
this is not compulsory
• Mandatory participation (min. cardinality is 1)
• At least one instance of one entity must participate in a relationship with another entity
131
Relationship Degree
• Indicates the number of entities or participants
associated with a relationship
• Unary relationship: association is
maintained within a single entity
• Recursive relationship: relationship exists
within a single entity type
132
Example
Vehicle Relationship Manufacturing Division
• Corolla
• Camry • Compaq Car
• Rav4 • SUV
• C-HR • Jeep
• Prius Built • Van
• Yaris • Truck
• Highlander • Hybrid
• 4Runner • Maintenance
• Sienna • Logistic Support
• Tacoma
• Tundra
133
Example •
•
134
•
•
Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
135
•
•
Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
136
•
•
Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
137
•
•
Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
140
•
•
Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
142
The Entity Relationship Model
143
Crow’s Foot Notation Example
144
Chen Notation
145
Source :Wikipedia 146
•
•
Let’s call our example for Crow’s foot
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •
(min,max) (min,max)
(0,M) (1,1) 147
Associative (Composite) Entities
• Used to represent an M:N relationship between two or more entities
• Has a 1:M relationship with the parent entities
• Composed of the primary key attributes of each parent entity
• May also contain additional attributes that play no role in connective process
M N
c
1 M M 1
148
Database Design Challenges: Conflicting Goals
• Database designers must often make design compromises that are triggered by
conflicting goals
• Fallow the design standards and best practices.
• High processing speed may limit the number and complexity of logically desirable relationships
• Maximum information generation may lead to loss of clean design structures and high
transaction speed
• Best practices.
• Prevent bad data from being entered into tables of interest.
• Enforce business logic at the database-level.
• Documentation of important database rules.
• Enforce relational integrity between any number of tables.
• Improve database performance.
• Enforce uniqueness.
149
Developing an ER Diagram-Example (1/4)
• Activities involved in building and ERD
1. Create a detailed narrative of the organization’s description of operations
2. Identify business rules based on the descriptions
3. Identify main entities and relationships from the business rules
4. Develop the initial ERD
5. Identify the attributes and primary keys that adequately describe entities
6. Revise and review ERD
150
Did you finalize your ERD?
151
Developing an ER Diagram-Example (2/4)
Task 1.Create a detailed narrative of the organization’s description of operations
• We have small training center and we teach number of topics. We have staff and
teachers who works in 5 classrooms every night.
152
Developing an ER Diagram-Example (3/4)
Task3 :Identify main entities and relationships from the business rules
• Easy to understand
• Simple boxes ,lines and text
• Easy to enhanced
• Highly abstract –no details
Task4 :Develop the initial ERD
• Only “Entities” visible [tables]
• Translation from business You are in
requirements Conceptual Data Modeling Stage..
Developing an ER Diagram-Example (4/4)
Task5 :Identify the attributes and primary keys that adequately describe entities
Task6: Revise and review ERD
• Enhanced from conceptual model
• Add attributes for each entity
You are in
• Add Relationships
Logical Data Modeling stage..
• Add Cardinalates
• Decide Key attributes
• Primary keys
• Foreign Keys
• Still generic not pointing to any specific database.
register teach
Questions ?
155
Chapter 3 – The Relational Database Model
156
Engin Calisir University of Texas at Dallas
Learning Objectives
• After completing this chapter, you will be able to:
• Describe the relational database model’s logical structure
• Identify the relational model’s basic components and explain the structure,
contents, and characteristics of a relational table
• Use relational database operators to manipulate relational table contents
• Explain the purpose and components of the data dictionary and system
catalog
• Identify appropriate entities and then the relationships among the entities in
the relational database model
• Describe how data redundancy is handled in the relational database model
• Explain the purpose of indexing in a relational database
157
A Logical View of Data
• Relational database model enables logical representation of the data and its relationships
• Logical simplicity yields simple and effective database design methodologies
• The logical view is facilitated by the creation of data relationships based on a logical construct called a
relation
• No worries about hardware requirements at this stage
Example of 1:M
Example of 1:1
fills teaches
158
Tables and Their Characteristics
1 A table is perceived as a two-dimensional structure
composed of rows and columns.
159
Types of Keys (1/2)
• Keys consist of one or more attributes that determine other attributes
• Ensure that each row in a table is uniquely identifiable
• Establish relationships among tables and to ensure the integrity of the data
• Superkey: key that can uniquely identify any row in the table ( it can be one or more
attributes)
• Primary key (PK) is a super key
• ID or ID+SensorID ID SensorID Time Value
1 3 10 14.3
2 2 16 124
3 1 40 3
• Candidate key: minimal super key 4 3 70 14.4
• ID 5 1 100 8
• How about “Time” ? 6 2 116 186
• How about PK ?
160
Types of Keys (2/2)
• Simple Key :LastName or FirstName or ID
• Composite key: key that is composed of more than one attribute
• LastName+FirstName+StudentID or ID+SensorID etc..
• Compound key : more than one simple key’s combination
• StudentID+StudentEmail or StudentID+CourseID ;
• Difference between composite and component keys ;
• if CourceID is combination of more then one attribution then StudentID+CourseID became a
CompositeID
• Some DB vendors use both word is interchangeable
• Foreign key: primary key of one table that has been placed into another table to create a common
attribute
• Secondary key: key used strictly for data retrieval purposes
• Secondary key is another candidate key that is not selected as a PK.
161
Dependencies
• Determination
• State in which knowing the value of one attribute makes it possible to determine the value of
another
• Establishes the role of a key
• Based on the relationships among the attributes
• Functional dependence: value of one or more attributes determines the value of one or more
other attributes
• Determinant: attribute whose value determines another
• Dependent: attribute whose value is determined by the other attribute
• Full functional dependence: entire collection of attributes in the determinant is necessary for the
relationship <perhaps for OODB? >
162
Database Integrity
• Entity integrity: condition in which each row in the table has its own unique
identity
• All of the values in the primary key must be unique
• No key attribute in the primary key can contain a null
163
Integrity Rules
• Ways to handle nulls
• Flags
• Special codes used to indicate the absence of some value
• Constraints
• NOT NULL constraint: placed on a column to ensure that every row in the table has a value for
that column
• UNIQUE constraint: restriction placed on a column to ensure that no duplicate values exist for
that column
164
What is null ?
• Null: absence of any data value
• Unknown attribute value, known but missing attribute value, or inapplicable condition
• Ways to handle nulls
• Flags
• Special codes used to indicate the absence of some value
• Constraints
• NOT NULL constraint: placed on a column to ensure that every row in the table has a
value for that column
• UNIQUE constraint: restriction placed on a column to ensure that no duplicate values
exist for that column
165
Relational Algebra
• Theoretical way of manipulating table contents using relational operators
• Relational algebra is a procedural query language, which takes instances of
relations as input and yields instances of relations as output.
• It uses operators to perform queries.
• An operator can be either unary or binary.
• They accept relations as their input and yield relations as their output
166
Relational Set Operators (1 of 13)
• Select (Restrict) Single Table (Unary Operations)
• Project
167
Relational Set Operators (2 of 13)
168
Relational Set Operators (3 of 13)
• SELECT (Restrict)
• Unary operator that yields a horizontal subset of a table
• Only one table is a “input”
• Output is always subset of input table
• SELECT ( Condition) FROM Table;
Select ;
ID SensorID Time Value Select Time < 100 ID SensorID Time Value
•
1 3 10 14.3
Horizontal
1 3 10 14.3
2 2 16 124 • No limit
2 2 16 124
3 1 40 3
3 1 40 3
Select ID = 1 4 3 70 14.4
4 3 70 14.4
5 1 100 8 ID SensorID Time Value
6 2 116 186 1 3 10 14.3
169
Relational Set Operators (4 of 13)
Unary Operators Example
PROJECT
Project ; SensorID
3
ID SensorID Time Value Project SensorID 2
1 3 10 14.3 1
2 2 16 124 3
3 1 40 3 1 • Vertical
2 •
4 3 70 14.4 Time Value No limit
5 1 100 8 10 14.3
6 2 116 186 16 124
Project Time and Value 40 3
70 14.4
100 8
116 186
170
Relational Set Operators (5 of 13)
• UNION
• Combines all rows from two tables, excluding duplicate rows
• Union-compatible: tables share the same number of columns, and their corresponding
columns share compatible domains
• No conditions
SELECT column_name(s) FROM table1
UNION
SELECT column_name(s) FROM table2;
171
Relational Set Operators (6 of 13)
• Full Outer Join
• Specifies a row from either left or right table
• Union-compatible: tables share the same number of columns, and their
corresponding columns share compatible domains
SELECT * FROM table_A
FULL OUTER JOIN table_B
ON table_A.A=table_B.A;
172
What we learned so far
173
Relational Set Operators (7 of 13)
• Equijoin
• The SQL EQUI JOIN is a simple SQL join uses the equal sign(=) as the comparison operator for
the condition.
• It has two types - SQL Outer join and SQL Inner join
• Theta ( non-Equijoin)
• The SQL NON EQUI JOIN is a join uses comparison operator other than the equal sign like >, <,
>=, <= with the condition
175
Relational Set Operators (9 of 13)
176
Relational Set Operators (10 of 13)
• Natural Join
• It is similar like equijoin based on table level and all columns names and type must be same in both
tables .Repeated columns and rows are avoided.
• SQL use mostly inner join form with SELECT statement based on (ON predicate) columns -Eliminate
duplicated rows not columns
177
Relational Set Operators (11 of 13)
• PRODUCT
• Yields all possible pairs of rows from two tables
• Cartesian or Cross Joins ( advanced class topic)
• DIVIDE
• Yields all rows in one table that are not found in the other table
• Tables must be union-compatible to yield valid results .
• SQL does not use DIVIDE relational operator in real life instead SQL use
either sub-query or “where …except “ type logical implication.
• Example :
SELECT * FROM suppliers as s
WHERE NOT EXISTS (( SELECT p.pid FROM parts as p )
EXCEPT
(SELECT sp.pid FROM supplies sp WHERE sp.sid = s.sid ) );
178
Relational Set Operators (12 of 13)
• DIFFERENCE
• It is Minus operator and Oracle use “MINUS” and SQL use “EXCEPT” command not “-”
• Yields all rows in one table that are not found in the second table.
179
Relational Set Operators (13 of 13)
180
What we learned so far
Select (Restrict) Single Table (Unary Operations)
Project
181
Confused ?
182
Data Dictionary /System Catalog
• Description of all tables, views etc., in the database created by the user and
designer ,it is vital for DB.
183
Microsoft System Catalog
• https://docs.microsoft.com/en-us/sql/relational-databases/system-catalo
g-views/querying-the-sql-server-system-catalog-faq?view=sql-server-201
7
• Use generally ;
• Documentation
• Communicate with other users/programs about a common meaning of elements
• Troubleshooting
• One-to-None
• Single tables with no relationship with anyone.
• Log tables, some security tables etc..
185
Relationships within the Relational Database (2 of 4)
One-to-many (1:M) ;Most common norm for relational databases
186
Relationships within the Relational Database (3 of 4)
One-to-one (1:1)
One entity can be related to only one other entity and vice versa , this kind of relationship is very
rare
187
Relationships within the Relational Database (4 of 4)
Many-to-many (M:N)
189
Codd’s Relational Database Rules (1 of 2)
Rule Rule Name Description
1 Information All information in a relational database must be logically represented as column values in rows within
tables.
2 Guaranteed access Every value in a table is guaranteed to be accessible through a combination of table name, primary key
value, and column name.
3 Systematic treatment of nulls Nulls must be represented/supported and treated in a systematic way, independent of data type.
4 Dynamic online catalog based The metadata must be stored and managed as ordinary data—that is, in tables within the database; such
on the relational model data must be available to authorized users using the standard database relational language.
Data Dictionary/catalog must exist.
5 Comprehensive data The relational database may support many languages; however, it must
sublanguage support one well-defined, declarative language as well as data definition,
view definition, data manipulation (interactive and by program), integrity
constraints, authorization, and transaction management (begin, commit,
and rollback).it is SQL
6 View updating Any view that is theoretically updatable must be updatable through the
system. Logical view tables must be update according to system.
7 High-level insert, update, and The database must support set-level inserts, updates, and deletes.
delete
190
Codd’s Relational Database Rules (2 of 2)
Rule Rule Name Description
8 Physical data independence Application programs and ad hoc facilities are logically unaffected when physical access methods
or storage structures are changed.
9 Logical data independence Application programs and ad hoc facilities are logically unaffected when changes are made to the
table structures that preserve the original table values (changing order of columns or inserting
columns).
10 Integrity independence All relational integrity constraints must be definable in the relational language and stored in the
system catalog, not at the application level.
11 Distribution independence The end users and application programs are unaware of and unaffected by the data location
(distributed vs. local databases).
12 Nonsubversion If the system supports low-level access to the data, users must not be allowed to bypass the
integrity rules of the database. SQL is hig-level database query language.
13 Rule zero /Foundation Rule relational database management system must be able to use the relational model functionalities
to organize, store, retrieve and manipulate the data.