Database Fundamentals
Database Fundamentals
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 1
What is a Database?
General: A database is any collection of related data. Restrictive: A database is a persistent, logically coherent collection of inherently meaningful data, relevant to some aspects of the real world.
The portion of the real world relevant to the database is sometimes referred to as the universe of discourse or as the database miniworld. Whatever it is called, it must be well understood by the designers of the database.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 2
External View 1
External View n
Conceptual Schema
Internal Schema
Physical Database
1994, 1995 Robert Robbins Database Fundamentals: 3
File: N_drive:\jhu\class\1995\db-fund.ppt
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 4
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 5
Application Programs
Database Administrator
DML Processor
DDL Compiler
Authorization Tables
Database Manager
File Manager
System Catalog
Metadata Database
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 6
What is a relational database? a database that treats all of its data as a collection of relations
What is a relation? a kind of set a subset of a Cartesian product an unordered set of ordered tuples
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 7
a set of ordered pairs, produced by combining each element of one set with each element of another set. B x C = { <H,R>,<H,B>,<T,R>,<T,B> } Cartesian products may be generated by multiplying any number of sets together. The actual number of sets involved in a particular case is said to be the degree or arity of that Cartesian product.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 8
The members of a set are unordered. Two sets are considered equivalent if and only if they contain exactly the same members, without regard for the order in which the members are listed. R = { 1,2,3,4,5,6 } = { 3,2,1,6,4,5 } G = { Marshall, Eisenhower, Bradley } = { Bradley, Marshall, Eisenhower }
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 9
A set may consist of an unordered collection of ordered tuples. For example, we could imagine the set of all ordered pairs of integers, such that the first element is the square root of the second element. R = { <1,1>,< 2,4 >,<3,9> ... }
As this ellipsis indicates, sets can be infinite in size. However, sets that are actually represented in a database must be finite.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 10
LET
B be the set of possible outcomes when rolling a single blue die. B = { 1,2,3,4,5,6 }
THEN
The Cartesian product R x B gives the set of outcomes when the two dice are rolled together: R x B: {
<1,1> <1,2> <1,3> <1,4> <1,5> <1,6> <2,1> <2,2> <2,3> <2,4> <2,5> <2,6> <3,1> <3,2> <3,3> <3,4> <3,5> <3,6> <4,1> <4,2> <4,3> <4,4> <4,5> <4,6> <5,1> <5,2> <5,3> <5,4> <5,5> <5,6> <6,1> <6,2> <6,3> <6,4> <6,5> <6,6> }
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 11
<1,1> <1,2> <1,3> <1,4> <1,5> <1,6> <2,1> <2,2> <2,3> <2,4> <2,5> <2,6>
<3,1> <3,2> <3,3> <3,4> <3,5> <3,6> <4,1> <4,2> <4,3> <4,4> <4,5> <4,6>
<5,1> <5,2> <5,3> <5,4> <5,5> <5,6> <6,1> <6,2> <6,3> <6,4> <6,5> <6,6>
1 2 3 4 5 6
1 2 3 4 5 6
A Cartesian product of two sets, shown as a connection diagram, with each member of the first set connected to each member of the other set.
Database Fundamentals: 12
File: N_drive:\jhu\class\1995\db-fund.ppt
A Cartesian product pairs every member of the first set with every member of the second set.
A relation pairs some members of the first set with some members of the second set.
Database Fundamentals: 13
S1
S2
By adding sets, relations can be extended to include ordered triples, ordered quadruples or, in general, any ordered n-tuple, as below. A relation with n participating sets is said to be of degree n or to possess arity n.
S1 x
S2
S3
Sn
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 14
Relations as a Database
An n-ary relation (i.e., a subset of a Cartesian product of n sets) could be be represented in a computer system as an n-column tabular file, with one member from the first set named in the first column of each record and one member of the second set in the second column, etc.
S1 x
S2
S3
Sn
Codd recognized that many of the files used in computerized information systems were very similar in structured to tabularized relations.
L. F. G. K. K.
1154 Elm Street 1154 Elm Street 765 Cedar Lane 2323 Maple Dr 7272 Cherry Ln.
MD MD MD MD MD
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 15
Relations as a Database
The business data file resembles a relation in a number of ways. The tabular file itself corresponds to a relation. Each column, or attribute, in the file corresponds to a particular set and all of the values from a particular column come from the same domain, or set. Each row, or record, in the file corresponds to a tuple
Domains (sets)
MI L. F. G. K. K.
address 1154 Elm Street 1154 Elm Street 765 Cedar Lane 2323 Maple Dr 7272 Cherry Ln.
state MD MD MD MD MD
If such a file is to be genuinely interchangeable with a relation, certain contraints must be met: every tuple must be unique every attribute within a tuple must be single-valued in in all tuples, the values for the same attribute must come from the same domain or set no attributes should be null
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 16
Relations as a Database
An essential attribute of a relation is that every tuple must be unique. This means that the values present in some individual attribute (or set of attributes) must always provide enough information to allow a unique identification of every tuple in the relation. In a relational database, these identifying values are known as key values or just as the key. Sometimes more than one key could be defined for given table. For example, in the table below (which represents, perhaps, a patient record file), several columns might serve as a key. Either patient number (assigned by the hospital) or social security number (brought with the patient) are possibilities. In addition, one might argue that the combination of last name, address, and birth date could collectively serve as a key. Any attribute or set of attributes that might possibly serve as a key is known as a candidate key. Keys that involve only one attribute are known as simple keys. Keys that involve more than one attribute are composite keys.
patient #
P-64122 P-75642 P-70875 P-79543 P-71536
SS #
123-45-6789 001-32-6873 444-44-5555 555-12-1212 888-88-8888
Last Name
Smith Pedersen Wilson Grant MacPherson
address
123 Main Street 1700 Cedar Barn Way 1321 North South St 808 Farragut Avenue 1617 Pennsylvania Ave
birth date
10 MAY 44 31 MAR 59 7 AUG 90 1 DEC 66 11 APR 60
In designing a database, one of the candidate keys for each relation must be chosen to be the primary key for that table. Choosing primary keys is a crucial task in database design. If keys need to be redesignated, the entire system may have to be redone. Primary keys can never be null and should never be changed. Sometimes none of the candidate keys for a relation are likely to remain stable over time. Then, an arbitrary identifier might be created to serve as a primary key. Such arbitrary keys are also known as surrogate keys.
File: N_drive:\jhu\class\1995\db-fund.ppt 1994, 1995 Robert Robbins Database Fundamentals: 17
Relations as a Database
A binary relation (i.e., a subset of a Cartesian product of two sets) could be be represented in a computer system as two-column tabular file, with one member from the first set named in the first column of each record and one member of the second set in the second column. For example, a binary relation could be used to provide unique three-letter identifiers for academic departments. Additional relations could be used to give more information about individual departments or individual faculty members.
Room 203 Room 714A Room 141 Room 320 Room 303
Natural Science Bldg Wells Hall Natural Science Bldg Chemistry Bldg South Kedzie Hall
355 4640 355 5210 353 4610 355 9175 355 6590
F. F. G. K. L.
1533 Raleigh Dr. 2842 Colony Ave. 99 W. East St. 99 W. East St. 7272 Cherry Ln.
MD MD MD MD MD
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 18
Relations as a Database
Yet another relation could be used to show what faculty were members of what departments. Notice that faculty member 999-99-9999 is a member of more than one department and that, even on this short list, the department of zoology has two members given.
Relations of this sort, that combine identifiers from two other relations, provide the glue that holds a relational database together.
other fields
SS Number
Faculty Relation
Member-of Relation
SS Number
Dept Code
Departments Relation
Dept Code
other fields
Whenever the values in an attribute column in one table point to primary keys in another (or the same) table, the attribute column is said to be a foreign key. Columns containing foreign keys are subject to an integrity constraint: any value present as a foreign key must also be present as a primary key.
File: N_drive:\jhu\class\1995\db-fund.ppt 1994, 1995 Robert Robbins Database Fundamentals: 19
Codd devised some additional operators to provide extra manipulatory power: select project join divide
The operators have now been extended to include more useful manipulations: outer join outer union
1994, 1995 Robert Robbins Database Fundamentals: 20
File: N_drive:\jhu\class\1995\db-fund.ppt
First Normal Form: A relation is in first normal form (1NF) if and only if all underlying domains contain atomic values only. Second Normal Form: A relation is in second normal form (2NF) if and only if it is in 1NF and every non-key attribute is fully dependent on the primary key. Third Normal Form: A relation is in third normal form (3NF) if and only if it is in 2 NF and the nonkey attributes are mutually independent.
File: N_drive:\jhu\class\1995\db-fund.ppt 1994, 1995 Robert Robbins Database Fundamentals: 21
other fields
SS Number
Faculty Relation
Member-of Relation
SS Number
Dept Code
Departments Relation
Dept Code
other fields
The three files represented above are all relations in the formal sense. Chen (1976) noted that different relations may play different roles in a database and that being able to recognize and document those roles is a key part of database design. The faculty and the department relations above both store information about particular real-world entities. The member-of relation, on the other hand, stores information about specific relationships involving individual pairs of real-world entities.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 22
Conceptual Database
Definition and mapping written in data definition language
Physical Database
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 23
External View n
Although the E-R approach does not require an underlying relational model, most E-R models can be converted to relational models fairly easily.
The entity-relationship approach (Chen, 1976) improved the mapping between the semantics of a database design and that portion of the real world being modeled with the data.
Physical Database
Codds relational model (1970) provided the first formal basis for database design.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 24
External View 1
External View n
Moving between conceptual models can be difficult, especially if automated tools to facilitate the move are not available.
A different conceptual model may be necessary to capture the semantics of the database domain.
If a commercial relational database system is used, mapping from a relational conceptual model to the physical database should be relatively straightforward.
If a commercial RDBMS is used, a relational conceptual model provides a basis for designing and implementing an underlying physical database.
File: N_drive:\jhu\class\1995\db-fund.ppt
Physical Database
Database Fundamentals: 25
Faculty
Departments
Students
Classrooms
Courses
Relationships between members of entity sets are represented with named diamonds that are connected to the rectangles of the participating entity sets with directed arcs:
Departments
4,n
majors in
1,2
Students
Arcs are drawn with an orientation that points from foreign keys to primary keys. The min:max participation cardinality can be indicated by placing pairs of numbers on each arc. Here, 4,n means that every department is required to have at least four student majors, but can have many more; 1,2 means that each student is required to have at least one major and is permitted to have no more than two majors. Sometimes only the maximum participation cardinalities are shown.
File: N_drive:\jhu\class\1995\db-fund.ppt 1994, 1995 Robert Robbins Database Fundamentals: 26
Relates
Entity Set B
Relates
Entity Set B
Relates
Entity Set B
Relates
Entity Set B
One-to-many: (mandatory)
Entity Set A
1:1
Relates
1:n
Entity Set B
One-to-many: (optional)
Entity Set A
1:1
Relates
0:n
Entity Set B
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 27
Departments
member of
Faculty
Departments
Faculty
The 1,1 cardinality for departments means that every department must have one and only one chairman. The 0,1 cardinality for faculty means that not all faculty participate in the chairman-of relationship and that no faculty member may participate more than once. That is, not all faculty are chairmen and no one faculty member may serve as chairman of more than one department.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 28
Departments
Faculty
1,1
chairman of
0,1
A database design derived from the figure above would allow a faculty member to chair a department of which he/she was not a member. To indicate an integrity constraint that requires membership in a department in order to chair the department, the E-R diagram would be modified as below:
Departments
m member of n
Faculty
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 29
Person
1:n
ISA
1:n 1:n 1:n 1:n
Faculty
Staff
Student
1:n
1:n
ISA
1:n 1:n 1:n 1:n 1:n
ISA
1:n 1:n 1:n
Tenured
Untenured
Temporary
Graduate
Undergraduate
Nondegree
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 30
Relationships may be recursive. Here, this E-R figure represents all possible mother-child relationships among all humans.
mother:child
This cardinality indicates that not all persons participate in the relationship as mothers, but that those who do participate may participate one or more times.
0:n
1:1
This cardinality indicates that all persons participate in the relationship as child and that no child may have more than one mother.
All Persons
Recursive relationships are particularly useful for representing any data structure that could also be represented as a directed graph. Entries in the entity table represent nodes of the graph and entries in the relationship table represent arcs.
File: N_drive:\jhu\class\1995\db-fund.ppt
Database Fundamentals: 31